简介

• 简介
• 监控报警内在原因
• 一个好的监控报警系统什么样
  • 监控的几个反模式
  • 报警哲学
  • 监控理念
• 常见痛点及解决
• 未来是关联
• 工程
• 其它

一切系统都是分布式的在经典分布式计算理论中，我们学到的一件事情是：分布式系统经常会发生故障，而且 大都是局部而非全局故障。这些故障不仅难于诊断和预测，而且很难复现。应对复杂分布式系统的方法并不是简单地增加测试，或者采用敏捷开发流程，也不是采用 DevOps 或者持续交付（continuous delivery）。任何单一的技术或方法都无法阻止事故再次发生。实际上，类似这样的事情肯定会再次发生。你必须开始：

1. 接受这样的假设：支撑你的软件运行的系统一定会发生故障
2. 对为什么会发生故障以及故障可能会以怎样的形式发生做出预案
3. 针对这些预案设计数据收集方案

这并不是像说一句“我们需要更多测试”那么简单。传统的测试哲学中，假定 所有测试用例都是能够描述出来的，但在分布式系统中这一点不再成立。（这并不是说 测试不重要了，而是说测试不再是万灵药。）当处于一个分布式环境、并且大部分故障模 式都是无法提前预测也无法测试时，监控就成了唯一的理解应用行为的方式。在这个过程中开发者不能再将监控视为纯粹是系统管理员的领 域。

看Netflix如何简化应用程序监控体系

淘宝客户端诊断体系升级实践

2022，我们该如何理解可观测技术我们可以将可观测问题大致分为四类：

1. 分布式链路追踪技术：可观测的基石。分布式链路追踪技术的核心思想是：在用户一次请求服务的调⽤过程中，无论请求被分发到多少个子系统，子系统又调用了多少其他子系统，我们都要把系统信息和系统间调用关系都追踪记录下来，最终把数据集中起来做可视化展示。
2. APM：Application Performance Monitoring ，应用性能监控
3. NPM：Network Performance Monitoring ，网络性能监控。其关键在于实现全网流量的可视化，对数据包、网络接口、流数据进行监控和分析。
4. RUM：Real User Monitoring，真实用户监控。关键在于端到端反应用户的真实体验，捕捉用户和页面的每一个交互并分析其性能。 同时，可观测存在三个主要的数据源： 聊聊可观测性之数据模型
5. 指标（metrics），告诉我们是否有故障，它的数据模型：LabelSet + Timestamp + Number
6. 链路（trace），告诉我们故障在哪里，数据模型：LabelSet + Timestamp + String，和 Metric 类似，只是 Number 换成了 String
7. 日志（log），告诉我们故障的原因，数据模型：Operation Name + Start / End Timestamp + Attributes + Events + Parent + SpanContext。
   1. Operation Name：操作名
   2. Start / End Timestamp：开始和结束时间
   3. Attributes：KV 对，包括 Status（比如 OK、Cancelled、Permission Denied）、
   4. SpanKind（CLIENT、SERVER、PRODUCER、CONSUMER、INTERNAL 等）、自定义信息等
   5. Events：若干个元组列表，每个元组包括 timestamp、name、Attributes，用于记录一系列重要事件
   6. Parent 包含父亲的 Span ID、Trace ID
   7. SpanContext 包含自身的 Span ID、Trace ID 所处行业不同，对可观测体系的需求也会有较大差异。比如说，电商行业可能对链路和日志监控的联动要求很高，但物联网系统可能很多不需要链路监控。

透彻理解OpenTelemetry 未读

OPLG：新一代云原生可观测最佳实践 未细读

监控报警内在原因

蚂蚁智能监控在设计稳定性架构之初，我们首先应该意识到系统的运行时环境和输入都不会是稳定的。

