ad 1) в зависимости от используемого метода вы можете определить интервал ротации файлов плюс команду перемещения файлов с суффиксом их временной метки. существуют известные аддоны для графических файлов, такие как pnp4nagios или ingraph, которые описывают это как свои требования - например, http://docs.pnp4nagios.org/pnp-0.6/config#bulk_mode_with_npcd что касается ротации ядром - вам нужно убедиться, что $ something обрабатывает файлы данных о производительности - и вы должны следить за этой обработкой, чтобы не закончиться «файловая система заполнена» или что-то подобное.
ad 2) прямая передача данных из ядра во внешний обработчик возможна путем определения команды, выполняющей это, но имейте в виду, что это не произойдет асинхронно и может заблокировать ядро - ваше приложение обработки должно принимать передаваемые данные, и затем сам поставил в очередь. это также может вызвать проблему, если база данных отсутствует - если ваш обработчик не может убить себя из-за тайм-аута соединения, это повредит общей производительности вашего ядра мониторинга (да, это известная проблема архитектуры 1.x, которая является почему файлы спула на диске - лучший подход).
объявление 3) не уверен, правильно ли я понял, но есть некоторые вещи, которые вы действительно должны помнить при использовании файлов спула на диске
- если ротация происходит между разными файловыми системами, inode mv займет больше времени, чем на той же
- при использовании той же файловой системы убедитесь, что ваше нижележащее оборудование (raid, hdd) достаточно быстрое
- вы, конечно, должны поместить все временные данные, созданные icinga, в ту же файловую систему, но не в ту же файловую систему, где находится ваша база данных или хранилище rrdtool.
- если вас не интересуют необработанные данные спула, создайте tmpfs и настройте их там
- не используйте расширенные файловые системы с функцией моментальных снимков / резервного копирования для таких переходных данных, как zfs / xfs / btrfs - это значительно снизит производительность в крупномасштабных системах.
- отслеживать ожидание io и использование ваших файловых систем, чтобы получить представление о возможных узких местах
- если впоследствии обработка происходит с помощью rrdtool, обязательно используйте rrdcached для ускорения обработки приложения
возврат к синхронному режиму потребует, чтобы ваше приложение обработки само использовало своего рода очередь, а это не то, что будет использовать прямой доступ к базе данных. даже инграф (https://www.netways.org/projects/ingraph/wiki) создается с помощью демона-сборщика, который затем вставляет данные в базу данных. Короче говоря, делать это с 1.x опасно, тогда с icinga2 это будет возможно, имея собственный механизм очередей.
person
dnsmichi
schedule
08.06.2013
