共计 6612 个字符，预计需要花费 17 分钟才能阅读完成。
很多研发人员在日常工作中常常回遇到以下两个问题：居然不能够运行，为什么？居然能够运行，为什么？
因而，他们十分冀望可观测可能提供解决问题的思路。
引言
2017 年，推特工程师 Cindy 发表了一篇名为《Monitoring and Observability》的文章，首次将可观测性这一词汇带入开发者视线，通过半开玩笑的形式调侃了对于可观测性和监控的区别。在软件产品和服务畛域，监控可能告知咱们服务到底是否能失常运行，而可观测性能够通知咱们为为什么服务没有失常运行。
从谷歌趋势图中能够看到，可观测性的普及率出现逐年回升的态势，它也被视为零碎的属性，将逐渐成为零碎在做开发设计过程中就须要具备的个性。
可观测发展趋势
2020 年后，可观测的搜寻趋势呈现井喷，很大一部分起因是 SRE 站点可靠性工程逐渐遍及，国内大厂纷纷设立相干岗位和对应招聘指标，使得可观测性在国内也失去了较多关注。这也意味着越来越多的根底服务面临了稳定性挑战，而破解稳定性挑战的重要伎俩就在于提供可观测性。
上图左下角为可观测性的寰球搜寻趋势，其中中国的搜寻热度颇高。
可观测性定义
可观测性是由匈牙利工程师提出的一个数学概念，指零碎能够由内部输入推断其外部状态的水平。换句话说，可观测性该当能够从数据产出中剖析出其外部的具体运行细节。
难点与挑战
业务蓬勃发展 稳定性诉求激增
F6 汽车科技是一家专一于汽车后市场信息化建设的互联网平台公司，目前处于行业内头部地位。随着业务蓬勃发展，F6 反对的商户数目短时间内暴增数十倍，同时也逐渐发展了面向技师等 C 端场景的业务，比方 Vin 码解析、数据查问等，对于稳定性的要求显著进步。
康威定律的作用
康威定律是 IT 史上对整个组织架构进行微服务拆分的指导性定律。任何组织在设计零碎过程中都是组织架构的翻版，随着业务收缩，康威定律作用会导致设计微服务时拆分形式趋同于组织架构，业务增长会导致部门拆分，后续设计微服务时也会非常凑近组织架构。哪怕后期组织架构和微服务拆分不统一，前面微服务也会逐渐斗争于组织架构。
尽管微服务和组织架构趋同使得零碎沟通效率较高，然而这也带来了很多分布式的零碎问题。比方微服务之间的交互，没有人可能对服务有整体性、全局性的理解，研发人员最间接的冀望就是在分布式系统中也能有单机零碎的排查效率，这促使咱们须要将零碎以服务器为核心的思路转变为以调用链为核心的思路。
稳定性诉求激增
F6 最早进行业务开发时采纳烟囱式的建设。单体利用比较简单，然而它在扩展性和可维护性上存在很多问题。比方所有研发都在零碎上进行，代码抵触较多，什么工夫点能公布，发布会造成多少业务量损失等皆难以明确。因而，越来越多状况导致咱们须要进行微服务拆分，而微服务拆分和调用又会导致调用链十分复杂繁琐，如上图右所示，简直无奈人为剖析出调用链路。
那么，怎么样能力尽可能升高线上排查故障的难度？
可观测演进
传统监控 + 微利用日志收集
- ELKStack 获取日志和查问 ElastAlert 实现日志告警
传统的监控和微服务日志收集个别采纳 ELKStack 进行日志收集。ELK 是三个开源我的项目的首字母缩写，别离是 Elasticsearch、Logstash 和 Kibana。
咱们重度依赖 ELK 进行微服务日志的收集，与此同时，还应用了开源的基于 ES 的报警零碎 ElastAlert 组件，次要性能是从 ES 中查问出匹配规定，对相干类型数据进行报警。
上图形容了通过日志收集进行日常查问的思路。比方研发人员会通过 pipeling 查问线上日志，ElastAlert 通过匹配规定告警获取到 ES 日志中发掘出来异样数据，kibana 能够进行查问，也能够优先定位出零碎中产生的异样。
架构降级 + 可观测性引入
- Grafana 看板 +Zorka 反对 jvm 监控
随着业务倒退，系统对日志的要求也逐渐减少，比方团队十分多，须要配置各种各样的告警规定，因而咱们引入了 Grafana 逐渐代替 kibana 和 Zabbix 的查问性能。能够通过 Grafana 的 ES 插件查问对日志进行告警，而后通过 alert 性能实现原先 ElastAlert 的排除，同时能够应用 Grafana 做出更直观的可视化大屏进行展现。
除了日志外，咱们也冀望收集到 Java 利用指标，因而又引入了 Zorka 开源组件。Zorka 和 Zabbix 能够简略地进行联合，能够通过 Zorka 将收集到的信息上报给 Zabbix 进行展现。而 Zabbix 又能够通过 Grafana Zabbix 插件间接输入数据，最终将整个利用大屏和看板信息都收集到 Grafana 界面。
Zorka 的工作机制相似于通过 Zabbix Java gateway 的形式，通过 Java Agent 主动挂载到 Java 过程中，用于统计常见利用容器和申请数指标等，初步解决了咱们对于 Java 过程的观测需要。
云原生革新
- K8s 的编排能力和微服务相辅相成迫切需要 trace 组件的反对
随着微服务水平一直晋升，传统形式的运维老本越来越高，因而，咱们启动了云原生化革新。
首先，云原生化的革新是 K8s 侧就绪探针和存活探针的编写。存活探针的编写晋升了服务的自愈能力，呈现了 OOM 后服务可能主动复原、启动新节点，保障数据服务失常提供。除了 K8s 外，咱们还引入了 Prometheus 和 ARMS 利用监控。
Prometheus 作为 CNCF 仅次于 K8s 的 2 号我的项目，在整个 metrics 畛域造成了足够的话语权；ARMS 利用监控作为阿里云商业 APM 的拳头产品，使咱们可能联合云原生的形式，实现研发无感，无需进行任何代码改变即可领有 trace 性能。更重要的是，阿里云团队可能放弃继续迭代，反对越来越多中间件，因而咱们认为它必定会成为诊断利器。
- JmxExporter 疾速反对云原生 Java 组件的 jvm 信息展现
进行云原生化革新后，监控模型也产生了扭转。最早的监控模型是 push，Zorka 每次公布都在同一台机器上，因而它有固定的 host；而上云后，容器化革新导致 Pod 不再固定，且可能会呈现新的利用扩缩容等问题。因而，咱们将监控模型逐渐从 push 转换成 pull 模式，也更加符合 Prometheus 的收集模型，并逐渐将 Zorka 从可观测体系中剥离。
没有应用 ARMS 间接收集 JMX 指标是因为 ARMS 不会笼罩线上和线下所有 java 利用，没有被笼罩的利用也冀望有 JVM 数据收集性能，而 ARMS 老本略高。因而，出于老本的思考，咱们没有将 ARMS 作为残缺接入，而是抉择了 JMX Exporter 组件。
JMX Export 也是 Prometheus 官网社区提供的 exporter 之一。它通过 Java Agent 利用 Java JMX 机制读取 JVM 信息，能够将数据间接转化成为 Prometheus 能够辨识的 metrics 格局，使 Prometheus 可能对其进行监控和采集，并通过 Prometheus Operator 注册对应的 Service Moninor 实现指标收集。
- 利用配置核心实现利用到 owner 的精准告警
随着公司业务蓬勃发展，人员激增，微服务暴增，研发人数和告警也激烈增长。为了晋升告警触达率和响应率，咱们从新应用了 Apollo 配置核心的多语言 SDK，通过 Go 自研了一套基于 Apollo 业务的利用揭示，整体流程如下：
通过 Grafana 收集到 ES 告警或其余场景下的告警，再通过 metrics 利用关联到 alert，告警时会转发到前文提到的 Go 语言编写的精准告警服务上。精准告警服务解析到对应利用，依据利用从 Apollo 配置核心中获取到 owner 姓名、手机号等信息，再基于此信息通过钉钉进行告警，极大晋升了音讯浏览率。
- ARMS：无侵入反对 Trace**\
此外，咱们还引入了阿里云的利用实时监控服务 ARMS，可能在没有任何代码革新的前提下，反对绝大部分中间件和框架，比方 Kafka、MySQL、Dubbo 等。云原生化后，仅须要在 deployment 里增加注解即可反对相干探针的加载，微服务的可维护性极为敌对。同时，还提供了较为残缺的 trace 视图，能够查看线上利用节点调用日志的整个 trace 链路，也提供了甘特图的查看形式和依赖拓扑图、上下游耗时图等数据。
可观测降级
- Log Trace Metrics 理念降级
可观测在国内微服务畛域已遍地开花。因而，F6 公司也降级了可观测思路。业界宽泛推广的可观测性蕴含三大支柱，别离是日志事件、分布式链路追踪以及指标监控。任何时代都须要监控，然而它曾经不再是外围需要。上图能够看出，监控仅蕴含告警和利用概览，而事实上可观测性还需包含排错分析以及依赖剖析。
最早的监控性能应用主体是运维人员，但运维人员大多只能解决零碎服务告警。而回升到整个微服务畛域，更多问题可能呈现在利用之间，须要进行问题排障。比方服务呈现了慢申请，有可能是因为代码问题，也可能因为锁或线程池有余，或连接数不够等，以上种种问题最终体现进去的特色是慢和服务无奈响应。而如此多的可能性，须要通过可观测性能力定位到真正根因。然而，定位根因并非实在需要，实在需要更多的是利用可观测性剖析出问题所处节点，而后通过替换对应组件、进行熔断或限流等措施，尽可能晋升整体 SLA。
可观测性还能够很好的分析问题，比方线上服务慢，能够观测其每个节点的耗时、每个申请中的耗时等。依赖剖析也能够失去解决，比方服务依赖是否正当、服务依赖调用链路是否失常等。
随着利用越来越多，对于可观测性和稳定性的诉求也越来越多。因而，咱们自研了一套简略的根因剖析零碎，通过文本类似度算法将以后服务日志进行归类聚类分析。
- 简版根因剖析上线
上图为典型 ONS 故障，依赖服务进行服务降级。如果这是通过日志抓取智能剖析进去的日志，做了很长时间 SRE 后，变更也会对于线上稳定性造成很大毁坏。如果能将变更等也收集到可观测体系中，将会带来很大益处。同理，如果能将 ONS 要降级的信息收集到可观测体零碎中，通过种种事件关联，可能剖析出根因，对于零碎稳定性和问题排查将极为无益。
- **ARMS 反对 traceId 透出 responseHeader
F6 公司和 ARMS 团队也进行了深刻单干，摸索了可观测的最佳实际。ARMS 近期退出了一项新性能，将 traceID 间接透出到 HTTP 头，能够在接入层日志中将它输入到对应日志，通过 Kibana 进行检索。
客户在产生故障时，将日志信息和 traceID 一起上报给技术支持人员，最初研发人员可通过 traceID 疾速定位到问题起因、上下游链路，因为 traceID 在整个调用链路中是惟一的，非常适合作为检索条件。
同时，ARMS 反对间接通过 MDC 透传 traceID，反对 Java 支流日志框架，包含 Logback、Log4j、Log4j2 等，也能够将 traceID 作为规范 Python 输入。
上图展现了典型的日志输入场景下 ARMS 的后盾配置，能够关上关联业务日志和 traceID，反对各种各样的组件，只需在日志零碎中定义 eagleeye_traceid 即可输入 traceID。
上述计划较为简单，研发的批改也很少，甚至能够做到免批改，且对于 Loggin 和 Trace 的关联水平做到了较大晋升，缩小了数据孤岛。
- ARMS 反对运维告警平台
ARMS 为进一步升高 MTTR，提供了很多数据，然而数据如何达到 SRE、DevOps 或研发运维人员手里，仍然须要破费一些心理。
因而，ARMS 上线了运维告警平台，通过可视化形式实现了告警转发、分流等事件处理，能够通过静默性能、分组等，反对多种集成形式。目前 F6 在用的包含 Prometheus、buffalo、ARMS 以及云监控，其中云监控蕴含了包含 ONS、Redis 在内的很多数据，研发人员或 SRE 人员在钉钉群里认领对应的响应事件即可。同时还反对报表、定时揭示、事件降级等性能，便于预先复盘和改善。
上图为线上解决问题的界面截图。比方钉钉群里的告警会提醒上一次类似告警由谁解决、告警列表以及对应事件处理流程等。同时，还提供了过滤性能，能够宰割内容，通过字段丰盛或匹配更新等形式替换内容填充模板，用于精准告警，比方辨认到利用名称后，能够关联到对应利用的 owner 或告警人员。此性能后续也将逐渐代替前文用 Go 语言写的 Apollo SDK 利用。
- Java 生态免批改注入 agent 形式 -JAVA_TOOL_OPTIONS
同时，咱们也借鉴了 ARMS 免批改注入 Agent 的形式。ARMS 通过 one point initContainer 的形式注入了很多 ARMS 信息，也挂载了一个名为 home/admin/.opt 的 mount 用于存储日志。正因为有 initContainer，它才可能实现主动降级。
在 initContainer 中，能够通过调用 ARMS 接口获取到以后 ARMS Agent 最新版本，而后下载 Java Agent 最新版本，放到 mount 目录下，与目录下对应的数组 Pod 进行通信，通过共享 volume 的形式实现 Java Agent 共享。过程中最外围的点在于，通过 JAVA_TOOL_OPTIONS 实现了 Java Agent 挂载。
通过上述形式，咱们模仿了一套流程，通过 openkruise 组件 workspread 应用 patch 形式批改 deployment。最简略的实际是利用 openkruise workspread 给对应的 deployment 打注解，从而使得无需由研发或 SRE 团队进行解决，只有编写对应 CRD 即可，CRD 过程间接注入 JAVA_TOOL_OPTIONS（见上图右下角代码）。其利用场景也较为丰盛，能够做利用流量回放、自动化测试等。
- Prometheus Exporter
除了 ARMS 等商业化产品外，咱们也踊跃开源，拥抱 Prometheus 社区，接入了较多 Exporter 组件，包含 SSLExport 和 BlackBoxExporter，极大晋升了整个零碎的可观测性。Exporter 能够用于黑盒探针，比方探测 HTTP 申请是否失常、HTTPS 申请是否正、DNS 是否失常、TCP 是否失常等，典型的应用场景是探测以后服务入口地址是否失常。SSL 证书异样更为常见，通过 SSLExporter 能够定期轮询证书是否过期，进一步晋升可观测性。
- 老本观测
除了日常服务可观测，咱们还实际了老本可观测等优化我的项目。对于云原生环境，能够利用 kubecost 开源组件进行老本优化，间接输入资源使用率以及报表等，反馈给研发人员进行优化，甚至能够用来发现 CPU 和内存是否呈失常比例，尽可能实现资源正当调配。
将来畅想
基于 eBPF 的 Kuberneters 一站式可观测性
eBPF 云原生组件愈发进入到深水区，很多问题不再只停留于利用层面，更多地会呈现在零碎层面和网络层面，须要更加底层的数据进行追踪和排障。利用 eBPF 能够更好地答复 Google SRE 提出的比方提早、流量、错误率、饱和度等黄金指标呈现的问题。
比方 Redis 进行闪断切换的过程中，可能会造成 TCP 半开连贯，从而对业务产生影响；再比方 TCP 连贯刚建设时，backlog 是否正当等，都能够通过数据失去相应论断。
Chaos-engineering
Chaos-engineering 混沌工程激励和利用可观测性，试图帮忙用户后发制人地发现和克服零碎弱点。2020 年 6 月，CNCF 针对可观测性提出了特地兴趣小组。除了三大支柱外，CNCF 还提出了混沌工程和继续优化。
对于混沌工程是否能划分在可观测性里，以后社区仍然存在疑议，而 CNCF 的可观测性特地兴趣小组里已蕴含了 chaos-engineering 和继续优化。咱们认为，CNCF 的做法有肯定情理，混沌工程能够被认为是一种可观测性的剖析工具，但其重要前提是可观测性。试想，如果在施行混沌工程过程中产生故障，咱们甚至都无奈确定它是否由混沌工程引起，这也将带来极大麻烦。
因而，能够利用可观测性尽可能放大爆炸半径、定位问题，通过 chaos-engineering 继续优化零碎，提前发现零碎薄弱点，更好地为零碎稳定性保驾护航。
OpenTelemetry
OpenTelemetry 是一个通过多个我的项目合并而来的开源框架。咱们须要更加面向终端研发对立的可观测性视图，比方冀望将 logging、metrics 和 tracing 数据进行相互关联打标，尽可能减少数据孤岛，通过多数据源的关联晋升整体可观测性。并利用可观测性尽可能缩短线上故障排查工夫，为业务服务复原争取时间。
理解更多可观测产品详情，点击此处！