1. 运行时环境的不稳定 ，主要体现在机器的故障宕机、网络的抖动，或者更极端的机房光纤被挖断、城市自然灾害等客观因素影响。处理这类问题通常从两方面出发：
   1. 尽可能地提升系统的容灾等级。例如单点、机房级容灾、城市级容灾等
   2. 所有的数据处理流程都应该面向失败进行设计。因为当故障发生后，可能某几个周期的任务已经失败，这时候需要有能力驱动这些任务进行重试
2. 针对系统输入的不确定性 ，我们也分两种情况进行处理：
   1. 第一种情况是入口数据的错乱，例如脏配置、脏元数据、不合法的数据类型等，错误的数据流入系统可能会导致不可预期的行为，针对此类问题，我们通常需要在入口处进行校验，拒绝非预期的数据流入系统。
   2. 第二种情况是入口数据量级管控，任何系统，其性能都是和容量挂钩的，其设计也都是在一定的性能容量平衡假设下进行的。

一个好的监控报警系统什么样

云原生下的可观察性发展方向当我在说可观察性的时候我在说啥？

典型问题排查过程

在 IT 系统的可观察性上，也可以类似划分 6 级：

1. 等级 0：手工分析，依靠基础的 Dashboard、告警、日志查询、分布式链路追踪等方式进行手动告警、分析，也是目前绝大部分公司使用的场景
2. 等级 1：智能告警，能够自动去扫描所有的可观察性数据，利用机器学习的方式去识别一些异常并进行自动告警，免去人工设置 / 调整各种基线告警的工作
3. 等级 2：异常关联 + 统一视图，对于自动识别的异常，能够进行上下文的关联，形成一个统一的业务视图，便于快速的定位问题
4. 等级 3：根因分析 + 问题自愈，自动根据异常以及系统的 CMDB 信息直接定位问题的根因，根因定位准确后那边可以去做问题的自愈。这一阶段相当于是一次质的飞跃，在某些场景下可以在人不用参与的情况下实现问题的自愈。
5. 等级 4：故障预测，故障发生总会有损失，所以最好的情况是避免故障的发生，因此故障预测技术可以更好的来保证系统的可靠性，利用之前积累的一些故障先兆信息做到 “未卜先知”
6. 等级 5：变更影响预测，我们知道绝大部分的故障都是由变更引起的，因此如果能够模拟出每个变更对系统带来的影响以及可能产生的问题，我们就能够提前评估出是否能够允许此次变更。

vivo统一告警平台建设与实践

阿里可观测性数据引擎的技术实践 统一存储引擎，统一分析引擎，数据编排。

监控的几个反模式

1. 事后监控，没有把监控作为系统的核心功能
2. 机械式监控，比如只监控cpu、内存等，程序出事了没报警。只监控http status=200，这样数据出错了也没有报警。
3. 不够准确的监控
4. 静态阈值，静态阈值几乎总是错误的，如果主机的CPU使用率超过80%就发出警报。这种检查 通常是不灵活的布尔逻辑或者一段时间内的静态阈值，它们通常会匹配特定的结果或范围，这种模式 没有考虑到大多数复杂系统的动态性。为了更好地监控，我们需要查看数据窗口，而不是静态的时间点。如何在实际场景中使用异常检测？阿里云Prometheus智能检测算子来了
5. 不频繁的监控
6. 缺少自动化或自服务

一个良好的监控系统 应该能提供 全局视角，从最高层（业务）依次（到os）展开。同时它应该是：内置于应用程序设计、开发和部署的生命周期中。

很多团队都是按部就班的搭建监控系统：一个常见的例子是监控每台主机上的 CPU、内存和磁盘，但不监控可以指示主机上应用程序是否正常运行的关键服务。如果应用程序在你 没有注意到的情况下发生故障，那么即使进行了监控，你也需要重新考虑正在监控的内容是否合理。根据服务价值设计自上而下（业务逻辑 ==> 应用程序 ==> 操作系统）的监控系统是一个很好的方式，这会帮助明确应用程 序中更有价值的部分，并优先监控这些内容，再从技术堆栈中依次向下推进。从业务逻辑和业务输出开始，向下到应用程序逻辑，最后到基础设施。这并不意味着你不需要收集基础设施或操作系统指标——它们在诊断和容量规划中很有帮助——但你不太可能使用这些来报告应用程序的价值。如果无法从业务指标开始，则可试着从靠近用户侧的地方开始监控。因为他们才是最终的客 户，他们的体验是推动业务发展的动力。PS：只要业务没事，底层os一定没事， 底层os没事，业务逻辑不一定没事，监控要尽量能够反应用户的体验。

