国产监控之光-夜莺监控（Nightingale）
夜莺是什么？
夜莺是一个服务端组件，相似 Grafana，能够对接不同的TSDB时序数据库作为数据源，支撑的TSDB时序数据库如Prometheus、VictoriaMetrics、Thanos等等，只要数据进到这些库里了，夜莺就能够对数据源的数据进行分析、告警、可视化，以及后续的事情处理、告警自愈。
当然，夜莺也有端口接纳监控数据，能够跟开源社区常见的各种监控收集器打通，比方Telegraf、Categraf、Grafana-agent、Datadog-agent、Prometheus生态的各类Exporter等等。这些agent收集了数据推给夜莺，夜莺适配了这些agent的数据传输协议，所以能够接纳这些agent上报的监控数据，转存到后端对接的数据源，之后就能够对这些数据做告警分析、可视化。
夜莺布置架构
依据出产网络环境，夜莺能够完成**「中心会聚式布置计划」和「边际基层式稠浊布置计划」**。
关于网络结构简略或小规模网络场景下，选用**「中心会聚式布置计划」**施行比较简略，能够n9e中心组件选用单机或集群方法建立，集群形式下前端需架起Nginx作为软负载或F5进行硬件设备负载，同时依赖MySQL和Redis中间件存储根底的元数据、用户信息等，不存在大数据量问题，因而，不必太考虑功用瓶颈。
Categraf是夜莺团队开发保护的监控收集侧中心组件，相似Telegraf、Grafana-Agent、Datadog-Agent，期望对一切常见监控方针供给监控数据收集才能，选用All-in-one的规划，不光支撑方针收集，也期望支撑日志和调用链路的数据收集。Categraf收集器收集了数据推送给夜莺，然后转存到后端数据源，如TSDB、ElasticSearch等。
❝
留意：Categraf不属于夜莺监控体系组件，夜莺定位是服务端组件，不侧重监控数据收集侧。
❞
中心会聚式布置计划
一切机房网络域下监控数据收集器都直接推数据给n9e，这个架构最为简略，保护成本最低。当然，条件是**「要求机房网络域结构简略、规模不大场景，即不太重视跨网络域拜访安全问题和大规模跨网络域传输数据网络带宽约束等」**。
如果非上述场景，则要运用下面的**「边际下沉式稠浊布置计划：」**
边际下沉式稠浊布置计划
这个图尝试解释 3 种不同的景象，比方 A 机房和中心网络链路很好，Categraf 能够直接报告数据给中心n9e模块，另一个机房网络链路不好，就需求把时序库下沉布置，时序库下沉了，对应的告警引擎和转发网关也都要跟从下沉，这样数据不会跨机房传输，比较稳定。可是心跳还是需求往中心心跳，要不然在方针列表里看不到机器的 CPU、内存运用率。还有的时分，或许是接入的一个已有的Prometheus，数据收集没有走Categraf，那此时只需求把Prometheus作为数据源接入夜莺即可，能够在夜莺里看图、配告警规则，可是便是在方针列表里看不到，也不能运用告警自愈的功用，问题也不大，中心功用都不受影响。
「边际下沉式稠浊布置计划」中涉及到两个中心组件：「n9e-pushgw组件」和「n9e-alert组件」。
**「n9e-pushgw组件」**供给相似于remote_write和remote_read功用，categraf收集器将数据经过remote_write推送给n9e-pushgw组件，然后转存到tsdb时序数据，n9e服务端查询检索数据时经过remote_read讲求转发到对应机房下的n9e-pushgw组件。n9e-alert组件供给根据tsdb时序库中的方针数据告警功用。
一键布置
「笔者已经在公有云上建立了一套暂时环境，能够线登录体会下：」
http://124.222.45.207:17000/login
账号：root/root.2020
下面介绍下运用docker-compose快速一键布置。
1、代码在这儿： github.com/ccfos/night… 。如果有 docker 和 docker-compose 环境，咱们就能够一键安装了：
gitclonehttps://github.com/ccfos/nightingale.git
cdnightingale/docker
docker-composeup-d
2、安装完成之后，检查组件布置运行状况：
[root@VM-4-14-centosdocker]#docker-composeps
NameCommandStatePorts
--------------------------------------------------------------------------------------------------------
categraf/entrypoint.shUp
ibexsh-c/wait&&/app/ibexs...Up0.0.0.0:10090->10090/tcp,0.0.0.0:20090->20090/tcp
mysqldocker-entrypoint.shmysqldUp0.0.0.0:3406->3306/tcp,33060/tcp
n9esh-c/wait&&/app/n9eUp0.0.0.0:17000->17000/tcp
prometheus/bin/prometheus--config.f...Up0.0.0.0:9090->9090/tcp
redisdocker-entrypoint.shredis...Up0.0.0.0:6379->6379/tcp
❝
留意，docker中不能有同名组件，比方我在安装过程中呈现：ERROR: for prometheus Cannot create container for service prometheus: Conflict. The container name “/prometheus” is already in use by container xxx. You have to remove (or rename) that container to be able to reuse that name。
❞
3、浏览器拜访n9e组件露出的17000端口，即可看到页面，默许账号密码如下：
username="root"
password="root.2020"
4、拜访prometheus组件露出的9090端口，能够翻开Prometheus WebUI：
从Targets界面显现Prometheus接入2个方针收集点，从端口能够辨认一个抓取n9e组件监控方针，另一个便是抓取prometheus组件本身方针。
基本运用
1、翻开【根底设施】/【机器列表】菜单，该界面供给Categraf收集点机器办理，在【未归组方针】下就能够看到方才布置的一个Categraf收集点：
❝
Categraf 是一个监控收集 Agent，相似 Telegraf、Grafana-Agent、Datadog-Agent，期望对一切常见监控方针供给监控数据收集才能，选用 All-in-one 的规划，不光支撑方针收集，也期望支撑日志和调用链路的数据收集。
❞
Categraf经过Heartbeat心跳服务将节点的状况、内存、CPU、时刻偏移、核数、OS等信息上报给n9e组件，进而Web上方便检查。
方便机器列表办理，能够进行分组，如下图咱们对机器依照机房地域划分，并创立chengdu事务组：
❝
这儿我翻开【作为标签运用】开关，该事务组下机器收集数据推送TSDB库时会自动打上busigroup=[英文标识]标签，方便根据该维度进行数据聚合计算。
❞
【团队】这栏用于权限操控，比方操控哪个团队成员能够对该事务组下机用具有读写权限，或许只读权限等。【人员办理】/【团队办理】页面能够创立、办理团队。
选中机器，点击【批量操作】下【修改事务组】，将机器移入到新创立的事务组里：
还能够选中机器，挑选【批量操作】/【绑定标签】，手艺为机器打上指定标签，则相关机器方针存储到TSDB时序数据库时会带上这些标签：
2、装备数据源
翻开【体系装备】/【数据源】菜单，进入数据源办理界面，挑选增加Prometheus数据源：
❝
我这儿选用docker compose一键布置，所以这儿url能够填写http://prometheus:9090。
❞
2、增加好数据源，翻开【时序方针】/【即时查询】菜单：
这个查询基本相似于Prometheus WebUI查询页面，相关数据源，输入PromQL即可查询方针数据，点击Graph还能够展现对应的区间趋势图。
方针cpu_usage_active{busigroup="chengdu",cpu="cpu-total",env="test",ident="categraf01",source="categraf"}标签说明：
1、busigroup="chengdu"：这个便是方才创立事务组时翻开【作为标签运用】开关装备的标签；
2、cpu="cpu-total"：组件露出方针本身事务标签；
3、env="test"：方才在机器上手艺绑定标签装备；
4、ident="categraf01"：机器标识，即Categraf组件所属主机名；
当然也能够在Categraf组件config.toml装备文件中指定hostname：
5、source=”categraf”：Categraf组件config.toml装备文件中global.labels装备信息：
[global.labels]
source="categraf"
#region="shanghai"
#env="localhost"
总结
夜莺监控体系布置架构简略，关于小规模监控场景下快速建立一套监控体系来说是比较值得推荐的方法，全体体会也比较友好。但关于大规模监控场景，或许还不是那么的足够完善。
Categraf收集组件
1、categraf收集器选用推送形式(push)，而不是Prometheus的拉(pull)形式，push形式导致收集器存在状况，即收集器要知道自己要推送给哪个服务后端的装备，少量categraf收集器来说无所谓，可是一旦成千上万收集点，乃至几百收集点，保护成本都是比较高的，特别是后端地址发生变更等。
2、push形式还存在接入权限问题，由于往往服务后端和收集器保护是两拨人，服务后端是运维人员，而收集器是项目组人员保护，比较难于操控接入，或许单个项目组大量接入收集点形成服务端压力过大奔溃，从而影响整个体系运行稳定。
3、push形式还存在推送频率问题，categraf组件能够装备推送频率，可是只能在收集器端操控，不同项目组运维人员或许装备不同推送频率，难以从大局操控，或许这么个场景：前期收集点少，数据量不大，推送频率5s，可是后边接入的越来越多，存储不够用，需求下调推送频率15s，没有一致修改调整方法。
布置架构优化
边际下沉式稠浊布置计划
**「边际下沉式稠浊布置计划」**中categraf收集器还需求和夜莺后端n9e组件进行heartbeat心跳交互，这儿或许会存在问题，关于大规模网络下，categraf会布置成千上万个实例，服务后端n9e组件保护这些心跳功用：
1、服务后端n9e组件保护这些心跳对服务功用和网络IO都存在损耗问题，一个心跳交互影响微乎其微，可是放到成千上万个节点心跳这个影响就会扩展；
2、**「边际下沉式稠浊布置计划」**往往便是由于网络环境杂乱，为了heartbeat需求打通服务后端和那么多categraf组件网络连通性，或许影响是致命的；
3、n9e服务后端和categraf组件心跳传递数据主要：在线状况、CPU%、内存、CPU核数、CPU架构等，这个在线状况更多的是反映后端和categraf组件连通性，我觉得在线状况应该反映categraf有没有正常收集方针数据并推送到tsdb库或许更加合理，检查categraf收集组件前史一段区间内的在线状况、CPU、内存等，后端还需求考虑存储这些方针数据；
所以，categraf心跳交互这个逻辑应该移除，将心跳数据以方针方法露出，并增加一个up方针反映在线状况，在categraf向n9e-pushgw组件推送数据时一并存储到tsdb时序库中。n9e后端在查询categraf当前状况或某前史区间在线状况时，都能够经过n9e-pushgw从tsdb时序库中拉取展现。
比方中心网络和边际下沉网络或许有一段时刻网络断开，这种只会影响后端过来的查询不能履行，categraf收集组件本身依然能够正常收集数据并推送到tsdb时序库，关于categraf收集器组件来说依然是正常在线的，由于网络域内部是正常的，待网络康复后，n9e服务端就能够经过n9e-pushgw组件从tsdb时序库中查询出这段时刻categraf是否正常收集、CPU运用率等等状况。
**「边际下沉式稠浊布置计划」**不同网络域下TSDB时序库是分裂的，大局聚合汇总数据暂未发现如何完成：
