Skip to main content
The observability integration connects Luumen to your existing telemetry platform — Dynatrace, Datadog, New Relic, or another provider — so the agent’s host data is enriched with metrics, traces, and events from the tooling your team already operates. Once connected, the telemetry feeds two parts of the platform: advanced AI triage on the engineering side, and report views on the analytics side.

​
Supported providers

Built-in:
  • Dynatrace
Other providers — Datadog, New Relic, and similar — are supported through the same integration pattern. They’re enabled and configured during white-glove onboarding rather than being self-serve today. If your observability stack isn’t on this list, raise it with your account team. The integration model is the same regardless of provider (API key in, telemetry out), so adding a new one is a scoped piece of work rather than a custom build.

​
What it does

Per-host telemetry enrichment

Pull metrics and events from your observability platform per host. Memory, CPU, disk, network, response latencies, error rates — whatever the platform exposes for that host.

Advanced AI triage

LuumenAI uses observability data alongside agent-collected properties when investigating an incident. “Is CPU saturated on this host?” gets answered from live telemetry, not just a periodic snapshot.

Report views

Report views in the Luumen UI combine compliance data with observability data — for example, a single view of pass/fail status plus performance trends across a host group.

Custom views via white-glove

Apiphani’s white-glove service can build custom report views tailored to your team’s KPIs and the specific metrics your provider exposes.

​
How it powers AI triage

When you start a triage session in Luumen — from a ServiceNow incident, a failed compliance check, or directly from a host — the AI has both data sources to draw on:
  • Agent-collected properties for what the host looks like (OS version, installed packages, and any application-specific properties from integrations like SAP).
  • Observability data for how the host is behaving right now (CPU, memory, request latencies, error spikes, dependency health).
This combination changes what the AI can answer. Without observability, “Why is this host slow?” requires the AI to propose investigation commands you approve and run. With observability, the AI can read live metrics directly and skip straight to “CPU has been pinned at 100% since 14:32, here’s what’s running on it” — pulling the relevant chart into the triage thread for context. The same human-in-the-loop pattern still applies: the AI surfaces data and proposes actions, you approve commands before they run.

​
Report views

Each connected observability provider exposes a set of metrics Luumen can include in report views in the web UI. The built-in views cover common cases — fleet-wide CPU, memory, and disk trends; per-host availability over time; performance correlated with compliance status — and you can switch a view’s scope between host groups or individual hosts. Custom views are part of the white-glove service. If your team has specific KPIs that aren’t covered by the built-in views (e.g., “SAP HANA memory ratio per landscape, weighted by user count”), we can build those views during onboarding or as a follow-on engagement. See Support.

​
What you’ll set up

Connection setup is a single field per provider:
  • An API key from the observability provider with read access to the data you want Luumen to consume. Most providers have a scoped API-key concept — restrict the key to read-only on the relevant scopes if your security model requires it.
Paste the API key into the integration settings in Luumen and save. That’s the entire connection. Apiphani engineers will walk you through generating the key on the provider side during onboarding if you haven’t done it before.

​
Audit and control

  • Read-only by default. Luumen consumes observability data; it doesn’t push metrics back to the provider.
  • API key rotation. Rotate the key on the provider side, paste the new value into Luumen, and save. The integration picks up the new key on its next call. No agent restart required.
  • Per-workspace scope. Each Luumen workspace holds its own observability connection. Telemetry isn’t shared across workspaces or customers.

​
Limits

  • Provider feature parity isn’t 1:1. Built-in integrations expose a normalized set of metrics across providers (CPU, memory, disk, etc.). Provider-specific concepts (Dynatrace problems, Datadog monitors, New Relic NRQL) are surfaced where they map cleanly and noted as provider-specific where they don’t.
  • Host matching is hostname-based. Luumen matches observability hosts to its own hosts by hostname. If your observability platform uses different hostnames than the agent reports, mapping needs to be configured during onboarding.
  • Historical data depth follows the provider. Luumen displays whatever depth of history the provider retains and the API key has access to.