Pull or Push？监控系统如何选型

报警哲学

一个好警报的关键是能够在正确的时间、以正确的理由和正确的速度发送，并在其中放入有 用的信息。警报方法中最常见的反模式：

1. 发送过多的警报。比如故障的主机或服务上游会触发其下游的所有内容的警报。你应确保警报系统识别并抑制这些重复 的相邻警报。关注症状而不是原因（因为引发一个症状的原因有很多）。噪声警报会导致警报疲劳，最终警报会被忽略。修复警报不足比修复过度警报更容易。
2. 警报的错误分类。比如应设置正确的警报优先级
3. 发送无用的警报。警报应包括适当的上下文。

监控理念

devops基本理念：

1. if you can’t measure it,you can’t improve it
2. you build it,you run it, you monitor it. 谁开发，谁运维，谁监控

监控是分层次的， 以metric 为例

1. 系统层，比如cpu、内存监控，面向运维人员
2. 应用层，应用出错、请求延迟等，业务开发、框架开发人员
3. 业务层，比如下了多少订单等，业务开发人员

许式伟：信噪比高，有故障就报警，有报警就直指根因。

采用合适的精度：应该仔细设计度量指标的精确度，这涉及到监控的成本问题。例如，每秒收集 CPU 负载信息可能会产生一些有意思的数据，但是这种高频率收集、存储、分析可能成本很高。如果我们的监控目标需要高精度数据，但是却不需要极低的延迟，可以通过采样 + 汇总的方式降低成本。例如：将当前 CPU 利用率按秒记录。按 5% 粒度分组，将对应的 CPU 利用率计数 +1。将这些值每分钟汇总一次。这种方式使我们可以观测到短暂的 CPU 热点，但是又不需要为此付出高额成本进行收集和保留高精度数据。

将需要立即处理和可以第二天处理的报警规则区分一下。每个紧急状态的报警的处理都应该需要某种智力分析过程。如果某个报警只是需要一个固定的机械化动作，那么它就应该被自动化。

接警后的第一哲学，是尽快消除故障。找根因不是第一位的。如果故障原因未知，我们可以尽量地保留现场，方便故障消除后进行事故的根因分析。一般来说，有清晰的故障场景的监控报警，都应该有故障恢复的预案。而在那些故障原因不清晰的情况下，消除故障的最简方法是基于流量调度，它可以迅速把用户请求从故障域切走，同时保留了故障现场。

常见痛点及解决

基于海量日志和时序数据的质量建设最佳实践

1. 质量观测的几个痛点：
   1. 海量的异构数据
   2. 依赖规则，缺乏智能
   3. 告警风暴与告警误报 无效告警优化实践总结 跟误告警说再见，Smart Metrics 帮你用算法配告警
