作者：
沈斌，CloudSolution-云应用架构负责人
右京，阿里云GTS-交付技术部交付专家，云原生布道师、爱好者、实践者
友邦保险是香港联合交易所上市的人寿保险集团，覆盖18个市场。截至2021年12月31号，总资产3400亿美元。
友邦保险于1992年在上海设立分公司，是改革开放后最早一批获发个人人身保险业务营业执照的非本土保险机构之一，也是第一家将保险营销员制度引进国内的保险公司。2020年6月，友邦获批将友邦保险有限公司上海分公司改建为友邦人寿保险有限公司。2020年7月，友邦人寿正式成为中国内地首家外资独资人寿保险公司。友邦友享App在2021年荣获最佳保险科技平台。
保险业务流程异常复杂，需要银行利用各种各样的暖客工具发掘用户的保险需求，成单后还需引导用户注册使用友邦友享App，一遍对客户进行运营和管理，过程中涉及诸多业务和系统。
为了践行友邦健康长久好生活的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健康度以及联通性等通用指标，为公司决策提供支持。
右上方中屏主要展示流水线的研发效率指标、应用性能的指标以及全局调用链，帮助研发人员提升效率和问题定位的速度。
右下方小屏通过历史数据的对比，设置了报警阀值。出现异常时，通过钉钉或短信报警的方式推送到电脑、手机终端，帮助运维人员及时发现和处理问题。
