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. Two things behave differently from a VM install:

• Your token is not in the config file. It lives in a Secret and Alloy reads it from the AURORAIQ_TOKEN environment variable, so the config 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.

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.