Compose 示例使用示例凭据并对外暴露端口,共享或公网主机上部署前需改密码并检查网络访问;默认登录为 root / root.2020,访问 http://localhost:17000;AI agent 需自行配置模型端点(支持 OpenAI 兼容 API、Claude、Gemini 等),核心告警不依赖它;MCP 写工具默认不开放,需显式配置,且部分 Compose 示例关闭了 token 认证。

nightingale
ccfosApache-2.0活跃维护开源自托管的告警平台,统一处理指标、日志和数据库告警,内置 AI Agent 与 MCP Server,适合搭建可观测性告警体系。
Open-source, self-hosted alerting for metrics, logs, and databases. Includes a built-in AI agent and MCP server.
git clone https://github.com/ccfos/nightingale.git
cd nightingale/docker/compose-bridge
docker compose up -dREADME 未说明具体 CPU/内存/显存要求;快速开始用 Docker Compose 启动 Nightingale、MySQL、Redis、VictoriaMetrics 和 Categraf,单机小规模部署可选内置 TSDB。
自托管告警平台,把指标、日志、数据库的告警规则、事件处理和通知路由统一到一处
开源自托管的告警平台,统一处理指标、日志和数据库告警,内置 AI Agent 与 MCP Server,适合搭建可观测性告警体系。
核心能力
- 用 PromQL、日志查询或 SQL 定义告警条件
- 按业务组划分规则并分配团队权限
- 通过条件管道做事件抑制、订阅、标签重写与路由
- 内置 AI agent 可排查告警并生成规则和看板
- 内置 MCP 服务让外部助手调用其工具
容易踩的坑
- v9.3.0最新正式版2026-10-21 · 2026-10-21 08:10 UTC
What's Changed
- feat: native Microsoft Teams, Twilio (SMS / voice), Pushover, ntfy, Splunk On-Call (VictorOps) and LINE notification channels, each with built-in message templates (#3431, #3435)
- feat: the unit picker accepts custom units and searches units by description
- feat: table row actions expand into inline icon buttons when the row has room
- feat: the AI assistant adds preset questions for CloudWatch Logs
- fix: trigger values keep enough precision when rounding would hide the deviation from the threshold (#3429)
- fix: events of unknown idents are muted when a rule is limited to its business group (#3432)
- fix: host alert rules are no longer dropped by the empty-expression trigger filter
- fix: sub-path deployments — generated links honor the deployment prefix, exclude rules win over already-prefixed URLs, and an externally supplied prefix is kept at build time
- fix: toggling a rule's status keeps the row in place, and overlapping status updates are serialized so a stale read can no longer revert a confirmed status
- fix: the Elasticsearch log total is capped at
max_result_window - fix: notification media expand their advanced settings on validation failure, and the media type list / media list scroll independently
- fix: the log detail drawer opens at medium size, log download failures show a message, the scrollbar is visible in dark mode, and the app re-initializes after leaving the service error page
- docs: an editable SVG architecture diagram and deep links to the documentation site in the README (#3430)
v9 highlights
- Introducing Nightingale AI: a built-in AI assistant, a Skills marketplace, LLM configuration management, and page-aware prompt recommendations
- A built-in time series database that works out of the box, so small-scale setups no longer need a separate Prometheus / VictoriaMetrics
- Redesigned navigation menu, global layout and table UI
- Fully rebuilt alert rule / mute rule / subscribe rule / notification rule forms
- Reworked notification channel management
- A new event pipeline execution tracking page that shows the processing in detail
- A new generation of log explorer with unified support for Elasticsearch, Loki and VictoriaLogs
Upgrade steps
Replace the binary and restart. No schema changes in this release.
Notes
- The new AI assistant relies on Redis Streams, so Redis 5.0 or later is required (Redis 7.0+ recommended for Cluster users, to enable sharded Pub/Sub)
- Microsoft Teams and ntfy are created automatically at startup. Twilio, Pushover, Splunk On-Call and LINE need account credentials, so add them yourself under notification media. See https://github.com/ccfos/nightingale/blob/main/doc/api/notify-channel-native.md
- If you run n9e-edge or n9e-pushgw, upgrade them together with n9e
Full Changelog: https://github.com/ccfos/nightingale/compare/v9.2.0...v9.3.0
- v9.2.02026-10-11 · 2026-10-11 07:24 UTC
查看更新说明
What's Changed
- feat: native Jira, Discord, JSM Alert, Slack and Mattermost notification channels (#3408), and notification channel configs can reference user variables (#3349)
- feat: dashboard panels can mix datasources — each query target carries its own datasource, backed by a new v2 multi-datasource batch query API with KQL support (#3292)
- feat: anonymous, time-limited dashboard sharing links, plus a read-only fullscreen view with URL switches to hide the header and variables (#3345)
- feat: Grafana dashboard import rewritten — a conversion report shows what was migrated and what is unsupported before saving
- feat: dashboard query variables support label/value options and Doris SQL time macros; embedded Grafana (iframe) dashboards sync the time range and refresh interval
- feat: user accounts can be disabled and re-enabled without losing their roles, teams and permissions (#3395)
- feat: OAuth2 login can assign default teams to new users (#3406), and
/login?sso=xxxredirects straight to the given SSO provider - feat: built-in content supports arbitrary languages; ja / ru / pt-BR / es / id / ko / fr added on the backend, and pt-BR / es / id / ko / fr added to the console (#3352)
- feat: custom alert severity names, a fullscreen live view for active alert events, and filtering historical alert events by hash (#3392)
- feat: an aggregated Nightingale AI page with renamable and shareable conversations (#3325); the AI assistant can dispatch script tasks through ibex (#3378)
- feat: integration center onboarding guide (collect template → dashboard → alert rule); new x509_cert integration, rabbitmq_exporter collect template and SNMP device health alert rules (#3394, #3348)
- feat: 403 responses render in place instead of redirecting to
/403, so the URL survives and going back works - feat: passwordless demo login entry for public demo sites, off by default (#3426) — see Notes
- perf: AI chat renders markdown incrementally, and A2A task store write amplification is cut ~30x (#3413)
- security: close an SSRF guard bypass via 6to4 / NAT64 / site-local IPv6 addresses (#3364), redact credentials embedded in datasource URLs (#3424), validate TDengine database / table names (#3423), tighten the dashboard share token scope (#3368), and upgrade vulnerable dependencies (#3419, #3422)
- fix: config key initialization now converges across instances, fixing a 401 / login loop in multi-instance deployments (#3385)
- fix: an unschedulable rule cron pattern no longer crashes n9e / n9e-edge / n9e-alert on every restart, and cron patterns are validated on save (#3407)
- fix: alert mutes that are not active yet are now synced into the engine cache (#3386), and empty mute tags are normalized (#3425)
- fix: populate the recovery time before dispatching alert events (#3382)
- fix: callback channels can notify without a message template (#3350)
- fix: disabled datasources can still be queried, and are kept out of write targets
- fix: an oversized VictoriaLogs line no longer fails the whole query (#3344)
- fix: PostgreSQL datasources use the configured database when initializing the client (#3367)
v9 highlights
- Introducing Nightingale AI: a built-in AI assistant, a Skills marketplace, LLM configuration management, and page-aware prompt recommendations
- A built-in time series database that works out of the box, so small-scale setups no longer need a separate Prometheus / VictoriaMetrics
- Redesigned navigation menu, global layout and table UI
- Fully rebuilt alert rule / mute rule / subscribe rule / notification rule forms
- Reworked notification channel management
- A new event pipeline execution tracking page that shows the processing in detail
- A new generation of log explorer with unified support for Elasticsearch, Loki and VictoriaLogs
Upgrade steps
Replace the binary and the
integrationsdirectory, then restart. To pick up the new metric descriptions in the added languages, also replace ` - v9.1.12026-08-18 · 2026-08-18 09:50 UTC
查看更新说明
What's Changed
- feat: list pages keep the current page in the URL, so a refresh or a trip into a detail page brings you back to where you were; the page resets to 1 only on save or when you switch business group
- feat: the user list gains an account source column, and the last-active-time column that was missing from the column config — neither rendered nor selectable — is fixed
- perf: the logs viewer renders rows through a virtual list, so large log volumes no longer stutter
- fix: concurrent webhook / callback queue creation no longer blocks on itself and drops events
- fix: a malformed
HH:MMeffective time span in an alert rule is now rejected outright instead of being saved silently as an unusable config - fix: integration component icons no longer break on Linux when an upgraded database has a directory case or spelling mismatch, and the icon route now rejects path traversal
- fix: woff2 fonts and
n9e-collect-templates/*.tomlcollect templates were treated as frontend routes and servedindex.html, which broke their download - fix: the
board_busigrouptable never got its composite primary key, because the tag was written outside thegormtag - fix: correct the normalization of LLM provider base URLs that do not end in
/v1 - fix: an Elasticsearch alert rule no longer keeps a stale
date_fieldwhen the selected index has no date fields - fix: the Doris log explorer resolves flattened pseudo field names back to the real columns when filtering
- fix: event pipeline header parameters are now submitted as an object
- fix: MCP APIs go through the
N9E_PATHNAMEprefix in sub-path deployments - fix: the datasource dropdown search now also matches the datasource type name
- fix:
raw_messageis surfaced when an API call fails
v9 highlights
- Introducing Nightingale AI: a built-in AI assistant, a Skills marketplace, LLM configuration management, and page-aware prompt recommendations
- A built-in time series database that works out of the box, so small-scale setups no longer need a separate Prometheus / VictoriaMetrics
- Redesigned navigation menu, global layout and table UI
- Fully rebuilt alert rule / mute rule / subscribe rule / notification rule forms
- Reworked notification channel management
- A new event pipeline execution tracking page that shows the processing in detail
- A new generation of log explorer with unified support for Elasticsearch, Loki and VictoriaLogs
Upgrade steps
Replace the binary and the
integrationsdirectory, then restart.Schema changes (skip this if your database account can create tables)
Nightingale creates the tables for you. If the database account Nightingale connects with cannot create tables, you need to create them by hand — the DDL is at https://github.com/ccfos/nightingale/blob/main/docker/migratesql/migrate.sql
Notes
- The new AI assistant relies on Redis Streams, so Redis 5.0 or later is required (Redis 7.0+ recommended for Cluster users, to enable sharded Pub/Sub)
- Replacing only the binary does not enable the built-in TSDB: the
[EmbeddedTSDB]section exists only in the newetc/config.toml, so carrying over an old config file leaves the feature off — copy the section across yourself. It is handled by the center process only (n9e-edge / n9e-alert / n9e-pushgw ignore it and log a warning), and the data lives on that center instance's local disk, so it suits single-instance deployments only; with multiple center replicas, use an external TSDB instead - telegraf users need to append
ignore_host=falseto the metrics write address, otherwise the hosts running telegraf will no longer register into the host list - If you run n9e-edge or n9e-pushgw, upgrade them together with n9e
- v9.1.02026-08-06 · 2026-08-06 12:18 UTC
查看更新说明
What's Changed
- feat: built-in time series database — metrics pushed by Categraf are stored locally, so no external Prometheus / VictoriaMetrics is required to get started; a Prometheus datasource named
embedded-tsdbis auto-registered on first start. Existing setups are respected: if any enabled Prometheus datasource is already present, the datasource is not auto-created — samples are still written locally, and you can add a Prometheus datasource pointing at the built-in TSDB to query them (#3283) - feat: import datasources from Grafana in one click, with a per-datasource result summary (#3295)
- feat: datasource page revamp — after saving a datasource, Nightingale probes it with sentinel metrics to report which built-in dashboard / alert rule templates already have data, and guides you to your first query (#3301)
- feat: per-cycle alert evaluation records — each rule evaluation persists what it queried and how it judged to the alert engine's local disk, inspectable from a drawer on the alert rule page (#3305)
- feat: notification channel configs can be tested, and message templates previewed, before they are saved (#3302)
- feat: Categraf collect-config wizard — a new
/agents/categraf/collect.shendpoint serves the applier script, with plugin templates and metric verification in the console (#3286) - feat: event pipeline supports mock events in try-run, time-range filtering on execution records, batch enable/disable, and a new change API (#3281, #3285)
- feat: built-in alert rule templates in integrations greatly expanded and revised, with en_US i18n (#3282)
- feat: MySQL datasources can append extra params to the DSN (#3299)
- feat: Doris datasources support
doris.internal_addrfor the edge process to reach FE MySQL (#3298) - feat: alert rule list supports filtering by trigger type
- feat: active alert event list shows the value at trigger time, adds three-state tags, and remembers filter panel, auto-refresh interval and time range across visits
- feat: log explorer adds a query doc button for Loki and VictoriaLogs, lets you append a field filter straight from the logs viewer, and supports BCE BLS drilldown
- feat: dashboard TableNG panel supports a row detail drawer
- feat: host page onboarding — one-click host monitoring pack, test alert action, and next-steps cards
- feat: datasource proxy and log query access are now written to the audit log with the user and the payload
- feat: edge retries event persistence to center, with a tightened per-request timeout
- feat: new API to check whether any notification was ever delivered successfully (#3300)
- perf: speed up notification record queries and the daily cleanup, backed by two new
notification_recordindexes created online at startup (#3311) - fix: deep copy events before pushing them to the queue, so a recovery event no longer overwrites a not-yet-consumed trigger event in place
- fix: a blank DingTalk app config no longer breaks group robot notifications (#3309)
- fix: pin explicit column types on the
ai_*models to stop AutoMigrate schema drift, which had been failing the migration of those tables - fix: support
max_completion_tokensfor newer OpenAI models (#3306) - fix: guard invalid label names in alert rule
event_relabel_config(#3287, #3296) - fix: accept YAML content for collect builtin payloads (#3307)
- fix: allow force-saving a datasource that fails its health check (#3304)
- fix: probe the global default datasource against the full datasource list before per-engine cluster filtering, so a default datasource owned by another cluster is no longer cleared
- fix: correct alert rule units
- fix: repair builtin skill YAML frontmatter and expose code search tools in chat
- fix: give the async table migration its own gorm session, so one failed statement no longer poisons the rest
V9 new feature
- feat: Introduce Nightingale AI — built-in AI assistant, Skills marketplace, LLM config management, with page-specifi
- feat: built-in time series database — metrics pushed by Categraf are stored locally, so no external Prometheus / VictoriaMetrics is required to get started; a Prometheus datasource named
- v9.0.02026-07-25 · 2026-07-25 03:55 UTC
查看更新说明
What's Changed
- feat: alert rules support test fire — trigger a rule on demand against real queried series and get a stage-by-stage report (query check → threshold → event → notify pipeline → notification), to verify the whole alerting chain before the condition is ever met (#3274)
- feat: log query supports VictoriaLogs (#3239)
- feat: alert mute rules support notify-only mute — the event is still generated and recorded (and tagged as muted in the event list and detail) while notifications are suppressed (#3250)
- feat: the host page supports one-click Categraf installation — collector packages ship with the server, and a ready-to-run install script is generated per platform (#3272)
- feat: the built-in
/mcpendpoint now serves a fine-grained toolset (alerts, targets, datasource, mutes, notify rules, alert subscribes, event pipelines, users, metrics, logs, dashboards, roles) — read-only by default, with write tools and the toolset whitelist both requiring an explicit opt-in (#3245) - feat: AI Skills support authorization scope — public or team-private, with editing restricted to authorized teams (#3247, #3268)
- feat: alert rule / mute / subscription / notification rule forms redesigned — section cards, right-side navigation with a live condition summary, auto-naming, quick duration presets, and scenario-based empty states
- feat: message templates and the template center support i18n, so a single template renders in the recipient's language (#3235, #3238, #3261)
- feat: alert history events can be retained for a configurable number of days (
CleanAlertHisEventDay, cleaned in nightly batches), with a new composite index and cursor pagination (#3264) - feat: the AI summary node in event pipelines can reuse a centralized LLM config instead of carrying its own (#3242)
- feat: full i18n coverage on the console
- feat: list tables support inline row actions, sortable creator and time columns, and a pagination quick jumper
- fix: aggregated alert event operations no longer fail with HTTP 414 — event IDs are now sent in the POST body as a JSON array
- fix: batch-deleting history events no longer removes events that still have an active alert (#3263)
- fix: quote the external config column so DDL works on MySQL 9.7 (#3276)
- fix: sanitize user input and detail URLs before HTML rendering (XSS hardening)
New Contributors
- feat: Introduce Nightingale AI — built-in AI assistant, Skills marketplace, LLM config management, with page-specific prompt recommendations
- feat: Redesigned navigation menu, global layout, and table UI
- feat: Refactored notification channel management
- feat: New event pipeline execution tracking page with detailed execution view
Upgrade note ⚠️
The new AI assistant relies on Redis Streams, so Redis 5.0 or later is required (Redis 7.0+ recommended for Cluster users to enable sharded Pub/Sub).
Full Changelog: https://github.com/ccfos/nightingale/compare/v9.0.0-beta.4...v9.0.0
用户点评
登录用户的真实使用记录,可按版本和硬件筛选还没有人点评。第一个说出真实体验的人最有价值。
Nightingale brings alert rules, event processing, and notification routing into one place. Connect Prometheus, VictoriaMetrics, Elasticsearch, Loki, ClickHouse, and other data sources you already run, then deliver alerts to Slack, PagerDuty, and your team's existing tools.
Self-hosted · Apache-2.0 · Built-in AI agent · MCP server
Why Nightingale?
- Give teams ownership of their alerts. Organize rules into business groups, assign team permissions, and manage rules and notification settings through the UI and API.
- Bring scattered alerting into one place. Evaluate rules against metrics, logs, and SQL data sources while keeping your existing collectors, storage, and Grafana dashboards.
- Understand what happened to an alert. Inspect rule evaluation records, historical events, and notification results to trace a query through to delivery.
Quick start
With Git and Docker Compose installed, start the included evaluation stack:
git clone https://github.com/ccfos/nightingale.git
cd nightingale/docker/compose-bridge
docker compose up -d
This starts Nightingale, MySQL, Redis, VictoriaMetrics, and Categraf. Open http://localhost:17000 and sign in with root / root.2020.
To get your first alert:
- Connect a data source. Add your existing Prometheus-compatible endpoint, or use
http://victoriametrics:8428for the VictoriaMetrics instance in this Compose stack. - Create an alert rule. Choose a business group and data source, then enter a PromQL expression. For an always-firing test, use
vector(1) > 0and set the duration to0. - Configure delivery. Set up a notification channel, create a notification rule, and attach it to the alert rule. Check that the test notification arrives, then disable the test alert.
The Compose stack uses example credentials and exposes service ports for local evaluation. Change credentials and review network access before deploying on a shared or public host. See deployment options for other ways to run Nightingale.
How it fits into your stack
Nightingale queries your data sources, evaluates alert conditions, processes events, and routes notifications. Your existing data stays in its current stores.
Keep Grafana for visualization and your on-call platform for scheduling, escalation, and incident response. Nightingale also includes dashboards for teams that want to explore data alongside their alerts.
Starting without a monitoring stack? The standalone configuration includes an optional embedded TSDB for small, single-instance deployments. Categraf is an optional collector for hosts, middleware, databases, and network devices.
Key capabilities
| Capability | What you can do |
|---|---|
| Alerting across data sources | Use PromQL, log queries, or SQL to define conditions. Apply a rule to multiple instances of the same data source type. |
| Team ownership | Group rules and dashboards by business group, assign team permissions, and connect OIDC, OAuth2, LDAP, or CAS for sign-in. |
| Event processing and routing | Mute notifications, subscribe to alerts, enrich or rewrite labels, and route events through conditional pipelines. |
| Alert execution records | Review evaluation queries and results, active and historical events, and notification delivery records. |
| Reusable integrations | Start with bundled collector configurations, alert rules, and dashboards. Review queries and thresholds for your environment before enabling them. |
| Distributed evaluation | Distribute rules across alerting engines and use n9e-edge to evaluate alerts close to remote data sources. |
Notification integrations include Slack, PagerDuty, Discord, Email, Telegram, Mattermost, Jira, and Jira Service Management, with HTTP webhooks and scripts for custom destinations. See the native notification channel reference for configuration details.
For automated responses, connect ibex to run predefined remediation scripts when an alert fires.
Built-in AI agent
Nightingale includes an AI agent you can use directly in the web UI. The agent runs inside Nightingale, calls tools to inspect your monitoring data and configuration, and works through tasks over multiple steps.
- Investigate alerts. Query related metrics and logs, inspect affected hosts, and explain findings using the data it retrieves.
- Troubleshoot the alerting process. Inspect rules, evaluation logs, mute settings, event processing, and notification results to find why an alert did not fire or reach its destination.
- Create and update configuration. Build alert rules and dashboards, generate PromQL and SQL, and configure notification rules, mutes, and subscriptions through conversation. The built-in tools for updating existing alert rules and dashboards present proposed changes for confirmation.
- Extend it with Skills. Bundled Skills cover common monitoring workflows. Add your team's procedures, reference material, and scripts as custom Skills, including Skills imported from Git.
For example:
Why did this alert fire? Check the affected host's metrics and logs around the trigger time.
Create a memory-usage alert for the production hosts and notify our team in Slack.
Configure a model endpoint to get started. The agent supports OpenAI-compatible APIs, Claude, Gemini, and compatible self-hosted models. You choose the model service and credentials; core alerting works independently of the agent.
Model provider configuration · Skill management · Bundled Skills
Connect external agents
- MCP lets external assistants call Nightingale's tools. The server runs inside Nightingale at
/mcp, exposes read tools by default, and applies the caller's existing API permissions. Write tools require explicit configuration. See MCP setup. - A2A lets another agent delegate a task to Nightingale's built-in agent. See A2A integration.
Cursor plugin
This repository also contains a Cursor plugin that connects to the built-in MCP server of your own Nightingale deployment. The plugin uses Streamable HTTP and the same permissions as your Nightingale account.
Prepare Nightingale. Enable [HTTP.TokenAuth].Enable, leave
[HTTP.A2A].Disable and DisableMCP unset or false, and create a personal token
under Profile → Token management. Some Docker Compose examples disable token
authentication; check the configuration you actually deploy. See
MCP setup for the server configuration.
Install from a repository. In Cursor, open Customize → Plugins → Add →
From Local Repository and select a checkout containing these plugin files.
The n9e marketplace exposes one plugin, nightingale; choose Add to install
it. .cursor-plugin/marketplace.json provides the repository installation entry.
Repository imports use a Git revision, so commit the plugin files in the checkout
before importing it. This also works before a public Marketplace listing exists.
To test uncommitted changes, copy the plugin configuration under Cursor's local plugin directory instead. On macOS or Linux, run these commands from the repository root:
mkdir -p ~/.cursor/plugins/local/nightingale/.cursor-plugin
cp .cursor-plugin/plugin.json ~/.cursor/plugins/local/nightingale/.cursor-plugin/
cp mcp.json ~/.cursor/plugins/local/nightingale/
Use a different folder name if another local plugin already uses that path.
Cursor skips local-plugin symlinks pointing outside ~/.cursor/plugins/local.
Restart Cursor or run Developer: Reload Window, then open
Customize and check that the Nightingale plugin and its MCP server appear.
This local installation does not depend on a Marketplace listing.
Configure your instance. Open Customize → Plugins → nightingale → Configure and set the variables below. For a team-distributed plugin, an administrator sets them under Dashboard → Plugins → Configure:
| Variable | Value |
|---|---|
N9E_MCP_URL | The full endpoint, such as https://n9e.example.com/mcp. Include /mcp; use the instance address reachable from the client. |
N9E_TOKEN | Your Nightingale personal token, sent as X-User-Token. |
For a local Nightingale process, the endpoint is normally
http://127.0.0.1:17000/mcp. Use HTTPS for remote connections. The manifest
declares only the configuration fields; mcp.json contains placeholders. Keep
the actual token in your own Cursor configuration, not in this repository.
Team-distributed plugin variables are shared by the team; choose the
Nightingale account and permissions for that shared connection accordingly.
Verify the connection. In Customize, enable the plugin's MCP server and
check that it connects. Cursor prefixes plugin MCP names, so it may appear as
plugin-nightingale-nightingale. If it stays at Connecting after you save
the variables, open the MCP entry and choose Reload. List its tools, then ask:
List the business groups I can access in Nightingale.
Which alerts are firing right now? Group them by severity.
The results should match what the same user can see in Nightingale. Read tools
are enabled by default; server-side write-tool configuration is described in
MCP setup. A 401 response means
the token is missing, invalid, or token authentication is disabled. A 404
usually means the endpoint or reverse-proxy route is wrong; it must be /mcp,
not /api/n9e/mcp.
For direct client configuration or OAuth, see MCP setup. Plugin structure, configuration variables and local installation follow the Cursor plugin reference and local development guide.
Product screenshots
Manage alert rules by data source and business group:

Deployment
| Option | Start here |
|---|---|
| Local evaluation with Docker Compose | Included Compose stack |
| Linux binaries for amd64 and arm64 | Release downloads and configuration reference |
| Kubernetes | Helm chart and installation instructions |
For production, pin a release, configure credentials and TLS, back up the metadata database, and monitor rule evaluation and notification failures. Multiple Nightingale instances share a metadata database and Redis; use external time-series storage for a multi-instance deployment. The embedded TSDB stores data on one instance's local disk.
See the documentation, the installation guide, release notes, and security policy for further guidance and supported versions.
FAQ
Do I need to replace my collectors or move my monitoring data?
No. Nightingale can query your existing data sources directly. Keep your exporters and collectors. Categraf and the embedded TSDB are available when you need collection or local storage.
Can I import existing Prometheus alert rules?
Yes. The rule import supports Prometheus YAML, including expressions, durations, labels, and annotations. Review the converted rules and rebuild notification routing in Nightingale. Import is not a complete conversion of alertmanager.yml; run both systems during evaluation before switching notifications over.
Can I manage rules through Git and CI?
Rules can be exported as JSON and created or updated through the HTTP API, so you can build a workflow around version-controlled configuration. Nightingale does not currently provide built-in rule revision history or rollback to earlier revisions.
Is AI required, and where do model requests go?
Alerting works without AI. The built-in assistant sends prompts and the data it uses to your configured model endpoint; you can use a model hosted in your own network. External MCP clients use their own model settings. Model service credentials and usage costs are managed by you.
Does Nightingale provide on-call scheduling and escalation?
Connect an on-call platform such as PagerDuty for schedules, escalation policies, and incident response. Nightingale handles rule evaluation, event processing, and notification routing.
Community
Questions, bug reports, documentation improvements, and contributions are welcome in English.
- GitHub Discussions — ask questions and share ideas.
- GitHub Issues — report bugs and request features. Include the version, deployment method, and steps to reproduce.
- Slack — join the community.
- Adopter reports — see how others use Nightingale and share your own experience.
- Security policy — report vulnerabilities privately and check version support.
For substantial changes, open an issue to discuss the approach before submitting a pull request. Please follow the Code of Conduct.
Nightingale was originally developed at DiDi and donated to CCF ODC in 2022. Learn about project governance, committers, and contributors.
Stargazers over time
License
Nightingale is available under the Apache License 2.0.