关于监控工具:云原生-•-监控国产监控之光夜莺监控Nightingale

国产监控之光-夜莺监控（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、代码在这里： https://github.com/ccfos/nightingale 。如果有 docker 和 docker-compose 环境，咱们就能够一键装置了：
git clone https://github.com/ccfos/nightingale.gitcd nightingale/dockerdocker-compose up -d
2、装置实现之后，查看组件部署运行状况：
[root@VM-4-14-centos docker]# docker-compose ps   Name                 Command               State                         Ports                       --------------------------------------------------------------------------------------------------------categraf     /entrypoint.sh                   Up                                                        ibex         sh -c /wait && /app/ibex s ...   Up      0.0.0.0:10090->10090/tcp, 0.0.0.0:20090->20090/tcpmysql        docker-entrypoint.sh mysqld      Up      0.0.0.0:3406->3306/tcp, 33060/tcp                 n9e          sh -c /wait && /app/n9e          Up      0.0.0.0:17000->17000/tcp                          prometheus   /bin/prometheus --config.f ...   Up      0.0.0.0:9090->9090/tcp                            redis        docker-entrypoint.sh redis ...   Up      0.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时序库是割裂的，全局聚合汇总数据暂未发现如何实现：

更多云原生监控运维，请关注微信公众号：Reactor2020