{
  "index": 34,
  "slug": "editorial-2027-01-field-debugging-decade",
  "title": "502 без догадок: как восстановить цепочку запроса по логам",
  "excerpt": "Пошаговый разбор 502 по access и application log: как связать события, отличить отказ до приложения от ошибки в нём и не назвать причину без доказательства.",
  "contentHtml": "<p>Клиент получает 502. В access log шлюза видны маршрут, время и внешний статус. В журнале приложения нет записи с тем же запросом. Инженер открывает последний релиз и начинает искать ошибку в коде. Через несколько часов выясняется, что шлюз не дождался upstream или не смог разобрать его ответ. Исправление приложения не меняет ситуацию, а время расследования уже потеряно.</p>\n<p>Цена ошибки состоит не только в часах. Команда может откатить исправный релиз, увеличить таймаут без понимания причины или добавить повторные запросы к уже перегруженной зависимости. Следующий дежурный получит уверенную, но неверную запись: «упало приложение». Она направит новое расследование по тому же ложному следу.</p>\n<p>Рабочий тезис простой: 502 надо разбирать как разрыв цепочки событий. Сначала фиксируют, где появился статус. Затем ищут связанную запись приложения по идентификатору. Только после подтверждения передачи запроса переходят к зависимости. Отсутствие записи — тоже результат. Он ограничивает вывод и открывает отдельную проверку.</p>\n<h2>Что означает внешний статус</h2>\n<p>RFC 9110 определяет 502 как ответ gateway или proxy, который получил недействительный ответ от сервера, к которому обращался для выполнения запроса. Это описание роли узла, а не доказательство того, что конкретный сервис сломан. Клиент видит ответ ближайшей границы. Причина может находиться между шлюзом и upstream: в соединении, таймауте, формате ответа, маршрутизации или фильтре.</p>\n<p>Поэтому первая запись должна называть субъект результата. Поле <code>edge.status=502</code> точнее, чем сообщение «сервер вернул 502». Рядом нужны <code>route</code>, <code>method</code>, <code>duration_ms</code>, время события, имя узла и ключ корреляции. Без этих полей access log подтверждает симптом, но не даёт короткого пути к следующему слою.</p>\n<h2>Как строится доказательная цепочка</h2>\n<p>Для одной попытки запроса нужны минимум два источника: access log на границе и application log в сервисе. Они связываются по точному <code>request_id</code> или по trace context. Время и путь помогают проверить совпадение, но не должны быть единственным ключом. Два запроса к одному маршруту могут попасть в одно и то же временное окно.</p>\n<p>Если application event найден, сравните время, маршрут, статус и длительность. Запись приложения с 500 показывает, что запрос дошёл до приложения и там завершился ошибкой. Она не объясняет, почему произошёл отказ зависимости. Запись приложения с 200 при внешнем 502 показывает расхождение границ: надо проверять retry, кэш, преобразование статуса или другой upstream.</p>\n<p>Если application event не найден, не подставляйте приложение в роль виновника. Проверьте timeout до приложения, правила маршрутизации, формат идентификатора, фильтры коллектора и задержку доставки. После этого можно сказать только: «внешний отказ подтверждён, запись приложения не найдена». Это полезный вывод, потому что он отделяет неисправность канала наблюдения от отказа бизнес-операции.</p>\n<figure><img src=\"/assets/editorial/2027/debugging-decade-2027-hypothesis-evidence-loop.svg\" alt=\"Цепочка разбора 502 от access event через application event к проверке зависимости\" loading=\"lazy\" /><figcaption>Полевой разбор начинается с внешнего события. Разрыв между access и application не позволяет объявить приложение причиной.</figcaption></figure>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Матрица первой проверки для 502</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Возможная причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>502 в edge, application event отсутствует</td><td>timeout, маршрут до сервиса или потеря записи</td><td>сверить upstream, окно времени, collector и формат id</td><td>зафиксировать разрыв; не обвинять приложение</td></tr><tr><td>502 в edge, application 500 с тем же id</td><td>ошибка обработки запроса в сервисе</td><td>сравнить время, route, статус и dependency event</td><td>исследовать ошибку приложения и её границу</td></tr><tr><td>502 в edge, application 200</td><td>retry, cache или преобразование ответа на proxy</td><td>проверить попытки, upstream и mapping статусов</td><td>разделить результат приложения и результат клиента</td></tr><tr><td>В access нет request id</td><td>неполная схема structured log</td><td>проверить конфигурацию полей и передачу заголовка</td><td>исправить корреляцию до следующего разбора</td></tr></tbody></table></div>\n<h2>Учебный пример корреляции</h2>\n<p>Ниже приведён учебный пример для локальной проверки идеи. Массивы не взяты из production и не доказывают поведение конкретного шлюза. Функция получает события одной попытки и классифицирует только наблюдаемый разрыв.</p>\n<pre><code>const edge = [\n  { requestId: 'r-1', at: '12:00:01.100', status: 502, durationMs: 3000 },\n  { requestId: 'r-2', at: '12:00:02.100', status: 502, durationMs: 420 },\n];\n\nconst app = [\n  { requestId: 'r-2', at: '12:00:02.080', status: 500, error: 'db unavailable' },\n];\n\nfunction classify(edgeEvent, appEvents) {\n  const appEvent = appEvents.find((event) => event.requestId === edgeEvent.requestId);\n  if (!appEvent) return 'gateway-failed-before-app-or-event-missing';\n  if (appEvent.status >= 500) return 'app-error-reached-gateway';\n  return 'status-mapping-needs-check';\n}\n\nedge.map((event) => ({\n  requestId: event.requestId,\n  result: classify(event, app),\n}));\n// r-1: gateway-failed-before-app-or-event-missing\n// r-2: app-error-reached-gateway</code></pre>\n<p>Для <code>r-1</code> код видит только отсутствие события. Это не различает timeout, сбой коллектора и неверный идентификатор. Для <code>r-2</code> найдено согласованное событие приложения. Оно подтверждает путь запроса, но не доказывает, что база была первопричиной. Следующий запрос должен проверить dependency event, лимит соединений и время ожидания.</p>\n<p>В рабочем коде нормализуйте схему на входе, сохраняйте номер попытки и не смешивайте повторные запросы в одну карточку. Не включайте в общий журнал токены, тело формы, email и сырые заголовки. Безопасный fingerprint может помочь связать закрытый источник с публичной карточкой, если правила хранения это разрешают.</p>\n<h2>Действия по порядку</h2>\n<ol><li>Скопируйте одну попытку из edge log: timestamp, route, method, status, duration и request id.</li><li>Уточните, какой узел сформировал 502 и какой upstream он выбирал.</li><li>Найдите application events по точному id в ограниченном временном окне. Запишите число найденных событий.</li><li>Сверьте время, route, status и номер попытки. Отдельно отметьте retry, очередь и возможный clock skew.</li><li>Если приложение подтверждено, проверьте dependency event и только затем формулируйте рабочую гипотезу о причине.</li><li>Если приложение не найдено, проверьте timeout, маршрутизацию, collector, формат идентификатора и задержку доставки.</li><li>Запишите вывод как наблюдение и следующий тест: например, «нет application event; проверить timeout и collector».</li><li>После изменения повторите тот же запрос и убедитесь, что цепочка снова собирается по идентификатору.</li></ol>\n<h2>Где метод перестаёт работать</h2>\n<p>Лог может быть неполным. Sampling удаляет часть событий. Буферизация меняет порядок доставки. Collector может отбросить запись или обрезать длинное сообщение. Часы сервисов могут расходиться. Поэтому близкое время не заменяет ключ корреляции, а найденный ключ не гарантирует полноту цепочки.</p>\n<p>Один request id может пережить retry или быть создан заново на новой попытке. Это надо выяснять по <code>attempt</code>, span id и временным интервалам. Trace context помогает передавать связь между HTTP-границами, но не доказывает, что каждый сервис записал событие или что наблюдаемый участок был причиной сбоя.</p>\n<p>Структурированные поля упрощают поиск, но не делают журнал достоверным автоматически. Формат RFC 5424 предусматривает отдельную область для parseable structured data; конкретная система всё равно может неправильно настроить поля, транспорт или collector. Если корреляция часто ломается, сначала исправьте контракт логирования. Новый экран наблюдаемости не компенсирует отсутствующий идентификатор.</p>\n<p>Метод также не заменяет нагрузочный анализ и проверку контракта ответа. Если 502 появляется только при перегрузке, одного разбора карточки недостаточно. Нужны распределение длительностей, число retry, состояние очередей и лимиты соединений. Эти данные расширяют расследование, но не отменяют первый шаг: определить, где появился внешний статус.</p>\n<h2>Критерий готовности</h2>\n<p>Разбор готов, когда для одной повторной попытки можно показать access event, application event или явно подтверждённый разрыв, согласованные время и маршрут, номер попытки и следующий проверяемый вывод. Исправление готово, когда после него тот же сценарий даёт ожидаемый статус, цепочка событий собирается по идентификатору, а отрицательный путь остаётся различимым. Формулировка «проблема решена» без этих наблюдений недостаточна.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html#section-15.6.3\" target=\"_blank\" rel=\"noopener\">RFC 9110, раздел 15.6.3: 502 Bad Gateway</a></li><li><a href=\"https://www.rfc-editor.org/rfc/rfc5424.html#section-6.3\" target=\"_blank\" rel=\"noopener\">RFC 5424, раздел 6.3: STRUCTURED-DATA</a></li><li><a href=\"https://www.w3.org/TR/trace-context/\" target=\"_blank\" rel=\"noopener\">W3C Trace Context Recommendation</a></li></ul>"
}