Nightingale 正在参加 2020 年度 OSC 中国开源项目评选,请投票支持!
Nightingale 在 2020 年度 OSC 中国开源项目评选 中已获得 {{ projectVoteCount }} 票,请投票支持!
投票让它出道
已投票
Nightingale 获得 2020 年度 OSC 中国开源项目评选「最佳人气项目」 !
Nightingale 获得 2020 年度 OSC 中国开源项目评选「最佳人气项目」「最积极运营项目」 !
Nightingale 获得 2020 年度 OSC 中国开源项目评选「最积极运营项目」 !

软件简介

夜莺(Nightingale)是一个企业级监控解决方案。旨在满足云原生时代企业级的监控需求。Nightingale 在产品完成度、系统高可用、以及用户体验方面,达到了企业级的要求,可满足不同规模用户的场景,小到几台服务,大到数十万都可以完美支撑。兼顾云原生和裸金属,支持应用监控和系统监控,插件机制灵活,插件丰富完善,具有高度的灵活性和可扩展性。

Nightingale 在 Open-Falcon 的基础上,结合滴滴内部的最佳实践,在性能、可维护性、易用性方面做了大量的改进,作为集团统一的监控解决方案,支撑了滴滴内部数十亿监控指标,覆盖了从系统、容器、到应用等各层面的监控需求,周活跃用户数千。五年磨一剑,取之开源,回馈开源。

Nightingale 采用树状节点导航,我们称之为对象树。对象树本质上是一种对监控对象的分组管理机制,方便查找和查看监控对象,以及对监控对象设置监控策略等管理动作。 一棵典型的树可从上到下描述为组织架构关系、产品服务模块关系、机房和机器挂载关系,该导航树可根据用户需求自行灵活定制。

监控策略应用到某个节点后,该节点下的所有子节点挂载的所有的机器都会应用这个策略,任何一台机器触发相关阈值都会产生告警。

监控大盘的定制做了大幅易用性改进,支持了图表阈值,支持了图表分类,新增图表和排序管理都是可见即所得的方式,巡检大盘的定制从此不再是困难。

Nightingale 是在 Open-Falcon 的基础上衍化发展而来,Open-Falcon 作为国内使用最广泛的监控解决方案之一,为 Nightingale 的设计开发提供了大量的借鉴意义。

与 Open-Falcon 的不同点

  • 告警引擎重构:Open-Falcon 的告警策略,在监控数据推送上来的同时会触发策略判断,这种「推」的模式优势是策略的判断时效性非常高,但是不利于更高级的告警策略的支持和扩展,比如多条件的组合报警就很难支持。Nightingale 转为推拉结合模式,通过推模式保证大部分策略判断的效率,通过拉模式支持了与条件告警和nodata告警。
  • 引入了导航对象树:将 Open-Falcon 采用的扁平 HostGroup,转为 Nightingale 的导航对象树,对象树本质上是一种对监控对象的分组管理机制,方便查找和查看监控对象,以及对监控对象设置监控策略等管理动作。 同时在 Nightingale 中,去除了告警模板的概念,告警策略直接与树节点绑定,简化设计,大幅提升灵活度和易用性。
  • 索引模块升级换代:Open-Falcon 使用 MySQL 存储 metrics 的索引数据,在扩展性和灵活性上存在瓶颈。Nightingale 根据监控需求,设计开发了全新的内存索引模块 index,查询方式更多样,查询效率更高,避免了原来 MySQL 索引数据达到亿级别时面临的维护优化工作。
  • 时序数据库优化:在 Open-Falcon 存储模块 Graph 的基础上,引入 Facebook 的 Gorilla 压缩方案,近期几个小时的数据采用内存存储,大幅提升数据查询效率,长期数据仍然使用 rrdtool 数据格式存储在硬盘上。同时进一步完善了时序数据库的性能和稳定性。
  • 告警引擎高可用改进:告警引擎 judge 模块通过心跳机制做到了故障自动摘除,再也不用担心单个 judge 宕机导致部分策略失效,需要人工介入的问题,index 模块也是采用类似方式保证可用性。
  • 原生内置日志监控功能:Nightingale 客户端原生内置了日志匹配和指标抽取能力,在 web 控制台页面上支持了日志匹配规则的配置,同时也支持读取目标机器特定目录下的配置文件的方式,让业务指标监控更为易用。
  • 可运维性增强:将 portal (falcon-plus 中的 api)、uic、dashboard、hbs、alarm 合并为一个模块:monapi,简化了系统整体部署难度,原来的部分模块间调用变成进程内方法调用,性能更高。
  • 配置文件中心化:配置文件做了易用性改造,抽取数据库通用配置到 mysql.yml,抽取端口实例地址等关联配置到 address.yml,大批配置在代码里给了默认值,使得配置文件更清晰,易于维护。

