Nightingale滴滴夜莺监控系统入门（一）--夜莺对比zabbix、Prom

夜莺介绍

系统架构3.x版本

夜莺是Open-Falcon的进阶版，由Open-falcon的主要成员经过滴滴的生产实践优化后的版本，至于Open-falcon是啥，各为看官可以移步Open-falcon官网查看。

其实每家公司多少都会有自己的监控系统，不管是Zabbix也好，还是Promethues，选型没有最好，只有最合适，所以入门一就给大家接个引子，介绍下夜莺的架构和一些产品对比，后续文章会深入介绍。

夜莺是天生分布式的监控告警一体的运维平台

下图是夜莺3.x版本的架构图，分别对应采集，传输，存储，索引，告警，监控，资产管理，任务，rdb模块：

#Agent：夜莺的采集客户端，部署在各个终端上；
#Transfer：夜莺的网关，用于接收agent采集的数据，分发到后端的tsdb存储上；
#TSDB：时序数据库，N9E是用rddtool来实现的数据存储，好处是指标文件会在指标创建的时候创建，文件大小在新建时就占住位了，不会随数据的增多而增大，方便运维，老旧数据会降维归档；
TSDB这里夜莺也支持其他存储后端，3.3.0版本支持了M3DB
#Index：索引模块，某台服务器的某条指标，就是一条索引；
#Judge：告警判断模块，在夜莺上配置的告警策略会由judge来处理，将事件写入redis里，用于给monapi部分告警消费
#Monapi：一部分是用于写入告警事件，一部分是用于前端的系统入口；
#Rdb：在2.x版本需要独立部署的Sender集合在了这里，目前支持邮件、短信、电话、和IM的通知，并且包含了一些系统权限控制的功能；
#Job：任务执行模块，可在服务器上批量执行任务脚本，且可以用来告警后的告警自愈；
#Ams：资产管理模块，目前功能还比较上，就是做了一个终端简单的管理；

为什么使用夜莺

其实大家和我一样，会在众多的监控系统里选型，不知道到底哪个与公司的业务场景更贴切，下面我说说我的建议：

• [全公有云]：如果公司全部服务器都已经上云，大部分都是一些互联网创业公司较多，建议直接就使用云平台提供的监控，所有整合云平台都已经做的很好，无论是监控、告警、还是自愈，都已经做的很完善，没有必要再自己组装一辆单车；
• [新老系统共存]：公有私有云都有的情况，且大部分都还是以私有云为主的话，基本都是容器应用就上Prom，毕竟这些是天生适配；非容器应用比较多的传统行业的这些老公司，直接就上夜莺吧，不用多考虑什么，毕竟这类公司是啥都有一些，交换机监控，容器监控，本地应用监控，虚拟平台监控，有啥还能比白Piao来的更爽，毕竟夜莺是从采集、存储、监控、告警判断、告警通知、告警自愈都开源出来了，换句话说就是：开箱即用，直接采集交换机/虚机/应用指标，出现异常直接通知到钉钉/企微/邮箱。

如何开箱即用

夜莺是Go开发的，所有组件编译后均是二进制文件，无须安装其他依赖，后端只需要上述九个夜莺模块的二级制包，加上mysql，redis，nginx三个组件，就可以轻松在公司上落地监控。

[n9e@n9e-01 n9e]# ls
control  n9e-agent  n9e-index  n9e-judge   n9e-rdb   n9e-tsdb   etc 
meta    n9e-ams    n9e-job    n9e-monapi  n9e-transfer  pub
#control是用来统一编译，统一启动停止进程的脚本 
#这里的pub是前端文件，直接配置nginx的webroot到这里就可以了

监控对比

夜莺对比Zabbix

夜莺对比Prometheus

导航: Nightingale滴滴夜莺监控系统入门（二）–单机部署夜莺
导航: Nightingale滴滴夜莺监控系统入门（三）–夜莺页面功能说明
导航: Nightingale滴滴夜莺监控系统入门（四）–聊聊夜莺的后端储存
导航: Nightingale滴滴夜莺监控系统入门（五）–采集功能