搜索中...
🔍

未找到相关结果

Akemi

夜莺Nightingale部署与使用

Kubernetes 夜莺 监控告警
字数统计: 2.2k阅读时长: 9 min
2026/08/22

集中监控方案对比

维度 Prometheus Zabbix 夜莺 N9E
数据采集 ✅ 自己拉取（pull） ✅ 自己采集（agent） ❌ 不做采集，靠外部
数据存储 ✅ 本地 TSDB ✅ 自带数据库 ❌ 不存数据，接外部库
查询语言 PromQL 自有查询 用数据源的查询语言
可视化 基础 中等 基础（官方建议用 Grafana）
告警引擎 Alertmanager 内置 ✅ 这是核心
通知渠道 几种（需要配置） 几十种 20种内置
告警自愈 ❌ ✅ ✅
多数据源 ❌ 只管自己 ❌ 只管自己 ✅ Prom/ES/Loki/CK/MySQL等

我之前还以为夜莺是prometheus的替代品，实际上不是的 ， 某种意义上来说它与alertmanager定位相同

产品特点

能力 说明
告警规则 支持 PromQL / 日志查询，可导入 Prometheus 原生规则
屏蔽规则 按时间/标签条件屏蔽告警
订阅规则 用户订阅自己关心的告警
通知规则 灵活的分发策略
20种通知媒介 电话、短信、邮件、钉钉、飞书、企微、Slack 等
事件管道 Pipeline 处理，给告警附加元信息 / relabel
告警自愈 告警后自动触发脚本（清磁盘、抓现场等）
业务组 分门别类管理规则，支持权限体系
历史告警 存档 + 多维查询统计 + 聚合分组

  1. 多数据源对接：

    • Prometheus / VictoriaMetrics
    • ElasticSearch / Loki（日志告警）
    • ClickHouse / TDEngine
    • MySQL / Postgres
    • 一套告警规则可以跨数据源

  2. 边缘机房下沉部署：

    • 中心端 + n9e-edge 模式
    • 边缘机房网络割裂时，告警不受影响
    • 对多机房场景很实用

  3. 采集器 Categraf：

    • All-in-one，替代 Node Exporter + 各种中间件 Exporter
    • 指标命名跟 Telegraf（而非 Node Exporter）
    • 和夜莺丝滑对接

Docker Compose部署

官方文档：夜莺项目整体介绍

居然是中文文档，甚至有点不习惯

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
git clone https://github.com/ccfos/nightingale.git
cd nightingale/

# 提供了host网络和bridge网络两种方式，使用host网络
cd compose-host-network
docker compose up -d
WARN[0000] /root/nightingale/docker/compose-host-network/docker-compose.yaml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion
[+] Running 5/5
 ✔ Container redis       Running                                                               0.0s
 ✔ Container mysql       Running                                                               0.0s
 ✔ Container n9e         Running                                                               0.0s
 ✔ Container categraf    Running                                                               0.0s
 ✔ Container prometheus  Started     
 
我这个prometheus因为我kind集群里的prometheus用端口转发，已经占用了9090端口了，所以直接不用了
直接用我自己的prometheus就行
 
访问17000端口
root/root.2020

添加数据源

我本地的架构比较复杂，目前我的prometheus是通过remote write转发到vm中进行存储
而且夜莺的数据源一方面是要从里面读取数据来查询，一方面是categraf要往里面写数据
所以我连数据源应该连我的vm

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
1.添加数据源vm
# 写入端口
kubectl port-forward -n victoria-metrics svc/vminsert-victoria-metrics-k8s-stack 8480:8480 --address=0.0.0.0 &
# 查询端口
kubectl port-forward -n victoria-metrics svc/vmselect-victoria-metrics-k8s-stack 8481:8481 --address=0.0.0.0 &
# 修改n9e配置
docker-compose里自带了一个prometheus，所以n9e就默认了写入地址为9090端口，需要改掉
config.toml
- Url = "http://127.0.0.1:9090/api/v1/write"
+ Url = "http://127.0.0.1:8480/insert/0/prometheus/api/v1/write"
并且重启n9e容器

VictoriaMetrics 的 API 需要带完整路径
数据源URL
http://localhost:8481/select/0/prometheus
Remote Write URL
http://localhost:8480/insert/0/prometheus/api/v1/write

