关于阿里云:友邦人寿可观测体系设计与落地

作者：沈斌、右京

业务场景与挑战

友邦保险是香港联结交易所上市的人寿保险团体，笼罩 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 大盘进行展现。

对立监控平台

上图为建设成绩。通过大屏、中屏和小屏的形式造成指挥决策、研发仪表盘&利用性能展现以及告警推送、多维度的监控能力。

其中左侧大屏展现外围指标，比方容器集群的资源利用率、service Pod 衰弱度以及联通性等通用指标，为公司决策提供反对。

右上方中屏次要展现流水线的研发效率指标、利用性能的指标以及全局调用链，帮忙研发人员晋升效率和问题定位的速度。

右下方小屏通过历史数据的比照，设置了报警阀值。出现异常时，通过钉钉或短信报警的形式推送到电脑、手机终端，帮忙运维人员及时发现和解决问题。

对于可观测性咨询服务

点击此处 ，理解更多产品详情！