有人可以解释一下默认 munin 图表的“用例”吗?

有人可以解释一下默认 munin 图表的“用例”吗?

安装 munin 时,它会激活一组默认插件(至少在 ubuntu 上)。或者,您可以直接运行munin-node-configure以找出您的系统支持哪些插件。大多数这些插件都会绘制直接数据。我的问题是不是解释数据的性质(嗯……也许对某些人来说是这样),但是什么这就是您在这些图表中寻找的东西吗?

安装 munin 并查看精美的图表很容易。但如果有图表却不能“读取”它们,它们就完全没用了。

我将列出我的系统上默认启用的标准插件。所以这将是一个很长的列表。为了完整起见,我还将列出我认为可以理解的插件,并简要说明我认为它们的用途。如果我对其中任何一个有误,请纠正。

因此,让我将这个问题分为三个部分:

  • 我甚至不明白数据的插件
  • 我了解数据但不知道应该注意什么的插件
  • 我认为可以理解的插件

我甚至不明白数据的插件

这些问题可能不一定只针对 munin。不理解数据通常意味着在操作系统/硬件方面存在基础知识方面的差距……;)请随意用“giyf”回答。

这些插件我只能猜测这是怎么回事啊……我都快不想看这些“猜测”了……

  • 每个设备的磁盘 I/O 数(I/O/秒)
    什么是 IO。我知道它代表输入/输出。但仅此而已。
  • 每个设备的磁盘延迟(平均 IO 等待时间)
    不知道“IO 等待”是什么......
  • IO 服务时间
    这是一个巨大的混乱,几乎不可能在图表中看到任何东西。

我了解数据但不知道应该注意什么的插件

  • IOStat(块/秒读取/写入)
    我猜,这里要注意的是峰值?这意味着设备使用频率很高吗?
  • 可用熵(字节)
    我认为这对于随机数生成很重要?我为什么要绘制这个图表?到目前为止,该值一直接近恒定。
  • VMStat(正在运行/I/O 睡眠进程)
    这个图和“进程”图有什么区别?两者都显示正在运行/休眠的进程,而“进程”图似乎包含更多详细信息。
  • 每个设备的磁盘吞吐量(读取/写入的字节数/秒)
    这个和“IOStat”图表有什么区别?
  • inode 表使用情况
    我应该在此图表中寻找什么?

我认为可以理解的插件

我会在这里猜测一些事情...如果我错了,请纠正我。

  • 磁盘使用率百分比(百分比)
    已使用/剩余多少磁盘空间。由于该值接近 100%,您应该考虑清理或扩展分区。这是极其对于根分区来说很重要。
  • 防火墙吞吐量(数据包/秒)
    通过防火墙的数据包数量。如果该数量长时间处于峰值状态,则可能是 DOS 攻击的迹象(或者我们只是在接收一个大文件)。它还可以让您了解防火墙的性能。如果该数量趋于平稳,并且您需要更多“功率”,则应考虑负载平衡。如果该数量趋于平稳并且与您的 CPU 负载相关,则也可能意味着您的硬件速度不够快。与磁盘使用率的相关性可能表明您的 FW 配置中的 LOG 目标过多。
  • eth0 错误(数据包输入/输出)
    网络错误。如果此值增加,则可能是硬件故障的征兆。
  • eth0 流量(比特/秒输入/输出)
    原始网络流量。这应该与防火墙吞吐量相关。
  • 线程数
    不断增加的值可能表示进程未正确关闭线程。请调查!
  • 进程
    活动进程(包括休眠进程)崩溃。此处的快速峰值可能表示存在 fork 炸弹。缓慢但不断增加的值可能表示应用程序生成了子进程但未正确关闭它们。使用 进行调查ps faux
  • 进程优先级
    这显示了进程优先级的分布。只有高优先级的进程没有多大用处。考虑降低一些进程的优先级。
  • CPU使用率
    相当简单。如果出现峰值,则可能是正在发生攻击,或者某个进程正在占用 CPU。如果在正常运行时,该值缓慢增加并接近最大值,则应考虑升级硬件(或负载平衡)。
  • 文件表使用情况
    主动打开的文件数。如果达到最大值,则可能有一个进程正在打开,但无法正确释放文件。
  • 平均负载
    显示系统负载的汇总值。应与 CPU 使用率相关。增加的值可能来自多个来源。查找与其他图表的相关性。
  • 内存使用情况
    内存的图形表示。只要有大量未使用的+缓存+缓冲区,就没问题。
  • 换入/换出
    显示交换分区上的活动。该值应始终为 0。如果您看到该分区上有活动,则应为机器添加更多内存!

答案1

每个设备的磁盘 I/O 数(I/O/秒)

对于传统硬盘来说,这是一个非常重要的数字。I/O 操作是对磁盘的读取或写入操作。使用旋转主轴,您可以获得每秒数十到 200 IOPS 的速度,具体取决于磁盘速度及其使用模式。

这并不是全部:现代操作系统确实有 I/O 调度程序,它们会尝试将多个 I/O 请求合并为一个,从而加快处理速度。此外,RAID 控制器等也会执行一些智能 I/O 请求重新排序。

每个设备的磁盘延迟(平均 IO 等待时间)

从对单个磁盘执行 I/O 请求到实际从那里接收数据需要多长时间。如果这个时间在几毫秒左右,则表示一切正常;如果是几十毫秒,则表示磁盘子系统开始出汗;如果是几百毫秒以上,则表示问题很大,或者至少系统非常非常慢。

IO 服务时间

您的磁盘子系统(可能包含许多磁盘)的整体运行情况。

IOStat(块/秒读取/写入)

每秒读取/写入多少个磁盘块。查找峰值和平均值。如果平均值开始接近磁盘子系统的最大吞吐量,则是时候计划性能升级了。实际上,在此之前就做好计划。

可用熵(字节)

有些应用程序确实希望获得“真正的”随机数据。内核从多个来源收集“真正的”随机性,例如键盘和鼠标活动、许多主板上的随机数生成器,甚至视频/音乐文件(video-entropyd 和 audio-entropyd 可以做到这一点)。

如果您的系统耗尽了熵,那么需要该数据的应用程序就会停滞,直到它们获得数据为止。我个人过去曾亲眼目睹过 Cyrus IMAP 守护程序及其 POP3 服务出现这种情况;它在每次登录前生成一个很长的随机字符串,并且在一个非常快地消耗熵池的繁忙服务器上。

解决该问题的一种方法是切换应用程序以仅使用半随机数据(/dev/urandom),但这不再是本主题的一部分。

VMStat(正在运行/I/O 睡眠进程)

之前没有想过这个问题,但是我认为这可以告诉你每个进程的 I/O 统计信息,或者主要是它们是否正在运行某些 I/O,以及该 I/O 是否阻止 I/O 活动。

每个设备的磁盘吞吐量(读取/写入的字节数/秒)

这纯粹是字节每秒读取/写入,而且通常这是比人类可读的形式,可能会有所不同。块大小可能会因使用的磁盘、使用的文件系统(及其设置)等而有所不同。有时块大小可能是 512 字节,有时是 4096 字节,有时是其他大小。

inode 表使用情况

对于具有动态 inode 的文件系统(例如 XFS),则什么都没有。对于具有静态 inode 映射的文件系统(例如 ext3),则一切都会好转。如果您拥有静态 inode、大型文件系统以及大量目录和小文件的组合,您可能会遇到无法在该分区上创建更多文件的情况,即使理论上会剩下大量可用空间。没有可用的 inode == 不好。

相关内容