Multi-DC telemetry ingress: edge-collector tier over the Koder VPN

accepted

Status

accepted — ratificada 2026-05-29 (owner escolheu o caminho de longo prazo explicitamente e aprovou via /k-go). Primeira instância de rollout = OBS-060 (exportador RSS/FD do kdb-gateway no s.r1.kdb-next-dev).

Summary

Telemetria (OTLP) de qualquer host em qualquer DC Koder chega ao fabric observe central (s.khost1, OBS-061067071) por um tier de collector de borda por DC que forwarda ao central sobre o Koder VPN (overlay WG privado). Não se expõe um endpoint OTLP público pra a frota própria; o ingress central fica bound só na interface do overlay.

Motivation

O fabric observe vive em s.khost1 (Vivver LAN); seus serviços (collector :4317/:4318, kdb-gateway, apm, log) são loopback-bound de propósito (superfície mínima). Mas a Koder é multi-DC: s.r1 (EVEO/Crescer LAN) e regiões futuras precisam empurrar telemetria pro central, e não há rota privada direta entre os DCs. observability-first R7.2 manda tudo em OTLP pro backend self-hosted; falta o "como cruza o DC".

Decision

Adotar a topologia OTel canônica agente → gateway com transporte privado:

  1. Collector de borda por DC. Cada DC roda um OTel Collector local; todos

    os hostsexportadores daquele DC pusham OTLP pra ele via LANloopback (sem exposição pública dentro do DC). O edge dá buffer + retry (resiliência: telemetria sobrevive a queda do central / da rede entre DCs).

  2. Forward sobre o Koder VPN. O edge forwarda ao collector central por um

    único canal cifrado do overlay WG. O ingress central (collector :4317/:4318) escuta só na interface do VPN — zero endpoint OTLP na internet pública.

  3. Um egress controlado por DC, não N hosts cada um precisando de

    reachability. DC novo = +1 edge collector + 1 peer WG (padrão uniforme).

Topologia concreta (confirmada 2026-05-29)

  • Hub WG = container wg em s.khost1 (10.200.0.1wg0, 10.0.1.131eth0;

    endpoint público 177.93.107.3:51820/udp; peers 10.200.0.0/24 — flow já é peer 10.200.0.30). Ref: reference_koder_vpn_hub.

  • Rollout por DC: peer WG novo → rota 10.200.0.0/24 → bridge Incus do

    observe no hub.

Restrição dura — colisão de IP entre DCs (achado OBS-073, 2026-05-29): o DC Crescer (EVEO) usa 10.0.0.0/16 incluindo 10.0.1.0/24 — o mesmo range do bridge Incus do s.khost1. Logo o endereço Incus do observe (10.0.1.27) é inalcançável de hosts Crescer (roteia pra LAN local). → O collector central DEVE ser alcançado por um endereço de overlay 10.200.0.x (port-forward no container wg: 10.200.0.1:4317 → 10.0.1.27:4317, ou 2ª iface no observe), nunca pelo IP do bridge. Regra geral da arquitetura: edge → central sempre via endereço de overlay WG, nunca via IP de bridge de DC (que pode colidir).

Alternatives considered

  • Ingress OTLP público (otlp.koder.dev via Jet + TLS + mTLS/API-key).

    Reachability trivial de qualquer lugar, mas superfície pública permanente num dado sensível (telemetria). Rejeitado como default pra a frota própria; reservado como fallback só pra fontes que não podem entrar na VPN (host de cliente/terceiro). Mais fraco em security.kmd (superfície mínima).

  • Peer WG por-host. Cada host um peer direto. Imaturo: sem buffer de borda,

    N peers por DC, acoplamento à disponibilidade cross-DC. O edge-collector-por- DC é a forma certa.

  • Expor o collector central em 0.0.0.0 + firewall. Frágil (depende só de

    nft), ainda superfície de rede; o overlay cifrado é superior.

Rollout

Faseado, começando pela necessidade real (OBS-060 / kdb#728 S3/S4):

  1. s.r1 (Crescer DC) — piloto. Edge collector no container kdb-next-dev;

    exportador (koder-kdb-rssfd-exporter, já pronto) pusha pro edge em localhost; edge forwarda ao central via VPN. Extensão da VPN = ticket infra/net (peer + rota; mudança de produção no hub compartilhado → deliberada, janela própria).

  2. Demais DCs/hosts adotam o mesmo padrão sob demanda.
  3. Fallback público só se/quando surgir uma fonte fora-da-VPN (RFC adendo).

Consequences

  • + Segurança: nenhum endpoint OTLP público pra a frota própria.
  • + Resiliência (always-on): buffer/retry no edge; central pode cair sem

    perder telemetria.

  • + Hyperscale: escala por DC, não por host.
  • + Reuse/self-hosted: reusa o Koder VPN existente; nada de SaaS/ingress novo.
  • − Custo operacional: um edge collector + peer WG por DC (aceito; é o preço

    da superfície mínima + resiliência).

  • Risco de rollout: editar o hub WG compartilhado afeta todos os peers →

    mudança deliberada com verificação (não improvisar).

References

  • policies/observability-first.kmd R7.2/§7 (OTLP, backend self-hosted)
  • policies/security.kmd (HTTPS-only, superfície mínima) · policies/always-on.kmd

    (resiliênciamulti-região) · `policieshyperscale-first.kmd · reuse-first.kmd · self-hosted-first.kmd`

  • modules/observe-otlp-fabric.md (fabric central) · OBS-060 (piloto) ·

    reference_koder_vpn_hub