Быстрый поиск строк в логах: ripgrep

Когда на сервере гигабайты логов, а надо срочно найти конкретную ошибку, стандартный grep начинает тормозить.

Здесь помогает ripgrep (rg) — современный инструмент поиска по тексту. 

Он оптимизирован под большие объёмы данных и работает в разы быстрее.

Пример для поиска ошибок во всех логах:

rg "ERROR" /var/log

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

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

rg -C 3 "FATAL" /var/log/postgresql

Так выводятся три строки до и после совпадения — удобно при анализе логов PostgreSQL, Nginx или системных журналов.

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

rg -t sql "SELECT.*FROM" /var/log

Вывод ограничится только SQL-логами.

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает механизм Copy-on-Write (CoW) в Linux и зачем он нужен?

✅Ответ: Copy-on-Write (CoW) — это оптимизационный механизм, который позволяет нескольким процессам совместно использовать одну и ту же область памяти до тех пор, пока один из них не попытается ее изменить.

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

BGP PIC (Prefix Independent Convergence)

BGP PIC ускоряет failover, предустанавливая резервный next-hop. 

При падении primary hop трафик мгновенно переключается без полной перерасчётки маршрутов. Обычно обычный BGP failover занимает секунды, с PIC — миллисекунды.

Применяется в WAN и датацентрах с критическим SLA, ECMP-сценариях, L3VPN/EVPN.

Виды:

⏺Core (по префиксу) — precomputed backup next-hop в FIB, переключение мгновенное.
⏺Edge (по соседу) — резерв на уровне BGP-соседа, удобно для PE/CE.

Настройка на Cisco IOS-XR:

router bgp 65001
 address-family ipv4 unicast
  bgp bestpath pic
  network 10.0.0.0 mask 255.255.255.0

Juniper JunOS:

protocols {
 bgp {
  group IBGP {
   type internal;
   local-address 192.168.0.1;
   family inet { unicast; }
   pic;
  }
 }
}

Для проверки failover включают BFD, пингуют primary hop и отключают линк. С BGP PIC потеря пакетов минимальна, трафик идёт на backup сразу.

⚡️Особенности: резервный next-hop должен быть в FIB, потребляет RAM/CPU для precompute, на больших таблицах BGP может потребоваться tuning.

Инкрементальные бэкапы с tar

Помимо привычных архивов, tar умеет делать инкрементальные бэкапы через ключ --listed-incremental.

Он хранит «снимок» метаданных файлов и при следующем запуске берёт только изменения.

Пример:

# первый полный бэкап
tar --listed-incremental=/var/backups/snapshot.file \
    -czf full-backup.tar.gz /home

# инкрементальный
tar --listed-incremental=/var/backups/snapshot.file \
    -czf incr-backup.tar.gz /home

👉 snapshot.file — база, где хранится информация о прошлых бэкапах. Если её удалить, то следующий архив будет снова полным.

Плюсы:
➕экономия места (в архив попадают только изменившиеся файлы);
➕встроено в стандартный tar, не нужны отдельные утилиты;
➕можно комбинировать с cron и хранением на удалённом сервере.

Подходит для небольших серверов, dev-сред и домашних каталогов, где не нужна тяжёлая система бэкапов, но важна скорость и простота.

etckeeper: контроль версий для /etc

Каталог /etc — сердце системы: здесь лежат конфиги сервисов, сетевые настройки, права доступа. 

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

⏺etckeeper решает задачу просто: сохраняет /etc в Git (или другом VCS). Получаем историю изменений, удобный diff и возможность быстро откатить.

Установка (Debian/Ubuntu):

sudo apt install etckeeper git
sudo etckeeper init
sudo etckeeper commit "init"

После этого можно работать как с обычным репозиторием:

sudo git status /etc
sudo git diff /etc/ssh/sshd_config
sudo git log /etc

Фишка — etckeeper интегрируется с apt и yum: перед обновлением пакетов он автоматически делает commit.

Можно добавить git remote и пушить историю в отдельный репозиторий (например, на приватный GitLab или в backup).

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

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое SoftIRQ в Linux и зачем он используется?

✅Ответ: SoftIRQ (Software Interrupt Request) — это механизм в ядре Linux для обработки отложенных задач, которые нельзя выполнить в контексте аппаратного прерывания (IRQ), но и запускать как обычные процессы слишком дорого.

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

Swap-файл vs swap-раздел: как влияет на SSD и работу в системах с малым ОЗУ

На слабых серверах и миниатюрных VPS наличие подкачки решает всё. Даже базовая установка apt без swap может закончиться «убийством» процессов через OOM-killer.

Но что выбрать: swap-файл или swap-раздел? И главное — как сделать, чтобы не угробить SSD и не словить тормоза?

Что выбрать — swap-файл или swap-раздел?