与 Open-Falcon 的相同点

  • 数据模型没有变化,仍然是 metric、endpoint、tags 的组织方式,agent 基本是可以复用的,Nightingale 中的 agent 叫 collector,融合了原来 Open-Falcon 的 agent 和 falcon-log-agent 的逻辑,各种监控插件也都是可以复用的。
  • 数据流向和整体处理逻辑是类似的,仍然使用灵活的推模型,分为数据存储和告警判断两条链路。

Nightingale 架构 

  • collector即agent,可以采集机器常见指标,原生支持日志监控,支持插件机制,支持业务通过接口直接上报数据;
  • transfer提供rpc接口接收collector上报的数据,然后通过一致性哈希,将数据转发给多台tsdb和多台judge;
  • tsdb即open-falcon中的graph组件,用于存储历史数据,支持配置为双写模式提升系统容灾能力,tsdb会把监控数据转发一份给index建索引;
  • index是内存索引模块,替换原来的mysql方案,在内存里构建索引,便于后续数据检索,在检索的灵活性和检索性能方面大幅提升;
  • judge是告警引擎,从monapi(portal)同步监控策略,然后对接收到的数据做告警判断,如满足阈值,则生成告警事件推送到redis队列;
  • monapi(alarm)从redis队列中读取judge生成的事件,进行二次处理,补充一些元信息,生成告警消息,重新推送回redis队列;
  • 各发送组件,比如mail-sender、sms-sender等,从redis读取告警消息,发送告警,抽象出各类sender是为了后续定制方便;
  • monapi集成了原来多个模块的功能,提供接口给js调用,api前缀为/api/portal,数据查询走transfer,去除了 open-falcon 中原来的query组件,api前缀为/api/transfer,索引查询的api前缀/api/index,于是,在前端统一搭建nginx,即可通过不同location将请求转发到不同后端;
  • 数据库仍然使用MySQL,主要存储的内容包括:用户信息、团队信息、树节点信息、告警策略、监控大盘、屏蔽策略、采集策略、部分组件心跳信息等;

仍在进行中的工作 

  1. 提供监控指标聚合组件,现在的架构可以解决机器级、模块级的监控,但是集群维度的监控指标,是需要聚合整个集群的所有模块、机器的指标,做一些加和、求平均之类的操作,相关聚合组件,我们在紧锣密鼓的开源过程中;
  2. 与k8s无缝集成的工作,也在进行之中;
  3. 完善更多监控插件,之前Open-Falcon社区里的很多插件都是可以直接用的,我们会尽量补充社区没有的插件,并对社区已有的插件,进行二次整理和维护,让Nightingale周边更完善;

联系我们 

致谢和说明

  • Open-Falcon 是小米运维团队开源的企业级监控解决方案,在国内广泛使用。
  • Nightingale 采用 Apache-2.0 开源协议,Copyright © 滴滴 2020。
展开阅读全文

代码

的 Gitee 指数为
超过 的项目

评论 (14)

