Как стать автором
Обновить

Комментарии 23

Подскажите, пожалуйста, куда лучше писать логи от своих приложений?
Если вы системный программист, который пишет системные приложения — /var/log/
Если очень популярные прикладные продукты — то в /var/log/app/
Если не очень популярные, или еще не уверены — в app/log/
Приложение собственное — web server на dotnet core.
сначала в логгер, типа serilog, log4net или nlog, а затем использовать sinks к любому удобному типу вывода — syslog, console, tcp, db etc.
НЛО прилетело и опубликовало эту надпись здесь

/var/log/'название вашего приложения'/и т.д.

/dev/null тоже подойдёт…
Спасибо, очень удобно! Теперь логи совсем не занимают места! Скажите, а как их теперь прочитать?
lnav /dev/null, вы вообще статью читали?
Логи своих приложений лучше писать в stdout и полагаться на супервизор (systemd, Docker) в плане их сохранения.
я бы еще добавил, что если логи предполагается анализировать машинным путем, то очень удобно хранить их в JSON формате
По строчно, событие — json объект, так удобнее всего (я обычно время храню в float unixtime в начале строки а уже после него через пробел/tab json).
я бы посоветовал в
~/.my_app/log/
НЛО прилетело и опубликовало эту надпись здесь
Если уж совсем правильно, то в $XDG_CONFIG_HOME/my_app/…

Ссылку знаете, а читать не умеете. Там ясно написано, что XDG_CONFIG_HOME для “user specific configuration files”. Журналы являются файлами настроек пользователя? Из всех каталогов подходит только $XDG_DATA_HOME/my_app.

я все понимаю, но совсем не упомянуть journald мне кажется неприличным
Тоже удивился, когда читал раздел про бинарные логи. Как будто бы и нет systemd нигде :) Но вообще статья-то всё равно очень полезная. Вообще, я бы хотел иметь какой-нибудь сайтик где можно было бы узнать куда какая софтина пишет и как это правильно искать.
У меня такой вопрос: Какие есть логи или другие возможности проанализировать причину Kernel Panic?

Неотключенные, сэр… И /var/spool/abrtd, если мне не изменяет память.


P.S. коллеги, не забывайте настраивать logrotate. Это правда очень важно, когда надо быстро разобрать инцидент.

Причину kernel palic можно узнать двумя способами:


  1. увидеть на консоли, если запретить перезагрузку после kernel panic (sysctl kernel.panic=0)
  2. настроить отправку сообщения по сети на какой-нибудь сервер (гуглить netconsole)

При втором способе ядро посылает предсмертное сообщение по udp на указанный вами адрес.
На сервере-источнике нужно будет подгрузить модуль ядра с нужными параметрами.
А на сервере-приемнике нужно заранее запустить что-нибудь, постоянно слушающее udp порт.
Самый простой вариант — nc в режиме сервера (nc -u -l 6666).
Более надежный — настроить syslog сервер слушать в raw режиме udp порт и записывать все, что туда
приходит.

А ещё можно разукрашивать вывод логов (и не только) с помощью ccze, например:
tail -f /var/log/syslog | ccze -A
Также для этих целей сгодится редактор vim

Простите, vim для просмотра логов?

А если у Вас лог в несколько гигабайт(про ротацию логов не стоит сейчас пожалуйста). Вы все еще используете vim для просмотра логов? Тогда мы идем к вам…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.