Database Icinga性能数据：将管道直接导入数据库

我刚刚阅读了一些关于性能数据收集和处理的icinga文档。但我现在还不清楚一些事情：

写入文件/磁盘->这是否会滚动以及如何滚动

我想跳过磁盘“缓冲区”，直接通过管道进入后处理脚本，将数据放入外部数据库。这可能吗？如何实现？（我看到有一个管道模式，但我并不完全了解它是如何工作的，因为大多数示例和设置都使用这些文件）。如果无法访问数据库或数据接收过程可能死亡，则使用管道的风险是什么

如果使用了中间文件，则在忙盒上加载性能-我们遇到了一些高负载，不确定是否管道通过会更好（除了一些故障场景，请参阅第二个问题）

非常感谢

ps：在nagios下标记为icinga尚未提供，我到目前为止没有足够的分数；-）

ad 1）根据所使用的方法，您可以定义文件旋转间隔加上一个命令，用其时间戳后缀移动文件。有一些著名的grapher插件，比如pnp4nagios或ingraph，它们将这描述为它们的需求——例如。 关于核心的轮换，您需要确保$something处理性能数据文件，并且您应该监控该处理，以避免以“文件系统已满”或类似方式结束

ad 2）通过定义这样做的命令，可以将数据从核心直接管道传输到外部处理程序——但请记住，这不会异步发生，可能会阻塞核心——处理应用程序需要接收正在馈送的数据，然后将其自身放入队列中。如果数据库不存在，这也可能会产生问题-如果处理程序由于连接超时而无法自行终止，这将损害监视核心的整体性能（是的，这是1.x体系结构的一个已知问题，这就是为什么磁盘上的spool文件是更好的方法）

ad 3）不确定我是否正确理解，但在使用磁盘上的spool文件时，有一些事情确实应该记住

• 如果在不同的文件系统之间发生旋转，inode mv将比在同一文件系统上花费更长的时间
• 如果使用相同的文件系统，请确保底层硬件（raid、hdd）足够快
• 当然，您应该将icinga创建的所有临时数据放在同一个文件系统上，但与您的数据库或rrdtool存储所在的文件系统不同
• 如果您不关心未处理的假脱机数据，请创建一个tmpfs并在那里进行配置
• 不要对此类过渡数据（如zfs/xfs/btrfs）使用具有快照/备份功能的高级文件系统-这将显著降低大型系统的性能
• 监视io等待和文件系统的使用情况，了解可能的瓶颈
• 如果之后使用rrdtool进行处理，请确保使用rrdcached加快处理应用程序的速度

回到同步模式需要处理应用程序本身使用某种队列，而直接数据库访问不会使用这种队列。甚至ingraph（）都是使用收集器守护进程构建的，然后将数据插入数据库。简言之，使用1.x这样做是危险的，使用icinga2则有可能拥有自己的排队机制。

Great-ad1）非常有效！我们甚至多次转储它，每个后端都可以根据需要获取其数据。没有阻塞，只需关注icinga文件系统的大小！