主页 / server / 问题 / 766066
Accepted
Cédric Girard
Asked: 2016-03-26 02:11:20 +0800 CST

Munin：一切正常时的通知

  • 772

我使用一台 Munin-Master 监控 20 多台服务器，除一台服务器外，所有服务器都运行良好。收到的最后三封穆宁邮件：

05h25

infra :: backup2.infra :: 磁盘使用百分比 OKs：/var 是 22.55，/run/user/1001 是 0.00，/home 是 8.87，/mnt/usb1 是 30.55，/export/oxa 是 51.58，/tmp 是0.60，/dev/shm 是 0.00，/space2 是 40.39，/run 是 8.77，/run/lock 是 0.00，/run/user/65534 是 0.00，/space 是 76.38，/sys/fs/cgroup 是 0.00，/是 18.46。

infra :: backup2.infra :: Inode 使用百分比 OKs：/dev/shm 是 0.00，/run 是 0.05，/space2 是 7.44，/run/user/65534 是 0.00，/run/lock 是 0.00，/sys/ fs/cgroup 是 0.00，/space 是 0.24，/ 是 8.07，/dev 是 0.03，/home 是 0.13，/mnt/usb1 是 0.51，/export/oxa 是 0.01，/tmp 是 0.02，/var 是 2.02，/运行/用户/1001 是 0.00。

07:00

infra :: backup2.infra :: Inode 使用百分比 OKs：/home 是 0.13，/var 是 2.02，/run/user/1001 是 0.00，/dev/shm 是 0.00，/run 是 0.05，/run/lock 是0.00, /space 是 0.24, /run/user/1003 是 0.00, /tmp 是 0.02, / 是 8.07, /space2 是 7.44, /mnt/usb1 是 0.51, /export/oxa 是 0.01, /dev 是 0.03, / sys/fs/cgroup 为 0.00。

08h50

infra :: backup2.infra :: Inode 使用百分比 OKs：/run/user/1001 是 0.00，/tmp 是 0.02，/dev 是 0.03，/run/user/0 是 0.00，/dev/shm 是 0.00，/ run 是 0.05，/space 是 0.24，/sys/fs/cgroup 是 0.00，/mnt/usb1 是 0.51，/ 是 8.07，/home 是 0.13，/space2 是 7.44，/run/lock 是 0.00，/var 是 2.02 , /export/oxa 是 0.01。

infra :: backup2.infra :: 磁盘使用百分比 OKs: / 是 18.46, /mnt/usb1 是 30.62, /sys/fs/cgroup 是 0.00, /export/oxa 是 51.62, /run/lock 是 0.00, /var是 22.29，/space2 是 40.39，/home 是 8.87，/tmp 是 0.60，/run/user/1001 是 0.00，/space 是 76.49，/dev/shm 是 0.00，/run 是 9.27，/run/user/0为 0.00。

一切正常，主日志中没有错误，但我仍然收到很多这些消息。

这是关于这个节点的master上的日志

munin-update.log:2016/03/25 10:40:24 [警告]backup2.infra/backup2.admin2:4949 上的服务 nfs4_client 未返回标签 fsinfo munin-update.log:2016/03/25 10 的数据： 40:21 [警告] backup2.infra/backup2.admin2:4949 上的服务 nfs_client 没有返回标签删除的数据

munin-update.log:2016/03/25 09:55:06 [INFO] 在 29082 开始为 backup2.infra/backup2.admin2:4949 工作。munin-update.log:2016/03/25 09:55:06 [INFO] 节点 backup2.infra 将自己宣传为 backup2。munin-update.log:2016/03/25 09:55:12 [INFO]: 节点基础设施的 Munin 更新完成；backup2.infra (6.67 秒) munin-update.log:2016/03/25 09:55: 13 [INFO] 收获 Munin::Master::UpdateWorker。退出值/信号：0/0

通知配置

 contact.devs.command mail -s "Munin notification ${var:host}" [email protected] 
 contact.devs.always_send warning critical

这是此节点的配置文件（生成的，与所有节点一样）

[backup2.infra]
     address backup2.admin2
     use_node_name yes
     diskstats_latency.backup2_store_export.avgrdwait.warning :7
     diskstats_latency.backup2_store_export.avgwrwait.warning :7
     diskstats_latency.backup2_store_export.avgrdwait.critical :10
     diskstats_latency.backup2_store_export.avgwrwait.critical :10

Munin Master和节点版本：2.0.25-1（都是Debian Jessie）

我在哪里可以观看以了解和解决？

munin

3 个回答

  1. Best Answer

    Debian 中的df插件还检查动态安装的文件系统/run/user/<uid>，当用户登录时出现在这些文件系统下，当用户注销时这些文件系统消失。尽管所有级别都正常，但这种出现和消失被认为是触发电子邮件的更改。

    您应该能够通过创建一个名为/etc/munin/plugin-conf.d/df以下内​​容的文件来避免这种情况：

    [df*]
env.exclude_re /run/user/

    要检查您的设置是否有效并列出df插件考虑的路径，请使用以下命令：

    munin-run -d df

    如果您对结果满意，请重新启动 munin-node 服务 ( service munin-node restart)。

    • 7

  2. Debian 和派生发行版中的最新 Munin 应根据Debian 错误 #788736处理此问题。

    有关tmpfs 类型挂载（/run/user/* 是）的一些逻辑已在 Munin 上游项目中修复。据我所知，它们不被排除在公关之外。默认（可能是执行此操作的 Debian 特定配置）。

    • 1

  3. 对我来说，docker 卷是这个错误的另一个原因。

    我最终使用此配置来解决 @Oliver 的 /run/user 问题以及我的 docker 问题；

    [df*]
env.exclude_re ^(/run/user/|/var/lib/docker)
    • 0

相关问题