Modules

A module is one signal family, switched on or off as a whole. Turning a module off skips its storage schema, its API, its collection, and its screen in the UI — so a traces-only install carries none of the storage or CPU weight of logs or profiling.

Most modules are on by default — you turn them off, and the service map still lights up in minutes either way. Four ship off: green, mesh, cost and ai. Each is off for the same reason, which is what happens at upgrade: a default-on module would silently switch itself on for every existing install. Green depends on RAPL hardware, cost starts watching cluster-scoped objects and takes a lease, and mesh and ai would light up a navigation entry for infrastructure — a service mesh, a model — that most installs do not have.

The modules

Module	Covers	Switch
core	Service map, traces, and RED metrics	Always on — this is the wedge
logs	Log collection, search, and trace correlation	modules.logs.enabled
infra-metrics	Node and pod metrics, the sensor inventory	modules.infraMetrics.enabled
profiling	Continuous CPU profiling and flame graphs	modules.profiling.enabled
green	Per-service energy & carbon from CNCF Kepler	modules.green.enabled — off by default (needs RAPL; also opt in sensor.green.enabled, and it requires infra-metrics)
error-tracking	Deduplicated, triageable issues derived from spans and logs	modules.errorTracking.enabled
service-health	Group health with criticality tiers, rolled up from RED	modules.serviceHealth.enabled
alerting	Webhook notifications on health transitions	modules.alerting.enabled — inert until you configure rules
mesh	Proxy RED and control-plane health (mesh)	modules.mesh.enabled — off by default; the control-plane half also needs infra-metrics
cost	Reserved against used capacity (cost & waste)	modules.cost.enabled — off by default (also opt in sensor.agent.cluster.enabled, and it requires infra-metrics)
ai	Model calls, tokens and cost (AI) from the gen_ai.* spans you already send	modules.ai.enabled — off by default; owns no schema and needs no other module

RED metrics are derived from your traces, not from the metrics tables, so the Metrics view is part of core and stays available even with infra-metrics off.

:::caution The AI module does not gate prompt redaction gateway.genai.redactContent drops model message content whether or not you run the ai module — content arrives either way, so gating the protection on the screen would protect only the installs that went looking. See AI observability. :::

Turn a module off

# Traces + service map only — lighter storage, same 5-minute start.
helm upgrade --install avuruobs deploy/helm/avuruobs \
  --set modules.logs.enabled=false \
  --set modules.infraMetrics.enabled=false \
  --set modules.profiling.enabled=false

In Docker Compose, set the AVURUOBS_MODULES environment variable on the migrate and hub services to the comma-separated list you want (for example core,logs). An empty or unset value means every module.

What happens when a module is off

• Storage — its tables are never created, so it consumes no disk or write CPU. A module never creates materialized-view overhead you aren't using.
• API — its endpoints return 404. Clients discover the active set from GET /api/v1/capabilities.
• Collection — the sensor stops gathering that signal. A module is the master switch over the per-signal collection knobs: with profiling off, the profiler collects nothing even if its own toggle is on.
• UI — its sidebar entry disappears, and navigating straight to its page shows how to enable it instead of an error.

Turning a module back on

Set its value to true and run helm upgrade again. The schema migrator is idempotent: it applies the newly-active module's tables on the next run, and your existing data is untouched. Turning a module off leaves its tables in place — no data is dropped — it simply stops managing them.