Блок 18

Мониторинг, журналы, производительность и диагностика

> Что вас ждёт в этом блоке: мы углубим и систематизируем всё, что вы уже частично изучали о процессах (Блок 11), службах (Блок 10) и логах на протяжении курса, превратив разрозненные знания в цело…

Обновлено: 23 июля 2026 · DeeNet

Введение в блок

> Что вас ждёт в этом блоке: мы углубим и систематизируем всё, что вы уже частично изучали о процессах (Блок 11), службах (Блок 10) и логах на протяжении курса, превратив разрозненные знания в целостный, профессиональный подход к диагностике проблем. Вы научитесь глубоко анализировать системные журналы, детально изучать использование процессора, памяти, диска и сети в реальном времени, находить первопричины замедления или сбоя системы, познакомитесь с обзором промышленных инструментов мониторинга, и освоите системный алгоритм troubleshooting — пошаговый процесс поиска и устранения неполадок, применимый к практически любой проблеме.

> Что нужно знать перед началом: весь материал курса, в особенности процессы и сигналы (Блок 11), службы и journalctl (Блок 10), сеть (Блок 12), безопасность (Блок 14) и bash-скрипты (Блок 15) — этот блок во многом является синтезом ранее изученного, применённым к задаче диагностики.

Урок 18.1. `/var/log` и `journalctl` углублённо

Систематизировать и углубить знания о системе журналирования Linux: детально разобрать структуру /var/log, освоить продвинутые возможности journalctl для фильтрации и анализа журналов, и научиться настраивать ротацию логов через logrotate.

Теория

Напоминание и расширение уже изученного материала. В Блоке 10 мы уже познакомились с journalctl в контексте управления службами через systemd, а в Блоке 14 использовали логи для аудита безопасности. Теперь мы рассмотрим журналирование Linux как самостоятельную, целостную тему, углубляясь в детали, которые до этого затрагивались лишь частично.

Два параллельных мира логов в современном Ubuntu. Важно чётко понимать, что в типичной современной системе Ubuntu сосуществуют два подхода к хранению журналов:

Традиционные текстовые файлы в /var/log/ — классический подход Unix, при котором каждая программа или подсистема пишет свои сообщения в отдельный текстовый файл, который можно просматривать любыми уже знакомыми нам текстовыми утилитами (cat, less, grep, tail — материал Блоков 2 и 6).
Systemd journal, управляемый демоном journald и просматриваемый через journalctl — более современный, структурированный подход, при котором сообщения хранятся в специальном бинарном формате (не читаемом напрямую через cat), содержащем богатые метаданные о каждой записи (какой именно процесс, с каким PID, в какой момент времени, с каким уровнем важности сформировал сообщение).

Важный практический нюанс: многие традиционные программы по-прежнему пишут напрямую в /var/log/, тогда как современные, спроектированные с учётом systemd, службы отправляют логи именно в journal. Кроме того, journald часто настроен пересылать (forward) часть или все свои записи также в традиционный /var/log/syslog (или похожий файл) для совместимости с инструментами, ожидающими классический текстовый формат — то есть на практике одно и то же сообщение иногда можно найти обоими способами.

Структура /var/log/ — детальный разбор ключевых файлов и директорий:

/var/log/syslog** — традиционный, «общий» системный журнал, куда исторически стекаются сообщения от самых разных источников (в современных системах на основе systemd многие сообщения сюда попадают именно как копия из journal).
/var/log/auth.log** — журнал, специально посвящённый аутентификации и авторизации: попытки входа по SSH (материал, который мы активно использовали в Блоке 14 при работе с Fail2Ban), использование sudo, изменения пользователей и групп.
/var/log/kern.log** — сообщения непосредственно от ядра Linux — аппаратные события, работа драйверов, иногда критически важная информация при диагностике проблем с оборудованием.
/var/log/dpkg.log** — журнал операций пакетного менеджера (мы уже использовали его в Блоке 14 для проверки истории обновлений).
/var/log/apt/** — директория с более подробными журналами именно APT-операций (в дополнение к записям в dpkg.log).
/var/log/nginx/, /var/log/mysql/** и подобные — директории, специфичные для конкретного установленного программного обеспечения (мы вернёмся к логам Nginx подробно в Блоке 19).
/var/log/boot.log** — сообщения, связанные с процессом загрузки системы.
Файлы с числовым или .gz суффиксом (например, syslog.1, syslog.2.gz) — это уже ротированные** (архивированные) старые версии логов, о механизме ротации мы поговорим ниже в этом же уроке.

Углублённые возможности journalctl — расширение материала Блока 10.

Фильтрация по времени:

```bash

journalctl --since "2026-07-20" # с конкретной даты

journalctl --since "1 hour ago" # относительное время

journalctl --since "09:00" --until "12:00" # диапазон времени

journalctl --since yesterday

```

Фильтрация по важности (приоритету) сообщения. Journal, как и классический syslog, использует стандартизированную шкалу важности сообщений (называемую уровнями syslog), от самых критичных до чисто информационных:

| Числовой уровень | Название | Значение |

|---|---|---|

| 0 | emerg | Система полностью неработоспособна |

| 1 | alert | Требуется немедленное действие |

| 2 | crit | Критическая ситуация |

| 3 | err | Ошибка |

| 4 | warning | Предупреждение |

| 5 | notice | Обычная, но значимая ситуация |

| 6 | info | Информационное сообщение |

| 7 | debug | Отладочная информация |

```bash

journalctl -p err # показать только сообщения уровня err и выше по критичности (то есть err, crit, alert, emerg)

journalctl -p warning..err # показать сообщения в диапазоне от warning до err

```

Фильтрация по конкретной службе (юниту systemd — вспомните материал Блока 10):

```bash

journalctl -u ssh # логи конкретно SSH-службы

journalctl -u nginx -u docker # логи сразу нескольких служб одновременно

```

Фильтрация по конкретному процессу или пользователю:

```bash

journalctl _PID=1234 # логи от конкретного PID

journalctl _UID=1000 # логи, связанные с конкретным пользователем (по числовому UID — вспомните Блок 8)

```

Дополнительные полезные флаги:

```bash

journalctl -k # только сообщения ядра (аналог dmesg, команды которую мы не разбирали подробно, но которая тоже показывает буфер сообщений ядра)

journalctl -b # только с момента последней загрузки системы

journalctl -b -1 # логи предыдущей загрузки (чрезвычайно полезно для диагностики причины неожиданной перезагрузки или сбоя!)

journalctl --disk-usage # сколько места на диске занимает journal

journalctl -f # следить за новыми записями в реальном времени (аналог tail -f)

journalctl -o json-pretty # вывод в структурированном JSON-формате — полезно для программной обработки или очень детального изучения метаданных записи

```

Ротация логов — зачем и как. Логи, накапливающиеся годами без ограничений, рано или поздно займут весь доступный объём диска — очевидная и серьёзная проблема, особенно для активно используемых серверов, генерирующих большой объём записей (например, веб-серверов с высокой посещаемостью). Ротация логов (log rotation) — механизм, который периодически «архивирует» текущий лог-файл (обычно сжимая его и переименовывая, добавляя числовой суффикс, как мы видели в примерах файлов syslog.1, syslog.2.gz выше), начиная запись в новый, пустой файл, и в конце концов удаляет самые старые архивы, если их накопилось больше заданного лимита.

logrotate — стандартный инструмент ротации логов в Linux. Работает на основе конфигурационных файлов, описывающих, как именно ротировать каждый конкретный лог (или группу логов) — как часто (ежедневно, еженедельно), сколько архивных копий хранить, сжимать ли их, и так далее.

```bash

cat /etc/logrotate.conf

ls /etc/logrotate.d/

```

Файл /etc/logrotate.conf содержит общие, глобальные настройки, а директория /etc/logrotate.d/ содержит отдельные конфигурационные файлы для конкретных программ (обычно устанавливаемые автоматически вместе с самим пакетом программы — то есть, устанавливая, например, Nginx, вы, скорее всего, автоматически получите готовую конфигурацию ротации именно для логов Nginx).

Journal и его собственный механизм ограничения размера. Systemd journal, в отличие от классических текстовых логов, использует собственный встроенный механизм ограничения занимаемого места, настраиваемый в файле /etc/systemd/journald.conf (директивы вроде SystemMaxUse=, ограничивающие максимальный суммарный размер journal) — это отдельный, независимый от logrotate механизм именно для journal.

Практика

Шаг 1. Изучите общий размер, занимаемый journal:

```bash

journalctl --disk-usage

```

[Скриншот терминала]

Шаг 2. Потренируйтесь с фильтрацией по времени:

```bash

journalctl --since "1 hour ago" | tail -20

journalctl --since today | wc -l

```

Шаг 3. Отфильтруйте логи по важности — найдите все сообщения уровня error и выше за последние сутки:

```bash

journalctl -p err --since "24 hours ago"

```

Что вы увидите: если система работает штатно, список может быть пустым или содержать лишь несколько записей — это нормально и является хорошим знаком (отсутствие критичных ошибок).

[Скриншот терминала]

Шаг 4. Изучите логи предыдущей загрузки системы — эта возможность особенно ценна, если система когда-то неожиданно перезагружалась или зависала:

```bash

journalctl --list-boots

```

Что вы увидите: список всех «загрузок» системы, о которых у journal сохранилась информация, с указанием временного диапазона каждой.

```bash

journalctl -b -1 -p err 2>/dev/null | tail -20

```

(Если система перезагружалась только один раз или ещё ни разу с момента установки, этот запрос может вернуть пустой результат или сообщение об отсутствии данных о предыдущей загрузке — это ожидаемо для новой учебной системы.)

Шаг 5. Изучите логи конкретной службы с ограничением по важности одновременно (комбинирование нескольких фильтров):

```bash

journalctl -u ssh -p info --since "24 hours ago" | tail -20

```

Шаг 6. Изучите вывод в структурированном JSON-формате для одной конкретной записи — это позволяет увидеть все метаданные, которые journal хранит для каждого сообщения, значительно больше, чем отображается в обычном, компактном выводе:

```bash

journalctl -n 1 -o json-pretty

```

Что вы увидите: подробную структуру полей — время (в нескольких форматах), PID, UID, GID процесса-источника, имя исполняемого файла, командную строку, с которой был запущен процесс, и многое другое.

[Скриншот JSON-вывода]

Шаг 7. Изучите структуру /var/log/ подробно:

```bash

ls -la /var/log/

```

Шаг 8. Найдите и изучите уже ротированные (архивные) логи:

```bash

ls -la /var/log/ | grep -E "\.gz$|\.[0-9]$"

```

Что вы увидите: список файлов с числовыми суффиксами или расширением .gz — свидетельство того, что logrotate уже выполнял свою работу на этой системе.

Шаг 9. Изучите содержимое сжатого лога, не распаковывая его полностью на диск, а используя специальную утилиту zcat (аналог cat, но для .gz-файлов, которую мы не разбирали ранее в курсе, хотя логика применения аналогична уже знакомым нам cat/grep):

```bash

ls /var/log/*.gz 2>/dev/null | head -1

```

Если такой файл найден:

```bash

sudo zcat /var/log/syslog.*.gz 2>/dev/null | head -20

```

Шаг 10. Изучите конфигурацию logrotate:

```bash

cat /etc/logrotate.conf

```

Обратите внимание на директивы вида weekly (ротировать еженедельно), rotate 4 (хранить 4 архивные копии), compress (сжимать архивы).

[Скриншот файла конфигурации]

Шаг 11. Изучите специфичную конфигурацию ротации для конкретного пакета (например, для rsyslog, стандартного демона классического syslog):

```bash

ls /etc/logrotate.d/

cat /etc/logrotate.d/rsyslog 2>/dev/null

```

Шаг 12. Изучите настройки самого journal:

```bash

cat /etc/systemd/journald.conf | grep -v "^#" | grep -v "^$"

```

(Используем уже знакомый нам приём фильтрации закомментированных и пустых строк из Блока 14.)

Шаг 13. Протестируйте logrotate «в холостую», без реального выполнения — специальный флаг для проверки конфигурации без внесения изменений:

```bash

sudo logrotate -d /etc/logrotate.conf 2>&1 | head -30

```

(Флаг -d, debug-режим — показывает, что logrotate сделал бы, не выполняя реальных действий, аналогично уже знакомому нам принципу --dry-run, который мы видели у rsync в Блоке 13 и unattended-upgrades в Блоке 14.)

[Скриншот вывода тестового запуска logrotate]

Разбор команд

Углублённые флаги journalctl — сводная таблица:

| Флаг | Назначение |

|---|---|

| --since, --until | Фильтрация по времени (абсолютному или относительному) |

| -p | Фильтрация по уровню важности (приоритету) |

| -u | Фильтрация по конкретной службе (юниту) |

| _PID=, _UID= | Фильтрация по PID или UID процесса-источника |

| -k | Только сообщения ядра |

| -b [N] | Логи конкретной загрузки системы (текущей или N-й от текущей) |

| -f | Слежение за новыми записями в реальном времени |

| -o json-pretty | Структурированный, подробный вывод |

| --disk-usage | Объём диска, занимаемый journal |

| --list-boots | Список загрузок системы, известных journal |

Команда logrotate

Назначение:** ротация (архивирование, сжатие, удаление устаревших) лог-файлов согласно конфигурации.
Синтаксис:** logrotate [-d] [-f] /путь/к/конфигу; -d (debug, тестовый прогон без изменений), -f (force, принудительно выполнить ротацию немедленно, даже если по расписанию ещё не время).
Обычно запускается автоматически** через systemd-таймер (аналог cron, изученного в Блоке 15) на ежедневной основе — прямой ручной запуск нужен редко, в основном для тестирования конфигурации или принудительной немедленной ротации.

Команда zcat

Назначение:** вывести содержимое .gz-сжатого файла, аналогично cat для обычного текстового файла, без необходимости предварительно распаковывать файл на диск.
Синтаксис:** zcat файл.gz
Родственные команды:** zgrep (аналог grep для сжатых файлов), zless (аналог less).

Возможные ошибки

Ошибка:** journal занимает неожиданно много места на диске, потенциально приводя к проблемам с нехваткой дискового пространства (материал Блока 9).

Почему возникает: отсутствие или неправильная настройка ограничений в /etc/systemd/journald.conf (директивы SystemMaxUse, SystemMaxFileSize и подобные), особенно на системах с очень «шумными» (часто пишущими логи) службами.

Как определить: journalctl --disk-usage показывает неожиданно большое значение; df -h (материал Блока 9) может показывать нехватку места на разделе, где физически хранится journal (обычно /var/log/journal/).

Как исправить: настроить явные ограничения в journald.conf (например, SystemMaxUse=500M), перезапустить systemd-journald; можно вручную ограничить размер немедленно командой sudo journalctl --vacuum-size=200M.

Как избежать: с самого начала эксплуатации сервера явно задавать разумные ограничения размера journal, особенно на серверах с ограниченным объёмом диска.

Ошибка:** попытка просмотреть .gz-архивный лог обычной командой cat, получая нечитаемый «мусор» вместо текста.

Почему возникает: .gz-файл — это сжатые бинарные данные, а не обычный текст; cat показывает файл «как есть», без распаковки.

Как исправить: использовать zcat, zgrep или zless вместо обычных cat/grep/less для файлов с расширением .gz, либо предварительно распаковать файл командой gunzip (создающей несжатую копию).

Практические задания

Найдите в journal все сообщения об ошибках (-p err) за последнюю неделю, сохраните результат в файл (> ~/weekly_errors.log, используя перенаправление из Блока 6), и изучите его — есть ли повторяющиеся паттерны или конкретные службы, генерирующие больше всего ошибок?
Изучите (через journalctl _UID=0, где UID 0 соответствует root — вспомните материал Блока 8) все действия, выполненные от имени root за последний час на вашей системе — сопоставьте это с вашими собственными недавними действиями через sudo в терминале.
Настройте (аккуратно, с обязательным резервным копированием файла перед изменением — привычка из Блока 14) explicit-ограничение размера journal в /etc/systemd/journald.conf, установив SystemMaxUse=200M, перезапустите systemd-journald (sudo systemctl restart systemd-journald), и проверьте новую настройку через journalctl --disk-usage.

Проверка знаний

Вопрос 1. В чём разница между традиционными текстовыми логами в /var/log/ и systemd journal, и почему в современных системах Ubuntu присутствуют оба подхода одновременно?

Ответ: Традиционные текстовые логи в /var/log/ — это классический подход Unix, при котором каждая программа пишет обычный текст в отдельный файл, читаемый стандартными текстовыми утилитами. Systemd journal — более современная система, хранящая записи в структурированном бинарном формате с богатыми метаданными (PID, UID, точное время, приоритет и многое другое), доступная через специальный инструмент journalctl. Оба подхода сосуществуют в современном Ubuntu по историческим причинам и для совместимости: многие традиционные программы и инструменты по-прежнему ожидают классические текстовые логи, тогда как современные, спроектированные под systemd службы используют journal, который часто дополнительно пересылает часть сообщений и в традиционный /var/log/syslog именно ради этой совместимости.

Вопрос 2. Зачем нужна ротация логов (logrotate), и что произошло бы, если бы она отсутствовала на активно используемом сервере?

Ответ: Без ротации лог-файлы росли бы бесконечно, поскольку программы продолжают дописывать в них новые записи без остановки. На активно используемом сервере (особенно с высоконагруженными службами, генерирующими большой объём записей — например, веб-сервером с высокой посещаемостью) это неизбежно привело бы к постепенному исчерпанию всего доступного дискового пространства, что могло бы вызвать полный отказ системы (невозможность записи новых данных куда бы то ни было на переполненном разделе — критическая проблема, способная затронуть работу самых разных, даже не связанных с логированием напрямую, служб). Ротация решает эту проблему, периодически архивируя (сжимая) текущий лог и удаляя самые старые архивные копии сверх заданного лимита хранения.

Итоги урока

Вы изучили: два параллельных подхода к журналированию (традиционные /var/log/ логи и systemd journal), детальную структуру ключевых файлов /var/log/, продвинутые возможности фильтрации journalctl (по времени, приоритету, службе, PID/UID), уровни важности сообщений (syslog levels), механизм ротации логов через logrotate, ограничение размера journal.

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

В следующем уроке потребуется: понимание журналирования — теперь мы обратимся к диагностике текущего состояния системы в реальном времени, углубляя материал о процессах из Блока 11.

Урок 18.2. Мониторинг в реальном времени: `top`, `htop`, `vmstat`, `iostat`

Углубить владение уже знакомыми инструментами (top, htop из Блока 11) и освоить новые инструменты диагностики использования памяти, диска и производительности системы в реальном времени — vmstat и iostat.

Теория

Напоминание материала Блока 11. Мы уже подробно изучали top и htop для просмотра процессов и общей нагрузки на систему. В этом уроке мы углубим понимание выводимых этими инструментами данных, и расширим набор инструментов дополнительными, более специализированными утилитами.

Углублённое понимание вывода top — то, что часто остаётся незамеченным при поверхностном знакомстве:

Строка load average (мы бегло упоминали её ранее) — три числа, показывающие среднюю «нагрузку» системы за последние 1, 5 и 15 минут. Важно понимать точное значение этих чисел: load average — это в среднем количество процессов, находящихся в очереди на выполнение или ожидающих завершения дисковых операций, в данный промежуток времени. Число 1.0 на одноядерном процессоре означает полную загрузку (процессор постоянно занят); на четырёхъядерном процессоре то же число 1.0 означает лишь 25% от максимальной теоретической нагрузки, поскольку три ядра из четырёх остаются свободными. Поэтому интерпретация load average всегда должна учитывать количество ядер процессора (которое можно узнать через nproc, команду, которую мы, возможно, кратко упоминали ранее в курсе):

```bash

nproc

```

Строка %Cpu(s) в top детализирует использование процессора по категориям:

us (user) — время, потраченное на выполнение пользовательских процессов с обычным приоритетом.
sy (system) — время, потраченное непосредственно ядром на системные операции.
ni (nice) — время, потраченное на процессы с изменённым приоритетом (мы, возможно, кратко касались nice в контексте приоритетов процессов в Блоке 11).
id (idle) — время простоя, когда процессору нечего делать.
wa (iowait) — крайне важная метрика: время, когда процессор простаивает специально потому, что ожидает завершения операции ввода-вывода (обычно дисковой). Высокое значение wa часто указывает не на проблему с процессором, а на проблему с диском — медленную или перегруженную дисковую подсистему, из-за которой процессор вынужден «ждать», хотя формально свободен для другой работы.
hi, si — время, потраченное на обработку аппаратных и программных прерываний соответственно (специализированная метрика, реже требующая внимания в повседневной диагностике).

Раздел памяти в top — здесь важно правильно интерпретировать понятия:

total — общий объём физической оперативной памяти.
free — память, вообще не используемая ни для чего.
used — память, активно используемая процессами.
buff/cache — память, используемая ядром для дисковых буферов и кэша файловой системы. Критически важное понимание: эта память не «потеряна» и не «занята впустую» — ядро Linux агрессивно использует свободную память для кэширования недавно прочитанных с диска данных, что значительно ускоряет повторный доступ к тем же данным. Если приложению внезапно понадобится больше памяти, ядро может почти мгновенно освободить часть этого кэша. Именно поэтому опытные администраторы Linux не пугаются, увидев малое значение free и большое buff/cache — это нормальное, даже желательное поведение хорошо работающей системы, а не признак нехватки памяти.

Инструмент vmstat («virtual memory statistics») — предоставляет сводную статистику по использованию памяти, процессов, страничного обмена (swap) и активности процессора, обновляемую с заданным интервалом:

```bash

vmstat 2 5 # обновлять каждые 2 секунды, всего 5 раз

```

Ключевые колонки вывода vmstat:

r** (running) — количество процессов, находящихся в очереди на выполнение процессором прямо сейчас (тесно связано с концепцией load average).
b** (blocked) — количество процессов, заблокированных в ожидании завершения операции ввода-вывода.
swpd** — объём используемой swap-памяти (виртуальной памяти на диске, используемой как «резерв» при нехватке физической оперативной памяти — если это значение постоянно растёт и остаётся большим, это тревожный сигнал недостатка оперативной памяти).
si/so** (swap in / swap out) — интенсивность обмена данными со swap-областью. Активный, постоянный своп — серьёзный признак проблем с производительностью, поскольку операции с диском (даже быстрым SSD) на порядки медленнее операций с оперативной памятью.
us/sy/id/wa** — аналогично уже разобранным категориям использования процессора в top.

Инструмент iostat («I/O statistics») — специализированный инструмент для детальной статистики дисковой активности, разбитой по каждому отдельному диску/разделу:

```bash

iostat -x 2 5 # расширенный вывод (-x), обновление каждые 2 секунды, 5 раз

```

(Если команда не найдена, потребуется установка пакета sysstat, содержащего и iostat, и vmstat в более полной версии — стандартный vmstat часто уже предустановлен как часть базовых утилит, тогда как iostat обычно требует отдельной установки этого пакета.)

Ключевые колонки расширенного (-x) вывода iostat:

%util** — процент времени, в течение которого устройство было занято обработкой запросов ввода-вывода — значение, близкое к 100%, указывает на то, что диск является узким местом (bottleneck) производительности системы.
r/s, w/s** — количество операций чтения/записи в секунду.
rkB/s, wkB/s** — объём прочитанных/записанных данных в килобайтах в секунду.
await** — среднее время (в миллисекундах), которое запрос ввода-вывода проводит в очереди плюс время его фактического выполнения — высокое значение указывает на медленный или перегруженный диск.

Когда использовать какой инструмент — практическая систематизация:

top/htop** — быстрый общий обзор системы, идентификация конкретных «прожорливых» процессов.
vmstat** — быстрая общая оценка состояния памяти, свопинга, и общей загрузки процессора/дисковых операций без разбивки по отдельным процессам.
iostat** — когда top/vmstat показывают высокий wa (iowait) или подозрение падает конкретно на дисковую подсистему, для детального изучения того, какой именно физический диск является узким местом.

Практика

Шаг 1. Изучите количество ядер вашего процессора — это необходимая база для правильной интерпретации load average:

```bash

nproc

```

Шаг 2. Запустите top и изучите строку load average в связке с количеством ядер:

```bash

top

```

Обратите внимание на первую строку с тремя числами load average. Разделите каждое из этих чисел на количество ядер, полученное на шаге 1, чтобы получить процент от максимально возможной загрузки. Выйдите из top клавишей q.

[Скриншот терминала с top и load average]

Шаг 3. Изучите детализацию %Cpu(s) — запустите top, и специально обратите внимание на значение wa (iowait):

```bash

top

```

Если значение wa близко к нулю (что типично для системы без активной дисковой нагрузки в данный момент) — это ожидаемо, но полезно знать, где эта метрика находится на экране для будущей диагностики.

Шаг 4. Создайте временную искусственную дисковую нагрузку для демонстрации wa (безопасная, ограниченная по времени операция копирования большого временного файла):

```bash

dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 2>&1 &

top

```

(Команда dd — низкоуровневая утилита копирования данных, здесь используется для создания файла размером 1 ГБ из нулевых байтов, взятых из специального устройства /dev/zero — это создаёт кратковременную, но заметную дисковую нагрузку.)

Пока dd выполняется в фоне (символ & в конце команды, материал Блока 11), в top вы, возможно, заметите кратковременное повышение wa. Выйдите из top через q, дождитесь завершения dd, и удалите временный файл:

```bash

rm /tmp/testfile

```

[Скриншот терминала с повышенным wa]

Шаг 5. Запустите vmstat с интервалом обновления:

```bash

vmstat 2 5

```

Что вы увидите: пять строк статистики, обновляемых каждые 2 секунды. Обратите особое внимание на колонки swpd, si, so (активность свопа) — в норме, на системе с достаточным объёмом оперативной памяти, эти значения должны быть нулевыми или близкими к нулю.

[Скриншот вывода vmstat]

Шаг 6. Изучите однократный, «мгновенный» вывод vmstat без повторения (без указания интервала и количества — покажет статистику с момента последней перезагрузки):

```bash

vmstat

```

Шаг 7. Проверьте наличие iostat, и установите пакет sysstat, если необходимо:

```bash

iostat -V

```

Если не найдено:

```bash

sudo apt update

sudo apt install sysstat

```

Шаг 8. Запустите iostat с расширенным выводом:

```bash

iostat -x 2 3

```

Что вы увидите: статистику по каждому обнаруженному диску/разделу вашей системы, включая колонки %util, r/s, w/s, await, обновляемую трижды с интервалом 2 секунды.

[Скриншот расширенного вывода iostat]

Шаг 9. Создайте искусственную дисковую нагрузку ещё раз, на этот раз одновременно наблюдая через iostat в отдельном терминале (если у вас есть возможность открыть второе окно/вкладку терминала) — если нет второй сессии, выполните последовательно:

```bash

iostat -x 2 5 &

dd if=/dev/zero of=/tmp/testfile2 bs=1M count=2048

wait

rm /tmp/testfile2

```

(wait, команда, встроенная в bash — заставляет скрипт/сессию дождаться завершения фонового процесса, запущенного через &, прежде чем продолжить — полезная деталь для координации фоновых задач, которую мы не разбирали подробно в Блоке 15, но которая логично дополняет уже изученный материал о фоновых процессах.)

Что вы увидите: во время выполнения dd значения %util, w/s, wkB/s в выводе iostat заметно повысятся, демонстрируя реальную дисковую активность в реальном времени.

[Скриншот iostat во время активной записи на диск]

Шаг 10. Сравните вывод htop (материал Блока 11) с только что изученными инструментами — обратите внимание на то, что htop тоже показывает индивидуальные полоски загрузки для каждого ядра процессора отдельно, что даёт более наглядное, визуальное представление о распределении нагрузки между ядрами по сравнению с текстовым выводом vmstat:

```bash

htop

```

Выйдите через q или F10.

Разбор команд

Команда nproc

Назначение:** вывести количество доступных процессорных ядер (точнее, логических процессоров, что не всегда то же самое, что физические ядра, если включена технология Hyper-Threading/SMT).

Команда vmstat

Назначение:** сводная статистика памяти, процессов, свопинга и процессора.
Синтаксис:** vmstat [интервал [количество]]
Ключевые колонки:** r/b (процессы в очереди/заблокированные), swpd/si/so (своп), us/sy/id/wa (процессор).

Команда iostat

Назначение:** детальная статистика дисковой активности по каждому устройству.
Синтаксис:** iostat [-x] [интервал [количество]]; -x — расширенный вывод с дополнительными колонками.
Ключевые колонки:** %util, r/s/w/s, await.
Требует установки пакета:** sudo apt install sysstat.

Команда dd

Назначение:** низкоуровневое копирование и преобразование данных, здесь применена для создания тестового файла заданного размера.
Синтаксис:** dd if=источник of=назначение bs=размер_блока count=количество_блоков
Предупреждение:** dd — мощный, но потенциально опасный инструмент при неаккуратном использовании (например, ошибка в указании of= может привести к перезаписи важных данных или даже целого диска) — всегда внимательно проверяйте параметры перед выполнением.

Возможные ошибки

Ошибка:** интерпретация высокого числа load average как признака проблемы без учёта количества ядер процессора.

Почему возникает: непонимание того, что load average — абсолютное число процессов в очереди, требующее сопоставления с количеством доступных ядер для содержательной интерпретации.

Как избежать: всегда проверять nproc и делить значение load average на это число, чтобы получить процент от максимальной нагрузки, прежде чем делать выводы о состоянии системы.

Ошибка:** беспокойство по поводу малого значения free памяти в top/free -h, без учёта buff/cache.

Почему возникает: непонимание того, что Linux намеренно использует свободную память для кэша, и эта память мгновенно доступна для приложений при необходимости.

Как избежать: оценивать реальную доступность памяти по колонке available в выводе free -h (если доступна в вашей версии free — современные версии обычно её показывают), а не по колонке free, которая отражает лишь абсолютно неиспользуемую память, не учитывая легко освобождаемый кэш.

Практические задания

Изучите вывод free -h (команда, кратко упомянутая в Блоке 9, но не разбираемая детально) на вашей системе, сопоставьте значения total, used, free, buff/cache, available — объясните в конспекте своими словами, почему available обычно значительно больше, чем просто free.
Установите sysstat (если ещё не установлен) и запустите iostat -x 5 10 (10 обновлений с интервалом в 5 секунд) в фоновом режиме, тем временем выполняя обычную работу в системе (просмотр файлов, редактирование, что угодно) — изучите, меняются ли показатели %util в ответ на ваши действия.
Проведите эксперимент: запустите vmstat 1 20 (20 обновлений с интервалом в 1 секунду) и одновременно (в отдельном окне или после завершения этой команды повторно) запустите ресурсоёмкую операцию — например, распаковку большого архива или компиляцию, если у вас есть подходящий пример под рукой; в противном случае используйте команду из шага 4 практики (dd) с увеличенным размером файла. Опишите в конспекте, как изменились колонки us, sy, wa во время этой операции по сравнению с состоянием покоя.

Проверка знаний

Вопрос 1. Почему load average, равный 2.0, может быть совершенно нормальным показателем для одной системы, но серьёзным поводом для беспокойства для другой?

Ответ: Load average — это абсолютное число процессов, находящихся в очереди на выполнение или заблокированных в ожидании ввода-вывода, безотносительно к количеству доступных процессорных ядер. На системе с 8 ядрами load average 2.0 означает лишь 25% от максимальной теоретической загрузки — совершенно комфортное состояние. На системе с одним-двумя ядрами то же самое значение 2.0 означает полную или даже избыточную загрузку, при которой процессы начинают заметно «ждать» своей очереди на выполнение. Именно поэтому интерпретация load average всегда требует сопоставления с результатом команды nproc.

Вопрос 2. Что означает высокое значение wa (iowait) в выводе top, и на какую именно проблему это обычно указывает — на процессор или на что-то другое?

Ответ: wa показывает долю времени, в течение которого процессор простаивает специально потому, что ожидает завершения операции ввода-вывода (чаще всего дисковой). Высокое значение wa парадоксально означает не проблему с самим процессором (он как раз свободен и мог бы выполнять другую работу), а проблему с подсистемой ввода-вывода — обычно медленным, перегруженным или неисправным диском, из-за которого процессы вынуждены простаивать в ожидании данных. При обнаружении высокого wa дальнейшую диагностику стоит направить именно на дисковую подсистему — например, через детальный анализ с помощью iostat.

Итоги урока

Вы изучили: углублённую интерпретацию load average с учётом количества ядер, детализацию использования процессора (us/sy/wa/id) и памяти (buff/cache) в top, инструменты vmstat (сводная статистика памяти/процессора/свопинга) и iostat (детальная дисковая статистика по устройствам), практический алгоритм выбора подходящего инструмента для конкретной диагностической ситуации.

Вы умеете: правильно интерпретировать load average, различать реальную нехватку памяти от нормального использования кэша, диагностировать проблемы дисковой подсистемы через iostat, создавать контролируемую тестовую нагрузку для практики диагностики.

В следующем уроке потребуется: владение всеми изученными в этом и предыдущем уроке инструментами — теперь мы применим их вместе в рамках целостного процесса поиска причин конкретной проблемы производительности.

Урок 18.3. Поиск причин нагрузки

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

Теория

От отдельных инструментов к целостному процессу. В предыдущих уроках (и ранее в курсе, особенно в Блоке 11) мы изучили множество отдельных диагностических инструментов. Настоящее профессиональное мастерство администратора заключается не просто в знании этих инструментов по отдельности, а в умении систематически комбинировать их для быстрого и точного нахождения первопричины конкретной проблемы — будь то жалоба пользователя на «медленную работу сервера», внезапный рост потребления ресурсов, или полная неработоспособность службы.

Общая стратегия диагностики нагрузки — последовательность «от общего к частному»:

Шаг 1: Подтвердить и охарактеризовать проблему. Прежде чем что-либо диагностировать, важно чётко понять: что именно наблюдается? Медленный отклик конкретного приложения? Общее «зависание» системы? Полная недоступность? Когда это началось? Это происходит постоянно или периодически? Эта информация критически сужает пространство поиска.

Шаг 2: Общий обзор состояния системы. Начать с широких, общих инструментов — top/htop для быстрого понимания общей картины: высокая ли загрузка процессора, много ли используется памяти, есть ли признаки свопинга, высок ли wa. Этот шаг обычно сразу подсказывает, в каком направлении двигаться дальше — «упирается» ли система в процессор, в память, или в диск.

Шаг 3: Определить конкретный ресурс-«узкое место» (bottleneck). На основе общего обзора использовать специализированные инструменты для более глубокого анализа именно того ресурса, который выглядит наиболее подозрительным:

Если высок %CPU у конкретных процессов в top — процессор действительно является узким местом, переходим к детальному изучению конкретных процессов.
Если высок wa — вероятно, узкое место в дисковой подсистеме, переходим к iostat (материал предыдущего урока).
Если наблюдается активный свопинг (si/so в vmstat) — вероятно, проблема в нехватке оперативной памяти.
Если ни процессор, ни память, ни диск не выглядят перегруженными, но проблема всё равно наблюдается — возможно, дело в сети (материал Блока 12), либо в конкретном приложении, ожидающем внешний ресурс (например, медленно отвечающую базу данных или внешний API).

Шаг 4: Идентифицировать конкретный процесс-виновник. Найдя перегруженный ресурс, следующий шаг — определить, какой именно процесс потребляет его больше остальных:

```bash

ps aux --sort=-%cpu | head -10 # топ-10 процессов по использованию CPU

ps aux --sort=-%mem | head -10 # топ-10 процессов по использованию памяти

```

(Мы уже применяли похожую команду в Блоке 14 для аудита безопасности — здесь та же техника применяется в контексте диагностики производительности.)

Инструмент pidstat (часть того же пакета sysstat, что и iostat) предоставляет детальную, разбитую по времени статистику использования ресурсов конкретными процессами — полезно, когда обычного «мгновенного снимка» ps/top недостаточно, и требуется проследить изменение потребления ресурсов процессом во времени:

```bash

pidstat 2 5 # статистика CPU по всем процессам, обновление каждые 2 секунды, 5 раз

pidstat -r 2 5 # статистика использования памяти

pidstat -d 2 5 # статистика дискового ввода-вывода по процессам

```

Особенно ценность pidstat -d в том, что она показывает, какой конкретный процесс создаёт дисковую нагрузку, обнаруженную через iostat (который показывает статистику по устройству в целом, но не разбивает её по процессам).

Шаг 5: Изучить логи, связанные с подозрительным процессом или временным периодом. После определения проблемного процесса или временного окна, обратиться к материалу предыдущего урока — изучить journalctl -u имя_службы для соответствующей службы, или общие логи (/var/log/syslog) за интересующий период, в поисках сообщений об ошибках, предупреждений или другой полезной диагностической информации, объясняющей, почему этот процесс потребляет столько ресурсов.

Шаг 6: Проверить недавние изменения. Часто причиной внезапного ухудшения производительности являются недавние изменения — обновление пакета (материал /var/log/dpkg.log из предыдущего урока), изменение конфигурации, увеличение объёма данных или нагрузки (например, рост числа пользователей). Вопрос «что изменилось незадолго до того, как начались проблемы?» часто оказывается ключевым для быстрого нахождения причины.

Инструмент lsof («list open files», список открытых файлов) — чрезвычайно полезная утилита, показывающая все файлы (в широком, unix-понимании «файла» — включая сетевые соединения, вспомните философию «всё есть файл» из ранних блоков курса), открытые конкретным процессом или связанные с конкретным файлом/портом:

```bash

lsof -p PID # все открытые файлы конкретного процесса

lsof -i :80 # какой процесс использует порт 80 (расширение материала Блока 12, где мы использовали ss для похожей задачи)

lsof /путь/к/файлу # какие процессы имеют открытым конкретный файл

```

Инструмент strace (кратко упомянем для общего представления — детальное освоение выходит за рамки вводного курса) — позволяет отследить все системные вызовы (низкоуровневые обращения программы к ядру операционной системы), которые выполняет конкретный процесс, что бывает бесценно для очень глубокой диагностики того, «что именно делает» зависший или странно ведущий себя процесс, хотя требует более продвинутого понимания внутреннего устройства системы для полноценной интерпретации вывода.

Практика

Шаг 1. Установите pidstat, если он ещё не установлен (входит в тот же пакет sysstat, что и iostat из предыдущего урока):

```bash

pidstat -V

```

Если не найдено, sysstat уже должен быть установлен из практики предыдущего урока — в противном случае: sudo apt install sysstat.

Шаг 2. Создайте безопасную, контролируемую искусственную нагрузку на процессор для практики полного диагностического цикла — простой bash-скрипт, интенсивно нагружающий CPU в течение ограниченного времени:

```bash

cd ~/scripts

cat > cpu_load_demo.sh << 'EOF'

#!/bin/bash

echo "Создаю нагрузку на CPU на 30 секунд..."

end=$((SECONDS + 30))

while [ $SECONDS -lt $end ]; do

echo "scale=5000; 4*a(1)" | bc -l > /dev/null

done

echo "Нагрузка завершена."

EOF

chmod +x cpu_load_demo.sh

```

(Этот скрипт использует bc — калькулятор командной строки — для интенсивных, повторяющихся математических вычислений, создавая реальную нагрузку на процессор в течение 30 секунд. Переменная SECONDS, встроенная в bash, автоматически считает количество секунд с начала выполнения текущего скрипта — полезная деталь, которую мы не упоминали в Блоке 15, но логично дополняющая изученный материал о переменных.)

Установите bc, если необходимо:

```bash

sudo apt install bc

```

Шаг 3. Запустите скрипт в фоновом режиме и сразу приступите к его диагностике, применяя весь пошаговый процесс из теории:

```bash

./cpu_load_demo.sh &

```

Шаг 4 (Шаг 2 диагностического процесса — общий обзор):

```bash

top

```

Что вы увидите: заметно повышенное значение %us (user CPU time) в строке %Cpu(s), и в списке процессов — процесс bc, потребляющий значительную долю CPU. Выйдите через q.

[Скриншот терминала с высокой нагрузкой от bc]

Шаг 5 (Шаг 4 диагностического процесса — идентификация процесса-виновника):

```bash

ps aux --sort=-%cpu | head -5

```

Что вы увидите: процесс bc (или его родительская bash-оболочка, в зависимости от того, как именно система показывает вложенный процесс) на верхней позиции по потреблению CPU.

Шаг 6. Используйте pidstat для детального наблюдения за конкретным процессом во времени — сначала найдите PID процесса bc:

```bash

pgrep bc

```

(pgrep, команда, которую мы кратко упоминали в Блоке 11 — находит PID процессов по имени.)

```bash

pidstat -p $(pgrep bc | head -1) 1 5

```

Что вы увидите: детальную статистику использования CPU именно этим процессом на протяжении 5 обновлений с интервалом в секунду.

[Скриншот вывода pidstat для конкретного процесса]

Шаг 7. Дождитесь автоматического завершения фоновой нагрузки (около 30 секунд с момента запуска) или, если хотите завершить её раньше для продолжения практики, останавливающих его вручную:

```bash

pkill -f cpu_load_demo.sh

```

(pkill, тоже кратко упомянутая в Блоке 11 — завершает процессы по совпадению имени/командной строки, здесь используем флаг -f для поиска совпадения по полной командной строке, а не только по имени исполняемого файла.)

Шаг 8. Теперь продемонстрируем диагностику, ориентированную на сеть/открытые порты — изучите, какой процесс слушает конкретный порт (расширение материала Блока 12):

```bash

sudo lsof -i :22

```

Что вы увидите: процесс sshd, слушающий порт 22 — SSH-служба, с которой мы подробно работали в Блоке 13.

[Скриншот вывода lsof для порта 22]

Шаг 9. Изучите все открытые файлы конкретного процесса (используя PID самого демона SSH или, для интереса, PID вашей текущей оболочки):

```bash

lsof -p $$

```

(Вспомните $$ — PID текущего процесса, изученный в уроке 15.3.)

Что вы увидите: список файлов, открытых вашей текущей bash-сессией — включая, например, файл истории команд, открытые терминальные устройства, и, если есть, дополнительные файлы, с которыми вы недавно работали.

Шаг 10. Проверьте, какой процесс использует конкретный файл — например, файл лога, который может быть заблокирован и недоступен для чтения другим процессом, пока используется первым:

```bash

lsof /var/log/syslog

```

Шаг 11. Смоделируйте полный сценарий комплексной диагностики — представьте гипотетическую ситуацию «сервер работает медленно» и пройдите весь чек-лист, записывая результаты каждого шага в конспект:

```bash

echo "=== Шаг 1: Общий обзор ==="

uptime

echo "=== Шаг 2: Топ процессов по CPU ==="

ps aux --sort=-%cpu | head -5

echo "=== Шаг 3: Топ процессов по памяти ==="

ps aux --sort=-%mem | head -5

echo "=== Шаг 4: Состояние диска ==="

df -h

echo "=== Шаг 5: Свежие ошибки в journal ==="

journalctl -p err --since "1 hour ago" | tail -10

```

(Команда uptime, которую мы уже использовали в разных контекстах ранее в курсе, показывает, помимо времени работы системы, также и load average — удобная сводка в одну строку для самого первого, самого общего взгляда на состояние системы.)

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

[Скриншот полного диагностического отчёта]

Разбор команд

Команда pidstat

Назначение:** детальная, разбитая по времени статистика использования ресурсов (CPU, память, диск) конкретными процессами.
Синтаксис:** pidstat [-p PID] [опции] [интервал [количество]]; -r (память), -d (диск).

Команда pgrep

Назначение:** найти PID процессов, соответствующих имени/шаблону.
Синтаксис:** pgrep имя_процесса

Команда pkill

Назначение:** завершить процессы, соответствующие имени/шаблону (аналог kill, но по имени, а не по PID).
Синтаксис:** pkill [-f] имя_процесса; -f — искать совпадение по всей командной строке, а не только по имени исполняемого файла.

Команда lsof

Назначение:** показать список открытых файлов, включая сетевые соединения.
Синтаксис:** lsof [-p PID] (файлы процесса), lsof -i :порт (процесс, использующий порт), lsof /путь (процессы, использующие конкретный файл).

Переменная $SECONDS

Назначение:** встроенная переменная bash, автоматически считающая количество секунд с момента запуска текущего скрипта/сессии оболочки.

Возможные ошибки

Ошибка:** попытка диагностировать проблему производительности, глядя только на один-единственный инструмент/метрику, без систематического прохождения по всей цепочке возможных узких мест.

Почему возникает: соблазн сразу «угадать» причину на основе первого увиденного показателя, без проверки альтернативных гипотез.

Как избежать: следовать систематическому процессу «от общего к частному», описанному в теории — начиная с общего обзора (top/uptime), последовательно проверяя каждую категорию ресурсов (CPU, память, диск, сеть), прежде чем делать окончательные выводы.

Ошибка:** путаница между высоким использованием CPU конкретным процессом и общей загрузкой всей системы.

Почему возникает: невнимательное чтение вывода top/ps — например, процесс с %CPU больше 100% на многоядерной системе (что вполне возможно и означает использование более одного ядра одновременно многопоточным процессом) может ошибочно интерпретироваться как ошибка вывода.

Как избежать: помнить, что %CPU в выводе ps/top для отдельного процесса может превышать 100% на многоядерных системах (100% соответствует полной загрузке одного ядра; при использовании нескольких ядер одним многопоточным процессом суммарное значение может достигать, например, 350% на четырёхъядерной системе).

Практические задания

Модифицируйте скрипт cpu_load_demo.sh из практики, чтобы он запускал не один, а три параллельных процесса нагрузки одновременно (используя & для каждого из трёх вызовов bc и wait в конце для ожидания завершения всех трёх) — понаблюдайте через top/htop, как распределяется нагрузка между ядрами процессора (если ядер больше одного).
Используя lsof, найдите, какой процесс на вашей системе имеет открытым больше всего файлов одновременно (подсказка: можно скомбинировать lsof с уже знакомыми нам sort/uniq -c/sort -rn из Блока 6, группируя вывод lsof по имени процесса, колонка COMMAND) — объясните в конспекте, почему определённые типы процессов (например, базы данных, веб-серверы) обычно держат открытым больше файлов, чем простые утилиты.
Создайте собственный bash-скрипт quick_diag.sh (расширяя пример из шага 11 практики), сохраняющий результаты диагностического чек-листа в файл с меткой времени в названии, и настройте его на запуск через cron (материал Блока 15, урок 15.9) каждый час, для накопления истории состояния системы, которую впоследствии можно будет проанализировать в поисках паттернов.

Проверка знаний

Вопрос 1. Опишите общую логику систематического диагностического процесса «от общего к частному» при поиске причины нагрузки на систему.

Ответ: Процесс начинается с широкого, общего обзора состояния системы (через top/htop/uptime), позволяющего быстро определить общее направление проблемы — процессор, память, диск или что-то ещё. Затем, на основе этого общего обзора, применяются более специализированные инструменты для глубокого анализа именно того ресурса, который выглядит проблемным (например, iostat при подозрении на диск, pidstat для детального изучения конкретного процесса во времени). После определения перегруженного ресурса и конкретного процесса-виновника исследуются связанные логи (journalctl) и недавние изменения в системе, чтобы понять первопричину, а не только симптом проблемы.

Вопрос 2. Чем pidstat отличается от обычного ps aux --sort=-%cpu, и когда стоит использовать именно pidstat?

Ответ: ps aux --sort=-%cpu даёт лишь один, «мгновенный снимок» текущего состояния процессов в момент выполнения команды. pidstat, подобно vmstat/iostat, может выводить повторяющуюся статистику с заданным интервалом, показывая изменение потребления ресурсов конкретным процессом во времени — что особенно ценно, когда нужно проследить динамику (растёт ли потребление ресурсов процессом, колеблется ли оно, или стабильно) вместо единичного снимка, а также когда нужна более детальная статистика конкретно по дисковому вводу-выводу процесса (pidstat -d), не входящая в стандартный вывод ps.

Итоги урока

Вы изучили: систематический шестишаговый процесс диагностики нагрузки (от подтверждения проблемы до проверки недавних изменений), инструменты pidstat (детальная статистика по процессам во времени), lsof (открытые файлы и сетевые соединения), pgrep/pkill (поиск и завершение процессов по имени), краткое представление о strace.

Вы умеете: последовательно и методично диагностировать причины повышенной нагрузки, идентифицировать конкретные процессы-виновники, находить, какой процесс использует конкретный порт или файл, создавать контролируемую тестовую нагрузку для отработки диагностических навыков.

В следующем уроке потребуется: понимание всех изученных ранее диагностических инструментов — теперь мы познакомимся с промышленными системами мониторинга, автоматизирующими и визуализирующими многое из того, что мы делали вручную.

Урок 18.4. Обзор Netdata, Zabbix, Prometheus

Получить общее представление о промышленных системах мониторинга, понять, какую проблему ручного администрирования они решают, разобраться в основных архитектурных различиях между рассматриваемыми инструментами, и осознать, когда и зачем стоит переходить от ручной диагностики к автоматизированному мониторингу.

Теория

От ручной диагностики к постоянному мониторингу — зачем нужен переход. Всё, что мы изучали в предыдущих двух уроках этого блока — прекрасные, мощные инструменты, но у них есть фундаментальное ограничение: они показывают состояние системы в момент запуска команды. Если проблема производительности возникла ночью, когда никто не следил за системой, и к утру уже разрешилась сама собой (или система просто перезагрузилась) — вы, скорее всего, никогда не узнаете, что именно произошло, ведь top/vmstat/iostat не сохраняют историю автоматически. Системы мониторинга решают именно эту проблему: они непрерывно, автоматически собирают метрики (числовые показатели состояния системы) через равные промежутки времени, сохраняют их в специализированную базу данных, предоставляют удобную визуализацию (обычно через веб-интерфейс с графиками), и — что особенно важно для реальной эксплуатации — могут автоматически оповещать администратора (например, по email, в мессенджер, или через любой другой канал), когда определённые показатели выходят за заданные пороговые значения, ещё до того, как проблема станет критичной или заметной пользователям.

Этот урок носит обзорный характер — мы не будем детально устанавливать и настраивать каждый инструмент (что является темой отдельных, весьма объёмных курсов), а познакомимся с ключевыми концепциями и различиями между тремя широко используемыми в индустрии решениями, чтобы вы могли осознанно ориентироваться в этой области и знать, куда двигаться дальше при необходимости.

Netdata — простота и мгновенная детализация.

Netdata — инструмент мониторинга, разработанный с акцентом на исключительную простоту установки (часто буквально одна команда) и чрезвычайно детализированную, визуально насыщенную панель мониторинга в реальном времени, работающую прямо «из коробки» без сложной настройки. Ключевые характеристики:

Собирает метрики с очень высокой частотой (обычно раз в секунду), что даёт исключительно детальную картину происходящего именно сейчас.
Автоматически обнаруживает множество работающих на сервере служб (базы данных, веб-серверы, Docker-контейнеры — материал предыдущего блока) и начинает собирать специфичные для них метрики без ручной настройки.
Изначально спроектирован для мониторинга одного конкретного сервера с исключительной детализацией «здесь и сейчас», хотя современные версии Netdata также поддерживают централизованный сбор данных с нескольких серверов.
Идеально подходит для быстрой, глубокой диагностики происходящего на конкретном сервере прямо в данный момент — своего рода промышленный, автоматизированный, визуализированный аналог инструментов, которые мы изучали вручную в предыдущих уроках этого блока.

Zabbix — комплексная система мониторинга масштаба предприятия.

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

Архитектура клиент-сервер: центральный Zabbix Server собирает данные от множества Zabbix Agent (небольших программ, устанавливаемых на каждый отслеживаемый сервер) или через прямой опрос (для устройств без установленного агента, например, сетевого оборудования — материал, вскользь связанный с сетевыми технологиями Блока 12).
Мощная, гибкая система оповещений (алертинга) с поддержкой сложных условий срабатывания, эскалации, интеграции с самыми разными каналами уведомлений.
Хранит долгосрочную историю метрик в собственной базе данных (часто использующую те же СУБД, что мы изучим в Блоке 19 — например, PostgreSQL или MySQL), позволяя анализировать долгосрочные тренды за месяцы и годы.
Требует более существенных усилий по первоначальной настройке по сравнению с Netdata, но предоставляет взамен значительно более широкие возможности для комплексного мониторинга разнородной инфраструктуры.

Prometheus (в связке с Grafana) — современный стандарт для облачных и контейнеризированных сред.

Prometheus — система мониторинга, ставшая фактическим стандартом в экосистеме современных облачных и контейнеризированных приложений (тесно связанная с материалом предыдущего Блока 17 про Docker, и особенно с уже упомянутой там технологией Kubernetes). Ключевые архитектурные особенности, заметно отличающие Prometheus от Zabbix и Netdata:

Модель «pull» (вытягивание), а не «push» (проталкивание). В отличие от многих других систем, где отслеживаемые серверы сами отправляют метрики на центральный сервер мониторинга, Prometheus работает наоборот: сам сервер Prometheus периодически опрашивает** («вытягивает» данные с) каждый отслеживаемый источник через специальный HTTP-эндпоинт (адрес, аналогичный тем, что мы разбирали при изучении веб-технологий в Блоке 12), который эта система сама предоставляет.
Экспортёры (exporters)** — небольшие вспомогательные программы, которые запускаются рядом с отслеживаемой системой/приложением и предоставляют её метрики в специальном, стандартизированном текстовом формате, понятном Prometheus, через простой HTTP-запрос. Существует огромное множество готовых экспортёров для самых разных технологий (баз данных, веб-серверов, самой операционной системы через node_exporter).
Prometheus сам по себе не предоставляет продвинутую визуализацию — для этого практически всегда используется отдельный, специализированный инструмент Grafana, подключаемый к Prometheus как к источнику данных и предоставляющий чрезвычайно гибкие, настраиваемые дашборды (панели с графиками).
Особенно хорошо подходит для мониторинга динамичных, часто меняющихся инфраструктур — например, когда контейнеры (материал Блока 17) постоянно создаются и уничтожаются, что плохо сочетается с более «статичными» моделями агентов, характерными для традиционных систем вроде Zabbix.

Сравнительная таблица — краткое резюме различий:

|---|---|---|---|

Какой инструмент выбрать — практическое соображение (без универсально «правильного» ответа). Выбор конкретной системы мониторинга зависит от масштаба и специфики инфраструктуры: для быстрой, детальной диагностики одного-двух серверов Netdata часто оказывается наиболее удобным стартовым выбором благодаря простоте; для комплексного мониторинга традиционной, разнородной корпоративной инфраструктуры (серверы, сетевое оборудование, разные операционные системы) часто выбирают Zabbix; для современных, активно использующих контейнеризацию и облачные технологии инфраструктур Prometheus в связке с Grafana стал практически отраслевым стандартом. Многие организации в реальности используют комбинацию нескольких таких инструментов для разных целей.

Практика

Поскольку полноценная установка и настройка любой из этих систем — весьма объёмная тема, выходящая за рамки вводного курса, мы познакомимся с ними на практике через быструю, безопасную установку Netdata (действительно устанавливаемого буквально одной командой) для получения непосредственного, наглядного опыта работы с полноценной системой мониторинга.

Шаг 1. Установите Netdata через официальный скрипт быстрой установки (аналогично тому, как мы добавляли официальный репозиторий Docker в Блоке 17, здесь используется несколько иной, но тоже официально поддерживаемый метод — однострочный установочный скрипт, широко практикуемый именно для Netdata):

```bash

curl -Ss https://my-netdata.io/kickstart.sh | sh

```

(Обратите внимание: выполнение скриптов, скачанных из интернета и сразу передаваемых на выполнение через конвейер, — практика, к которой стоит подходить с осторожностью и доверять только для действительно надёжных, официальных источников, каким в данном случае является официальный сайт проекта Netdata; в общем случае разумной практикой является сначала скачать и изучить содержимое скрипта, прежде чем его выполнять.)

Дождитесь завершения установки — процесс может занять несколько минут.

[Скриншот процесса установки Netdata]

Шаг 2. Проверьте, что служба Netdata запущена (применяя уже привычный нам из Блока 10 подход):

```bash

sudo systemctl status netdata

```

Шаг 3. Netdata по умолчанию предоставляет веб-интерфейс на порту 19999. Если вы работаете в графической среде с доступом к браузеру на этой же машине, откройте:

```

http://localhost:19999

```

Если вы работаете исключительно через терминал без графического доступа (например, на удалённом сервере, к которому подключены только по SSH), эта возможность будет ограничена — в таком случае прочитайте следующий шаг как ознакомительный, без обязательного выполнения.

Шаг 4. Изучите (через браузер, если доступен) визуальную панель мониторинга Netdata: секции с загрузкой CPU в реальном времени (обновляется буквально каждую секунду), использованием памяти, дисковой активностью, сетевым трафиком — обратите внимание, насколько это визуально похоже на данные, которые мы вручную собирали через top/vmstat/iostat в предыдущих уроках, но представленные в виде наглядных, непрерывно обновляющихся графиков.

[Если доступно: скриншот веб-интерфейса Netdata]

Шаг 5. Изучите, какие метрики Netdata собирает через его собственный API — даже без графического интерфейса можно получить данные в текстовом (JSON) виде через curl прямо из терминала:

```bash

curl -s http://localhost:19999/api/v1/info | head -30

```

Шаг 6. Получите текущее значение конкретной метрики (загрузка системы) через API:

```bash

curl -s "http://localhost:19999/api/v1/data?chart=system.load" | head -20

```

Что вы увидите: структурированные данные о load average, собираемые Netdata автоматически — та же метрика, которую мы вручную изучали через uptime/top в предыдущих уроках, но теперь непрерывно собираемая и доступная программно.

[Скриншот вывода API]

Шаг 7. Изучите конфигурационные файлы Netdata (для общего представления, не обязательно изменяя их):

```bash

sudo ls -la /etc/netdata/

```

Шаг 8. Если вы решите не оставлять Netdata установленным после практики этого урока (например, для экономии ресурсов учебной системы), изучите (но не обязательно выполняйте, если хотите продолжить исследовать инструмент) команду для удаления, которую сам установочный скрипт обычно подсказывает в своём выводе, либо через:

```bash

sudo netdata-uninstaller.sh 2>/dev/null || echo "Для удаления следуйте официальной документации Netdata, если понадобится."

```

Разбор команд

В этом уроке мы работали в первую очередь с самим приложением Netdata через его веб-интерфейс и API, а не с новыми bash-командами. Ключевые уже знакомые нам команды, применённые в новом контексте:

systemctl status netdata — проверка статуса службы мониторинга, тем же способом, что мы проверяли любую другую службу на протяжении курса (Блок 10).

curl -s URL — обращение к локальному API Netdata, аналогично тому, как мы использовали curl для проверки веб-серверов в Docker-контейнерах в Блоке 17.

Возможные ошибки

Ошибка:** веб-интерфейс Netdata (порт 19999) недоступен при попытке подключения с другого компьютера (не с самого сервера).

Почему возникает: по умолчанию firewall (если настроен, материал Блока 14) может блокировать этот порт для внешнего доступа; кроме того, сам Netdata по умолчанию иногда настроен слушать только на localhost, а не на всех сетевых интерфейсах.

Как исправить: если нужен внешний доступ — открыть порт в UFW (sudo ufw allow 19999/tcp, материал Блока 14) и проверить конфигурацию Netdata на предмет привязки к нужному сетевому интерфейсу; для реальной эксплуатации, впрочем, часто рекомендуется не открывать интерфейс мониторинга напрямую всему интернету по соображениям безопасности, а использовать дополнительные меры защиты (аутентификацию, ограничение по IP, или доступ исключительно через VPN/SSH-туннель).

Как избежать: осознанно решать вопрос сетевого доступа к инструментам мониторинга с самого начала, учитывая, что такие панели часто содержат чувствительную информацию о внутреннем устройстве и состоянии инфраструктуры.

Практические задания

Изучите список всех доступных «чартов» (графиков/метрик), которые собирает Netdata на вашей системе, через API: curl -s http://localhost:19999/api/v1/charts | grep '"id"' | head -30 — найдите среди них хотя бы 5 метрик, о которых мы не говорили явно в этом курсе, и изучите (через документацию Netdata или её собственное описание в API), что именно они измеряют.
Найдите в интернете (без обязательной установки) информацию о том, как выглядит типичный дашборд Grafana, подключённый к Prometheus, и сравните визуально с тем, что вы видели (или могли бы увидеть) в веб-интерфейсе Netdata — опишите в конспекте замеченные различия в подходе к представлению данных.
Прочитайте (через поиск в интернете) о концепции node_exporter в экосистеме Prometheus, и опишите в конспекте, какие именно метрики операционной системы (Linux) он обычно предоставляет — сопоставьте этот список с командами top/vmstat/iostat, которые мы изучали вручную в предыдущих уроках этого блока.

Проверка знаний

Вопрос 1. Какую фундаментальную проблему ручной диагностики (с помощью инструментов вроде top, vmstat, iostat) решают системы непрерывного мониторинга вроде Netdata, Zabbix или Prometheus?

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

Вопрос 2. В чём принципиальное архитектурное отличие модели сбора данных Prometheus (pull) от более традиционного подхода (push), используемого, например, в Zabbix?

Ответ: В модели push (традиционно используемой во многих системах мониторинга, включая типичную настройку Zabbix) отслеживаемые серверы или установленные на них агенты сами инициируют отправку метрик на центральный сервер мониторинга. В модели pull, используемой Prometheus, происходит обратное: центральный сервер Prometheus сам периодически обращается («опрашивает», «вытягивает» данные) к каждому отслеживаемому источнику через специальный HTTP-эндпоинт, который эта система предоставляет (часто с помощью вспомогательных программ-экспортёров). Модель pull особенно хорошо подходит для динамичных, часто меняющихся инфраструктур (например, с активно используемыми контейнерами), поскольку Prometheus может гибко обнаруживать и опрашивать новые источники метрик по мере их появления.

Итоги урока

Вы изучили: проблему, которую решают системы непрерывного мониторинга по сравнению с ручной диагностикой, ключевые характеристики и архитектурные особенности Netdata (простота, детализация в реальном времени), Zabbix (комплексность, масштаб предприятия, мощный алертинг), Prometheus+Grafana (модель pull, экспортёры, стандарт для облачных/контейнеризированных сред), практические соображения для выбора конкретного инструмента.

Вы умеете: устанавливать и базово использовать Netdata, обращаться к его API для получения метрик программно, ориентироваться в основных различиях между тремя рассмотренными подходами к промышленному мониторингу.

В последнем уроке этого блока потребуется: весь материал блока целиком — теперь мы соберём общий, универсальный алгоритм troubleshooting, применимый к диагностике практически любой проблемы, независимо от того, какие конкретно инструменты для этого используются.

Урок 18.5. Алгоритм troubleshooting

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

Теория

Зачем нужен формальный алгоритм, если можно просто «попробовать разобраться». Начинающие администраторы часто подходят к диагностике проблем хаотично — пробуют случайные решения, найденные через быстрый поиск в интернете, не до конца понимая происходящее, иногда даже усугубляя ситуацию непродуманными изменениями. Опытные администраторы, напротив, придерживаются (часто неосознанно, «на автомате», но тем не менее последовательно) определённой методологии — систематического процесса, который надёжно приводит к нахождению первопричины проблемы, минимизируя риск дальнейшего усугубления ситуации и экономя время в долгосрочной перспективе, даже если на первый взгляд кажется, что «интуитивный» подход был бы быстрее.

Универсальный алгоритм troubleshooting — пошаговый разбор.

Шаг 1: Точно определить и зафиксировать проблему (Identify).

Прежде чем что-либо делать, нужно чётко сформулировать: что именно наблюдается, в чём именно проявляется проблема? «Сервер медленный» — недостаточно конкретная формулировка для эффективной диагностики. Гораздо продуктивнее: «Веб-страница загружается 8 секунд вместо обычной 1 секунды, начиная примерно с 14:00 сегодня, воспроизводится стабильно при каждой попытке». Хорошая практика на этом шаге — точно зафиксировать (записать) наблюдаемые симптомы, время начала проблемы, и любые сообщения об ошибках дословно, а не по памяти.

Шаг 2: Собрать информацию о контексте (Gather information).

Что происходило непосредственно перед началом проблемы? Были ли недавние изменения — обновления пакетов (материал Блока 9, /var/log/dpkg.log из урока 18.1), изменения конфигурации, развёртывание нового кода, изменения в нагрузке (рост числа пользователей, необычный трафик)? Кто ещё может обладать релевантной информацией? Этот шаг напрямую использует навыки из уроков 18.1 и 18.3 этого блока.

Шаг 3: Сформулировать гипотезы (Hypothesize).

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

Шаг 4: Проверить гипотезы систематически, одну за другой (Test).

Проверять гипотезы по одной, начиная с наиболее вероятной или наиболее простой в проверке — а не пытаться исправить сразу несколько потенциальных причин одновременно. Это критически важный принцип: если внести сразу несколько изменений одновременно, и проблема исчезнет, вы не будете знать точно, какое именно из изменений её решило (что осложнит понимание проблемы и её предотвращение в будущем, а также может создать новые, отдельные проблемы, замаскированные под «решение» исходной). Этот шаг напрямую использует весь инструментарий, изученный в уроках 18.1-18.3: journalctl, top/htop, vmstat/iostat, pidstat, lsof.

Шаг 5: Внести изменение, ведущее к решению (Resolve).

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

Шаг 6: Проверить, что проблема действительно решена (Verify).

Не полагаться на предположение, что изменение сработало — явно, целенаправленно проверить, что первоначально наблюдаемая проблема (симптом из шага 1) действительно исчезла, желательно тем же способом, каким она изначально была обнаружена.

Шаг 7: Задокументировать проблему и решение (Document).

Записать, в чём заключалась проблема, какова была первопричина, и как именно она была решена. Это кажется необязательным «бюрократическим» шагом, но на практике оказывается бесценным: аналогичная проблема почти неизбежно повторится в будущем (возможно, через месяцы, возможно, у другого администратора той же инфраструктуры), и наличие точной документации резко сокращает время повторной диагностики. Именно для этой цели материал Блока 16 (Git) особенно полезен — многие команды хранят подобную документацию именно в версионируемых репозиториях.

Дополнительные важные принципы эффективного troubleshooting, дополняющие основной алгоритм:

Принцип «сначала самое простое» (Occam's razor в применении к диагностике). Начинать проверку гипотез с наиболее простых, наиболее вероятных объяснений, прежде чем переходить к экзотическим, маловероятным теориям. Известная шутливая, но практически полезная эвристика в мире IT: «если слышишь топот копыт — думай сначала о лошадях, а не о зебрах» — то есть сначала проверить типичные, распространённые причины (диск заполнен, служба не запущена, неверная конфигурация), прежде чем подозревать редкие, экзотические причины.

Принцип «не доверяй, а проверяй» (Don't assume, verify). Не полагаться на предположения о состоянии системы («наверное, служба работает», «скорее всего, порт открыт») — явно проверять каждое предположение конкретной командой, вместо того чтобы строить дальнейшую диагностику на непроверенном фундаменте.

Принцип разделения проблемы на части (Divide and conquer). Для сложных, многокомпонентных систем (например, веб-приложение, состоящее из веб-сервера, приложения и базы данных, материал которого мы coснёмся в Блоке 19) — методично изолировать, на каком именно «уровне» возникает проблема, тестируя каждый компонент по отдельности, если это возможно, вместо попытки понять всю сложную цепочку целиком сразу.

Принцип сохранения возможности отката (Preserve rollback capability). Перед внесением потенциально рискованного изменения — по возможности сохранять резервную копию текущего состояния (конфигурационного файла, как мы неоднократно практиковали в Блоке 14, или всей системы, о чём подробнее поговорим в Блоке 20) — чтобы в случае, если изменение не помогло или, хуже того, усугубило ситуацию, можно было быстро вернуться к известному рабочему состоянию.

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

Практика

В практике этого заключительного урока блока мы применим полный алгоритм troubleshooting к сконструированной, но реалистичной учебной проблеме, объединяя многие инструменты, изученные на протяжении всего курса.

Шаг 1. Смоделируем реалистичную проблему для практики — «сломаем» доступность веб-сервера намеренно, но контролируемым образом, чтобы затем провести полную диагностику с нуля. Сначала запустите контейнер с веб-сервером (применяя материал Блока 17):

```bash

docker run -d --name troubleshoot-demo -p 8888:80 nginx:alpine

```

Убедитесь, что он изначально работает:

```bash

curl -I http://localhost:8888

```

(Флаг -I у curl запрашивает только заголовки ответа, без полного тела страницы — более компактный способ быстро проверить доступность.)

Шаг 2. Теперь «сломаем» ситуацию — остановим контейнер, имитируя реальную проблему (в реальной жизни причиной недоступности мог бы быть сбой процесса, нехватка ресурсов, или множество других причин — мы выбираем простой, безопасный, воспроизводимый сценарий для практики):

```bash

docker stop troubleshoot-demo

```

Шаг 3. Применяем Шаг 1 алгоритма — точно определить проблему. Представьте, что вы получили от «пользователя» жалобу: «сайт не открывается». Проверьте это утверждение конкретно:

```bash

curl -I http://localhost:8888

```

Что вы увидите: ошибку соединения (curl: (7) Failed to connect...) — подтверждение того, что проблема реальна и воспроизводима.

[Скриншот терминала с ошибкой подключения]

Шаг 4. Применяем Шаг 2 — сбор информации о контексте. Проверьте общее состояние Docker и список контейнеров (вспомните материал Блока 17):

```bash

docker ps -a

```

Что вы увидите: контейнер troubleshoot-demo в статусе Exited — уже значимая информация, сужающая пространство поиска.

Шаг 5. Применяем Шаг 3 — сформулировать гипотезы. На основе увиденного на шаге 4, разумная гипотеза: «Контейнер веб-сервера остановлен, поэтому нет ответа на порт 8888». Альтернативные гипотезы для полноты (даже если основная уже выглядит убедительной, хорошая практика — не останавливаться на первом впечатлении без проверки): «возможно, проброс порта настроен неправильно», «возможно, проблема на уровне firewall хоста».

Шаг 6. Применяем Шаг 4 — проверить гипотезы систематически. Начнём с наиболее вероятной, простой для проверки гипотезы — статуса контейнера, что мы уже частично сделали на шаге 4. Дополнительно изучите логи контейнера перед его остановкой, чтобы понять, была ли какая-то ошибка, приведшая к остановке (в нашем случае мы намеренно остановили его командой, но в реальной ситуации это мог быть и сбой):

```bash

docker logs troubleshoot-demo

```

Шаг 7. Применяем Шаг 5 — внести целенаправленное изменение. На основе подтверждённой гипотезы (контейнер остановлен) — минимально необходимое действие: запустить контейнер заново:

```bash

docker start troubleshoot-demo

```

Шаг 8. Применяем Шаг 6 — проверить, что проблема решена, тем же способом, каким она была изначально обнаружена (шаг 3):

```bash

curl -I http://localhost:8888

```

Что вы увидите: успешный ответ HTTP/1.1 200 OK — проблема решена, что подтверждено конкретной, объективной проверкой, а не просто предположением.

[Скриншот успешного восстановления]

Шаг 9. Применяем Шаг 7 — задокументировать. Создайте простую запись о проведённой диагностике (в реальной практике это могло бы быть полноценным описанием инцидента в системе документации команды — материал Блока 16 про Git отлично подходит для хранения подобной документации):

```bash

cat > ~/troubleshooting_log_$(date +%Y%m%d).md << EOF

Дата: $(date)

Симптом: curl http://localhost:8888 возвращал ошибку соединения.

Диагностика: docker ps -a показал контейнер troubleshoot-demo в статусе Exited.

Причина: контейнер был остановлен.

Решение: docker start troubleshoot-demo.

Проверка: повторный curl вернул HTTP/1.1 200 OK.

EOF

cat ~/troubleshooting_log_$(date +%Y%m%d).md

```

[Скриншот созданного отчёта]

Шаг 10. Смоделируйте ещё одну, немного более сложную учебную проблему, самостоятельно применяя весь алгоритм — на этот раз проблема будет связана с портом, а не с остановленным контейнером. Остановите текущий контейнер и запустите новый, с намеренно неправильным пробросом порта (проброс на порт 9999 вместо ожидаемого 8888, к которому «привыкли» пользователи):

```bash

docker stop troubleshoot-demo

docker rm troubleshoot-demo

docker run -d --name troubleshoot-demo2 -p 9999:80 nginx:alpine

```

Теперь самостоятельно, применяя весь семишаговый алгоритм, продиагностируйте, почему curl http://localhost:8888` больше не работает, и найдите правильное решение (подсказка: примените материал Блока 12 и 17 о портах и пробросе; обратите внимание, что в данном случае «исправление» может заключаться не в изменении порта на хосте, а в понимании, что изменились ожидания — возможно, правильным решением было бы сообщить пользователям новый адрес, либо пересоздать контейнер с изначально ожидаемым портом 8888, если это было именно ошибкой конфигурации).



Шаг 11. Очистите все учебные контейнеры и файлы после завершения практики:

```bash

docker stop troubleshoot-demo2

docker rm troubleshoot-demo2

```

Разбор команд

В этом уроке мы не вводили принципиально новых команд, а системно применяли уже хорошо знакомый инструментарий (curl, docker ps/logs/stop/start, материал Блоков 12 и 17) в рамках формального диагностического процесса — что и является главной целью данного заключительного урока: не изучение новых команд, а синтез уже имеющихся знаний в целостную, применимую на практике методологию.

Возможные ошибки



Ошибка:** попытка одновременно внести несколько изменений «на всякий случай», без систематической проверки каждой гипотезы по отдельности.



Почему возникает: желание сэкономить время, «на всякий случай» исправить сразу несколько потенциальных причин одним махом.

Как определить/последствия: даже если проблема после этого исчезает, остаётся неясным, какое именно из внесённых изменений реально помогло — что осложняет понимание истинной причины и увеличивает риск, что одно из «попутных» изменений создаст новую, отдельную, замаскированную проблему.

Как избежать: строго следовать шагу 4 алгоритма — проверять гипотезы по одной, начиная с наиболее вероятной, документируя результат проверки каждой из них перед переходом к следующей.



Ошибка:** пропуск шага верификации (Шаг 6) — предположение, что внесённое изменение решило проблему, без явной, объективной проверки.



Почему возникает: излишняя уверенность после внесения «очевидно правильного» исправления.

Как избежать: всегда явно, объективно перепроверять исходный симптом проблемы тем же способом, каким она была обнаружена изначально — не полагаться на субъективное ощущение «должно было заработать».

Практические задания



Вспомните (или, если ведёте конспект на протяжении всего курса, найдите в записях) реальный случай из практики этого курса, когда вы столкнулись с какой-либо ошибкой или неожиданным поведением системы (например, при настройке SSH в Блоке 13, firewall в Блоке 14, или любой другой момент курса) — опишите этот случай в терминах семишагового алгоритма troubleshooting: как вы (осознанно или нет) прошли (или могли бы пройти) каждый из семи шагов.

Смоделируйте собственный, придуманный вами сценарий учебной проблемы (используя любой из инструментов, изученных в курсе — Docker, systemd-службы, файлы конфигурации), пройдите весь алгоритм самостоятельно от начала до конца, и оформите результат в виде документа по аналогии с шагом 9 практики.

Изучите (через поиск в интернете) термин «post-mortem» (или «post-incident review») в контексте IT-индустрии — как эта практика соотносится с седьмым шагом изученного алгоритма (документирование), и почему многие серьёзные технологические компании относятся к этому процессу как к обязательной, формализованной части своей операционной культуры, а не просто как к необязательной бюрократической формальности.



Проверка знаний

Вопрос 1. Почему на четвёртом шаге алгоритма troubleshooting (проверка гипотез) важно проверять их по одной, а не пытаться исправить сразу несколько потенциальных причин одновременно?

Ответ: Если внести несколько изменений одновременно и проблема после этого исчезнет, невозможно точно определить, какое именно из изменений реально решило проблему — это существенно осложняет понимание истинной первопричины, что критично важно для документирования (седьмой шаг) и предотвращения повторения проблемы в будущем. Кроме того, каждое «попутное» изменение, внесённое без должной проверки, несёт собственный риск создания новой, отдельной проблемы, которая может быть ошибочно связана (или, наоборот, не связана и потому упущена из виду) с исходной ситуацией, усложняя дальнейшую диагностику.

Вопрос 2. Почему седьмой шаг алгоритма (документирование) считается важной, а не второстепенной частью процесса troubleshooting, даже после того, как проблема уже практически решена?

Ответ: Документирование сохраняет знание о проблеме и её решении не только для собственной памяти в будущем (аналогичные проблемы имеют свойство повторяться, иногда спустя месяцы), но и делает это знание доступным другим людям — коллегам по команде, или тем, кто придёт работать с этой инфраструктурой позже. Без документации каждое повторное возникновение похожей проблемы потребует повторного прохождения всего диагностического процесса заново, «с нуля», тогда как наличие точной, конкретной документации о симптомах, причине и решении может свести повторную диагностику к быстрой проверке уже известного, задокументированного сценария.

Итоги урока

Вы изучили: семишаговый универсальный алгоритм troubleshooting (определить проблему, собрать информацию, сформулировать гипотезы, проверить их систематически, внести решение, верифицировать, задокументировать), дополнительные принципы эффективной диагностики (простейшее объяснение сначала, не полагаться на предположения, разделение сложной проблемы на части, сохранение возможности отката, умение вовремя обратиться за помощью).

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

В следующем блоке потребуется: весь диагностический инструментарий этого блока, а также накопленные знания курса о службах — Блок 19 познакомит вас с веб-серверами и базами данных, и весь материал этого блока (журналы, мониторинг, диагностика) будет непосредственно применяться при настройке, отладке и обеспечении надёжной работы этих новых, важных компонентов инфраструктуры.

Мини-проект блока

Задача: объединить материал всего блока в единый практический артефакт — продвинутый диагностический скрипт, а также полноценную симуляцию и документирование реалистичного инцидента с применением полного алгоритма troubleshooting.

Что нужно сделать:



Напишите комплексный диагностический скрипт ~/scripts/system_health_check.sh, применяя материал Блока 15 (функции, обработка ошибок) и всего этого блока. Скрипт должен включать функции для:





Общего обзора (load average с учётом nproc, использование памяти через free -h).

Топ-5 процессов по CPU и по памяти.

Проверки состояния дисков (df -h) с предупреждением, если занято больше 80% (по аналогии с материалом урока 15.4).

Проверки на наличие ошибок в journal за последний час (journalctl -p err --since "1 hour ago").

Проверки статуса ключевых служб (SSH, Docker, если установлен, и других значимых для вашей системы).

Вывода итогового структурированного отчёта в консоль и одновременного сохранения его в лог-файл с меткой времени.





Настройте регулярный автоматический запуск этого скрипта через crontab (материал урока 15.9) — например, каждые 30 минут, с накоплением истории отчётов.





Смоделируйте полноценный инцидент, комбинируя минимум два разных источника проблемы одновременно (например: остановленный Docker-контейнер И искусственная нагрузка на CPU через модифицированный cpu_load_demo.sh из урока 18.3) — специально усложнив диагностику по сравнению с более простыми примерами практики этого блока.





Проведите полную диагностику, строго следуя семишаговому алгоритму из урока 18.5, используя ваш собственный диагностический скрипт как часть процесса сбора информации (Шаг 2 алгоритма).





Составьте полноценный отчёт об инциденте (в формате Markdown, применяя материал Блока 16, если хотите дополнительно попрактиковаться и сохранить отчёт в Git-репозитории) — включающий все семь шагов алгоритма с конкретными деталями, командами и их результатами на каждом этапе.



Критерий готовности: у вас есть работающий, комплексный диагностический скрипт, запускаемый автоматически по расписанию, и полноценный, детальный отчёт о смоделированном многокомпонентном инциденте, демонстрирующий уверенное владение всем диагностическим алгоритмом и инструментарием этого блока.

Контрольные вопросы



В чём разница между традиционными текстовыми логами в /var/log/ и systemd journal, и зачем в современном Ubuntu присутствуют оба этих механизма одновременно?

Опишите назначение флагов -p, -u, -b, --since команды journalctl.

Зачем нужна ротация логов, и какой инструмент за неё отвечает в классических текстовых логах?

Объясните, почему интерпретация load average требует обязательного учёта количества ядер процессора.

Что означает высокое значение wa (iowait) в выводе top, и на диагностику какого именно ресурса это должно направить внимание администратора?

Опишите систематический процесс диагностики нагрузки «от общего к частному», перечислив основные его шаги.

В чём разница между ps aux --sort=-%cpu (мгновенный снимок) и pidstat (статистика во времени)?

Опишите ключевое архитектурное различие между моделью сбора данных Prometheus (pull) и более традиционным подходом (push), характерным для Zabbix.

Перечислите все семь шагов универсального алгоритма troubleshooting в правильном порядке.

Почему важно проверять гипотезы о причине проблемы по одной, а не пытаться исправить несколько потенциальных причин одновременно?



Выводы по блоку

Этот блок завершает формирование вашего диагностического мышления, начатое ещё в Блоках 10-11 при первом знакомстве со службами и процессами. Вы систематизировали и значительно углубили работу с журналами (traditional logs и systemd journal), освоили полный набор инструментов для анализа производительности системы в реальном времени (top/htop/vmstat/iostat/pidstat/lsof), познакомились с ландшафтом промышленных систем мониторинга (Netdata/Zabbix/Prometheus), и, что, возможно, наиболее ценно в долгосрочной перспективе — освоили универсальный, применимый далеко за пределами одного лишь Linux алгоритм troubleshooting, синтезирующий все технические навыки в целостную, профессиональную методологию решения проблем.

Важно понимать: технические инструменты меняются, новые версии программ и даже совершенно новые технологии появляются постоянно — но систематический, методичный подход к диагностике проблем, которому посвящён этот блок (и особенно его заключительный урок), остаётся неизменно ценным навыком на протяжении всей карьеры в этой области, значительно переживая любой конкретный набор используемых сегодня инструментов.

Материал этого блока будет непосредственно и активно применяться в оставшейся части курса: в Блоке 19 (веб-серверы и базы данных) вы будете использовать весь этот диагностический инструментарий для отладки новых, более сложных систем; в Блоке 20 (серверное администрирование) troubleshooting и мониторинг становятся неотъемлемой, повседневной частью работы с реальными производственными серверами; а в финальном практическом проекте Блока 21 продемонстрированное умение методично диагностировать и решать проблемы, вероятно, будет одним из ключевых, наиболее ценных для оценки навыков.

Список изученных тем



/var/log и journalctl: два параллельных подхода к журналированию, детальная структура ключевых файлов логов, углублённые флаги journalctl (по времени, приоритету, службе, PID/UID, загрузке системы), уровни важности сообщений, ротация логов через logrotate, ограничение размера journal.

Мониторинг в реальном времени: углублённая интерпретация top (load average с учётом ядер, детализация CPU и памяти), vmstat (сводная статистика, свопинг), iostat (детальная дисковая статистика по устройствам).

Поиск причин нагрузки: систематический шестишаговый процесс диагностики, pidstat (статистика процессов во времени), lsof (открытые файлы и порты), pgrep/pkill.

Обзор систем мониторинга: проблема, решаемая непрерывным мониторингом, ключевые характеристики Netdata, Zabbix, Prometheus+Grafana, архитектурные различия (push vs pull), практика установки и использования Netdata.

Алгоритм troubleshooting: семь шагов (определить, собрать информацию, гипотезы, проверка, решение, верификация, документирование), дополнительные принципы (простейшее объяснение, проверка предположений, разделение проблемы, сохранение возможности отката, умение обратиться за помощью).



Рекомендации перед переходом

Убедитесь, что вы умеете:



Гибко фильтровать журналы через journalctl по времени, приоритету и источнику для быстрого нахождения релевантной информации.

Правильно интерпретировать ключевые метрики системы (load average, CPU, память, диск) без распространённых заблуждений, разобранных в этом блоке.

Систематически, методично диагностировать причину проблемы, применяя универсальный алгоритм, вместо хаотичных попыток наугад.



В Блоке 19 мы применим весь накопленный курсом инструментарий — от базовых команд первых блоков до диагностических техник этого блока — к настройке и эксплуатации двух важнейших компонентов практически любой современной веб-инфраструктуры: веб-сервера (Nginx) и базы данных (PostgreSQL/MySQL), связав их в единую работающую систему.





      
        ← Предыдущий блокБлок 17. Виртуализация и контейнеры
        Следующий блок →Блок 19. Веб-сервер и базы данных