Наблюдаемость¶
Требования применяются к платформенной доставке сигналов приложений и
наблюдаемости инфраструктурных компонентов в non-production и production.
Уровни обязательности определены в корневом README.md.
INF-OBS-001. Корпоративный маршрут сигналов¶
Уровень: MUST
Применяется к: production workload
Платформа должна предоставить и эксплуатировать маршрут логов по
architecture:OBS-LOG-001–OBS-LOG-008: приём stdout/stderr через Vector
и доставку в OpenObserve.
Если проект выбрал рекомендуемые метрики, трассы или сбор ошибок по
architecture:OBS-MET-001, architecture:OBS-TRACE-001 либо
architecture:OBS-ERR-001, платформа должна предоставить соответствующий
приём OpenTelemetry Protocol (OTLP) через OpenTelemetry Collector и доступ к
GlitchTip. Инфраструктура не должна менять семантику выбранных сигналов,
требовать второго параллельного транспорта или делать эти каналы обязательными
для микросервиса.
Инфраструктурные компоненты должны экспортировать доступные им health, capacity и error signals в корпоративную систему наблюдаемости.
Обоснование¶
Единые маршруты позволяют сопоставлять состояние приложения и платформы.
Проверка¶
- генерация тестового лога и каждого выбранного проектом дополнительного сигнала;
- поиск выбранных сигналов по service, environment и version.
Исключения¶
Компонент, для которого тип сигнала неприменим, должен иметь это решение в операционном README; отсутствие exporter у платформенного компонента не должно ломать приложение.
INF-OBS-002. Идентификация deployment¶
Уровень: MUST
Применяется к: телеметрии workload
Платформа должна передавать приложению стабильные service.name,
service.version и deployment.environment.name. service.version должен
позволять определить release identifier image и commit и соответствовать
architecture:OBS-MET-002, architecture:OBS-TRACE-003 и
architecture:OBS-ERR-005.
Обоснование¶
Без общей идентификации невозможно сравнить версии и связать инцидент с поставкой.
Проверка¶
- запрос всех сигналов одной версии;
- сопоставление с GitLab deployment.
Исключения¶
Не допускаются.
INF-OBS-003. Dashboard и alerts¶
Уровень: MUST
Применяется к: production-цели
Цель должна иметь dashboard состояния rollout, трафика, ошибок, задержки,
ресурсов и критичных зависимостей. Alert должен иметь численный порог, окно,
severity, владельца и ссылку на runbook; отсутствие требуемой телеметрии не
должно считаться нормальным состоянием. Пользовательские SLI/SLO и incident
severity определяются architecture:OPS-SLO-001–OPS-SLO-005 и
architecture:OPS-INC-001–OPS-INC-004.
Обоснование¶
График без действия и alert без владельца не обеспечивают эксплуатацию.
Проверка¶
- синтетическое нарушение каждого обязательного alert;
- review ссылок и маршрута уведомления.
Исключения¶
Метрика трафика не требуется для workload без запросов или сообщений.
INF-OBS-004. Ограничение доступа и хранения¶
Уровень: MUST
Применяется к: инфраструктурной телеметрии
Платформенные фильтры, роли доступа и retention должны реализовывать
классификацию и минимизацию из
architecture:DATA-CLS-001–DATA-CLS-003, а также защиту сигналов из
architecture:OBS-LOG-006, architecture:OBS-MET-007 и
architecture:OBS-ERR-007. Значение секрета, token или Kubernetes Secret не
должно сохраняться платформой наблюдаемости.
Обоснование¶
Централизованная телеметрия увеличивает последствия утечки.
Проверка¶
- тестовые canary-secret и поиск в OpenObserve/GlitchTip;
- review ролей и retention.
Исключения¶
Не допускаются.
INF-OBS-005. Наблюдаемость платформенных компонентов¶
Уровень: MUST
Применяется к: production Kubernetes-платформе
Должны наблюдаться как минимум готовность узлов и control plane, ошибки DNS, состояние APISIX и cert-manager, срок сертификатов, GitLab Agent/GitOps reconciliation, capacity и ошибки Longhorn, backup jobs, OpenTelemetry Collector, Vector и заполнение storage наблюдаемости. Для применимого компонента потеря quorum, degraded state либо приближение к capacity limit должны иметь alert до полной недоступности.
Обоснование¶
Сигналы приложения не объясняют отказ общей платформенной зависимости.
Проверка¶
- контролируемый отказ или синтетическая проверка каждого компонента;
- проверка dashboard, alert и ссылки на runbook.
Исключения¶
Неприменимый компонент должен отсутствовать из platform manifest; заменяющий внешний сервис должен предоставлять эквивалентный сигнал.
INF-OBS-006. Доставка телеметрии не блокирует workload¶
Уровень: MUST
Применяется к: Vector и OpenTelemetry Collector на пути приложения
Недоступность OpenObserve не должна блокировать обработку приложения или создавать неограниченный buffer на узле. Buffer, retry, drop policy и предел диска/памяти должны быть заданы численно; потеря или отбрасывание сигналов должны наблюдаться.
Обоснование¶
Отказ наблюдаемости не должен превращаться в каскадный отказ workload.
Проверка¶
- отключение OpenObserve под нагрузкой;
- измерение ресурсов, dropped signals и восстановления экспорта.
Исключения¶
Audit-сигнал MAY требовать fail-closed поведения только по отдельному архитектурному контракту.
INF-OBS-007. Сигналы non-production release¶
Уровень: MUST
Применяется к: non-production-цели, используемой как release gate
Цель должна доставлять те же типы сигналов, поля идентификации и health результаты, на которых основано production-продвижение. Значения environment, endpoint и retention должны отличать её от production. Отсутствие требуемого сигнала должно останавливать gate, а не считаться нулём ошибок.
Обоснование¶
Release gate нельзя проверить в среде, не создающей его входные данные.
Проверка¶
- генерация каждого gate signal в non-production;
- отключение транспорта и проверка остановки продвижения;
- поиск сигнала по environment/version.
Исключения¶
Недоступный только в production бизнес-сигнал MAY заменяться заранее определённым синтетическим критерием.