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

OpenTracing大有一统天下的架势，它在其中融合Tracing、Log、Metrics的概念。我们还是看张图吧，等真正去做的时候去了解也不晚(来源于网络)：

值得一提的是，SpringCloud对它的支持还是比较全面的(OpenTracing API Contributions)，但依赖关系和版本搞的非常混乱。建议参考后自己开发，大体使用”spring boot starter”技术，可以很容易的写上一版。

至于”Spring Cloud 2”，更近一步，集成了micrometer这种神器，对prometheus集成也是非常的有好。业务metrics监控将省下不少力气。

以上谈了这么多，仅仅是聊了一下收集方面而已。标准这个思路是非常对的，否则每个公司都要写一遍海量的收集组件，多枯燥。至于国内大公司的产品，是否会主动向其靠拢，我们拭目以待。

服务端方面，我们以Uber的Jaeger为例，说明一下服务端需要的大体组件：

• Jaeger Client：就是上面我们所谈的
• Agent：监听在 UDP 端口上接收 span 数据的网络守护进程，它会将数据批量发送给 collector
• Collector：接收 jaeger-agent 发送来的数据，然后将数据写入后端存储。
• Data Store：后端存储被设计成一个可插拔的组件，支持将数据写入 cassandra、ES
• Query：接收查询请求，然后从后端存储系统中检索 trace 并通过 UI 进行展示

是的，典型的无状态系统，对等节点当机无影响。

4、分析和预警

上面的状态图不止一次提到流计算，这也不用非要整个Spark Streaming，从kafka接收一份数据自己处理也叫流计算，选用最新的kafka stream也是不从的选择。重要的是聚合聚合聚合，重要的事情说三遍。

一般，算一些QPS，RT等，也就是纯粹的计数;或者斜率，也就是增长下降速度;复杂点的有TP值(有百分之多少的请求在XX秒内相应)，还有调用链的服务拓扑图、日志异常的统计，都可以在这里进行计算。

幸运的是，流计算的API都比较简单，就是调试比较费劲。

分析后的数据属于加工数据，是要分开存储的，当然量小的话，也可以和原始数据混在一起。

分析后的数据量是可评估的，比如5秒一条数据，一天就固定的17280条，预警模块读的是分析后的数据(原始数据太大了)，也会涉及大量的计算。

那么分析后的统计数据用来干什么用呢?一部分就是预警;另一部分就是展示。

1)预警

拿我设计的一个原型来看，对一个metric的操作大体有以下内容：

• 在时间间隔内，某监控项触发阈值XX次
• 触发动作有：大于、小于、平均值大于、平均值小于、环比大于、环比小于、同比大于、同比小于、自定义表达式等
• 阈值为数字数组，支持多监控项相互作用
• 级别一般根据公司文化进行划分，6层足够了
• 聚合配置用来表明是阈值触发还是聚合触发，比如在时间跨度5分钟内发生5次，才算是处罚
• 报警触发后，会发邮件、打电话、发短信、发webhook等

仅做参考，这只是配置的冰山一角。要把各种出发动作做一遍，你是要浪费很多脑细胞的。

2)展示

有很多可视化js库，但工作量一般都很大。但没办法，简单的用grafana配置一下就可以了，复杂点的还需要亲自操刀。

我这里有两张简单的grafana图，可以参考一下：

[系统监控]

[jvm监控一部分]

5、小结

整体来说，整个体系就是收集、处理、应用这大三类数据(logs、metrics、trace)。

其中有些组件的经验可以共用，但收集部分和应用部分相差很大。我尝试总结了一张图，但从中只能看到有哪些组件参与，只看图是临摹两可的。

具体的数据流转和处理，每种结构都不尽相同，这也是为什么我一直强调分而治之的原因。

（编辑：核心网）

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