Предыстория:

Я работаю с Linux больше 15 лет. Начинал с хостинга, где «сервер тормозит» означало зайти по SSH и запустить top. Потом были выделенные серверы, кластеры, Kubernetes. Задачи менялись, но вопрос оставался один и тот же:

Сервер тормозит. Что не так?

За эти годы у меня накопились инструкции, SSH-скрипты, обёртки над vmstat, iostat, ss, perf. Каждый раз, подключаясь к проблемному серверу, я тратил 20-40 минут на одни и те же действия вроде команды top

Это Tier 1 — базовый уровень. Но когда top показывает что всё вроде нормально, а приложение всё равно тормозит, начинается настоящая диагностика.

Глубже: BPF, softnet, NUMA и другие невидимые проблемы

С опытом я погружался глубже. BPF/eBPF инструменты от Brendan Gregg — runqlat, biolatency, tcpretrans, offcputime — открыли целый мир проблем, невидимых через top

Проблема в том, что подобные задачи решаются не каждый день. Между инцидентами проходят недели, иногда месяцы. И каждый раз я забывал: как называлась та утилита для softnet? Какой файл в /proc показывает conntrack drops? Какой sysctl отвечает за watermark?

Я снова гуглил, перечитывал свои же заметки, вспоминал синтаксис BCC-тулз.

AI изменила правила игры — но не до конца

Появление ChatGPT, а затем Claude изменило workflow. Теперь не нужно парсить глазами вывод cat /proc/net/netstat — можно скормить его нейронке и получить анализ. Не нужно помнить, что PruneCalled > 0 означает давление на TCP-память — AI это знает.

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

Я понял, что нужен мост между сервером и AI: инструмент, который соберёт все данные за один прогон, в структурированном виде, и отдаст нейронке для анализа.

Что я сделал

melisai — один Go-бинарник. Без зависимостей, без конфигов, без демонов. Одна команда:

sudo melisai collect --profile quick -o report.json

За 10 секунд (quick) или 60 секунд (deep) он:

1. Собирает данные из 8 Tier 1 коллекторов (procfs, sysfs, ss, ethtool, nvidia-smi)

2. Запускает до 67 BCC/eBPF инструментов (runqlat, biolatency, tcpretrans и ещё 64)

3. Вычисляет rate-based метрики через двухточечный сэмплинг

4. Прогоняет 37 правил обнаружения аномалий

5. Генерирует рекомендации с готовыми командами sysctl

6. Выдаёт health score от 0 до 100

На выходе — один JSON-файл с полной картиной: CPU, память, диск, сеть, процессы, контейнеры, GPU.

Реальный пример: каскадная деградация на production

Подключаюсь к production Docker-хосту. 8 ядер, 32 GB RAM, HDD RAID. «Всё тормозит».

sudo melisai collect --profile deep --ai-prompt -o report.json

60 секунд. Результат:

Health Score: 46 / 100

Anomalies (6):
  [CRITICAL] tcp_retransmits          134/sec
  [WARNING]  disk_utilization          80.5%
  [WARNING]  cpu_psi_pressure          17.6%
  [WARNING]  io_psi_pressure           12.8%
  [WARNING]  disk_avg_latency          12.1ms
  [WARNING]  tcp_close_wait            1 socket

Шесть аномалий. Но самое ценное — не отдельные метрики, а каскад, который melisai позволяет увидеть:

HDD p99 = 49ms → Диск не справляется. Block I/O latency из biolatency подтверждает.

PruneCalled = 105 → Ядро 105 раз обрезало TCP-буферы. Это значит: памяти не хватает для TCP-стека, ядро жертвует буферами.

TCP retransmits = 31/s → Следствие обрезки буферов. Пакеты теряются не в сети, а внутри сервера.

WireGuard tx_dropped = 226,132 → VPN-тоннель теряет пакеты. Следствие ретрансмитов выше.

Четыре симптома, одна корневая причина: HDD не справляется с нагрузкой.

Без melisai я бы потратил 30-40 минут чтобы это собрать. С melisai — 60 секунд на сбор, и дальше AI анализирует JSON.

Как это работает с AI

