监控告警与日志服务

[二、日志服务 SLS](#二、日志服务 SLS)

一、监控告警（CloudMonitor）

1、监控是干什么的

没有监控：机器挂了、磁盘满了、数据库慢了，往往等用户投诉才知道。

有监控：

采集指标 → 发现异常 → 告警通知 → 人处理 → 恢复

云监控（CloudMonitor） = 阿里云基础可观测入口：看资源好不好、出事找谁、怎么通知。

2、企业监控分层

层次	看什么	常见产品
资源监控	CPU、内存、磁盘、连接数	CloudMonitor
日志	错误日志、访问日志	SLS
链路/APM	接口耗时、调用链	ARMS
拨测	从公网探测网站是否通	云拨测

3、企业级铁律

先建联系人 / 联系组，再建规则（别告警了没人收）
用应用分组 + 报警模板，别给每台机器手搓规则
资源打标签（env/app/owner），按标签自动入组
分级通知：严重电话/短信，一般钉钉即可
阈值要合理：持续几分钟再告，减少抖动误报
告警要可行动：能看出是哪台、哪个指标、谁负责
定期复盘：噪声太多就调阈值，漏告就补规则
ECS 装云监控插件，才能采到内存、磁盘等主机指标

4、核心概念

概念	描述
监控指标	CPU%、磁盘%、连接数等数值
事件	如实例重启、OOM、抢占回收等"发生了什么"
告警规则	超过阈值就报警
联系人 / 联系组	通知发给谁
应用分组	按业务把 ECS+RDS+Redis 等放一筐
报警模板	一套标准规则，批量套到分组
通知渠道	短信、邮件、电话、钉钉/飞书 Webhook

企业搭法：联系人组 → 应用分组（按业务/环境）→ 报警模板应用上去 → 钉钉/电话通知

5、知识了解

（1）联系人与通知通道

云监控 → 报警联系人
填手机、邮箱，按提示激活
建联系组：如 ops-oncall、app-order-owners
（推荐）钉钉群加自定义机器人，关键词设为「告警」，拿到 Webhook

企业习惯：

生产值班组收 P0/P1
业务群收本业务告警
夜间电话只给值班，不给全员轰炸

（2）应用分组（按业务打包）

示例分组：order-prod（订单生产）

建议纳入：

ECS / ESS 伸缩出来的机器（靠标签自动加入更好）
ALB
RDS
Redis
（相关）OSS 用量或关键事件

创建方式：

按标签：env=prod 且 app=order
或按实例名规则匹配

以后新机器只要打对标签，会自动进组、自动带上告警。

（3）基础指标清单

① ECS

指标	建议阈值思路
CPU 使用率	> 80% 持续 5 分钟
内存使用率	> 85% 持续 5 分钟
磁盘使用率	> 85%（根分区/数据盘）
磁盘 inode	> 85%
网络流入/流出异常	按业务基线

内存/磁盘常需云监控插件。

② RDS

指标	建议
CPU	> 80% 持续
连接数	接近规格上限（如 > 80%）
磁盘空间	> 80%～85%
IOPS / 慢查询相关	按实例能力设
只读延迟（若有）	超过业务可接受秒数

③ Redis

指标	建议
内存使用率	> 80%
连接数	接近上限
命中率	明显下降要关注
流出带宽 / 延迟	突增告警

④ ALB / 负载均衡

指标	建议
后端异常主机数	> 0 持续
5xx / 健康检查失败	按业务
QPS / 连接数异常	突增或掉底

⑤ OSS（费用与可用性相关）

关注点	说明
计量/流量异常	防盗刷导致费用暴涨
可用性相关事件	按产品事件订阅

（4）报警模板（一次配置，多处复用）

创建模板如：tpl-prod-basic

写入上面 ECS + RDS + Redis + ALB 的规则，然后应用到 order-prod、user-prod 等分组。

好处：

新业务复制分组 + 套同一模板
改阈值只改模板，不逐台改

官方用法：报警模板设置应用分组规则

（5）事件告警（指标之外）

除了"数值超标"，还要订事件，例如：

ECS 重启、释放、OOM
RDS 主备切换、只读实例异常
抢占式实例被回收

事件往往比"CPU 慢慢升高"更能解释突发故障。

（6）告警怎么写才有用

差的告警：

CPU 高了

好的告警应能回答：

哪个环境/应用（标签、分组名）
哪台实例
什么指标、当前值、阈值
建议动作（可在通知文案里写简要 runbook）

例如：

[P1][order-prod] ECS i-xxx CPU 92% > 80% (5m)

处理：看是否流量突增 / 慢接口 / 是否该 ESS 扩容

（7）降噪（企业必做）

告警太多 = 没人看。手段：

手段	做法
持续时长	连续 N 个周期再告
分级	P0 电话，P2 只钉钉
静默	发布窗口临时屏蔽
合并	同类告警聚合（云监控 2.0 / ARMS 通知策略）
阈值校准	按一周误报情况回调

原则：宁可少而准，不要多而烦。

（8）和前后架构串起来

用户 → ALB ──监控：5xx、后端健康

↓

ECS/ESS ──监控：CPU/内存/磁盘；ESS 是否扩容成功

├─ Redis ──监控：内存、命中率、连接

├─ RDS ──监控：CPU、连接、磁盘、延迟

└─ OSS ──监控：流量异常、（业务侧可用性）

告警 → 钉钉/短信/电话 → 值班 → 上堡垒机处理

和 RAM：只有运维角色能改告警规则；开发可只读。

和标签：没有标签，分组与分账、告警都会乱。

小结

监控 = 分组管资源 + 模板管规则 + 联系人收通知。

先让 ECS/RDS/Redis/ALB 的基础指标和关键事件叫得应，再谈精细化与链路追踪。

二、日志服务 SLS

官方参考：快速入门 · 索引 · Logtail 采集

1、SLS 是什么

SLS（Simple Log Service） = 阿里云的集中日志平台。

以前：登录每台 ECS 用 tail / grep 翻日志。

机器一多、ESS 一扩缩，就找不到了。

有了 SLS：

各台机器/容器上的日志

→ 采集到 SLS（集中存放）

→ 网页里搜索、统计、告警、看板

和云监控分工：

	云监控	SLS
主要看	CPU、磁盘、连接数等指标	文本/结构化日志
典型问题	"机器是不是满了？"	"哪条请求报错？错误栈是什么？"

2、三个核心词

概念	描述	例子
Project	项目/命名空间，做隔离	`order-prod`
Logstore	一种日志的仓库	`app-log`、`nginx-access`
Logtail / LoongCollector	装在机器上的采集器	读 `/var/log/app/*.log` 上报

常见拆法：

Project: order-prod

├─ Logstore: nginx-access

├─ Logstore: app-error

└─ Logstore: app-biz

3、企业级铁律

按环境/业务分 Project（生产、测试分开）
按日志类型分 Logstore（访问日志、错误日志别混一锅）
要查要分析，必须开索引；只归档可考虑查询型降成本
应用日志务必带 request_id / trace_id，才能串起一次请求
设保存天数（如 7～30 天热查，更久投递 OSS）
敏感信息脱敏（密码、证件号别明文打日志）
采集增量：配置后文件要有新写入才会采到
和监控联动：指标告警 + 日志告警，定位更快

4、知识了解

（1）创建 Project / Logstore

项	建议
Project 名	`公司-业务-环境`，如 `demo-order-prod`
地域	与 ECS 同地域（采集更快、更稳）
Logstore	标准型（要 SQL 分析）；纯归档可查询型
保存时间	生产常见 15～30 天（按合规）
Shard	流量大开自动分裂

（2）采集 ECS 应用日志（最小闭环）

控制台进入 Project → 采集数据 → 主机/文本日志
选同账号同地域 ECS，自动安装 Logtail
建机器组，确认心跳 OK
配置采集路径，例如：/var/log/myapp/*.log
选解析模式（极简 / JSON / Nginx / 正则）
预览有数据后，开启索引
进入查询页，搜关键词验证

官方入门：SLS 快速入门

ESS 伸缩出的新机器：要用机器组 + 镜像预装 Logtail，或运维自动化安装，否则新节点没日志。

（3）索引（能搜还是能分析）

类型	作用
全文索引	关键词搜索（像搜文档）
字段索引	按字段精确查，并能做 SQL 统计

规则：

只搜关键字 → 全文即可
要 status=500、统计 QPS/错误率 → 字段索引 + 开启统计
索引字段别太多（建议别堆到上百无关字段），控制成本

改索引大约 1 分钟生效。

（4）查询语句（最常用）

假设 Nginx/访问日志已解析出 status、request_uri 等字段：

bash 复制代码

# 查包含 error 的日志
error

# 查 5xx
status >= 500

# 组合
status >= 500 and request_uri: /api/order

# 分析：最近错误数（需字段统计）
status >= 500 | SELECT count(*) AS err_cnt

# 按状态码聚合
* | SELECT status, count(*) AS c GROUP BY status ORDER BY c DESC

排障神器：用业务里的 request_id 一把搜出全链路相关日志：

bash 复制代码

request_id: 59f9xxxx-xxxx

（5）日志告警（和云监控互补）

示例：15 分钟内 5xx 过多就告警。

SLS → 告警 → 新建告警
查询：status >= 500 \| SELECT count(*) AS err_cnt
条件：err_cnt > 100
通知：钉钉 / 短信 / 电话（可复用你们的值班通道）

适合：

业务错误码激增
登录失败暴涨（安全）
某接口耗时字段超阈值

云监控偏资源；SLS 告警偏业务日志语义。

（6）仪表盘与投递

仪表盘：PV、错误率、Top URL、慢请求
投递 OSS：超期日志归档降成本
审计类：云产品操作日志、WAF/云防火墙日志也可接入 SLS 做合规检索

（7）应用怎么打日志才"企业级"

建议每条关键日志包含：

时间 | 级别 | request_id | 用户/订单号 | 接口 | 耗时 | 消息

JSON 示例：

bash 复制代码

{
  "level": "ERROR",
  "request_id": "a1b2c3d4",
  "order_id": "10086",
  "path": "/api/pay",
  "cost_ms": 820,
  "msg": "payment timeout"
}

好处：SLS 字段索引好配，告警和统计都方便。

（8）和前后知识串起来

用户 → ALB

↓

ECS/ESS ──Logtail──► SLS（app/nginx 日志）

├─ Redis

└─ RDS

云监控：CPU/磁盘/连接数告警

SLS ：error/5xx/request_id 定位根因

堡垒机：必要时登机器（但日常优先查 SLS，少登生产）

排障顺序（推荐）：

云监控看资源是否异常
SLS 用时间窗 + error / request_id 查日志
再决定是否上堡垒机深挖

5、常见坑

坑	说明
有配置但无数据	文件无增量；路径不对；机器组心跳 FAIL
能搜不能统计	没开字段索引/统计
费用突然升高	索引字段过多、保存过久、写入量暴增
新扩容 ECS 没日志	镜像未含采集器/未自动加入机器组
日志含密码 Token	安全事故隐患，要脱敏

小结

SLS = 集中收日志 + 索引查询 + 统计告警。

机器用 Logtail 采上来，日志带 request_id，和生产监控配合，才能又快又准地排障。