Введение
Представьте, что робот убирает ваш дом, пока вы спите. Вы не видите, как он работает. Проснувшись, как вы узнаете, действительно ли робот всё убрал или застрял под диваном?
Ответ прост: попросите робота вести дневник.
В Linux автоматизированные скрипты часто работают в фоновом режиме или запускаются планировщиками, когда никто не наблюдает за терминалом. Поэтому вывода на экране недостаточно. Чтобы отслеживать произошедшее, мы записываем вывод в файл журнала.
Это одна из самых простых и одновременно самых полезных привычек при автоматизации. Скрипт без журналов может завершиться с ошибкой незаметно. Скрипт с журналами оставляет свидетельства своей работы.
В этой лабораторной работе вы:
- Перенаправите вывод: научите скрипт записывать данные в файл, а не на экран.
- Сохраните историю: используете оператор добавления, чтобы новые записи не удаляли старые.
- Добавите временные метки: обеспечите наличие даты и времени в каждой записи журнала.
Запись вывода в файл журнала
Обычные скрипты сразу выводят сообщения на экран. Это похоже на разговор лицом к лицу. Но если никто не слушает, как бывает с автоматизированными скриптами, эти сообщения навсегда теряются.
Нам нужно записать их в файл. Для этого мы воспользуемся операторами перенаправления.
Это напрямую связано с уже изученным принципом работы оболочки: команды обычно записывают данные в стандартный вывод, а перенаправление меняет место назначения этого вывода. Журналирование — практическое применение того же механизма в автоматизации.
>(перезапись): «Сотрите дневник и начните новую страницу». (Плохо для хранения истории.)>>(добавление): «Перейдите к следующей пустой строке и запишите данные туда». (Хорошо для хранения истории!)
Посмотрим на подготовленный простой скрипт:
cat myscript.sh
Он всего лишь сообщает: «Скрипт выполняется». Если сейчас запустить его (./myscript.sh), сообщение появится на экране.
Изменим скрипт так, чтобы он записывал данные в дневник с именем script.log.
Откройте скрипт:
nano myscript.sh
Измените строку, используя оператор >>.
Полезный совет: при записи журналов всегда используйте абсолютный путь (полный адрес), например /home/labex/project/script.log. Это гарантирует, что дневник не потеряется в случайной папке, если скрипт будет запущен из другого места.
Эта привычка особенно важна для запланированных заданий: они часто запускаются из рабочего каталога, отличного от того, который вы ожидаете при работе в интерактивной оболочке. Если скрипт записывает данные в script.log без указания пути, файл может оказаться не в той папке.
Файл должен выглядеть так:
#!/bin/bash
echo "The script is running" >> /home/labex/project/script.log
Сохраните файл и выйдите из редактора.
Теперь запустите скрипт:
./myscript.sh
Тишина.
Скрипт выполнился, но ничего вам не сообщил. Вместо этого он записал сообщение в дневник.
Проверьте дневник:
cat script.log
Вы должны увидеть сохранённое сообщение.
Добавление временных меток
Запись в дневнике, описывающая «что произошло», бесполезна без указания «когда это произошло». Если ваш скрипт запускается каждый день в течение года, файл журнала будет содержать 365 одинаковых строк «The script is running».
Нужно добавить временную метку. В Linux есть команда date, которая выводит текущие дату и время. Мы также перенаправим её вывод в файл журнала.
Это начало наблюдаемости: вы оставляете достаточно свидетельств, чтобы позже человек мог восстановить ход событий. Даже простые временные метки значительно упрощают поиск причин проблем в автоматизированных заданиях.
Откройте myscript.sh:
nano myscript.sh
Добавьте команду date перед сообщением. Тогда в журнале сначала будут указаны время, а затем действие.
#!/bin/bash
date >> /home/labex/project/script.log
echo "The script is running" >> /home/labex/project/script.log
Сохраните файл и выйдите из редактора.
Снова запустите скрипт:
./myscript.sh
Проверьте журнал:
cat script.log
Теперь вы должны увидеть примерно следующее:
The script is running
Fri Oct 27 10:00:00 UTC 2023
The script is running
(Первая строка осталась от предыдущей проверки.)
Теперь каждое действие сопровождается точным временем. Так вы сможете доказать руководителю, что автоматизированное резервное копирование действительно запустилось в 3 часа ночи!
В крупных системах журналы также помогают ответить на более сложные вопросы: запускался ли скрипт дважды, остановился ли он на полпути и сколько времени прошло между запусками. Хорошие журналы превращают невидимую автоматизацию в процесс, который можно проверить.
Проверка истории журнала
Проверим принцип работы добавления. Если использовать > (перезапись) вместо >> (добавление), файл журнала не будет расти: фактически в нём будет виден только последний запуск.
Это различие важно, когда скрипт запускается многократно. Перезапись удобна для текущего снимка состояния, но для хранения истории обычно лучше добавление, поскольку оно сохраняет последовательность событий.
Сымитируем загруженный день, в течение которого скрипт запускается несколько раз.
Запустите его три раза подряд:
./myscript.sh
./myscript.sh
./myscript.sh
Теперь прочитайте дневник:
cat script.log
Вы должны увидеть увеличивающийся список записей, каждая из которых содержит собственную временную метку. Эта история очень полезна при поиске причин проблем. Если вчера сервер завершил работу с ошибкой, вы сможете найти в журнале вчерашнее время и точно увидеть, чем в тот момент занимался скрипт.
Итоги
Вы успешно научили свой скрипт вести дневник.
В этой лабораторной работе вы узнали:
- Перенаправление (
>>): отправка «сообщений» в файл, чтобы они не терялись. - Добавление: сохранение истории вместо её удаления.
- Добавление временных меток: использование
date, чтобы знать, когда произошли события.
Так работают стандартные профессиональные сервисы в Linux. Веб-серверы, базы данных и другие службы записывают данные в файлы журналов точно так же, как вы сделали это сейчас.
