👀 Диагностика сетевых проблем с mtr и ss

🌟 mtr (My Traceroute) - сочетает ping и traceroute, выводит маршрут и потери пакетов до цели. Очень наглядно показывает, где в пути начинается деградация.

▪️ Пример:

mtr -rw -c 50 8.8.8.8

Покажет 50 запросов, каждый hop, потери (%) и задержку (ms).
Если видите 30–50% потерь на каком-то промежуточном IP - скорее всего, это и есть проблемный участок.

🌟 ss (socket statistics) - замена netstat. Помогает найти открытые порты, "зависшие" соединения и выяснить, какой процесс что слушает.

▪️ Примеры:

1️⃣ Просмотр всех TCP/UDP портов с PID:

ss -tulpn

2️⃣ Кто держит порт 443:

ss -ltnp | grep ':443'

3️⃣ Зависшие соединения в состоянии CLOSE-WAIT:

ss -tan state close-wait

⭐️ Сценарий диагностики:

1. Сначала mtr до внешнего хоста - проверка трассировки и потерь.
2. Потом ss - смотрим, что на машине: может, переполнен backlog, слушающий порт не отвечает или слишком много соединений.

#mtr #ss #debug

🧑‍💻 NetworkAdmin

🔄 strace и ltrace: отладка процессов

Часто возникает ситуация: программа подвисает, работает странно или вообще не запускается. В таких случаях на помощь приходят два инструмента - strace и ltrace. Оба они позволяют заглянуть внутрь процесса, но делают это на разных уровнях.

▪️ strace - системные вызовы. strace перехватывает системные вызовы, которые делает процесс, и возвращаемые значения. Это удобно для анализа проблем с доступом к файлам, сетевыми подключениями или зависаниями.

📍 Запуск с приложением:

strace ls /nonexistent

Вывод покажет, что ls пытается открыть директорию и получает ENOENT (нет такого файла).

📍 Подключение к уже работающему процессу:

strace -p 1234

Теперь видно, чем занимается процесс с PID 1234.

📍 Фильтрация вызовов:

strace -e open,read,write -p 1234

Будут показаны только вызовы open, read, write.

▪️ ltrace - вызовы библиотек. Если strace работает с системными вызовами ядра, то ltrace отслеживает вызовы функций библиотек. Это особенно полезно, если программа спотыкается не на уровне ядра, а на уровне glibc или других библиотек.

📍 Пример:

ltrace ls

Вы увидите вызовы функций вроде malloc(), strlen(), fopen().

📍 Фильтрация по конкретным функциям:

ltrace -e malloc,free ./myprog

Будут показаны только вызовы функций управления памятью.

▪️ Совместное применение. Часто эти инструменты используют вместе:

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

▪️ Практические кейсы

📍 Отладка зависающих процессов:

strace -p <PID>

Сразу видно, ждёт ли программа I/O или зациклилась.

📍 Диагностика ошибок "файл не найден":

strace ./prog 2>&1 | grep ENOENT

Можно увидеть, какой именно файл не удаётся открыть.

📍 Поиск утечек памяти:

ltrace -e malloc,free ./prog

Если много malloc(), но мало free() - повод задуматься.

#linux #debug

🧑‍💻 NetworkAdmin

⌛️ Быстрый способ отладки bash-скриптов

Когда в скрипте что-то идет не так, часто хочется понять, какая команда выполнилась последней и какие значения получили переменные. Вместо того чтобы расставлять десятки echo, в bash есть встроенный инструмент - set -x.

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

▪️ Пример: резервное копирование файла

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

#!/bin/bash
set -x

src="/etc/hosts"
dst="/tmp/backup"

mkdir -p "$dst"
timestamp=$(date +%Y%m%d_%H%M%S)
cp "$src" "$dst/hosts_$timestamp"

echo "Backup created: $dst/hosts_$timestamp"

Вывод консоли:

▶ Запуск
# ./backup.sh
+ src=/etc/hosts
+ dst=/tmp/backup
+ mkdir -p /tmp/backup
+ date +%Y%m%d_%H%M%S
+ timestamp=20251007_121330
+ cp /etc/hosts /tmp/backup/hosts_20251007_121330
+ echo 'Backup created: /tmp/backup/hosts_20251007_121330'
Backup created: /tmp/backup/hosts_20251007_121330

Мы видим каждое действие: какие переменные подставились, как отработала команда date, куда скопировался файл.

#linux #debug

🧑‍💻 NetworkAdmin

🧑‍💻 Отладка контейнеров без инструментов

Иногда нужно что-то быстро продебажить внутри контейнера: посмотреть процессы, сделать ping, проверить DNS или снять tcpdump. Но чаще всего внутри контейнера нет вообще ничего, кроме самого приложения.

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

▪️ Пример использования. Создадим контейнер с Nginx, где нет даже ps:

docker run --name nginx -d -p 8080:80 nginx
docker exec -it nginx bash
ps axf

bash: ps: command not found

Теперь подключаем Network-Multitool к тому же namespace, где работает контейнер Nginx:

docker run --rm -it \
  --network=container:nginx \
  --pid container:nginx \
  wbitt/network-multitool:alpine-extra bash

Проверим процессы:

ps axf
  PID TTY      STAT   TIME COMMAND
   47 pts/0    Ss     0:00 bash
   60 pts/0    R+     0:00 \_ ps axf
    1 ?        Ss     0:00 nginx: master process nginx -g daemon off;
   29 ?        S      0:00 nginx: worker process
   30 ?        S      0:00 nginx: worker process

Теперь у вас есть все необходимое: ping, dig, curl, tcpdump, netcat, iftop, mysql, git, tshark и многое другое.

▪️ Варианты сборок

alpine-extra - расширенная версия (максимум инструментов, включая tshark, ab, postgresql-client, git и др.).
alpine-minimal - легкая сборка, только базовые сетевые утилиты.

#docker #debug

🧑‍💻 NetworkAdmin