全栈监控

今天这篇文章是对于上面分布式日志，链路追踪以及聚合度量的一些总结，以及监控系统的在实际应用中的一些知识点。

一个好的全栈监控系统的构建需要满足一下目标：

• 全栈监控的满足，必须能监控系统的全栈构建。
• 关联分析
• 跨系统调用的串联
• 实时报警，自动处理
• 系统性能的分析

什么是全栈监控？

全栈监控就是对于系统的三个层次都进行监控

• 基础层，比如 cpu 磁盘，磁盘使用量，磁盘的 io 情况，网路吞吐量等
• 中间层，对使用的中间件都要进行监控，比如 MySQL，Redis，Kafka 等。
• 应用层，HTTP 访问的吞吐量、响应时间、返回码，调用链路分析，性能瓶颈，还包括用户端的监控。

什么是监控系统的标准化？

• 日志数据的结构化
• 监控数据格式标准化
• 统一的监控平台
• 统一的日志分析

一个好的监控系统应该满足下面几个目标

• 主要从为用户服务的 API 来监控整个系统
• 关联指标聚合，无论运行在哪里，我们都需要把服务的具体实例和主机关联在一起，否则，对于一个分布式系统来说，定位问题犹如大海捞针
• 快速故障定位

好的监控系统主要提升了系统哪些内容？

• 容量管理，是否需要增加机器
• 性能管理，可以看到系统瓶颈，针对性的优化系统
• 定位问题，快速地暴露并找到问题的发生点
• 性能分析，可以快速地找到系统的瓶颈

监控系统应该实现具体哪些功能？

• 服务调用链跟踪，监控系统应该从对外的 API 开始，然后将后台的实际服务给关联起来，然后再进一步将这个服务的依赖服务关联起来，直到最后一个服务
• 服务调用时长分布
• 服务的 TOP-N 视图，一般来说，这个排名会有三种排名的方法：a）按调用量排名，b) 按请求最耗时排名，c）按热点排名
• 数据库操作关联
• 服务资源跟踪

我们通过监控系统应该达到的目标是：

• 当一台机器挂掉时，我们应该知道会影响哪些对外服务的 API (因为我们始终是对外服务的，所以最终关注的是对外服务的 API 服务)
• 当一个服务响应过慢的时候，我们马上能关联出来是否在做 GC，或是其所在的计算结点上是否有资源不足的情况，或是依赖的服务是否出现了问题
• 当发现一个 SQL 操作过慢的时候，我们能马上知道其会影响哪个对外服务的 API。
• 当发现一个消息队列拥塞的时候，我们能马上知道其会影响哪些对外服务的 API。

一旦发现某个服务过慢是因为 CPU 使用过多，我们就可以做弹性伸缩；一旦发现某个服务过慢是因为 MySQL 出现了一个慢查询，我们就无法在应用层上做弹性伸缩，只能做流量限制，或是降级操作。