2.添加categraf采集器（可选，因为我们docker-compose里自带了已经）
curl -sSfL 'http://192.168.10.100:17000/api/n9e/agents/categraf/install.sh' | bash -s -- --server 'http://192.168.10.100:17000'

3.添加配置采集（http，探测我本地的一个服务 http://192.168.10.100:5010
curl -sSfL 'http://192.168.10.100:17000/api/n9e/agents/categraf/collect.sh' | bash -s -- --input 'http_response' --conf-b64 'IyBtYW5hZ2VkIGJ5IG5pZ2h0aW5nYWxlIGNvbGxlY3Qgd2l6YXJkIChpbnB1dC5odHRwX3Jlc3BvbnNlKQoKW1tpbnN0YW5jZXNdXQp0YXJnZXRzID0gWyJodHRwOi8vMTkyLjE2OC4xMC4xMDA6NTAxMCJdCmV4cGVjdF9yZXNwb25zZV9zdGF0dXNfY29kZXMgPSAiMjAwIgo='

4.查看数据查询-实时

配置n9e仪表盘(入门)

感觉和grafana比也差不多，而且也不算夜莺的核心，所以不详细展开了

配置告警规则（UI/API/prometheus导入）

为了进行这个测试，我用python手动起一个测试的端口python -m http.server 8080
然后添加一个配置采集curl -sSfL 'http://192.168.10.100:17000/api/n9e/agents/categraf/collect.sh' | sudo bash -s -- --input 'http_response' --conf-b64 'IyBtYW5hZ2VkIGJ5IG5pZ2h0aW5nYWxlIGNvbGxlY3Qgd2l6YXJkIChpbnB1dC5odHRwX3Jlc3BvbnNlKQoKW1tpbnN0YW5jZXNdXQp0YXJnZXRzID0gWyJodHRwOi8vMTkyLjE2OC4xMC4xMDA6ODA4MCJdCmV4cGVjdF9yZXNwb25zZV9zdGF0dXNfY29kZXMgPSAiMjAwIgo='

UI 手动创建

选择基础配置→选择数据源→选择告警条件（先做到这，通知以后再配）

导入 Prometheus 原生规则文件

API形式创建

操作 方法 路径
登录拿 token POST /api/n9e/auth/login
列出业务组 GET /api/n9e/busi-groups
列出某业务组规则 GET /api/n9e/busi-group/{group_id}/alert-rules
创建规则 POST /api/n9e/busi-group/{group_id}/alert-rules
更新规则 PUT /api/n9e/alert-rule/{rule_id}
删除规则 DELETE /api/n9e/alert-rule/{rule_id}

业务组是 id=1（Default Busi Group）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 第1步：拿 token（用 root / root.2020 换）
TOKEN=$(curl -s "http://192.168.10.100:17000/api/n9e/auth/login" \
  -X POST -H "Content-Type: application/json" \
  -d '{"username":"root","password":"root.2020"}' \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['dat']['access_token'])")

# 第2步：创建规则（== 200，服务健康就触发）
curl -s "http://192.168.10.100:17000/api/n9e/busi-group/1/alert-rules" \
  -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '[{
    "group_id": 1,
    "cate": "prometheus",
    "name": "测试-8080服务挂了才告警",
    "note": "生产姿势：服务异常才触发",
    "disabled": 0,
    "datasource_queries": [{"match_type": 0, "op": "in", "values": [2]}],
    "prom_eval_interval": 15,
    "prom_for_duration": 0,
    "rule_config": {
      "queries": [
        {"prom_ql": "http_response_response_code{target=\"http://192.168.10.100:8080\"} != 200", "severity": 1}
      ]
    }
  }]'

{"dat":{"测试-8080服务挂了才告警":""},"err":"","request_id":"b8061b15-ad17-4aa9-bef1-d484e29fa09b"}

配置告警通知

告警产生 → ①通知规则(notify-rule) → ②通知媒介(channel) → ③用户联系方式(contact) → ④送达

