分布式链路追踪

Web 页面中的白屏时间、DOM 元素/资源加载耗时、文档网络耗时；App 的卡顿率、崩溃率、热启动加载时长

在 Web 页面中，如果出现脚本错误，则需要将相应的异常信息通过日志的方式上报服务器

App 也会有相应的日志输出，但移动端更关注系统崩溃或出现异常时的日志信息

访问量、成功率、响应时间等

访问是否可用、响应耗时长短等。这与 CDN、DNS 等

响应时间、QPS 等

MySQL 中的慢查询监控

Kafka 中的 Lag 监控

如内存级别的 Redis 会消耗大量的内存

Kakfa 则因为要进行磁盘写入所以会要求较好的 I/O

JVM 监控，比如 GC 时间、线程数、FGC/YGC 耗时等信息

应用访问量到达阈值

如是否会存在两个服务之间的相互循环引用，下游服务出现问题是否会干扰整个流程的执行

服务之间的响应时长、上下游服务的依赖程度等

应用自身日志

三方组件日志，如MySQL 的进程日志、慢查询日志等

当前服务是否存活、服务运行是否稳定等

ES 中可以看到服务的状态（RED、YELLOW、GREEN）

Eureka

I/O 使用率、CPU 利用率、内存使用率、磁盘使用率、网络使用率、负载等

主机与主机之间的网络情况

请求 IP、请求 UA，还包含与下游服务相关的 IP 地址、响应时长信息等

如 Java 开发人员使用最多，最熟悉的 Tomcat

容器启动日志

请求访问日志

通过框架编写

一般指的是 Linux 平台中的“/var/log/messages”

通常 Linux 的日志会通过环境变量定制

查询到哪个人在哪个时间点进行了哪些操作

在系统出现异常问题时，查看是谁，因为什么操作而导致的

在高并发的情况下，存在比较严重的锁竞争关系，会导致性能不能得到有效的发挥

更加高效的写入性能

更多的功能，比如异步日志

采用 Disruptor 来进行异步日志

提供了动态占位符的功能

系统/应用启动和参数变更

关键操作节点

大型任务进度上报

异常

日志编写位置

日志数量

日志编写等级

日志输出级别

无用输出参数

节约性能

便于编写

便于查看

会话标识

请求标识

参数信息

发生数据的结果

四个九 = 8760 * (1 - 99.99%) = 0.876 小时 = 0.876 * 60 = 52.6 分钟  五个九 = 8760 * (1 - 99.999%) = 0.0876 小时 = 0.0876 * 60 = 5.26 分钟

2xx：响应被正常处理。一般系统中会使用 JSON 来返回数据，而 JSON 可能会有不同的业务状态码，监控时可以依据具体的情况定制。 3xx：请求被重定向。如果出现了大量的重定向，一般就表明该网页存在一定的问题，而且也存在降低用户使用体验的风险。 4xx：无法访问，比如我们常见的 403 无权限、404 未找到。4xx 说明业务边界存在问题，可能会导致身份信息出现问题或者页面访问异常。 5xx：这个在后端比较常见，如果服务器内部出现了错误，通常也会伴随着访问出现错误。

在 HTTP 请求层面，一般可以通过总共的请求数与 5xx 请求数之间的运算获得

总共有多少个用户访问

在使用 Dubbo 的时候，你可以通过监控线程池的资源信息掌握系统运行的状态，这其中的指标有总计的线程数、活跃线程数等

活跃数、闲置数和总共的资源数

监控任务的发送量、处理量、Lag 值、处理耗时

关注命中率、内存使用率、数据量等指标

监控其请求数、耗时情况等指标

在与第三方服务通信的时候，我们一定要做好熔断降级策略

关键路径

处理流程

触发行为

队列

线程池

处理过程

处理结果

调用次数

调用时长/错误次数

入口

出口

本地

增加埋点成本高，很难全面覆盖

占用 CPU 和内存的资源

动态增加埋点技术不可靠

了解整个系统的架构、服务和服务之间的依赖