2. 针对第一点，数据统一接入和管理，将这些异构的数据进行统一的存储和管理。将日志、指标、Trace等数据全部接入到一个统一的可观测性存储中。然后基于这个统一的存储，进行后续的查询分析、可视化、监控告警、AI 等上层能力，甚至还可以进行数据的加工和规整，一站式地完成异构数据到同构数据的转换过程。基于统一的存储，我们可以构建统一的查询和分析语法，从而一套语法适配不同的数据，并且让不同的数据之间进行联合查询也变成了可能。我们以标准 SQL 为基础，进行了部分 DSL 扩展和 SQL 函数扩展，并融合了 PromQL，从而让不同类型的数据查询和分析变得统一。
3. 针对第一点， AntMonitor 总结 - 云原生 Prometheus 监控实践 AntMonitor是一款主要以日志方式采集监控数据的监控产品，Prometheus 是 metrics 监控的事实标准，需要将 Prometheus 的主要功能融合进了 AntMonitor 的现有架构
   1. AntMonitor 现有的数据链路大致为由 agent 采集日志数据缓存于内存，由 spark 计算集群从 agent 内存中拉取数据，进行聚合，存储于 CeresDB。 metrics 数据不同于日志数据，，可以跳过计算步骤，直接进行存储。因此，我们根据用户的业务需求，提供了两条数据链路：直接存储metric 源 == 拉取==> 采集agent ==> PushGateway ==> CeresDB存储；需要数据聚合的情况下，走基于 spark 的聚合数据采集。
   2. 日志数据均需要按照某些固定 schema（数据表结构）作切分清洗、计算聚合，但metric 必须由用户配置聚合规则，由于 metrics 数据本身就包含 schema 信息，我们通过自动化的配置项，自动对 Gauge、Counter、Histogram 等 metric type 自动为用户生成了部分聚合配置
   3. 原生 Prometheus 提供多种服务发现机制
   4. 原生 Prometheus 通过 relabeling 功能实现采集目标过滤等，还可以通过 metric relabeling 对拉取到的数据进行编辑。
   5. 存储时， CeresDB 针对这种数据量巨大的情景，按 label 标签进行了分区。 原生 Prometheus 提供了 Recording Rules (RR) 和 Alerting Rules (AR) 功能，将一些指标预计算并存储，方便日常查询。
   6. PromQL 查询数据时，会将查询按选定label维度拆分下推至所在 data 节点进行执行，再由每个 data 节点产出的结果，在 proxy 节点产出最终查询结果，返回至用户。
   7. AntMonitor 的可视化主要为日志监控设计，而社区普遍使用 grafana 来解决metrics监控的可视化问题
4. 针对第二点，智能巡检。我们采用无监督学习算法，自动识别实体的数据特征，根据数据特征选取不同的算法组合，针对数据流实时建模，完成异常任务检测。并根据用户的打标信息（对告警进行确认或者误报反馈），训练监督模型，对算法进行不断优化，从而提高监控的准确率。目前异常检测我们使用了两种算法：
   1. 流式图算法，适用于一般性时间序列的异常检测场景，包括：机器级别的监控指标的异常巡检，例如CPU占用率、内存利用率、硬盘读写速率等。Time-Series Event Prediction with Evolutionary State Graph
   2. 流式分解算法，适用于对具有周期性的数据序列进行巡检，且要求数据的周期性较为明显。例如游戏的访问量、客户的订单量。RobustSTL: A Robust Seasonal-Trend Decomposition Algorithm for Long Time Series
5. 针对第三点
   1. 告警智能降噪包含以下几种机制：自动去重；路由合并；告警抑制；告警静默。
   2. 动态分派。多渠道；动态通知；通知升级；值班和代班机制（报警报给值班人）

面对疾风吧，如何搭建高协同的精准告警体系？

1. 「标准化告警处理流体系」的缺失
   1. 告警源数据缺乏统一标准以及统一维度的标签
   2. 缺乏全局视角的告警数据处理和富化，需要 对告警进行分解、提取和内容增强的工具。
2. 组织协同处理告警难以落地
   1. 如何通过组织协同灵活处理告警？
   2. 如何避免组织隔离的复杂性灵活处理告警？ 解决
3. 「标准化告警事件处理流」
   1. 借助告警平台灵活的编排组合能力以及丰富的处理动作，去快速处理多样化告警场景。PS： 也可以拖拖拽拽的编排一个告警的处理？
   2. 内容 CMDB 富化，打破信息孤岛。
   3. 通过 AI 内容识别，快速了解告警分布。报警关联。根据常见告警现象自带 20+ 规则，帮组用户快速压缩告警事件