加载中
没有考虑过直接客户端自动派发安装collector吗,手动安装好麻烦的一说
2020/06/30 22:14
回复
举报
这个能用在centos6.9上么?
2020/06/14 19:11
回复
举报
应该可以,GO写的系统都是通用的
2020/06/14 19:20
回复
举报
这个插件机制是和falcon-plus 一样的么?需要用git去控制插件?
2020/05/24 13:16
回复
举报
夜莺监控软件作者
不是,这个是需要手工分发的,然后在页面上配置不同的服务树节点执行不同的插件,不同的插件可能使用不同的参数
2020/05/25 23:30
回复
举报
夜莺监控软件作者
#Nightingale# 版本帝来了,2.2.1发布,优化上报频率大于告警频率的极端情况
2020/05/22 08:24
回复
举报
滴滴开源的?
2020/05/21 23:58
回复
举报
你们这个网站首页的中文是骗鬼呢?
2020/05/21 12:44
回复
举报
夜莺监控软件作者
哈哈,已支持中文
2020/05/21 23:17
回复
举报
2020/05/22 18:36
回复
举报
滴滴云
2020/03/27 21:12
回复
举报
您好,请问一个服务(JVM)装在一台机器上能充分压榨机器的性能吗?还是需要装多个服务?
2020/03/27 17:47
回复
举报
夜莺监控软件作者
机器性能包含很多方面,CPU、内存、硬盘、IO、网络,通常是CPU密集型的和IO密集型的服务混部来提升机器利用率
2020/05/21 23:18
回复
举报
夜夜 嘤嘤嘤。。。
2020/03/26 09:17
回复
举报
2020/03/26 08:49
回复
举报
更多评论
发表于运维专区
2020/12/10 13:08

滴滴夜莺运维平台发布 3.3.1 版本

最大的功能点是后端存储支持了M3DB,M3是uber开源的一款时序数据库,在uber内部号称处理了66亿监控指标,扩缩容非常方便、容灾也做的很好,跟夜莺默认使用的rrd版本相比,对硬盘IO的要求更小,但是存储的是原始数据,会占用更多硬盘空间,非常值得一试。其他升级点如下: 前端 fix: 修复IE11兼容问题,目前支持 IE >= 11,Chrome >= 70 fix(mon): 修复屏蔽策略无法选择屏蔽节点问题 fix(mon): 修复某些日志采集修改会导致名称被...

0
9
2020/10/08 20:43

滴滴夜莺发布 v3 版本,从运维监控演化成了运维平台

Nightingale 从 3 月份开源到现在,过去了半年多点时间,收获了接近 2000 个 github star,300 多个 issue,感谢各位业界同仁的关注和社区参与。 经过慎重考虑,我们决定把商业版本中的更多功能拿出来开源,组成一个轻量级运维平台,这块业界的开源解决方案较少,我们希望贡献一份自己的力量。除了已有的监控告警的能力,又引入了如下功能模块: 用户资源中心:提供完备的用户信息管理、组织结构管理、组织权限管理、组织资源管...

6
49
发表于DevOps专区
2020/05/30 22:00

运维监控系统 Nightingale 2.4.1 发布,支持对接 Grafana

Nightingale是滴滴开源的一款运维监控系统,是Open-Falcon的下一代,融入了滴滴的生产实践经验,适用于大规模监控场景。产品完善度很高,集采集、传输、存储、查询、告警、事件处理、告警自愈于一体,是一款开箱即用的运维监控解决方案。 2.4.1版本更新内容: 支持了Grafana作为绘图展示工具,可以在Grafana里配置Nightingale作为数据源。Grafana针对Nightingale的数据源插件:https://github.com/n9e/grafana-n9e-datasource 增...

2
26
发表于运维专区
2020/05/21 08:41

Nightingale 2.2.0 发布,滴滴开源运维监控系统

Nightingale从正式发布到今天5.21号,差不多两个月左右的时间,社区用户参与热情很高,发布了多个版本,最新版本已经到了2.2.0,这里罗列一下相关改进,供大家参考,欢迎大家参与到Nightingale的建设中来,我们希望与社区一起,把监控这个事情,做到极致。 进程采集不但支持采集进程数目,也支持采集进程cpu和mem占用 页面上支持了plugin的配置,可以给plugin脚本传参,通过配置也可以指定只启用部分节点下的plugin 服务端接收到...

10
24
没有更多内容
加载失败,请刷新页面
点击加载更多
加载中
下一页
发表于运维专区
2020/12/26 22:59

[nightingale]夜莺中的交换机监控

## nightingale [nightingale](https://github.com/didi/nightingale) - 夜莺,是滴滴开源的运维监控系统,他传承于 [Open-Falcon](https://github.com/open-falcon/falcon-plus) 但提供更多了运维能力,例如服务树结构等。 在网络监控上,原 Open-Falcon 体系内的 [swcollector](http://github.com/gaochao1/swcollector) 同样能够支持夜莺。同时基于夜莺的服务树架构,他还能提供更好的自动化支持。 ## swcollector swcollect...

