Menu
Server Logs for Humans: как читать access/error логи и чинить типовые проблемы

Server Logs for Humans: как читать access/error логи и чинить типовые проблемы

Что это (простыми словами)

Логи — это «чёрный ящик» вашего сервиса. В отличие от метрик, которые показывают агрегаты (графики p95, долю 5xx), логи рассказывают историю каждого запроса: кто пришёл, куда сходили внутри, что ответили и почему. Правильно организованные access и error логи позволяют:

  • быстро понять, есть ли инцидент и как он проявляется у пользователей;
  • локализовать первопричину (приложение, БД, внешнее API, сеть, TLS, CDN);
  • сократить MTTR и стабилизировать релизы;
  • строить анти‑фрод и защиту от ботов на фактах;
  • считать экономику: где теряются миллисекунды и деньги.

Важно помнить: логи — не архив «на всякий случай». Это инструмент эксплуатации и развития продукта. Их нужно проектировать, как проектируют API: с контрактом, полями, ретеншном и доступом по ролям.

Как работает (структура и принципы)

1) Два класса логов: access и error

Access‑логи фиксируют каждый входящий запрос: IP/ASN, методы и пути, код ответа, размер и тайминги. Это источник истины для доступности и производительности.

Error‑логи фиксируют исключения и сбои: stack trace, таймауты, лимиты ОС/БД, ошибки рукопожатия TLS, отказ WAF/ACL. Это ключ к первопричине.

Оба класса должны быть связаны единым request_id (или trace_id), чтобы по одному идентификатору собрать цепочку: edge → приложение → БД/очередь → внешний провайдер.

2) Форматирование: читаемо глазами, парсится роботом

Договоритесь о контракте полей. Практичный баланс:

  • Access — расширенный читаемый формат: timestamp, клиент (IP/X‑Forwarded‑For/ASN), метод, путь, код, размер, тайминги (connect/tls/upstream_wait/response), кеш‑статус, request_id, user‑agent, страна.
  • Error — компактный JSON с ключами: timestamp, level, service, component, request_id, message, error_code, duration_ms, retry_count, resource (db/cache/queue), безопасные фрагменты контекста.

Избегайте PII: маскируйте email/телефоны, удаляйте токены и секреты. Логирование паролей запрещено.

3) Доставка, индексация, ретеншн

Модель «собираем всё в stdout и забираем агентом» упрощает жизнь. Для продакшена удобно: Vector / Fluent Bit / Filebeat → Loki / ELK / OpenSearch → дашборды в Grafana/Kibana → алерты. Ретеншн:

  • «Горячие» (7–30 дней) — быстрый поиск, реагирование.
  • «Тёплые» (1–3 месяца) — анализ трендов, регрессии.
  • «Архив» (6–12 месяцев) — расследования, безопасность, требования регуляторов.

4) Безопасность и доступ

Логи часто содержат чувствительные данные: IP, рефереры, технические заголовки. Нужны роли и аудит доступа, шифрование «на диске» и на транспорте, а также механизмы редакции/маскировки.

Почему важно (5 быстрых причин)

  • Сокращение MTTR. Когда алерт приходит с ссылкой на дашборд логов и понятным текстом, инженер тратит минуты, а не часы.
  • Профилактика инцидентов. Повторяющиеся WARN/таймауты в error‑логах — ранние маркеры будущего падения.
  • Факты для оптимизаций. Видно, где рвётся пайплайн: БД, кэш, внешнее API, CDN, TLS, сети/пиринг.
  • Безопасность. Боты, подборы паролей, скрейпинг, странные user‑agent и ASN обнаруживаются первыми по access‑логам.
  • Диалог с бизнесом. Логи позволяют показать, как изменения (NVMe, кэш, лимиты) уменьшили p95 и увеличили выручку.

Как читать логи без боли: шаблоны и чек‑листы

Шаблон 1 — «Сайт тормозит»

Смотрим: p95/p99 по ключевым эндпоинтам, распределение кодов 2xx/4xx/5xx, upstream_* тайминги, долю кеш‑HIT.

