ДЕНЬ 03: Расследование логов

Введение

Идет третий день в LabEx Corporation, и проект «Феникс» (Project Phoenix) оказался на грани катастрофы! Вы приходите в офис и обнаруживаете, что Сара Чен и команда разработчиков работают в режиме чрезвычайной ситуации. Приложение, которое вы помогали упорядочить вчера, столкнулось с критическими ошибками во время первой крупной фазы тестирования.

Системы мониторинга переполнены аварийными оповещениями, пользователи сообщают о сбоях, а конвейер развертывания (deployment pipeline) полностью остановился. Сара смотрит на вас с отчаянием — старший DevOps-инженер на больничном, а крайний срок сдачи проекта уже близко.

«Нам нужен наш лучший следователь для этого дела», — говорит Сара, передавая вам отчет об инциденте. — «Ваш системный подход к организации файлов был именно тем, что нам нужно. Теперь нам нужно такое же методичное мышление, чтобы разгадать эту тайну».

Ваша миссия — глубоко погрузиться в сервер проекта «Феникс», проанализировать логи и файлы конфигурации и выявить первопричину этих сбоев. Вы будете использовать продвинутые инструменты командной строки Linux, чтобы собрать улики воедино и восстановить стабильность приложения, над которым так усердно работала ваша команда. Будущее проекта «Феникс» — и, возможно, ваша карьера в TechNova — зависит от ваших детективных навыков!

Просмотр содержимого файла логов приложения

Ваш первый шаг как следователя — проверить файл логов приложения проекта «Феникс». Приложение записывает свои логи в ~/project/logs/app.log. Поток сообщений может быть огромным, поэтому вам нужно быстро найти критические сообщения об ошибках, чтобы понять, что идет не так с системой, которую вы помогали упорядочить вчера.

Задачи

• Отфильтруйте файл ~/project/logs/app.log, чтобы найти все строки, содержащие слово ERROR.
• Сохраните отфильтрованные строки в новый файл с именем ~/project/error_report.txt.

Требования

• Вы должны использовать инструмент командной строки для поиска в файле.
• Входной файл для поиска — ~/project/logs/app.log.
• Результат должен быть сохранен в файле ~/project/error_report.txt в директории ~/project.
• Выходной файл должен содержать только строки со словом ERROR.

Подсказки

• Команда grep идеально подходит для поиска шаблонов в текстовых файлах.
• Чтобы сохранить вывод команды в файл, можно использовать оператор перенаправления >. Это создаст файл, если он не существует, или перезапишет его, если он уже есть.

Примеры

После успешной фильтрации файла логов ваш файл ~/project/error_report.txt должен содержать только строки с ошибками:

$ cat ~/project/error_report.txt
[2023-10-26 10:00:03] ERROR: Failed to process payment transaction #12345.
[2023-10-26 10:00:05] ERROR: NullPointerException at com.innovatech.Billing.process(Billing.java:101).

Файл должен содержать ровно 2 строки, обе начинаются с временных меток и содержат слово "ERROR".

Исследование сообщений загрузки системы

Ошибки приложения могут быть симптомом более глубокой проблемы на уровне оборудования или ядра. Хорошее место для поиска таких проблем — кольцевой буфер ядра (kernel ring buffer), который содержит сообщения процесса загрузки системы и работы драйверов.

Задачи

• Изучите сообщения ядра системы на наличие строк, связанных с fail или error.
• Сохраните эти результаты в файл с именем ~/project/boot_issues.txt.

Требования

• Вы должны использовать команду dmesg для просмотра сообщений ядра.
• Поиск fail или error должен быть нечувствительным к регистру.
• Результаты должны быть сохранены в файл ~/project/boot_issues.txt.
• Примечание: для доступа к сообщениям ядра могут потребоваться права администратора (sudo).

Подсказки

