Loki
Connect your own Grafana Loki (self-hosted or otherwise) as a source the investigator agent reads from during an incident, the same way it reads Datadog, Coralogix, or Prometheus.
Why logs, not just metrics
A metric can show that something broke; the log line is frequently what shows why — a stack trace, a specific error message, a request id. Connecting Loki gives the investigator agent that evidence directly, alongside whatever metrics sources you've already connected.
Connecting a Loki as a queryable source
An organization connects Loki the same way every other telemetry source is connected: through the integrations wizard. Once connected, the investigator agent can query it during an incident with zero source-specific agent code — the same dynamic-discovery mechanism every other source uses (see Integrations architecture).
What you'll need
- A Loki server reachable FROM Landfall — the same genuine limitation already documented for Prometheus: a Loki running inside your own private network is typically not reachable from a hosted Landfall the way a public SaaS API is.
- If your Loki runs multi-tenant (the common case for a customer-run or Grafana Cloud Loki — Loki's own default), its tenant id, sent as X-Scope-OrgID on every request.
- An admin on your Landfall organization, to save the connection under Settings → Integrations.
Settings → Integrations → Loki
Enter your Loki server's base URL. If it's multi-tenant, add the tenant id. If it sits behind auth, add either a bearer token or a basic-auth username/password — leave all three blank for an unauthenticated, single-tenant instance.
Settings → Integrations → Loki
Test connection
Landfall calls your Loki's own /loki/api/v1/labels endpoint before saving anything — deliberately not /ready, which answers before Loki checks tenancy or auth at all. A Loki that can't be reached, or that rejects the supplied tenant id or credentials, is refused outright rather than stored as "configured but unverified."
Settings → Integrations → Loki
Save integration
Loki now shows Configured alongside your organization's other connectors, and appears in the capability listing an incident's investigator (human or Beacon) can query against.
Settings → Integrations
- Confirm the base URL is reachable FROM wherever core-api runs, not just from your own browser/laptop — the two are frequently on different networks.
- A 401/403 usually means a missing or wrong tenant id — most self-hosted and every Grafana Cloud Loki run multi-tenant by default.
- If your Loki requires auth, confirm you've set exactly one of bearer token OR basic auth; a bearer token takes precedence when both are present.
- The base URL should be the origin only (e.g. http://loki.internal:3100) — Landfall appends /loki/api/v1/… itself.
Alerting → incidents
Connecting Loki (above) lets the investigator agent read your logs during an investigation. Opening an incident automatically the moment a log-pattern condition fires is a separate, independent capability, built on Loki's own bundled ruler — which notifies through the exact same Alertmanager webhook a Prometheus alerting rule uses. See Triggering Integrations → Alertmanager for that setup, including Loki's own addition to it. The two are independent; most teams eventually set up both.
Reference
| Field | Value |
|---|---|
| Base URL | Your Loki server's origin, reachable from Landfall — required |
| Tenant ID | Optional; sent as X-Scope-OrgID. Required by most multi-tenant/Grafana Cloud Loki deployments. |
| Bearer token | Optional; sent as Authorization: Bearer |
| Basic auth username/password | Optional; ignored when a bearer token is set |
| Read operations | describeLogGroups (discover what log streams exist — /loki/api/v1/label/<label>/values, defaults to the container label), queryRange (/loki/api/v1/query_range, for correlating log lines against an incident's time window), queryInstant (/loki/api/v1/query), listLabels (/loki/api/v1/labels) |