grep: история о возможностях, которыми почти никто не пользуется

Большинство знают grep как “поиск строки в файле”. На самом деле это один из самых мощных инструментов анализа в Linux.

Поиск по множеству файлов

grep "ERROR" /var/log/*.log
grep -r "token" .

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

Регулярки и флаг -E

grep -E "ERROR|WARN|FATAL" app.log

-E включает расширенные регулярные выражения. Без него половина возможностей просто недоступна.

Читаемый вывод

grep --color=auto "timeout" app.log

Цвет - не гулянка. Это скорость анализа и меньше ошибок глазами.

Поиск с исключениями

grep -v "healthcheck" access.log

Идеально, когда нужно убрать шум и оставить только важное.

Как посмотреть использование сети в реальном времени в Linux

Одна из самых частых болей в Linux - «интернет лагает, но непонятно почему». Процессов много, сервисов ещё больше, а понять, кто именно сейчас ест сеть, бывает сложно. Именно для таких ситуаций и существует bandwhich.

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

В отличие от top, который работает с CPU и памятью, bandwhich вообще не интересуется загрузкой процессора. Он смотрит на сетевые сокеты и сопоставляет их с процессами. Поэтому top здесь бесполезен. netcat - это инструмент для ручной работы с соединениями, а не мониторинг. lsmod вообще показывает загруженные модули ядра и к сети отношения не имеет.

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

Отдельный плюс - читаемый интерфейс. Никаких графиков ради графиков, только полезная информация: процесс, направление трафика, скорость и общий объём. Именно поэтому bandwhich часто используют DevOps, админы и SRE во время инцидентов, когда времени разбираться «по науке» просто нет.

Если коротко: когда нужен быстрый и честный ответ на вопрос «кто жрёт сеть прямо сейчас», правильная команда - bandwhich.

Что делает команда ncdu и почему без неё сложно жить

В какой-то момент на любом Linux-сервере заканчивается место. Причём заканчивается внезапно: всё работало, алертов не было, а потом - «No space left on device». И вот тут начинается классическая боль: что именно съело диск?

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

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

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

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

Что делает команда mtr и почему она незаменима при сетевых проблемах

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

Пакеты теряются, задержки скачут, сервисы то отвечают, то молчат. В такие моменты обычный ping даёт слишком мало информации, а traceroute - слишком статичную картину.

mtr объединяет оба подхода. Эта команда в реальном времени показывает маршрут до узла, задержки на каждом хопе и процент потерь пакетов. Причём данные обновляются постоянно, а не один раз, как в классическом traceroute. Именно поэтому mtr так любят админы и DevOps во время инцидентов.

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

Другие варианты из опроса к задаче не относятся. mtr не работает с HTTP, не мониторит ядро и не проверяет лимиты процессов. Его задача строго одна - диагностика сети.

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