0
0
发表了博客
2020/06/06 10:56

didi出品 夜莺

http://n9e.didiyun.com/docs/install/compile/

0
0
2020/03/23 08:35

「开源发布」 滴滴内部监控系统 Nightingale 开源啦

本文字数:2464 字 精读时间:8 分钟 也可在 4 分钟内完成速读 夜莺(Nightingale)是滴滴基础平台联合滴滴云研发和开源的企业级监控解决方案。旨在满足云原生时代企业级的监控需求。Nightingale 在产品完成度、系统高可用、以及用户体验方面,达到了企业级的要求,可满足不同规模用户的场景,小到几台机器,大到数十万都可以完美支撑。兼顾云原生和裸金属,支持应用监控和系统监控,插件机制灵活,插件丰富完善,具有高度的灵活...

0
0
发表了博客
2020/03/21 14:06

滴滴开源夜莺Nightingale:企业级监控解决方案

导读:滴滴开源又双叒发布新开源项目啦——夜莺(Nightingale)是滴滴基础平台联合滴滴云研发和开源的企业级监控解决方案。旨在满足云原生时代企业级的监控需求。一起来了解项目详情吧。 夜莺(Nightingale)是滴滴基础平台联合滴滴云研发和开源的企业级监控解决方案。旨在满足云原生时代企业级的监控需求。Nightingale 在产品完成度、系统高可用、以及用户体验方面,达到了企业级的要求,可满足不同规模用户的场景,小到几台机...

0
0
发表了博客
2020/05/15 17:24

搜索相关性算法在 DiDi Food 中的探索

导读:今天给大家分享的主题是搜索匹配问题在 DiDi Food 中的一些探索与应用。本文首先介绍了搜索相关性的一些背景,之后介绍了业界常见的三种匹配模型,以及在DiDi Food业务中的模型效果对比。 匹配模型包括:1. 基于表征的深度匹配模型;2. 基于交互的深度匹配模型;3. 同时基于表征与交互的深度模型。文章最后会介绍目前搜索匹配算法在 DiDi Food 业务中的一些效果。 1. 搜索相关性 搜索相关性模型本质上是一个匹配的过程,即...

0
0
发表了博客
2020/08/11 21:41

DiDi Food中的智能补贴实战漫谈

桔妹导读:随着因果推断理论体系(Casual Inference)的建立和补充,智能营销/智能补贴近年来在业界有了越来越多的落地成果。滴滴的国际化外卖团队DiDi Food自2020年上半年起开始推进了智能补贴算法在业务场景内的实验和落地,离线和线上效果均取得了一定进展。本文将主要介绍DiDi Food对这个方向上一些探索和实践经验。 0. 目录 本文内容较长,主要会包括以下几点: 1. 差异化定价的经济学原理 2. 差异化定价在DiDi Food中的抓...

0
0
发表于云计算专区
2020/05/22 18:23

搜索相关性算法在 DiDi Food 中的搜索

