Logreplica: сбор логов со всего кластера в единую точку в реальном времени

Я продолжаю делиться полезными утилитами, которые использую в различных проектах. На этот раз речь пойдет о logreplica — простом инструменте, который позволяет организовать надежную передачу логов с разных серверов кластера на единую машину с большими дисками «в реальном времени». Это очень удобно, если вы хотите централизованно мониторить или анализировать логи со всего кластера так, как будто бы они пишутся напрямую на единственную машину.

Можно сказать, что logreplica задумывался как более удобный и надежный способ сбора логов в центральное место, нежели способ использования настроек syslog/syslog-ng.

Преимущество logreplica — в простоте конфигурирования: вы единственный раз настраиваете «маску» имен лог-файлов и задаете адреса машин-источников, и в дальнейшем логи, соответствующие маске, автоматически и «на лету» складываются на центральную машину (в том числе если на машинах-источниках появляются новые лог-файлы, неизвестные на момент старта logreplica). При добавлении новой машины на ней не нужно ничего донастраивать: достаточно включить ее имя в конфиг-файл.

Пример конфига /etc/dklab_logreplica.conf

# What directory at the current machine to store logs to.
destination = /var/log/cluster

# Skip these log files prefixes while storing to destination directory.
skip_destination_prefixes = /var/log:/var/lib/pgsql/data/logs

# Path to internal state directory (may not change).
scoreboard = /var/run/dklab_logreplica.scoreboard

# Time interval to sleep before log growth checks.
delay = 0.25

# Default user to connect to remote hosts.
user = root

# What files to monitor at all of logs source machines.
[files]
/var/log/{messages,maillog}
/var/log/httpd/*_log

# What hosts to connect to gather logs from.
[hosts]
first=machine1.example.com
second=[e-mail]

Как установить и настроить logreplica

На машинах-источниках не нужно ничего настраивать: они сразу же оказываются в строю после прописывания в центральный конфиг-файл. Так что к logreplica можно свободно подключить несколько десятков серверов без их конфигурирования: все настройки располагаются в единственном файле /etc/dklab_logreplica.conf.

1. Выберите сервер, на которые будут складываться все логи; скопируйте дистрибутив logreplica в /opt/dklab_logreplica/.
2. Скопируйте инит-скрипт dklab_logreplica.init в /etc/init.d и настройте его автозапуск при загрузке машины (см. chkconfig, update-rc.d и др. утилиты Linux).
3. Скопируйте дефолтный конфиг dklab_logreplica.conf.sample в /etc/dklab_logreplica.conf и измените его согласно вашей системе:
   • задайте машины, с которых будут собираться логи;
   • укажите маски имен лог-файлов, которые нужно мониторить;
   • укажите директорию, куда в реальном времени будут копироваться логи.
4. Создайте закрытый+открытый ключ при помощи ssh-keygen -t rsa. Разложите открытый ключ по машинам, откуда будут скачиваться логи: ssh-copy-id root@machine-to-be-pulled. В итоге вы должны получить беспарольный доступ с лог-сервера на все машины-источники, иначе logreplica не сможет работать.
   
5. Теперь запустите /etc/init.d/dklab_logreplica start — и logreplica начнет отслеживать изменения в лог-файлах на машинах-источниках и складывать данные в директорию назначения.

Демон logreplica умеет восстанавливать связь с машинами-источниками, если она вдруг исчезнет из-за проблем в сети. При этом будут переданы все данные, которые накопились в логах за время простоя, так что ничего не потеряется. Также logreplica отслеживает ротацию логов на машинах-источниках и корректно ее обрабатывает.

Проблемы, которые решает logreplica

Предположим, в кластере есть несколько физических или виртуальных машин, выполняющих различные задачи (например, SQL-сервер, web-frontend, балансировщик, почтовый сервер и т. д.). Иногда хочется иметь логи со всех этих машин в едином месте — например, чтобы считать различную статистику или просто удобно (хоть даже и с помощью tail -f) следить за тем, что происходит во всей системе.

Конечно, можно настроить syslog или syslog-ng для передачи всех логов по сети на центральный лог-сервер, однако, если вы так сделаете, то столкнетесь с целым рядом неудобств:

1. В случае временных перебоев связи между машинами (такое случается, к сожалению, чаще, чем хотелось бы) куски логов могут потеряться, так что вы иногда будете терять данные.
2. Довольно сложно на практике поддерживать конфигурацию syslog или syslog-ng синхронизированной с реальным состоянием дел в кластере: новые машины могут добавляться, набор лог-файлов — меняться и т. д.
3. Не все сервисы поддерживают передачу логов в syslog (например, apache и nginx пишут их напрямую в файлы для минимизации задержек). Так что придется использовать именованные каналы (named pipes) для передачи данных в syslog, а значит, конфиги и зависимости будут расти и расти.
4. Часто хочется реплицировать лог-файлы на центральную машину по маске, а не жестко указав имя лог-файла. Syslog и syslog-ng этого делать не умеют.
5. Наконец, на практике оказывается очень удобно хранить логи не только на центральной машине, но и на той машине, где они создаются (на машине-источнике может при этом настраиваться более узкое «окно ротации»). Так что ваши конфиги syslog и syslog-ng снова растут...

Утилита logreplica как раз и создавалась с тем, чтобы решить все эти проблемы. В общем, логи просто «магическим» образом и в режиме реального времени оказываются на центральной машине, без каких-либо изменений в настройках сервисов и удаленных машин.

Ссылки: logreplica на dklab.ru, logreplica на GitHub. Пишите в комментариях, если знаете аналоги или имеете другое видение на описанную проблему.