Это перевод оригинальной статьи “I Have a 10GB CSV File and Only 512MB RAM” — The Interview Question That Stumped Me.

И как отчаянное упоминание Кафки спасло мой ответ (в некотором роде).

Я проходил собеседование на позицию Java-разработчика. Всё шло хорошо — я ответил на вопросы по Spring Boot, микросервисам и даже решил несколько задач в стиле LeetCode.

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

«Представьте, что у вас есть очень большой файл — допустим, CSV размером 10 ГБ. При этом вычислительные ресурсы сильно ограничены — например, всего 512 МБ оперативной памяти и одно ядро процессора. Как бы вы обработали этот файл, чтобы выполнить предварительную обработку данных и сохранить их в другом формате?»

Я замер. Мысли в голове сменяли друг друга.

«Просто читать файл построчно?» — слишком очевидно, вероятно, неправильно.
«Использовать многопоточность?» — но ресурсы ограничены.
«Загрузить в базу данных?» — но тогда базе данных также потребуется память.

Я понимал, что нужно сказать что-то действительно разумное.

Мой первый ответ (спойлер: он был не самым удачным)

Я попросил уточнить: «Какие именно данные? Они структурированы?»

Интервьюер: «Это CSV-файл — строки и столбцы. Вам нужно его очистить, преобразовать некоторые столбцы и сохранить в формате JSON или Parquet».

После нескольких секунд раздумий я ответил:

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

Интервьюер медленно кивнул, но по выражению его лица было ясно: «Это всё ещё слишком наивно».

Он возразил: «Даже чтение 10 000 строк за раз может оказаться слишком затратным, если каждая строка большая. И что насчёт отказоустойчивости? Что будет, если процесс завершится с ошибкой посередине? Как вы продолжите обработку?»

Я зашёл в тупик. Я понимал, что мой ответ неполный.

Тогда, почти от отчаяния, я сказал:

«Я не уверен на сто процентов в деталях реализации на низком уровне, но знаю, что подобные задачи обычно решаются с помощью фреймворков потоковой обработки данных, таких как Apache Kafka или Apache Flink. Они из коробки обеспечивают exactly-once семантику, разбиение данных на партиции и отказоустойчивость».

Брови интервьюера слегка приподнялись. Он не сказал, что я не прав. Но и не сказал, что я прав.

Я вышел с собеседования с ощущением, что смог выкрутиться, но так и не дал настоящего ответа.

Что я узнал после собеседования

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

Идеальное решение — это не Kafka или Flink, поскольку они избыточны для обработки одного файла на одной машине. Настоящее решение гораздо проще и элегантнее.

Вот что мне следовало ответить.

Идеальное решение: потоковая обработка + разбивка на фрагменты + отслеживание смещения

Шаг 1: Никогда не загружайте весь файл в память

Используйте потоковое чтение CSV, обрабатывая файл по одной строке за раз.

В Java для этого подходят библиотеки OpenCSV или Super CSV. Для простых случаев достаточно даже обычного BufferedReader вместе с String.split(",").

List<String> batch = new ArrayList<>(5000);
while ((line = reader.readLine()) != null) {
 batch.add(line);
 if (batch.size() == 5000) {
 processBatch(batch);
 batch.clear(); // free memory
 }
}

Такой подход практически не расходует память — требуется лишь столько памяти, сколько занимает одна строка.

Шаг 2: Если пакетная обработка необходима (для повышения производительности), используйте её разумно

Если разбор CSV сам по себе ресурсоемкий (например, включает сложную валидацию), можно обрабатывать данные пакетами по 1000–5000 строк.

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

List<String> batch = new ArrayList<>(5000);
while ((line = reader.readLine()) != null) {
    batch.add(line);
    if (batch.size() == 5000) {
        processBatch(batch);
        batch.clear(); // free memory
    }
}

Шаг 3: Отслеживайте прогресс для обеспечения отказоустойчивости

Если процесс завершится с ошибкой, не стоит начинать обработку заново. Сохраняйте номер последней обработанной строки или смещение в байтах.

Можно использовать небольшой checkpoint-файл:

offset = 1048576   # bytes processed so far

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

В Java для перехода к нужной позиции можно использовать RandomAccessFile.

RandomAccessFile raf = new RandomAccessFile("large.csv", "r");
raf.seek(lastKnownOffset);   // resume from here

Шаг 4: Используйте модель producer-consumer (необязательно)

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

• Поток 1 (Producer) — считывает строки из файла и помещает их в небольшую очередь.
• Поток 2 (Consumer) — извлекает строки из очереди и обрабатывает их.

Так диск продолжает читать данные, пока процессор занимается обработкой. Но при очень ограниченных ресурсах даже это может быть избыточным.

Подождите — а может быть, Kafka или Flink — это и есть правильный ответ?

Да, но только если задача распределенная.

Если под «ограниченными вычислительными ресурсами» подразумевается одна небольшая машина, Kafka и Flink — не лучший выбор. Они лишь добавят дополнительные накладные расходы.

Однако если файл хранится в распределенной файловой системе (например, HDFS), а обработка выполняется на кластере из нескольких узлов, тогда Kafka вместе с Flink (или Spark Streaming) становятся вполне оправданным решением. Они разбивают данные на партиции, обрабатывают их параллельно и обеспечивают exactly-once семантику.

Возможно, интервьюер хотел услышать не названия конкретных инструментов, а понимание самой концепции потоковой обработки.

Моя ошибка заключалась в том, что я упомянул инструменты, не объяснив принципы их работы:

• Разбиение данных на партиции
• Контрольные точки
• Семантика exactly-once

Правильный ответ в одном предложении

Если бы я мог вернуться в прошлое, я бы сказал:

«Я использовал бы потоковый CSV-ридер для построчной обработки файла, при необходимости обрабатывая данные небольшими пакетами по несколько тысяч строк, чтобы не перегружать память. Кроме того, я реализовал бы механизм checkpointing, периодически сохраняя смещение в байтах, чтобы в случае сбоя можно было продолжить обработку с последнего сохраненного места, а не начинать всё сначала».

А если бы интервьюер спросил о распределенных системах:

«Если файл распределен между несколькими машинами, я использовал бы фреймворк потоковой обработки данных, например Kafka вместе с Flink, чтобы разбить данные на партиции, обрабатывать каждую партицию независимо и использовать checkpointing для обеспечения отказоустойчивости».

Чему это меня научило

• Не стоит сразу переходить к использованию крупных фреймворков, не разобравшись в сути проблемы.
• Всегда уточняйте масштаб — это разовая задача на одной машине или непрерывный конвейер в кластере?
• Отказоустойчивость и возможность продолжить обработку после сбоя зачастую важнее максимальной скорости.
• Даже неправильный ответ может быть ценным — он подтолкнул меня к изучению правильного.

Это перевод оригинальной статьи Linux Logs.

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

Традиционные логи хранятся в /var/log/

Типы логов Linux

1. Логи ядра: генерируются ядром Linux.
2. Системные логи: управляются службами логирования, такими как rsyslog, systemd-journald.
3. Логи приложений: программы создают собственные логи. Примеры: Apache (/var/log/httpd/), Nginx (/var/log/nginx/), MySQL (/var/log/mysql/)

ls /var/log #shows all existing logs

Важность логов в Linux

Логи крайне важны для:

1. Устранения ошибок
2. Расследования в вопросах безопасности
3. Мониторинга производительности
4. Отладки служб
5. Аудита изменений системы

Как работает логирование в Linux

Происходит событие → приложение/ядро генерирует сообщение лога → сообщение отправляется в интерфейс логирования → systemd-journald получает сообщение → лог записывается в файл (/var/log…) → logrotate управляет размером и хранением

Расположение логов

/var/log — это важнейший каталог для хранения логов. Он содержит записи о системной активности, события безопасности, сообщения ядра и информацию об операциях с пакетами.

Системные файлы логов: эти логи содержат общую информацию о системной активности в файле /var/log/messages.

Логи аутентификации: критически важны для мониторинга безопасности в файле /var/log/secure.

Логи ядра: события, связанные с ядром, такие как обнаружение оборудования при загрузке, проблемы драйверов, ошибки памяти, проблемы с дисками, находятся в /var/log/kern.log

Логи загрузки: показывают, что происходит во время запуска системы, /var/log/boot.log

Логи управления пакетами: отслеживают установку, удаление и обновления в файле /var/log/dnf.log

cat /var/log/message #shows general system activity
cat /var/log/dnf.log #shows installation history
cat /var/log/secure #shows authentication activity

syslog и rsyslog

syslog — это стандарт для логирования сообщений в системах Unix/Linux. Он определяет, как приложения, сервисы и ядро ​​могут отправлять сообщения в центральный лог. Он не определяет, как сообщения хранятся, а только как они форматируются и передаются.

Каждое сообщение syslog состоит из двух компонентов: FACILITY.SEVERITY.

FACILITY (Источник логов): FACILITY определяет, откуда поступило сообщение.

Распространённые источники:

Priority (уровни важности): показывает, насколько серьёзным является событие.

От наивысшего к наименьшему:

rsyslog — это современная замена традиционному syslog, вносящая улучшения в реализацию протокола syslog. Это демон логирования (сервис), отвечающий за сбор логов, фильтрацию логов и запись логов в файлы. /etc/rsyslog.conf или /etc/rsyslog.d. Rsyslog использует правило facility.priority action

systemd Journal (journald) в Linux

systemd-journald — это сервис логирования по умолчанию, заменяющий многие традиционные конфигурации, использующие только syslog, что делает её незаменимой для устранения неполадок и мониторинга.

systemd-journald предоставляет структурированные логи с метаданными (временная метка, PID, сервис, приоритет)

journalctl — это команда для запроса логов journald. Она фильтрует логи по сервисам, времени, уровню важности и т.д. для удобства эффективной обработки.

Journald может хранить логи двумя способами:

а. Временные (по умолчанию в некоторых системах): логи хранятся в оперативной памяти и теряются при перезагрузке, доступ к ним осуществляется через /run/log/journal/

b. Постоянные: логи хранятся на диске и сохраняются после перезагрузки, использование /var/log/journal позволяет хранить логи между перезагрузками, но требует создания указанной директории.

Ротация логов — критически важная часть работы с логами, поскольку без неё логи могут заполнять дисковое пространство и замедлять системные процессы.

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

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

cat /etc/logrotate.conf #shows log rotation settings that can be modified

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

Это перевод оригинальной статьи Migrating a Docker container between two Linux hosts.

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

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

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

Список всех контейнеров

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

docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}"

Это даёт компактное представление, с которым проще работать, чем с необработанным выводом JSON. Здесь важно не просто получить список контейнеров, а сформировать минимальную инвентаризацию. Имена показывают, как адресуются сервисы, образы показывают, откуда они получены, статус даёт представление об ожидаемом рабочем состоянии, а порты показывают, как они подключены к сети.

Тома

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

docker inspect <container> | grep -A 20 "Mounts"

для получения общей картины используйте:

docker ps -a --format "table {{.Names}}\t{{.Mounts}}"
docker volume ls

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

Типичный результат проверки наглядно показывает эту разницу:

"Mounts": [
 {
 "Type": "bind",
 "Source": "/opt/data/homeassistant",
 "Destination": "/config"
 },
 {
 "Type": "volume",
 "Name": "influxdb-data",
 "Destination": "/var/lib/influxdb2"
 }
]

На этом этапе полезно привести способ хранения данных к единому виду. Преобразование именованных томов в bind mount превращает миграцию в обычную задачу по переносу файлов, а не в Docker-специфичную операцию.. Это не является обязательным, но обычно значительно упрощает всё, что будет дальше.

Воспроизводимые и пользовательские образы

Образы создают проблему другого рода. Некоторые образы воспроизводимы по своей природе, другие — нет. Получить их список просто:

docker images
docker inspect <container> | grep -E "Image"

Осторожность требуется именно при интерпретации результатов. Образы из публичных реестров, например postgres, nginx или redis, а также образы, поддерживаемые известными организациями, можно повторно загрузить на целевой хост с минимальными усилиями. Их версии следует зафиксировать, но переносить их вручную нет необходимости.

Пользовательские образы требуют большего внимания, потому что если образ не соответствует шаблону repository/name или был создан локальной сборкой либо с помощью docker commit, он содержит состояние, которое невозможно восстановить где-либо ещё. Такие образы необходимо явно экспортировать. Если вы не уверены, каким образом был создан образ, часто имеет смысл перед переносом пересобрать его из Dockerfile, даже если это потребует дополнительных усилий в краткосрочной перспективе.

Обычно я создаю таблицу в Markdown, которая включает имена контейнеров, типы томов, пути монтирования, классификацию образов, версии, порты, переменные окружения и все неявные зависимости, например предположения об использовании фиксированных IP-адресов.

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

Преобразование именованных томов в bind mount

Если именованные тома преобразованы в bind mount, процесс становится понятнее. Рассмотрим контейнер базы данных, данные которого находятся в каталоге томов Docker. Перенос включает остановку стека, копирование данных в каталог проекта, обновление compose.yaml так, чтобы он ссылался на относительный путь, и повторный запуск сервиса:

docker compose down
cp -RT /var/lib/docker/volumes/patchmon_postgres_data/_data /docker/stacks/patchmon/postgres-data
docker compose up -d

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

Перенос томов между хостами

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

docker compose down
tar czf migration-data-stirling-pdf$(date +%Y%m%d).tar.gz stirling-pdf
scp migration-data-*.tar.gz user@new-host:/tmp/

На целевой системе распакуйте архив в заранее подготовленную структуру каталогов:

mkdir -p /opt/stacks/
tar xzf migration-data-stirling-pdf20251117.tar.gz -C /opt/stacks/

Иногда возникает соблазн временно включить SSH-доступ для пользователя root ради удобства. Если вы решите так сделать, сразу после завершения передачи данных верните настройки обратно. Если оставить его включённым, это создаст риск, который никак не связан с самим переносом, но его легко не заметить.

Перенос образов (Pull или Export)

Перенос образов достаточно прост. Сначала повторно загрузите стандартные образы:

docker compose pull

Экспортируйте и загрузите пользовательские образы:

docker save -o utcar-utcar.tar utcar-utcar:latest
scp utcar-utcar.tar user@new-host:/tmp/
docker load -i utcar-utcar.tar

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

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

docker compose pull
docker compose up -d
docker compose logs -f

Действительно ли работает?

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

docker compose ps
docker compose logs <service>
docker compose exec <service> ls -la <mount>

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

Это перевод оригинальной статьи 10 Things I Check First When a Linux Server Becomes Slow.

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

Самое неприятное — не медленный сервер. Самое неприятное — не знать, куда смотреть в первую очередь.

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

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

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

Вот десять первых вещей, которые я проверяю, когда Linux-сервер начинает тормозить.

1. Проверьте загрузку процессора

Первое, что я проверяю, — это загрузка CPU. Если процессор перегружен, всё на сервере начинает работать медленно.

Обычно я запускаю:

top

или

htop

Эти команды быстро показывают, какой процесс использует больше всего CPU.

Иногда проблема заключается в зависшем процессе. Иногда это скрипт, работающий в цикле. Иногда задача резервного копирования запускается не в то время.

Как только вы определите процесс, вы сможете решить, остановить его, перезапустить или продолжить расследование.

2. Проверьте использование памяти

Недостаток памяти может очень быстро замедлить работу сервера.

Для проверки использования памяти я выполняю следующую команду:

free -m

Если в системе заканчивается оперативная память, Linux начинает использовать swap. swap работает гораздо медленнее, чем оперативная память. Когда это происходит, система начинает работать медленно.

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

3. Проверьте свободное место на диске

Заполненный диск может вызвать множество странных проблем.

Я проверяю использование дискового пространства с помощью:

df -h

Если какой-либо раздел заполнен почти на 100 процентов, приложения могут начать работать со сбоями или медленно.

Часто причиной являются логи. Иногда старые резервные копии заполняют диск, и никто этого не замечает.

Удаление неиспользуемых файлов может сразу улучшить производительность.

4. Проверьте активность дискового ввода-вывода

Иногда диск не заполнен, но при этом всё равно сильно загружен.

Чтобы проверить дисковую активность, я использую:

iostat

или

iotop

Эти инструменты показывают, какие процессы интенсивно читают или записывают данные на диск.

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

Когда узким местом становится дисковый ввод-вывод, даже простые команды могут выполняться медленно.

5. Проверьте Load Average

Показатель средней загрузки сервера позволяет понять насколько загружен сервер.

Его можно посмотреть с помощью:

uptime

или

top

Если Load Average значительно выше количества ядер CPU, значит система испытывает высокую нагрузку.

Обычно это означает, что процессы ожидают доступа к ресурсам ЦП, диска или другим ресурсам.

6. Проверьте запущенные процессы

Иногда всю проблему создает один-единственный процесс.

Я проверяю запущенные процессы с помощью:

ps aux

или сортирую процессы в top.

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

Такое часто происходит из-за ошибок приложений или неправильно настроенных скриптов.

7. Проверьте сетевые проблемы

Медленная работа сервера не всегда является проблемой самого сервера. Иногда это проблема сети.

Я проверяю сетевое подключение с помощью:

ping

и

ss -tulnp

Если сетевые соединения перегружены или зависли, приложения могут казаться медленными, даже если сам сервер работает нормально.

8. Проверьте последние логи

Логи часто рассказывают настоящую историю.

Обычно я проверяю системные логи с помощью:

journalctl -xe

или просматриваю файлы логов в каталоге /var/log.

Ошибки, связанные с сервисами, дисками или памятью, часто появляются именно здесь.

Очень часто ответ уже написан в логах. Нужно лишь посмотреть.

9. Проверьте сервисы и приложения.

Иногда с операционной системой всё в порядке, но проблемы испытывает приложение.

Например, веб-сервер, база данных или фоновый процесс могут быть перегружены.

Я проверяю состояние сервиса с помощью:

systemctl status

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

Но всегда важно понимать, почему это вообще произошло.

10. Проверьте последние изменения

Этот шаг часто игнорируют, но он очень важен.

Задайте себе простой вопрос.

Что изменилось недавно?

Возможно, произошло новое развертывание. Возможно, была добавлена задача cron. Возможно, была изменена конфигурация.

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

В заключение

Медленный сервер может очень быстро вызвать раздражение. Пользователи недовольны. Команды начинают задавать вопросы. Напряжение быстро нарастает.

Но большинство проблем с производительностью развиваются по одному и тому же сценарию.

ЦП, память, диск, процессы, сеть или последние изменения.

Вместо того чтобы наугад перебирать разные команды, следование четкому контрольному списку значительно упрощает поиск и устранение неисправностей.

За эти годы этот простой ритуал сэкономил мне много часов и избавил от множества стрессовых утренних часов.

И в конечном итоге каждый системный администратор усваивает один и тот же урок.

Когда Linux-сервер начинает работать медленно, причина обычно кроется на виду. Нужно просто сначала поискать в нужных местах.

