友邦人寿可观测体系设计与落地

业务场景与挑战

友邦保险是香港联合交易所上市的人寿保险集团，覆盖 18 个市场。截至 2021 年 12 月 31 号，总资产 3400 亿美元。

友邦保险于 1992 年在上海设立分公司，是改革开放后最早一批获发个人人身保险业务营业执照的非本土保险机构之一，也是第一家将保险营销员制度引进国内的保险公司。2020 年 6 月，友邦获批将友邦保险有限公司上海分公司改建为友邦人寿保险有限公司。2020 年 7 月，友邦人寿正式成为中国内地首家外资独资人寿保险公司。友邦友享 App 在 2021 年荣获最佳保险科技平台。

业务特点和架构

为了践行友邦健康长久好生活的 slogan ，上云过程中我们对应用做了大量微服务化改造，以适应快速变化的业务要求和性能要求，并将此前在 AS400 里的 core 包程序做了微服务化改造，提高了可用时间。此外，我们采用了容器化方案，使应用运行在 K8s 上以获得弹性扩容能力和自愈能力。

上述改造导致了应用系统复杂度的提升，因此，观测微服务和 K8s 的运行成为了一大挑战。

与此同时，部分外采应用没有源码，不适合做微服务化改造，但我们仍然对这部分应用进行了容器化改造，将它们部署进 K8s；还有一部分应用由于各种原因，不适合上云改造，最终留在了 IDC 机房。因此，服务之间的调用会涉及云上到云下、云下到云上等复杂情况。

迁云之后实实在在为我们带来了 SLA 的提升，但也导致了访问链路和部署复杂度的提升，如何更好地观测应用成为了无法回避的挑战。

可观测性建设痛点和挑战

建设一个优秀的观测系统，会面临以下痛点：

观测复杂度提升：云原生微服务化虽然带来了很高的 HA，但也提升了系统的复杂度，加大了可观测的难度。核保通过率、交单成功率、用户的日活/月活散落在各个业务模块里，业务需要提供全局视角，以观察整个保单生命周期里重要业务节点的运行情况，并获取研发态的具体情况。
技术选型困难：由于历史原因，友邦内部应用技术选型不一，版本各异，导致可观测技术和调用链追踪面临很大的困难。
统一观测困难：友邦是一家金融公司，开发系统和应用运维完全分开，日志也完全分开存储和维护，因此无法将以上数据在同一个大盘里呈现。
指标治理：IaaS层、PaaS 层和应用层有很多指标，单数据库方面就可能有超过 200 多个指标。如果希望指标达到比较容易理解与追踪的数量，则需要不断地进行回顾、删减。
快速故障定位：在 IDC 机房时代，没有直观的方式让应用查看自己的资源是否足够。虽然已经有商业 APM 工具，但其价格高昂，不属于经济有效的方式。问题发生时，因为只有少量应用安装了 APM ，所以调用链不完整，无法实现快速故障定位。

可观测性建设流程和规划

可观测系统的建设主要分为调研分析、方案设计、改造实施和上线验证四个阶段。

一个优秀的可观测系统至少需要满足五个要求：

服务资源追踪：可以将服务运行节点上的 CPU 内存、网络磁盘、 IO 应用指标进行聚合。问题发生时，能够轻松观察到异常指标。
提供服务 Top 视图：按照服务的调用量、请求耗时、热点排名，应用可以很方便获知哪些是热点 API、哪些 API 请求量较高等，可以更好地规划自身的服务资源。
调用链追踪：关联服务上下游，并且最好是无侵入式，可以很方面地从 Trace关联到日志，获取到链路问题所在。
调用时长分布：观察服务的上游与下游，观察异步耗时，请求慢时可以很方便地判断是服务资源耗时还是依赖服务资源耗时。
数据库关联操作：帮助应用观察到 API 的关联 SQL、慢 SQL、 Redis 的查询存在慢 key 查询、Mongo 存在慢查询等操作。

实践与落地

可观测性整体设计思路

友邦为了满足业务发展需求，在技术层面需要做云原生技术架构的升级和改造。因此阿里云与友邦在应用容器化和可观测性上展开了深度合作。结合业务情况和监控痛点，通过几十次的讨论和推演，我们最终明确了两个重要建设思路：

