技术

学习ebpf go设计哲学 ceph学习 学习mesh kvm虚拟化 学习MQ go编译器 学习go 为什么要有堆栈 汇编语言 计算机组成原理 运行时和库 Prometheus client mysql 事务 mysql 事务的隔离级别 mysql 索引 坏味道 学习分布式 学习网络 学习Linux go 内存管理 golang 系统调用与阻塞处理 Goroutine 调度过程 重新认识cpu mosn有的没的 负载均衡泛谈 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go channel codereview gc分析 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes扩缩容 神经网络模型优化 直觉上理解深度学习 如何学习机器学习 TIDB源码分析 什么是云原生 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 副本一致性 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全访问机制 jvm crash分析 Prometheus 学习 Kubernetes监控 容器日志采集 Kubernetes 控制器模型 容器狂占资源怎么办？ Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes类型系统 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用？ 串一串一致性协议 当我在说PaaS时，我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言那些事儿 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 分布式计算系统的那些套路 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记 log4j学习 为什么netty比较难懂？ 回溯法 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 Scala的一些梗 OpenTSDB 入门 spring事务小结 分布式事务 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker namespace和cgroup Linux网络源代码学习——整体介绍 zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践（二） Thrift基本原理与实践（一） 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 Redis概述 深度学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring（八） 支持AOP 自己动手写spring（七） 类结构设计调整 分析log日志 自己动手写spring（六） 支持FactoryBean 自己动手写spring（九） 总结 自己动手写spring（五） bean的生命周期管理 自己动手写spring（四） 整合xml与注解方式 自己动手写spring（三） 支持注解方式 自己动手写spring（二） 创建一个bean工厂 自己动手写spring（一） 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM执行 git maven/ant/gradle使用 再看tcp kv系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go基础 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

tensorflow分布式训练 分布式训练 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 在离线业务混部 RNN pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 多活 volcano特性源码分析 推理服务 kubebuilder 学习 mpi 学习pytorch client-go学习 tensorflow学习 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台 tf-operator源码分析 k8s批处理调度 喜马拉雅容器化实践 Kubernetes 实践 学习rpc BFF 生命周期管理 openkruise学习 可观察性和监控系统 基于Kubernetes选主及应用 《许式伟的架构课》笔记 Kubernetes webhook 发布平台系统设计 k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 controller 组件介绍 openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的？ 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI 《推荐系统36式》笔记 资源调度泛谈 业务系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 serverless 泛谈 概率论 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 《聊聊架构》 书评的笔记 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念入门 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 用户登陆 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 当我在说模板引擎的时候，我在说什么 用户认证问题 资源的分配与回收——池 消息/任务队列

标签

Container 22

Concurrency 14

Life 40

Tool 9

Algorithm 8

JVM 10

Go 17

Kubernetes 48

Other 5

Network 15

Python 1

Java 20

Spring 17

Netty 10

Storage 20

Distribute 9

MQ 8

WEB 5

Linux 12

Scala 2

Code 9

MachineLearning 24

Practice 19

RPC 6

Compute 5

Architecture 24

DDD 4

Reactive 5

Basic 12

Product 3

Monitor 6

Mesh 11


可观察性和监控系统

2021年01月13日

简介

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

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

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

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

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

监控报警内在原因

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

  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. 谁开发，谁运维，谁监控

四种主要的监控方式

  1. Logging
  2. Tracing
  3. Metric
  4. Healthchecks

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

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

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

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

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

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

常见痛点及解决

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

  1. 质量观测的几个痛点：
    1. 海量的异构数据
    2. 依赖规则，缺乏智能
    3. 告警风暴与告警误报 无效告警优化实践总结
  2. 针对第一点，数据统一接入和管理，将这些异构的数据进行统一的存储和管理。将日志、指标、Trace等数据全部接入到一个统一的可观测性存储中。然后基于这个统一的存储，进行后续的查询分析、可视化、监控告警、AI 等上层能力，甚至还可以进行数据的加工和规整，一站式地完成异构数据到同构数据的转换过程。基于统一的存储，我们可以构建统一的查询和分析语法，从而一套语法适配不同的数据，并且让不同的数据之间进行联合查询也变成了可能。如下图所示，我们以标准 SQL 为基础，进行了部分 DSL 扩展和 SQL 函数扩展，并融合了 PromQL，从而让不同类型的数据查询和分析变得统一。
  3. 针对第二点，智能巡检。我们采用无监督学习算法，自动识别实体的数据特征，根据数据特征选取不同的算法组合，针对数据流实时建模，完成异常任务检测。并根据用户的打标信息（对告警进行确认或者误报反馈），训练监督模型，对算法进行不断优化，从而提高监控的准确率。目前异常检测我们使用了两种算法：
    1. 流式图算法，适用于一般性时间序列的异常检测场景，包括：机器级别的监控指标的异常巡检，例如CPU占用率、内存利用率、硬盘读写速率等。Time-Series Event Prediction with Evolutionary State Graph
    2. 流式分解算法，适用于对具有周期性的数据序列进行巡检，且要求数据的周期性较为明显。例如游戏的访问量、客户的订单量。RobustSTL: A Robust Seasonal-Trend Decomposition Algorithm for Long Time Series
  4. 针对第三点
    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 报表等)，需要根据业务形态和需求进行深度定制，复杂性较高，缺乏直接能用的工具和手段。

trace

分布式链路跟踪中的traceid和spanid代表什么？在分布式链路跟踪中有两个重要的概念：跟踪（trace）和 跨度（ span）。trace 是请求在分布式系统中的整个链路视图，span 则代表整个链路中不同服务内部的视图，span 组合在一起就是整个 trace 的视图。

  1. 在整个请求的调用链中，请求会一直携带 traceid（由客户端或网关生成） 往下游服务传递，每个服务内部也会生成自己的 spanid 用于生成自己的内部调用视图，并和traceid一起传递给下游服务。traceid 在请求的整个调用链中始终保持不变，所以在日志中可以通过 traceid 查询到整个请求期间系统记录下来的所有日志。
  2. 请求到达每个服务后，服务都会为请求生成spanid，而随请求一起从上游传过来的上游服务的 spanid 会被记录成parent-spanid或者叫 pspanid。当前服务生成的 spanid 随着请求一起再传到下游服务时，这个spanid 又会被下游服务当做 pspanid 记录。

在 A->B->C->D 的情况下，在整个调用链中，正常情况下会产生 3 个 Span，分别是 Span1（A->B）、Span2（B->C）、Span3（C->D），这时 Span3 的父 Span 就是 Span2，而 Span2 的父 Span 就是 Span1。

深入剖析全链路灰度技术内幕 未读

分布式链路追踪在字节跳动的实践 未读

其它

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

  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）。