监控系统用于监控其他的监控系统、基础设施,系统绝对是自监 P0 级的服务,那监控系统的监控自监控应该怎么做呢?如果自己监控自己 ,有些组件挂掉了难免循环依赖 ,系统如果单独搞一套新的自监监控系统来监控当前服役的监控系统 ,又搞得有些过于复杂。监控本文我们来探讨一下监控系统的系统自监控应该怎么做 。
首先,自监监控系统自身是建站模板监控会暴露监控指标的 ,比如 Prometheus、系统VictoriaMetrics、自监Nightingale ,监控都通过 /metrics 接口暴露了自身的系统监控指标 ,这些指标通过监控系统自身的自监采集机制去采集就好,相关数据的历史趋势图 、告警规则,也在监控系统自身配置好 ,只要自身模块没有挂掉 ,或者没有全部挂掉,相关数据基本都可以正常使用。高防服务器
比如 Nightingale 的自身监控指标 ,可以通过 categraf 的 input.prometheus 插件来采集 ,即 conf/input.prometheus/prometheus.toml 的内容如下 :
[[instances]] urls = [ "http://localhost:17000/metrics" ]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 插件的配置样例:
[[instances]] targets = [ # "127.0.0.1:22", # "localhost:6379", # ":9090" ] ## Set timeout (default 5 seconds) # timeout = "5s" ## Set read timeout (only used if expecting a response) # read_timeout = "5s" # # Concurrent requests to make per instance # concurrency = 10 # # gather interval # interval = "30s" # # Optional append labels # labels = { env="production", team="devops" } ## Protocol, must be "tcp" or "udp" ## NOTE: because the "udp" protocol does not respond to requests, it requires ## a send/expect string pair (see below). # protocol = "tcp" ## The following options are required for UDP checks. For TCP, they are ## optional. The plugin will send the given string to the server and then ## expect to receive the given expect string back. ## string sent to the server # send = "ssh" ## expected string in answer # expect = "ssh" [instances.alerting] ## Enable alerting or not enabled = true ## Same functionality as Prometheus keyword for for_duration = 0 ## Minimum interval duration between notifications repeat_interval = "5m" ## Maximum number of notifications repeat_number = 3 ## Whether notify recovery event recovery_notification = true ## Choice: Critical, Warning, Info default_severity = "Warning"如果目标 IP:Port 连不上了,就会报警 ,报警事件的具体推送策略在 [instances.alerting] 配置段配置。源码下载
如果监控系统的某个模块,不监听端口 ,没法监控端口存活,可以使用进程数量监控 ,即 procnum 插件,相关配置样例如下 :
[[instances]] # # executable name (ie, pgrep <search_exec_substring>) # search_exec_substring = "" # # pattern as argument for pgrep (ie, pgrep -f <search_cmdline_substring>) search_cmdline_substring = "" # # windows service name # search_win_service = "" alert_if_num_lt = 1 check = "进程存活检测(进程数量检测)" interval = "30s" [instances.alerting] ## Enable alerting or not enabled = true ## Same functionality as Prometheus keyword for for_duration = 0 ## Minimum interval duration between notifications repeat_interval = "5m" ## Maximum number of notifications repeat_number = 3 ## Whether notify recovery event recovery_notification = true ## Choice: Critical, Warning, Info default_severity = "Warning"net 和 procnum 这两个插件配合,理论上一定可以发现进程挂掉的情况,如此一来,严重的情况 catpaw 就可以发现了,不严重的情况,监控系统自身的指标就可以发现了,齐活。