阿里云可观测性三部曲：云监控、Prometheus与日志服务的深度整合

凌晨三点，告警炸了。一个跨境电商平台的订单接口返回504，用户纷纷投诉。运维团队登上ECS查看，CPU、内存看起来都正常，就是慢。折腾了两小时，最后在登录服务器手动curl时才意识到是上游一个第三方物流API超时。为什么监控没发现？因为只看了基础指标，没有全链路追踪和日志分析。这次事故后，企业负责人找到我们，下定决心建立真正的可观测性体系。作为阿里云代理，我们借此项目，将云监控、Prometheus、SLS日志服务以及ARMS整合成了一套“三部曲”方案，这篇文章便复盘了其中的精髓。

一、第一层：云监控原生——基础的千里眼

阿里云为每一台ECS和轻量应用服务器都提供了免费的云监控基础版，包括CPU、内存、磁盘IO、网络等指标。这是最基础的保障，但很多人连告警都没设对。我们做的第一步，就是规范告警规则，形成如下表格：

这些规则虽然基础，但能覆盖80%的硬件级故障。然而对于应用层问题（如接口超时），需要更细致的指标。

二、第二层：Prometheus自定义——抓取应用的脉搏

阿里云提供了Prometheus托管服务（与容器服务ACK集成，也支持ECS），我们为客户的ECS节点安装了Node Exporter和自定义的应用Exporter（例如针对Java的JMX Exporter，或业务指标暴露端）。Prometheus可以抓取JVM堆内存、线程数、第三方API调用延迟等，并配置预聚合规则。

我们将业务黄金指标（延迟、流量、错误、饱和度）全部接入Prometheus，并用Grafana在云上搭建了集中可视化大屏。与纯云监控的对比如下：

我们还为轻量服务器上的Node.js应用写了一个简单的exporter，暴露事件循环延迟等指标，通过公网拨测采集。这让轻量服务器的监控不再“黑盒”。

三、第三层：SLS日志服务——还原事件现场的显微镜

当异常发生，指标能告诉我们“发生了什么”，而日志能回答“为什么发生”。我们将所有ECS、ALB、DCDN的日志全部接入SLS。SLS的强大之处在于可以实时分析。我们为物流API超时问题搭建了如下日志分析链路：Nginx访问日志 -> SLS快速分析聚合上游API响应时间的P99 -> 发现某物流API P99飙到10秒 -> 联合业务日志查看具体请求参数 -> 定位原因。

核心操作：使用SLS的日志聚类功能，自动发现新出现的错误模式。并结合告警，当某错误日志模式在5分钟内出现超过10次，即触发通知。这样，下次再有第三方超时，30秒内就能锁定，无需再凌晨抓瞎。

四、整合的威力：一个排障场景重现

我们模拟一次实际排障：用户登录慢。首先，ARMS应用监控（或Prometheus自定义指标）捕获到登录API的P95延迟突增；接着，Grafana看板下钻，发现调用认证服务的耗时上升；然后，点击跳转到SLS日志查询认证服务相关日志，发现该服务频繁GC，对应JVM指标在Prometheus中也显示堆内存耗尽。最终结论：认证服务内存泄漏。从发现到定位，不到5分钟。而没有这套可观测性之前，可能要一天。

可观测性的建立不是堆砌工具，而是编织一张感知网络。使用正规国际阿里云账号，我们可以无缝开启这些服务，并利用企业级IAM精细化授权访问SLS日志。那些通过“账号买卖”弄来的账户，连开启高级日志分析的权限都可能因风控而受限。所以，监控的底座，依旧是一个干净、完整的账号。

如今，那家电商平台的运维团队，不再半夜惊慌地登陆服务器，而是从容地打开Grafana和SLS仪表盘，像医生看着监护仪一样看着他们的业务。这，就是可观测性带给人最大的踏实。

如果需要更深入咨询了解可以联系全球代理上TG:jinniuge  他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。