维度 Zabbix 夜莺
通知对象 固定：用户/用户组（配好媒体类型） 用户组 + 订阅规则（用户可自订阅）
通知媒介 内置多种，但每用户逐个配置媒体 20 种渠道，channel 集中管理
分发策略（核心差异） 相对固定，按 action 触发 显式的「通知规则」：可对事件做复杂路由
模板 Message 模板（宏变量） 更丰富的模板 + 事件 Pipeline 附加元信息
屏蔽/抑制 维护期、依赖关系 屏蔽规则 + 抑制(自抑制/跨规则) + 订阅
告警自愈 有（远程命令） 有（回调脚本），但更标准化
  • 创建媒介→创建通知规则
  • 通知规则绑定告警

精细化路由

仅了解，我感觉这个也不太难，夜莺的引导做的还是挺好的，网页上点点点就都有了

场景 路由逻辑
按级别 P1 严重 → 电话+飞书，P2 警告 → 飞书，P3 提醒 → 邮件
按业务组 数据库告警 → DBA组，网络告警 → 网络组，应用告警 → 开发组
按时间段 工作时间 → 飞书，非工作时间 → 电话（升级）
按标签 team=backend → 后端群，team=frontend → 前端群

告警治理

仅了解即可，升级和聚合是商业版功能（但其实也可以通过webhook的方式实现）

订阅本质上其实也是将告警规则与通知媒介进行绑定，但是视角是用户侧的

手段 作用 夜莺实现
屏蔽规则 按时间/标签静默告警（维护窗口、已知问题） 配置 mute 规则
抑制 同一个服务挂了，只发第一条，后续同类告警压住 通知规则里的 notify_repeat_step
订阅 用户自己订阅关心的告警，不关心的不发 subscribe 规则，按标签匹配
聚合 10 台机器同时告”磁盘满”，合并成一条发 事件管道 relabel + 聚合分组
升级 5 分钟未恢复，自动升级通知方式（飞书→电话） 通知规则里的 escalation

Helm chart部署

在摸清了夜莺核心的基础上，引申出来的内容，也是更多生产会用到的部署方式

参考文档：https://github.com/flashcatcloud/n9e-helm

这是官方推荐的helm git项目，不过官方其实并不推荐k8s部署的方式：

“不过，我们不建议您把夜莺部署到 Kubernetes 中，因为监控系统太过重要，如果 Kubernetes 集群出现问题，可能会导致监控系统无法正常工作。而此时您可能希望通过监控数据排查 Kubernetes 的问题，导致循环依赖。尤其是，其他团队此时想使用监控系统发现用不了，可能会来怼你。”

1
2
3
git clone https://github.com/flashcatcloud/n9e-helm.git
cd n9e-helm
helm install nightingale . -n n9e --create-namespace

原文作者：王盛

原文链接：https://akemi.zj.cn/2026/08/22/Nightingale-Deploy-And-Usage/

发表日期：August 22nd 2026, 1:50:00 pm

更新日期：August 22nd 2026, 1:51:26 pm

版权声明：本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可

📚 相关文章推荐

2026-06-16 自动清理镜像思路优化、amd/arm双镜像 #Kubernetes 2026-07-29 etcd更换磁盘 #Kubernetes 2026-07-28 HAMi GPU测试框架 #Kubernetes
CATALOG
  1. 1. 集中监控方案对比
  2. 2. 产品特点
  3. 3. Docker Compose部署
    1. 3.1. 添加数据源
    2. 3.2. 配置n9e仪表盘(入门)
    3. 3.3. 配置告警规则（UI/API/prometheus导入）
    4. 3.4. 配置告警通知
    5. 3.5. 精细化路由
    6. 3.6. 告警治理
  4. 4. Helm chart部署
Total : 355
2026
2025
2024
2023
web服务 自动化 Docker Kubernetes DaemonSet k8s Linux服务 前端 存储 Buildah 多架构 容器镜像 虚拟化 网络 Python 容器 Dify Prometheus Consul VictoriaMetrics Promxy 数据库 PVE EVE-NG EFK Elasticsearch ELK logstash filebeat elasticsearch kibana Fluentd Fluent Bit 数据清洗 安全 Kibana GeoIP etcd 运维 纳甲六爻 易经 六爻 六神 GPU虚拟化 HAMi Milvus Helm LangChain AI 占卜 DNS CoreDNS 数据备份 MoneyPrinter 夜莺 监控告警 容器技术 实战 PostgreSQL Patroni K8s 监控 Rsyslog 审计日志 Blackbox Exporter Meilisearch 博客优化 iflow OpenClaw iFlow 故障处理 容器运行时 测试