Что такое разумная политика журналов?
С одной стороны, хотелось бы все сохранить навсегда. С другой стороны, я не хочу тратить время на административные задачи и должен избегать переполнения дисков на производственных серверах.
Что такое разумная политика журналов? Какие существуют инструменты (бесплатные или нет), которые помогут вам реализовать политику.
Вы меняете журналы? Вероятно, это будет ваш лучший план действий. Использование logrotate позволяет очень легко сохранять старые журналы, сжимать их, если вы хотите, и хранить их столько, сколько захотите.
"/export/log/non-local/mail.log" {
daily
rotate 7
missingok
postrotate
/etc/init.d/syslog-ng reload >/dev/null
endscript
compress
notifempty
}
"/export/log/non-local/lab-submit" {
rotate 5
monthly
postrotate
/etc/init.d/syslog-ng reload >/dev/null
endscript
notifempty
} Это фрагмент одного из моих файлов logrotate. Первая строфа обновляет журнал почты каждый день, сохраняя старые копии в течение семи дней. "missingok" означает, что он проигнорирует файл, если он находится не там, где должен быть. Постротат. . . Раздел endcript содержит команды, которые будут запускаться после поворота файла. Сжатие говорит само за себя, по умолчанию используется gzip. Вы можете изменить сжатие, используя что-то вроде
compresscmd /usr/bin/bzip2 compressext .bz2
Журнал отправки в лабораторию обновляется один раз в месяц и хранится в течение 5 месяцев.
Надеюсь, это поможет. Я предполагаю (очевидно), что вы в настоящее время не вращаете свои журналы, что вы используете какой-то Linux, и что вы хотели бы использовать logrotate, в зависимости от вашего дистрибутива и типа журнала, который вы, возможно, не захотите использовать logrotate . Если какое-либо из моих предположений неверно, дайте мне знать, и я постараюсь пересмотреть свой ответ.
Мой общий образ действий зависит от объема диска, который я могу с комфортом поддерживать для информации журнала, при этом имея дело с этим случайным катастрофическим событием отладки, которое может вызвать резкое увеличение использования дискового пространства.
Всегда удаленное ведение журнала по следующим причинам:
На центральном сервере ведите журналы столько времени, сколько считаете нужным (или требуются). Обычно я храню [сжатые] журналы от 6 до 12 месяцев для отслеживания тенденций, но вам может подойти 1 или 2 месяца.
Локальное ведение журнала и ротация:
Локальное ведение журнала защищает вас на случай, если в какой-то момент вы потеряете подключение к сети.
Для некоторых вещей я хочу хранить журналы в течение длительного времени - например, мои журналы apache для исторического интереса. Но даже там у меня есть cron работа выполняется каждый день и / или неделю, чтобы сделать простой анализ уникальных посетителей, которые отправляются по почте в учетную запись Gmail, которую я создал специально для такого рода вещей.
Однако мой общий подход заключается в том, что я не хочу и не нуждаюсь большинство данных в этих журналах за более чем несколько дней.
Я уже знаю, что никогда не собираюсь «обходить стороной», когда дело касается графического или исторического анализа, потому что, честно говоря, я слишком занят своей «настоящей» работой :)
Если вы используете syslog сборщик, вам может потребоваться дольше хранить эти журналы - просто потому, что они собирают все с любого количества серверов, с которых вы собираете.
В последний раз у меня был syslog При настройке сервера у нас была пара старых DL180 с жесткими дисками на 18 ГБ, работающими под управлением Ubuntu. Оба перекрестно смонтированы через nfs (<othersys>/path/to/log @ <currentsys>/path/to/backup).
Мы ежедневно меняли журналы, сжимая через bzip2. Когда объем дискового пространства превышает 90%, мы отбрасываем самый старый файл.
Уже упоминалось ранее*, но вы также можете изучить анализатор журналов, например эпилог или Splunk как компонент вашей политики ведения журнала.
Что такое разумная политика журналов?
Что ж, в реальном мире нехватка денег и времени обычно мешает; но вот основные проблемы ИМХО:
а) Собирайте журналы в центральном репозитории. Собирайте журналы в одном безопасном месте, чтобы
б) Используйте поиск и фильтрацию в реальном времени для нарезки данных журнала, когда это необходимо.
в) Настроить оповещения. Настройте значимые предупреждения для вашей системы. Это во многом перекликается с другими системами, такими как Мунин или Nagios; они могут делать примерно то же самое. Какую систему вы предпочитаете предупреждать, зависит от вашего мнения и индивидуальных обстоятельств.
г) Хранить все не менее 90 дней. Вы можете выбросить менее важные данные по прошествии более 90 дней, если вам это нужно, но, возможно, в этом нет необходимости. Например, если вы используете MySQL с Механизм хранения архивов для исторических данных, тогда вы можете сохранить большой объемы данных дешево, но в основном доступны только для чтения и с плохой индексацией. Разделение данных на «горячие» и «ближние» может работать хорошо.
Хорошие и дешевые системы, которые позволяют все это? Я все еще ищу. Кажется, что решения разделены на два ИМХО: 1) системы с открытым исходным кодом / дешевые системы, основанные на базе данных и некоторых сценариях, и 2) дорогостоящие системы крупных предприятий, которые «мы помогаем вам с соблюдением нормативных требований». Ни то, ни другое не кажется мне подходящим.