这里有很全的监控组件，你适合哪一款？

监控是分布式系统的必备组件，能够起到提前预警、问题排查、评估决策等功效，乃行走江湖、居家必备之良品。

一、监控系统功能划分

一个宿主机cpu的报警叫做监控;一个业务日志的报错叫做监控;一个APM条件的触发，也叫做监控。分布式系统错综复杂，随便做个统计指标的集合，也属于监控的范畴。

怎样做到通用化，理清其中的关系，是需要花点功夫的，否则揉成一团，就不好拆了。

我习惯性从以下两种类型对其进行划分，真正实施起来，系统还是按照数据象限分比较合理：

• 数据象限：从数据类型划分，大体可分为：日志(logs)、监控(metrics)、调用链(tracing)。
• 功能象限：从业务角度划分，可分为：基础监控、中间件监控、业务监控

不管什么样的监控系统，又涉及以下几个模块过程：

• 数据收集：如何在广度和效率上进行数据归并。
• 数据加工：数据的整理、传输和存储。
• 特称提取：大数据计算，中间结果生成存储。
• 数据展示：高颜值、多功能显示。

其中，特征提取只有数据量达到一定程度才会开启，因为它的开发和运维成本一般小公司是不会玩的。

二、典型实现

不同的监控模块，侧重于不同领域，有着不同的职责。我个人是倾向于 独立设计 的，但需要做一定程度的集成，主要还是使用方式上的集成和优化。

我将从几个典型解决方案说起，来说一下为什么要分开设计，而不是揉成一团。

1、系统监控

系统监控用来收集宿主机的监控状况(网络、内存、CPU、磁盘、内核等)，包括大部分数据库和中间件的敏感指标。这些metric的典型特点是结构固定、有限指标项，使用时序数据库进行存储是最合适的。

指标收集方面，支持多样化的组件将被优先下使用。比如telegraf，支持所有的系统指标收集和大部分中间件和DB的指标收集。

注：在这里特别推荐一下其中的jolokia2组件，可以很容易的实现JVM监控等功能。

指标收集以后，强烈建议使用kafka进行一次缓冲。除了其逆天的堆积能力，也可以方便的进行数据共享(比如将nginx日志推送给安全组)。

指标进入消息队列后，一份拷贝将会通过logstash的过滤和整理入库ES等NoSQL;另外一份拷贝，会经过流计算，统计一些指标(如QPS、平均相应时间、TP值等)。

可以有多种途径计算触发报警的聚合计算。回查、叠加统计都是常用的手段。在数据量特别大的情况下，先对指标数据进行预处理是必备的，否则，再牛的DB如influxdb也承受不住。

展现方面，grafana因其极高的颜值，首选，并支持通过iframe嵌入到其他系统。

其缺点也是显著的：支持类型有限(同比、环比、斜率都木有);报警功能不是很好用。

怎么?觉得这套技术栈过长?你其实是可以直接选择zabbix这种现成的解决方案组件的，它的插件也够多，小型公司用起来其实最爽不过了。

但组件毕竟太集中了，你不方便将其打散，发现问题也不能任性的替换它的模块，这在架构上，是一个致命硬伤。最后突然发现，实现成本居然增加了。这也是为什么上点规模的公司，都不在用它。

自己开发一个也是可行的，但不简单，要处理各种复杂的前端问题，也不是每个人都能够做漂亮。

2、日志

说到日志部分，大家首先想到的肯定是ELKB啊。但我觉得ELKB的链路不稳定不完整，建议做以下改造：

可以看到和系统监控的构造其实是差不多的，很多组件可以重用。区别就是数据量大，往往一不小心就把带宽占满了。日志的特点就是量大无规则(nginx算是良民了)，SLA要求不会太高。

这时候收集部分就要用一些经的住考验的日志收集组件了。Logstash的资源控制不是太智能，为了避免争抢业务资源，flume、beats是更好的选择。

同样，一个消息队列的缓冲是必要的，否则大量Agent假死在业务端可不是闹着玩的。

关于日志落盘。很多日志是没必要入库的，比如研发同学开开心心打出来的DEBUG日志，所以要有日志规范。logstash根据这些规范进行过滤，落库到ES。日志量一般很大，按天建索引比较好。更久之前的日志呢，可以归集到日志堡垒机(就是非常非常大的磁盘)，或者直接放HDFS里存档了。

那么怎么过滤业务日志的错误情况呢，比如有多少XXX异常触发报警。这种情况下可以写脚本，也可以接一份数据进行处理，然后生成监控项，抛给metrics收集器即可。

哈!又绕回去了。

3、Tracing

相比较普通监控和日志，调用链APM等就复杂的多了。除了有大量的数据产生源，也要有相应的业务组件来支持调用链聚合和展示。其功能展示虽然简单，但却是监控体系里最复杂的模块。

Google 的论文

“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”

开启了调用链的流行。后续可以说是百家齐放，直到近几年才出现了OpenTracing这样的标准。

在数据处理和后续展示方面，它的技术点其实与监控技术是雷同的，复杂性主要体现在调用链数据的收集上。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!