Если: — растут 502/504 — upstream падает/не успевает; — всплеск 499 — клиенты сами закрывают соединение (не дождались); — p95 растёт без 5xx — узкое место в БД/поиске/внешнем API.

Делаем: включаем/чиним кеш, увеличиваем пулы и таймауты аккуратно, сжимаем ответы, оптимизируем запросы.

Шаблон 2 — «Много 404/403»

Смотрим: топ путей, рефереры, user‑agent, географию/ASN, дату релиза.

Если: 404 группируются вокруг одного пути — сломанный роут/ссылка; 403 идут сериями с одного ASN — WAF/ACL режет или идёт брутфорс.

Делаем: 301‑редиректы, правим sitemap/robots, настраиваем WAF/ratelimit/капчу, закрываем админ‑пути по IP.

Шаблон 3 — «Шторм 401/429»

Смотрим: нагрузку на auth‑сервис, расход токен‑бакета, интервалы запросов.

Если: 401 на /login — подбор паролей/слом SSO; 429 — «залипший» SDK или злоупотребление API.

Делаем: усилить ratelimit/капчу, кэшировать токены, исправить клиент, добавить backoff и джиттер.

Шаблон 4 — «Проблемы с TLS/SSL»

Смотрим: ошибки рукопожатия (handshake failed, unknown ca, no shared cipher), сроки сертификатов, SAN, долю старых клиентов.

Делаем: перевыпуск/автопродление, корректные cipher suites, тесты совместимости.

Шаблон 5 — «Рандомные 5xx на пиках»

Смотрим: error‑логи по request_id, очереди/воркеры, лимиты ОС (open files, sockets), GC.

Делаем: тюнинг пулов, рост ulimit, расширение воркеров, оптимизация горячих запросов, горизонтальное масштабирование.

Что включить в access‑логи (минимально необходимое)

  • Время и часовой пояс: UTC, единый формат ISO‑8601.
  • Клиент: источник (IP/X‑Forwarded‑For), ASN/страна (если обогащаете), user‑agent.
  • Запрос: метод, путь, версия протокола (HTTP/1.1, HTTP/2, HTTP/3).
  • Ответ: статус, размер, кеш‑статус (HIT/MISS/BYPASS), редирект‑цель.
  • Тайминги: connect, tls, upstream_wait, upstream_response, общая длительность.
  • Корреляция: request_id/trace_id + ссылка на спан в трейсинге.

Без таймингов и request_id логи теряют 80% ценности для диагностики.

Что включить в error‑логи (без превращения в «мусорку»)

  • Уровень: ERROR/WARN/INFO/DEBUG (для продакшена ограничивайте DEBUG).
  • Компонент: nginx/app/db/cache/queue/worker/cron.
  • Контекст: эндпоинт/операция, безопасные параметры, request_id.
  • Технические детали: код ошибки ОС/драйвера/БД, задержки, повторная попытка (да/нет).
  • Совет по фиксу (по возможности): «увеличить пул до N», «добавить индекс», «проверить таймаут внешнего API».

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

Дашборды на основе логов: must‑have виджеты

  • Коды статуса по всем запросам и по ключевым эндпоинтам (p95 рядом).
  • Латентность p50/p95/p99 в разрезе маршрутов, регионов, устройств.
  • Ошибки из error‑логов: топ исключений, частота, последние стеки.
  • Upstream тайминги: connect/TLS/wait/response.
  • Кеш‑статусы и доля кеш‑промахов.
  • Аномалии безопасности: 401/403/404/429, топ IP/ASN/user‑agent, 5xx‑шквалы.

Дашборд должен открываться с алерта одной ссылкой и содержать фильтры: по request_id, пути, коду, региону, user‑agent.

Плейбуки: короткие сценарии действий

Плейбук «502/504»

  1. Проверить доступность upstream и его p
  2. Сравнить метрики «до/после» релиза.
  3. Взять последние error‑логи: таймауты, недоступность БД/кэша, внешний API.
  4. Увеличить пулы соединений, оптимизировать N+1, добавить кеш перед API.
  5. Временно поднять таймауты (умеренно), включить деградацию/фолбэк.

