Skip to content

Observability

The observability stack is a shared dependency. Install it before (or at least alongside) application modules so metrics, logs, and traces have somewhere to go.

What it provides

Typical components in ams-helm-observability-stack include:

  • Grafana (dashboards and explore)
  • Metrics backend (for example Mimir)
  • Logs backend (for example Loki)
  • Traces backend (for example Tempo)
  • OpenTelemetry collector / Alloy agents as configured in chart values

Exact enablement flags live in the chart’s Azure release values — adjust for your environment size and retention needs.

Why modules and adapters need it

  • Application modules emit operational and product telemetry.
  • Adapters push upstream events into the OpenTelemetry path so AMS can correlate activity from Dify, LibreChat, Copilot, and similar systems.
  • Without observability, you can still run UIs, but troubleshooting and agent-lifecycle visibility become much harder.

Deploy outline

  1. Create the observability namespace (if not created by the chart).
  2. Prepare secrets (Grafana admin, object storage credentials, etc.) via Key Vault or Kubernetes Secrets.
  3. Edit release values for domain, storage, retention, and ingress paths if Grafana is exposed on the AMS host or a dedicated host.
  4. Install with Helm from an operator host that can reach the cluster API:
helm upgrade --install ams-observability ./ams-helm-observability-stack \
  --namespace observability \
  --create-namespace \
  -f providers/azure/release/values.yaml

Use your real chart path and value file names. The important part is a deliberate release values overlay — not copying internal Dev/QA GitOps files blindly.

After install

  • Confirm pods are Ready in the observability namespace.
  • Confirm Grafana (or your chosen UI) is reachable per your ingress design.
  • Note OTLP endpoints that adapters and apps should use; you will reference them in adapter values.