IBEX Harness
DocsBenchmarksBlogChangelogRoadmap
GitHub
IBEX Harness

Documentation

Architecture Decision RecordsADR-0002: Repository foundation bootstrapADR-0003: Branch protection and merge policyADR-0004: Protobuf and code generation policyADR-0005: Postgres migration strategyADR-0006: Auth protobuf contract (`ibex.auth.v1`)ADR-0007: Auth token validation implementationADR-0008: Security scanning and CI quality gatesADR-0009: Permission bitmap layoutADR-0010: Cryptography policyADR-0011: Proxy auth gRPC client and middlewareADR-0012: Proxy request normalization (OpenAI chat)ADR-0013: Proxy input validation and stable error envelopeADR-0014: Core domain migration sequencingADR-0015: Proxy rate limit skeleton (Phase 1)ADR-0016: Proxy agent identity verification (Phase 1)ADR-0017: Request ID and trace context strategy (Phase 1)ADR-0018: Graceful shutdown contract (Phase 1)ADR-0019: OpenTelemetry provider configuration (Phase 1)ADR-0020: Shared package boundaries — `packages/config` and `packages/apierror`ADR-0021: Prometheus Metric Catalog (Phase 1)ADR-0022: Health check contract (Phase 1)ADR-0023: Docs site architecture (Phase 1.5)ADR-0024: Benchmark data publishing modelADR-0025: LLM provider abstractionADR-0026: OpenAI client designADR-0027: Streaming dual-write strategyADR-0028: Auth cache designADR-0029: Token revocation propagation via Redis pub/subADR-0030: Directive versioning strategyADR-0031: System prompt injection strategyADR-0032: Session data model and retentionADR-0033: ClickHouse llm_traces schema and retentionADR-0034: Proxy overhead performance measurement methodologyADR-0035: Chat Idempotency-Key Redis dedupeADR-0038: Context assembly service design and gRPC contractADR-0039: Proxy Postgres ownership for session and directive storesADR-0040: Anthropic provider adapterADR-0041: Model capability registryADR-0042: Self-hosted OpenAI-compatible LLM adapterADR-0043: Tokenizer registry architectureADR-0044: Non-streaming response pipelineADR-0045: Streaming response transformationADR-0046: Embedder interface and profile registryADR-0047: Memory temporal validity foundationADR-0048: Memory multi-label categoriesADR-0049: Memory relationship graph readinessADR-0050: MCP server skeleton (transport, auth, audit)ADR-0051: Local LGTM observability stack (Phase 2.5 exit pull-forward)ADR-0052: Memory schema v2 expand (HNSW, quality columns)ADR-0053: Vector store abstraction and composite scoring v2
ADRs›ADR-0051: Local LGTM observability stack (Phase 2.5 exit pull-forward)
ADRs

ADR-0051: Local LGTM observability stack (Phase 2.5 exit pull-forward)

Architecture decision record 0051 — Docker Compose Prometheus/Grafana/Tempo/Loki/OTel Collector for Phase 2.5 exit; HA platform remains later.

ADR-0051: Local LGTM observability stack (Phase 2.5 exit pull-forward)

  • Status: Accepted
  • Date: 2026-08-25
  • Authors: IBEX Harness team
  • Milestone: 2.5.G7 Phase 2.5 exit gate

Context

Services already expose Prometheus /metrics (proxy, auth, embedder, mcp-memory) and Go services initialize OpenTelemetry (ADR-0019 / ADR-0021). MONITORING.md specifies Grafana dashboards (including Proxy Critical Path) and a full LGTM stack, but FILE_STRUCTURE.md / infra/README.md previously deferred Prometheus/Grafana/Loki/Tempo to “beyond Phase 5.”

Without a runnable collection plane, Phase 2.5 cannot prove operability: no graphs, no scrape targets, no local trace sink. Pulling a local/dev LGTM stack into the Phase 2.5 exit gate unblocks operators without claiming production HA observability is done.

Decision

1) Compose stack under infra/compose/observability/

Ship Prometheus, Grafana, Tempo, Loki, OpenTelemetry Collector, and Alertmanager as a dedicated compose project (separate from compose/dev data stores). Make targets: observability-up, observability-down, observability-smoke.

2) Configs as code under infra/monitoring/

Prometheus scrape + alert rules, OTel collector config, Tempo/Loki configs, Grafana datasource and dashboard provisioning. Dashboards cover only metrics that exist today (no Phase 3 memory/worker panels).

3) Thin Helm chart infra/helm/observability/

Kind/minikube parity for the same stack. Full ibex-harness application Helm remains Phase 4+.

4) What remains deferred

  • Multi-AZ / HA Prometheus, long-term object storage for Tempo/Loki
  • Full app ServiceMonitors for every future service
  • Sentry SaaS wiring
  • Memory/context/worker metric catalogs (Phase 3+)

Consequences

  • Operators can open Grafana locally and see Proxy Critical Path after smoke traffic.
  • infra/README.md timing for LGTM is updated: local stack = Phase 2.5 exit; org-wide hardening later.
  • Phase 2.5 exit criteria include make observability-up / make observability-smoke and ADR-0051.

Was this page helpful?

Edit on GitHub

Last updated on

PreviousADR-0050: MCP server skeleton (transport, auth, audit)NextADR-0052: Memory schema v2 expand (HNSW, quality columns)

On this page

  • Context
  • Decision
  • 1) Compose stack under infra/compose/observability/
  • 2) Configs as code under infra/monitoring/
  • 3) Thin Helm chart infra/helm/observability/
  • 4) What remains deferred
  • Consequences
0%