Linux: "Кто съел весь канал?" top для вашей сети — nethogs

Классическая проблема: сервер "тормозит", вы запускаете top — CPU в норме, iotop — диски спят. Но пинги высокие, а ssh лагает. Кто-то "ест" всю полосу пропускания, но кто?

netstat и ss покажут соединения. nethogs покажет, какой ПРОЦЕСС генерирует этот трафик.

Как это работает: nethogs — это top для сети. Он группирует трафик по PID и показывает, сколько KB/sec отправляет и получает каждый процесс в реальном времени.

Установка и запуск:
Bash

# Ubuntu/Debian
sudo apt update && sudo apt install nethogs

# RHEL/CentOS
sudo yum install nethogs

Запуск (обязательно с sudo):
Bash

# 1. Мониторить весь трафик
sudo nethogs

# 2. Мониторить только один интерфейс (например, eth0)
sudo nethogs eth0

Вы увидите интерактивный список: PID - USER - PROGRAM - INTERFACE - SENT - RECEIVED.

Взгляд архитектора: Вы не просто "смотрите" на трафик. Вы проводите аудит. Вы можете мгновенно определить:
* backup.sh (rsync), который забыли ограничить по скорости.
* Скомпрометированный apache2, который стал частью ботнета и рассылает спам.
* java-приложение с утечкой данных.

Это переход от "наверное, сеть" к "процесс PID 1234, запущенный от user www-data, шлет 50 МБ/с на этот IP".

#linux #networking #sre #diagnostics #nethogs #команды #гайд

Гайд/Linux (Networking)
Linux: ping и traceroute — это прошлое. Диагностируем сеть как SRE с mtr

Проблема: Сервер "лагает". ssh "залипает". Вы запускаете ping — 0% потерь. Вы запускаете traceroute — он доходит до цели. Так в чем же дело?

Ответ: Вы не видите потери пакетов (packet loss) на промежуточных узлах.

mtr (My Traceroute) — это ping и traceroute в одном флаконе, на стероидах. Он в реальном времени показывает потери и пинг до каждого хопа на пути к цели.

Как читать mtr: Просто запустите: mtr google.com

Вы увидите таблицу: Host (Хопы) | Loss% (Потери) | Snt (Отправлено) | Last | Avg | Best | Wrst

Ваша задача — смотреть на Loss%:

Если потери 0% до самого конца — с сетью все в порядке.

Если на 7-м хопе (маршрутизатор вашего провайдера) 10% потерь, а на всех последующих тоже 10% — вы нашли виновника.

Команда для отчета (для скриптов):

Bash

# Отправить 10 пакетов и вывести отчет, не запуская интерактивный режим
mtr --report -c 10 ya.ru

Взгляд архитектора: Вы переходите от жалобы "у меня тормозит" к факту: "На 7-м хопе, xe-0-1-0.msk.provider.net, 10% потерь пакетов, начиная с 14:00". Это Data-Driven Troubleshooting (поиск неисправностей на основе данных), а не гадание.

#linux #networking #sre #mtr #diagnostics #команды #гайд

Linux: Скрипт "Daily Digest". Топ-10 ошибок из journalctl

Сервер "глючит". Лог journalctl — это миллион строк. Вы не можете найти причину в этом "шуме".

Реакция админа: Листать journalctl | grep "error" и надеяться. Реакция архитектора: Агрегировать данные и найти паттерны.

Этот Bash-скрипт — ваш "SRE-ассистент". Он проанализирует логи journalctl за последние 24 часа и покажет Топ-10 самых частых ошибок, отсекая весь "шум".

Код скрипта:
Bash

#!/bin/bash
# --- JournalCTL Error Digest ---

echo "--- Топ-10 ошибок в journalctl за последние 24 часа ---"

# 1. journalctl: Запрашиваем все с приоритетом "error" (3) за последние 24 часа.
# 2. awk: Вырезаем только само сообщение (все, что после ': ').
# 3. sort: Сортируем строки, чтобы одинаковые были рядом.
# 4. uniq -c: "Схлопываем" одинаковые строки и считаем их (count).
# 5. sort -nr: Сортируем по числу (numeric) в обратном порядке (reverse).
# 6. head -n 10: Показываем топ-10.