• Команда dmesg отображает сообщения ядра. Вы можете «перенаправить» (pipe) её вывод в другую команду для фильтрации.
• Оператор конвейера | передает вывод одной команды на вход другой.
• Опция -i команды grep делает поиск нечувствительным к регистру.
• Чтобы искать несколько шаблонов одновременно (например, fail ИЛИ error), можно использовать grep -E 'pattern1|pattern2'.
• Примечание: если вы столкнулись с ошибкой "Operation not permitted", попробуйте выполнить команду с sudo, чтобы получить необходимые привилегии.

Примеры

После успешной фильтрации сообщений ядра ваш файл ~/project/boot_issues.txt должен содержать соответствующие системные сообщения:

$ cat ~/project/boot_issues.txt
[    0.330755] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
[    1.026520] RAS: Correctable Errors collector initialized.
[   28.260800] kernel: [   10.123456] my-driver: probe of 0000:00:1f.0 failed with error -2

Файл должен содержать сообщения ядра, включающие слова "fail" или "error" (без учета регистра), указывающие на потенциальные проблемы с оборудованием или драйверами во время загрузки системы.

Изучение файла конфигурации веб-сервера

Критических проблем с оборудованием не обнаружено. Проблема может быть в конфигурации веб-сервера. Давайте изучим файл конфигурации Nginx, чтобы увидеть, как он настроен. Иногда неправильные настройки, например, слишком малое количество рабочих процессов (worker processes), могут вызвать узкие места в производительности и привести к сбоям приложения под нагрузкой.

Задачи

• Найдите файл конфигурации веб-сервера по адресу ~/project/config/nginx.conf.
• Найдите строку, содержащую директиву worker_processes.
• Добавьте эту строку в конец файла ~/project/error_report.txt, который вы создали на первом шаге.

Требования

• Входной файл — ~/project/config/nginx.conf.
• Вы должны добавить результат в ~/project/error_report.txt, а не перезаписывать его.

Подсказки

• Вы можете снова использовать grep для этой задачи.
• Чтобы добавить вывод в файл, а не перезаписывать его, используйте оператор >>.

Примеры

После добавления строки worker_processes в существующий отчет об ошибках, файл ~/project/error_report.txt должен содержать как исходные строки ошибок, так и новую строку конфигурации:

$ cat ~/project/error_report.txt
[2023-10-26 10:00:03] ERROR: Failed to process payment transaction #12345.
[2023-10-26 10:00:05] ERROR: NullPointerException at com.innovatech.Billing.process(Billing.java:101).
worker_processes 4;

Файл должен содержать всего 3 строки: 2 исходные строки ошибок плюс 1 новая строка с "worker_processes 4;".

Сравнение файлов конфигурации стейджинга и продакшена

Частой причиной проблем в продакшене является расхождение между средами стейджинга (staging) и продакшена (production). Функция может отлично работать в стейджинге, но давать сбой в продакшене из-за небольшой разницы в конфигурации. Давайте сравним файлы конфигурации приложения из обеих сред, чтобы выявить различия.

Задачи

• Сравните файл конфигурации стейджинга ~/project/config/staging/app.conf с файлом конфигурации продакшена ~/project/config/production/app.conf.
• Сохраните различия в новый файл с именем ~/project/config_diff.txt.

Требования

• Вы должны использовать команду diff.
• Вывод, показывающий различия, должен быть сохранен в ~/project/config_diff.txt.

Подсказки

• Команда diff специально разработана для сравнения двух файлов построчно.
• Базовый синтаксис: diff file1 file2, где команда показывает, какие изменения нужно внести в file1, чтобы он стал идентичен file2.
• Порядок файлов имеет значение! diff A B и diff B A покажут разные результаты.
• Вы можете перенаправить вывод diff в файл точно так же, как вы делали это с grep.

Примеры

После сравнения файлов конфигурации стейджинга и продакшена ваш файл ~/project/config_diff.txt должен показать различия между двумя средами:

