自监控

问题

监控系统用于监控其他的系统、基础设施,绝对是 P0 级的服务,那监控系统的自监控应该怎么做呢?如果自己监控自己,有些组件挂掉了难免循环依赖,如果单独搞一套新的监控系统来监控当前服役的监控系统,又搞得有些过于复杂。本文我们来探讨一下监控系统的自监控应该怎么做。

解决方案:自身指标

首先,监控系统自身是会暴露监控指标的,比如 Prometheus、VictoriaMetrics、Nightingale,都通过 /metrics 接口暴露了自身的监控指标,这些指标通过监控系统自身的采集机制去采集就好,相关数据的历史趋势图、告警规则,也在监控系统自身配置好,只要自身模块没有挂掉,或者没有全部挂掉,相关数据基本都可以正常使用。

比如 Nightingale 的自身监控指标,可以通过 categraf 的 input.prometheus 插件来采集,即 conf/input.prometheus/prometheus.toml 的内容如下:

  1. [[instances]]
  2. urls = [
  3. "http://localhost:17000/metrics"
  4. ]

localhost:17000 换成你的 Nightingale 的地址即可。然后导入内置仪表盘:https://github.com/ccfos/nightingale/tree/main/integrations/n9e/dashboards,即可看到 Nightingale 自身的监控指标了。

解决方案:存活监控

如果监控系统同时有多个模块故障,此时自身指标可能都采集不到了,告警引擎可能也有故障,此时就没法通过自身指标来监控了,此时就需要一个外挂的小监控系统来监控这类严重情况了。而且,告警通道尽量也不要复用之前的通道,因为通道可能也会故障。

我的建议是采用 catpaw + FlashDuty 来搞这个需求。FlashDuty 是外网的 SaaS 服务,只要公网出口是好的,就能提供监控服务,而且无需我们维护,使用免费套餐都够用,毕竟监控系统也不会经常挂。。。

catpaw 最新版本是 v0.7.0,已经提供了 exec(执行脚本的插件)、filechange(文件变化监控的插件)、http(HTTP探测的插件)、journaltail(系统日志异常检测插件)、mtime(递归判断文件变化的插件)、net(TCP、UDP探测的插件)、ping(PING插件)、procnum(进程数量监控插件)、sfilter(自定义脚本插件,相比exec插件更简单,匹配脚本输出)等多个监控插件,我们可以使用 net 插件来探测监控系统的各个组件的存活情况,比如下面是 net 插件的配置样例:

  1. [[instances]]
  2. targets = [
  3. # "127.0.0.1:22",
  4. # "localhost:6379",
  5. # ":9090"
  6. ]
  7. ## Set timeout (default 5 seconds)
  8. # timeout = "5s"
  9. ## Set read timeout (only used if expecting a response)
  10. # read_timeout = "5s"
  11. # # Concurrent requests to make per instance
  12. # concurrency = 10
  13. # # gather interval
  14. # interval = "30s"
  15. # # Optional append labels
  16. # labels = { env="production", team="devops" }
  17. ## Protocol, must be "tcp" or "udp"
  18. ## NOTE: because the "udp" protocol does not respond to requests, it requires
  19. ## a send/expect string pair (see below).
  20. # protocol = "tcp"
  21. ## The following options are required for UDP checks. For TCP, they are
  22. ## optional. The plugin will send the given string to the server and then
  23. ## expect to receive the given 'expect' string back.
  24. ## string sent to the server
  25. # send = "ssh"
  26. ## expected string in answer
  27. # expect = "ssh"
  28. [instances.alerting]
  29. ## Enable alerting or not
  30. enabled = true
  31. ## Same functionality as Prometheus keyword 'for'
  32. for_duration = 0
  33. ## Minimum interval duration between notifications
  34. repeat_interval = "5m"
  35. ## Maximum number of notifications
  36. repeat_number = 3
  37. ## Whether notify recovery event
  38. recovery_notification = true
  39. ## Choice: Critical, Warning, Info
  40. default_severity = "Warning"

如果目标 IP:Port 连不上了,就会报警,报警事件的具体推送策略在 [instances.alerting] 配置段配置。

如果监控系统的某个模块,不监听端口,没法监控端口存活,可以使用进程数量监控,即 procnum 插件,相关配置样例如下:

  1. [[instances]]
  2. # # executable name (ie, pgrep <search_exec_substring>)
  3. # search_exec_substring = ""
  4. # # pattern as argument for pgrep (ie, pgrep -f <search_cmdline_substring>)
  5. search_cmdline_substring = ""
  6. # # windows service name
  7. # search_win_service = ""
  8. alert_if_num_lt = 1
  9. check = "进程存活检测(进程数量检测)"
  10. interval = "30s"
  11. [instances.alerting]
  12. ## Enable alerting or not
  13. enabled = true
  14. ## Same functionality as Prometheus keyword 'for'
  15. for_duration = 0
  16. ## Minimum interval duration between notifications
  17. repeat_interval = "5m"
  18. ## Maximum number of notifications
  19. repeat_number = 3
  20. ## Whether notify recovery event
  21. recovery_notification = true
  22. ## Choice: Critical, Warning, Info
  23. default_severity = "Warning"

net 和 procnum 这两个插件配合,理论上一定可以发现进程挂掉的情况,如此一来,严重的情况 catpaw 就可以发现了,不严重的情况,监控系统自身的指标就可以发现了,齐活。