Это перевод оригинальной статьи Your sudo Is Not Safe — Here’s Where It All Goes Wrong.

Руководство для системных администраторов по пониманию внутреннего устройства sudo, распространённых ошибок конфигурации и методов усиления безопасности.

Вы думаете, что ваша система защищена, потому что никто не использует root, а все работают только через sudo. Подумайте ещё раз!

Злоумышленникам не нужно взламывать sudo, чтобы получить доступ к root. Использовать sudo безопаснее, чем работать напрямую под root, но неправильная конфигурация всё равно может предоставить злоумышленникам те же самые возможности.

Большинство пользователей Linux воспринимают sudo как «слово, которое мы ставим перед командой, когда нам нужны права root». Но за кулисами sudo — это нечто большее. Понимание того, как работает sudo, помогает разобраться, как Linux контролирует выполнение привилегированных действий и как сохранить этот контроль безопасным.

В этой статье мы разберём, как sudo работает на самом деле, где он может стать небезопасным и как исправить распространённые ошибки конфигурации.

Что такое sudo?

sudo (Subuser Do) — это команда, которая позволяет обычному пользователю выполнять определённые команды с повышенными привилегиями (обычно от имени суперпользователя/root), не входя в систему под пользователем root.

sudo выполняет четыре действия в указанном порядке:

1. Аутентификация — подтверждает, кто мы есть.
2. Авторизация — проверяет, разрешено ли нам выполнять эту команду.
3. Повышение привилегий — запускает команду с временными правами администратора.
4. Аудит — записывает, что мы сделали (логи).

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

Аутентификация PAM

Первое, что делает команда sudo, — это проверяет, кто мы. Она задает простой вопрос:

«Действительно ли этот пользователь является тем, за кого себя выдаёт?»

Для решения этой задачи sudo использует PAM, что расшифровывается как Pluggable Authentication Modules.

Что такое PAM?

PAM — это система Linux, которая отвечает за аутентификацию. В зависимости от того, как настроена система, PAM может требовать:

• Наш пароль (не пароль root)
• Действительную учётную запись
• Доступ только в определённое время
• Многофакторную аутентификацию (OTP или аппаратный ключ)
• Корпоративные системы входа, такие как LDAP, Active Directory или Kerberos.

Файл конфигурации PAM

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

/etc/pam.d/

Для sudo используется файл:

/etc/pam.d/sudo

Этот файл сообщает PAM, какие проверки необходимо выполнить, когда кто-то использует sudo. Можно представить его как контрольный список, которому следует PAM, когда sudo спрашивает: «Можешь подтвердить этого пользователя?»

# Example /etc/pam.d/sudo file
#%PAM-1.0
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    include      system-auth

# Allow users in the "wheel" group to execute sudo without a password
# auth       sufficient   pam_wheel.so trust group=wheel

• auth include system-auth — указывает PAM использовать правила аутентификации, определённые в /etc/pam.d/system-auth, для проверки пароля пользователя.
• account include system-auth — проверяет, является ли учётная запись пользователя действительной (например, не истёк ли срок её действия и не заблокирована ли она).
• password include system-auth — отвечает за смену пароля при необходимости (обычно sudo напрямую этот механизм не использует)
• session include system-auth — управляет созданием и завершением сеанса, например записью в логи момента начала и окончания сеанса.
• pam_wheel.so (опционально) — если не закомментировано, позволяет участникам определённой группы (например, wheel) выполнять sudo без ввода пароля.

Поведение аутентификации можно изменить, отредактировав файл конфигурации PAM, не изменяя сам sudo.

Авторизация через sudoers

PAM подтверждает, кто мы, но не принимает решение о том, что нам разрешено делать.

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

Политика Sudoers

Политика sudoers — это набор правил, который определяет, кому разрешено выполнять какие команды с повышенными привилегиями. Эти правила хранятся в:

/etc/sudoers      # main sudoers configuration
/etc/sudoers.d/   # extra rule files

Эти файлы определяют:

• Какие пользователи или группы могут использовать sudo
• Какие команды они могут выполнять
• От имени какого пользователя они могут выполнять команды (root или другой учётной записи)
• Требуется ли ввод пароля?
• Особые ограничения или лимиты

# Example of sudoers policy
# Allow a user full sudo access
alice ALL=(ALL) ALL 

# Allow a user to run only one command
bob ALL=(root) /usr/bin/systemctl restart nginx 

# Allow a group sudo access
%devops ALL=(ALL) ALL 

# No password required
carol ALL=(root) NOPASSWD: /usr/bin/docker ps

Логирование для обеспечения безопасности и расследования инцидентов

По умолчанию sudo записывает информацию в системный сервис логирования, что делает его безопаснее и удобнее для отслеживания действий, чем использование su или прямой вход под пользователем root. По умолчанию sudo записывает в логи:

• Кто выполнил sudo
• С какого терминала (TTY)
• Рабочий каталог пользователя
• Целевого пользователя
• Точную команду
• успешное или неуспешное выполнение
• временную метку.

# Log example
Feb 12 10:15:22 server1 sudo:  alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/apt update

• alice — пользователь, запустивший команду sudo
• TTY=pts/0 — используемый терминал
• PWD=/home/alice — каталог, в котором была выполнена команда
• USER=root — команда была выполнена от имени root
• COMMAND=… — точная команда, которая была выполнена

Эти логи хранятся в системных файлах логов, например:

/var/log/auth.log    # Debian/Ubuntu
/var/log/secure      # RHEL/CentOS
journalctl -u sudo   # systemd

Почему логирование важно

Логирование создаёт чёткую историю административных действий. Когда sudo записывает команды в логи, мы можем точно увидеть, что было сделано и кем. Это помогает:

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

Расширенное логирование sudo: запись сеанса

По умолчанию sudo записывает в логи только информацию о том, какая команда была выполнена. Но он не записывает всё, что происходило во время выполнения этой команды.

Параметры log_input и log_output позволяют записывать весь сеанс sudo. Это означает, что мы можем увидеть:

• что вводил пользователь
• что система выводила в ответ
• работу интерактивных команд
• пошаговую терминальную активность

Это позволяет впоследствии воспроизвести весь сеанс для проведения аудитов и расследования инцидентов.

Defaults log_input, log_output # In sudoers
# or
user ALL = (ALL) LOG_INPUT: LOG_OUTPUT: /bin/bash # per command

Ошибки при использовании sudo, которые приводят к риску

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

1. Предоставление полного доступа через sudo слишком большому числу пользователей

%developers ALL=(ALL) ALL

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

2. Разрешение на выполнение всех команд, когда нужна только одна

bob ALL=(ALL) ALL

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

3. Слишком широкое использование подстановочных символов

alice ALL=(root) /usr/bin/systemctl *

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

# It opens a text editor (like vim or nano) to modify service files
sudo systemctl edit any-service.service        

# Run service that executes a reverse shell or adds a new admin user
sudo systemctl enable /home/alice/hack.service 
sudo systemctl start hack    

4. Использование NOPASSWD без серьёзной причины

carol ALL=(root) NOPASSWD: ALL

Такая настройка полностью убирает запрос пароля. Это удобно, но опасно. Если учётная запись будет скомпрометирована, злоумышленник мгновенно получит права root.

Не используйте NOPASSWD для полного доступа через sudo.
Используйте NOPASSWD только для строго ограниченного набора команд, которые пользователь должен выполнять без ввода пароля.

carol ALL=(root) NOPASSWD: /usr/bin/systemctl restart apache2

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

Defaults timestamp_timeout=1

5. Разрешение запуска опасных программ с помощью sudo

Некоторые программы могут выйти в shell:

• редакторы (vim, nano)
• пейджеры (less, more)
• Инструменты для написания скриптов (Python, Perl, Bash)

bob ALL=(root) /usr/bin/vim

Из Vim пользователь может выполнить :!bash и получить root shell.

6. Отсутствие проверки логов sudo

Логирование sudo полезно только в том случае, если логи регулярно анализируются. Игнорирование логов означает пропущенные предупреждающие сигналы и задержку реагирования на инциденты.

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

7. Редактирование /etc/sudoers напрямую

Всегда используйте команду visudo для редактирования /etc/sudoers, так как она проверяет синтаксис перед сохранением. Поврежденный файл sudoers может заблокировать административный доступ.

visudo

8. Аутентификация PAM является слабой

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

Как обеспечить надежную аутентификацию и дополнительные меры защиты:

• Используйте надежные пароли (с помощью pam_pwquality)
• Блокируйте учетные записи после неудачных попыток входа (с помощью pam_faillock)
• Используйте более надежное хеширование (SHA-512 или yescrypt)
• Включите дополнительные проверки PAM, такие как многофакторная аутентификация (MFA) / одноразовый пароль (OTP) для дополнительного фактора аутентификации, аппаратные ключи безопасности (например, YubiKey), ограничения времени входа или ограничения сессий.

9. Дополнительные модули PAM

В конфигурации PAM каждое правило имеет управляющий флаг, например:

required
requisite
sufficient
optional

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

10. Неправильный порядок PAM

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

• Базовая проверка пароля пройдена успешно
• Проверка MFA выполняется слишком поздно
• Доступ предоставляется до того, как MFA будет проверена

11. Логи хранятся только локально

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

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

Отправляйте логи sudo на другой сервер в реальном времени (сервер syslog, SIEM или сборщик логов). Даже если локальная машина будет скомпрометирована, логи уже будут надежно сохранены в другом месте.

Заключительные мысли

sudo безопаснее, чем использовать учетную запись root напрямую, но это не гарантирует полной безопасности. Безопасность зависит от трех факторов:

• Надежная аутентификация PAM
• Строгие правила для sudoers
• Корректное логирование

Когда эти элементы работают вместе, sudo становится мощным механизмом обеспечения безопасности. Когда они настроены слишком свободно или игнорируются, они становятся скрытым риском.

В этой статье мы рассмотрели, как sudo создает уровень защиты с помощью PAM, правил sudoers и аудита логов. Мы также рассмотрели распространенные ошибки, которые могут ослабить эту защиту.

Спасибо за чтение! Надеюсь, эта статья поможет лучше понять, как работает sudo и как правильно обеспечить его безопасность. Учитесь, делитесь, вносите свой вклад!

Это перевод оригинальной статьи Kubernetes Networking: A Deep Dive.

Введение:

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

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

Kubernetes обеспечивает выполнение трёх базовых принципов сетевого взаимодействия, которые являются основой всего остального:

• Взаимодействие Pod-to-Pod: каждый под может напрямую взаимодействовать с любым другим подом на любых узлах — без NAT.
• Взаимодействие Node-to-Pod: узлы могут обращаться к любому поду, а поды могут обращаться к узлам — также без NAT.
• Согласованность IP-адреса Pod: собственный IP-адрес пода совпадает с тем IP-адресом, который другие подмы видят извне — без трансляции IP-адресов.

Это создаёт плоскую маршрутизируемую сеть уровня L3, в которой каждый под является полноценным сетевым объектом. Приложения взаимодействуют с использованием обычных IP-адресов — без необходимости трансляции портов. Это значительно упрощает взаимодействие микросервисов и позволяет применять сетевые политики на уровне подов.

Пять типов сетевого взаимодействия Kubernetes

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

Взаимодействие между контейнерами

Контейнеры, находящиеся внутри пода, имеют одну общую особенность. Все они используют одно и то же сетевое пространство имён. Это означает, что все контейнеры внутри пода видят одинаковые сетевые интерфейсы, и все они используют один и тот же IP-адрес. Они также совместно используют пространство портов. Когда контейнерам внутри пода необходимо взаимодействовать друг с другом, сделать это очень просто. Контейнеры внутри пода могут использовать localhost для взаимодействия друг с другом.

• Общее сетевое пространство имён: контейнеры внутри пода используют один IP-адрес и взаимодействуют через localhost.
• Общие тома: контейнеры обмениваются данными, читая и записывая данные в общее хранилище
• Межпроцессное взаимодействие: контейнеры используют такие механизмы, как общая память и семафоры, для взаимодействия друг с другом.

Как работает общее пространство имен:

Каждый под получает специальный pause-контейнер (также называемый sandbox или infra container), единственная задача которого — удерживать сетевое пространство имён. Все контейнеры приложения присоединяются к этому пространству имён с помощью функции Linux setns(). Такая архитектура означает, что контейнеры могут перезапускаться независимо друг от друга без потери общей сетевой идентичности.

Сетевые интерфейсы внутри пода:

• lo. Интерфейс обратной связи: это виртуальный интерфейс. Он помогает контейнерам взаимодействовать друг с другом на компьютере, используя адрес 127.0.0.1. Он есть в каждой сетевой подсистеме Linux. Всё, что использует этот интерфейс, доступно только внутри пода.
• eth0. Интерфейс пода: сетевой интерфейс пода. Он получает IP-адрес, например 10.244.1.5. Он обрабатывает весь входящий и исходящий трафик пода, включая обращения к сервисам, доступ к веб-сайтам и выход в интернет.
• VETH_P. VETH на стороне пода: это один конец виртуального Ethernet-кабеля. Он находится внутри пода. Когда трафик покидает под, он проходит через eth0. Этот интерфейс подключён к интерфейсу veth.
• VETH_H. VETH на стороне хоста: это другой конец виртуального Ethernet-кабеля. Он находится на узле, где работает под. Он помогает передавать трафик подов в CNI-плагин, например в мост cni0. Он также помогает выполнять маршрутизацию на узле.

ПРИМЕЧАНИЕ: Интерфейс loopback делает взаимодействие внутри пода чрезвычайно быстрым — трафик никогда не покидает ядро. Интерфейс eth0 обрабатывает всё остальное. Два контейнера внутри одного пода не могут использовать один и тот же номер порта, поскольку они совместно используют пространство портов.

Взаимодействие Pod-to-Pod

Каждый Kubernetes под получает свой специальный адрес в сети, поэтому поды могут напрямую взаимодействовать друг с другом. Это означает, что поды Kubernetes не должны использовать Network Address Translation.

Модель IP-адреса для каждого пода упрощает работу с сетью. Она помогает Kubernetes подам находить и взаимодействовать с другими Kubernetes подами в кластере.

Трафик внутри одного узла и трафик между узлами:

Когда у вас есть два пода, которые находятся на одном узле, трафик остается в локальном мосте cni0. Это похоже на работу коммутатора уровня 2. Когда поды находятся на разных узлах, трафик должен пройти через базовую сеть. Для этого используется overlay-сеть CNI. Поды по-прежнему смогут взаимодействовать друг с другом, даже если они находятся на разных узлах, благодаря механизму CNI overlay.

kube-proxy — оркестратор трафика:

Kube-proxy работает на каждом узле как DaemonSet. Он следит за Kubernetes API server, чтобы видеть, есть ли какие-либо изменения в сервисах и Endpoint. Когда он обнаруживает изменение, он обновляет сетевые правила, чтобы трафик направлялся туда, куда необходимо. Kube-proxy выполняет свою работу тремя способами:

Взаимодействие Pod-to-Service

Поды эфемерны. Они выходят из строя, а затем постоянно запускаются заново. Их IP-адреса динамически меняются.

Это решается с помощью сервисов, где используется стабильный виртуальный IP (ClusterIP), который не изменяется, даже когда backend-поды появляются и исчезают.

Пошаговый сценарий:

• Под клиента, выполняющий поиск DNS для my-service, получает в ответ ClusterIP (10.96.0.10).
• Трафик направляется на ClusterIP (виртуальный IP-адрес — здесь ничего не прослушивается).
• Правила iptables/IPVS в kube-proxy перехватывают трафик и изменяют адрес назначения на реальный IP-адрес пода (DNAT).
• Пакеты беспрепятственно достигают бэкэнд-пода.
• Ответный трафик формируется с учетом отслеживания соединений (но клиент никогда не видит IP-адреса подов-бэкендов).

Сервисы Kubernetes:

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

Внешний доступ к сервису: Ingress-сеть

Трафик извне в кластер — это совсем другая история. В Kubernetes существует 4 основных пути, и Ingress предоставляет наиболее полный набор функций для HTTP/HTTPS.

Ingress и Gateway API: сравнение

Сообщество Kubernetes поддержало Gateway API как модель следующего поколения. API Ingress является функционально замороженным (но не устаревшим), а инновации теперь происходят исключительно в Gateway API.

Pod-to-External: Egress Networking

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

Распространенные сценарии использования Egress:

ПРИМЕЧАНИЕ: Контролируйте egress с помощью NetworkPolicies. По умолчанию весь egress разрешен. Используйте правила NetworkPolicy policyTypes: [Egress], чтобы ограничить исходящий трафик к определенным назначениям, реализуя zero-trust исходящую сетевую модель.

Сетевое взаимодействие контейнеров и плагины CNI

Kubernetes не предоставляет сетевое взаимодействие самостоятельно. Container Network Interface (CNI) — это стандартный API, который позволяет сетевым плагинам настраивать сетевые интерфейсы в контейнерах. Без плагина CNI поды не получают IP-адреса и не могут взаимодействовать.

Что делают CNI-плагины

• Создают сетевые пространства имен подов.
• Подключают пары veth между подом и хостом.
• Назначают уникальные IP-адреса подам.
• Настраивают таблицы маршрутизации, чтобы IP-адреса подов были доступны.
• Включают overlay networking для взаимодействия между узлами.
• Применяют правила NetworkPolicy в поддерживаемых CNI.

Выбор подходящего CNI:

DNS в Kubernetes

Kubernetes использует CoreDNS в качестве встроенного DNS-сервера (по умолчанию начиная с K8s 1.13). Каждый под получает предварительно настроенный /etc/resolv.conf для использования CoreDNS, что позволяет обнаруживать сервисы по имени.

Сетевые политики: обеспечение безопасности взаимодействия подов

По умолчанию всё взаимодействие pod-to-pod в Kubernetes полностью открыто. Любой под может обращаться к любому другому поду. Network Policies позволяют реализовать zero-trust сетевое взаимодействие, определяя точные правила межсетевого экрана на уровне подов.

ПРИМЕЧАНИЕ: Network Policies применяются CNI-плагином — а не самим Kubernetes. Если ваш CNI не поддерживает NetworkPolicy (например, стандартный Flannel), политики будут молча игнорироваться. Используйте Calico, Cilium или облачный CNI для применения правил.

Сквозной поток трафика Kubernetes

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

1. Разрешение DNS: myapp.com преобразуется во внешний публичный IP-адрес облачного балансировщика нагрузки через внешний DNS.
2. Облачный балансировщик нагрузки: публичный IP принадлежит облачному балансировщику нагрузки. Он перенаправляет трафик к подам Ingress Controller, используя проверки состояния (health probes), чтобы только работоспособные узлы получали трафик.
3. Контроллер Ingress: анализирует HTTP-запрос, сопоставляет hostname/path с правилами Ingress, а затем определяет целевой Kubernetes сервис. Также он выполняет завершение TLS.
4. Сервис (ClusterIP): трафик отправляется на виртуальный ClusterIP. Здесь не прослушивает ни один реальный процесс.
5. kube-proxy: правила iptables/IPVS выполняют DNAT, переписывая назначение на реальный IP пода и распределяя нагрузку между работоспособными репликами.
6. Обработка подом: Целевой под получает запрос, обрабатывает его и формирует ответ.
7. Обратный путь: Ответ проходит тот же путь в обратном направлении, а отслеживание соединений гарантирует корректное возвращение пакетов.

