ДЕНЬ 03: Исследователь логов

Введение

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

Системы мониторинга переполнены экстренными оповещениями, пользователи сообщают о сбоях, а конвейер развертывания полностью остановлен. Сара обращается к вам с надеждой: ведущий 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".

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

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

Задачи

• Изучите системные сообщения ядра на наличие строк, связанных с 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.
• Вы должны именно добавить (append) результат в ~/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

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

Задачи

• Сравните конфигурационный файл staging ~/project/config/staging/app.conf с конфигурационным файлом production ~/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.

Примеры

После сравнения файлов конфигурации staging и production ваш файл ~/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 показывает, какие изменения потребуются для файла конфигурации staging, чтобы он соответствовал конфигурации production. Строки, начинающиеся с <, показывают содержимое из файла staging, а строки, начинающиеся с >, — из файла production. Это наглядно демонстрирует, что в среде production используются другие URL-адреса баз данных, API-ключи, флаги функций и значения тайм-аутов по сравнению со staging.

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

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

Задачи

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

Требования

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

Подсказки

• Команда diff также может сравнивать директории, если вместо путей к файлам указать пути к директориям.
• Использование опции -r или --recursive при сравнении директорий является хорошей практикой, так как это позволит сравнить все вложенные файлы.
• Формат вывода 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, staging), но отсутствует во второй (server2_files, production). Сравнивая сначала staging, а затем production, мы можем легко идентифицировать файлы, которые не были перенесены в рабочую среду, что может объяснять некоторые сбои приложения.

Резюме

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

В ходе вашего системного расследования вы освоили основные команды для поиска и устранения неисправностей:

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

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

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