夜莺监控新版，中心端连不通的时序库也可以告警了

最新推荐文章于 2025-10-24 18:35:54 发布
原创 最新推荐文章于 2025-10-24 18:35:54 发布 · 1.1k 阅读 · 16 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#夜莺监控 #运维监控 #Nightingale #开源监控 #监控告警

以防读者不了解夜莺，开头先做个介绍：

夜莺监控，英文名字 Nightingale，是一款侧重告警的监控类开源项目。类似 Grafana 的数据源集成方式，夜莺也是对接多种既有的数据源，不过 Grafana 侧重在可视化，夜莺是侧重在告警引擎。比如把 Prometheus、VictoriaMetrics、ElasticSearch 等作为数据源接入夜莺，即可在夜莺里配置告警规则做指标、日志的告警。当然了，夜莺也不止做告警，还提供了 ad-hoc 查询、指标视图、仪表盘等可视化能力，不过在可视化方面没有 Grafana 道行深。配合 Categraf 采集器，夜莺可以做到一站式监控。其项目地址是：https://github.com/ccfos/nightingale

近期，夜莺监控项目发布了 v8.0.0-beta10 版本，虽然是 beta 版本，实际是稳定的，可以放心升级，只不过要配合市场工作会把正式版放到每年 7 月发布。这个版本最重要的变化，是支持在中心端无法连通的时序库的告警。

示意图

在这里插入图片描述

通常来讲，夜莺只需要部署中心端一个 n9e 进程即可，使用这个 n9e 进程去对接各个时序库、日志库，做查询、告警等。在网络环境比较好的情况下是 ok 的，但是有的时候，中心端无法直连边缘机房的时序库（可能是因为安全性、合规等各种因素），只能是边缘机房连中心。此时，要想在中心机房统一看数据是不行的，但是仍然可以在中心统一管理告警规则，对边缘机房的时序库做告警。这个版本就支持了这个场景。

老版本夜莺要处理边缘机房的场景，需要在「数据源」那里把边缘机房的时序库地址配置上，但是中心端连不上边缘机房，保存的时候会报错。新版本支持了仅保存不做连通性校验的能力，配合「时序库内网地址」的配置，就可以达成上图的效果了。

在这里插入图片描述

最终，n9e-edge 周期性调用 n9e 的接口同步告警规则，缓存在内存里（即便网络断了，还可以使用内存中缓存的规则），然后查询时序库（使用时序库的内网地址），做告警判定。在这个模式下，其实在夜莺的数据源页面那里，最上面 ① 的位置即便配置一个假地址都无所谓了，因为压根就不校验了。

其他更新

changelog 和新版下载地址：https://github.com/ccfos/nightingale/releases/tag/v8.0.0-beta.10，其他更新：

  • feat: 仪表盘新版数据源选择器
  • refactor: 仪表盘包含 “机器标识” 变量时禁止启用匿名访问
  • refactor: 仪表盘下线 “业务组标识” 变量
  • refactor: 告警规则默认执行频率改为 60 秒
  • refactor: 记录规则表单页提交按钮统一改名为 “保存”
  • refactor: 通知规则优化
    • 告警规则的通知规则选择器添加查看规则功能
    • 消息模板支持克隆
    • 消息模板右侧文档宽度支持调节
  • fix: 修复创建数据源后部分页面数据源类型未刷新问题
  • fix: 修复告警规则克隆时遇规则被其他修改无法保存问题
  • fix: 修复告警规则 Elasticsearch 源保存的字段路径错误问题
  • fix: 修复 Elasticsearch 日志查询 Lucene 模式的过滤条件的字段值中包含 and or 等字符时会被自动转换成大写问题
  • fix: 修复一些比较老的仪表盘导入后因为缺少 legend.placement 导致图例容器溢出问题
  • fix: 修复折线图提示信息没有过滤掉空值图例问题

