关于运维:监控系统自监控怎么做

2次阅读

共计 2924 个字符，预计需要花费 8 分钟才能阅读完成。

监控零碎用于监控其余的零碎、基础设施，相对是 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 就能够发现了，不重大的状况，监控零碎本身的指标就能够发现了，齐活。

enjoy :-)

正文完