云布道师
2022 年 9 月 28 日，阿里云用户组（AUG）第 11 期活动在深圳举办。活动现场，阿里云产品专家陶炳哲向参会企业分享了《Java 应用最佳实验》。本文根据演讲内容整理而成。
大家好，我是陶炳哲，是阿里云产品专家。这是我做可观测的第八个年头了。开始其实跟大家一样，我也是做运维出身的，今天想和大家分享一下我们阿里的最佳实践，同时也一起探讨一下我们后面的一些方向。首先解释一个概念问题，其实也是我最早的题目 《当我们在讨论可观测的时候，我们在讨论什么》。我相信大家对监控的概念非常熟悉了，从这几年开始突然流行起来可观测的概念，它和监控有什么不一样呢？监控-APM-可观测
云原生时代的基础设施
从这张图上我们可以看到从监控到可观测演变的一个路径，可能有一些参加工作比较早的同学用过像 Zabbix、Nagios 这样的产品，它们是我们最早的基础监控软件，主要关注的是机器指标，关注我们当前机器的 CPU 高不高，内存高不高，进程是否还存在，他给我们提供的就是对于机器环境的监控能力，这个在早期单机环境下是十分有效的。随着这些年整体技术的演进，出现了基础设施上云、应用微服务化、容器化等等趋势，仅仅这些机器指标不再能有效衡量我们的服务健康，需要引入类似 log、trace 等等不同的数据，想要衡量服务的健康程度这件事情变得更复杂了。一句话总结，就是管的集群变大了，变复杂了，数据也更多了。同时随着 devops 等概念的流行，我们希望每个同学都具备端到端处理问题的能力，监控工具不应该只能告诉我哪里有问题，还应当可以协助我去定位和诊断问题。这也是为什么会从监控演变成我们说的可观测的原始动力，所以我在这里提出来我认为的一个合格可观测平台和传统监控工具最大的 2 个区别：云原生可观测需求和数据支撑
那么再具体一点，可观测怎么样解决业务问题，我把它分成了三个部分。首先，我们需要对业务体验做一个定义，我们的业务需要用哪些指标来衡量它目前是不是正常的运行。比如说淘宝主页，我们每分钟成交的订单数是不是一个符合我们预期的。如果他有个不符合预期，是因为我们的系统产生问题了，还是说我们业务流程上出现了问题，这个时候我们需要通过我们定义出来的业务指标来衡量业务的正常程度，然后在拆解到一些具体问题，比如 app 的崩溃，页面的白屏等等。然后中间这一层就是我们的后端的服务的稳定性。后端的稳定性我们把它分为 2 部分：一部分是应用本身的稳定性，另一部分是应用依赖的中间件服务。我们在处理这一层的问题时候，应当首先关注应用本身的指标，类似响应时间，错误率等等，然后通过应用本身的数据在关联中间件的指标去看，当然如果你是一个 dba 或者中间件的维护方，反过来也可以。目前这一层也往往是最经常发生问题的一层，因为各种业务复杂的逻辑往往都集中在这部分，同时随着各种微服务框架的使用，问题往往不单单发生在一个单机上，而是会是一串请求拼接而成的调用链，在这里我们一般重点强调 2 个方向的建设。- 第一个是 tracing 的能力，我们最好是选择跟随开源的 opentracing 协议方便我们将各种业务数据更好的在调用链上定义出来。
- 第二个是 Profiling 的能力，对于 OOM，死锁等严重问题，往往通过指标或者日志很难排查，我们需要重点建设 Profiling 能力去解决他们。
最下面一层，也就是我们传统监控的范围，传统的 cpu、内存、网络、磁盘等数据。这些数据往往作为我们上层业务层层排查的排除项，用于排除硬件相关问题，同时也可以作为我们弹性扩缩容的辅助指标，帮我们更好地建设业务稳定性。
基于阿里云产品构建一站式可观测解决方案
刚才讲到，可观测基本上就是各种各样的指标的作用和建设优先级，如果仅仅是按此把指标建设完成，我认为它还并不是一个完整的可观测平台，就像我们做大数据一样，我们也需要一个统一的可观测数据体系。在 ARMS 的方案里面我们选择 prometheus 作为我们 metrics 的统一存储，sls 作为我们日志/trace 数据的统一存储，Grafana 作为我们的统一大盘，同时自建了一个集成诊断和告警的 AIOPS 中心用于对数据进行智能分析。对于各个不同的监控对象和层次，我们基于这套体系来进行建设，比如对于某一个应用的监控，你可以选择使用开源/我们 arms 提供的探针来进行数据上报，我们会把数据统一存储在 prometehus 和 sls 并对用户开放，然后通过 Grafana 展示我们已经预置好的各种大盘，同时通过 aiops 中心智能的巡检数据产生各种告警事件。建设可见、可用、可诊断的可观测体系
最后一部分其实还是回到我们的核心问题，有了这样的平台，我们如何通过它快速提升我们的问题解决能力。
第一个阶段：发现问题
你需要把我们最关心的那些业务指标（类似访问量）定义出来，然后把它配成一些基础的业务告警，让我们能在问题出现的第一时间去发现。 第二个阶段：定位问题
定位问题的时候，我们需要能用到像类似 APM 的工具和一些 Logs 工具，能把这些问题迅速缩小范围，到哪一个接口，甚至哪一个节点上面代码操作。然后我们就可以根据这个范围，去和具体的负责人确认，建立我们的问题作战室，进行问题的诊断。
第三个阶段：诊断问题
到这个阶段，我们通过数据已经确认了问题的范围，需要一些可以一锤定音的结论性证据，这个时候就需要用到我们刚才提到的 profiling 工具，来对数据进行进一步的诊断，场景的 profiling 工具有类似 jstrack，jmap，mat 等工具。第一个是这些工具的使用和结果解析是有一定难度的，我们可以通过白屏化的方式降低使用难度，同时对于返回的数据进行进一步加工，比如 jstack 的结果往往会包含大量 java 本身代码，这些数据对我们定位问题是没有帮助的，我们可以有选择地忽略他们。第二个是这些工具的使用往往需要较高的性能开销，一般是不能常态开启的，但是线上又不一定能够稳定复现，这时候我的建议是引入类似 JFR 这样的 Continuous Profiling 方案，作为我们 Profiling 能力的补充。（正文完）/ 相关推荐 /
你可能还想看关注我们欢迎关注加星标✨ 每日推送不错过