Повседневные задачи администрирования Linux требуют автоматизации. Как правило, автоматизация сводится к написанию bash скриптов и их «ротации по крону», либо выполнении вручную, в зависимости от задачи. В этой заметке собраны часто встречающиеся практики логирования bash скриптов. Целевая аудитория — системные администраторы linux.
Самый простой и очевидный способ сохранить вывод скрипта это просто перенаправить его в файл.
exemple.sh > exemple.sh.log
На самом деле, нужно добавить к выводу STDERR, потому, как сообщения об ошибках пишутся именно в него:
exemple.sh 2&>1 > exemple.sh.log
Это считается нормальной практикой и обычно удовлетворяет большую часть системных администраторов. Но если серверов несколько(десятков, сотен), и логирование централизованно, удобнее использовать logger. Напомню, что logger это утилита, которая отправляет сообщения в syslog.
exemple.sh 2&>1 | logger
Плюсы такого подхода в том, что можно перенаправлять вывод не только bash скриптов.
Минусы — невозможно отделить сообщения об ошибках от других информационных сообщений, так как в этом примере вывод слеплен в один поток и все это попадает в syslog с приоритетом user.notice(приоритет по умолчанию).
Для некоторых задач допустимо применение следующего варианта:
exemple.sh 2>&1 >/dev/null | logger -p user.error -t exemple.sh
В этом варианте логируется только STDERR (STDOUT перенаправляется в /dev/null) с приоритетом error. Также сообщения помечаются тегом с названием скрипта. Все это может упростить поиск и устранения неисправностей в работе скриптов.
Минусом этого подхода является то, что мы теряем STDOUT. Чтобы решить эту проблему можно использовать перенаправление потоков вывода непосредственно внутри скрипта.
#!/bin/bash
exec > >(logger -p local0.notice -t `basename "$0"`)
exec 2> >(logger -p local0.error -t `basename "$0"`)
echo "error" >&2
echo "notice"
Этот пример иллюстрирует как можно перенаправить STDOUT и STDERR независимо друг от друга. К сожалению, этот способ порождает неожиданную проблему: сообщения из разных потоков могут попадать в syslog не в том порядке, в котором были отправлены. Такое поведение связано с тем, что потоки обрабатываются как два независимых друг от друга процесса. Не смотря на это, способ часто применяется для логирования скриптов, запускаемых cron.
Но иногда требуется запускать скрипт вручную, и в этом случае не всегда удобно следить за его работой в syslog.
#!/bin/bash
#
# .--------.
# | STDOUT |
# '--------'
# ^
# |
# .--------. .-----. .--------.
# | STDOUT |----->| tee |---->| logger |
# '--------' '-----' '--------'
#
exec > >(tee >(logger -p local0.notice -t `basename "$0"`))
# возможны варианты
exec 2> >(tee >&2 >(logger -p local0.error -t `basename "$0"`))
#exec 2> >(logger -p local0.error -t `basename "$0"` -s)
echo "error" >&2
echo "notice"
В этом примере tee копирует «входящий» поток в logger и обратно — в STDOUT(поведение по умолчанию), а во втором случае в STDERR. Таким образом мы получаем логирование в syslog + вывод на консоль во время выполнения, что бывает полезно для скриптов, запускаемых вручную.
Выводы:
Логи в syslog — это просто.
Логи в syslog — это полезно, особенно если логирование централизованно. При параллельном перенаправленнии потоков вывода — следует помнить о возможном нарушении порядка следования сообщений.
Ссылки по теме:
Redirecting bash script output to syslog
Logging From Launchd
Автор: serpentf
