MinMon - 一个有偏见的最低限度监控和报警工具（适用于 Linux）

此工具仅包含一个二进制文件和配置文件。没有数据库，没有 GUI，没有图表。只是监控和报警。我之所以编写这个工具，是因为我能找到的现有替代方案过于笨重，主要关注于具有图表的漂亮的 GUI（而不是报警），设置过于复杂，或者针对云/多实例配置。

检查

检查读取 MinMon 将要监控的测量值。

• DockerContainerStatus
• 文件系统使用情况
• 内存使用情况
• 网络吞吐量
• 压力平均值
• 进程退出状态
• Systemd 单元状态
• 温度

操作

当检查的报警改变状态或触发报告事件时，将触发 操作。

• 电子邮件
• 日志
• 进程
• Webhook

报告

报警的缺失可能意味着两件事：一切正常，或者监控/报警完全失败。这就是为什么 MinMon 可以触发定期的 报告 事件，让您知道它正在运行。

设计决策

• 没有复杂的脚本语言。
• 没有花哨的配置目录结构 - 只有一个 TOML 文件。
• 没有用户、组或角色。
• 没有晦涩的缩写。配置文件中额外的几个字母不会伤害任何人。
• 没有预定义的阈值名称，如“警告”或“关键”。您可能需要更多，或者只需要一个。因此，这取决于您在配置中定义。
• 同一检查插件可以多次使用。您可能希望在不同时间间隔内为不同的文件系统触发不同的操作。
• 报警在“周期”中计时（即检查间隔的倍数）而不是秒。这并不非常用户友好，但有助于保持内部处理和代码简单、高效。
• 警报自明 - 它们之间没有关联。这意味着根据您的配置，同一检查可能同时触发两个（或更多）事件。在某些情况下，这可能是不可取的。
• 简单、干净、无冗余的代码，具有良好的测试覆盖率。
• 根据您的配置，配置文件中可能存在类似或相同的块。这是配置文件格式灵活性和简单性的结果。
• 所有时间和日期都是UTC。不涉及本地时间和时区。
• 重启之间不存储任何内部状态。
• 目前仅适用于Linux，但应该很容易适应其他*NIX或甚至Windows。
• 上述一些内容在未来可能会改变（请参阅路线图）。

配置文件

配置文件使用TOML格式，并包含以下部分

• general
• log
• report
• actions
• checks

架构

系统概述

graph TD
    A(Config file) --> B(Main loop)
    B -->|interval| C(Check 1)
    B -.-> D(Check 2..n)
    C -->|data| E(Alarm 1)
    C -.-> F(Alarm 2..m)
    E -->|cycles, repeat_cycles| G(Action)
    E -->|recover_cycles| H(Recover action)
    E -->|error_repeat_cycles| I(Error action)
    E --> J(Error recover action)

    style C fill:green;
    style D fill:green;
    style E fill:red;
    style F fill:red;
    style G fill:blue;
    style H fill:blue;
    style I fill:blue;
    style J fill:blue;

警报状态机

每个警报有三种可能的状态："良好"、"不良"和"错误"。
需要连续的cycles个不良数据点才能从"良好"状态转换为"不良"状态，需要recover_cycles个良好的数据点才能返回。这些转换将触发action和recover_action操作。在"不良"状态下，action会在每个repeat_cycles周期（如果repeat_cycles不为0）再次触发。

"错误"状态有些特别，因为它只"掩盖"其他状态。错误表示完全没有数据可用，例如无法确定/home的文件系统使用情况。由于这种情况很少发生，因此转换到错误状态总是在第一次周期触发error_action。如果下一个周期有有效数据，状态机将继续像错误状态不存在一样继续，并触发error_recover_action。

stateDiagram-v2
    direction LR

    [*] --> Good
    Good --> Good
    Good --> Bad: action/cycles
    Good --> Error: error_action

    Bad --> Good: recover_action/recover_cycles
    Bad --> Bad: repeat_action/repeat_cycles
    Bad --> Error: error_action

    Error --> Good: error_recover_action
    Error --> Bad: error_recover_action
    Error --> Error: error_repeat_action/error_repeat_cycles

示例

每分钟检查位于/home的挂载点。如果使用率连续3次周期（即3分钟）超过70%，则"警告"警报会触发"Webhook 1"操作。该操作会每隔100个周期重复，直到"警告"警报恢复。这发生在连续5个周期低于70%之后，也会触发"Webhook 1"操作。如果在检查文件系统使用时发生错误，将触发"记录错误"操作。这会每隔200个周期重复。

配置

[[checks]]
interval = 60
name = "Filesystem usage"
type = "FilesystemUsage"
mountpoints = ["/home"]