4. 「面向告警的组织协同」
   1. 联系人自助注册到告警系统
   2. 复用已有账号体系，避免在工作中使用多个账号系统
   3. 灵活的权限分配方式。
   4. 丰富的可扩展能力。基于钉钉建设的 ChatOps 能力

从 “香农熵” 到 “告警降噪” ，如何提升告警精度？

一文看懂业界在离线混部技术可观测性在分布式及云原生时代，遇到了以下障碍:

1. 云原生的体系，决定了服务能力和服务规模随时都在动态调整，所以端上数据收集 、传输的成本大大增加，极端情况下甚至对服务本身性能造成侵扰。
2. 可观测性输出要形成决策意义，需要基于一些维度进行归并、拟合、建模等操作，包括使用决策树到 AI 学习等一系列分析动作。在大服务体量和实时变动的背景下，可观测性输出的分析时延、准确性都面临很大挑战。
3. 可观测性的可视化以及延展关联分析 (BI 报表等)，需要根据业务形态和需求进行深度定制，复杂性较高，缺乏直接能用的工具和手段。

未来是关联

一文读懂可观测性与Opentelemetry传统的系统相对简单，(我们会不辞劳苦地在各种指标数据中寻找可能的关联性，得到关键线索后，我们会在大脑中构造出一堆复杂的日志查询条件来验证自己的猜想。就这样比对、猜想、验证，同时还要在各种工具中切换)行之有效。现代IT系统的关键词是分布式、池化、大数据、零信任、弹性、容错、云原生等，越来越庞大，越来越精细，越来越动态，同时也越来越复杂。通过人去寻找各种信息的关联性，再根据经验判断和优化，显然是不可行的，耗时耗力还无法找到问题根因。传统的工具是垂直向的，引入一个新的组件的同时也会引入一个与之对应的观测工具，这样是保证了数据的全面性，但丢失了数据的关联性和分析排查的连贯性（换句话说，我们方方面面都监控到了，但遇到问题，还是不能很好地发现和定位）。此时我们很自然的想到做一个统一的数据平台，想象中把所有数据放在一个平台就能解决关联性的问题，但往往实际情况是我们只是把数据堆在一个地方，用的时候还是按传统的方式各看各的。我们只是把无数根柱子（工具），融合成了三根柱子：一个观测指标、日志、链路的统一平台，数据统一了，但关联性还得靠人的知识和经验。这里边最关键的其实是解决数据关联的问题，把之前需要人去比对、过滤的事交给程序去处理，程序最擅长此类事同时也最可靠，人的时间更多的用在判断和决策上。这在复杂系统中，节省的时间会被放大很多倍，就这点小事就是可观测性看得见的未来。

那么，如何做数据关联呢？说起来很容易，那就是做时间+空间的关联。在我们的统一数据平台上，由于数据是来自于各种观测工具的，虽然我们在数据格式上统一成了metric、log、trace，但不同工具的metric、log、trace的元数据截然不同，而如果我们在这个统一数据平台上去梳理和映射这些元数据的话，这将是庞杂、难维护、不可持续的。那该如何做呢？答案就是标准化。只有将标准化、结构化的数据喂给观测平台，观测平台才能从中发现巨大价值。统一数据平台只是在数据格式上进行了标准化，而要想将trace、metric、log关联还必须建立context的标准化，context就是数据的空间信息，再叠加上时间信息的关联就可以发挥真正的观测价值。

MetaFlow：开源的高度自动化可观测性平台非常酷的AutoMetrics，AutoTracing、AutoTagging、SmartEncoding等创新能力