journalctl --since "24 hours ago" -p err | \
    awk -F': ' '{ $1=""; $2=""; print $0 }' | \
    sort | \
    uniq -c | \
    sort -nr | \
    head -n 10

echo "---------------------------------------------------------"

Как использовать:
Сохраните как digest.sh.
chmod +x digest.sh
sudo ./digest.sh

Взгляд архитектора: Вы не "ищете ошибку". Вы анализируете частотность. Если одна и та же ошибка (Failed password for root) повторилась 5000 раз — это brute-force атака, и вам нужен fail2ban. Если (Disk I/O error) — у вас умирает диск. Это Data-Driven Troubleshooting.

#linux #bash #journalctl #sre #diagnostics #скрипты #devops

Linux: "Почему мой Docker-контейнер тормозит?" Вскрываем `cgroups`

Вы выделили Docker-контейнеру 2 CPU, а он "задыхается". Вы запускаете htop на хосте — а там 20% простоя. Что происходит?

Происходит CPU Throttling (троттлинг). Ваш контейнер хочет больше CPU, но cgroups (Control Groups) его "душат".

cgroups — это технология ядра, которая изолирует и ограничивает ресурсы (CPU, RAM, I/O) для групп процессов. Это фундамент, на котором стоят systemd, Docker и Kubernetes.

Как увидеть "троттлинг" своими глазами:

Найдите "слайс" вашего контейнера:

Bash

# Найти "слайс" Docker
systemd-cgls | grep 'docker-'
# /docker-a1b2c3d4e5f6.scope
Прочитайте статистику CPU (самое важное):

Bash

# Идем в "папку" cgroup этого контейнера
cd /sys/fs/cgroup/cpu/docker/a1b2c3d4e5f6...

# Читаем файл статистики
cat cpu.stat

* nr_periods: Сколько раз процесс "приходил" за CPU.

* nr_throttled: Сколько раз ему было отказано (он был "задушен").

* throttled_time: Суммарное время, которое процесс провел в "задушенном" состоянии (в наносекундах).

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

#linux #sre #docker #cgroups #performance #diagnostics #гайд #architect

Linux: "Куда делся диск?" Скрипт для поиска "призрачных" файлов

Боль: Вы запускаете df -h и видите Use% 99% на разделе /var. Вы запускаете du -sh /var... и он показывает, что занято только 50%. Где остальные 49%?!

