陶澍百度百科，陶澍简历

2022年9月28日，阿里云用户群第十一届活动(AUG)在深圳举行。活动现场，阿里云产品专家陶秉哲与参会企业分享了“Java应用的最佳实验”。本文根据演讲内容整理。

大家好，我是陶冰哲，我是阿里云产品专家。这是我观察的第八年。其实一开始，我和大家一样，也是运维出身。今天我想和大家分享一下我们阿里的最佳实践，也探讨一下我们背后的一些方向。

首先解释一个概念性的问题，这其实是我最早的话题，“当我们在谈论可观测性的时候，我们在谈论什么？”相信大家对监控这个概念都很熟悉，可观测性这个概念也是近几年突然流行起来的。它和监控有什么区别？

监控-APM-原始可观测云时代的基础设施

从这张图中，我们可以看到一条从监测到可观测的进化路径。一些较早参与工作的同学可能用过Zabbix和Nagios这样的产品。它们是我们最早的基础监控软件，主要关注机器指标，关注我们当前机器的CPU和内存是否高，进程是否还存在。他给我们提供的是对机器环境的监控能力，在早期单机环境下非常有效。

随着近年来整体技术的演进，基础设施出现了云端化、微服务化、容器化等趋势。仅仅这些机器指标已经不能有效衡量我们的服务健康状况，有必要引入像log和trace这样的不同数据。衡量服务的健康状况更加复杂。总之，管道的集群变得更大更复杂了，数据也更多了。

同时，随着devops等概念的普及，我们希望每个学生都有端到端处理问题的能力。监控工具不仅应该告诉我哪里有问题，还应该帮助我定位和诊断问题。

这就是为什么它已经从监控发展到我们所说的可观察的原始力量，所以我在这里提出合格的可观察平台和传统监控工具之间的两个最大区别:

首先是统一。可观测平台应该是各种传统监测工具的有机结合。它有三种类型的数据，日志/跟踪/度量，它们是完全相关的。用户可以根据自己的需要继续分析数据。二是专业。可观察平台可以完成发现问题、定位问题、诊断问题的闭环，而不仅仅是发现问题。最好能提供一些专家经验，帮助用户快速定位问题。云原生可观察需求和数据支持

更具体地说，我们可以观察如何解决业务问题。我把它分成三部分。

首先需要明确业务体验，我们的业务需要用什么指标来衡量目前是否正常运行。

比如淘宝首页，我们每分钟成交的订单数是否符合我们的预期？如果其中一项没有达到预期，那是因为我们的系统或我们的业务流程出现了问题。这时候就需要通过我们定义的业务指标来衡量业务的正常程度，然后拆解到一些具体的问题，比如app的崩溃，页面的白屏等等。

然后中间层是我们后端服务的稳定性。后端的稳定性分为两部分:一是应用本身的稳定性，二是应用所依赖的中间件服务。

我们在处理这一层问题的时候，首先要关注应用本身的指标，比如响应时间、错误率等。，然后通过应用本身的数据来看关联中间件的指标。当然，如果你是dba或者中间件维护人员，反过来也可以。目前这一层往往是问题发生最频繁的一层，因为各种业务的复杂逻辑往往集中在这一部分。同时，随着各种微服务框架的使用，问题往往不仅出现在单台机器上，还会出现在由一系列请求拼接而成的调用链上。这里我们一般强调两个方向的建设。

首先是追查能力。我们最好选择遵循开源的opentracing协议，这样可以更好地定义调用链上的各种业务数据。二是侧写能力。对于严重的问题，如OOM和死锁，通常很难通过指示器或日志来检查。我们需要专注于建立剖析能力来解决它们。底层，也就是我们传统监控的范围，传统的cpu、内存、网络、磁盘等数据。这些数据经常作为我们上层业务的排除项，用于排除硬件相关的问题，也可以作为我们灵活扩张收缩的辅助指标，帮助我们更好的构建业务稳定性。

基于阿里云产品构建一站式可观察解决方案

刚才说了，可观测性基本上就是各种指标的作用和构造优先级。如果只是据此构建指标，我认为并不是一个完整的可观测平台。就像我们做大数据一样，我们也需要统一的可观测数据系统。

在ARMS的方案中，我们选择了prometheus作为我们的metrics的统一存储，sls作为我们的log /trace数据的统一存储，Grafana作为我们的统一磁盘，同时我们构建了一个集成诊断和告警的AIOPS中心，用于智能数据分析。

针对不同的监控对象和级别，我们构建了基于此的系统。例如，对于应用程序的监控，您可以选择使用我们的arm提供的开源/探针来报告数据。我们会将数据存储在prometehus和sls中并向用户开放，然后通过Grafana显示各种预置盘，同时通过aiops中心的智能巡检数据生成各种报警事件。

建立一个可见、可用和可诊断的可观察系统。

最后一部分其实回到了我们的核心问题。有了这样的平台，如何通过它快速提高自己的解题能力？

第一阶段:发现问题

你需要定义我们最关注的业务指标(类似于访问量)，然后匹配成一些基本的业务告警，这样才能第一时间发现问题。

第二阶段:定位问题

在定位问题时，我们需要能够使用APM之类的工具和一些日志工具，这些工具可以快速缩小这些问题的范围，到哪个接口甚至哪个节点进行编码。然后我们就可以根据这个范围跟具体负责人确认，成立我们的问题作战室，诊断问题。

第三阶段:诊断问题

现阶段我们已经通过数据确认了问题的范围，还需要一些确凿的证据。此时，我们需要使用我们刚刚提到的分析工具来进一步诊断数据。场景的剖析工具有jstrack、jmap、mat之类的工具。

在这里，我们应该强调两个方面的建设:

第一个是很难使用这些工具和分析结果。我们可以通过白屏来降低使用它们的难度，并对返回的数据进行进一步的处理。比如jstack的结果往往包含大量java代码，对我们定位问题没有帮助，可以选择性忽略。

第二是这些工具的使用往往需要很高的性能开销，无法正常启动，但也不一定能稳定在线重现。此时，我的建议是引入类似JFR的连续剖析方案，作为我们剖析能力的补充。(正文结束)

阿里云产品专家陶秉哲:Java应用的最佳实验