Зачем это нужно

ML-сервис редко работает изолированно: он принимает HTTP-запросы, ходит в базу за фичами, тянет модель из S3. Когда «что-то не работает», нужно понять: проблема в коде, в сети или в соседнем сервисе? Базовая сетевая грамотность экономит часы дебага.

Вы не обязаны стать сетевым инженером, но должны уметь ответить: «порт слушается?», «DNS резолвится?», «HTTP возвращает 200 или 503?», «что в логах?».

Основные идеи

IP и порты. Каждый сервер имеет IP-адрес (например, 10.0.1.42). Сервис слушает порт — число от 1 до 65535. HTTP обычно на порту 80 (или 443 для HTTPS). ML inference API часто на 8080 или 8000.

ss -tlnp # какие порты слушаются (современная замена netstat) curl http://localhost:8080/health # запрос к локальному сервису

DNS — система имён. scoring.api.company.com → IP. Если DNS не работает, curl по hostname падает, по IP — работает.

nslookup scoring.api.company.com dig scoring.api.company.com

curl — швейцарский нож HTTP:

curl -v http://localhost:8080/predict -H "Content-Type: application/json" -d '{"features": [1,2,3]}' curl -I https://api.example.com/health # только заголовки curl -w "%{http_code} %{time_total}s\n" -o /dev/null -s http://localhost:8080/health

Флаги: -v verbose, -H заголовок, -d тело POST, -w формат вывода метрик.

Логи. Приложение пишет в stdout/stderr или в файл. На Linux с systemd журнал централизован:

journalctl -u scoring-service -n 100 # последние 100 строк сервиса journalctl -u scoring-service -f # follow (как tail -f) journalctl -u scoring-service --since "1 hour ago" journalctl -u scoring-service -p err # только ошибки

Файловые логи:

tail -n 50 /var/log/scoring/app.log grep "ERROR" /var/log/scoring/app.log | tail -20

Типовая схема диагностики:

Сервис отвечает локально (curl localhost)? → если да, проблема снаружи (firewall, load balancer).
Процесс запущен (ss -tlnp)?
Что в логах (journalctl)?
Доступен ли upstream (БД, S3)?

Как это выглядит на практике

QA сообщает: POST /predict возвращает 502. MLE на staging-сервере:

Шаг 1: жив ли процесс?

ss -tlnp | grep 8080

Шаг 2: локальный запрос

curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/health

→ 503

Шаг 3: логи

journalctl -u scoring-service -n 30 --no-pager

→ "Connection refused to postgres:5432"

Шаг 4: проверка БД

nc -zv postgres.internal 5432

→ Connection refused → задача для DBA, Incident в Jira

Runbook в Confluence содержит именно эту цепочку — on-call не импровизирует.

Что сделать после занятия

Поднимите простой HTTP-сервер (python -m http.server 8080) и проверьте через curl.
Выполните POST-запрос с JSON через curl.
Найдите в journalctl или /var/log (если доступно) записи за последний час.

Официальные материалы

systemd — journalctl documentation