在基础层中，我们可以把系统宕机、进程或者端口挂掉、网络丢包这样的情况认定为是故障

在业务层中，监控的内容也就相对比较多了，比如 Dubbo 调用出错、日志中出现的错误，都是可以被认定为“错误”的指标

以立即看出来的错误

表面上显示完全正确，但是在数据中已经出现异常的错误

在表面上显示正确，但是可能因为某种策略被认定为错误

简化数据

易于告警

时间点

主体

测量值

选择阈值

保证实时性

告警操作

定期删除

不同的告警级别设置不同的频率

通常指出现告警或者故障时，相对比较容易处理的问题，一般和告警分级中的 warning 级别对应

如果某个事件内容持续出现，并且并没有被处理，事件单就会升级为问题单，然后进一步通知开发人员，直到开发人员的 TL。在告警规则中，problem 级别的告警会直接被认定为问题单

如果指定的问题依旧没有被处理，此类任务就会再次升级为故障单。故障单一般是系统出现了严重错误，此时影响面相对较广，需要更多的人来参与到问题的处理，及时修复问题。这和告警分级中的 critical 相互对应

根据重要级别确认告警内容是由于短暂的问题导致的异常信息，还是会向更严重的级别发展

当天需要给出响应的解决办法，并跟进后续的改进

在此次告警处理完成后，可以记录问题出现的原因和如何恢复的

对于此次告警，后续会有哪些改进措施来避免此类问题

事故总控负责人：负责把握此次故障的整体进度，协调人力资源来处理此次告警。在处理完成后汇总整体流程，完成最终的故障复盘、后续跟进等工作。一般来说，负责人是 on-call 值班人员、项目负责人或是运维负责人，他是整个故障中流程跟进最重要的人员。

问题处理团队：负责问题的整体处理，与总控人员在事件中都全程参与问题原因的发现和故障的解决。这个团队可能是相关业务的开发团队，也有可能是运维团队。

聚集参与者

紧急恢复，保留现场

发现原因

确认解决方案并实施

事故复盘

发生时间：问题真正出现的时间点，可以通过查询相关观测数据获得。

发现时间：得知问题的时间点，无论是人员反馈还是系统报警。

结束时间：告警被处理完成的时间点，将这部分时间减去发生时间，可以得知此次故障范围总计的时长。

处理流程：由时间节点和处理内容构成，用于说明事件恢复的整体速度。在复盘时，我们可以在这里看出来哪里流程上还有优化的空间。

故障原因：用于描述此次问题发生的主要原因，可以结合告警系统中的数据内容来展示。

影响范围：本次故障会导致哪些地方的用户无法访问或是使用流程中有哪些阻碍。

后续改进措施：故障处理完成后，后续的跟进也很重要。这部分内容可以帮你了解如何避免类似的问题，如何更快地得知问题，如何降低其发生的概率，或者是如何从根本上解决。这里要列出相关的解决方案、处理人和处理事件节点。这是防止类似问题发生的关键步骤

收集到数据之后，它会将数据发送至 Kafka 集群中

接下来 Logstash 就可以启动一个集群来消费 Kafka 集群中的日志信息

数据采集：对于推送模式来说，业务系统一旦启动，便会定期主动将数据信息上报；拉取模式则是暴露指标，由收集器决定是否获取数据

可扩展性：推送模式可以随时扩展新的节点信息，实现线性增长；拉取模式的工作负载由业务系统的数量决定，如果业务系统数量不断增加，收集器系统也只需要动态增加机器

安全性：推送模式本身就是安全的，业务系统可以防止遭受到远程攻击；拉取模式一般采用轮训协议，可能有潜在的访问攻击

灵活性：推送模式相对不灵活，因为它只能定期发送数据；拉取模式则可以随时获取数据

系统耦合：推送模式对于系统耦合性相对较高，因为它需要获取到收集器列表，并对其进行发送数据处理，如果收集系统出现问题，数据可能会丢失；拉取模式的耦合性则相对较低

接收器集群

聚合服务器