CDN监控系统（一）

CDN监控系统（一）

---

监控系统不仅仅是为了告警，在人工智能里面 只有 反馈收敛机制的系统才能不断进化智能。监控系统要能反馈形成闭环，不断正反馈。避免问题 而不是发现问题 ：

1. 针对开发，需要完善代码，日志、接口、甚至开发管理。
2. 针对运营，如何快速发现、排查、解决问题，避免问题（devops aiops）。
   介绍系统 避免直接从软件开始介绍 而是从业务 到 要解决的问题 以及如何闭环，软件只是工具，意识和思想更加重要。

最早在讨论监控系统的愿景中，希望能做以下要求：

• 避免泛洪
  针对告警要严格审核，不需要立即处理的坚决不要告警，（注意监控告警和监控运营的区别，可以放到运营平台后续分析处理）

• 自动化分析
  除了告警以外，最好是能提供更多方便排查的信息。比如cache 出现域名 5xx 状态码告警，需要联动大数据平台或者工具：（不一定要立即做到以下过程，但至少第一步需要做到）

  1. 找到该类型 5xx 最多的 top 机器
  2. 在 top机器 根据日志 判断 5xx 的来源（源返回？缓存节点返回？负载均衡节点返回？哪一个环节出的问题。节点软件最好调用公有的错误状态码返回接口，并在该接口中置一些调试信息，输出到访问日志，可以方便迅速定位）

• 区别错误预防和错误告警
  比如 服务软件 影响并发数的一个重要参数是 listen baklog 队列大小，可以使用 ss -nlp |grep nginx 查看。如果 第三列 太小 是有问题的。不应该把baklog 放入 监控 而是需要跑一个上线前的预检测：

  1. 监听并发数是否太低（隐藏的问题并发太大时 偶尔建联不成功）；
  2. 日志或者输出文件有没有回滚（包括引用的第三方库是否暗藏日志，可以用工具https://github.com/zengxiaobai/systemtap-scripts iostatic.stap 查看库是否在某个角落偷偷打印日志）可能导致磁盘满
  3. check_service 自重启 上报告警, 开机自重启
  4. check_core 和clean core，可能导致磁盘满

现在开始接监控系统，对告警结合网上的描述有些总结很好：

告警收敛（PS： 收敛的基本策略：减少输入、 分类、包含、屏蔽、合并）

• 分组 最基本的管理方式
• 抑制 主机挂了引起服务挂了告警 只需报主机挂了
• 静默 当发生告警1和告警2 时，静默告警3 和告警4
• 延时 类似任务周期合并策略

告警系统的高可用性

当没有告警时 怎么确定是真的正常 还是 告警系统挂了？https://blog.csdn.net/qq_39015563/article/details/84749241

告警系统和运营系统结合使用

监控指标

机器级别

• cpu
  cpu 使用率和负载
• mem
  可用mem空间 和swap是否关闭
• disk
  磁盘可用空间 和 iowait
• eth_IO
  网卡出入流量，千兆（不超过 1G）和万兆网卡（不超过 10G）
  网卡流量变化太快
  上下行流量（下行流量过高）

网络级别

• ping
  ping loss 或者 ping 太久
• port
  端口 是否联通
• tcp_conn
  time_wait等 端口耗尽

系统级别

• 进程数

软件级别

• 服务状态
  systemctl status xxx
• 服务响应异常、时间长
• core 监控
• 软件版本
• 配置文件丢失
• 攻击
• 其他业务指标 （如 分频道状态码、流量、攻击、单机状态码等等）