欢迎大家下载试用。有问题提 issue 即可，研发人员会持续关注。

总结

本文介绍夜莺新版本的一个重要更新，支持在中心端无法连通的时序库的告警。这个版本的更新增强了夜莺的灵活性和可用性，尤其是在复杂网络环境下的应用场景。希望大家能在实际使用中体验到这个新功能的便利。

一张图详解开源监控夜莺（Nightingale）的架构
n9ecommunity的博客
07-22 2833
如果您对此开源项目感兴趣，可以 star 一下留备后用。
手把手教你搭建Nightingale夜莺监控系统
m0_66190021的博客
01-10 9035
夜莺监控
【架构】-- Nightingale：云原生监控告警平台的深度解析
最新发布
欢迎来到我的博客，一起探索代码里的世界！
10-24 753
Nightingale是一款专注于告警管理的开源云原生监控平台，由滴滴团队开发并捐赠给中国计算机学会。核心特性包括多数据源支持（Prometheus、ElasticSearch等）、专业告警管理（降噪、升级、自愈）、业务分组与权限管理。采用Go语言开发，支持Docker快速部署，特别适合企业级监控和边缘计算场景。与Grafana相比，更强调告警能力而非可视化。项目在GitHub上获得12.5k+星标，持续更新中，是云原生监控领域的专业解决方案。
从0搭建夜莺v6基础监控告警系统（一）：基础服务安装
小鲸鱼大梦想
09-18 1713
项目介绍架构介绍仪表盘黄埔营培训计划相关信息介绍Categraf 项目简介整个过程核心安装包都是采用二进制部署文件，适用于各种x86服务器操作系统，很轻便官方推送使用的时间序列数据库：VictoriaMetrics，相比之 Prometheus，性能较好，CPU、内存的占用较少，而且完全是兼容 Prometheus 的查询接口各服务和需要监控主机的节点都是需要配置时间同步服务的，这很重要采集器选择的是：Categraf；采用 All-in-one 的设计，更加方便管理。
夜莺监控系统
liuhuangjian的博客
12-22 1629
夜莺监控（ Nightingale ）是一款国产、开源云原生监控分析系统，采用 All-In-One 的设计，集数据采集、可视化、监控告警、数据分析于一体。于 2020 年 3 月 20 日，在 github 上发布 v1 版本，已累计迭代 60 多个版本。
Nightingale 夜莺监控系统 - 告警篇（3）
RAB
01-13 3881
Nightingale 夜莺监控系统 - 告警篇（3）
夜莺监控告警规则里的 “仅在本业务组生效” 具体是怎么个逻辑？
n9ecommunity的博客
08-13 418
对于某个告警规则（假设其归属业务组 A），其 promql 为 cpu_usage_idle < 5 告警，夜莺的告警引擎就会拿着这个 promql 去查时序库，比如查到 10 台机器的 cpu_usage_idle 数据都小于 5 ，于是，时序库返回 10 条数据，进而产生 10 条告警。但是，有的时候，promql 可能会写一些聚合函数，导致 promql 查询的结果中不包含 ident 标签，此时，夜莺就无能为力了，不知道时序库返回的这个数据属于哪个机器，也就无法根据机器的归属关系判断是否发告警了。
从0搭建夜莺v6基础监控告警系统（二）：采集数据、打通夜莺显示
小鲸鱼大梦想
09-19 2266
使用 categraf 采集器来进行数据采集，然后推数据给夜莺，夜莺转存到时序库，并且后续对这些数据做可视化、告警等。首次只需要打通时序数据库与夜莺v6的连接，后续需要监控的主机只需要安装采集器 Categraf 即可Categraf 项目简介官方操作手册被监控主机的采集器可以使用脚本统一安装，这样方便一点下阶段只需要打通一下企业微信监控报警就稍微完美，实现了基础数据的监控报警。
Kubernetes VM部署方案：VictoriaMetrics与Grafana/Nightingale监控告警系统的集成与配置
08-16
VictoriaMetrics作为一款高效的时序数据库，与Grafana及Nightingale监控告警系统集成后，可以实现对Kubernetes集群的深度监控和智能告警，保证系统的健康性和稳定性。 VictoriaMetrics是一个轻量级、高性能的时序...
夜莺监控系统说明
liuhuangjian的博客
12-22 1206
夜莺监控是一款开源云原生观测分析工具，采用 All-in-One 的设计理念，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力。夜莺于 2020 年 3 月 20 日，在 github 上发布 v1 版本，已累计迭代 100 多个版本。夜莺最初由滴滴开发和开源，并于 2022 年 5 月 11 日，捐赠予中国计算机学会开源发展委员会（CCF ODC），为 CCF ODC 成立后接受捐赠的第一个开源项目。
国产监控之光-夜莺监控（Nightingale）
god_86的专栏
04-15 3266
国产监控之光-夜莺监控（Nightingale）夜莺是什么？夜莺是一个服务端组件，类似 Grafana，可以对接不同的TSDB时序数据库作为数据源，支持的TSDB时序数据库如Prometheus、VictoriaMetrics、Thanos等等，只要数据进到这些库里了，夜莺就可以对数据源的数据进行分析、告警、可视化，以及后续的事件处理、告警自愈。当然，夜莺也有端口接收监控数据，可以跟开源社区常见的...
Nightingale | 夜莺监控
zs11234的博客
04-19 2091
​ Nightingale | 夜莺监控，一款先进的开源云原生监控分析系统，采用 All-In-One 的设计，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力。
Linux本地部署Nightingale夜莺监控并实现远程访问提高运维效率
热门推荐
优快云站内信: https://i.youkuaiyun.com/#/msg/chat/qyj19920704
05-13 1万+
夜莺监控是一款开源云原生观测分析工具，采用 All-in-One 的设计理念，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力。夜莺于 2020 年 3 月 20 日，在 github 上发布 v1 版本，已累计迭代 100 多个版本。本地部署后,为解决无法远程访问的难题,今天我们介绍如何实现让本地 nightingale 结合 cpolar 内网穿透工具实现 远程也可以访问,提高运维效率.
夜莺 Nightingale——服务器资源监控
qq_48721706的博客
03-14 3842
夜莺（Nightingale）作为一款开源云原生监控工具，最初由滴滴开发和开源，并于 2022 年 5 月 11 日，捐赠予中国计算机学会开源发展委员会（CCF ODC），为 CCF ODC 成立后接受捐赠的第一个开源项目。是一款开源的分布式监控系统，专注于服务器资源监控与告警管理。它整合了数据采集、存储、可视化、告警等功能，支持云原生环境，适合中小企业的运维团队。通过夜莺，用户可以构建从基础设施到业务层的全方位监控体系，并实现自动化告警响应，显著提升运维效率。
夜莺监控（ Nightingale ），看这一篇就够了。（介绍、部署、配置、优化、自定义）
西原一点红的博客
06-19 6934
夜莺监控（ Nightingale ），看这一篇就够了。（介绍、部署、配置、优化、自定义
Nightingale 夜莺监控系统 - 部署篇（1）
RAB
01-11 8467
Nightingale 夜莺监控系统 - 部署篇（1）
Nightingale夜莺服务监控
qq_44621891的博客
08-20 2316
滴滴夜莺服务部署文档Nightingale
Nightingale 夜莺监控系统 - 监控篇（2）
RAB
01-13 3541
Nightingale 夜莺监控系统 - 监控篇（2）
夜莺短信告警教程
n9ecommunity的博客
11-28 1341
本文讲解在夜莺监控中如何对接自己的短信通道，实现短信告警
使用大模型分析夜莺告警数据
03-25
<think>嗯，用户想了解如何使用大模型分析夜莺告警数据。首先，我需要明确夜莺是什么，可能是一个监控系统，用于收集告警数据。然后，大模型指的是像GPT、BERT这类的大型AI模型吧。接下来，我需要考虑用户可能的背景，可能是运维或数据分析人员，他们需要处理大量的告警信息，希望用AI来优化流程。 用户的需求可能包括降噪、分类、根因分析、预测和自动化处理。需要分步骤解释每个环节，同时给出具体的例子，比如如何用NLP分类告警，用时间序列预测故障。还要注意技术细节，比如数据处理、模型选型、结果评估这些步骤。 可能用户对具体实施有疑问，比如数据准备需要哪些步骤，模型训练要注意什么，怎么评估效果。需要确保回答结构清晰，逐步引导，同时保持语言通俗，避免太专业的术语。另外，用户可能关心实际应用场景，比如如何与现有系统整合，是否需要大量标注数据，这些都需要在回答中涉及。 最后，要提醒潜在挑战，比如数据质量、计算资源、模型解释性，以及持续优化的重要性。确保用户有一个全面的了解，既能知道优势，也明白需要注意的地方。这样回答应该能帮助用户系统地规划他们的分析流程。</think>以下分步骤介绍如何利用大模型分析夜莺（Nightingale）监控系统的告警数据： 1. **数据预处理阶段** - 结构化告警元数据：提取时间戳、告警类型、主机/IP、指标数值等字段，格式化为表格数据 $$ \text{Alert} = \{ t \in \mathbb{R}^+, \text{type} \in \{CPU, MEM, DISK...\}, \text{host}=ip, \text{value}=x \} $$ - 上下文增强：关联CMDB配置库、日志文件、调用链数据构建知识图谱 2. **特征工程构建** - 时序特征：计算告警频率$\frac{\Delta count}{\Delta t}$、持续时间$\int_{t_1}^{t_2} dt$ - 空间特征：统计同机房/集群的告警密度$\rho = \frac{n}{V_{\text{area}}}$ - 文本特征：用BERT将告警描述$T$编码为向量$\vec{v} \in \mathbb{R}^{768}$ 3. **大模型应用层** - **告警降噪** 使用Transformer计算相似度矩阵： $$ \text{Sim}_{ij} = \frac{\vec{v_i} \cdot \vec{v_j}}{||\vec{v_i}|| \cdot ||\vec{v_j}||} $$ 当$\text{Sim}_{ij} > 0.85$时合并相关告警 - **根因分析** 构建因果图模型： $$ P(\text{root\_cause}| \text{alerts}) = \prod_{i=1}^n P(\text{alert}_i | \text{pa}(alert_i)) $$ 通过GNN推断最大可能路径 - **预测性维护** 用时序大模型如Informer预测： $$ \hat{y}_{t+1} = f(y_{t-k},...,y_t) + \epsilon $$ 当预测值$\hat{y} > \text{threshold}$时触发预警告 4. **实施案例参考** ```python # 示例：告警分类prompt alerts = ["CPU使用率>90%持续5分钟", "磁盘inode不足"] prompt = f""" 请将以下告警分类并标注紧急程度(1-5): {alerts} 分类体系：[资源类|应用类|基础设施类] 响应建议：<自动生成> """ ``` 5. **效果评估指标** - 准确率：$\frac{TP+TN}{TP+TN+FP+FN} > 85\%$ - MTTA降低：$\frac{t_{\text{new}} - t_{\text{old}}}{t_{\text{old}}} \leq -40\%$ - 误报率：$\frac{FP}{N} < 5\%$ **挑战与建议** - 数据质量：需清洗$15\%$以上的脏数据 - 模型解释：使用LIME生成可解释报告 - 冷启动问题：建议积累至少$10^4$条标注数据 实际部署时推荐采用混合架构：大模型处理复杂场景（如日志语义分析），传统算法处理确定性规则（如阈值告警），通过决策树进行结果融合。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

夜莺开源监控

您的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值