首先，根据业务价值自上而下设计可观测体系。从业务监控、应用监控和资源监控一直向下推进。如果使用自下而上的设计方式，出现问题时团队会浪费大量时间和精力排查从来不会导致客户受影响的问题，或客户先于监控系统发现了问题。因此，需要最先关注和设计与用户体验、核心交易相关的业务监控。

其次，需要结合业务设计服务的链路追踪、应用性能监控。比如将某应用的 API 接口翻译成业务可读懂的语言，比如依靠保单生效的接口处理时间和处理数量以及接口还调用/依赖了其他哪些服务等来最终明确问题所在，最后结合应用诊断工具 Arthas、 JVM 的调优工具、应用日志以及资源级别的监控来确认是代码问题还是底层资源的使用问题。通过从确定事故发生再到定位引起事故的原因，进而确认问题本身来提升故障发现和问题定位能力。

确认了自上而下的可观测体系后，接下来需要明确可观测的指标范围。

全生命周期监控指标设计

可观测指标不仅是运行态，还需要包含研发态，形成应用全生命周期的监控指标体系。

系统经过云原生改造后，友邦的 CICD 流水线通过 Jenkins 进行自动化。为了提升软件的研发效率，需要抽象出可衡量的指标，比如应用每天的构建次数、构建时长、构建成功率、部署频率或部署成功率，以及形成这些指标的基础元数据信息等。

运行态分为系统层监控、应用层监控和业务层监控三层，监控重要性等级依次升高。资源监控层主要聚焦在 K8s 集群的 node 节点、磁盘网络、运行 Pod 监控、核心云产品等监控指标；应用层主要聚焦于应用的健康度、状态码、性能监控、JVM、GC 等性能指标上；业务层主要监控业务的核心指标，如 PV、UV、投保人数、投保金额、签单数等，它直接影响着监控系统设计的成败，因为这是最能够体现业务价值的部分。

可观测性架构大图

上图为友邦人寿可观测性体系的架构，总体设计思路分为三层：

第一层为采集层。因为要符合友邦的技术架构和建设需求，我们选择用 Java 编写流水线的 CICD 数据采集器。研发人员在使用 Jenkins 进行应用的 build 或 deploy 时，该采集器能将应用构建的数据和部署的数据全部存到数据库里。另外，采集数据时加上了相关联的 tag ，实现了元数据的共享。比如流水线构建的应用名称必须与 K8s 的服务名称一致，构建失败时即可快速找到出错的应用。

此外，针对应用的 APM 探针，社区一般使用字节码增强的无侵入技术。但是由于友邦架构的复杂度，Skywalking 探针无法完全覆盖友邦的场景。同时，友邦对于深度性能的诊断也有较高要求，希望能够集成阿里开源的 Arthas、 Memory dump 等能力，APM 探针也会影响应用性能，因此我们最终选择经过双 11 大规模检验的 ARMS Agent。

各类云产品中间件、集群的监控指标采集主要通过 Prometheus；应用日志主要使用 DaemonSet 的方式进行采集，相比于 Sidecar，其占用资源更少，工程上也更为简单。

第二层为存储层。研发态的元数据和 pipeline 的构建数据因其数据量不大，而且是结构化形态，因此存储在 MySQL 里。Metrics 监控指标的数据存储在阿里云的 Prometheus 产品上，日志和调用链 Tracing 数据存储在阿里云的 SLS 产品上。考虑到业务的增长，未来会产生大量的数据，这两款产品能够保证监控系统的稳定性、可扩展性和高可用性。同时，两款产品都是 Serverless 化持续按量付费，不存在磁盘或空间浪费。

第三层为统一展示层，通过 Grafana 进行汇聚和展示。当时阿里还未推出托管版的 Grafana，因此我们选择自建，推荐使用 8.0 以上的版本。为了保证运行的高可用，需要多实例部署，并将配置的数据统一传到数据库里，然后根据此前设计的监控指标，选择对应的数据源编写查询语句，最终结合 Grafana 丰富的图表进行统一展示。

业务监控的实现是通过将采集到 SLS 里的业务日志和应用日志做统计分析。SLS 的 SQL 查询功能非常丰富，语句编写也非常方便。再通过 SLS Grafana 插件集成到 Grafana 里，最终业务统计数据即可在 Grafana 大盘进行展示。