[[checks.alarms]]
name = "Warning"
level = 70
cycles = 3
repeat_cycles = 100
action = "Webhook 1"
recover_cycles = 5
recover_action = "Webhook 1"
error_repeat_cycles = 200
error_action = "Log error"

[[actions]]
name = "Webhook 1"
type = "Webhook"
url = "https://example.com/hook1"
body = """{"text": "{{check_name}}: Alarm '{{alarm_name}}' for mountpoint '{{check_id}}' changed state to *{{alarm_state}}* at {{level}}."}"""
headers = {"Content-Type" = "application/json"}

[[actions]]
name = "Log error"
type = "Log"
level = "Error"
template = """{{check_name}} check didn't have valid data for alarm '{{alarm_name}}' and id '{{alarm_id}}': {{check_error}}."""

# This is a block comment. It demonstrates how to add another check and alarm.
# [[checks]]
# name = "System pressure"
# type = "PressureAverage"
# cpu = true
# avg60 = true
#
# [[checks.alarms]]
# name = "Warning"
# level = 80
# action = "Another action"

Webhook文本将被渲染为类似于"警告：挂载点'/home'的文件系统使用率达到了70%。"的形式。

图表

graph TD
    A(example.toml) --> B(Main loop)
    B -->|every 60 seconds| C(FilesystemUsage 1: '/srv')
    C -->|level '/srv': 60%| D(LevelAlarm 1: 70%)
    D -->|cycles: 3, repeat_cycles: 100| E(Action: Webhook 1)
    D -->|recover_cycles: 5| F(Recover action: Webhook 1)
    D -->|error_repeat_cycles: 200| G(Error action: Log error)

    style C fill:green;
    style D fill:red;
    style E fill:blue;
    style F fill:blue;
    style G fill:blue;

一些（更奇特）的想法

只是为了提供一些可能的想法

• 在您的办公工作站上本地运行它，并使用"进程"操作和notify-send在文件系统填满时发送通知到您的桌面环境。
• 将报告与Webhook操作和telepush结合使用，并让它在您的Telegram消息应用中每周发送一次"我还在，自{{minmon_uptime_iso}}以来一直如此！"以安心。

占位符

为了提高动作的可重用性，可以为报告、事件、检查、警报和动作定义自定义占位符。当触发动作时，占位符（通用和自定义）将合并到最终的占位符映射中。在动作内部（根据动作的类型），可以使用占位符在配置字段中（一个或多个）使用以下语法：{{placeholder_name}}。还有一些始终可用的通用占位符。在动作触发时没有值的占位符将被空字符串替换。

过滤器

过滤器可以应用于转换测量数据。这有不同的用途。例如

• 补偿测量中的波动。
• 确定多个周期内的总网络流量。

它们可以配置为检查，在这种情况下，它们会影响属于检查的所有警报或单个警报。这两种选项在某些情况下减少了配置文件中的重复。检查是首选的过滤位置，因为它只为所有警报执行一次，从而减少了内存和CPU的使用。

安装

Docker镜像

要拉取Docker镜像，请使用

docker pull ghcr.io/flo-at/minmon:latest

或示例docker-compose.yml文件。
在这两种情况下，将配置文件以只读方式挂载到/etc/minmon.toml。

使用cargo构建和安装

确保您的本地机器上正确安装了cargo和OpenSSL。
您可以使用以下命令从crates.io安装MinMon：

cargo install --all-features minmon

或者如果您已经检查出了仓库，您可以像这样构建和安装本地副本

cargo install --all-features --path .

将systemd.minmon.service文件复制到/etc/systemd/system/minmon.service，并将配置文件放在路径/etc/minmon.toml。您可以使用以下命令启用和启动服务：systemctl daemon-reload && systemctl enable --now minmon.service。

从AUR（Arch Linux）安装

使用您选择的包管理器安装来自AUR的minmon包。
将您的配置文件放在路径/etc/minmon.toml。您可以使用以下命令启用和启动服务：systemctl daemon-reload && systemctl enable --now minmon.service。

systemd集成（可选）

使用--features systemd构建以启用对systemd的支持。

• 将日志记录到日志。
• 通知systemd启动完成（Type=notify）。
• 定期重置systemd看门狗（WatchdogSec=x）。

lm_sensors集成（可选）

使用--features sensors构建以启用对lm_sensors的支持。
对于Docker镜像，可选地将您的lm_sensors配置文件挂载到/etc/sensors.d/。
注意：libsensors不合作，理论上可能会阻止事件循环。

贡献

请参阅CONTRIBUTING.md