Плейбук «499 растёт»

  1. Сопоставить с пиками трафика и ростом p
  2. Сжать и кешировать ответы, включить пререндер/Edge Cache.
  3. Разобраться с мобильными сетями/региональной латентностью.

Плейбук «401/403/429 волнами»

  1. Выделить IP/ASN, user‑agent, сегменты.
  2. Проверить скорость auth‑сервиса, сторожа rate‑лимита.
  3. Включить капчу/челленджи, блок AS, добавить backoff в SDK.

Плейбук «TLS ошибки»

  1. Проверить цепочку CA, SAN, сроки.
  2. Обновить сертификат, включить автопродление.
  3. Пересмотреть cipher suites и поддержку старых клиентов.

Типовые ошибки и как их избежать

  • Лишний шум. Пишите то, что помогает принять решение. Уберите ишью‑ID/трасс в INFO, переносите их в DEBUG.
  • Несогласованные форматы. Разные сервисы пишут по‑разному — корреляция ломается. Стандартизируйте контракт.
  • Нет ретеншна. Диск забился логами — теперь ещё и даунтайм. Настройте ротацию и архивирование.
  • PII и секреты в логах. Включите маскировку/редакцию и регулярные тесты.
  • Отсутствие request_id. Без него поиск первопричины превращается в квест.
  • Логи на том же диске, что и БД. Вынесите на отдельный том/пул, иначе на пике логи «задушат» прод.

План «улучшим логи за один вечер»

  • Стандартизировать поля access/error логов и добавить тайминги + request_id.
  • Включить сбор и поиск (Vector/Fluent Bit → Loki/ELK) с готовыми индексами.
  • Собрать базовый дашборд: статусы, p95, ошибки, тайминги upstream, кеш‑HIT.
  • Завести алерты на рост 5xx, 502/504, 499, 401/403/429, истечение TLS, p95 выше SLO.
  • Написать 5 плейбуков под самые частые кейсы (шаблоны выше).
  • Провести тренинг: симулировать инцидент (отключить кэш/замедлить БД) и пройти путь по логам до фикса.

Как выбрать инструменты и не «переплатить сложностью»

  • Небольшой проект/один сервер: ротация + локальный grep/awk, простые отчёты, алерты по fail2ban/лог‑паттернам.
  • Рост и несколько сервисов: централизованный сбор (Vector/Fluent Bit), индексация в Loki/ELK, унифицированные форматы, базовые дашборды.
  • Нагрузка, микросервисы, SLO: полноценная платформа логирования + метрики + трейсинг (ELK/OpenSearch/Loki + Prometheus + OTel), выделенные тома под логи, ретеншн по классам.

Не забывайте про стоимость хранения: включайте сэмплирование успешных запросов, логируйте 100% ошибок и критичные события.

Почему Unihost как платформа под логи

Сеть и периметр. Пиринги и DDoS‑фильтрация снижают шум в логах и дают предсказуемую латентность. Приватные VLAN упрощают разделение трафика логов и продакшена.

Хранилище. NVMe Gen4/Gen5 под индексы и журналы обеспечивают стабильные IOPS. Разведение логов и БД по разным пулам предотвращает деградации.

Гибкая архитектура. Легко стартовать на VPS, а затем перейти на выделенные/GPU‑серверы, не переписывая пайплайны логов — перенос через IaC. Снапшоты/бэкапы включаются политиками.

Инструменты. Готовые профили под Vector/Fluent Bit, ELK/Loki, Prometheus/Grafana/OTel, а также помощь инженеров в стандартизации форматов и создании плейбуков.

Заключение

Хорошие логи — это не «красивые текстовые файлы», а операционная система вашей команды: они ускоряют расследования, защищают от ботов, показывают эффекты оптимизаций и делают релизы спокойнее. Возьмите за правило: единые форматы, тайминги и request_id, централизованный сбор, дашборды и короткие плейбуки. Через неделю у вас появятся первые инсайты, через месяц — предсказуемая эксплуатация.

Попробуйте серверы Unihost — стабильная инфраструктура для ваших проектов.
Разверните логирование и наблюдаемость на VPS или выделенных серверах Unihost — и сократите MTTR уже в первый месяц.