HighLoad.org – блог о высоких нагрузках
HighLoad.org > Масштабируемое логирование посредством Syslog

Масштабируемое логирование посредством Syslog
2010-03-01 02:27 my_fess  
Syslog - это обычно используемый механизм транспорта для системных логов. Но люди иногда забывают, что его можно также использовать и для многих других целей.
Возьмем, например, интересную задачу агрегации логов веб серверов со 100 различных серверов на один сервер и дальнейшее их слияние. Если вы разработали свой собственный инструмент для этого, вы должны были обнаружить, насколько это невыгодно опрашивать все серверы, и насколько устаревшими становятся эти логи, к началу обработки. Если вы не вставляете их в какое-то хранилище, которое сортирует записи по timestamp, вам также приходится решить задачу написания скрипта для слияния-сортировки. Нет ничего, что бы мешало приложениям использовать syslog. Если ваши приложения написаны на Java, вам стоит попробовать  Syslog appender для log4j [1] [2]. Вы получаете не только возможность централизованного ведения логов, но также возможность выполнять в реальном времени "tail -f" для просмотра событий по мере их появления в объдиненном файле. Вы можете просмотривать любые происшествия в вашей сети в одном месте. Если ваш объем логов большой, вам придется использовать другие инструменты (или разработать свой собственный) для анализа логов. Вот несколько моментов, которые вам стоить обдумать, если вы планируете использовать syslog в вашем окружении.
  1. Установите отдельные syslog серверы для каждого из ваших датацентров, используя split DNS или различные имена хостов
  2. Старайтесь не пересылать данные по WAN соединениям.
  3. Выполняйте ротацию логов в ночное время или в зависимости от их объема.
  4. Уменьшите количество регистрируемых событий (например, исключите отладочное логирование в пролакшн окружении) .
  5. Напишите инструменты для определения изменения объема логов в dev/qa окружении. Если вы следуете практике хорошего логирования, вы должны быть способны быстро определить компоненты, которые ответственны за увеличение объема.
  6. Определите образцы логов, которые могут быть причиной беспокойства и настройте какое-нибудь оповещение используя свою обычную службу мониторинга (например, nagios). Не бойтесь использовать сторонние инструменты, которые хорошо справляются с этим.
  7. Syslog работает поверх UDP в неблокирующем режиме, но syslog сервер может быть перегружен, если объем логов не контролируется. Самое узкое место при ведении логов - это дисковый ввод/вывод.
  8. UDP не гарантирует, что каждое регистрируемое событие дойдет до syslog сервера. Определите какой уровень погрешности при регистрации событий допустим в вашем окружении.
Другие интересные наблюдения:
  1. Количество изменений, которые необходимо внести в java приложение, которое уже использует log4j, чтобы оно заработало с syslog - тривиально.
  2. Логирование в локальные файлы может быть отключено, что означает, что вам не придется беспокоиться о дисковом пространстве на каждом сервере.
  3. Если вы используете, или хотите использовать инструменты вроде splunk или hadoop/hbase для анализа логов, то syslog - это простейший путь к этому.
  4. Вы можете управлять балансировкой нагрузки на syslog серверы, используя DNS балансировку нагрузки.
  5. Apache веб серверы, не умеют "из коробки" работать с syslog, но это все же можно настроить.
  6. Мне лично больше нравится haproxy, и он умеет работать с syslog "из коробки".
  7. Если вы хотите регистрировать события из startup/shutdown скриптов, вы можете использовать *nix команду "logger" для отправки событий на syslog сервер.
А как происходит агрегация логов в вашем окружении? Ссылки:

Автор статьи: Royans Tharakan Дата: 25 февраля 2010 Оригинал статьи


комментарии [0]  | комментировать

  © 2010-2018 HIGHLOAD