Заключительные мысли:

Освоение этих основ помогает не только при подготовке к сертификациям, таким как CKA и CKAD, но и создает прочную основу для проектирования масштабируемых, безопасных и готовых к промышленной эксплуатации cloud-native приложений.

Это перевод оригинальной статьи 13 Tiny Bash Scripts That Save Me Time Every Day.

Простые shell-скрипты, которые можно использовать каждый день и которые повысят производительность.

Вам не нужен Bash-скрипт на 500 строк.

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

Shell-скрипты не обязаны быть сложными. Простой скрипт на 10 строк, который избавляет нас от необходимости каждый день вводить одни и те же команды, может быть невероятно полезным. Он экономит время, уменьшает количество ошибок, сокращает объем повторяющейся работы и делает наши повседневные задачи проще и эффективнее.

В этой статье мы рассмотрим практические Bash-скрипты, которые короткие, простые для понимания и решают распространенные повседневные задачи.

#1. Создавайте резервную копию перед редактированием файлов

Одно из золотых правил системного администрирования — всегда создавать резервные копии перед редактированием важного файла. Независимо от того, редактируете ли вы /etc/nginx/nginx.conf, /etc/ssh/sshd_config или файл .env, наличие резервной копии позволяет быстро восстановить оригинал, если что-то пойдет не так.

Конечно, cp file.conf file.conf.bak работает идеально. Но вводить одну и ту же команду каждый раз при редактировании файла становится утомительно. Небольшой Bash-скрипт может сделать то же самое с помощью более короткой и простой команды.

#!/usr/bin/env bash
# bak - create a timestamped backup of a file
# Usage: bak <file> [file ...]

set -euo pipefail

if [[ $# -eq 0 ]]; then
    echo "Usage: bak <file> [file ...]" >&2
    exit 1
fi

TIMESTAMP=$(date +%Y%m%d-%H%M%S)

for file in "$@"; do
    if [[ ! -e "$file" ]]; then
        echo "bak: '$file' not found" >&2
        continue
    fi

    backup="${file}.${TIMESTAMP}.bak"

    cp -a -- "$file" "$backup"
    echo "Created backup: $backup"
done

#Usage:
bak /etc/nginx/nginx.conf
# Created backup: /etc/nginx/nginx.conf.20260618-143015.bak

bak ~/.bashrc ~/.vimrc    # Multiple input
# Created backup: /home/user/.bashrc.20260618-143027.bak
# Created backup: /home/user/.vimrc.20260618-143027.bak    

Вместо того чтобы дважды вводить длинные пути в команде cp file.conf file.conf.bak, этот скрипт автоматизирует процесс и добавляет точную временную метку, чтобы избежать перезаписи предыдущих резервных копий.

Примечание:
Чтобы использовать bak как команду, убедитесь, что скрипт находится в каталоге, который входит в PATH (например, ~/bin), сделайте его исполняемым с помощью chmod +x и перезагрузите конфигурацию shell (source ~/.bashrc).

#2. Создавайте каталог и сразу переходите в него

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

Мы всегда можем выполнить mkdir -p complex/path/to/project, затем cd complex/path/to/project, или объединить их в одну команду: mkdir -p complex/path/to/project && cd complex/path/to/project. Это работает идеально, но каждый раз вводить одну и ту же длинную команду — больше усилий, чем должно требоваться для такой распространенной задачи.

# Add to ~/.bashrc - not a standalone script, needs to be a function
mkcd() {
    if [ -z "$1" ]; then
        echo "Usage: mkcd <directory_path>"
        return 1
    fi

    mkdir -p "$1" && cd "$1"
}

# Usage:
mkcd my-project                
mkcd projects/rust/axum-demo  # Create nested directories if they don't already exist
mkcd "My New Project"         # Use quotes for directory names that contain spaces

Благодаря mkcd создание каталога и переход в него становится операцией в один шаг, что экономит несколько нажатий клавиш каждый раз, когда мы начинаем новый проект.

Примечание:
Отдельный Bash-скрипт не может изменить текущий рабочий каталог терминала, который его запускает. Любая команда cd внутри скрипта влияет только на сам скрипт, и после его завершения терминал остается в исходном каталоге. Именно поэтому здесь используется функция shell.

#3. Распаковывайте любой архив

Сжатые файлы бывают самых разных форматов, таких как .zip, .tar.gz, .tgz, .tar.bz2 и .tar.xz. Проблема в том, что для каждого формата существует своя команда распаковки, которую бывает трудно запомнить.

#!/usr/bin/env bash
# extract — universal archive extractor
# Usage: extract <file> [file ...]
set -euo pipefail

if [[ $# -eq 0 ]]; then
    echo "Usage: extract <archive> [archive ...]" >&2
    exit 1
fi

for file in "$@"; do
    if [[ ! -f "$file" ]]; then
        echo "extract: '$file' not found" >&2
        continue
    fi
    echo "Extracting: $file"
    case "$file" in
        *.tar.bz2|*.tbz2)  tar xjf "$file"     ;;
        *.tar.gz|*.tgz)    tar xzf "$file"     ;;
        *.tar.xz|*.txz)    tar xJf "$file"     ;;
        *.tar.zst)         tar --zstd -xf "$file" ;;
        *.tar)             tar xf "$file"      ;;
        *.bz2)             bunzip2 "$file"     ;;
        *.gz)              gunzip "$file"      ;;
        *.xz)              unxz "$file"        ;;
        *.zip)             unzip "$file"       ;;
        *.7z)              7z x "$file"        ;;
        *.rar)             unrar x "$file"     ;;
        *.Z)               uncompress "$file"  ;;
        *.deb)
            mkdir -p "${file%.deb}"
            dpkg-deb -xv "$file" "${file%.deb}"
            ;;
        *.rpm)
            mkdir -p "${file%.rpm}"
            cd "${file%.rpm}" && rpm2cpio "../$file" | cpio -idmv
            cd ..
            ;;
        *)
            echo "extract: unknown format — '$file'" >&2
            ;;
    esac
done

# Usage:
extract archive.tar.gz
extract file1.zip file2.tar.bz2 file3.7z   # multiple at once

Вместо того чтобы запоминать отдельную команду для каждого формата архива, нам достаточно запомнить только одну: extract <filename>. Скрипт автоматически определяет тип файла и запускает правильную команду распаковки. Он поддерживает практически все форматы архивов, с которыми мы сталкиваемся в повседневной работе.

Примечание:
Для некоторых форматов архивов требуются дополнительные утилиты. Например, для распаковки файлов .rar необходим unrar, а для распаковки .7z — p7zip (или p7zip-full в Debian/Ubuntu).

#4. Сжимайте файлы и каталоги удобным способом

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

#!/usr/bin/env bash
# compress — compress files or directories
# Usage: compress <target> [format]
# Formats: gz (default), bz2, xz, zip, zst
set -euo pipefail

TARGET="${1:-}"
FORMAT="${2:-gz}"
if [[ -z "$TARGET" ]]; then
    echo "Usage: compress <file-or-dir> [gz|bz2|xz|zip|zst]" >&2
    exit 1
fi
if [[ ! -e "$TARGET" ]]; then
    echo "compress: '$TARGET' not found" >&2
    exit 1
fi
# Strip trailing slash
TARGET="${TARGET%/}"
NAME=$(basename "$TARGET")
STAMP=$(date +"%Y%m%d_%H%M%S")
case "$FORMAT" in
    gz)
        OUTPUT="${NAME}_${STAMP}.tar.gz"
        tar czf "$OUTPUT" "$TARGET"
        ;;
    bz2)
        OUTPUT="${NAME}_${STAMP}.tar.bz2"
        tar cjf "$OUTPUT" "$TARGET"
        ;;
    xz)
        OUTPUT="${NAME}_${STAMP}.tar.xz"
        tar cJf "$OUTPUT" "$TARGET"
        ;;
    zst)
        OUTPUT="${NAME}_${STAMP}.tar.zst"
        tar --zstd -cf "$OUTPUT" "$TARGET"
        ;;
    zip)
        OUTPUT="${NAME}_${STAMP}.zip"
        zip -r "$OUTPUT" "$TARGET"
        ;;
    *)
        echo "compress: unknown format '$FORMAT'. Use: gz bz2 xz zst zip" >&2
        exit 1
        ;;
esac
SIZE=$(du -sh "$OUTPUT" | cut -f1)
echo "  Created: $OUTPUT ($SIZE)"

compress ./my-project              # → my-project_20240617_143022.tar.gz
compress ./logs bz2                # → logs_20240617_143022.tar.bz2
compress config.yml zip            # → config.yml_20240617_143022.zip

Этот скрипт позволяет сжимать файлы или каталоги в формате по умолчанию либо выбрать другой формат, указав его в качестве аргумента. Нам больше не нужно запоминать команды вроде tar -czf или zip -r.

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

#5. Быстрый поиск больших файлов

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

Один из самых быстрых способов понять, в чем проблема, — использовать find, чтобы определить, что именно занимает место в дереве каталогов. Но синтаксис этой команды не всегда легко запомнить.

#!/usr/bin/env bash
# findlarge — find the largest files under a path
# Usage: findlarge [directory] [min_size_MB] [count]
set -euo pipefail

DIR="${1:-.}"
MIN_MB="${2:-100}"
COUNT="${3:-20}"
echo "Finding files larger than ${MIN_MB}MB under ${DIR} ..."
echo ""
find "$DIR" -type f -size +"${MIN_MB}M" -printf '%s\t%p\n' 2>/dev/null \
    | sort -rn \
    | head -"$COUNT" \
    | awk '{
        size=$1
        path=$2
        if (size >= 1073741824)
            printf "  %7.2f GB  %s\n", size/1073741824, path
        else
            printf "  %7.2f MB  %s\n", size/1048576, path
    }'

# Usage: 
findlarge /var 50 10      # top 10 files >50MB under /var
findlarge /home 200       # default top 20, >200MB, under /home
findlarge                 # top 20 files >100MB in current directory

Этот скрипт позволяет легко находить большие файлы при очистке дискового пространства или поиске того, что занимает место на диске. Использование параметра -printf команды find выводит размеры файлов в байтах, что удобно для сортировки и надежнее, чем разбирать размеры в человекочитаемом формате.

#6. Краткий обзор состояния системы

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

Запуск каждой команды отдельно работает, но это занимает время и требует помнить несколько команд.

#!/usr/bin/env bash
# sysbrief — quick system health snapshot
set -euo pipefail

BOLD='\033[1m'
RESET='\033[0m'
RED='\033[0;31m'
YELLOW='\033[0;33m'
GREEN='\033[0;32m'
section() { echo -e "\n${BOLD}── $1 ──${RESET}"; }
section "System Information"
echo "Host   : $(hostname)"
echo "Kernel : $(uname -r)"
section "Uptime & Load"
uptime -p
awk '{printf "Load avg: %.2f %.2f %.2f\n", $1, $2, $3}' /proc/loadavg
section "Memory"
free -h | awk 'NR==2 {
    used=$3; total=$2; avail=$7
    printf "Used: %s / %s  |  Available: %s\n", used, total, avail
}'
section "Disk Usage (>70%)"
df -h --output=target,pcent,size,avail | awk 'NR==1 || $2+0 > 70 {
    if (NR==1) print; else print "\033[0;33m" $0 "\033[0m"
}'
section "Top 5 CPU Consumers"
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -6
section "Swap"
swapon --show 2>/dev/null || echo "No swap configured"

sysbrief

Вместо запуска нескольких команд, таких как uptime, df -h и free -h, нам нужна только одна команда, чтобы получить быстрый обзор нашей системы. Она особенно полезна при устранении проблем или проверке состояния сервера.

#7. Удаление дубликатов файлов в каталоге

Наличие дубликатов файлов — обычное явление, особенно после многократной загрузки одного и того же файла, копирования папок проекта или объединения резервных копий. Со временем они занимают место на диске и усложняют организацию каталогов.

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

#!/usr/bin/env bash
# rmdup — find (and optionally remove) duplicate files
# Usage: rmdup [directory] [--delete]
set -euo pipefail

DIR="${1:-.}"
DELETE="${2:-}"
echo "Scanning for duplicates in: $DIR"
echo ""
declare -A SEEN
DUPES=()
while IFS= read -r -d '' file; do
    hash=$(md5sum "$file" | cut -d' ' -f1)
    if [[ -n "${SEEN[$hash]:-}" ]]; then
        DUPES+=("$file")
        echo "  DUP  $file"
        echo "  OF   ${SEEN[$hash]}"
        echo ""
    else
        SEEN[$hash]="$file"
    fi
