Lakerunner

Connect Cardinal to Lakerunner for querying logs, metrics, and configuring alerts.

Overview

Lakerunner is Cardinal’s observability data platform. With this integration, the AI agent can:

• Query logs and metrics using natural language
• Explore available data sources, fields, and time ranges
• Receive alerts from Lakerunner via webhook and respond to incidents automatically

Maestro auto-provisions the alert webhook target on Lakerunner whenever alerting is enabled on the deployment, the admin API URL is set, and the admin API key is valid. There is no manual three-step setup anymore.

Capabilities

Two deployment models

Cardinal-managed (SaaS)

The Cardinal SaaS operator pre-configures the Lakerunner deployment in the superadmin Managed Lakerunner Instances page. URLs and admin credentials live on the deployment row. Once Alerting available on this deployment is checked there, every linked org integration auto- provisions on its next save (or immediately, for new links).

Org owners do not see (and cannot set) the admin URL or key for managed Lakerunners.

Org-private (BYO)

The org owner connects their own Lakerunner instance.

By default the admin API URL must be HTTPS. For self-hosted deployments that genuinely need HTTP, the superadmin can set the per-integration setting lakerunner-allow-insecure-admin-api to true via the admin API. Cardinal-fleet-operated deployments never set this override.

Perch operator key (BYO Lakerunner only)

If your Lakerunner deployment also runs the Perch operator and you’ve pointed perch.maestro.url at this Maestro, you must hand Perch an ingest API key that this Maestro recognises — Perch sends collector inventory to your local Maestro, not to app.cardinalhq.io.

1. After provisioning the integration above, copy the active ingest API key from Settings → Integrations → Lakerunner.

2. Create a Secret in the namespace where Lakerunner runs:

   kubectl create secret generic perch-local-maestro-key \
     --from-literal=api-key='<paste plaintext key>'

3. Reference it from the Lakerunner Helm values:

   perch:
     maestro:
       url: "http://maestro.<your-maestro-ns>.svc.cluster.local:4200"
       apiKey:
         existingSecret: "perch-local-maestro-key"

SaaS deployments (perch.maestro.url left at https://app.cardinalhq.io) do not need this — the license-derived key is already valid there.

Auto-provisioning behavior

When the gate above passes, maestro:

1. Probes Lakerunner with GET /api/v1/alert/webhook-targets to confirm the admin URL is reachable, the key is valid, and the alerting workers are wired (4xx classifies the integration as invalid_admin_credentials or not_supported; transient errors classify as provisioning_error and retry on the next reconcile tick).
2. Upserts a webhook target on Lakerunner via PUT /api/v1/alert/webhook-target keyed on notifier_id = integration.id (the Cardinal integration’s UUID — stable, idempotent under retries).
3. Stores the most recent callback URL on the integration row so a subsequent change to MAESTRO_BASE_URL is detected and re-provisioned by the reconcile cron (default cadence: 1 hour).

The status badge on the integration shows one of:

If the integration sits in any non-connected, non-disabled state for more than one reconcile tick, an org owner can click Reconnect alerting in the integration page to enqueue an immediate retry (rate-limited to 1/minute per integration).

On delete

Deleting a Lakerunner integration (org owner DELETE, superadmin DELETE, managed-instance unlink, or org delete) runs the same pre-hook in every case:

1. Sync-delete every alert rule the integration owns on Lakerunner. If any deletion fails the request returns 502 and the local state is not destroyed — fix the upstream issue and retry.
2. Hard-delete local rules.
3. Deprovision the webhook target on Lakerunner.

Migration from manual setup

If you previously wired the webhook by hand (paste shared secret in Cardinal, create webhook target on Lakerunner, copy Notifier ID back), the migration leaves your settings.notifierId in place and your integration in alerting_status='connected' so existing rules continue to flow through the legacy notifier id. New rules created after the migration use integration.id as the notifier id once the next provision runs (e.g. on a deployment URL/key change or on reconnect).