$ cat ~/project/config_diff.txt
1,5c1,5
< ## Staging Configuration
< database.url=jdbc:mysql://staging-db:3306/nexus
< api.key=staging_key_abc123
< feature.flag.new_dashboard=true
< timeout.ms=3000
---
> ## Production Configuration
> database.url=jdbc:mysql://prod-db:3306/nexus
> api.key=prod_key_xyz789
> feature.flag.new_dashboard=false
> timeout.ms=5000

Вывод diff показывает, какие изменения нужно внести в файл конфигурации стейджинга, чтобы он соответствовал файлу конфигурации продакшена. Строки, начинающиеся с <, показывают содержимое из файла стейджинга, а строки, начинающиеся с >, — содержимое из файла продакшена. Это показывает, что среда продакшена использует другие URL-адреса баз данных, ключи API, флаги функций и значения тайм-аутов по сравнению со стейджингом.

Проверка согласованности директорий между серверами

Разница в конфигурации — это важная зацепка! Похоже, что на сервере продакшена также отсутствуют некоторые критические файлы, которые есть на сервере стейджинга. Это может быть связано с неудачным развертыванием. Давайте сымитируем это, сравнив две директории, представляющие файловые структуры с двух разных серверов.

Задачи

• У вас есть две директории: /home/labex/project/server1_files (представляющая сервер стейджинга) и /home/labex/project/server2_files (представляющая сервер продакшена).
• Сравните эти две директории, чтобы выяснить, какие файлы уникальны для server1_files.
• Сохраните полный результат сравнения в файл с именем /home/labex/project/missing_files.txt.

Требования

• Вы должны использовать команду diff для сравнения двух директорий.
• Результат должен быть сохранен в /home/labex/project/missing_files.txt.

Подсказки

• Команда diff также может сравнивать директории, если вы укажете пути к директориям вместо путей к файлам.
• Использование опции -r или --recursive с diff — хорошая практика для сравнения директорий, так как она сравнит все файлы внутри них.
• Формат вывода diff для директорий будет явно указывать, какие файлы находятся «Только в» (Only in) конкретной директории.
• Как и в случае с файлами, порядок имеет значение при сравнении директорий. diff dir1 dir2 показывает, что есть в dir1, но нет в dir2, в то время как diff dir2 dir1 показывает обратное.

Примеры

После сравнения двух директорий серверов ваш файл /home/labex/project/missing_files.txt должен показать, какие файлы отсутствуют на сервере продакшена:

$ cat /home/labex/project/missing_files.txt
Only in /home/labex/project/server1_files: asset2.js

Этот вывод указывает на то, что asset2.js существует в первой директории (server1_files, представляющей сервер стейджинга), но отсутствует во второй директории (server2_files, представляющей сервер продакшена). Сравнивая сначала стейджинг, а затем продакшен, мы можем легко определить файлы, которые отсутствуют в продакшене, что может объяснить некоторые сбои приложения.

Итоги

Исключительная детективная работа! Вы успешно определили первопричины критических сбоев проекта «Феникс» и предоставили Саре Чен и команде разработчиков полезную информацию для решения проблем.

Благодаря вашему систематическому расследованию вы освоили важные команды для устранения неполадок:

• grep: для фильтрации файлов логов и извлечения критической информации об ошибках.
• dmesg: для исследования проблем с оборудованием и ядром на системном уровне.
• diff: для сравнения файлов конфигурации и выявления расхождений между средами.
• Конвейеры команд и перенаправление: для эффективной обработки и документирования ваших находок.

Ваш методичный подход к анализу логов спас проект «Феникс» от потенциально катастрофического сбоя. У команды разработчиков теперь есть четкое направление по исправлению несоответствий в конфигурации и отсутствующих файлов развертывания, которые вы обнаружили.

Сара Чен была настолько впечатлена вашими навыками расследования, что рекомендует вас на роль в сфере безопасности. Завтра вы примерите на себя роль «Стража крепости» (Fortress Guardian), чтобы обеспечить безопасность инфраструктуры проекта «Феникс» и защитить её от будущих угроз!