done < <(find "$DIR" -maxdepth 1 -type f -print0 | sort -z)
if [[ ${#DUPES[@]} -eq 0 ]]; then
    echo "No duplicates found."
    exit 0
fi
echo "Found ${#DUPES[@]} duplicate(s)."
if [[ "$DELETE" == "--delete" ]]; then
    for f in "${DUPES[@]}"; do
        rm -v "$f"
    done
    echo "Deleted ${#DUPES[@]} duplicate(s)."
else
    echo "Run with --delete to remove duplicates."
fi

# Usage:
rmdup ~/Downloads              # show duplicates only
rmdup ~/Downloads --delete     # show and delete duplicates

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

По умолчанию он только показывает список дубликатов, а для их удаления необходимо использовать --delete, что делает запуск более безопасным.

#8. Мониторинг нескольких сервисов

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

Запуск отдельных команд journalctl -f в разных терминалах работает, но быстрое переключение между окнами становится неудобным.

#!/usr/bin/env bash
# journalwatch — monitor multiple services with color-coded output
# Usage: journalwatch nginx [...]
set -euo pipefail

services=("$@")

if [ $# -eq 0 ]; then
    echo "Usage: journalwatch <service> [service ...]"
    exit 1
fi

colors=(
    "\033[31m"
    "\033[32m"
    "\033[33m"
    "\033[34m"
    "\033[35m"
)
reset="\033[0m"

for i in "${!services[@]}"; do
    service="${services[$i]}"
    color="${colors[$((i % ${#colors[@]}))]}"

    journalctl -fu "$service" |
    while IFS= read -r line; do
        printf "${color}[%s]${reset} %s\n" "$service" "$line"
    done &
done

wait

journalwatch nginx docker myapp

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

Примечание:
Этот скрипт использует journalctl, поэтому он работает в Linux-системах, использующих systemd. Для просмотра логов некоторых сервисов может потребоваться sudo.

#9. Сводка Git-репозитория

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

Запуск каждой команды отдельно работает, но быстро становится повторяющимся.

#!/usr/bin/env bash
# gitsum — git repo status summary
set -euo pipefail

BOLD='\033[1m'
CYAN='\033[0;36m'
YELLOW='\033[0;33m'
GREEN='\033[0;32m'
RESET='\033[0m'
if ! git rev-parse --is-inside-work-tree &>/dev/null; then
    echo "Not inside a git repository." >&2
    exit 1
fi
ROOT=$(git rev-parse --show-toplevel)
BRANCH=$(git symbolic-ref --short HEAD 2>/dev/null || git rev-parse --short HEAD)
REMOTE=$(git remote 2>/dev/null | head -1)
echo -e "${BOLD}Repository:${RESET} $(basename "$ROOT")"
echo -e "${BOLD}Branch:${RESET}     ${CYAN}${BRANCH}${RESET}"
# Ahead/behind tracking
if [[ -n "$REMOTE" ]]; then
    TRACKING=$(git for-each-ref --format='%(upstream:short)' "$(git symbolic-ref HEAD 2>/dev/null)" 2>/dev/null)
    if [[ -n "$TRACKING" ]]; then
        AHEAD=$(git rev-list "${TRACKING}..HEAD" --count 2>/dev/null || echo 0)
        BEHIND=$(git rev-list "HEAD..${TRACKING}" --count 2>/dev/null || echo 0)
        echo -e "${BOLD}Remote:${RESET}     ${REMOTE} (↑${AHEAD} ↓${BEHIND})"
    fi
fi
echo ""
echo -e "${BOLD}Working tree:${RESET}"
STATUS=$(git status --short)
if [[ -z "$STATUS" ]]; then
    echo -e "  ${GREEN}Clean${RESET}"
else
    echo "$STATUS" | sed 's/^/  /'
fi
echo ""
echo -e "${BOLD}Recent commits:${RESET}"
git log --oneline --graph --decorate -8
echo ""
echo -e "${BOLD}Stash:${RESET} $(git stash list 2>/dev/null | wc -l) entries"

gitsum

Вместо запуска git branch, git status, git log, git remote и git stash list отдельно мы можем использовать одну команду, чтобы увидеть текущую ветку, состояние рабочей директории, последние коммиты, количество записей в stash и находится ли ветка впереди или позади удалённой ветки. Это даёт быстрый обзор перед началом работы или отправкой изменений.

#10. Проверка записей SSH-конфигурации

При управлении большим количеством удалённых хостов в ~/.ssh/config нам нужно убедиться, что записи доступны и что аутентификация по ключу работает.

Можно вручную пройтись по всем настроенным хостам и проверить их состояние, но это неудобно и занимает много времени.

#!/usr/bin/env bash
# sshcheck — test connectivity to all configured SSH hosts
# Usage: sshcheck [timeout_seconds]
set -euo pipefail

TIMEOUT="${1:-5}"
CONFIG="${HOME}/.ssh/config"
GREEN='\033[0;32m'
RED='\033[0;31m'
YELLOW='\033[0;33m'
RESET='\033[0m'
if [[ ! -f "$CONFIG" ]]; then
    echo "No SSH config found at $CONFIG" >&2
    exit 1
fi
HOSTS=$(grep -i '^Host ' "$CONFIG" | awk '{print $2}' | grep -v '\*')
echo "Testing SSH hosts (timeout: ${TIMEOUT}s)..."
echo ""
printf "  %-30s %s\n" "Host" "Status"
printf "  %-30s %s\n" "----" "------"
while IFS= read -r host; do
    if ssh -o ConnectTimeout="$TIMEOUT" \
           -o BatchMode=yes \
           -o StrictHostKeyChecking=no \
           "$host" true 2>/dev/null; then
        printf "  ${GREEN}%-30s ✓ OK${RESET}\n" "$host"
    else
        EXIT=$?
        if [[ $EXIT -eq 255 ]]; then
            printf "  ${RED}%-30s ✗ Unreachable${RESET}\n" "$host"
        else
            printf "  ${YELLOW}%-30s ⚠ Auth failed (exit $EXIT)${RESET}\n" "$host"
        fi
    fi
done <<< "$HOSTS"

sshcheck       # test all hosts, 5s timeout
sshcheck 10    # 10s timeout

Вместо подключения к каждому серверу отдельно sshcheck проверяет каждый хост, определённый в ~/.ssh/config, с помощью одной команды. Он быстро показывает, какие серверы доступны, а какие требуют внимания, что делает его удобным инструментом перед развертыванием или регулярным обслуживанием.

#11. Проверка прослушиваемых портов

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

Мы можем использовать ss или lsof для этого, но это всё ещё требует ручной проверки и не предоставляет быстрого обзора, из-за чего процесс становится медленным и повторяющимся.

#!/usr/bin/env bash
# portcheck — show listening ports with owning process
# Usage: portcheck [port]
set -euo pipefail

if [[ $# -eq 1 ]]; then
    ss -tlnp | awk -v port=":$1" '$4 ~ port || $5 ~ port'
    echo ""
    echo "Process detail:"
    lsof -i :"$1" -nP 2>/dev/null || echo "  (lsof unavailable or no match)"
else
    echo "All listening TCP/UDP ports:"
    echo ""
    ss -tulnp | column -t
fi

portcheck          # all listening ports
portcheck 5432     # who owns port 5432

Вместо запоминания разных команд ss и lsof нам нужно только выполнить portcheck. Он быстро показывает, какие порты прослушиваются и, для конкретного порта, какой процесс его использует. Это особенно полезно при проверке корректного запуска сервиса или исследовании конфликтов портов.

#12. Снимок сетевых подключений

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

Хотя ss и netstat могут предоставить эту информацию, они выводят необработанные данные вместо понятной сводки.

#!/usr/bin/env bash
# netsnap — summarize active network connections
set -euo pipefail

BOLD='\033[1m'
RESET='\033[0m'
echo -e "${BOLD}Established connections by remote host:${RESET}"
ss -tnp state established \
    | awk 'NR>1 {print $4}' \
    | sed 's/:[0-9]*$//' \
    | sort | uniq -c | sort -rn \
    | awk '{printf "  %4d  %s\n", $1, $2}' \
    | head -20
echo ""
echo -e "${BOLD}Connection states summary:${RESET}"
ss -tan \
    | awk 'NR>1 {print $1}' \
    | sort | uniq -c | sort -rn \
    | awk '{printf "  %4d  %s\n", $1, $2}'
echo ""
echo -e "${BOLD}Listening services (TCP):${RESET}"
ss -tlnp \
    | awk 'NR>1 {printf "  %-25s %s\n", $4, $NF}'

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

#13. Пакетное переименование файлов

Нередко бывает, что появляются десятки файлов с именами IMG_20240101_*.jpg, которые нужно переименовать в vacation_*.jpg, или требуется удалить пробелы из каждого имени файла в каталоге.

Переименование файлов вручную непрактично, когда нужно обновить десятки или сотни имён.

#!/usr/bin/env bash
# rename-batch — bulk rename files using find-and-replace on filenames
# Usage: rename-batch <find> <replace> [directory]
set -euo pipefail

FIND="${1:-}"
REPLACE="${2:-}"
DIR="${3:-.}"
if [[ -z "$FIND" || -z "$REPLACE" ]]; then
    echo "Usage: rename-batch <find> <replace> [directory]" >&2
    echo "  Replaces all occurrences of <find> in filenames under [directory]" >&2
    echo "  Example: rename-batch ' ' '_' ./downloads" >&2
    exit 1
fi
COUNT=0
while IFS= read -r -d '' file; do
    dir=$(dirname "$file")
    base=$(basename "$file")
    newbase="${base//"$FIND"/"$REPLACE"}"
    if [[ "$base" != "$newbase" ]]; then
        mv -- "$file" "$dir/$newbase"
        echo "  $base  →  $newbase"
        (( COUNT++ ))
    fi
done < <(find "$DIR" -maxdepth 1 -type f -print0 | sort -z)
echo ""
echo "Renamed $COUNT file(s)."

rename-batch ' ' '_' ~/Downloads        # spaces → underscores
rename-batch 'IMG_' 'photo_' ./         # prefix swap
rename-batch '.JPEG' '.jpg' ./photos    # extension normalization

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

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

Shell-скрипты не обязательно должны означать написание сотен строк кода. Многие самые полезные скрипты — это небольшие утилиты, которые решают повседневные задачи. Они устраняют повторяющуюся работу, уменьшают количество ошибок и позволяют сосредоточиться на настоящем решении проблем вместо повторения одних и тех же команд.

Когда вы сталкиваетесь с повторяющимися задачами, спросите себя: «Могу ли я превратить это в скрипт?» Со временем эти небольшие скрипты накапливаются — они экономят вам секунды здесь, предотвращают ошибки там и делают работу в терминале более удобной.

Скрипты в этой статье не предназначены быть идеальными или полностью функциональными. Думайте о них как о начальных вариантах, которые мы можем настроить под собственный сценарий работы.

Спасибо за чтение! Надеюсь, эта статья станет отправной точкой для создания собственных инструментов и повышения вашей продуктивности.

Это перевод оригинальной статьи These 10 Linux Tools Changed Everything.

В последнее время жить в терминале стало по-настоящему интересно

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

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

Не поймите меня неправильно — cat, grep, find и cd десятилетиями обеспечивали работу мировой инфраструктуры. Это проверенные временем, надёжные инструменты, и они никуда не исчезнут. Однако сегодня пользоваться некоторыми из них — всё равно что писать код в Vim, когда знаешь, что существуют современные IDE вроде Cursor. Да, это своего рода знак мастерства, но работа определённо становится медленнее🤷‍♂️.

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

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

1. fzf — инструмент для нечёткого поиска

Если бы мне завтра пришлось полностью переустановить систему и начать всё с нуля, fzf, вероятно, был бы один из первых инструментов, которые я бы переустановил. По своей сути это инструмент для нечёткого поиска (fuzzy finder). Достаточно передать ему список элементов, и он позволит интерактивно искать по нему — будь то файлы, каталоги, ветки Git, Docker-контейнеры, процессы, история команд оболочки. Если что-то можно представить в виде текста, то, скорее всего, это можно искать с помощью fzf.

Для меня самым большим изменением стал поиск по истории команд. Большинство из нас используют Ctrl + R, чтобы искать ранее выполненные команды. Но после интеграции fzf это сочетание клавиш становится по-настоящему незаменимым. Нужно найти ту самую команду Docker, которую вы выполняли три недели назад? Нажмите Ctrl + R, введите несколько символов — даже не обязательно подряд — и нужная команда, скорее всего, появится ещё до того, как вы закончите печатать. Практически отпадает необходимость помнить точные команды или имена файлов, а терминал начинает казаться почти телепатическим. Это один из тех инструментов, которые незаметно меняют ваши привычки.

Через несколько недель использования возвращаться к терминалу без fzf уже кажется неудобным. Хотя сам по себе этот инструмент очень мощный, по-настоящему он раскрывается при интеграции с другими командами. Например:

# Interactive password selection from the linux password manager
pass show $(pass ls | fzf)

# Or with shell integration, just press TAB:
pass show   # Opens fzf interface

# Search command history (Ctrl+R with fzf integration)
history | fzf

Установить fzf— https://github.com/junegunn/fzf

2. tmux — полнофункциональный мультиплексор терминала

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

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

Долгие вычисления, среды разработки, миграции баз данных, обучение моделей — всё продолжает работать, даже если SSH-соединение разорвётся, ноутбук перейдёт в спящий режим или Wi-Fi решит именно сегодня начать сбоить. Пока сервер работает, всё в порядке. Вы можете отключиться, пойти прогуляться, подключиться позже даже с другого ноутбука — и всё окажется ровно там, где вы остановились.

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

# SSH into server and start tmux
ssh user@server
tmux

# Start a long-running task
htop

# Detach from session (Ctrl+b, then d)
# Even if SSH connection drops, you can reconnect:
ssh user@server
# Reattach to existing session (add -t <session> if you have multiple sessions)
tmux attach

Лично мне не нравятся стандартные сочетания клавиш, поэтому я использую собственную конфигурацию, которую можно найти здесь. Она добавляет поддержку мыши, а также возможность копировать и вставлять данные через буфер обмена, благодаря чему пользоваться tmux становится гораздо удобнее. Достаточно скопировать этот файл в каталог ~/.config/tmux/tmux.conf на вашем Linux-сервере. Если же вы предпочитаете настройки по умолчанию, обратитесь к руководству (man page).

Установить tmux — https://github.com/tmux/tmux/wiki/installing

3. mosh — мобильная оболочка (Mobile Shell)

Если вы когда-либо подключались к удалённому серверу по SSH через Wi-Fi в отеле, аэропорту или нестабильной точке доступа, вы, вероятно, сталкивались с этим:

Вы закрываете ноутбук. Переходите в другую комнату. Открываете его снова. И ваша SSH-сессия обрывается.

Именно эту проблему решает mosh (Mobile Shell). В отличие от SSH, который жёстко привязан к конкретному сетевому соединению, mosh изначально был разработан для работы в нестабильных и ненадёжных сетях. Вы можете переключаться между Wi-Fi и мобильной сетью, переходить из одной сети в другую, переводить ноутбук в спящий режим или даже ненадолго полностью терять соединение — при этом ваша терминальная сессия сохранится.

Секрет в том, что mosh использует собственный протокол синхронизации поверх UDP, который поддерживает синхронизацию между клиентом и сервером независимо от состояния сетевого соединения. Кроме того, он применяет технологию predictive local echo, благодаря которой ввод ощущается заметно более отзывчивым — особенно при работе с серверами, расположенными на другом конце света. И самое приятное — менять привычный способ работы не придётся. За аутентификацию по-прежнему отвечает SSH, поэтому ваши существующие ключи и методы входа продолжают работать без каких-либо изменений.

# instead of 
ssh user@server
# you use
mosh user@server

В сочетании с tmux это, пожалуй, самая надёжная конфигурация для удалённой разработки, которой мне когда-либо приходилось пользоваться.

Установить mosh — https://mosh.org/#getting

4. zoxide — ускоренная навигация по каталогам

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

Именно здесь на помощь приходит zoxide. По сути, это более умная версия команды cd, которая запоминает, в каких каталогах вы бываете чаще всего, и строит систему ранжирования на основе частоты и давности посещений. Благодаря этому навигация по файловой системе становится значительно быстрее. После нескольких дней использования вы вообще перестаёте думать о пути.

# instead of the verbose 
cd ./../../../../../code/development/projects/frontend/customer/portal
# we simply use `z portal`
# that's way less typing to achieve the same thing.
# plus it doesn't care about your current directory.
z portal

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

Установите zoxide — https://zoxide.org/

5. bat — улучшенная версия cat

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

Стоит один раз открыть с помощью bat shell-скрипт, YAML-файл или Python-модуль — и сразу становится понятно, почему так много разработчиков переходят на него практически мгновенно. Ничего революционного здесь нет — просто более приятный вариант по умолчанию, который делает повседневную работу немного комфортнее. А когда весь день проводишь за чтением текста, именно такие небольшие улучшения складываются в действительно заметную разницу.

Установить bat — https://github.com/sharkdp/bat#installation

6. btop — новый уровень удобства для top

Раньше я считал, что htop и так достаточно хорош. Но потом попробовал btop. Разница не столько в функциональности, сколько в качестве исполнения. btop в режиме реального времени показывает загрузку процессора, использование памяти, активность дисков, сетевой трафик и запущенные процессы — причём делает это так, что смотреть на интерфейс действительно приятно. Графики выглядят аккуратно, интерфейс работает отзывчиво, а найти процесс, который неожиданно начал потреблять 100% процессорного времени, можно буквально за несколько секунд.

Это один из тех инструментов, достоинства которого трудно оценить по скриншотам. Кроме того, btop очень быстрый и не расходует лишние ресурсы, поскольку написан на высокооптимизированном C++.

Установить btop — https://github.com/aristocratos/btop#installation

7. ripgrep — молниеносный поиск по тексту

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

Если вы не знакомы с grep, это утилита командной строки, которой большинство разработчиков пользуются для поиска текста внутри файлов. Проблема в том, что она без разбора просматривает всё подряд, включая ненужные каталоги вроде pycache, node_modules и другие, впустую расходуя ресурсы системы.

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

# grep command to search for "isAdmin" in the current project
# usually slow and includes node_modules
grep -r isAdmin .
# equivalent ripgrep command
rg isAdmin

Улучшенная скорость работы и более разумное поведение по умолчанию делают ripgrep исключительно удобным инструментом при работе с большими проектами. Поверьте, впервые воспользовавшись ripgrep на крупном репозитории, вы, скорее всего, зададитесь вопросом, почему не сделали этого раньше.

Установить ripgrep — https://github.com/burntsushi/ripgrep#installation

8. fd — современный поиск файлов

Если ripgrep — это улучшенная версия grep, то fd — улучшенная версия find. И если честно, большинству разработчиков этого уже достаточно, чтобы понять, зачем он нужен.

Я до сих пор не могу запомнить синтаксис find. Каждый раз, когда мне требуется что-то сложнее самых простых случаев, я открываю шпаргалку, ищу ответ на Stack Overflow или прошу AI-ассистента сделать это за меня.

Вот простой пример:

# Lets say I want to list all the files with the word "util" in their filename
find . -type f -name "*util*"
# with fd, it is as simple as
fd util

Как и ripgrep, fd поставляется с большим количеством удачных настроек по умолчанию. Он работает быстрее, учитывает .gitignore, по умолчанию выполняет поиск без учёта регистра и поддерживает как регулярные выражения, так и шаблоны glob.

Если требуется более гибкая фильтрация, можно использовать, например, такую команду:

# Find files containing "test" but exclude those with "route"
fd test --exclude "*route*"

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

Установить fd — https://github.com/sharkdp/fd

9. delta — подсветка синтаксиса

Просматривать различия между файлами с помощью diff или изменения в Git через git diff стало гораздо проще после того, как я установил delta. Конечно, стандартный вывод diff и git diff выполняет свою задачу, но работать с ним значительно менее удобно. Особенно это ощущается, когда pull request разрастается хотя бы до нескольких файлов — просмотр изменений начинает быстро утомлять.

delta делает вывод различий гораздо более наглядным, добавляя подсветку синтаксиса, нумерацию строк, режим сравнения бок о бок и подсветку изменений на уровне отдельных символов. Это один из тех инструментов, про который кажется, что он должен был появиться в составе Git ещё много лет назад. Чтобы ознакомиться со всеми возможностями, загляните в файл README.md репозитория.

Установить delta — https://github.com/dandavison/delta

10. lazydocker — TUI для управления Docker

Если вы каждый день работаете с Docker, то, скорее всего, уже довели до автоматизма примерно такой набор команд:

docker ps
docker logs <container>
docker stats
docker inspect <container>

lazydocker объединяет всю эту функциональность в одном терминальном интерфейсе. Вы получаете дашборд, на котором в реальном времени отображаются контейнеры, образы, тома, логи, потребление ресурсов и состояние контейнеров — без необходимости постоянно переключаться между отдельными командами. Вы можете просматривать логи, просто выбрав нужный контейнер, перезапускать его нажатием одной клавиши и сразу видеть потребление ресурсов — всё это уже встроено в интерфейс. По ощущениям lazydocker для Docker делает примерно то же самое, что btop для мониторинга системы. Когда начинаешь пользоваться им регулярно, возвращаться к ручному выполнению множества Docker-команд уже кажется неоправданно неудобным.

ctop — хороший дополнительный инструмент к lazydocker, однако лично мне возможностей lazydocker вполне хватает. Когда я только начинал с ним работать, мне очень помогло это руководство по настройке. Надеюсь, оно окажется полезным и вам!

Заключительные мысли

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

За последние пару лет эти десять CLI-инструментов кардинально изменили мой подход к работе в терминале. Мои рекомендации следующие.

Если вы только начинаете работать локально, попробуйте прежде всего fzf, zoxide, ripgrep и fd. Если же вы постоянно подключаетесь к удалённым серверам, то mosh, tmux и fzf — это инструменты, без которых действительно не стоит обходиться. Когда освоитесь хотя бы с частью из них, попробуйте и остальные — по мере того как будете сталкиваться с задачами, для которых они предназначены.

Это перевод оригинальной статьи auditd: More Than Just Logs — Know Who Did What on Linux.

Повысьте уровень прозрачности вашей системы Linux — от базовых логов до полноценного аудита

Кто это сделал?

Каждый администратор Linux рано или поздно сталкивается с такими вопросами:

• Кто удалил этот файл?
• Кто внес изменения в эту конфигурацию?
• Кто выполнил эту команду?

Это может привести к сбоям, когда внешне всё выглядит нормально, но на самом деле что-то важное уже не работает.

Мы не можем достоверно определить, кто это сделал, используя только логи или мониторинг, поскольку они обеспечивают лишь частичную видимость. Чтобы полностью понять, что произошло, нам нужен аудит.

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

Введение в аудит

Что такое auditd?

auditd (Audit Daemon) — это сервис пользовательского пространства, который собирает и сохраняет события аудита, генерируемые Linux Audit Framework.

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

Linux Audit Framework

Для эффективного использования auditd необходимо понимать его экосистему. Это не просто отдельный инструмент, а набор компонентов, работающих вместе в рамках Linux Audit Framework.

Linux Audit Framework состоит из нескольких компонентов:

+-------------------+
| Linux Applications|
+---------+---------+
          |
          v
+-------------------+
| Linux Kernel      |
| Audit Subsystem   |
+---------+---------+
          |
          v
+-------------------+
| auditd Daemon     |
+---------+---------+
          |
          v
+-------------------+
| Audit Logs        |
| /var/log/audit/   |
+-------------------+

• Приложение → Выполняет действия, такие как доступ к файлам, выполнение команд, сетевые операции или аутентификация пользователя, которые выполняют системные вызовы (например, open, execve).
• Подсистема аудита ядра → Обнаруживает эти системные вызовы и генерирует события аудита, когда они соответствуют настроенным правилам аудита, применяемым к системным вызовам и событиям ядра.
• auditd → Получает события аудита от ядра и записывает их на диск в структурированном формате.
• Логи аудита → Постоянные записи, создаваемые auditd, обычно хранящиеся в /var/log/audit/audit.log, используемые для поиска, формирования отчетов и криминалистического анализа.

Примечание:
В отличие от стандартных средств логирования, таких как rsyslog или systemd-journald, которые зависят от того, сообщают ли приложения о собственной активности, аудит работает на уровне ядра. Это означает, что его нельзя обойти обычными инструментами пользовательского пространства, и даже если процесс скомпрометирован, его системные вызовы всё равно будут записаны, если только не скомпрометировано само ядро.

Правила аудита

Правила аудита — это директивы конфигурации, которые указывают Linux Audit System (auditd), какие действия необходимо отслеживать и записывать. Эти правила определяют, какие события будут фиксироваться, например доступ к файлам, изменения конфигурации, действия пользователей и системные вызовы.

Правила хранятся в виде файлов .rules в каталоге /etc/audit/rules.d/ и при запуске системы (или при выполнении augenrules --load) компилируются в файл /etc/audit/audit.rules.

Порядок загрузки файлов правил:
Размещайте правила аудита в пронумерованных файлах .rules, чтобы управлять порядком их загрузки. Файлы обрабатываются последовательно в алфавитно-цифровом порядке утилитой augenrules.

/etc/audit/rules.d/
├── 10-base-config.rules     # Kernel/auditd settings# Kernel/auditd settings
├── 20-netsys.rules          # Network-related rules
├── 30-suid.rules            # SUID/SGID execution
├── 40-modules.rules         # Kernel module loading
├── 50-identity.rules        # Identity/auth files
├── 70-system-local.rules    # Local custom rules
└── 99-finalize.rules        # Lock the ruleset

• Использование системы нумерации помогает упорядочить политики аудита, упрощает сопровождение и гарантирует загрузку правил в нужном порядке.

Важно:
правила можно добавить временно с помощью auditctl или сделать постоянными с помощью файлов в каталоге /etc/audit/rules.d/.

Записи аудита

Когда происходит отслеживаемое событие, Linux Audit System генерирует одну или несколько записей аудита, объединенных в одно событие общими временной меткой и серийным номером. Один системный вызов open() может создать записи типов SYSCALL, PATH, CWD и PROCTITLE.

Распространенные типы записей:

• SYSCALL → сведения о системном вызове (имя, аргументы, PID, UID)
• PATH → путь к файлу, участвующему в системном вызове
• CWD → текущий рабочий каталог на момент события
• EXECVE → аргументы, переданные запускаемому процессу
• USER_AUTH → событие аутентификации PAM
• USER_LOGIN → попытка входа в систему (успешная или неуспешная)
• USER_CMD → команда, выполненная через sudo
• CRED_ACQ → получение учетных данных (например, sudo)
• SOCKADDR → информация об адресе сокета (для сетевых событий)
• AVC → отказ SELinux Access Vector Cache
• CONFIG_CHANGE → конфигурация аудита была изменена

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

Распространенные поля записей аудита:

• auid — Audit UID, исходный UID пользователя, вошедшего в систему; сохраняется после su/sudo
• uid/gid — эффективный UID/GID на момент события
• euid/egid — эффективный UID/GID
• comm — имя команды (обрезается до 15 символов)
• exe — полный путь к исполняемому файлу
• key — метка, назначенная правилу для удобной фильтрации
• success — успешно ли выполнен системный вызов (yes/no)
• res — результат событий пользовательского пространства (success/failed)

Примечание:
Поле auid особенно важно, поскольку оно идентифицирует пользователя, который первоначально вошел в систему, и остается неизменным даже после повышения привилегий (например, с помощью sudo или su). Это делает его критически важным для правильной привязки действий к конкретному пользователю.

Файлы конфигурации

/etc/audit/auditd.conf — основной файл конфигурации демона auditd. Он управляет тем, как логи аудита сохраняются, ротируются и обслуживаются.

# /etc/audit/auditd.conf

# Where logs are written
log_file = /var/log/audit/audit.log
log_format = ENRICHED        # Resolves UIDs/GIDs to names in the log
log_group = root

# Log rotation
max_log_file = 50            # Max size of each log file in MB
num_logs = 10                # Number of rotated files to keep
max_log_file_action = ROTATE # ROTATE | SYSLOG | SUSPEND | KEEP_LOGS | EXEC

# What to do when disk space is critically low
space_left = 75              # MB remaining — trigger space_left_action
space_left_action = SYSLOG
admin_space_left = 50        # MB remaining — trigger admin_space_left_action
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND

# Performance
backlog_wait_time = 60000    # Microseconds to wait when backlog is full
priority_boost = 4           # Nice level boost for auditd process

Начало работы с auditd

Установка

Большинство современных корпоративных дистрибутивов Linux (RHEL, Rocky Linux, Ubuntu Server) поставляются с уже установленным auditd. Если он отсутствует, мы можем установить его с помощью менеджера пакетов:

# Debian/Ubuntu:
sudo apt update && sudo apt install auditd audispd-plugins -y
sudo systemctl enable --now auditd

# RHEL/CentOS/Fedora:
sudo dnf install audit audit-libs -y
sudo systemctl enable --now auditd

# Verify it's running:
sudo systemctl status auditd
sudo auditctl -s  # Show kernel audit status

Создаем первое правило аудита

Правила аудита определяют, какие действия должен отслеживать auditd.

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

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

1. Добавьте правило наблюдения.

sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config

• -w → отслеживать определенный файл или каталог
• -p wa → отслеживание изменений записи (w) и атрибутов (a)
• -k ssh_config → назначить ключ для поиска с именем ssh_config

Эта команда указывает auditd записывать любые изменения, внесенные в файл, включая изменения метаданных файла /etc/ssh/sshd_config, и помечать событие ключом ssh_config.

Примечание:
Всегда используйте параметр -k (key). Назначение уникального текстового ключа правилам значительно упрощает фильтрацию гигабайтов логов с помощью ausearch.

2. Убедитесь, что правило аудита активно, перечислив все загруженные в данный момент правила auditd.

sudo auditctl -l

Должно отображаться:

-w /etc/ssh/sshd_config -p wa -k ssh_config

3. Сгенерируйте тестовое событие, изменив файл конфигурации SSH.

echo "# auditd test" | sudo tee -a /etc/ssh/sshd_config

• Это создаст событие изменения файла, которое должно быть зафиксировано auditd.

4. Проверьте событие:

sudo ausearch -f /etc/ssh/sshd_config

• Команда вернет одну или несколько записей аудита, показывающих доступ к /etc/ssh/sshd_config или его изменение, включая имя процесса, временную метку и ключ правила аудита.

Примечание:
ausearch — это утилита командной строки, входящая в состав auditd, предназначенная для поиска и извлечения событий из логов аудита Linux.

Понимание правил аудита

Правила аудита определяют, что именно должно отслеживать ядро. Обычно они делятся на три категории:

• Правила управления (Control Rules) → настраивают поведение системы аудита (например, размеры буферов или поведение при сбоях).

# Delete all existing rules (always first)
-D

# Set the backlog buffer — increase for high-traffic systems
-b 8192

# Failure mode: 0=silent, 1=printk, 2=panic
-f 1

# Rate limit audit messages (per second, 0=unlimited)
-r 0

• Правила наблюдения за файловой системой (File System Watches) → отслеживают доступ к определенным файлам или каталогам.

# Syntax: -w <path> -p <permissions> -k <key>
# Permissions: r=read, w=write, x=execute, a=attribute change

# Watch passwd file for any writes or attribute changes
-w /etc/passwd -p wa -k identity

# Watch shadow file
-w /etc/shadow -p wa -k identity

# Watch sudoers
-w /etc/sudoers -p wa -k scope
-w /etc/sudoers.d/ -p wa -k scope

# Watch SSH configs
-w /etc/ssh/sshd_config -p wa -k sshd_config

# Watch audit configuration itself
-w /etc/audit/ -p wa -k audit_config
-w /etc/libaudit.conf -p wa -k audit_config
-w /etc/audisp/ -p wa -k audit_config

• Правила системных вызовов (System Call Rules) → перехватывают определенные операции, выполняемые любым процессом через системные вызовы ядра Linux.

# Syntax:
# -a <list>,<action> -S <syscall> -F <field>=<value> -k <key>
#
# Lists: task, exit, user, exclude, filesystem
# Actions: always, never

# Log all chmod/chown/chattr syscalls by non-root users
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_mod

# Log all execve calls (process execution) — critical for forensics
-a always,exit -F arch=b64 -S execve -k exec
-a always,exit -F arch=b32 -S execve -k exec

# Log failed file access attempts (unauthorized reads/writes)
-a always,exit -F arch=b64 -S open,openat,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -k access
-a always,exit -F arch=b64 -S open,openat,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -k access

# Log privilege escalation attempts
-a always,exit -F arch=b64 -S setuid,setgid,setreuid,setregid -F auid>=1000 -k priv_esc

# Log kernel module loading/unloading
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k modules

Примечание:
Всегда определяйте правила как для b64 (64-битная архитектура), так и для b32 (32-битная совместимость). 32-битный процесс, работающий на 64-битном ядре, использует другие номера системных вызовов, поэтому он не будет соответствовать правилам b64.

Снижение уровня шума: правила исключения

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

# Exclude high-frequency, low-value events from specific processes
-a never,exit -F arch=b64 -F auid=unset -k ignore_unset_auid

# Exclude audit events from the audit daemon itself (prevents recursion)
-a never,exit -F exe=/sbin/auditd

# Exclude noisy cron jobs (audit their config changes, not every execution)
-a never,exit -F arch=b64 -F uid=daemon -S execve

# Exclude specific paths from file watch recursion
# (watch /etc/ but not the high-churn temp files inside it)
-a never,exit -F path=/etc/mtab

# Exclude systemd journal chatter
-a never,exit -F arch=b64 -F exe=/lib/systemd/systemd-journald

Важно:
Правила never должны располагаться перед правилами always для одного и того же события, поскольку ядро обрабатывает правила по порядку и останавливается на первом совпадении.

Поиск по логам с помощью ausearch

По мере работы auditd может генерировать или даже миллионы записей логов, ручной просмотр /var/log/audit/audit.log непрактичен. Вместо этого используется ausearch, чтобы эффективно фильтровать и извлекать только нужные события.

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

Поиск по ключу

Один из наиболее распространенных способов поиска в логах аудита — использование ключа, назначенного правилу аудита.

Например, если мы создали следующее правило:

sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config

• Это добавляет активное правило аудита, которое отслеживает /etc/ssh/sshd_config на предмет изменений записи и атрибутов, помечая соответствующие события ключом ssh_config для упрощения поиска.
• Здесь мы использовали auditctl, чтобы добавить правило только в работающую систему (временно, правило будет потеряно после перезагрузки). Для постоянного использования правило должно быть помещено в /etc/audit/rules.d/.

Мы можем получить соответствующие события с помощью:

sudo ausearch -k ssh_config

• Эта команда выполняет поиск в логах аудита всех событий, помеченных ключом ssh_config, и показывает связанную с ними активность.

Поиск по файлу

Найти события, связанные с конкретным файлом:

sudo ausearch -f /etc/passwd

Это полезно при расследовании того, кто обращался к критически важному файлу или изменял его.

Поиск по пользователю

Отображение событий, связанных с конкретной учетной записью пользователя:

sudo ausearch -ua alice

# Or use a UID
sudo ausearch -ui 1000

Это может помочь отслеживать активность пользователя в ходе конкретного расследования.

Поиск по времени

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

# View events that occurred recently:
sudo ausearch -ts today

# Search events from the last hour:
sudo ausearch -ts recent

# Specify a custom time range:
sudo ausearch -ts "2026-06-10 09:00:00" -te "2026-06-10 10:00:00"

• -ts → время начала
• -te → время окончания

Поиск событий, завершившихся ошибкой

Найдите операции, завершившиеся ошибкой:

# failed events
sudo ausearch -sv no

# successful events
sudo ausearch -sv yes

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

Поиск по идентификатору процесса

Находит все события аудита, сгенерированные определенным идентификатором процесса (PID).

sudo ausearch -p 1234

Это полезно для отслеживания всего, что сделал один работающий процесс за время своего существования.

Поиск по исполняемому файлу

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

ausearch -x /usr/bin/sudo

Это помогает определить все действия, выполненные определенной программой.

Поиск по системному вызову

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

ausearch -sc execve

Это полезно для отслеживания низкоуровневых действий ядра, таких как выполнение процессов или доступ к файлам.

Интерпретация вывода (преобразование числовых идентификаторов, удобное форматирование)

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

ausearch -k identity -i

• -k identity → фильтровать логи аудита по ключу identity
• -i → преобразовать числовые значения в читаемые имена (UID → имя пользователя, номера системных вызовов → имена системных вызовов и т.д.)

# Example Output

# Without -i:
uid=1000 syscall=59 success=no

# With -i:
uid=alice syscall=execve success=no

Вывод в определенных форматах

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

ausearch -k exec -i --format text  # Human-readable
ausearch -k exec --format csv      # CSV for analysis

Это упрощает чтение и интеграцию с другими инструментами.

Комбинирование фильтров

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

# Search all events related to SSH configuration changes in readable format.
ausearch -k ssh_config -i

# Find all sudo executions recorded today, with human-readable output.
ausearch -k exec -x /usr/bin/sudo --start today -i

# Trace everything done by a specific process ID.
ausearch -p 1234 -i

# Show identity-related changes (users/groups) that occurred today.
ausearch -k identity --start today --end now -i

# Find permission changes made by a specific user.
ausearch -k perm_mod -ui 1000 -i

Формирование отчетов с помощью aureport

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

Сводная информация по всем типам событий

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

sudo aureport --summary

Summary Report
======================
Range of time in logs: 06/10/2026 08:00:00 - 06/10/2026 12:00:00time in logs: 06/10/2026 08:00:00 - 06/10/2026 12:00:00

Login Summary
----------------------
root     3
alice    12
bob      5

Authentication Summary
----------------------
success  50
failed   5

Event Summary
----------------------
type=USER_LOGIN    20
type=USER_AUTH     35
type=SYSTEM_BOOT    1

Отчет о входе/аутентификации

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

sudo aureport -au              # authentication events (detailed)
sudo aureport -au --summary    # authentication statistics
sudo aureport -au --failed     # failed authentication attempts

Отчеты об активности пользователей

Сформируйте отчет о событиях, связанных с пользователями:

sudo aureport --user

Это позволяет получить сводную информацию об активности по идентификатору пользователя и может помочь выявить необычное поведение.

Отчет об исполняемых файлах

Формирует сводный отчет по выполненным программам, отслеживая системный вызов execve. Он показывает, какие исполняемые файлы запускались в системе и как часто они использовались.

sudo aureport -x --summary

Executable Summary
======================
/usr/bin/sudo        40
/usr/bin/passwd      10
/usr/bin/vim         18
/bin/systemctl        7

Отчеты о доступе к файлам

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

File Report
=================================
# date time file event
1 06/10/26 10:15:42 /etc/passwd WRITE
2 06/10/26 10:20:18 /etc/shadow ATTRIB

Это полезно для отслеживания того, какие файлы читаются, записываются, создаются или удаляются, а также какие пользователи или процессы выполняют эти действия.

Отчет об изменениях учетных записей пользователей

Сформируйте отчет об изменениях учетных записей пользователей, чтобы отслеживать изменения, внесенные в системные учетные записи.

sudo aureport -m

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

Отчет о системных вызовах

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

sudo aureport -s

Отчет за определенный диапазон времени

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

# Shows all audit activity from the start of the current day up to the present time.
sudo aureport --start today    

# Shows only events that occurred between 9 AM and 12 PM.
sudo aureport --start "09:00:00" --end "12:00:00"

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

Важно:
Используйте параметр -i, чтобы преобразовать числовые значения, такие как идентификаторы пользователей (UID), идентификаторы групп (GID) и номера системных вызовов, в читаемые имена. Это делает вывод отчета аудита более удобным для чтения и интерпретации. Например: sudo aureport -au -i.

Мониторинг потерянных событий

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

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

1. Проверьте состояние подсистемы аудита:

sudo auditctl -s

# Output:
enabled 1
failure 1
pid 1234
rate_limit 0
backlog_limit 8192
lost 0
backlog 0

Обратите пристальное внимание на поле lost:

• lost = 0 → означает, что ни одно событие аудита не было потеряно.
• lost > 0 → указывает, что некоторые записи аудита не были сохранены и были потеряны, что может свидетельствовать о перегрузке системы, ограничениях буфера или проблемах с логированием, которые необходимо расследовать.

Увеличение размера буфера Backlog

Если возникают потерянные события, увеличьте размер буфера аудита.

# Temporary change:
sudo auditctl -b 16384

# Persistent configuration (rules file): under /etc/audit/rules.d/
-b 16384
sudo augenrules --load  # Reload the rules

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

Сокращение количества правил

Если увеличение размера backlog не помогает, пересмотрите правила аудита:

sudo auditctl -l

Обратите внимание на:

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

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

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

Практические правила для production

Вместо того чтобы создавать правила с нуля, отраслевым стандартом является размещение модульных файлов .rules в каталоге /etc/audit/rules.d/ и их загрузка с помощью augenrules --load.

Ниже приведены основные production-ready конфигурации, которые должен реализовать каждый инженер по безопасности:

## /etc/audit/rules.d/99-production.rules
## Production hardening ruleset

## ─── SECTION 1: Control ───────────────────────────────────────────────────────
-D
-b 8192
-f 1
--backlog_wait_time 60000

## ─── SECTION 2: Identity & Auth Files ───────────────────────────────────────
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity
-w /etc/nsswitch.conf -p wa -k identity

## ─── SECTION 3: Sudoers & Privilege Escalation ───────────────────────────────
-w /etc/sudoers -p wa -k scope
-w /etc/sudoers.d/ -p wa -k scope
-a always,exit -F arch=b64 -S setuid -F a0=0 -F exe=/usr/bin/su -k priv_esc
-a always,exit -F arch=b32 -S setuid -F a0=0 -F exe=/usr/bin/su -k priv_esc
-a always,exit -F arch=b64 -S setresuid -F a0=0 -F exe=/usr/bin/newgrp -k priv_esc

## ─── SECTION 4: File Permission Changes ──────────────────────────────────────
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b64 -S chown,fchown,lchown,fchownat -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b32 -S chown,fchown,lchown,fchownat -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -k perm_mod
-a always,exit -F arch=b32 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -k perm_mod

## ─── SECTION 5: Unsuccessful File Access ────────────────────────────────────
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k access
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k access
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k access
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k access

## ─── SECTION 6: Kernel Module Operations ────────────────────────────────────
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module,finit_module -k modules
-a always,exit -F arch=b64 -S delete_module -k modules

## ─── SECTION 7: Network Configuration Changes ───────────────────────────────
-a always,exit -F arch=b64 -S sethostname,setdomainname -k network_modifications
-w /etc/hosts -p wa -k network_modifications
-w /etc/network/ -p wa -k network_modifications
-w /etc/sysconfig/network -p wa -k network_modifications
-w /etc/netplan/ -p wa -k network_modifications

## ─── SECTION 8: System Calls — Time ──────────────────────────────────────────
-a always,exit -F arch=b64 -S adjtimex,settimeofday -k time_change
-a always,exit -F arch=b32 -S adjtimex,settimeofday,stime -k time_change
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -k time_change
-w /etc/localtime -p wa -k time_change

## ─── SECTION 9: Process Execution ───────────────────────────────────────────
-a always,exit -F arch=b64 -S execve -k exec
-a always,exit -F arch=b32 -S execve -k exec

## ─── SECTION 10: Mount / Unmount Operations ──────────────────────────────────
-a always,exit -F arch=b64 -S mount,umount2 -F auid>=1000 -F auid!=-1 -k mounts
-a always,exit -F arch=b32 -S mount,umount2 -F auid>=1000 -F auid!=-1 -k mounts

## ─── SECTION 11: File Deletion ───────────────────────────────────────────────
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=-1 -k delete
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=-1 -k delete

## ─── SECTION 12: SSH ─────────────────────────────────────────────────────────
-w /etc/ssh/sshd_config -p wa -k sshd
-w /etc/ssh/sshd_config.d/ -p wa -k sshd

## ─── SECTION 13: Cron & Scheduled Tasks ─────────────────────────────────────
-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## ─── SECTION 14: SUID / SGID Execution ──────────────────────────────────────
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid
-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k setuid
-a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid
-a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k setgid

## ─── SECTION 15: Audit Configuration ────────────────────────────────────────
-w /etc/audit/ -p wa -k audit_config
-w /etc/libaudit.conf -p wa -k audit_config
-w /etc/audisp/ -p wa -k audit_config
-w /sbin/auditctl -p x -k audit_tools
-w /sbin/auditd -p x -k audit_tools

## ─── FINALIZE: Make rules immutable (requires reboot to change) ──────────────
## Uncomment in production after thorough testing
# -e 2

• Флаг -e 2 в конце делает конфигурацию аудита неизменяемой до следующей перезагрузки, что критически важно для защиты от несанкционированных изменений в средах с повышенными требованиями к безопасности.

Лучшие практики использования auditd

Auditd — это мощный инструмент аудита, однако неправильно настроенная конфигурация может генерировать чрезмерное количество логов, занимать дисковое пространство и усложнять расследование инцидентов. Цель состоит в том, чтобы собирать полезные события, связанные с безопасностью, не перегружая при этом систему.

• В первую очередь отслеживайте критически важные файлы → начните аудит с файлов, которые напрямую влияют на безопасность системы и управление доступом пользователей.

#Common examples:
/etc/passwd
/etc/shadow
/etc/group
/etc/sudoers
/etc/ssh/sshd_config

# These files are often the first place attackers or administrators make changes.

• Используйте понятные ключи → Всегда задавайте понятные ключи с помощью параметра -k. Осмысленные ключи значительно упрощают поиск и создание отчетов.

-k ssh_config
-k user_changes
-k sudo_usage
-k privileged_commands

• Не пытайтесь аудировать всё → Распространенной ошибкой является попытка логировать каждое возможное событие, что может привести к огромному объему логов и повлиять на производительность системы.
• Отслеживайте привилегированную активность → Отслеживайте действия, выполняемые с повышенными привилегиями.

sudo auditctl -a always,exit \
  -F arch=b64 \
  -S execve \
  -F euid=0 \
  -k privileged_commands

• Делайте правила постоянными → Правила, добавленные с помощью auditctl, исчезают после перезагрузки. Храните production-правила в каталоге /etc/audit/rules.d/.
• Определяйте правила аудита как для b64 (64-битной архитектуры), так и для b32 (32-битной совместимости) → В 64-битном ядре 32-битные процессы используют другие номера системных вызовов, и без отдельных правил они могут не попасть в аудит.
• Включите ротацию логов → В загруженных системах логи аудита могут быстро расти. Правильно настроенная ротация предотвращает неожиданное заполнение диска.
• Контролируйте доступное место на диске → Если логи аудита невозможно записать, мы можем потерять видимость важных событий.
• Регулярно используйте ausearch и aureport → Сбор данных аудита полезен только в том случае, если кто-то регулярно их анализирует.
• Пересылайте логи в централизованную систему → Для production-сред не полагайтесь исключительно на локальное хранение логов.
• Периодически пересматривайте правила аудита → Требования к аудиту со временем меняются. Политика аудита должна развиваться вместе с нашей инфраструктурой.
• Периодически проверяйте состояние аудита → Убедитесь, что события не теряются, выполнив команду sudo auditctl -s и проверив, что значение поля lost остается равным 0.

Заключение

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

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

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

Спасибо за чтение! Надеюсь, это руководство поможет вам повысить безопасность и улучшить наблюдаемость Linux-систем.

Какие правила auditd являются для вас обязательными на каждом Linux-сервере?

Это перевод оригинальной статьи Stop Memorizing Commands! Learn These 10 Linux Workflows Instead.

Новички сосредоточены на командах. Опытные инженеры мыслят рабочими сценариями

Команды меняются, но рабочий процесс остается прежним

Команды — это всего лишь инструменты. Они могут различаться в зависимости от окружения, дистрибутива, версии системы или предпочтений команды. На одном сервере может быть доступен только top, на другом используют htop. Одни команды работают с grep, другие предпочитают rg (ripgrep). Именно поэтому недостаточно просто запоминать команды.

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

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

#1. Высокое потребление памяти

Высокое потребление памяти — одна из самых распространённых причин срабатывания оповещений в Linux. Обычно первым делом запускают команду free -h, которая подтверждает наличие проблемы, но не объясняет её причину.

Когда использование памяти высокое, главная задача — не допустить, чтобы OOM Killer (Out-Of-Memory Killer) завершил критически важные сервисы, такие как базы данных или основные процессы приложения. Для этого нужен последовательный алгоритм действий, который поможет правильно определить причину и устранить проблему до того, как она станет критической.

Шаг 1. Проверьте, не сработал ли уже OOM Killer

OOM Killer (Out Of Memory Killer) означает, что в системе закончилась память, и Linux принудительно завершил один или несколько процессов, чтобы сохранить работоспособность системы. Если это уже произошло, текущее состояние отражает последствия аварии, а не нормальную работу системы.

dmesg -T | grep -E "(Out of memory|oom_kill|Killed process)" | tail -20

#or
journalctl -k | grep -i "killed process"

# Example output:
[Mon Feb 23 03:14:22 2026] Out of memory: Killed process 18432 (java)
 total-vm:8388608kB, anon-rss:6291456kB, file-rss:0kB, shmem-rss:0kB

Если ошибка нехватки памяти уже произошла:

• Определите, какой процесс был завершён;
• Оцените текущее состояние системы, найдите первопричину и устраните проблему с памятью (шаги 2–7);
• Восстановите работу сервиса (systemctl restart <service-name>)

Шаг 2. Подтвердите наличие нехватки памяти

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

free -h

               total        used        free      shared  buff/cache   available
Mem:            15Gi       6.2Gi       1.1Gi       512Mi       7.7Gi       8.3Gi
Swap:           2.0Gi         0B       2.0Gi

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

• Высокое значение (норма): доступно примерно 30–50% общего объёма RAM — запас памяти достаточный.
• Среднее: доступно 10–30% — нормальное состояние, но стоит наблюдать, если показатель продолжает снижаться.
• Низкое: менее 10% — память начинает испытывать нагрузку.
• Критическое: менее 5% (или стабильно менее 1–2 ГБ на системах с большим объёмом памяти) — существует риск использования swap, снижения производительности или срабатывания OOM Killer.

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

Использование swap:
Ещё один важный показатель — swap. Он показывает, какой объём данных был выгружен из оперативной памяти на диск из-за её нехватки. Однако оповещения должны срабатывать раньше, чем начинает активно использоваться swap, поскольку его использование обычно означает, что свободной RAM уже недостаточно.

• 0% swap — идеальное состояние, нехватки памяти нет.
• Низкое использование: 1–20% от общего объёма swap — незначительная нагрузка, обычно это нормально (если показатель остаётся стабильным).
• Высокое использование: более 20–30% — система испытывает серьёзную нехватку памяти, возможны замедление работы и повышенная нагрузка.

Шаг 3. Определите основных потребителей памяти

Если объём available невелик, проверьте, какие процессы используют больше всего памяти.

# live monitoring
top        # press Shift + M to sort by memory

# snapshot
ps -eo pid,comm,%mem,rss --sort=-rss | head

# Output: ps -eo pid,comm,%mem,rss --sort=-rss | head

  PID COMMAND         %MEM    RSS
 2341 firefox         12.3  1024300
 1987 chrome          10.1   842500
 1102 java             8.7   725300
  901 gnome-shell      3.2   265400
  745 systemd           1.5   120000
  512 dockerd           1.2    98000
  333 sshd              0.5    42000
  210 cron              0.1    12000
  105 systemd-journal   0.1    11000

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

Шаг 4: Изучите полученные результаты.

Для каждого процесса с высоким потреблением памяти или подозрительным поведением выясните, сколько памяти он использует: оперативной памяти (RAM), swap и виртуальной памяти.

cat /proc/<PID>/status | grep -E 'VmRSS|VmSwap|VmPeak|VmSize'

VmRSS   :  120000 kB   (RAM used)
VmSwap  :   50000 kB   (swap used)
VmSize  :  300000 kB   (total virtual memory)
VmPeak  :  320000 kB   (peak memory usage)

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

• VmRSS высокий уровень: > 30% RAM → процесс потребляет много RAM
• VmSwap > 0 → часть памяти процесса уже находится в swap (нехватка памяти).
• Высокий VmRSS + растущий VmSwap → явный признак проблем с памятью

Шаг 5: Подтверждение поведения

VmSwap > 0 (процесс уже использует swap)
Иногда это может быть нормальным, но также может указывать на нехватку памяти, если объём swap продолжает расти или сопровождается высоким значением VmRSS.

# Monitor system memory + CPU + swap activity view updated every 1 second.
vmstat 1  

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs  us  sy  id  wain   cs  us  sy  id  wa
 1  0  10240  200000  50000 800000    0    5     2     3   120  200  5   2  90   3

• si (swap in) → память возвращается с диска в оперативную память.
• so (swap out) → данные выгружаются из оперативной памяти в swap на диске.

Если значение so постоянно больше 0, это означает, что система испытывает постоянную нехватку памяти и активно выгружает данные в swap.

Если si часто больше 0, значит система регулярно возвращает данные из swap обратно в RAM, что указывает на трудности с восстановлением свободной памяти.

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

# Monitor VmRSS every 5 seconds to check if memory usage is stable or growing
watch -n 5 "cat /proc/<PID>/status | grep VmRSS"

# Output:
VmRSS:   245678 kB

• Стабильное значение → нормальное поведение
• Постоянный рост → вероятный признак утечки памяти или аномального потребления, вызванного тем, что процесс непрерывно выделяет память, не освобождая её, либо увеличением нагрузки или трафика, с которыми система уже не справляется эффективно.

Шаг 6: Примите меры

После того как проблема с памятью подтверждена (высокий VmRSS, использование swap или непрерывный рост потребления памяти), выберите соответствующий способ её устранения, в зависимости от серьёзности проблемы:

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

systemctl restart <service-name>

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

# graceful shutdown (recommended first)
kill <PID>   # allows the process to exit cleanly

# force shutdown (use only if it does not respond)
kill -9 <PID>   # immediately terminates the process

3. Снизьте нагрузку на систему
Снизьте нагрузку, временно освободив память и уменьшив объём выполняемой работы, чтобы система перестала активно использовать swap и вернулась в стабильное состояние.

# Clear cache (temporary relief)
sync; echo 3 > /proc/sys/vm/drop_caches

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

Шаг 7: Предотвратите повторение подобного инцидента

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

1. Найдите первопричину
Цель — определить, почему резко выросло значение VmRSS, почему начала использоваться swap и какие изменения в системе или приложении привели к этому.

# If we know which service is the root cause
# Analyze logs for a specific service
# Goal: find what exactly is wrong with that service
journalctl -u <service-name>

Обратите внимание на:

• Критические ошибки: записи в логах с ERROR, FAILED или FATAL.
• Частые перезапуски: быстро повторяющиеся циклы Restarting, Started или Stopped.
• Системное вмешательство: сообщения OOM killed (нехватка памяти) или ошибки сегментации (segfault).
• Узкие места: предупреждения о превышении времени ожидания или сбои в работе зависимостей.

# If we don’t know which service is the root cause
# Review all system logs leading up to the incident
# Goal: Correlate system-wide events to establish a timeline of the failure.
journalctl --since "2 hours ago" -p 3..0

Обратите внимание на:

• События-триггеры: какой конкретный процесс или развертывание изменились непосредственно перед скачком потребления памяти?
• Каскадные сбои: одновременные ошибки в нескольких независимых сервисах.
• Вмешательства ядра: сообщения Out of memory: Kill process.
• Ограничения ресурсов: предупреждения о проблемах с дисковой подсистемой, высокой нагрузке на CPU или нехватке памяти.

2. Внедрите долгосрочные меры по устранению проблемы

После выявления первопричины примените одно или несколько из следующих постоянных решений:

• На уровне приложения → устраните утечки памяти в коде или оптимизируйте ограничения конфигурации (например, настройте размер кучи Java через параметр -Xmx или лимиты рабочих процессов Apache/Nginx).
• На уровне инфраструктуры → задайте жёсткие ограничения ресурсов с помощью systemd cgroups или лимитов памяти Docker, чтобы один процесс не мог вывести из строя всю систему.
• На уровне мониторинга → настройте предупреждения при использовании памяти на уровне 80%, чтобы вмешиваться до того, как система начнёт активно использовать swap или сработает OOM Killer.

#2. Высокая загрузка CPU

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

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

Шаг 1. Подтвердите загрузку CPU

Загрузка CPU на уровне 100% не всегда означает проблему. Например, пакетная обработка данных может вполне закономерно использовать все доступные ресурсы процессора. Сначала убедитесь, что процессор действительно полностью загружен и что такая нагрузка не является ожидаемой.

# Refresh every 1 second to monitor CPU, memory, and process activity in real time
top -d 1

top - 14:32:15 up 10 days,  3:21,  2 users,  load average: 1.25, 1.10, 0.95
Tasks: 215 total,   1 running, 214 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.5 us,  3.2 sy,  0.0 ni, 83.1 id,  0.8 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :  16000.0 total,   1200.0 free,   9500.0 used,   5300.0 buff/cache
MiB Swap:   2048.0 total,   1800.0 free,    248.0 used

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1234 appuser   20   0   12.5g   4.2g   150m S  85.0 26.3  45:12.31 java
 5678 nginx     20   0  250000  45000  12000 S   2.0  0.3   2:15.04 nginx
 9012 mysql     20   0    3.0g   1.1g   300m S   1.5  6.9 120:45.18 mysqld

Обратите внимание на:

• us (пространство пользователя): > 70% → приложение активно использует ЦП
• sy (пространство ядра): >20% → высокая активность ядра; может указывать на большое количество системных вызовов, интенсивную работу сети или частое переключение контекста.
• wa (ожидание ввода-вывода): > 5% → вероятно, узким местом является дисковая подсистема или сеть, а не процессор.

Шаг 2. Найдите виновника.

Если объем пользовательского пространства (%us) высок, выясните, какое приложение или сервис создаёт основную нагрузку.

# Show the top 20 processes sorted by CPU usage (highest first)
ps aux --sort=-%cpu | head -20

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
appuser   1234 85.2 12.3 12500000 4200000 ?   Sl   10:00  45:12 java
mysql     2345 15.4  6.8  3200000 1100000 ?   Sl   09:30 120:45 mysqld
nginx     3456  2.1  0.3   250000   45000 ?   S    08:00   2:15 nginx
root      4567  1.5  0.1   120000   12000 ?   S    07:00   0:30 systemd
...

Сосредоточьтесь на:

• %CPU → какие процессы потребляют больше всего процессорного времени.
• COMMAND → определите, какое приложение/сервис вызывает нагрузку (наше приложение, база данных или неожиданный процесс).
• TIME → общее время использования CPU. Высокое значение за короткий период жизни процесса может указывать на резкий всплеск нагрузки.
• PID → идентификатор процесса для дальнейшего анализа.
• %MEM → проверьте, не является ли процесс одновременно ресурсоёмким по памяти.

Если системное пространство (%sy) велико, изучите активность ядра, чтобы определить, какие системные вызовы или системные задачи потребляют ресурсы ЦП.

# Show real-time system performance (updated every 1 second)
# Helps identify CPU pressure, context switching, and I/O wait
vmstat 1

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs  us  sy  id  wain   cs  us  sy  id  wa
 1  0  10240  200000  50000 800000    0    5     2     3  120  200   5   3  90   2
 2  0  10240  198000  50000 799000    0    3     0     4  150  250   6   4  88   2

Сосредоточиться на:

• cs (переключения контекста): > 10 000/сек → процессор слишком часто переключается между процессами или потоками, что создаёт дополнительную нагрузку на планировщик задач и может замедлить работу системы.
• in (прерывания): > 10 000/сек → процессор слишком часто обрабатывает аппаратные прерывания (сетевые карты, диски и другие устройства). Высокие значения обычно указывают на интенсивную сетевую активность, работу дисков или проблемы с драйверами.

Шаг 3. Выясните, что стало причиной всплеска нагрузки на CPU

Высокое значение us означает, что большая часть процессорного времени тратится на выполнение кода приложений (в пространстве пользователя, user space). Чтобы определить причину, выясните, какие изменения или условия могли увеличить нагрузку на приложение или снизить его эффективность:

• Не увеличился ли неожиданно объём трафика или количество запросов?
• Не было ли недавно развёртывания новой версии, изменения конфигурации или перезапуска?
• Не зациклился ли процесс, не выполняет ли он чрезмерное количество повторных попыток (retries) или циклов обработки ошибок?
• Не обрабатывает ли приложение необычно большой объём данных (пакетные задания, обработку данных, построение отчётов и т. п.)?

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

• Выполнялись ли в момент всплеска нагрузки какие-либо задания cron?
• Не потребляют ли ресурсы задачи резервного копирования?
• Не устанавливались ли системные обновления примерно в это же время?
• Совпадает ли всплеск загрузки CPU с увеличением активности пользователей?

Шаг 4. Выберите подходящее решение

Проблемы на уровне приложения (высокое us):

• Ожидаемый рост нагрузки → Продолжайте наблюдение и убедитесь, что система остаётся стабильной при штатном масштабировании.
• Всплеск трафика → Масштабируйте приложение по горизонтали (добавьте новые экземпляры) или оптимизируйте обработку запросов и распределение нагрузки.
• Неэффективный код или неверная конфигурация → Выполните профилирование приложения, найдите наиболее затратные участки кода (hot paths) и оптимизируйте их.
• Бесконечный цикл или некорректная логика → Исправьте ошибку и при необходимости перезапустите затронутый процесс.
• Ресурсоёмкая пакетная обработка → Перенесите выполнение на другое время, ограничьте скорость обработки или распределите нагрузку между несколькими узлами.

Проблемы на уровне ядра/системы (высокое sy):

• Высокая активность ввода-вывода (диск/сеть) → Оптимизируйте операции ввода-вывода, используйте кэширование и сократите количество лишних операций чтения и записи.
• Слишком много системных вызовов → Уменьшите чрезмерное количество обращений приложения к ядру и по возможности объединяйте системные операции.
• Интенсивное переключение контекста → Сократите число потоков и процессов, настройте уровень параллелизма.
• Неэффективность ядра или драйверов → Обновите ядро/драйверы и изучите известные проблемы системного уровня.
• Задания Cron, резервное копирование или системные задачи → Измените расписание их выполнения, чтобы избежать конкуренции за ресурсы.
• Резкий скачок трафика, создающий нагрузку на систему → Масштабируйте инфраструктуру и настройте параметры ОС и сети (очереди, буферы, параметры сетевого стека).

Шаг 5. Предотвращение повторных проблем с CPU

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

• Настройте мониторинг и оповещения по CPU → Отслеживайте устойчивые значения us и sy (а не только общую загрузку CPU) и настройте предупреждения до того, как ситуация станет критической.
• Оптимизируйте неэффективный код → Выполните профилирование приложения, устраните наиболее затратные участки, сократите лишние циклы, повторные попытки и тяжёлые вычисления.
• Настройте параметры приложения → Скорректируйте уровень параллелизма, размеры пулов потоков и пулов соединений, чтобы избежать перегрузки процессора.
• Пересмотрите расписание фоновых задач → Разнесите по времени выполнение cron, резервного копирования и пакетных заданий, чтобы избежать предсказуемых пиков нагрузки.
• При необходимости увеличьте ресурсы → Если высокая загрузка CPU стала новой нормой, а не временным всплеском, масштабируйте систему по горизонтали или увеличьте вычислительные ресурсы.

#3. Высокая интенсивность дискового ввода-вывода

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

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

Шаг 1. Подтвердите наличие нагрузки на дисковую подсистему

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

# detailed disk I/O stats, refreshed every 1s (5 times)
iostat -xz 1 5

Device:         rrqm/s   wrqm/s     r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sda               0.00     5.00   120.0    80.0     1.2     3.5     45.00     2.10   15.20    10.50    22.10   2.50  92.30

Сосредоточиться на:

• %util: > 80% → диск сильно загружен (если значение длительное время держится около 100%, это может указывать на насыщение).
• await: SSD > 1 мс, HDD > 10 мс → высокая задержка свидетельствует о медленной обработке операций ввода-вывода.
• r/s и w/s → количество операций чтения и записи в секунду (интенсивность нагрузки).
• rkB/s и wkB/s → объём данных, считываемых и записываемых в секунду (пропускная способность).

Шаг 2. Определите, какие процессы за это отвечают.

# show all processes with I/O activity (accumulated + active only)
iotop -ao

Total DISK READ: 12.34 M/s | Total DISK WRITE: 45.67 M/s
Current DISK READ: 3.21 M/s | Current DISK WRITE: 10.11 M/s
    TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
  1823 be/4  mysql      2.10 M/s    8.30 M/s   0.00 %  95 %    mysqld
  2210 be/4  appuser    0.50 M/s    1.20 M/s   0.00 %  40 %    java -jar app.jar
  1401 be/4  root       0.00 M/s    0.80 M/s   0.00 %  20 %    rsyslogd

Обратите внимание на:

• DISK READ / DISK WRITE → Объём данных, который процесс считывает с диска или записывает на диск в секунду. Ищите процессы с необычно высокой дисковой активностью.
• IO% (или IO>): > 30% → процесс значительную часть времени ожидает завершения операций ввода-вывода. Это означает, что он блокируется дисковой подсистемой.
• COMMAND→ определяет сервис, являющийся источником нагрузки.

Шаг 3. Определите, к каким файлам осуществляется доступ.

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

# list all files opened by a specific process
lsof -p <PID> | grep REG    # Regular files only

java    2210 appuser  5u  REG  8,1  1048576  789 /var/log/app.log
java    2210 appuser  7u  REG  8,1  5242880  912 /opt/app/data.db
java    2210 appuser 12w  REG  8,1   204800  333 /tmp/cache.tmp

Обратите внимание на:

• FD → режим использования файла (r: чтение, w: запись, u: чтение и запись). Большое количество w/u может свидетельствовать об интенсивной записи, большое число FD — о возможной утечке, а постоянный доступ к одним и тем же файлам — о неэффективной работе приложения.
• TYPE → тип ресурса. Обычно основной причиной высокой нагрузки являются обычные REG-файлы (такие как logs/DB/data).
• NAME → путь к файлу. Это наиболее важное поле для определения реального источника дисковой нагрузки.

Шаг 4. Проверьте состояние файловой системы и устройства хранения

Цель этого шага — определить, вызвана ли проблема состоянием диска или нехваткой места, а не работой приложения.

# Shows how much disk space is used on each filesystem and what type it is (ext4, xfs, etc.).
df -hT

# Searches kernel logs for disk and hardware-related errors.
dmesg | grep -i 'error\|I/O error\|reset\|timeout' # Detect failing disks, cables, or controllers

# Reads the internal health data of a physical disk.
smartctl -a /dev/sda  # Detect early hardware degradation

• df -hT → «Не заполнен ли диск?»
• dmesg → «Система сообщает об ошибках диска?»
• smartctl → «Не выходит ли из строя сам накопитель?»

Шаг 5. Проверьте исчерпание инода

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

# show inode usage per filesystem (how many files can still be created)
df -ih

Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 1.2M 1.1M 100K 92% /
/dev/sdb1 2.0M 500K 1.5M 25% /data
tmpfs 250K 50K 200K 20% /run

Обратите внимание на:

• IUse% (процент использования inode): > 90% → использование inode очень высокое. Система может перестать создавать новые файлы (логи, временные файлы, записи баз данных), даже если свободное место на диске ещё есть.

Шаг 6. Примите меры.

После того как причина проблемы определена, выполните соответствующие действия:

• Выявлена ​​проблема → Перезапустите, исправьте или настройте приложение, создающее чрезмерную нагрузку на дисковую подсистему ввода-вывода.
• Интенсивная работа с файлами (логи, базы данных, временные файлы) → Настройте ротацию логов, оптимизируйте доступ к базе данных или очистите временные файлы.
• Файловая система заполнена → Освободите место на диске или увеличьте объём хранилища.
• Исчерпаны inode (IUse% > 90%) → Удалите ненужные мелкие файлы, очистите логи и кэш или увеличьте количество доступных inode.
• Обнаружены ошибки диска или оборудования → Замените или отремонтируйте неисправный накопитель и выясните первопричину аппаратной неисправности.

#4. Медленная работа сети

Медленную работу сети бывает сложно диагностировать, потому что причина не всегда заключается в самой сети. Такие проблемы, как неполадки с DNS, высокая задержка, потеря пакетов, перегрузка сети, правила межсетевого экрана (firewall) или перегруженные приложения, могут сделать приложение медленным.

Многие начинают диагностику с ping, но успешный ответ на ping лишь подтверждает наличие соединения — он не объясняет проблемы с производительностью. Цель — определить, где возникает задержка, и понять, что является первопричиной: клиент, сервер, сетевой маршрут или приложение.

Шаг 1. Исключите задержки DNS.

Часто «медленная сеть» на самом деле оказывается медленным DNS-резолвером. Если разрешение имени занимает 2 секунды, а передача данных — всего 10 миллисекунд, значит сама сеть работает нормально.

# Measure precise DNS resolution time
time dig www.google.com

; <<>> DiG 9.18 <<>> www.google.com
;; ANSWER SECTION:
www.google.com.  300  IN  A  142.250.190.68

real    0m0.045s
user    0m0.010s
sys     0m0.005s

Обратите внимание на real (общее время разрешения DNS):

• < 50 мс → Быстрый DNS
• 50–200 мс → Приемлемо
• 200–500 мс → Медленный DNS
• > 1 с → Вероятная проблема с DNS

Шаг 2. Проверьте загрузку и ошибки локального сетевого интерфейса.

Убедитесь, что локальная сетевая карта (NIC) не теряет пакеты и не упирается в предел своей пропускной способности.

# View live network throughput across all interfaces
ip -s link

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    RX: bytes    packets   errors   dropped
    1256347890   1543210   0        12

    TX: bytes    packets   errors   dropped
    987654321    1321456   0        5

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

# Monitor real-time interface statistics (refreshes every 1 second)
sar -n DEV 1

12:00:01 AM IFACE   rxkB/s   txkB/s
12:00:01 AM eth0     1250      980
12:00:02 AM eth0     1305     1024
12:00:03 AM eth0     1288      995

Следите за rxkB/s - входящим и txkB/s - исходящим сетевым трафиком: если значения длительное время близки к максимальной пропускной способности интерфейса, это может свидетельствовать о перегрузке сети.

Шаг 3. Определите источники сетевой нагрузки

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

# show top remote connections grouped by IP:port and TCP state
ss -tnp | awk '{print $5, $6}' | sort | uniq -c | sort -rn | head -20

150 10.0.0.5:443 ESTAB
120 10.0.0.8:443 ESTAB
 90 10.0.0.12:443 TIME-WAIT
 40 10.0.0.15:443 SYN-RECV
 25 10.0.0.20:443 CLOSE-WAIT

Обратите внимание на:

• SYN-RECV (Соединения, ожидающие завершения TCP-рукопожатия) → Большое количество может указывать на SYN-флуд, проблемы балансировщика нагрузки или сети.
• TIME-WAIT (недавно закрытые соединения) → Высокое количество соединений может наблюдаться во время пиков трафика или при работе приложений, создающих множество кратковременных соединений.
• CLOSE-WAIT (удалённое соединение закрыто, локальное ещё нет) → Высокие значения обычно указывают на проблему в приложении (утечке соединений или отсутствии корректного закрытия).

Шаг 4. Проверьте общую нагрузку на сокеты

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

ss -s

Total: 1200
TCP:   900 (estab 600, closed 150, orphaned 0, timewait 120)

Transport Total     IP        IPv6
RAW       1
UDP       50
TCP       900
INET      951

Команда выводит сводную статистику по состояниям сокетов. Обратите внимание на:

• Очень высокий показатель ESTAB → высокий сетевой трафик или приложение с большим количеством активных соединений;
• Очень высокий показатель TIME-WAIT → множество короткоживущих соединений или отсутствие повторного использования соединений;
• Ненулевое значение ORPHANED → Проблема обработки сокетов приложения

Шаг 5. Сбор и анализ трафика.

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

# capture 200 TCP packets on port 443 (HTTPS)
tcpdump -i eth0 -n -c 200 'tcp port 443'

12:01:01.123 IP 10.0.0.5.52344  > 10.0.0.12.443: Flags [S], seq 12345, win 64240
12:01:01.124 IP 10.0.0.12.443   > 10.0.0.5.52344: Flags [S.], seq 67890, ack 12346
12:01:01.125 IP 10.0.0.5.52344  > 10.0.0.12.443: Flags [.], ack 67891


# S → connection start (SYN)
# S. → SYN-ACK (handshake response)
# . → established data transfer
# F → connection close

Обратите внимание на:

• Повторяющиеся SYN-пакеты (только S) → неудачные попытки подключения (возможно, флуд, блокировка брандмауэром или сбой рукопожатия)
• Повторная передача SYN-пакета → повторная попытка клиента из-за отсутствия SYN-ACK (потеря пакета, перегрузка сети или нестабильность сети)
• Нет ответа SYN-ACK → сервер не отвечает или трафик блокируется
• Много кратковременных соединений (быстрое S → F) → неэффективная обработка соединений или высокая текучесть соединений.
• Повторная передача / дублирование подтверждений → потеря пакетов, перегрузка сети или ухудшение качества сети.
• Доминирование одного IP-адреса в трафике → всплеск трафика, неправильно настроенный клиент или возможная атака.

Шаг 6. Проверьте исчерпание таблицы отслеживания соединений (на хостах NAT/брандмауэра).

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

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

Если значение count близко к max, новые соединения будут незаметно разрываться.

Шаг 7. Примите меры.

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

• Задержки DNS → смените DNS-резолвер, исправьте конфигурацию DNS или настройте более эффективное кэширование.
• Перегрузка или ошибки сетевого интерфейса → уменьшите объём трафика, увеличьте пропускную способность или устраните проблемы с сетевой картой и оборудованием.
• Высокая сетевая нагрузка → ограничьте скорость для клиентов (rate limiting), оптимизируйте запросы или масштабируйте сервисы.
• Перегрузка сокетов (TIME-WAIT, CLOSE-WAIT и т.д.) → настройте обработку соединений в приложении или устраните утечки соединений.
• Потеря пакетов, повторные передачи, ошибки SYN → проверьте правила firewall, маршрутизацию и устраните перегрузку сети.
• Исчерпание conntrack → увеличьте лимиты или уменьшите количество создаваемых соединений.
• Проблемы на уровне приложения → оптимизируйте повторные попытки запросов, повторно используйте соединения и устраните неэффективные сетевые вызовы.

#5. Высокий показатель средней нагрузки (Load Average)

Высокая средняя загрузка не обязательно означает высокую загрузку ЦП (различие, которое многие упускают из виду). Средняя загрузка измеряет количество процессов, которые либо выполняются на процессоре, либо ожидают доступа к ресурсам, таким как процессорное время или дисковый ввод-вывод. В результате система может иметь высокую среднюю загрузку, даже если загрузка ЦП кажется низкой.

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

Шаг 1. Подтвердите среднюю загрузку.

Для начала проверьте текущую нагрузку.

# show system uptime and load average (1, 5, and 15 minutes)
uptime

14:32:18 up 25 days,  4:17,  2 users,  load average: 2.15, 1.87, 1.42

# 2.15 → average load over the last 1 minute
# 1.87 → average load over the last 5 minutes
# 1.42 → average load over the last 15 minutes

Сравните среднюю загрузку процессора с количеством ядер процессора:

• Загрузка ≈ ядер CPU → система полностью загружена
• Загрузка > ядер CPU → процессы ожидают ресурсов
• Загрузка < ядер CPU → у системы есть запас производительности

Шаг 2. Разграничьте нагрузку на CPU и нагрузку на ввод-вывод.

Средняя загрузка процессора — это не только использование CPU. Она включает в себя процессы, работающие на CPU, и те, которые ожидают ресурсов, таких как операции ввода-вывода на диске. Высокая средняя загрузка может указывать на перегрузку CPU, узкие места в операциях ввода-вывода или и то, и другое.

# show CPU, memory, and I/O activity every 1 second (5 times)
vmstat 1 5

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa stin   cs us sy id wa st
 2  0      0 512000  45000 820000    0    0     5    10  120  300 25  5 70  0  0
 8  3      0 500000  45000 820000    0    0  1200  800  500 1200 20 10 30 40  0

В центре внимания: r (процессы, ожидающие загрузки CPU), b (процессы, заблокированные, обычно ожидающие операций ввода-вывода), wa (время CPU, затраченное на ожидание операций ввода-вывода), us / sy (нагрузка CPU приложения/системная нагрузка).

• Высокая r (> количества ядер CPU) + высокая us/sy (us + sy > 70%) → загрузка ЦП
• Высокий b (> 1) + высокий wa( wa > 10%) → нагрузка ввода/вывода
• Высокое значение r (> количество ядер CPU) + низкое значение us/sy ( us + sy < 50%) → Наиболее вероятно - время ожидания ввода-вывода (подтвердите, проверив значение wa > 10% и/или ненулевое значение b)

Если проблема связана с загрузкой CPU, следуйте алгоритму действий при высокой загрузке CPU.
Если проблема связана с загрузкой ввода-вывода, следуйте алгоритму действий при высокой нагрузке на дисковый ввод-вывод.
Если проблема связана с ожиданием ввода-вывода, следуйте алгоритму действий при высокой нагрузке на дисковый ввод-вывод.

#6. Сервис не запускается

Отказ сервиса запускаться — одна из самых распространённых эксплуатационных проблем в Linux. Типичная реакция — снова и снова выполнять systemctl restart в надежде, что проблема исчезнет. Иногда это помогает. Но чаще всего — нет.

Цель — определить, почему сервис не смог запуститься, устранить первопричину и безопасно восстановить его работу.

Шаг 1. Подтвердите сбой.

# Show service state, recent logs, and start/stop status
systemctl status <service>

● nginx.service - A high performance web server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
   Active: failed (Result: exit-code) since Thu 2026-06-25 10:15:12
  Process: 2210 ExecStart=/usr/sbin/nginx (code=exited, status=1/FAILURE)

Jun 25 10:15:12 server nginx[2210]: nginx: [emerg] bind() to 0.0.0.0:80 failedbind() to 0.0.0.0:80 failed
Jun 25 10:15:12 server systemd[1]: nginx.service: Failed to start

• Активное состояние
  active (running) → всё в порядке
  failed → сервис не запускается
  inactive → сервис остановлен
• ExecStart error → показывает причину, по которой произошёл сбой при запуске
• Строки логов (внизу) → указывают на первопричину (конфликт портов, ошибка конфигурации, проблема с правами доступа)

Шаг 2. Просмотрите логи

Логи обычно позволяют быстрее всего найти первопричину.

# Shows recent logs with errors and explanations
journalctl -u <service-name> -xe --no-pager

-- Logs begin at Thu 2026-06-25 --
Jun 25 10:15:12 systemd[1]: Starting My Application Service...
Jun 25 10:15:12 myapp[2210]: ERROR: Failed to load configuration file /etc/myapp/config.yaml
Jun 25 10:15:12 systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
Jun 25 10:15:12 systemd[1]: myapp.service: Failed with result 'exit-code'.'exit-code'.
Jun 25 10:15:12 systemd[1]: Failed to start My Application Service.

Обратите внимание на:

• сообщения об ошибках ( emerg, error, failed) → непосредственная причина сбоя сервиса
• ошибки привязки/порта → порт уже используется
• ошибки прав доступа → отсутствует доступ к файлу или каталогу
• Сбои в работе зависимостей → необходимый сервис не запущен.

Шаг 3. Проверьте конфигурацию

Некорректная конфигурация — одна из самых частых причин, по которым сервис не запускается. Многие сервисы имеют встроенную команду проверки конфигурации, поэтому всегда выполняйте её перед перезапуском сервиса или применением изменений.

# test Nginx configuration for syntax errors
nginx -t

# test Apache configuration
apachectl configtest

# HAProxy syntax check
haproxy -c -f /etc/haproxy/haproxy.cfg

# SSH configuration test (syntax check only)
sshd -t

Если у сервиса нет встроенной команды проверки, вручную запустите исполняемый файл сервиса из командной строки, используя те же аргументы, которые указаны в unit-файле systemd.

# shows the full unit file including ExecStart
systemctl cat <service-name>

# /lib/systemd/system/nginx.service
[Unit]
Description=A high performance web server

[Service]
Type=forking
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -s reload
ExecStop=/bin/kill -s QUIT $MAINPID

[Install]
WantedBy=multi-user.target

Обратите внимание на:

• ExecStart= → точная команда, используемая для запуска сервиса;
• ExecReload/ExecStop → как сервис перезагружается и останавливается;
• Дополнительные параметры (если присутствуют) → пользовательские переопределения, которые могут изменять поведение по умолчанию.

Шаг 4. Проверьте зависимости

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

# show all required and optional dependencies
systemctl list-dependencies <service>

myapp.service
● ├─network.target
● ├─mysql.service
● ├─redis.service
● ├─system.sliceslice
● └─basic.target

Обратите внимание на:

• Обязательные сервисы (например, mysql.service, redis.service) → они должны быть активны, иначе сервис не запустится.

# check if a specific dependency is running
systemctl status <dependency-service>

• network.target → сеть должна быть доступна до запуска сервиса.

Шаг 5. Проверьте наличие конфликтов портов

Если в логах указано "Address already in use" или "Failed to bind", это означает, что другой процесс уже прослушивает сетевой порт, который требуется вашему сервису.

# Identify which process is holding the target port (e.g., port 80)
ss -tulpn | grep :80

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

Шаг 6. Проверьте права доступа и владельцев файлов

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

# Verify the user/group assigned to the service
systemctl show <service-name> -p User,Group

# Verify ownership of the service's critical directories
ls -ld /var/log/<service-name> /var/lib/<service-name> /etc/<service-name>

Если во время ручной диагностики файлы были случайно изменены или созданы от имени root, восстановите правильного владельца:

# change ownership of service data directory to correct user and group
chown -R <service-user>:<service-group> /var/lib/<service-name>

Шаг 7. Проверьте системные ресурсы

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

# check CPU and memory usage
top

# check available memory and swap usage
free -h

# check disk space availability
df -h

# check process/resource limits
ulimit -a

Обратите внимание на:

• высокое потребление памяти / недостаток свободной оперативной памяти → сервис может завершаться или не пройти инициализацию.
• высокая загрузка ЦП → запуск может быть медленным или завершаться ошибкой;.
• диск заполнен (100%) → сервис не сможет записывать логи или временные файлы;
• слишком низкие лимиты файловых дескрипторов или других ресурсов → сервис не сможет открыть необходимые файлы или сокеты.

Шаг 8. Запустите сервис и убедитесь, что он работает

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

# start the service
systemctl start <service-name>

# verify service is active and running
systemctl status <service-name>

# check logs if service still fails or behaves unexpectedly
journalctl -u <service-name> -xe --no-pager

#7. Исследование процесса

Каждое приложение, работающее в Linux, является процессом. Понимание жизненного цикла процесса — одна из фундаментальных основ эффективного администрирования систем. Многие инженеры знают отдельные команды, такие как ps, kill или systemctl, однако устранение проблем, связанных с процессами, требует понимания всего жизненного цикла — от создания процесса до его завершения.

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

Шаг 1. Найдите процесс

# Search for a running process by name
ps aux | grep <process-name>

root      2210  2.5  1.2  450000 50200 ?  Sl  10:15   0:08 nginx: master process
www-data  2211  1.1  0.8  451200 34120 ?  S   10:15   0:03 nginx: worker process

Обратите внимание на PID(например, 2210, 2211) → уникальный идентификатор процесса, который используется в последующих командах для исследования, мониторинга или управления процессом.

Шаг 2. Исследуйте процесс

После того как PID найден, исследуйте процесс, чтобы понять его текущее состояние и поведение.

# Show detailed information for a specific process
ps -o pid,ppid,state,%cpu,%mem,etime,cmd -p <PID>

  PID  PPID S %CPU %MEM     ELAPSED CMD
 2210     1 S  2.5  1.2     02:15:43 nginx: master process

Обратите внимание на:

• PPID: 1 → идентификатор родительского процесса.
• STATE ( S):
  R → выполняется (Running)
  S → спящий (Sleeping)
  D → непрерываемый сон (ожидание I/O)
  Z → процесс-зомби (Zombie)
• %CPU: 2.5 → текущее использование CPU
• %MEM: 1.2 → текущее использование памяти
• ELAPSED: 02:15:43 → как долго длится этот процесс
• CMD: nginx: master process → команда, которой был запущен процесс.

Шаг 3. Проверьте ооткрытые файлы и сетевые соединения

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

# List all open files and network connections for the process
lsof -p <PID>

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
nginx   2210 root  cwd    DIR  8,1      4096       2 /
nginx   2210 root  txt    REG  8,1   1260032  393298 /usr/sbin/nginx
nginx   2210 root    3r   REG  8,1    524288 1048576 /etc/nginx/nginx.conf
nginx   2210 root    6w   REG  8,1   1048576 2097152 /var/log/nginx/error.log
nginx   2210 root    7u  IPv4  45678       0     TCP 0.0.0.0:80 (LISTEN)
nginx   2210 root    8u  IPv4  45679       0     TCP 192.168.1.10:80->192.168.1.20:52314 (ESTABLISHED)

Обратите внимание на:

• FD
r → чтение
  w → запись
  u → чтение и запись
• TYPE
REG → обычный файл
  DIR→ каталог
  IPv4/ IPv6 → сетевой сокет
• NAME
  Путь к файлу → указывает, к каким файлам обращается процесс
  LISTEN → ожидание входящих соединений
  ESTABLISHED → активное сетевое соединение

Шаг 4. Просмотрите логи

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

# Show all logs for a specific systemd service
journalctl -u <service>

Обратите внимание на:

• Сообщения ERROR / FAIL → непосредственная причина сбоя;
• последовательность запуска (Startup sequence) → что происходило до сбоя;
• ошибки конфигурации или прав доступа → наиболее распространённые причины;
• коды завершения (Exit codes) → причина остановки сервиса.

Шаг 5. Примите соответствующее решение

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

• Ошибка конфигурации → исправьте конфигурационный файл, затем повторно выполните проверку и перезапустите сервис.
• Сбой зависимостей → запустите или восстановите отсутствующую зависимость (БД, сеть, точку монтирования).
• Конфликт портов → остановите конфликтующий процесс или измените порт сервиса.
• Проблема с правами доступа → исправьте владельца или права (chown, chmod).
• Проблема с ресурсами → освободите место на диске или память либо скорректируйте системные лимиты.
• Сбой/неизвестная проблема → изучите более подробные логи и выполните отладку в фоновом режиме.

Не завершайте процесс, пока не поймёте его назначение и влияние на зависящие от него сервисы.

#8. Процесс не завершается

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

Шаг 1. Корректное завершение

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

# Request polite termination (SIGTERM - Signal 15)
kill -15 <PID>

Альтернатива для многопроцессных приложений: если главный процесс создал несколько рабочих процессов (например, Apache, Nginx или PHP-FPM), используйте pkill, чтобы отправить сигнал всей группе процессов по имени:

# Safely request all processes matching the name to stop
pkill -15 -f <process-name>

Шаг 2. Принудительное завершение.

Этот способ немедленно завершает процесс, не позволяя ему выполнить очистку ресурсов.

# Force termination via the kernel (SIGKILL - Signal 9)
kill -9 <PID>

Шаг 3: Проверьте состояние процесса

Если kill -9 не удалил процесс из вывода ps или top, значит процесс находится в состоянии, в котором он не может принимать сигналы.

# show process state, wait channel, and command
ps -o pid,stat,wchan,comm -p <PID>

PID STAT WCHAN  COMMAND
 2210 D    0      java

Обратите внимание на STAT:

• D → процесс находится в непрерываемом сне (Uninterruptible Sleep), обычно ожидая завершения операций ввода-вывода (диск, NFS или другое хранилище). Такой процесс нельзя завершить, пока операция ввода-вывода не завершится.
• Z → процесс-зомби (Zombie). Он уже завершил выполнение, но всё ещё присутствует в таблице процессов, потому что родительский процесс ещё не получил его статус завершения.

Шаг 4. Выполните необходимые действия

Процесс находится в состоянии D (непрерываемый сон).
Если в столбце STAT отображается D, процесс ожидает завершения операций ввода-вывода на уровне ядра.

# Shows what kernel function the process is currently waiting on (if any)
cat /proc/<PID>/wchan

• blk_mq_get_tag → ожидание очереди блочного устройства (узкое место дисковой подсистемы)
• io_schedule → ожидание планировщика ввода-вывода
• nfs_* → задержка сетевой файловой системы

Для решения этой проблемы необходимо определить и устранить узкое место в подсистеме хранения или сетевой файловой системе: уменьшить нагрузку на I/O, исправить проблемы с диском или NFS либо остановить процесс, создающий чрезмерную нагрузку. Если подсистема хранения полностью перестала отвечать, последним средством остаётся перезагрузка системы.

Процесс в состоянии Z (зомби)
Если в столбце STAT отображается Z, значит, процесс уже завершил выполнение, но всё ещё присутствует в таблице процессов.

# Find the parent process
ps -o ppid= -p <PID>

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

#9. Дисковое пространство заполнено

Заполненный диск — один из самых распространённых инцидентов в Linux. Первая реакция — обычно выполнить df -h, чтобы убедиться, что файловая система заполнена. Но эта команда лишь показывает, где находится проблема, а не что именно занимает место.

Цель состоит в том, чтобы определить, что использует дисковое пространство, понять, является ли рост использования ожидаемым или аномальным, и безопасно освободить место, не вызвав дополнительных проблем.

Шаг 1. Определите затронутую файловую систему

Для начала определите, какая файловая система заканчивает свободное место.

# Show disk usage in human-readable format
df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   45G   2.0G  96% /
/dev/sdb1       200G  120G   80G   60% /data
tmpfs            3.9G     0  3.9G    0% /run

Обратите внимание на:

• Use% → процент использования
• Mounted on → где файловая система смонтирована в системе.

Шаг 2. Найдите самые большие каталоги

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

# Shows which top-level directories consume disk space (e.g., /)
du -xh / --max-depth=1 2>/dev/null | sort -h

4.0K    /proc
120M    /boot
600M    /home
1.2G    /usr
2.5G    /var
8.0G    /opt
15G     /

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

Распространённые причины проблем в производстве:

• /var/log/ → логи, которые не ротируются, или приложение пишет чрезмерно подробные (debug) логи.
• /var/lib/docker/ → неиспользуемые слои контейнеров, "висящие" (dangling) тома или большие кэши сборки.
• /tmp/ → забытые дампы памяти (core dumps) или неочищенные временные файлы, загруженные приложениями.

Шаг 3. Найдите большие файлы

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

# Search for files larger than 500MB within a specific mounted filesystem/directory
find <mount_point> -type f -size +500M

# find /var/lib -type f -size +500M
/var/lib/mysql/ibdata1
/var/lib/mysql/mysql-bin.000012
/var/lib/docker/overlay2/sha256-layer/layer.tar

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

Шаг 4. Проверьте удалённые файлы, которые всё ещё используются

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

# Show files that are deleted but still held open by processes
lsof | grep deleted

nginx   2210 root  6w   REG  8,1  104857600 /var/log/nginx/access.log (deleted)
java    3321 app   12u  REG  8,1  524288000 /tmp/cache.tmp (deleted)

Если удалённый файл всё ещё открыт, перезапуск процесса, которому он принадлежит, может освободить занимаемое пространство.

Шаг 5. Определите причину

Прежде чем что-либо удалять, разберитесь, почему диск оказался заполнен.

• Не сработала ротация логов?
• Приложение генерирует слишком много логов?
• Недавно была создана резервная копия?
• База данных растёт ожидаемым образом?
• Пользователь загрузил большой объём данных?

Устранение симптома без устранения причины часто приводит к повторению того же инцидента.

Шаг 6. Безопасно освободите пространство

В зависимости от результатов анализа можно:

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

Избегайте бездумного удаления файлов, особенно в каталогах /var, /etc или каталогах с данными приложений.

Безопасная экстренная очистка

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

# Clean up systemd journal logs older than 3 days
journalctl --vacuum-time=3d

# Safely purge unused Docker containers, networks, and dangling images
docker system prune -f

# Clean package manager repository caches (Ubuntu/Debian)
apt-get clean

#10. Исчерпание inode

Иногда df -h показывает, что свободного места на диске достаточно, но приложения всё равно выдают ошибку No space left on device. Это означает, что закончились иноды (индексные узлы метаданных).

Шаг 1. Подтвердите исчерпание инода.

# Check inode utilization instead of block storage
df -i

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1      3276800 3200000  76800   98% /
/dev/sdb1     13107200  500000 12607200   4% /data
tmpfs          1000000     120   999880   1% /run

Обратите внимание на IUse% (процент использования inode):

• < 80% → норма
• 80–90% → предупреждение
• > 90% → высокий риск
• ~100% → исчерпание inode (невозможно создать новые файлы)

Шаг 2. Найдите каталоги, содержащие слишком большое количество файлов

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

# Find which directories consume most inodes
du -x --inodes / | sort -nr | head -n 10

1200000  /var
950000   /var/lib
600000   /var/log
450000   /home
300000   /var/cache
120000   /usr
80000    /tmp
50000    /opt
30000    /run
10000    /etc

Этот вывод показывает, какие каталоги используют больше всего inode (нагрузка по количеству файлов), а не дискового пространства.

Шаг 3. Перейдите к каталогам с большим количеством файлов.

# Narrow down inode-heavy subdirectories
du -x --inodes /var | sort -nr | head -n 10

800000   /var/log
500000   /var/lib
300000   /var/lib/docker
250000   /var/cache
120000   /var/spool
80000    /var/tmp
50000    /var/www
20000    /var/backups
15000    /var/mail
10000    /var/run

Что это нам говорит:

• /var/log → взрывной рост логов (очень распространённая проблема с inode)
• /var/lib/docker → слои контейнеров / образы / файлы overlay
• /var/cache → накопление кэша (менеджеры пакетов, приложения)
• /var/spool → задания в очереди (почта, печать, cron)

Эти данные помогают точно определить, какие подкаталоги внутри /var потребляют больше всего inode, позволяя выполнить целевую очистку вместо того, чтобы действовать наугад.

Шаг 4. Определите источник увеличения размера файлов

# Inspect directories likely generating many small files
find /var/log -type f | head

/var/log/syslog
/var/log/auth.log
/var/log/kern.log
/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/journal/abcd1234/system.journal
/var/log/mysql/error.log
/var/log/apt/history.log
/var/log/dpkg.log
/var/log/faillog

Эта команда позволяет быстро просмотреть структуру файлов логов, помогая определить, в каком направлении углубить анализ проблем с inode или использованием диска.

Шаг 5. Исправьте проблему и выполните очистку

Очистка логов / ротация:

logrotate -f /etc/logrotate.conf

Удалите безопасные временные файлы:

rm -rf /tmp/*
rm -rf /var/tmp/*

Исправление на уровне сервиса:

• перезапустить шумный сервис
• исправить конфигурацию логирования
• снизьте скорость генерации файлов

Шаг 6. Проверьте восстановление

# confirm inode usage dropped
df -i

# 11. Сервер работает медленно

«Сервер работает медленно» — один из самых распространённых и при этом наименее конкретных инцидентов, с которыми мы сталкиваемся. Он не указывает на какую-то одну проблему. Первой реакцией часто становится подключение к серверу по SSH и запуск top. Хотя это вполне разумная отправная точка, она показывает лишь часть общей картины.

Цель — определить, какая подсистема вызывает замедление, локализовать узкое место и устранить первопричину, а не действовать наугад.

Шаг 1. Проверьте возможные причины

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

• CPU → высокая загрузка или ресурсоёмкие процессы
• Память → Высокое использование оперативной памяти или swap
• Диск → высокий дисковый I/O, высокая задержка или недостаток свободного места на диске

# Display a one-time snapshot of CPU, memory, load average, and top resource-consuming process
top -b -n 1

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

• Средняя загрузка: > количества ядер CPU → Высокая средняя загрузка
• %CPU (us + sy): > 90% → Высокая загрузка CPU
• Доступная память: < 20% → Нехватка памяти

Шаг 2. Определите дальнейшие действия

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

• Высокая средняя загрузка → Сценарий при высокой средней загрузке
• Высокая загрузка CPU (>90%) → Сценарий высокой загрузки CPU
• Мало доступной памяти (<20%) → Сценарий диагностики высокой средней нагрузки

Если средняя загрузка, CPU и память в норме, проверьте другие параметры.

• Сеть работает медленно.
• Дисковое пространство заполнено

Шаг 3. Проверьте последние изменения.

Если ничего очевидного не обнаруживается, выясните, что изменилось.

# Focus on recent system logs 
# to check errors, service failures, or anomalies in the last 30 minutes
journalctl -S "30 minutes ago"

Найдите наиболее распространённые причины медленной работы сервера в логах:

• Изменения сервисов: Started, Stopped, Restarting, Reloaded
• Ошибки и сбои: ERROR, failed, failure, crash
• Проблемы производительности: timeout, slow, took too long, delayed
• Проблемы с ресурсами: Out of memory, OOM killer, No space left on device
• Нестабильность системы: kernel, panic, soft lockup, hang
• Проблемы сети: connection refused, reset, timed out

Шаг 4. Проверьте приложение

Если сервер выглядит исправным, сосредоточьтесь на уровне приложений.

• Проверьте логи приложения → найдите ошибки, исключения, тайм-ауты.
• Проверьте состояние сервиса → убедитесь, что процессы приложения запущены и не перезапускаются/не завершаются с ошибкой.
• Проверьте время отклика → медленные API, конечные точки с высокой задержкой.
• Производительность базы данных → Медленные запросы, блокировки, ограничения на количество подключений
• Недавние развертывания/изменения конфигурации → новый код, конфигурация или feature flags, вызывающие замедление
• Внешние зависимости → превышение времени ожидания при вызовах API, сервисов или сторонних сервисов
• Ограничения на количество потоков/соединений → Исчерпаны рабочие потоки или пулы соединений

Универсальный алгоритм устранения неполадок в Linux

Независимо от типа полученного оповещения (медленная работа сервера, высокая загрузка ЦП, проблемы с памятью или сбой сервиса), расследование обычно следует следующей закономерности:

Alert
  │
  ▼
Identify affected resource
(CPU, Memory, Disk, Network, Service)
  │
  ▼
Find the top consumer
  │
  ▼
Collect evidence
(top, vmstat, iostat, ss, journalctl)
  │
  ▼
Determine root cause
  │
  ▼
Apply a fix
  │
  ▼
Verify and monitor

Всегда используйте подход system → changes → application → root cause, который помогает избежать догадок и обеспечивает быструю и структурированную диагностику неисправностей каждый раз.

Заключительные мысли

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

В действительности опытные инженеры подходят к решению проблем иначе. Они не начинают с вопроса: «Какую команду мне выполнить?». Они начинают с вопроса: «Что именно я пытаюсь найти?». Когда цель ясна, выбрать правильную команду становится гораздо проще. Сценарии предоставляют воспроизводимый процесс исследования проблем независимо от того, какие инструменты доступны.

Опытные инженеры часто превращают часто используемые последовательности команд в псевдонимы (aliases), функции оболочки (shell functions) или небольшие shell-скрипты. Это уменьшает количество повторяющегося ввода, стандартизирует процесс расследования и позволяет сосредоточиться на анализе результатов, а не на запоминании команд.

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