作者：祁晓波
很多研发人员在日常工作中经常回遇到以下两个问题：竟然不可以运行，为什么？竟然可以运行，为什么？
因此，他们非常期望可观测能够提供解决问题的思路。
2017年，推特工程师Cindy发表了一篇名为《Monitoring and Observability》的文章，首次将可观测性这一词汇带入开发者视野，通过半开玩笑的方式调侃了关于可观测性和监控的区别。在软件产品和服务领域，监控能够告知我们服务究竟是否能正常运行，而可观测性可以告诉我们为为什么服务没有正常运行。
从谷歌趋势图中可以看到，可观测性的普及率呈现逐年上升的态势，它也被视为系统的属性，将逐步成为系统在做开发设计过程中就需要具备的特性。
2020年后，可观测的搜索趋势出现井喷，很大一部分原因是SRE站点可靠性工程逐步普及，国内大厂纷纷设立相关岗位和对应招聘指标，使得可观测性在国内也得到了较多关注。这也意味着越来越多的基础服务面临了稳定性挑战，而破解稳定性挑战的重要手段就在于提供可观测性。
上图左下角为可观测性的全球搜索趋势，其中中国的搜索热度颇高。
可观测性是由匈牙利工程师提出的一个数学概念，指系统可以由外部输出推断其内部状态的程度。换句话说，可观测性应当可以从数据产出中分析出其内部的具体运转细节。
1. 难点与挑战
F6汽车科技是一家专注于汽车后市场信息化建设的互联网平台公司，目前处于行业内头部位置。随着业务蓬勃发展，F6支持的商户数目短时间内暴增数十倍，同时也逐步开展了面向技师等C端场景的业务，比如Vin码解析、数据查询等，对于稳定性的要求显著提高。
康威定律是IT史上对整个组织架构进行微服务拆分的指导性定律。任何组织在设计系统过程中都是组织架构的翻版，随着业务膨胀，康威定律作用会导致设计微服务时拆分方式趋同于组织架构，业务增长会导致部门拆分，后续设计微服务时也会十分靠近组织架构。哪怕前期组织架构和微服务拆分不一致，后面微服务也会逐步妥协于组织架构。
虽然微服务和组织架构趋同使得系统沟通效率较高，但是这也带来了很多分布式的系统问题。比如微服务之间的交互，没有人能够对服务有整体性、全局性的了解，研发人员最直接的期望就是在分布式系统中也能有单机系统的排查效率，这促使我们需要将系统以服务器为中心的思路转变为以调用链为中心的思路。
F6最早进行业务开发时采用烟囱式的建设。单体应用比较简单，但是它在扩展性和可维护性上存在很多问题。比如所有研发都在系统上进行，代码冲突较多，什么时间点能发布，发布会造成多少业务量损失等皆难以明确。因此，越来越多情况导致我们需要进行微服务拆分，而微服务拆分和调用又会导致调用链十分复杂繁琐，如上图右所示，几乎无法人为分析出调用链路。
那么，怎么样才能尽可能降低线上排查故障的难度？
2. 可观测演进
传统的监控和微服务日志收集一般采用ELKStack进行日志收集。ELK是三个开源项目的首字母缩写，分别是Elasticsearch、Logstash和Kibana。
我们重度依赖ELK进行微服务日志的收集，与此同时，还使用了开源的基于ES的报警系统ElastAlert组件，主要功能是从ES中查询出匹配规则，对相关类型数据进行报警。
上图描述了通过日志收集进行日常查询的思路。比如研发人员会通过pipeling查询线上日志，ElastAlert通过匹配规则告警获取到ES日志中发掘出来异常数据，kibana可以进行查询，也可以优先定位出系统中发生的异常。
随着业务发展，系统对日志的要求也逐步增加，比如团队非常多，需要配置各种各样的告警规则，因此我们引入了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侧就绪探针和存活探针的编写。存活探针的编写提升了服务的自愈能力，出现了 OOM 后服务能够自动恢复、启动新节点，保证数据服务正常提供。
除了K8s外，我们还引入了Prometheus和ARMS应用监控。Prometheus作为CNCF仅次于K8s的2号项目，在整个metrics领域形成了足够的话语权；ARMS应用监控作为阿里云商业APM的拳头产品，使我们能够结合云原生的方式，实现研发无感，无需进行任何代码改动即可拥有trace功能。更重要的是，阿里云团队能够保持持续迭代，支持越来越多中间件，因此我们认为它必定会成为诊断利器。
进行云原生化改造后，监控模型也发生了改变。最早的监控模型是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完成指标收集。
接下篇：https://developer.aliyun.com/article/1222699?groupCode=alisoftwaretech
