是的，所以我开始掌握（并且喜爱）zabbix，并且已经开始对其进行微调alerts。
我有一个在 Linux 服务器上触发的警报，因为它有超过 300 个进程。
现在，这是一种充当防火墙的中央服务器，并运行一堆东西，即 proxy/httpd-server/mysql/open-vpn/zabbix
在向 350 个进程弹出警报触发器之前有什么需要注意的吗？
CPU 负载仍然相对较低，我想在提高警报之前也许应该检查其他东西。
我是否需要检查机器是否在其他地方遇到瓶颈，即 I/O 限制？
对此有什么好的建议吗或者一如既往，良好的文档（希望写得好并且易于理解）将不胜感激。
答案1
就像 @sam 所说的，这完全取决于服务器正在做什么以及服务器硬件有多强大。仅运行少数极其占用 CPU、内存和/或 I/O 的进程就很容易使功能强大的服务器过载。特别是如果某些事情导致您的服务器发生交换，那么一切进展都会比蜗牛或乌龟慢。
另一方面，像 Postfix 服务器这样的程序可以轻松地拥有数百或数千个进程，因为 Postfix 所做的一切都是非常轻量级的。
在我看来，监控（或至少因为监控而发出警报）全局进程计数是没用的。不过，如果你确信某个进程的实例不应该超过 X 个，那么就可以监控它，并在突然出现超过 X 个实例时发出警报。
您还可以绘制一些进程数量的趋势图：例如，我倾向于绘制 Cyrus IMAP/POP 进程数图表，这样我就可以知道它们是否在当前硬限制附近徘徊。
如果你有一些可预测的流程行为，你可以使用类似普斯蒙用于自动重启/终止（可选日志记录/电子邮件，用于获取有关 psmon 处理的事件的信息）行为不当的进程。当然，Zabbix 也可用于此，但 psmon 非常易于配置以用于此类任务。
我要绘制图表并监控什么
一般来说，图形（并监控）至少以下内容：
- 平均负载
- 内存使用情况
- 磁盘使用情况
- CPU使用率
- 网络流量
- 如果需要的话，可以增加一些单独的流程
- 服务响应时间
- 服务器正常运行时间（是一个非常有用的图表；如果某个服务器开始出现故障并且需要经常重新启动，那么从图表中很容易发现问题开始的那一刻）
然后监视器至少以下内容：
- 是应该正常运行的进程，并且正确响应；在我看来，如果还不够，只需测试端口是否正常运行或进程是否存在。相反，如果您想检查 Web 服务器是否正在运行，请查看它是否返回 HTTP 200 OK，最好查看测试页面是否包含一些预期的字符串。
- 服务器 ping。如果 ping 失败，立即报警。
- 内核日志记录严重事件，例如 I/O 错误、SAN 环境多路径配置中的路径失败、内核崩溃、OOM 事件等
我希望这可以帮助你。 ：）
答案2
我认为如果没有更多的信息就很难回答这个问题，但我会尝试一下。
这取决于;
在单核服务器上有五个 FFMPEG 线程渲染高清视频可能太多了，但它可以非常顺利地运行数百甚至数千个 5 行 Python 脚本，没有任何问题。一般来说，监控您能想到的一切！如果它输出一个数字，监视它并记录它，你永远不知道你以后可能需要什么统计数据。进程数本身可能不是一个好的性能衡量标准，它与其他信息结合使用很有用，比如说，如果服务器刚刚宕机，查看正在运行的进程、CPU/负载、内存、磁盘 IO 等会很有用。但我可能会说，除非你能准确确定每个进程使用了多少 CPU/内存/等，否则它就没那么有用了。
假设您有一个非常可预测的应用程序，每个用户在服务器上启动一个进程，并且每个进程在进程运行期间持续使用 10MB 内存、1% 的可用 CPU 使用率和 1% 的可用磁盘 IO。假设系统的基本使用率始终为 3% 的 CPU 和 500MB 内存，并且除了您的应用程序之外，不会在机器上启动任何其他进程。由此可以很容易地预测在出现问题之前可以运行多少个线程，但我认为我从未见过使用率如此精确的应用程序。
更好的策略是监控特定进程使用的资源，例如，如果您正在使用 mod_php 运行 Apache 服务器，则监控进程的平均内存、CPU 和磁盘 IO httpd，这将使您更好地了解服务器实际在做什么。对进程使用情况发出警报并不那么有用，监控它才有用。有许多因素可以增加进程数量而不会对系统产生任何影响，但单个进程可能会导致服务器瘫痪。
总结
- 进程计数并不是一个有用的警报
- 你应该还在记录它
- 了解你的服务器正在做什么，并监控与之相关的内容