如果你觉得这篇文章对你有帮助，请不要吝惜你的“关注”、“点赞”、“评价”，我们可以进一步讨论实现方案和细节。你的支持永远是我前进的动力~~~
灵魂拷问
- 服务之间的依赖关系？
- 服务的资源使用情况？
- 每天的业务高峰期是哪个时间段？
- 每天发生多少次异常？
- 有多少次是在收到业务反馈之前知道出问题了？
- 排查一次问题需要多少时长？
- 我们有哪些工具可以用于问题定位？
快请监控来帮忙吧！！！
监控分类
监控分类
日志、指标及链路追踪的关系
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
适用场景
不同的监控用于不同的场景
- 日志、链路、指标数据用于调试、定位问题
- 健康监控、指标数据用于监控告警
当然也不是绝对的，如也可以通过日志、链路的数据进行分析告警
监控分层
监控要从多个层次去做，否则会发现一堆报警，但查不出原因的尴尬处境
- 端用户监控：主要从端上采集性能、返回码、app版本、系统、运营商等数据，分析用户访问分布、端到服务器的延时等。
- 业务监控：定义业务的核心指标，如登录、注册、下单、支付等，可以分析访问频率、流量规律等。
- 应用层监控：qps、rt、慢请求、缓存命中率，cpu、内存、磁盘使用率等
- 中间件监控：网关、缓存、MQ、DB等中间件的相关指标
- 基础设施监控：如网络、交换机、丢包率、连接数、cpu、内存、磁盘等，这项监控通常由运维负责，基本上都是标配，不会遗漏
- 数据核对：数据一致性、正确性，资金对账等。指标数据都很好，但是数据错了，这才是真要命呢！！！
总结
监控数据有多种，每种有其不同的使用场景，解决不同的问题
完美的监控要从多方面、多层次、全方位考虑
当这些数据都有了，结合起来就具有了可观测性
持续优化系统，系统就可以朝着稳定、高性能的方向发展起来了
标签：实战,请求,概览,指标,监控,链路,日志,数据 From： https://blog.csdn.net/u013469646/article/details/142482474