Три pillarа: построй навигационную поверхность observability

Возьми небольшой HTTP-сервис (свой или стартовый) и инструментируй его всеми тремя сигналами через OpenTelemetry так, чтобы один всплеск метрики можно было навигировать к трейсу и log-строкам именно того медленного запроса за менее чем 30 секунд — затем докажи, что слой метрик переживает намеренно внедрённую cardinality-бомбу.

• Построй или возьми небольшой HTTP-сервис как минимум с одним эндпоинтом, вызывающим downstream-зависимость (запрос к БД или upstream HTTP-вызов), чтобы у трейса было больше одного span.
• Эмить все три сигнала через OpenTelemetry: RED-метрики (counter запросов и histogram задержки), структурированные JSON-логи с обязательными полями (timestamp, level, service.name, trace_id, span_id, message) и распределённые traces, пробрасываемые заголовком W3C traceparent.
• Используй OpenTelemetry Semantic Conventions для каждого join-ключа: service.name, http.route (шаблонный, не сырой URL), http.request.method, http.response.status_code и db.system / db.operation на span зависимости — идентичные имена во всех трёх сигналах.
• Прикрепи exemplar (trace_id) к histogram задержки, чтобы медленный bucket линковался к конкретному трейсу; держи всю per-customer или per-user идентичность ВНЕ label метрик.
• Настрой семплирование трейсов: head-based ParentBased(TraceIdRatioBased) на разумной базе (10-20%) с криптографически случайным trace_id, плюс tail-sampling политику на коллекторе, удерживающую 100% трейсов ERROR и задержки выше SLO.
• Внедри сбой в зависимость (задержку или ошибки), нагрузи до всплеска histogram задержки, затем выполни и запиши проход triage: всплеск метрики → клик по exemplar → waterfall трейса → логи, отфильтрованные по trace_id — фиксируя затраченное wall-clock время.
• Добавь guardrail на cardinality: CI-lint (или metric_relabel_configs labeldrop), блокирующий новые label метрик из deny-list (email, user_id, session_id), и алерт на rate(prometheus_tsdb_head_series_created_total). Затем намеренно добавь неограниченный label и покажи, что guardrail ловит его до вреда TSDB.

• Записанный проход triage metric → trace → log за менее чем 30 секунд, скриншоты или терминальные захваты на каждом шаге, все связанные одним trace_id.
• Доказательство, что три сигнала делят идентичные имена join-ключей (покажи label метрики, поле лога и атрибут span бок о бок для http.route и service.name).
• Histogram задержки показывает кликабельные exemplarы, и ни одна метрика не несёт per-user или per-customer label идентичности.
• Демонстрация, что guardrail на cardinality срабатывает на внедрённый неограниченный label (CI-сбой или алерт + labeldrop), при этом скорость создания серий возвращается к базе в пределах одного scrape-интервала.
• Сводка в один абзац, называющая для каждого из трёх сигналов вопрос, на который он ответил дешевле всего в triage, и ось стоимости, которую он взорвал бы при неверном использовании.