Куда пакету / opt следует записывать журналы?

for i in *.xml; do TMP=${i%.xml}; echo ${TMP:(-6)};done
13
27.03.2017, 15:01
2 ответа

Поскольку вы следуете соглашениям FHS для файлов конфигурации пакета, вы должны быть последовательны и хранить файлы журнала в /var/opt/package_name/log.

FHS гласит:

Переменные данные пакетов в /opt должны быть установлены в /var/opt/

а также гласит

Никакие другие файлы пакетов не могут существовать вне иерархии /opt, /var/opt и /etc/opt, за исключением тех файлов пакетов, которые должны находиться в определенных местах в дереве файловой системы для правильного функционирования. Например, файлы блокировки устройств должны быть размещены в /var/lock, а устройства - в /dev.

Размещение файлов журнала в /var/opt не мешает пакету работать правильно, поэтому использование /var/log вместо этого явно нарушает стандарт.

Неясно, что вы имеете в виду под "можно ли это обнаружить?", поскольку ваши пользовательские журналы, скорее всего, будут обрабатываться пользовательскими инструментами, но если предположить, что общий инструмент предназначен для их обработки, то он должен исследовать стандартное местоположение для таких пакетов, как ваш.

Обратите внимание, что syslog является полезным средством для централизации и настройки конфигурации журналов, но не полностью решает вопрос о том, где хранить журналы, если вам приходится делать это в обычных файлах с хорошо известным путем. Некоторые файлы, иногда хранящиеся в каталоге журнала приложения, предназначены для доступа по ожидаемому пути самим приложением или связанными с ним программами, например, файл, хранящий идентификатор процесса, поэтому syslog для них не работает.

8
27.01.2020, 19:52

Я бы поместил их в /var/log/имя_пакета; он лучше удовлетворяет принципу наименьшего удивления, чем /var/opt/package_name/log. У меня нет цитаты для этого; это просто соответствует тому, где я буду искать журналы.

Я мог бы также отказаться от написания собственных лог-файлов и вместо этого регистрироваться в syslog с соответствующим тегом и средством; если я ищу чистую интеграцию с установленными инструментами анализа, я не думаю, что смогу добиться большего успеха для канала связи:

  • Каждый общий инструмент с «анализом журнала» в качестве перечисленной функции уже просматривает syslog.
  • Освобождение файла журнала и семантика ротации выполняются за меня; Мне не нужно настраивать механизм для logrotate, чтобы сказать мне отпустить файл и открыть новый. Мне даже не нужно сообщать logrotate о новых файлах для ротации!
  • Выгрузка журналов на центральные серверы журналов выполняется за меня, если этого требует сайт; Существующие установленные инструменты, такие как rsyslog, будут использоваться при необходимости, поэтому мне не нужно думать о реализации этой функции самостоятельно.
  • Контроль доступа (POSIX и, например, SELinux) вокруг файлов журналов уже реализован, поэтому мне не нужно уделять столько внимания семантике безопасности конкретного дистрибутива.

Если только я не использую какой-то пользовательский двоичный формат для своего журнала, и даже в этом случае, я предпочитаю удобные для системного журнала текстовые форматы с машинным анализом, такие как JSON. Мне трудно оправдать свои собственные отдельные файлы журналов; инструменты анализа уже следят за syslog как ястреб.

19
27.01.2020, 19:52

Теги

Похожие вопросы