Nightingale 【开源推荐】夜莺企业级监控解决方案( 二 ) _开源

可运维性增强：将 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 ，主要存储的内容包括：用户信息、团队信息、树节点信息、告警策略、监控大盘、屏蔽策略、采集策略、部分组件心跳信息等；

仍在进行中的工作

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

致谢和说明