melisai включает встроенный MCP-сервер (Model Context Protocol). Claude Desktop или Cursor подключаются напрямую:

{
  "mcpServers": {
    "melisai": {
      "command": "ssh",
      "args": ["root@server", "/usr/local/bin/melisai", "mcp"]
    }
  }
}

После этого AI может сам:

1. Вызвать get_health — получить health score и аномалии

2. Вызвать explain_anomaly — получить root causes и рекомендации

3. Вызвать collect_metrics — получить полный отчёт с гистограммами и стектрейсами

Никаких copy-paste. AI видит всю картину и может задавать уточняющие вопросы.

В JSON-отчёте есть поле ai_context.prompt — динамический промпт с контекстом системы и 27 известными анти-паттернами. Это подсказка для AI: «вот что обычно бывает не так на таких системах».

Что под капотом

Трёхуровневый сбор

Tier 1: /proc, /sys, ss, ethtool, nvidia-smi
        Всегда работает. Root не нужен.

Tier 2: 67 BCC-инструментов (runqlat, biolatency, tcpretrans...)
        Нужен root + установленные bcc-tools.

Tier 3: Нативный eBPF через cilium/ebpf
        Нужен root + ядро ≥ 5.8 с BTF.

Если Tier 2 недоступен — fallback на Tier 1. Всегда что-то собрано.

Двухфазный сбор (observer effect)

Фаза 1: Tier 1 коллекторы снимают «чистый» baseline — CPU, память, диск, сеть. Фаза 2: BCC/eBPF тулзы запускаются, не влияя на baseline.

Это важно: BPF-тулзы сами потребляют CPU и I/O. Если запустить всё одновременно, baseline будет загрязнён.

Rate-based детекция

Все rate-метрики (retransmits/sec, softnet drops/sec, direct reclaim/sec) вычисляются через два замера с интервалом. Не cumulative counters с момента загрузки, а дельта за последние N секунд.

Это устраняет ложные срабатывания на серверах с uptime в 200 дней: cumulative softnet_dropped = 5000 ничего не значит, а softnet_drop_rate = 50/sec — это проблема прямо сейчас.

37 правил аномалий

Каждое правило — пороговое значение, основанное на рекомендациях Brendan Gregg и production best practices:

Рекомендации с готовыми командами

Каждая рекомендация — не абстрактный совет, а конкретная команда:

{
  "type": "fix",
  "title": "TCP memory pressure detected (PruneCalled) — increase tcp_mem",
  "commands": ["sysctl -w net.ipv4.tcp_mem='1048576 2097152 4194304'"],
  "evidence": "PruneCalled=105, tcp_mem=1541235 8388608 33554432",
  "source": "Linux TCP memory management, Brendan Gregg Systems Performance ch.10"
}

Тип fix — это проблема, которую нужно починить. Тип optimization — тюнинг, который можно сделать превентивно. AI различает их при анализе.

Что melisai НЕ делает

Честно о границах:

• Не мониторинг. Это диагностический инструмент — запустил, получил snapshot, исправил. Для непрерывного мониторинга нужен Prometheus/Grafana.

• Не алертинг. Не сидит демоном и не шлёт в Slack. Запускается по запросу или через cron.

• Не профилирует приложения изнутри. melisai видит, что процесс жрёт 245% CPU, но не скажет, какая функция виновата. Для этого — pprof, async-profiler.

• Только NVIDIA GPU. AMD ROCm в планах.

Установка

curl -sSL https://melisai.dev/install | sh

Один бинарник. Без Python, Ruby, Node.js. Кросс-компиляция с macOS. Apache 2.0.

Или собрать из исходников:

GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o melisai ./cmd/melisai/

Итог

За 15 лет я прошёл путь от top до BPF. Каждый шаг давал больше информации, но требовал больше времени и знаний. AI сжала анализ, но не сбор данных.

melisai закрывает этот gap: 67 BCC-тулз + 8 Tier 1 коллекторов + 37 правил аномалий в одном бинарнике. Один прогон, один JSON, один health score. Дальше — AI или человек анализирует результат.

Это не замена инженера. Это инструмент, который экономит 30-40 минут рутины на каждом инциденте.

GitHub
Сайт
Документация