共计 5669 个字符，预计需要花费 15 分钟才能阅读完成。
国产监控之光 - 夜莺监控（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