Основной передовой практикой ведения журналов является централизация или объединение журналов в одном месте, особенно если у вас несколько серверов или уровней архитектуры. Современные приложения часто имеют несколько уровней инфраструктуры, которые могут включать в себя сочетание локальных серверов и облачных сервисов.
Попытка найти нужный файл для устранения ошибки может быть невероятно сложной, а попытка соотнести проблемы в разных системах - очень сложной. Нет ничего более неприятного, чем обнаружить, что нужная вам информация не была записана в файл журнала или что файл журнала, в котором потенциально может содержаться ответ, был потерян после перезапуска сервера.
Это руководство объясняет, как использовать службы централизации для сбора и централизации файлов журналов Linux.
Преимущества централизации журналов
Централизация журналов упрощает и ускоряет поиск данных журналов, поскольку все журналы доступны в одном месте. Вместо того чтобы гадать, на каком сервере находится нужный файл, вы можете просто обратиться к этому хранилищу журнальных данных для поиска соответствующих событий. Централизация является ключевой частью крупных решений по управлению, поскольку она позволяет анализировать, разбирать и индексировать журналы перед их хранением в одном месте, что помогает упростить поиск и устранение неисправностей и решение производственных проблем. Централизация журналов также может предложить следующие преимущества:
- Резервное копирование журналов осуществляется в отдельном месте, защищая их от случайной или непреднамеренной потери, что позволяет сохранить доступ к ним в случае сбоя или отсутствия реакции ваших серверов.
- Вам не придется использовать SSH или неэффективные команды grep, которые могут использовать ценные вычислительные ресурсы для сложного поиска.
- Вы можете сократить объем дискового пространства, используемого файлами журналов.
- Инженеры могут устранять неполадки на производстве без прямого доступа к системам.
Хотя централизованное управление журналами, как правило, является лучшим вариантом, все же существуют некоторые риски, такие как плохое подключение к сети, приводящее к потере данных, или журналы, использующие большую пропускную способность сети. Ниже мы обсудим, как грамотно решить эти проблемы.
Популярные инструменты для централизации журналов
Большинство систем Linux уже централизуют журналы с помощью демона syslog. Как мы объясняли в разделе Основы ведения журналов Linux, syslog - это служба для сбора журналов от служб и приложений, работающих на хосте. Он может записывать эти журналы в файл или пересылать их на другой сервер по протоколу Syslog. Существует несколько реализаций syslog, которые вы можете использовать, включая:
- rsyslog: легкий демон, установленный в большинстве распространенных дистрибутивов Linux.
- syslog-ng: второй по популярности демон syslog для Linux.
- logstash: более тяжелый агент для более сложной обработки и разбора. Он может читать сообщения syslog с помощью плагина syslog input и направлять их в любое количество мест вывода.
- fluentd: еще один агент с расширенными возможностями обработки. Он также поддерживает ввод syslog с помощью плагина in_syslog.
Rsyslog является наиболее популярной реализацией syslog и устанавливается по умолчанию во многих дистрибутивах Linux. Если вам нужны более продвинутые возможности фильтрации или пользовательского разбора, Logstash является следующим по популярности выбором. Logstash также тесно интегрирован с Elastic Stack. В этом руководстве мы сосредоточимся на использовании rsyslog, поскольку он так широко распространен.
Настройка rsyslog.conf
Основной файл конфигурации rsyslog находится по адресу /etc/rsyslog.conf. Вы можете хранить дополнительные файлы конфигурации в каталоге /etc/rsyslog.d/. Например, в Ubuntu этот каталог содержит /etc/rsyslog.d/50-default.conf, который предписывает rsyslog записывать системные журналы в файл. Подробнее о конфигурационных файлах вы можете прочитать в документации по rsyslog.
Конфигурирование rsyslog включает в себя настройку входных источников (откуда rsyslog получает журналы), а также правил назначения, куда и как записываются журналы. Rsyslog уже предоставляет настройки по умолчанию для получения событий syslog, поэтому обычно вам нужно только добавить ваш сервер централизации в качестве выходного источника. Rsyslog использует RainerScript для своего синтаксиса конфигурации. В этом примере мы перенаправляем наши журналы на сервер central.example.com через TCP-порт 514.
| 1 | action(type="omfwd" protocol="tcp" target="central.server.com" port="514") |
В качестве альтернативы мы можем отправить журналы в решение для управления журналами.
Файлы и каталоги журналов
Rsyslog предоставляет модуль imfile, позволяющий отслеживать файлы журналов на предмет новых событий. Это позволяет вам указать файл или каталог в качестве источника журнала. Rsyslog может отслеживать как отдельные файлы, так и целые каталоги.
Например, мы хотим отслеживать файлы журналов, созданные сервером Apache. Мы можем сделать это, создав новый файл в /etc/rsyslog.d/ под названием apache.conf, загрузив модуль imfile и добавив файлы журнала Apache в качестве входных данных.
| 1 2 3 4 5 | # Журнал доступа Apache: input(type="imfile" File="/var/log/apache2/access.log" Tag="apache-access" Severity="info") # Файл ошибок Apache: input(type="imfile" File="/var/log/apache2/error.log" Tag="apache-error" Severity="warning") |
Параметр File поддерживает подстановочные знаки для мониторинга нескольких файлов, а также каталогов.
Какой протокол: UDP, TCP или RELP?
Существует три основных протокола, которые вы можете выбрать при передаче данных журнала: UDP, TCP и RELP.
- UDP отправляет сообщения без гарантии доставки или подтверждения получения (ACK). Он делает одну попытку отправить пакет, и если доставка не удалась, он не повторяет попытку. Этот протокол часто намного быстрее и использует меньше ресурсов, чем другие протоколы, но его следует использовать только в надежных сетях, таких как localhost. UDP также не поддерживает шифрование журналов.
- TCP - наиболее часто используемый протокол для потоковой передачи данных через Интернет, поскольку он требует ACK перед отправкой следующего пакета. Если доставка не удалась, он будет повторять попытки до тех пор, пока не доставит сообщение успешно. Однако TCP требует квитирования и активного соединения между отправителем и получателем, что использует дополнительные сетевые ресурсы.
- RELP разработан специально для rsyslog и является, пожалуй, самым надежным из этих трех протоколов. Он подтверждает получение данных на прикладном уровне и повторно отправляет их в случае ошибки. Так как он менее распространен, вам нужно убедиться, что ваше место назначения также поддерживает этот протокол.
Если rsyslog столкнется с проблемой при хранении журналов, например, с недоступным сетевым соединением, он поставит журналы в очередь до восстановления соединения. По умолчанию журналы, поставленные в очередь, хранятся в памяти. Однако память ограничена, и если проблема сохранится, журналы могут превысить объем памяти, что приведет к потере данных. Чтобы предотвратить это, рассмотрите возможность использования дисковых очередей.
Вы можете потерять данные, если будете хранить журналы только в памяти.
Надежная отправка с помощью очередей с поддержкой дисков
Rsyslog может ставить ваши журналы в очередь на диск, когда память заполнена. Очереди с поддержкой диска могут сделать транспортировку журналов более надежной. Вот пример того, как настроить правило пересылки журналов в rsyslog с очередью с поддержкой диска.
| 1 2 3 4 5 6 7 8 9 | action(type="omfwd" # Использовать с модулем omfwd protocol="tcp" # Использовать протокол TCP target="myserver" # Адрес целевого сервера port="6514" # Порт целевого сервера queue.filename="fwdRule1" # Префикс для файлов резервных копий, создаваемых на диске queue.maxDiskSpace="1000000000" # Резервирование 1 ГБ дискового пространства queue.saveOnShutdown="on" # Сохранять сообщения на диск при выключении. queue.type="LinkedList" # Распределять память динамически action.resumeRetryCount="1" # Продолжать попытки, если с целевым сервером не удается связаться) |
Шифрование журналов с помощью безопасности транспортного уровня (TLS)
Если вас беспокоит безопасность и конфиденциальность данных, вам следует подумать о шифровании журналов. Шпионы и посредники могут прочитать данные журнала, если вы передаете их через Интернет открытым текстом. Вам следует шифровать журналы, если они содержат частную информацию, важные идентификационные данные или данные, регулируемые правительством. Демон rsyslog может шифровать журналы с помощью протокола TLS и обеспечивать безопасность ваших данных.
Процесс включения шифрования TLS зависит от настроек ведения журнала. Как правило, он включает в себя следующие шаги:
- Создайте центр сертификации (ЦС). В каталоге rsyslog /contrib/gnutls есть образцы сертификатов, которые подходят только для тестирования - для производства вам нужно создать свой собственный. Если вы используете службу управления журналами, она уже готова предоставить вам такой сертификат.
- Сгенерируйте цифровой сертификат для вашего сервера, чтобы включить TLS, или используйте сертификат от поставщика услуг управления журналами.
- Настройте службу rsyslog на отправку зашифрованных TLS данных в службу управления журналами.
Вот пример конфигурации rsyslog с шифрованием TLS. Замените CERT и DOMAIN_NAME на собственные настройки сервера.
| 1 2 3 4 5 | $DefaultNetstreamDriverCAFile /etc/rsyslog.d/keys/ca.d/CERT.crt $ActionSendStreamDriver gtls $ActionSendStreamDriverMode 1 $ActionSendStreamDriverAuthMode x509/name $ActionSendStreamDriverPermittedPeer *.DOMAIN_NAME.com |
И перезапустите rsyslog.
| 1 | sudo systemctl restart rsyslog |
Лучшие практики ведения журналов приложений
Помимо журналов, которые Linux создает по умолчанию, хорошей идеей может быть централизация журналов важных приложений. Почти все серверные приложения на базе Linux записывают информацию о своем состоянии в отдельные, специальные файлы журналов. Сюда входят продукты баз данных, такие как PostgreSQL или MySQL, веб-серверы, такие как Nginx или Apache, брандмауэры, службы печати и обмена файлами, серверы каталогов и DNS и так далее.
Первое, что может сделать администратор после установки приложения, это настроить его. Приложения Linux обычно имеют файл .conf где-то в каталоге /etc. Он может находиться и в другом месте, но /etc - это первое место, где люди ищут файлы конфигурации. В зависимости от того, насколько сложным или большим является приложение, количество настраиваемых параметров может быть несколько или сотни. Обратитесь к документации приложения, чтобы узнать больше, или используйте команду locate, чтобы попытаться найти файл самостоятельно.
| 1 | locate postgresql.conf |
Пример
| 1 2 | /usr/pgsql-9.4/share/postgresql.conf.sample /var/lib/pgsql/9.4/data/postgresql.conf |
Установите стандартное местоположение для файлов журнала
Системы Linux обычно сохраняют свои файлы журналов в каталоге /var/log. Это хорошо работает, но проверьте, сохраняет ли приложение в определенном каталоге в /var/log. Если да, то отлично. Если нет, возможно, вы захотите создать специальный каталог для приложения в каталоге /var/log. Почему? Потому что другие приложения также сохраняют свои файлы журналов в каталоге /var/log, и если ваше приложение сохраняет более одного файла журнала - возможно, раз в день или после каждого перезапуска службы - может быть трудно просмотреть большой каталог, чтобы найти нужный файл.
Если в вашей сети работает более одного экземпляра приложения, этот подход также удобен. Подумайте о ситуации, когда у вас может работать дюжина веб-серверов. Если ваши журналы хранятся на центральном сервере syslog, как вы узнаете, в каком файле журнала содержатся журналы какого сервера? Ведя журнал каждого сервера в отдельном каталоге, вы будете точно знать, где искать неисправность любого сервера.
Используйте статическое имя файла
Многие приложения добавляют динамические данные в имена файлов журналов, например, текущую дату или метку времени. Это полезно для автоматического разделения журналов по дате, но усложняет поиск последнего файла для таких служб, как rsyslog. Однако лучшим подходом может быть использование неизменяемого имени для файла журнала, а затем использование logrotate для применения временной метки или номера к старым файлам журнала.
Добавление и ротация файлов журнала
Приложения должны добавлять существующие файлы журналов, а не перезаписывать их. Это помогает обеспечить захват всех строк журнала, и данные не будут потеряны, даже если приложение перезапустится. Однако со временем файлы журналов могут стать очень большими. Если вы пытаетесь найти первопричину проблемы, вы можете просмотреть десятки тысяч строк.
Мы рекомендуем складывать журналы в один файл, но также рекомендуем настроить приложение на частое вращение файлов журналов. Такие инструменты, как logrotate, могут делать это автоматически, копируя текущий файл журнала в новое место, присваивая ему уникальное имя, а затем усекая текущий файл журнала. Это может иметь несколько преимуществ, в том числе:
- Журналы разделяются по файлам по дате и времени, что облегчает поиск журналов за определенную дату.
- Каждый файл журнала значительно меньше, что облегчает его поиск и передачу по сети.
- Резервное копирование файлов журналов стало намного проще, а удаление или архивирование старых журналов может быть выполнено намного быстрее.
Частота ротации файлов журналов зависит от того, сколько журналов вы генерируете. В качестве эмпирического правила, начните с ротации журналов один раз в день.
Установка политики хранения файлов журналов
Как долго вы храните файл журнала? Это определенно зависит от требований бизнеса. Вас могут попросить хранить журнальную информацию в течение одной недели, или это может быть нормативное требование хранить данные в течение 10 лет. Что бы это ни было, журналы должны быть удалены с сервера в то или иное время.
В общем, если нет других требований, вам, вероятно, следует хранить файлы журналов как минимум за один месяц в режиме онлайн, а также копировать их во вторичное место (например, на сервер регистрации). Все, что старше, можно выгрузить на отдельный носитель.
Храните файлы журналов на отдельном диске
Файлы журнала пишутся постоянно, что может привести к высокому уровню дискового ввода-вывода на загруженных системах. В качестве лучшей практики вы можете смонтировать /var/log на отдельном устройстве хранения. Это позволит избежать того, что запись файлов журнала будет мешать работе ваших приложений (особенно на дисковых накопителях), а файлы журнала не будут заполнять весь диск, если они станут слишком большими.
Оформление записей в журнале
Какую информацию вы должны фиксировать в каждой записи журнала?
Это зависит от того, для чего вы хотите использовать журнал. Хотите ли вы использовать его только для устранения неполадок или фиксировать все происходящее? Является ли юридическим требованием фиксировать, что запускает или просматривает каждый пользователь?
Если вы используете журналы для поиска и устранения неисправностей, вам может понадобиться сохранять только ошибки, предупреждения или фатальные сообщения. Например, часто нет причин записывать отладочные сообщения. Иногда приложение может записывать отладочные сообщения по умолчанию, или другой администратор может включить эту функцию для устранения неполадок; однако, возможно, вам нужно отключить эту функцию, поскольку она может быстро заполнить пространство. Как минимум, достаточно фиксировать дату, время, имя клиентского приложения, IP-адрес источника или имя хоста клиента, выполненное действие и само сообщение.
Например, рассмотрим поведение журнала по умолчанию в PostgreSQL. Журналы хранятся в /var/log/postgresql, и каждый файл начинается с postgresql-, за которым следует дата. Файлы ротируются ежедневно, и к старым файлам добавляется номер, основанный на том, когда они были ротированы. К каждой строке журнала могут быть добавлены такие поля, как текущая метка времени, текущий пользователь, имя базы данных, идентификатор сессии и идентификатор транзакции. Вы можете изменить эти настройки, отредактировав файл конфигурации PostgreSQL (/etc/postgresql/11/main/postgresql.conf на Debian).
По умолчанию в каждой строке журнала отображается метка времени и идентификатор процесса PostgreSQL, за которым следует сообщение журнала.
| 1 | cat /var/log/postgresql/postgresql-11-main.log |
| 1 2 3 4 5 | 2023-05-14 15:53:16.109 EDT [609] LOG: received fast shutdown request 2023-05-14 15:53:16.131 EDT [609] LOG: aborting any active transactions 2023-05-14 15:53:16.143 EDT [609] LOG: background worker "logical replication launcher" (PID 754) exited with exit code 1 2023-05-14 15:53:16.147 EDT [748] LOG: shutting down 2023-05-14 15:53:16.215 EDT [609] LOG: database system is shut down |
Мониторинг файлов журнала с помощью imfile
Традиционно наиболее распространенным способом регистрации данных для приложений являются файлы. Хотя файлы удобно искать на одной машине, они плохо масштабируются при увеличении количества серверов. С помощью rsyslog можно отслеживать изменения в файлах и импортировать новые события в syslog, а затем пересылать журналы на централизованный сервер. Для этого используется модуль imfile. Чтобы включить модуль, создайте новый конфигурационный файл в /etc/rsyslog.d/, затем добавьте в него входной файл следующим образом:
| 1 2 3 4 5 6 7 8 | module(load="imfile" PollingInterval="10") # Опрос файлов журнала на предмет изменений каждые 10 секунд. # Файл 1 input(type="imfile" File="/path/to/file1" # Путь к вашему файлу журнала Tag="tag1" # Необязательный тег для применения к логам из этого файла Severity="error" # Степень серьезности журнала syslog для журналов из этого файла Facility="local7" # Объект, на который будут назначены эти журналы. |
Добавьте ваши потоки вывода после этой конфигурации, и rsyslog будет отправлять журналы из указанного файла в место назначения вывода.
Ведите журнал непосредственно в сокет Syslog с помощью imuxsock
Сокет похож на файловый хэндл UNIX, только он считывает данные в память, а не записывает их на диск. В случае с syslog это позволяет вам отправлять журналы непосредственно в syslog без необходимости записывать их в файл.
Этот подход позволяет эффективно использовать системные ресурсы, если ваш сервер ограничен дисковым вводом-выводом или у вас нет необходимости в локальных файловых журналах. Недостатком этого подхода является то, что сокет имеет ограниченный размер очереди. Если ваш демон syslog выйдет из строя или не сможет поддерживать работу, вы можете потерять данные журнала.
Чтобы включить протоколирование сокетов в rsyslog, добавьте следующую строку в конфигурацию rsyslog (по умолчанию она включена):
| 1 | $ModLoad imuxsock |
По умолчанию создается сокет на /dev/log, но вы можете изменить это, изменив параметр SysSock.Name. Вы также можете установить такие параметры, как ограничение скорости и управление потоком. Для получения дополнительной информации см. документацию rsyslog imuxsock.
Журналы UDP с помощью imupd
Некоторые приложения выводят данные журнала в формате UDP, который является стандартным протоколом при передаче файлов журнала по сети или через ваш локальный хост. Ваш демон syslog получает эти журналы и может обрабатывать или передавать их в другом формате. В качестве альтернативы вы можете отправить журналы на другой сервер syslog или решение для управления журналами.
Используйте следующую команду для настройки rsyslog на прием данных syslog по UDP через стандартный порт 514:
| 1 2 | $ModLoad imudp $UDPServerRun 514 |
Управление конфигурацией на многих серверах
Если у вас всего несколько серверов, вы можете вручную настроить ведение журнала на них. Если у вас несколько десятков или более серверов, вы можете воспользоваться инструментами, облегчающими и расширяющими эту задачу. На базовом уровне цель каждого инструмента - помочь вам включить syslog на каждом из ваших серверов, применить конфигурацию и убедиться, что изменения вступили в силу.
Pssh
Pssh (или параллельный SSH) позволяет выполнять команду SSH на нескольких серверах параллельно. Однако часто лучше всего использовать развертывание pssh только для небольшого количества серверов, так как если один из серверов выйдет из строя, вам придется подключаться к нему по SSH и выполнять развертывание вручную. Если у вас несколько отказавших серверов, то ручное развертывание на них может занять много времени.
Puppet/Chef
Puppet и Chef - это инструменты управления конфигурацией, созданные для автоматической настройки всех ваших серверов и приведения их в одинаковое состояние с одновременным мониторингом и синхронизацией. Puppet и Chef - это мощные инструменты, способные устанавливать программное обеспечение, создавать файлы, перезапускать службы и многое другое.
Kubernetes
Kubernetes - это инструмент оркестровки, созданный для управления контейнерами на нескольких узлах. Kubernetes может предоставить полную архитектуру протоколирования, которая автоматически собирает и записывает журналы контейнеров в файл на главной машине. Вы можете просмотреть журналы для конкретного Pod, выполнив команду kubectl logs <имя Pod>, что полезно для доступа к журналам приложений на удаленном сервере.
Docker
Docker использует контейнеры для запуска приложений независимо от базового сервера. Он часто используется в качестве среды выполнения контейнеров для таких оркестров, как Kubernetes, но может использоваться и как самостоятельная платформа.
Существует несколько способов ведения журнала из контейнеров Docker, в том числе:
- Ведение журнала через драйвер ведения журнала Docker на хост-систему (рекомендуемый метод).
- Перенаправление всех журналов контейнера в один выделенный контейнер для ведения журнала (так работает контейнер logspout).
- Ведение журнала в дополнительный контейнер для ведения журнала.
- Добавление агента протоколирования в контейнер.
Вы также можете использовать контейнеры Docker для сбора журналов с хоста. Если в контейнере работает служба syslog, вы можете либо отправлять журналы с хоста в контейнер через syslog, либо монтировать файлы журналов хоста внутри контейнера и использовать агент мониторинга файлов для чтения файлов.
Скрипты или агенты поставщика
Некоторые решения для управления журналами предлагают скрипты или агенты, позволяющие относительно легко отправлять данные с одного или нескольких серверов. Тяжелые агенты могут потреблять дополнительные системные ресурсы. Существуют также поставщики, которые могут интегрироваться с существующими демонами rsyslog для пересылки журналов без использования дополнительных ресурсов.