![](https://oscimg.oschina.net/oscnet/up-0d5a8b1c30471b67c957a02f1649f407fc1.png) >导读:今天给大家分享的主题是搜索匹配问题在 DiDi Food 中的一些探索与应用。本文首先介绍了搜索相关性的一些背景,之后介绍了业界常见的三种匹配模型,以及在DiDi Food业务中的模型效果对比。 匹配模型包括:1. 基于表征的深度匹配模型;2. 基于交互的深度匹配模型;3. 同时基于表征与交互的深度模型。文章最后会介绍目前搜索匹配算法在...

0
0
发表于运维专区
2020/05/31 18:21

CentOS7下部署滴滴云开源运维监控系统-Nightingale

夜莺(Nightingale)简介 Nightingale是滴滴基础平台联合滴滴云研发和开源的企业级监控解决方案。旨在满足云原生时代企业级的监控需求。 Nightingale在产品完成度、系统高可用、以及用户体验方面,达到了企业级的要求,可满足不同规模用户的场景,小到几台机器,大到数十万都可以完美支撑。兼顾云原生和裸金属,支持应用监控和系统监控,插件机制灵活,插件丰富完善,具有高度的灵活性和可扩展性。 Nightingale是一款分布式高性...

0
0
没有更多内容
加载失败,请刷新页面
点击加载更多
加载中
下一页
发表于运维专区
2020/06/30 11:26

配置 nodata 告警策略后,重启应用系统就会先报 nodata 的告警

配置了“监控agent失联 (proc.agent.alive)”的 nodata 告警策略,统计周期是 180 秒(上报周期 60 秒),关闭应用系统(./control stop all),等个 10 秒后,再重启应用系统(./control start all),发现都产生了“监控agent失联”的告警,然后很快就又产生了“监控agent失联”的恢复记录。 如果是通过重启命令(./control restart all),则有些会产生“监控agent失联”的告警,有些不会。...

2
0
发表于DevOps专区
2020/05/30 12:41

推送数据后,transfer的ui接口查询不到数据

tsdb日志ERROR.log的报错信息 ERROR rrdtool/sync_disk.go:235 flush ad7c5ed20a9675381d00c5f1a642d90a data to rrd err:Unknown error ERROR rrdtool/sync_disk.go:235 flush 8f869baf48ac377a0b8a7a2408b9b04a data to rrd err:Unknown error...

3
0
发表于DevOps专区
2020/05/30 17:41

我想用夜莺监控 ubuntu 的业务数据,但是不知道怎么将collector 部署在ubuntu 中

先说以下我的情况:对linux 的操作大概了解了不到一个星期,对golang 应该说没有经验,我本人是学C# 的,公司最近要对服务器进行全面监控所以想了解夜莺的用法。目前:我已经在Centos7.8 中采用编译源码的方式把夜莺的启动了,下一步就是想把 采集器collector 部署到ubuntu 中。我参考了官网资料安装教程,都是在centos 中暗转的教程,于是我想都是liunx ,rpm包的安装应该也是一样的但是一顿操作后发现各种缺包,下面将贴图展示...

1
0
发表于DevOps专区
2020/05/29 15:35

安装完成后在web看不到监控主机,judge存在报错,请问是什么问题呢。

centos7.2源码编译安装,时间也已校准,进入web看不到监控的机器,所有组件启动正常,judge日志有报错。

2
0
发表于运维专区
2020/05/27 11:48

日志采集和collector本身采集上报的时间戳不一样。日志采集的时间该如何解决

目前机器时间是0时区。 collector本身指标上报会转上海时区,但是日志的时间只是日志里命中的时间。入的库里是历史的时间,无法正常被页面加载和配置告警使用。请问怎么去规避这个问题。

9
0
发表于DevOps专区
2020/05/29 14:01

树节点修改后,未回复报警、所有历史告警记录找不到了

2020-05-26 拉取master的最新代码,树节点修改为中文后,发现未回复报警、所有历史告警记录找不到了,分析后,发现节点名称修改后,event、event_cur 表的 node_path 没有根据 nid 同步修改,能否考虑优化下呢?目前是自己写 SQL 去更新。

4
0
发表于运维专区
2020/05/27 08:35

夜莺如何配置微信告警,钉钉告警

使用微信和钉钉告警的时候,im应该如何配置,微信和钉钉只能二选一吗?

1
0
发表于DevOps专区
2020/05/25 16:16

Nightingale配置钉钉

测试发送钉钉消息时一直显示token为创建 我是直接在web页面上添加的im号,在配置文件中没有修改任何东西

4
0
发表于DevOps专区
2020/05/22 10:28

在Nightingale中配置了邮件和钉钉得不到报警信息

在Nightingale中配置邮件报警后,测试能够通过,且能正常发送短信,但是在Nightingale根据报警策略无法获取到报警的邮件信息。 钉钉上根本测试都不能做,也是收不到提示

5
0
发表了问答
2020/05/11 10:27

夜莺相关问题排查思路

1、相关进程是否都启动了 服务端进程有5个,transfer、tsdb、index、judge、monapi,客户端进程一个collector 2、相关进程是否有可疑日志 日志在二进制所在目录的logs下,分了多个目录,要做相关排查先 3、系统时间是否校准了 监控系统是时序数据处理的系统,对系统时间的校准要求比较苛刻,服务端、客户端的时间需要一致,相差不要超过1s 4、检查防火墙、安全组规则 比如超时了,访问不通了,先通过telnet确认一下,很可能是网...

1
0
没有更多内容
加载失败,请刷新页面
点击加载更多
加载中
下一页
14 评论
425 收藏
分享
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部