Ответ: Это "файлы-призраки". Процесс (например, nginx или java`) держит лог-файл открытым, а `logrotate в это время его rm (удалил). Файл исчез с диска, но пространство не освободится, пока процесс держит его "в памяти".

Реакция админа: reboot сервера.
Реакция архитектора: Найти "призрака" с lsof и освободить место без перезагрузки.

Этот Bash-скрипт использует lsof для поиска всех файлов, которые помечены как (deleted) , но все еще удерживаются процессами.

Код скрипта:
Bash

#!/bin/bash
# --- Поиск "призрачных" файлов (deleted but held open) ---

echo "--- Начинаю поиск файлов, удаленных, но удерживаемых процессами... ---"
echo "PID    USER     COMMAND     SIZE(MB)   FILE"
echo "----------------------------------------------------------------------"

# 1. lsof +L1: Найти файлы с link count < 1 (классический "призрак")
# 2. awk: Форматируем вывод, чтобы показать PID, User, Command, Size
# 3. sort: Сортируем по размеру (7-е поле, numeric-reverse)
# 4. head: Показываем топ-15

lsof +L1 -n | \
    awk '
    { 
        size_mb = $7 / (1024*1024); 
        if (size_mb > 1) { 
            printf "%-7s %-10s %-15s %-10.2f %s\n", $2, $3, $1, size_mb, $9 
        } 
    }' | \
    sort -k4 -nr | \
    head -n 15

Как использовать:
1. Сохраните как find_ghosts.sh и chmod +x find_ghosts.sh.
2. sudo ./find_ghosts.sh
3. Результат: Вы увидите, что PID 1234 (java) держит файл app.log (deleted) размером 10240 MB.
4. Решение: systemctl restart java-app.service. (Перезапуск процесса, а не всего сервера).

Взгляд архитектора: Вы не "гадаете", вы диагностируете. Вы понимаете, как VFS (Virtual File System) в Linux работает с inode и file descriptors . Это глубокое знание системы, которое отличает инженера от "эникейщика".

#linux #bash #sre #diagnostics #lsof #storage #скрипты #гайд

Windows: `Perfmon` — это не 'топ'. `ETW` — вот настоящий 'eBPF'

Боль: `Perfmon` (Системный монитор) показывает 100% I/O на диске, но не говорит, КАКОЙ процесс и КАКОЙ файл это вызвал. Вы "слепы".

Решение: ETW (Event Tracing for Windows) ETW — это "черный ящик" ядра Windows. Это самый низкоуровневый и производительный (почти 0% оверхеда) механизм трассировки всего: I/O, Registry, Network, CPU...

PerfView — это бесплатный инструмент от Microsoft для "чтения" ETW.

Как найти "пожирателя" I/O (на пальцах):

1. Скачайте PerfView.exe (один файл, не требует установки).

2. Запустите сбор:
* PerfView.exe collect
* Оставьте на 30-60 секунд, пока идет "торможение".
* Нажмите "Stop Collection".

3.Анализируйте *.etl.zip файл:
* Откройте файл.
* Найдите "File I/O".
* БИНГО: Вы видите таблицу, где Process Name (sqlservr.exe), File Name (C:\DB\data.mdf) и IO_Time (ms) (90% всего времени).

Взгляд архитектора: Sysmon — это "что случилось". Perfmon — это "как сильно". ETW / PerfView — это "ПОЧЕМУ". Это ваш "микроскоп" для SRE-диагностики, который дает неопровержимые данные о том, какая функция в каком процессе "убивает" вашу систему.

#windows #sre #performance #diagnostics #etw #perfview #architect #гайд

Linux: htop врёт. Куда на самом деле уходит память? Вскрываем pmap

Боль: Вы запускаете htop. Он показывает: VIRT: 25.0G, RES: 500M. Вопрос: Куда "делись" 24.5 ГБ? Почему VIRT (виртуальная) такой огромный, а RES (физическая) — маленький?

Реакция админа: "Наверное, это кэш. Перезагружу".
Реакция SRE: "Я посмотрю карту памяти процесса".

pmap (Process Memory Map) — это "рентген" для процесса. Он показывает каждый регион памяти, который процесс "попросил" у ядра.

Как это читать:
1. Найдите PID (например, pidof java -> 1234).
2. Запустите pmap с флагом -x (расширенный):
Bash

pmap -x 1234

Что вы увидите:
*Сотни строк с .so файлами (это shared libraries — общие библиотеки).
* [ anon ]: Это "анонимная" память — то, что malloc() выделил в "куче" (heap). Если эта цифра растет — у вас 100% утечка памяти (memory leak).
* [ stack ]: Стек процесса.

"Убийца"-команда (показать итог):
Bash

# Показать только ИТОГО (Total)
pmap -x 1234 | tail -n 1
# Вывод: total ---- 25165824K

Бинго! Вот ваши 25 ГБ. Это не "утечка", а 1000+ .so-библиотек, которые "раздули" виртуальное адресное пространство.

Взгляд архитектора: Вы перестаете "гадать" по htop. Вы видите корень проблемы. pmap — это ваш микроскоп для диагностики утечек памяти и "раздутых" приложений.

#linux #sre #performance #diagnostics #pmap #команды #гайд #architect

🔬 Linux (SRE): `htop` не видит диски. Находим "пожирателя" I/O с `iotop`

Боль: Сервер "тормозит". ssh "залипает". Вы открываете htop — CPU 5% , RAM 20% . Но iowait (wa) — 50% . Кто-то "убивает" дисковую систему.

Реакция админа: Перезагрузить сервер, надеясь, что "отпустит".
Реакция SRE: Запустить iotop.

iotop — это top для Disk I/O. Он в реальном времени показывает, какой ПРОЦЕСС и сколько читает (READ) и пишет (WRITE) на диск.

Как использовать (нужен root):

# 1. Установка
sudo apt install iotop
sudo yum install iotop

# 2. Запуск
sudo iotop

Ключевые флаги (чтобы видеть суть):

# -o: Показать ТОЛЬКО процессы, которые РЕАЛЬНО что-то пишут/читают
# -P: Показать Процессы, а не Потоки (намного чище вывод)
sudo iotop -oP

Результат: Вы мгновенно увидите, что PID 1234 (mysqld) пишет 200M/s (вероятно, "упал" индекс) или PID 5678 (jbd2/sda1-8) (журнал) сошел с ума.

Взгляд архитектора: Это SRE-диагностика. Вы не "гадаете", вы видите корень зла. Вы переходите от "наверное, диски" к "процесс mysqld (PID 1234) насыщает I/O, нужно смотреть его slow_query_log".

#linux #sre #performance #iotop #diagnostics #команды #гайд

🔬 Linux: Скрипт "Аудит dmesg". Ищем аппаратные ошибки
Боль: Сервер "тормозит", но htop и iotop — "зеленые". Приложение "вылетает" с Segfault.

Причина: Вы не видите аппаратных проблем. Отказ диска, "битая" RAM, проблемы с CPU — всё это логируется ядром в dmesg.

Реакция админа: "Проблемы с софтом, буду чинить приложение".
Реакция SRE: "Сначала проверю dmesg".

Этот Bash-скрипт — ваш "аппаратный аудитор". Он парсит dmesg и ищет "красные флаги".

Код скрипта:

#!/bin/bash
# --- Скрипт-аудитор 'dmesg' на ошибки ---

echo "--- Ищу 'красные флаги' в логах ядра (dmesg)... ---"

# -T: (Timestamps) Показать человеческое время
# --level=err,warn: Показать ТОЛЬКО ошибки и предупреждения
# (segfault, EDAC, I/O error, memory error...)
CRITICAL_ERRORS=$(dmesg -T --level=err,warn)

if [ -n "$CRITICAL_ERRORS" ]; then
    echo "[!!!] ОБНАРУЖЕНЫ КРИТИЧЕСКИЕ СОБЫТИЯ ЯДРА:"
    echo "$CRITICAL_ERRORS" | tail -n 20
    echo "--- Рекомендация: Немедленно проверьте I/O, EDAC (RAM) и CPU. ---"
else
    echo "[OK] Критических ошибок в dmesg не найдено."
fi

Взгляд архитектора: Это проактивный мониторинг "железа". Вы не ждете, пока smartd (диск) или EDAC (RAM) "покраснеют". Вы валидируете здоровье сервера на уровне ядра.

#linux #sre #diagnostics #bash #dmesg #скрипты #sysadmin

Windows (Диагностика): "Что вчера сломалось?" Скрытый Монитор стабильности

Боль: Сервер начал глючить сегодня утром. Вы открываете Event Viewer — там 10 000 событий "Information" и пара непонятных ошибок. Вы пытаетесь понять: "Что изменилось вчера?".

Реакция админа: Час копаться в логах Windows Update и MSI Installer.
Реакция профи: Открыть Монитор стабильности системы (Reliability Monitor).

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

Как открыть: Win + R -> perfmon /rel

Что вы увидите: График стабильности от 1 до 10 по дням. И, самое главное, четкий список событий по датам:

🔴 Критические события: "Вчера в 15:30 упал процесс sqlservr.exe".

🟡 Предупреждения: "Неудачная попытка установки обновления".

ℹ️ Информационные (Самое важное!): "Вчера в 14:00 был установлен новый драйвер сетевой карты" или "Установлено приложение Х".

Взгляд архитектора: Это лучший ответ на вопрос "Кто что трогал?". Вместо копания в логах вы видите причину и следствие на одном экране. "Ага, вчера обновился драйвер (Info), а через час начал падать SQL (Error)".

#windows #troubleshooting #diagnostics #sysadmin #perfmon #logs #гайд