微服务监控实战（一）：监控概览

如果你觉得这篇文章对你有帮助，请不要吝惜你的“关注”、“点赞”、“评价”，我们可以进一步讨论实现方案和细节。你的支持永远是我前进的动力~~~

灵魂拷问

1. 服务之间的依赖关系？
2. 服务的资源使用情况？
3. 每天的业务高峰期是哪个时间段？
4. 每天发生多少次异常？
5. 有多少次是在收到业务反馈之前知道出问题了？
6. 排查一次问题需要多少时长？
7. 我们有哪些工具可以用于问题定位？

快请监控来帮忙吧！！！

监控分类

监控分类

日志、指标及链路追踪的关系

Metrics 的特点是，它是可累加的：他们具有原子性，每个都是一个逻辑计量单元，或者一个时间段内的柱状图。 例如：队列的当前深度可以被定义为一个计量单元，在写入或读取时被更新统计; 输入 HTTP 请求的数量可以被定义为一个计数器，用于简单累加; 请求的执行时间可以被定义为一个柱状图，在指定时间片上更新和统计汇总。

Logging 的特点是，它描述一些离散的(不连续的)事件。 例如：应用通过一个滚动的文件输出 Debug 或 Error 信息，并通过日志收集系统，存储到 Elasticsearch 中; 审批明细信息通过 Kafka，存储到数据库(BigTable)中; 又或者，特定请求的元数据信息，从服务请求中剥离出来，发送给一个异常收集服务，如 NewRelic。

Tracing 的最大特点就是，它在单次请求的范围内，处理信息。 任何的数据、元数据信息都被绑定到系统中的单个事务上。 例如：一次调用远程服务的 RPC 执行过程;一次实际的 SQL 查询语句;一次 HTTP 请求的业务性 ID。

多维度比较

初始成本： CapEx, the initial cost to start instrumenting and collecting the signals;

持续投入成本： OpEx, the ongoing cost to run the supporting infrastructure;

反映灵敏度： Reaction, how good the system is at detecting and alerting on incidents;

对问题定位的帮助程度： Investigation, how much the system can help to triage and debug incidents

适用场景

不同的监控用于不同的场景

1. 日志、链路、指标数据用于调试、定位问题
2. 健康监控、指标数据用于监控告警

当然也不是绝对的，如也可以通过日志、链路的数据进行分析告警

监控分层

监控要从多个层次去做，否则会发现一堆报警，但查不出原因的尴尬处境

1. 端用户监控：主要从端上采集性能、返回码、app版本、系统、运营商等数据，分析用户访问分布、端到服务器的延时等。
2. 业务监控：定义业务的核心指标，如登录、注册、下单、支付等，可以分析访问频率、流量规律等。
3. 应用层监控：qps、rt、慢请求、缓存命中率，cpu、内存、磁盘使用率等
4. 中间件监控：网关、缓存、MQ、DB等中间件的相关指标
5. 基础设施监控：如网络、交换机、丢包率、连接数、cpu、内存、磁盘等，这项监控通常由运维负责，基本上都是标配，不会遗漏
6. 数据核对：数据一致性、正确性，资金对账等。指标数据都很好，但是数据错了，这才是真要命呢！！！

总结

监控数据有多种，每种有其不同的使用场景，解决不同的问题

完美的监控要从多方面、多层次、全方位考虑

当这些数据都有了，结合起来就具有了可观测性

持续优化系统，系统就可以朝着稳定、高性能的方向发展起来了