Повседневные задачи администрирования 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
ссылка на оригинал статьи https://habrahabr.ru/post/281601/
Добавить комментарий