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‑сервіс, витрату token‑bucket, інтервали запитів.
Якщо: 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 логи втрачають більшу частину цінності для діагностики.

Що включати в error‑логи (і не перетворити на «смітник»)

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

Повідомлення мають бути короткими й самодостатніми: інженер не повинен «перекладати» лог у дію.

Дашборди на основі логів: обов’язкові віджети

  • Коди статусу загалом і по ключових ендпоїнтах (поряд 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 і його p95.
  2. Порівняти метрики «до/після» релізу.
  3. Подивитися свіжі error‑логи: таймаути, недоступність БД/кеша, зовнішні API.
  4. Збільшити пули з’єднань, прибрати N+1, додати кеш перед API.
  5. Тимчасово підняти таймаути (обережно), увімкнути деградацію/фолбек.

«499 зростає»

  1. Зіставити з піками трафіку і p95.
  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 і підтримку старих клієнтів.

Типові помилки та як їх уникнути

  • Зайвий шум. Логуйте тільки те, що допомагає прийняти рішення. Перенесіть дрібні деталі у 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 уже в перший місяць.