1. AutoMetrics，MetaFlow完整的使用了eBPF的kprobe、uprobe、tracepoints能力，也完整的使用了eBPF的前身——已经有三十年历史的BPF的能力，与AF_PACKET、Winpcap等机制结合，实现面向任何操作系统、任意内核版本的全自动的数据采集。也就是说，不管一个调用是发生在Application这一侧的客户端或服务端，不管是一个加密之后的HTTPS调用、编码之后的HTTP2调用，还是普通明文的HTTP、Dubbo、MySQL、Redis调用，都能自动的获取到它的每一个调用的事件详情及RED（Request、Error、Delay）性能指标。不管这个调用流经的是Pod的虚拟网卡、VM的虚拟网卡、宿主机的物理网卡，还是中间的NFV虚拟网关，或者七层API网关，只要有MetaFlow Agent部署到的地方，都可以通过eBPF/BPF技术从内核中获取到调用数据，并生成应用层面的RED指标、网络层面的吞吐、时延、异常、重传等指标。这样的指标采集是完全自动化的，它不需要我们的开发者手动做任何的埋点或插码，所有这些能力，通过部署MetaFlow Agent即可自动获取到。
2. AutoTracing，eBPF追踪的是每个Request相关的TCP/UDP通信函数，通过挂载到这些系统调用函数中实现自动追踪，高度完整的展示出微服务调用链。PS：异步调用的追踪还有欠缺
3. AutoTagging，MetaFlow Agent通过同步K8s、服务注册中心的大量的资源、服务、API属性信息，然后由Server进程汇总并统一插入到所有的可观测性数据上，使得我们能够无缝的、在所有数据之间关联切换，呈现应用调用的全栈性能。基于AutoTagging构建统一的可观测性数据平台的实践 DeepFlow AutoTagging 之 Prometheus 标签标准化 未读。
4. SmartEncoding，MetaFlow会为所有观测数据自动注入大量的Tag，比如在容器环境中，从客户端去访问服务端这样的双端数据，可能要注入上百个维度的标签，这些标签有可能是非常长的字符串，给我们的后端存储造成了非常大的压力。MetaFlow创新的使用SmartEncoding机制，在Agent上独立采集标签和观测数据，同步到Server端后对标签进行独立的整形编码，并将整形编码注入到观测数据中存储下来，使得整个标签的注入开销降低10倍。由于存储的标签都是Int编码之后的，有助于降低查询过程中的数据检索量，也能显著提升查询性能。而对于一些衍生的Tag则完全没必要存储在数据库中，MetaFlow Server通过SQL接口抽象出来底层的一个大宽表。比如在底层我们存储了40个标签，通过Server的抽象，把它延展成100个标签的虚拟大宽表。上层应用在虚拟大宽表之上进行查询，完全感受不到标签是否存储在数据中、是以Int还是String的形式存储。

工程

案例：vivo容器集群监控系统架构与实践

线上故障突突突？如何紧急诊断、排查与恢复 问题实例流量隔离（而不是杀死实例）、内存快照、Arthas UI化、耗时/报错与源代码关联，真是把“故障 1 分钟响应、5 分钟定位、10 分钟恢复” 给做透了。

其它

做出让人爱不释手的基础软件：可观测性和可交互性 个人理解: 尽可能多的监控，之后就是尽量串起来

