Top-level карта observability в BloodGPT: какие сигналы куда пишутся, по каким доменам, и где их искать когда «что-то упало». Это не одна система — это набор surfaces, каждая со своей аудиторией и своими fields. Эта страница — точка входа; глубокие разборы по доменам — на специализированных страницах.
Принцип
Karpathy-style decomposition — одна страница на одну surface. Каждая surface отвечает на свой вопрос: «что просило LLM», «что сделал k8s pod», «кто читал PHI», «как вёл себя юзер в UI». Корреляция между surfaces — по timestamp + trace/request-id (W3C traceparent пока не пропагандируется end-to-end, см. open).
Surfaces (по доменам)
LLM-flow
Trace LLM-call от browser до provider и обратно — самая сложная multi-hop surface. 4 слоя (Edge / Application+Langfuse / Gateway-Bifrost / Provider), visibility matrix, blind spots между слоями.
→ llm-observability-stack (status: active)
Сейчас покрывает: GCP LB access logs, Langfuse traces (где интегрирован), Bifrost SQLite logs.db, provider billing dashboards. Главные gap-ы: algo-hub без Langfuse, Bifrost prometheus plugin не активирован, frontend errors invisible.
Infrastructure (Kubernetes + GCP)
K8s pod events, container restarts, OOM kills, node pressure, scheduling, ConfigMap drift. GCP Cloud Monitoring — CPU/memory/network per pod + node. Cloud Logging для всего resource.type=k8s_*.
→ TBD page (placeholder)
Включает: kubectl events, GKE workload metrics, ArgoCD sync status, GCP Cloud Monitoring dashboards. Сейчас доступ — ad-hoc через kubectl / Cloud Console; собранной wiki-страницы нет.
Database & FHIR persistence
- Postgres (Cloud SQL): slow query log, connection-pool stats, transaction errors. Включается на инстансе через
cloudsql.enable_pgaudit/ log_min_duration_statement. - Google Healthcare API (FHIR): audit logs обязательны по HIPAA — кто что читал / писал, какой dataset, ответ от server. См. google-healthcare-api для деталей API.
- BigQuery export (FHIR → BQ stream): не observability per se, но позволяет SQL-аналитику на FHIR-state для backfill / drift detection. См. multi-tenant-fhir-storage.
→ TBD page (placeholder)
Audit (compliance-required)
- FHIR audit logs (см. выше) — HIPAA: PHI access trail.
- WorkOS audit log — auth events, role changes, organization mutations (см. workos).
- Stripe webhook events — billing trail, refunds, disputes.
Все три — отдельные внешние системы с своими retention/export. Корреляция через user-id / timestamp.
→ TBD page (placeholder)
Orchestration (Inngest)
Inngest dashboard: function runs, step retries, sleep / wait-for-event состояния, concurrency-queue depth. См. inngest для архитектуры.
Видно: какой function запустился по какому event, какие steps выполнились, что вернули, retries, durations. Сами LLM-calls внутри step’а — не видно (это на llm-observability-stack).
→ покрытие частично в inngest, отдельная observability-страница не нужна (Inngest UI = primary tool).
Product analytics (PostHog)
User-side surface: page views, feature usage, funnel conversion, A/B experiments, session recordings. Используется в b2c-dashboard как минимум. Не error tracking — для product decisions.
→ TBD page (placeholder)
Application errors (Sentry)
Stack traces при exceptions, breadcrumbs, source maps для frontend, performance monitoring. Не интегрирован ни в один сервис (TBD verify) — это известный gap.
→ TBD page / decision — нужно ли подключать; кто платит; где живёт; коммерческий vs OSS Glitchtip / OpenObserve.
Edge (Cloudflare)
CF analytics dashboard: cache hit ratio, geo distribution, DDoS / bot scores, rate-limit hits, WAF actions. Отдельная от GCP LB access logs (та фиксирует latency, эта — что CF делал).
→ ad-hoc через CF dashboard; нет собранной wiki-страницы.
Cross-cutting вопросы
Где начинать когда «что-то упало»
Грубо — по симптомам:
| Симптом | Где смотреть первым |
|---|---|
| LLM-call long-running / timeout / wrong output | llm-observability-stack |
| HTTP 5xx / latency spike на endpoint’е | GCP LB access logs (gcloud logging read) |
| Pod crashloops / OOM | kubectl events + Cloud Monitoring pod metrics |
| DB connection errors / slow queries | Cloud SQL → Insights / Query Insights |
| «Юзер не получил email / billing» | Stripe dashboard + Inngest function runs |
| «UI белый экран» | Browser DevTools / PostHog session recording / Sentry (когда будет) |
| «Кто-то посмотрел чужие данные» | FHIR audit logs + WorkOS audit |
Корреляция между surfaces
Сейчас сшивка делается вручную по timestamp. Каждая surface пишет свои timestamps, и при отладке инцидента приходится открывать несколько окон и совмещать по времени.
Открытый вопрос — пропагандировать W3C traceparent header end-to-end (browser → CF → app → bifrost → provider) и собирать distributed trace в Cloud Trace / Langfuse. Сейчас единого traceparent нет; даже Langfuse-traces не correlated с k8s logs или LB logs.
Связано
- llm-observability-stack — глубокий разбор LLM-flow surface
- llm-resilience-stack — что делаем чтобы transport-layer не сломался (парная: эта про visibility, та про reliability)
- llm-call-failure-classes — таксономия типов LLM-сбоев (транспорт/схема/семантика)
- bifrost / langfuse — entity-pages для двух главных surfaces в LLM-stack
- inngest — orchestration observability (его dashboard сам по себе primary tool)
- google-healthcare-api — FHIR audit context
- workos — auth audit context
Открытые вопросы
- Infrastructure observability page — собрать что у нас в Cloud Monitoring / kubectl events / ArgoCD как single coherent picture. Сейчас knowledge размазан по INFRA-репам и устным практикам.
- FHIR audit + WorkOS audit consolidation — compliance-страница описывающая что куда пишется, retention, как extract для аудиторских запросов. Не написана.
- Sentry или альтернатива — приоритет интеграции, какой сервис, кто платит. Нет ни решения, ни tracking ticket.
- Distributed tracing end-to-end — W3C
traceparentчерез всю цепочку, single trace view. Требует кода в каждом сервисе и backend (Cloud Trace / Tempo / Jaeger). Не trivial. - Cost observability — отдельный pillar: сколько мы тратим на LLM-tokens, BQ-storage, Cloud Logging ingestion, Langfuse plan. Сейчас разрозненно по billing-dashboards. Возможна single consolidated view.