简介：互联网工程的高速倒退，分布式、微服务、容器化架构的风行，互联网已全面进入云原生时代。构建零碎的形式由最后的单体大利用演变为分布式架构，一台服务器可能仅存几小时甚至几分钟，这种复杂性大大增加了把零碎运行状态可视化的难度。
作者 | 京廊
起源 | 阿里技术公众号
一 写在后面
互联网工程的高速倒退，分布式、微服务、容器化架构的风行，互联网已全面进入云原生时代。构建零碎的形式由最后的单体大利用演变为分布式架构，一台服务器可能仅存几小时甚至几分钟，这种复杂性大大增加了把零碎运行状态可视化的难度。
高德打车业务的倒退历程也不例外，同样经验了从单体大利用到服务化拆分的过程，宏大的利用体系和架构的一直降级，保障了多个节假日出行顶峰的稳固，业务仍在继续疾速的倒退中，如何保障这套宏大又简单的零碎继续高性能、高可用、高可控？构建 360 度无死角的多维度可观测能力显得愈发重要。
二 谈零碎可观测性
1 什么是零碎可观测性
可观测性(observerbality)，是一个最近几年开始在监控社区流行起来的术语，可观测性的提出最早来自于 Google 驰名的 SRE 体系和 Apple 工程师 Cindy Sridharan 的博文《Monitoring and Oberservability》，感兴趣的同学能够看一下。
可观测性不是一种具体的工具或技术，更偏差于是一种理念，目前已成为简单分布式系统胜利治理的要害组成部分，它是指运行中的零碎可被调试的能力，这种可调试能力的外围就是可能在零碎运行时对其了解、询问、探查和调度。
了解，询问，探查体现在帮忙工程师发现问题 -> 定位问题 -> 解决问题(止损)，调度体现在可依据零碎运行状态做出的自动化，智能化决策的能力。
可观测性的指标是加强工程师对系统运行状况的理解，加强对系统的信念。
目前，业界宽泛推广的可观测性蕴含三大支柱：日志事件(Logging)，分布式链路追踪(Tracing) 和 指标监控(Metrics）。
- Logging：不能单纯的了解就是日志，泛指的是利用运行而产生的能够具体解释零碎运行状态的各种事件，日志记录是其中最罕用一种伎俩。
- Tracing：全链路追踪，面向的是申请，通过对申请打标、透传、串联，最终能够还原出一次残缺的申请，可帮忙工程师剖析出申请中的各种异样点。
- Metrics：是对 Logging 事件的聚合，泛指各种指标监控和大盘，通过多维度聚合、剖析和可视化展现，帮忙工程师疾速了解零碎的运行状态。
2 可观测性与监控的关系
可观测性 != 监控
第一印象很容易把“可观测性”认为就是“监控”，人类个别偏向于用之前的认知来了解一些新概念，其实两者是不一样的。
监控是机器代替人工，长期的察看零碎的行为和输入，帮忙团队察看和理解其零碎状态的工具或技术解决方案。监控与可观测性的区别如下：
关注点不同
监控更多关注的是具体指标的变动和报警，关注零碎的失败因素，多与运维相干，强调从外到内，从内部通过各种技术手段去看到外部，关注的是点。而可观测性关注的是利用自身的状态，是对系统的一种自我扫视，强调从内到外，站在宏观的角度去聚合剖析各种指标，不仅理解分布式系统所有链路的运行状况，还能在多指标同时产生问题时晓得什么是因，什么是果，让工程师“了解”零碎产生的所有行为，关注的是点线面的联合。
关注工夫不同
监控更加重视问题的发现与预警，关注软件交付过程中以及交付后的 1 到 2 天，也就是咱们常说的“事中与预先”。而“可观测性”是要对一个简单分布式系统所产生的所有行为给出正当解释，关注的是研发与运维的全生命周期。
目标不同
监控是通知咱们零碎在什么工夫、什么中央、产生了什么问题，仅提供对已知问题或故障的答案。而可观测性是为了通知咱们那里为什么产生了问题，还容许工程师提出新问题。具备可观测性的零碎，工程师既能够直观的察看到零碎的整体运行状态，又能够轻易深刻到零碎运行的各个细节角落。在失常运行时，能对系统进行评估，提供操作倡议，在产生故障时，可帮助工程师疾速了解、定位和修复问题。
监控与可观测性又是相辅相成的，监控是可观测性的一项基础设施和伎俩，监控是可观测性的子集，形象如下图：
三 咱们做了什么
分享下高德打车在摸索可观测性零碎建设过程中的一些具体实际，交流学习。
1 对立日志
首先对日志进行了对立治理，日志事件 (Logging) 是可观测性的三大支柱之一，当利用数上百，微服务数上千时，各利用的日志还任由开发人员依据本人爱好得心应手的打，可能会造成一场噩梦。例如形形色色的格局、级别、分类，甚至于 error 和 info 都混淆在一起。咱们将日志对立归为三类：监控日志，业务日志，谬误日志，并封装提供专门的日志 sdk，将“无效”的日志进行对立管控，还能间接达到管制老本的目标。
监控日志
监控日志只用来做监控，和其余日志进行辨别，输入到一个独自的滚动文件里。
监控的准则是用来发现问题，而不是用来定位问题，要定位具体的问题，须要更具体的日志，通过监控日志中的 traceId 去关联其余内容即可。
监控日志对立以 monitor 结尾，业务较多时，也可分多个，如 monitor-biz1.log, monitor-biz2.log。监控日志分隔符固定用竖线 | , 监控指标成功失败对立归类为 success，fail (业务失败)，error (接口失败)。耗时逻辑对立在 sdk 中实现，删除原代码中遍地存在的 long start=System.currentTimeMillis()。
对立监控日志还有另一个益处：当开发人员看到调用监控日志 api 的代码，会自然而然引起心田的器重，明确这是用来做监控的，我不能随便批改，防止不同开发人员合作时误改代码而导致监控谬误。
sdk 伪代码：
// 定义 key 值，标记起始工夫
MonitorLog mlog = MonitorLog.start("access", "url", "httpcode", "bizcode");
try {
//doSomeThing1...
// 标记 start 到 something1 做完后的工夫
mlog.addTimeScope("time1");
//doSomeThing2...
if ("胜利") {mlog.success(url, httpStatus, response_code);
} else {mlog.faild(url, httpStatus, response_code);
}
} catch (Exception e) {mlog.error(url, httpStatus, response_code);
}业务日志
这里的业务日志并不是指代码中开发人员随便打出的 log.info(…)，而是指专用于定位业务问题，依据本人的业务特点，通过认真布局，打出的须要对立收集、存储和剖析的业务相干的日志。
含要害信息，非关键信息，附加信息：
要害信息是业务流程中的重要标识，个别会建设查问索引，比方高德打车的订单 ID, 用户 ID 等。
非关键信息个别为业务日志形容，如“用户下单胜利”，非关键信息可不建索引。
附加信息个别为业务流程中的附加信息，如“订单状态”，“订单标记”等，可不建索引。
谬误日志
谬误日志也进行格局对立，不便对异样的全链路剖析和追踪。格局举例如下，如果某一项没有数据，会应用 ’-‘ 进行占位。
2 全链路追踪
分布式全链路追踪 (Tracing) 是可观测性的第二大支柱，全局惟一的 TraceId 利用阿里中间件鹰眼 Id 的现成解决方案实现，保障了在整个链路的唯一性，而后解决掉在分布式调用链路中，同步改异步失落 traceId 的问题，该 traceId 会同时在监控日志，服务日志，和谬误日志以及其余日志中透传并记录，traceId 继续的传下去，就是给整个申请链路打上了标记，链路上波及的所有利用日志收录到阿里云 SLS，接入阿里云 api，通过 api 拿到所有利用的日志，通过 TraceId 就能够还原这次申请的整个上下文。
市面上有很多 APM 厂商，监控社区也有很多开源的链路追踪零碎均可采纳。
3 监控治理
这一阶段我偏向于称作是对可观测零碎第三大支柱(Metrics) 的实现，是监控的梳理、补全优化阶段。“巧妇难为无米之炊”，如果根底监控项都笼罩不全，何谈可观测性。
这里我把监控归类为 5 个畛域，如图：
醒一下，监控体系建设没有银弹，任何值得解决的事件都须要为之付出致力，不要空想有一种工具能一下子解决你所有的监控问题。
再提一个监控建设的反模式“勾选式”监控。就是依照各种文档和要求，把各种监控工具都用上，而后就开始自嗨的认为本人的零碎就会强壮无比，居安思危，这就是典型的“勾选式”监控，为了应用而应用，不会有好的成果。
分类介绍下上图监控体系的 5 个畛域：
基础设施监控
首先是对于机器和操作系统环境的各项根底指标监控：cpu，mem，load，io，磁盘等，置信任何一个成熟的监控平台都会具备这项根底能力，不再赘述。
中间件监控
各种中间件的应用是分布式系统的重要元素，对于中间件的监控要遵循各个中间件的监控标准，举荐应用中间件本人的日志，指标模板等，不用反复造轮，口径对立也会缩小沟通老本。
利用 & 业务监控
利用监控对立演绎为申请量，耗时，成功率三类，称为三大黄金指标：
- 申请量，含 QPS、TPS、QPM、TPM 等，其中分钟级指标必备，秒级指标在外围链路中也是必备，秒级指标能够探查到刹时流量洪峰，在外围链路中是须要重点关注的。
- 耗时，不能只是均匀耗时，还有要 TP99，max 等，均匀耗时更多的是反馈一个趋势，开发人员必须要关注 TP99，只看均匀耗时会暗藏掉诸如毛刺等很多问题。
- 成功率，蕴含接口成功率和业务成功率，接口成功率即申请该接口失常返回即认为胜利，反映的是申请链路的问题。业务成功率是该接口的业务逻辑成功失败，反映的是业务的正确性，这是两个齐全不同的指标。谬误日志的监控，在此也归类到成功率的监控中，也是一个不可或缺的重要指标。
将利用监控的各项指标进行对立，一方面能够不便的查漏补缺，依照利用和接口 list，挨个查看，有则欠缺，无则补充，另一方面能够缩小沟通老本，不同的利用指标对立后，也升高了跨利用排查问题的复杂度和艰难度。
业务监控是不同开发同学基于本人的业务日志建设而来，应蕴含业务的量级监控，趋势监控，还有各种转化率，转化漏斗的监控，很多问题单靠量级和趋势是发现不了的。业务转化率和转化漏斗是绝对简单的逻辑，且此类数据的报表个别都是 BI 做的 T + 1 报表，及时性不够，短少实时的转化率和转化漏斗监控，会让咱们漏掉很多问题，问题发现时往往曾经过来很久，此类简单业务指标监控能够基于 flink 一类的流式计算来实现，即便做不到实时，能做到准实时，分钟级，小时级作用也是很大的，是对业务指标监控的重大晋升。
业务监控这里不得不提场景监控，不同场景流量的规模是齐全不同的。比方同一个微服务接口被不同的业务场景调用，只对接口级别的指标进行监控的话，流量小的场景谬误数量很容易被流量大的场景谬误量所吞没，在异样产生时，监控不报警，所以业务监控要做到针对场景的细分，能够领导咱们做精细化的管制。
资损监控
利用和业务监控指标失常，不代表服务就是失常的。数据的正确性校验，最终一致性校验，资金平安问题同样是很严厉的问题，很容易被疏忽。数据监控和资损防控能力也应是监控必备的能力，尤其是大促期间，上线各种促销补贴，促销流动和玩法，对资金平安提出更多挑战，避免用户 / 平台 / 服务商的资金损失，是对咱们服务的根本要求。波及数据核查，资损的防控个别都会波及多方，因为要多方对账，肯定要充沛沟通，重要的资金危险场景都要笼罩到，监控时效性做不到实时的话，准实时和离线小时级是要必备的。
监控大盘
有了各个利用精确的监控项做根底，还须要建设外围业务链路的监控大盘。大盘有技术指标维度的，还要有业务指标维度。大盘的指标摆放遵循：秒级指标，分钟级指标，成功率，上游依赖成功率，耗时，上游依赖耗时等。layout 提前设计，不能太宽松也不能太满，一行 2 - 3 个最好，趋势图和表格要共存，趋势图在数据源太多时展现同环比会很难看。
监控降噪
监控不能只是一味的减少，而不去保鲜，那是滥用，会产生很多恐怖的可能性。高德打车业务亦是如此，随着业务的倒退，新老监控达到肯定的量级，有些指标曾经年久失修，数据不准仍每天报警，钉钉音讯和短信数量爆炸，动辄未读 99+，曾经对工程师造成重大烦扰。
降噪的准则是每个报警项都应该是可执行的，报进去就是须要依附人的智慧来作出反应，而不应是机器人或脚本去主动回应。如果报警信息不能领导人的口头，就是乐音，节约精力去关注。
监控降噪有 2 方面内容：
- 一方面是报警数量爆炸，蕴含各种调试，压测的报警全都丢进去，导致工程师麻痹，不在意不关注，更重大的是大量无用的报警吞没了真正有问题的报警，导致故障产生，典型的“狼来了”！
- 另一方面是监控的名称和内容不精确，不置可否，用户不了解报出的问题是什么，对定位问题毫无帮忙，甚至造成困惑，贻误战机。
监控的名称语义要精确，见名知意，光看名字就能迅速晓得是哪块业务出的问题，节省时间，不便值班人员周知相干人员。特地是一些 url 类的监控，已知的 url 要尽可能用到翻译，很少有人记得清这个 url 是干什么的。
中间件类的监控项名称中最好蕴含中间件的名称、类型、以及利用或业务名等。如：中间件_RPC_生产者 / 消费者_类别(成功失败汇总 / 耗时 / 错误码等)_利用名。
告诉渠道
报警要有级别概念，依据指标外围水平，紧急水平，要辨别不同的渠道，高级别监控指标要有短信或电话报警，短信和电话报警不宜过多，紧急水平不能无脑 P0。
4 指标关联、拓扑、可视化
这一阶段我称作是对系统整体可观测能力的实现，目标是要能“了解”零碎的所有行为。
后面 3 点做完了，你可能还会遇到很多相似的难堪问题：监控零碎显示为“失常”，然而咱们的客服却一直收到客诉，甚至业务零碎曾经不能失常工作了，另外一种状况就是你曾经发现监控各种在报警，却没方法告知哪块业务会受到影响，哪里会不工作，在规模化微服务之后，你可能连宏观的关联关系都发现不了，更别谈对系统行为的“了解”。这就是在当今云原生时代下的大型分布式系统中，可观测性绝对于传统监控要解决的问题。
单纯的指标集监控可能会是一个不成体系的状态，在这种状态下，工程师掂量零碎的运行状态，多是靠一些零散指标，或是靠一些元老级工程师通过本人教训，从多个指标里含糊构建出业务全局状态，盲人摸象，是看不清全局的，而这些教训也往往是不可复用的。更正当的做法是站在创造者的角度去探索如何让零碎正确的展示本身的状态，通过技术手段建设系统监控的可观测性，既能从宏观角度去看一个申请的残缺链路，又能从宏观角度去剖析问题，“看清”零碎运行的全面状态，升高教训门槛和不确定性。
无效施行可观测性的第一要点就是要拆分指标，建设指标关联和拓扑，形式有很多，这里参考 OSM 数据分析模型法的形式，将监控指标分层进行拆解，细化到可落地执行的指标细项。
- 一级指标（次要为北极星指标）必须是全副认可、掂量业绩的外围指标。须要所有人了解、认同，且要易于沟通传播，比方下单量，完单量。
- 二级指标是北极星指标的门路指标。北极星指标发生变化的时候，咱们通过查看二级指标，可能疾速定位问题的起因所在。
- 三级指标是对二级指标的门路的剖析。通过三级指标，能够高效定位二级指标稳定的起因，这一步也会基于历史教训和拆解。
做监控指标的拆分并不是要求像 OSM 那样严格的依照 3 层去拆，只是借鉴一个理念，先整体的看业务全局，联合产品指标，业务链路，拆分出可执行，都认可的一级指标，以高德打车业务为例，最终定义出一级指标是下单，绑单，完单，领取：
对一级指标建设监控，建设量级和转化漏斗的多维度指标，如下单量，绑单量，下单量同环比，下单量趋势，业务转化漏斗绑单率，完单率，领取率等。
接下来抉择一级指标“完单量”为例，再持续进行二级指标的拆分，先剖析理清完单依赖的上游业务，通过趋势图和表格多种形式汇总展现。
上游依赖的二级指标拆分实现后，持续向下追溯，将上游依赖的外部依赖持续拆分，拆分出 3 层甚至 4 层更细粒度指标，指标持续拆分下钻，最底层可能就是各个依赖零碎的根底监控指标(cpu，mem，load，网络，宿主机等)。
指标关联和拓扑建设实现后，就要对指标履行可视化能力，采纳的形式多是一些监控大盘和图表，拓扑图等模式(监控大盘建设准则参考监控治理局部)。关联关系通过线、网、箭头交错在一起，再依据关联关系对链路流量进行染色，当相干指标产生报警时，就能够依据 trace 串联出残缺的调用链路，定位到相干的异样报警和业务影响。
可观测性监控问题排查过程
当监控具备了可观测性能力，就能够大大提高问题发现和定位的效率。排查起问题来就会变得像医生看病，由内到外，由宏观到宏观，通过 CT 等技术穿透身材各组织，将内外部整体的状况以图像的形式清晰展示，医生做出总体的诊断，中转病灶。
1）发现问题
当一级指标产生报警时，就是通知咱们，出问题了，这次以“下单”举例，比方收到了下单耗时减少的预警，开始接手去定位。
2）定位问题
如果一级监控指标下单产生了报警，那么它依赖的二级指标肯定会产生稳定。
比方下单的耗时 tp99 升高，察看下单依赖项，是下单依赖的二级指标“数据服务”耗时同期产生稳定。
要定位到最终起因，还需收集更多指标信息，持续下钻数据服务的上级指标，是利用数据库中间件 insert 耗时减少，排查后发现超时景象都产生在同一台服务器，持续跟踪该机器根底指标监控，该机器所在宿主机 load 升高导致，持续跟踪，是该宿主机网络设备呈现问题导致。
3）解决问题(止损)
问题定位后，对问题机器进行下线置换等伎俩，及时止损，耗时复原。
4）积淀预案
问题定位、解决实现之后，冀望把处理的教训积淀下来，这样就造成了预案，又多了一项保命符。
故障防御能力建设
当零碎的可观测性模型越来越粗疏，越来越准确，便能够催生出许多自动化，智能化的决策能力，辅助下层做出及时无效的决策，领导咱们做精细化的管制，解放人工生产力，这种能力我称之为故障防御能力，如图：
1）变更进攻策略编排
监控治理实现后，维度笼罩全面，就会多线上的各项变更纳入管控，这里将变更归类为业务类变更和运维类变更，具体如上图。针对不同的变更分类，能够指定不同的监控伎俩来防守，比方运维类的扩容、缩容，不波及到业务变更，在变更实现后，咱们只须要对 OS 指标监控，利用的指标监控进行核查即可。针对代码的变更，在公布部署后，除对根底的 os 指标，利用指标核对外，还须要对相干的业务指标进行核查，以及波及的资损指标监控。自定义各种编排策略，在不同分类的变更产生时，主动执行对应的监控伎俩。
2）变更管控
收录不同分类的变更，自动识别，主动打标，当产生变更时，能够获悉精确的工夫点，主动周知关注人。
3）实时巡检
对各项基础设施指标自动化巡检，及时发现问题，主动周知。
4）主动防御(故障主动定位)
当具备了可观测性，就有了全链路的关联追踪能力，产生故障时，把相干的变更、告警做剖析推导，主动给出根因举荐，还能够对一些外围指标做重保，当重保指标产生报警时及时作出问题举荐，产生解决工单，通过稳定性 AI 智能交互机器人继续跟进，可在钉钉群一键接手，造成处理闭环。对于可自行弥补的问题，主动执行弥补策略，故障自愈。
5）全域高精可观测性
所有的智能化决策能力，都是建设在零碎高精的可观测性根底之上，而可观测性，又是基于监控，日志，和全链路追踪三大支柱而来，最终造成无人值守故障防御能力。
四 写在最初
最初做一个小结，在云原生时代，运维自动化和智能化的大趋势中，零碎可观测性是稳定性建设的最根底一环，是稳定性保障武器库中的那把“霜之哀伤”，欠缺的可观测体系能够帮忙咱们屏蔽零碎的复杂性，使零碎整体的运行状态清晰可见，在故障进攻和排查方面施展了微小的作用，加强对系统的信念。
稳定性建设又是一个体系化的工程，不可能欲速不达，关键在于继续一直的欠缺，更脱离不了业务，高德打车业务的稳定性建设也是在业务一直倒退过程中逐渐摸索建设起来，2020 年多个节假日出行顶峰向咱们提供了最好的“练兵场”，“试金石”，零碎安稳度过。
当然稳定性建设的打法是多种多样的，但指标都是统一，心愿本文对大家有些许帮忙。
原文链接
本文为阿里云原创内容，未经容许不得转载。