1. 我觉得更重要的是，找问题过程中我们使用的工具、老司机的思考过程。作为一个观察者，我看到年轻的同事看着老司机熟练地操作 perf 和在各种各样工具和界面中切换那种仰慕的眼神，我隐约觉得事情有点不对：这意味着这门手艺不能复制。
2. 如果打开 TiDB 的内部 Grafana 就会看到大量这样的指标，得到对系统运行状态的大致图景。更进一步的关键是，这些系统的指标一定要和业务上下文联系在一起才能好用，举例说明，对于一个支持事务的数据库来说，假设我们看到 CPU 线程和 call stack，发现大量的 CPU 时间花在了 wait / sleep / idle 之类的事情上，同时也没有其他 I/O 资源瓶颈，此时，如果只看这些的数字可能会一脸懵，但是结合事务的冲突率来看可能柳岸花明，甚至能直接给出这些 lock 的等待时间都花在了哪些事务，甚至哪些行的冲突上，这对观测者是更有用的信息。
3. 如果我们讨论可观测性脱离了周期，就毫无意义。周期越贴近终端用户的使用场景越实用。譬如，在数据库中，选择单条 SQL 的执行作为周期不如选择事务的周期，事务周期不如应用程序一个请求全链路的周期。其实 TiDB 在很早就引入了 OpenTracing 来追踪一个 SQL 的执行周期内到底调用了哪些函数，花费多少时间，但最早只应用在了 TiDB 的 SQL 层内部（熟悉我们的朋友应该知道我们的 SQL 和存储是分离的），没有在存储层 TiKV 实现，所以就会出现一条 SQL 语句的执行过程往下追到 TiKV 就到了一个断头路；后来我们实现了把 TraceID 和 SpanID 传到了 TiKV 内部这个功能才算初步可用，至少把一个周期的图景变得更加完整了，本来我们打算就止步于此，但是后来发生了一个小事情，某天一个客户说：为什么我的应用访问 TiDB 那么慢？然后我一看 TiDB 的监控，没有啊，SQL 到数据库这边基本都是毫秒就返回了，但是客户说：你看我这个请求也没干别的呀，两边怎么对不上？后来我们把 Tracer 加进来以后才知道客户这边的网络出了点问题。这个案例提醒了我，如果能做到全链路的 Tracing，这里的全链路应该是从业务端请求开始计算，去看待生命周期才有意义。所以在此之后我们在 TiDB 里面通过拓展 Session Variable，能够支持用户将 OpenTracing 协议的 Tracer 信息通过 Session Varible 传入到 TiDB 的体系中，打通业务层和数据库层，能够真正实现的一个全生命周期的跟踪，这个功能也会在很近的未来的版本中和大家见面。
4. 根据我们的经验，结合上面内容，有了完善的 Tracing 系统，大部分的 Debug 过程在 Tracing + Log 就能找到问题的根因。
5. 我在观察老师傅处理问题的时候发现一个特别有意思的现象：有经验的开发者总是能够很快通过观测，决定自己接下来该做什么，不需要查阅资料什么或者等着别人指导，完全处于一个心流的状态（例如在 TiDB 里面看到数据在集群内部分布不均或者有热点，就知道去修改调度策略或者手工 split region），但是新人在这一步总是会卡着，要么去 Google 要么去翻文档，内心 OS：「我看到问题了，然后怎么办？」，如果这个时候，系统能够给一些接下来应该观测哪些指标，或者行动建议，会更加友好，目前能做到这一点的系统不多，如果能做到这一点，相信你的系统已经在可观测性上做得很棒了。把这个点放在可观测性的最后其实是想借着这个话题引出可交互性。
6. 一个优秀的基础软件，在输出负向反馈的时候，最好的做法就是建议开发者接下来该干嘛。遇到真的 Unknown Error 要输出各种帮助 Debug 的上下文信息，最后在错误日志里提示用户到哪个链接提 Github Issue，然后最好在 URL Link 里帮用户把 Issue Title 填好（让用户自己决定是不是发 Issue）。

高效定位代码问题为了提高排查效率，目前常见的解决方案是：链路跟踪+日志分析工具相结合。即通过链路跟踪产品（如阿里云的Tracing Analysis）可视化还原业务执行过程的系统调用链路的拓扑、接口请求量与耗时等数据，再配合日志分析工具（如阿里云的SLS）进一步分析链路中某个系统的详细日志从而锁定出问题的大致坐标。分析具体日志详情以及一键跳转日志关联的源码仓库，定位到问题代码行。PS: 定位问题项目 ==> 代码

日志在可观测场景下的应用以故障发现和故障定位为目的使用日志场景可大致分为日志搜索和日志分析两类：

1. 日志搜索：通过日志关键字搜索日志；通过线程名、类名搜索日志；结合 Trace 上下文信息，衍生出根据 TraceID、根据 spanName、parentSpanName、serviceName、parentServiceName 搜索日志。
2. 日志分析：查看、分析指定日志数量的趋势；根据日志内容生成指标（比如每次交易成功打印一条日志，可以生成关于交易额的一个指标）；自动识别日志模式（比如查看不同模式的日志数量的变化，占比）。