Swap-раздел исторически считался более «надёжным» вариантом: он выделяется на физическом уровне и не фрагментируется. Но в реальности:
⏺менять его размер сложно (особенно без LVM);
⏺требует переформатирования или изменения разметки;
⏺неудобен в облаках и на VPS.

Swap-файл — более гибкий и удобный. Особенно если:
⏺вы работаете на облаке с единственным диском;
⏺у вас ограниченное место;
⏺нужно быстро изменить размер или выключить swap.

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

Как правильно создать swap-файл

Не используйте dd — он может создать фрагментированный файл:

# Плохо:
dd if=/dev/zero of=/swapfile bs=1M count=1024

Вместо этого:

# Хорошо:
fallocate -l 1G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

В fstab:

/swapfile none swap sw 0 0

Дополнительные улучшения: zswap и zram

Чтобы продлить срок службы SSD и ускорить работу на слабых системах:

Zswap — сжатая подкачка в RAM. Включается одной командой:

echo 1 > /sys/module/zswap/parameters/enabled

Zram — компрессированный swap в памяти. Особенно эффективен на embedded и ARM-устройствах:

modprobe zram
echo lz4 > /sys/block/zram0/comp_algorithm
echo 512M > /sys/block/zram0/disksize
mkswap /dev/zram0
swapon /dev/zram0

Настройка поведения подкачки

Чтобы система не бросалась в swap при любой нагрузке:

sysctl vm.swappiness=10

10–20 — хороший баланс: сначала используется RAM, и только потом swap.

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое Writeback в Linux и как он влияет на производительность системы?

✅Ответ: Writeback — это процесс записи изменённых (dirty) страниц памяти обратно на диск. Когда приложение изменяет данные в памяти, они сначала остаются в RAM для ускорения работы, а ядро периодически переносит их на постоянное хранилище.

Система управляет writeback через параметры vm.dirty_ratio и vm.dirty_background_ratio, а также через демоны pdflush или flush. Правильная настройка writeback снижает задержки при записи, предотвращает перегрузку диска и балансирует использование оперативной памяти и I/O.

capsh и Linux capabilities

В Linux root-аккаунт обладает полным набором прав, но далеко не всегда это нужно. Capabilities позволяют «разрезать» привилегии на части и выдавать только нужные.

Это снижает риски: сервис не сможет сделать ничего лишнего, даже если его взломают.

Например, чтобы процесс слушал порты ниже 1024, достаточно capability CAP_NET_BIND_SERVICE. Полный root здесь избыточен.

Проверка текущих прав:

capsh --print

Запуск процесса только с нужной capability:

capsh --drop=all --add=cap_net_bind_service -- -c "./server"

⚡️Так можно запускать сервисы безопаснее, следуя принципу «минимально необходимых прав». Это актуально и для контейнеров, и для демонов в продакшене.

⚡️ На Stepik вышел курс по Linux

Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой).

Материал подаётся понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами.

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

Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 20% по промокоду «ADMGUIDES»: открыть курс на Stepik

Multikernel: несколько ядер Linux на одном хосте

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

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

⏺Запуск через улучшенный kexec, управление и отладка — через /proc/multikernel.
⏺Для обмена сообщениями используется собственный IPI-фреймворк.
⏺Поддерживается динамическое выделение ресурсов и изоляция отказов.

⚡️ RECURA — прокачка инфраструктуры: от админа до security

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

🔹Мощные скрипты для автоматизации рутины (Bash, Python)
🔹Конфиги для отказоустойчивых и защищённых контейнеров (Docker, K8s)
🔹Инструменты для мониторинга, аудита и харденинга Linux-серверов
🔹Прицельные советы по интеграции security в процессы разработки

⚠️ Подпишись, чтобы быть инженером-универсалом.

Профилирование CPU с perf и Flamegraph

Когда сервер «тормозит» или высокая загрузка CPU не очевидна, стандартных инструментов вроде top часто недостаточно. 

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

Здесь на помощь приходит perf и Flamegraph.

perf — запись стека вызовов

Для начала нужно установить perf (apt install linux-tools-common linux-tools-$(uname -r) на Debian/Ubuntu).

Простейший пример:

sudo perf record -F 99 -a -g -- sleep 10

⏺ -F 99 — частота выборки 99 Гц
⏺ -a — профилируем все CPU
⏺ -g — сохраняем стеки вызовов
⏺ -- sleep 10 — профилируем 10 секунд

После этого создаётся файл perf.data, содержащий информацию о нагрузке CPU.

perf script + Flamegraph — визуализация горячих функций

Flamegraph позволяет видеть «горячие» участки кода:

perf script | stackcollapse-perf.pl | flamegraph.pl > out.svg

⏺stackcollapse-perf.pl — склеивает одинаковые стеки
⏺flamegraph.pl — генерирует интерактивный SVG

Открыв out.svg в браузере, можно увидеть, какие функции съедают процессорное время. Чем выше «полоса», тем дольше выполняется функция.