Серверные логи и Web Vitals: структурные логи с request id и beacon, который называет плохой деплой

Ваши логи переехали — одна JSON-строка на событие, на сервере

Механизм «пропавших логов» — сама модель рендеринга. В pages-роутере код компонента выполнялся дважды — серверный рендер, затем гидрация в браузере, — поэтому его console.log появлялся в консоли браузера, и отладка там работала. Серверный компонент на клиент не отправляется никогда: его код исполняется только на сервере, и его логи существуют только в stdout серверного процесса. Ничего не потерялось — всё переехало туда, куда команда не смотрела: на serverless это часто платформенный сток логов с удержанием, измеряемым часами. Пункт чек-листа миграции, который никто не записывает: переместите глаза.

Когда вы уже смотрите в серверный stdout, следующим отказывает формат. Увидев payment failed без привязки к конкретному чекауту, поймите: это не проблема поиска — это проблема структуры. console.log(order) печатает многострочный дамп объекта; шипперы логов построчны, и одно событие превращается в семь фрагментов-сирот — незапрашиваемых и полуатрибутированных. Лечение структурное, не косметическое: один JSON-объект на строку на событие — модель pino — с уровнями, child-логгерами и встроенной редакцией:

// lib/logger.ts
import pino from 'pino';

export const logger = pino({
  level: process.env.LOG_LEVEL ?? 'info',
  redact: {
    paths: ['req.headers.authorization', 'req.headers.cookie', '*.email', '*.token'],
    censor: '[redacted]',
  },
});

Блок redact — это дисциплина PII, закреплённая в логгере, чтобы её нельзя было забыть в точке вызова. Логи — самое протекающее хранилище из всех, что вы эксплуатируете: они переживают строку в базе (холодное хранение, копии у вендора, ноутбуки разработчиков), они минуют права доступа, которые есть у таблиц, а «мы логировали всё тело запроса для отладки» — это то, как токены и почты попадают в сторонний индексатор. Редактируйте централизованно; логируйте идентификаторы (user id, id заказа), но никогда — идентифицирующее содержимое.

Корреляция: один request id на каждой строке

Структурные логи конкурентного трафика без корреляции — всё ещё шредер: три чекаута переплетаются, и payment failed не принадлежит никому. Лечение — id, отчеканенный один раз на первом хопе и приклеенный к каждой строке. Middleware и есть первый хоп — примите входящий x-request-id от балансировщика, если он есть (тогда ваш id склеится и с логами LB), иначе отчеканьте свой:

// middleware.ts — каждый запрос получает id до того, как кто-либо что-то залогирует
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(req: NextRequest) {
  const requestId = req.headers.get('x-request-id') ?? crypto.randomUUID();
  const headers = new Headers(req.headers);
  headers.set('x-request-id', requestId);
  const res = NextResponse.next({ request: { headers } });
  res.headers.set('x-request-id', requestId); // эхо клиенту — тикеты поддержки его цитируют
  return res;
}

// В любом серверном компоненте, действии или route handler
import { headers } from 'next/headers';
import { logger } from '~/lib/logger';

const log = logger.child({ reqId: (await headers()).get('x-request-id') });
log.error({ provider: 'stripe', code: 'card_declined' }, 'payment authorization failed');

Для глубокого служебного кода, которому нужно логировать без протаскивания id через десять сигнатур, нодовский AsyncLocalStorage несёт контекст запроса через границы await — войдите в store на входе handler-а или действия, и любая функция ниже достанет привязанный логгер. Честная оговорка: middleware может выполняться в отдельном edge-изоляте, не в вашем Node-процессе рендера, поэтому контекст ALS не перекрывает разрыв между middleware и рендером — мостом между процессами служит заголовок; ALS — удобство внутри одного. Дальше решите, что логирует каждый слой, потому что слои работают с разной частотой: middleware выполняется на каждом запросе и заслуживает максимум одну короткую строку решений маршрутизации или авторизации; серверные действия логируют намерение мутации и результат с id актора — это ваш аудиторский след; серверные компоненты логируют только сбои загрузки данных (рендеры слишком часты, чтобы пересказывать успех); route handler-ы — однострочную сводку запроса. И здесь окупается digest из прошлого урока: onRequestError отправляет digest с приклеенным request id, и тикет пользователя с любым из двух разворачивается в полную историю одним запросом.

Полевые vitals, beacon-ом домой

Серверная половина теперь крепка; клиентскую вскрывает девятидневная регрессия LCP (Largest Contentful Paint — время до отрисовки крупнейшего элемента страницы). Lighthouse в CI — лабораторное число: одна синтетическая машина, один профиль сети, пустой кеш. Ваши пользователи — распределение устройств и сетей, и единственное честное число производительности — полевой p75. Next.js даёт хук сбора — useReportWebVitals срабатывает в браузере для каждой метрики по мере её готовности; вы пересылаете её через navigator.sendBeacon, который переживает выгрузку страницы (обычный fetch был бы отменён на полпути, когда пользователь уходит, — ровно в момент, когда финализируются данные LCP):

'use client';
// app/vitals.tsx — монтируется один раз в корневом layout
import { useReportWebVitals } from 'next/web-vitals';

export function Vitals() {
  useReportWebVitals((m) => {
    const body = JSON.stringify({
      name: m.name,            // 'LCP' | 'INP' | 'CLS' | ...
      value: m.value,
      rating: m.rating,        // 'good' | 'needs-improvement' | 'poor'
      route: location.pathname,
      deploy: process.env.NEXT_PUBLIC_DEPLOY_ID, // ключ склейки, называющий плохой деплой
    });
    if (!navigator.sendBeacon('/api/vitals', body)) {
      fetch('/api/vitals', { method: 'POST', body, keepalive: true });
    }
  });
  return null;
}

Поле deploy — весь смысл затеи. Агрегируйте p75 по маршруту и id деплоя, и «LCP стал хуже» превращается в «деплой 7f3a сдвинул LCP страницы товара с 2,1 с до 3,4 с» — однострочный group-by вместо девяти дней дрейфа. Сверяйтесь со стандартными порогами на p75: LCP хорош до 2,5 с, плох после 4 с; INP хорош до 200 мс, плох после 500 мс; CLS хорош до 0,1, плох после 0,25. И замкните контур политикой алертов, уважающей человеческое внимание: алерт — на частоты, пейдж — на ущерб пользователям. Одиночная строка с 500 — ни то ни другое; частота ошибок по маршруту, пробившая бюджет, — алерт; частота сбоев чекаута или p75 страницы товара за порогом — пейдж. Пейджинг по строкам логов приучает дежурного игнорировать пейджер — самый дорогой провал наблюдаемости из всех.