Why Nightingale Is Shaping the Future of Enterprise Monitoring

Nightingale is an open‑source, enterprise‑grade monitoring solution jointly developed by Didi's foundational platform and Didi Cloud, designed to meet the monitoring demands of the cloud‑native era.

It achieves product completeness, high system availability, and excellent user experience, supporting scenarios from a few machines to hundreds of thousands, and works on both cloud‑native and bare‑metal environments with flexible, extensible plugins.

The system introduces a tree‑structured navigation called the object tree, which groups monitoring objects for easy lookup, management, and policy application. Applying a monitoring strategy to a node automatically affects all descendant nodes and their machines.

Dashboard customization has been greatly improved, offering visual chart thresholds, classification, and drag‑and‑drop management, making dashboard creation straightforward.

Key Differences from Open‑Falcon

Alert engine refactor : switches from a pure push model to a push‑pull hybrid, enabling complex conditional and no‑data alerts.

Object‑tree navigation : replaces flat HostGroup with a hierarchical tree, simplifying policy binding and enhancing flexibility.

Index module upgrade : replaces MySQL‑based metric indexing with an in‑memory index for higher scalability and performance.

Time‑series database optimization : adopts Facebook’s Gorilla compression for recent data in memory while retaining rrdtool for long‑term storage.

High‑availability alert engine : uses heartbeat mechanisms to auto‑remove failed judges and ensure continuous alert processing.

Built‑in log monitoring : native log matching and extraction capabilities are integrated into the client.

Operational simplifications : merges multiple modules into a single monapi component, reducing deployment complexity and improving performance.

Centralized configuration : consolidates common settings into dedicated YAML files for clearer maintenance.

Similarities to Open‑Falcon

The data model (metric, endpoint, tags) remains unchanged, and agents (collectors) are reusable.

The overall data flow and processing logic still use a flexible push model with separate storage and alert evaluation pipelines.

Nightingale Architecture

Collector (agent) gathers common metrics, supports native log monitoring, plugins, and direct data reporting via APIs.

Transfer receives data from collectors and forwards it to multiple TSDB and judge instances using consistent hashing.

TSDB (graph component) stores historical data, can operate in dual‑write mode for redundancy, and forwards data to the index module.

Index is an in‑memory indexing module that replaces MySQL, offering faster and more flexible queries.

Judge evaluates alerts based on synchronized policies and pushes alert events to a Redis queue.

Monapi (alarm) consumes judge events, enriches them, and republishes alert messages.

Sender components (mail‑sender, sms‑sender, etc.) read alerts from Redis and dispatch notifications.

Monapi also provides unified APIs for frontend access, consolidating functionalities of previous modules.

MySQL remains the metadata store for users, teams, tree nodes, alert policies, dashboards, and other configuration data.

Ongoing Work

Developing a metric aggregation component for cluster‑level monitoring.

Seamless integration with Kubernetes.

Expanding and maintaining a richer set of monitoring plugins, including contributions from the Open‑Falcon community.