Sending data to shoofi

The fastest path is the in-app onboarding wizard, which generates a ready-to-run Alloy config for your OS with your ingest token already baked in. Copy it, run Alloy, and your data starts flowing to your Grafana within a minute.

All ingest goes to push.shoofi.cloud over HTTPS:

# Metrics: Prometheus remote_write
https://push.shoofi.cloud/api/v1/push

# Metrics: OTLP / HTTP
https://push.shoofi.cloud/otlp/v1/metrics

# Auth: bearer token only. Do NOT set X-Scope-OrgID:
# the gateway derives your tenant from the token, server-side.
Authorization: Bearer <your-ingest-token>

Your bearer token is minted at onboarding and is the only credential. The gateway injects your tenant id server-side, so a client-supplied X-Scope-OrgID is ignored, so you can never read or write another tenant's data.

• Metrics via Prometheus remote_write (Alloy, Prometheus, Grafana Agent)
• Metrics via OTLP over HTTP (OpenTelemetry SDKs/collectors, HTTP exporter)

On Kubernetes, Alloy runs as a DaemonSet installed with the Grafana Helm chart. The onboarding page generates a Kubernetes variant of your config plus the exact commands. One thing behaves differently from a VM install:

• Where the token comes from. No config we generate contains your token, on any platform. On Kubernetes it lives in a Secret and Alloy reads it from the AURORAIQ_TOKEN environment variable; on a VM or in Docker it lives in /etc/shoofi/token, which you create. Either way the config file is safe in a ConfigMap or in git.

Pod metrics are opt-in. We only scrape pods that carry the prometheus.io/scrape annotation. This keeps your series count, and your bill, predictable. Annotate the pod template of any workload whose metrics you want:

spec:
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"     # required, opts the pod in
        prometheus.io/port: "8080"       # optional, metrics port
        prometheus.io/path: "/metrics"   # optional, defaults to /metrics

The Helm values we give you also mount the host's /proc, /sys and /. Without them Alloy would report the CPU, memory and disk of its own container instead of the node, which looks like real data but is not.

Once metrics arrive, a Clusters tab appears on your dashboard with node and pod health, the busiest pods by CPU and memory, restarts, and network traffic. Much of it comes from each node's kubelet, so it is there whether or not a pod opts in to the scrape annotation above.

Your token is not tied to one machine. Reuse it on every VM and every cluster you run — set a unique AURORAIQ_CLUSTER name per cluster and each shows up separately, with a picker to focus on one or see them all. Standalone VMs stay on the Instances tab; clusters on the Clusters tab.

Subscribe to alert rules on the Alerts page, then choose where they go on Destinations. Two channels are ready with no setup:

• Email — enter your address and you're done. Alerts arrive from shoofi; there is nothing to install or configure.
• Telegram — tap Connect Telegram, press Start in the bot, and we detect your chat automatically. For a team group, add the bot and send the short code shown in the dialog.

Every destination has a Send test button so you can confirm it works before a real alert fires. Route each destination to the severities you care about (or all of them).

Ingest is fronted by Cloudflare, which shapes what we can accept. These are hard constraints, not preferences:

• Batch size ≲ 90 MB per request; larger pushes are rejected (HTTP 413). Tune your agent's batch/queue size.
• 100-second request timeout; long pushes or queries are cut off (HTTP 524).
• HTTP/HTTPS only. No OTLP-gRPC, no StatsD, no syslog, no collectd, no raw TCP/UDP. If your OTEL exporter defaults to gRPC, switch it to the HTTP exporter.

A run is one invoke_agent trace. One trace that names three agents is one run for each of them, so the same trace can appear three times, once per agent.

What is not a run:

• create_agent — building an agent is not invoking one.
• A trace with only execute_tool or chat spans and no invocation.
• A trace too large for one query to return. These are counted and shown separately, never folded into the total.
• An archived agent — its runs stay in the Runs list and leave the charts.

Why your count may differ from another tool. Shoofi counts one run per trace. A tool that counts invoke_agent spans reports a larger number, because frameworks emit more than one invocation span per run — LangGraph emits two, and a multi-stage pipeline emits one per stage. Neither number is wrong; they count different things.

Where the numbers come from. The list and its counters are read from a table shoofi writes; the span detail of a single run is read from the trace store when you open it. That is why a run can still be listed after its trace is gone.

The delay. Shoofi re-reads the trace store every RUN_SYNC_INTERVAL_S seconds over a RUN_SYNC_WINDOW_S-second window. A finished run appears in the list, with its counters, in under RUN_VISIBILITY_SLO_SECONDS seconds in 95% of cases. The Runs page shows when it was last updated.

Runs still in progress are listed as running, with the counters seen so far. They are completed in place when they finish — the same row, not a second one. A run that never finishes stops being called running after RUNNING_MAX_AGE_S seconds.

When the trace expires. Traces are kept 168 hours. Run rows are kept RUN_RETENTION_DAYS days, so a run outlives its trace by about three weeks: the counters remain and the span detail does not. The run page says so, and gives the date the trace expired.

Per-tenant series and ingest-rate limits and retention depend on your plan. Your live usage against those limits is on the Usage page. During the private beta, please also read our beta terms & data-handling note.