在阿里云上跑业务，麻烦往往出在两个地方：服务挂了却没人知道，或者账单涨了才找到原因。把监控阿里云这件事做扎实，就能在用户投诉之前发现问题，也能在月底账单出来之前看到异常消费。这篇按落地顺序讲，先定目标，再看基础设施、应用、日志安全和费用，最后给一份搭建节奏。配置思路可以直接用，具体阈值需要结合自己的业务调整。
先想清楚要监控什么
不少团队一上来就把各种监控功能全开，结果告警短信每天几十条，真出问题时反而没人看。动手之前先回答三个问题：业务最怕出什么问题，出问题后谁要知道，多久之内必须响应。
拿一个电商小团队举例。他们最在意四件事：订单接口不能超时，数据库不能被打满，服务器磁盘不能写满，月度费用不能超过预算的120%。目标列清楚以后，监控项就少了很多，不用什么都盯。
基础设施层：云监控 CloudMonitor
云监控是阿里云自带的基础监控，ECS、RDS、SLB、OSS 等主流产品都有免费的基础指标，采集粒度一般是1分钟。日常最常看的指标有这几个：
- CPU使用率：持续超过80%，通常说明要扩容，或者该看看代码了。
- 内存使用率：ECS 默认不采集内存，要先安装云监控插件才能看到。这一步很容易漏，漏了就等于没有内存告警。
- 磁盘使用率与IOPS：磁盘写满是服务异常最常见的原因之一，建议单独设告警。
- 网络带宽与连接数：盯住出入带宽，看它是否接近购买的上限。
某内容站点吃过亏。日志文件两周里一直在涨，最后磁盘写满，Nginx 无法写日志，直接返回500。之后他们给磁盘使用率设了两级告警：70%发通知，90%打电话。这类问题后来没有再出现。
告警规则怎么设
告警规则的好坏，决定监控到底有没有用。下面几条是踩过坑之后比较值得照做的：
- 阈值参考历史基线，别直接抄网上的通用数字。比如批处理时段 CPU 本来就会冲高，固定80%会一直报警。
- 加上持续时间，比如 CPU 连续5分钟超过85%才触发，过滤掉瞬时波动。
- 分级通知：普通告警走钉钉或邮件，只有严重告警才打电话，否则很快会出现告警疲劳。
- 每条告警都要对应一个处理动作。写不出处理动作的告警，直接删掉。
应用层：补上云监控看不到的部分
云监控能告诉你服务器还活着，却不能告诉你接口返回的数据对不对，响应时间是否还在可接受的范围内。这部分要靠应用自己埋点，或者用外部拨测来补。
阿里云应用实时监控服务 ARMS 可以自动采集调用链、慢SQL和JVM指标。Java 应用接入时通常只需挂载探针，代码改动很小。如果不想用 ARMS，也可以自建 Prometheus 加 Grafana，用 Micrometer 或 OpenTelemetry 输出指标，再统一展示。
一家在线教育公司的直播接口平时平均响应80毫秒，但每天晚上八点会出现偶发的3秒延迟。服务器指标一切正常，他们通过 ARMS 调用链定位到是某个缓存批量过期引起的穿透，调整缓存策略后问题消失。这类问题只看服务器指标，很难发现。
日志与安全
日志服务 SLS 可以集中收集 ECS、容器、负载均衡等产生的日志，支持实时查询和告警。实际用得比较多的场景有三类：统计5xx错误率，追踪某个用户的操作记录，检测异常登录。
安全这块，建议开通云安全中心的基础防护，重点关注异常登录、挖矿程序和端口暴露。被入侵的服务器，早期常见的迹象就是 CPU 无缘无故升高。如果给 CPU 建了基线告警，就能更早察觉。
成本监控
只盯技术指标，费用就容易失控。阿里云费用中心可以设置预算告警，按产品或标签查看消费明细。具体做法有三件事：
- 给资源统一打标签，至少区分环境（生产、测试）和业务线，否则账单拆不开。
- 设置月度预算，同时配一个按日的用量预警，让异常当天就能看到。
- 定期清理闲置的云盘快照、未绑定的弹性IP和测试环境实例。
一个开发团队压测结束后忘了释放环境，一台高配 ECS 连续跑了三周，多出来的费用相当于一台中型服务器一个月的开销。他们后来给测试标签设了按日费用告警，同类情况第二天就能被发现。
搭建节奏
- 第一周：开通云监控，给核心 ECS、RDS 配置 CPU、内存、磁盘、连接数告警。
- 第二周：接入应用监控，梳理核心接口的响应时间和错误率。
- 第三周：配置日志告警和安全基线，设置费用预算。
- 之后每月复盘一次告警记录，删掉没人处理的噪音，补上漏掉的指标。
监控要跟着业务一起改。先把最核心的几个风险盯住，跑稳以后再慢慢加深，比一开始就追求面面俱到更省力。
