很多研发人员在日常工作中经常会遇到以下两个问题：跑不起来，为什么？它有效，为什么？因此，他们非常期待可观察性能够为解决问题提供思路。介绍2017年，Twitter工程师Cindy发表了一篇名为《Monitoring and Observability》的文章，首次将可观察性这个词带入了开发者的视野，半开玩笑地调侃了可观察性和监控的区别。在软件产品和服务的世界里，监控可以告诉我们一个服务是否正常工作，而可观察性可以告诉我们服务为什么不能正常工作。从谷歌趋势图可以看出，可观察性的渗透率逐年上升。它也被视为系统的一个属性，将逐渐成为系统在开发设计过程中需要具备的特性。可观察的发展趋势2020年后，可观察的搜索趋势将爆发。很大一部分原因是SRE站点可靠性工程逐渐普及。国内各大厂商都设置了相关岗位和相应的招聘指标，让可观察性在国内大行其道。更多的关注。这也意味着越来越多的基础服务面临稳定性挑战，而应对稳定性挑战的重要手段就是提供可观察性。上图左下角显示了observability的全球搜索趋势，其中在中国的搜索热度相当高。可观察性定义可观察性是匈牙利工程师提出的一个数学概念，指的是系统可以从外部输出推断出其内部状态的程度。换句话说，可观察性应该能够从数据输出中分析出具体的内部运行细节。困难与挑战业务蒸蒸日上，稳定需求激增。F6汽车科技是一家专注于汽车后市场信息化建设的互联网平台公司，目前处于行业领先地位。随着业务的蓬勃发展，F6支持的商户数量在短时间内增长了数十倍。同时，也逐步推出面向技术人员等C端场景的服务，如Vin码分析、数据查询等，对稳定性的要求明显提高。康威定律的作用康威定律是IT史上整个组织架构微服务拆分的指导法则。任何组织都是系统设计过程中组织结构的复制。随着业务的扩大，康威定律的作用会导致设计微服务的拆分方式在组织结构上趋于收敛。业务增长将导致部门分裂。后面设计微服务的时候，也会跟组织架构很接近。即使前期的组织架构与微服务的拆分不一致，但未来微服务也会在组织架构上逐渐妥协。微服务和组织结构的融合虽然让系统通信更加高效，但是也带来了很多分布式系统的问题。例如，在微服务之间的交互中，没有人能够对服务有一个整体的、全局的理解。研发人员最直接的期望就是在分布式系统中有单机系统的排错效率，这促使我们在系统集成上以服务器为中心的思路转变为以调用链为中心的思路。稳健需求激增F6在刚开始业务发展时采用了烟囱式结构。单体应用相对简单，但在可扩展性和可维护性方面存在很多问题。比如所有的研发都在系统上进行，代码冲突很多，很难知道什么时候发布，发布会会造成多少业务损失。因此，越来越多的情况导致我们对微服务进行拆分，而微服务的拆分和调用会导致调用链非常复杂繁琐。如上图右侧所示，人为分析调用链几乎是不可能的。那么，如何才能最大程度地降低在线排错的难度呢？Observable进化传统监控+微应用日志采集ELKStack获取日志，查询ElastAlert完成日志告警传统监控和微服务日志采集一般使用ELKStack进行日志采集。ELK是三个开源项目的首字母缩写，分别是Elasticsearch、Logstash和Kibana。我们非常依赖ELK来收集微服务日志。同时，我们还使用了开源的基于ES的报警系统ElastAlert组件。主要功能是从ES和告警相关类型的数据中查询匹配规则。上图描述了通过日志采集进行日常查询的思路。比如研发人员会通过管道查询线上日志，ElastAlert可以通过匹配规则告警获取ES日志中发现的异常数据。Kibana可以进行查询，也可以优先定位系统发生的异常。架构升级+可观察性引入Grafana看板+Zorka支持jvm监控随着业务的发展，系统对日志的要求也逐渐提高。比如团队比较多，需要配置各种告警规则，所以我们引入了Grafana来逐步替代kibana和Zabbix的Query功能。可以使用Grafana的ES插件对日志进行查询和告警，然后使用告警功能完成原有的ElastAlert排除。同时可以使用Grafana做更直观的可视化大屏展示。除了日志，我们还期望收集Java应用程序指标，因此我们引入了Zorka开源组件。Zorka和Zabbix可以很方便的结合，收集到的信息可以通过Zorka上报给Zabbix进行展示。而Zabbix可以直接通过GrafanaZabbix插件输出数据，最终将整个应用屏幕和看板信息收集到Grafana接口。Zorka的工作机制类似于ZabbixJava网关，通过JavaAgent自动挂载到Java进程中，用于统计常见的应用容器和请求数指标等，初步解决了我们对Java的观察需求过程。云原生转型K8s的编排能力与微服务相辅相成，急需Trace组件的支持。随着微服务的不断完善，传统运维的成本越来越高。因此，我们启动了云原生转型。首先云原生化的改造就是K8ssidereadinessprobe和survivalprobe的编写。生存探针的编写提高了服务的自愈能力。OOM发生后，服务可以自动恢复并启动新的节点，保证数据服务的正常提供。除了K8s，我们还引入了Prometheus和ARMS应用监控。Prometheus作为CNCF继K8s之后的第二号项目，在整个metrics领域已经形成了足够的话语权；ARMS应用监控作为阿里云商用APM的旗舰产品，让我们可以无感的结合云原生的方式实现研发。进行任何代码更改以具有跟踪功能。更重要的是，阿里云团队可以保持持续迭代，支持越来越多的中间件，所以我们认为它一定会成为一个诊断工具。JmxExporter快速支持云原生Java组件的jvm信息展示。云原生转型后，监控模型也发生了变化。最早的监控模型是push。Zorka每次都是在同一台机器上发布，所以它有一个固定的主机；上云后，容器化改造使得Pod不再固定不变，可能会出现新的应用扩缩容。问题。因此，我们逐渐将监控模型由push转为pull模式，更符合Prometheus的采集模型，逐步将Zorka从可观察系统中分离出来。之所以不使用ARMS直接采集JMX指标，是因为ARMS并没有覆盖所有线上线下的java应用，没有覆盖的应用也期望有JVM数据采集功能，而ARMS成本稍高。因此，出于成本考虑，我们没有使用ARMS作为完整的接入，而是选择了JMXExporter组件。JMXExport也是Prometheus官方社区提供的出口商之一。它使用JavaJMX机制，通过JavaAgent读取JVM信息，可以直接将数据转换成Prometheus可以识别的metrics格式，以便Prometheus进行监控和收集，并通过PrometheusOperator注册对应的ServiceMoninor来完成指标收集。通过配置中心完成对业主的精准报警。随着公司业务的快速发展，人员数量和微服务数量激增，研发人员数量和告警数量也急剧增加。为了提高告警到达率和响应率，我们复用了Apollo配置中心的多语言SDK，通过Go自主开发了一套基于Apollo业务的应用提醒。整体流程如下：通过Grafana采集ES告警或者其他场景的告警通过metrics应用连接到alert，告警将转发到上面提到的用Go语言编写的精准告警服务。精准报警服务解析到对应的应用，根据应用从Apollo配置中心获取机主姓名、手机号等信息，然后根据这些信息通过钉钉发送报警，大大提高消息阅读率。ARMS：非侵入式支持Trace此外，我们还介绍了阿里云的实时应用监控服务ARMS，无需任何代码修改即可支持绝大部分中间件和框架，如Kafka、MySQL、Dubbo等。云原生后，只需要在部署中添加注解即可支持相关探针的加载，微服务的可维护性极其友好。同时也提供了比较完整的trace视图，让你查看在线应用节点调用日志的整个trace链接，还提供了甘特图查看方法、依赖拓扑图、上下游耗时图和其他数据。Observable升级LogTraceMetricsObservable的概念升级在国内微服务领域遍地开花。因此，F6也对可观察性思维进行了升级。业界广泛推广的可观测性包括三大支柱，即日志事件、分布式链路追踪和指标监控。任何时代都需要监控，但监控不再是核心需求。从上图可以看出，监控只包括告警和应用概览，其实可观察性还包括故障分析和依赖分析。监控功能最早的使用者是运维人员，但大多数运维人员只能处理系统服务告警。当上升到整个微服务领域，应用之间可能会出现更多的问题，需要排查问题。比如某个服务请求慢，可能是代码问题，也可能是锁或线程池不足，连接数不足等。有这么多的可能性，真正的根本原因需要通过可观察性来定位。但是，查找根本原因并不是真正的要求。真正的需求更多的是利用可观察性来分析问题所在的节点，然后更换相应的组件，熔断或者限流，尽可能的提升整体的SLA。可观察性也可以很好的分析问题，比如在线服务慢，可以观察每个节点的耗时，每个请求的耗时。依赖分析也可以解决，比如服务依赖是否合理，服务依赖调用链路是否正常等。随着应用越来越多，对可观察性和稳定性的需求也越来越多。因此，我们开发了一个简单的根因分析系统，通过文本相似度算法对当前的服务日志进行分类和聚类。简化根本原因分析上图是一个典型的ONS故障，依赖于业务进行业务升级。如果这是通过日志抓取智能分析的日志，经过长时间的SRE，变更也会对线上稳定性造成很大的损害。如果更改等也可以收集到可观察系统中，那将是非常有益的。同理，如果能将ONS要升级的信息收集到可观察系统中，通过各种事件关联分析出根本原因，对于系统的稳定性和故障排除都极为有利。ARMS支持通过responseHeaderF6暴露traceId公司和ARMS团队也深度合作探索可观察性最佳实践。ARMS最近撤回了一个新特性，将traceID直接暴露在HTTPheader中，可以输出到访问层日志中对应的日志，通过Kibana获取。当出现故障时，客户会将日志信息和traceID上报给技术支持人员。最后，研发人员可以通过traceID快速定位问题原因和上下游环节，因为traceID在整个调用链中是唯一的，非常适合作为Search条件。同时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人员可以在钉钉群中申领相应的响应事件。同时还支持报表、定时提醒、事件升级等功能，方便事件后的回顾和改进。上图为在线解题界面截图。比如钉钉群里的告警，会提示最近一次类似告警的处理者，告警列表，以及对应的事件处理流程。同时还提供过滤功能，可以对内容进行划分，通过字段丰富或者匹配更新等方式替换内容填充模板，进行精准告警，比如识别应用名称后，可以与相应应用程序的所有者或报警人员相关联。该功能将逐步替代之前使用Go语言编写的ApolloSDK应用。Java生态免修改注入代理方法-JAVA_TOOL_OPTIONS同时我们也借鉴了ARMS免修改注入代理方法。ARMS通过一点initContainer注入大量的ARMS信息，同时还挂载了一个名为home/admin/.opt的挂载来存放日志。正是因为有initContainer，才可以自动升级。在initContainer中，可以通过调用ARMS接口获取当前ARMSAgent的最新版本，然后下载最新版本的JavaAgent，放到挂载目录下，与目录下对应的数组Pod通信，完成JavaAgent共享通过共享卷。流程中的核心点是通过JAVA_TOOL_OPTIONS挂载了JavaAgent。通过上面的方法，我们模拟了一组流程，通过openkruisecomponentworkspread，使用patch的方式修改deployment。最简单的做法是使用openkruiseworkspread注解对应的deployment，这样就不需要R&D或者SRE团队处理，只需要写对应的CRD，CRD过程直接注入JAVA_TOOL_OPTIONS（见代码上图右下角）。其应用场景也比较丰富，可用于应用流量回放和自动化测试。除了ARMS等商业产品，PrometheusExporter也在积极开源，拥抱Prometheus社区，接入更多的Exporter组件，包括SSLExport和BlackBoxExporter，大大提高了整个系统的可观察性。Exporter可用于黑盒探测，比如检测HTTP请求是否正常，HTTPS请求是否正常，DNS是否正常，TCP是否正常等，典型的使用场景是检测当前服务入口地址是否正常是正常的。SSL证书异常比较常见，SSLExporter可以周期性轮询证书是否过期，进一步提高可观察性。CostObservation除了日常的服务可观察性，我们还实践了成本可观察性等优化项目。针对云原生环境，可以使用kubecost开源组件进行成本优化，直接输出资源使用情况和报告等，反馈给研发人员进行优化。甚至可以用来判断CPU和内存的比例是否正常，从而尽可能实现资源的合理分配。畅想未来基于eBPF的Kubernetes一站式可观察性eBPF云原生组件越来越多地进入深水区。很多问题不再只停留在应用层面，更多的出现在系统层面和网络层面，需要更底层的数据进行跟踪和排查。使用eBPF可以更好的回答GoogleSRE提出的延迟、流量、错误率、饱和度等黄金指标问题。比如Redis在flash切换过程中，可能形成TCP半开连接，影响业务；比如TCP连接刚建立的时候，积压是否合理等等，都可以从数据中得到。相应的结论。Chaos-engineeringChaos-engineering混沌工程鼓励并利用可观察性，试图帮助用户先发制人地发现和克服系统弱点。2020年6月，CNCF提出了可观测性特别兴趣小组。除了三大支柱，CNCF还提出了混沌工程和持续优化。目前社区对混沌工程是否可以划分为可观察性仍有疑问，CNCF的可观察性特别兴趣组已经将混沌工程和持续优化纳入其中。我们认为CNCF的做法是有道理的。混沌工程可以认为是一种可观测性分析工具，但其重要前提是可观测性。试想一下，如果在混沌工程的实施过程中出现了故障，我们甚至无法确定是不是混沌工程造成的，同样会造成很大的麻烦。因此，可以利用可观测性最小化爆炸半径，定位问题，通过混沌工程持续优化系统，提前发现系统弱点，更好地保障系统稳定性。OpenTelemetryOpenTelemetry是一个开源框架，由多个项目合并而来。我们需要开发一个更面向终端的统一的可观察性视图。例如，我们希望通过关联多个数据源来关联和标记日志记录、指标和跟踪数据，以最大限度地减少数据孤岛并提高整体可观察性。并利用可观察性，尽可能缩短线上故障排查时间，为业务服务恢复争取时间。
