Skip to main content

Frequently Asked Questions

General

What is InfraSage?

InfraSage is a self-hosted AIOps platform. It ingests metrics, logs, traces, and events from your Kubernetes infrastructure, runs ML-based anomaly detection, performs AI-powered root cause analysis, and can execute automated runbooks in response to incidents.

Is InfraSage an observability tool like Grafana or Prometheus?

Observability (metrics, logs, traces) is the data layer. InfraSage sits on top of that: it processes the data with ML and AI to tell you what's wrong and why, not just display it. You can run Grafana alongside InfraSage. They complement each other.

What data does InfraSage send externally?

When RCA is triggered, InfraSage sends a structured analytical prompt (service IDs, metric summaries, causal graph) to the Anthropic API. No raw logs, traces, or user data are included. You can disable this entirely by setting LLM_PROVIDER=none or pointing to a self-hosted LLM. See Data Residency.

Deployment & setup

How long does it take to deploy?

The Helm chart installs in under 5 minutes. Initial anomaly baselines build after 24 to 48 hours of data collection. See Quick Start.

What are the minimum infrastructure requirements?

For the small profile (up to 1M events/day): 4 vCPUs, 8GB RAM, 100GB storage. For production workloads, see Scale Profiles.

Does InfraSage require Kubernetes?

For self-hosted, yes. The platform is Kubernetes-native and deployed with Helm. InfraSage Cloud has no infrastructure requirements.

Can I run InfraSage on a single node?

Yes for development and evaluation. For production, distribute ClickHouse and Kafka across at least 2 nodes for resilience.

Can I use an external ClickHouse or Kafka?

Yes. Set CLICKHOUSE_ADDR, CLICKHOUSE_USER, and CLICKHOUSE_PASSWORD to point to your existing ClickHouse instance. Similarly for Kafka. This is useful if you already operate these as shared infrastructure.

Data & compliance

Is InfraSage GDPR-compliant?

When self-hosted in an EU VPC, yes: all data stays inside your environment. InfraSage, Inc. does not process your telemetry. If you use the Anthropic API for RCA, you should confirm Anthropic's data processing terms satisfy your DPA requirements, or disable the LLM integration entirely.

Do I need a BAA with InfraSage for HIPAA?

No. Because InfraSage is self-hosted and InfraSage, Inc. never processes your data, there is no business associate relationship requiring a BAA.

How long is data retained?

By default, 90 days for metrics and 30 days for logs. Both are configurable via environment variables. See Retention Policy docs.

Can I delete a specific tenant's data?

Yes, via the admin API:

curl -X DELETE http://infrasage:8080/api/v1/tenants/my-tenant \
-H "Authorization: Bearer $SUPER_ADMIN_JWT"

This purges all telemetry, anomalies, and RCA data for that tenant.

Telemetry ingestion & data custody

Does InfraSage need to ingest my raw telemetry to work?

Architecturally, InfraSage's "brain" doesn't run on raw data. Anomaly detection, baselines, embeddings, and KPI guarding all consume compact per-minute aggregates. Raw telemetry lands in a short-lived transit buffer whose jobs are (1) deriving those aggregates in-stream and (2) serving as the evidence window the RCA agent searches during an incident, meaning the logs, traces, and exemplars for the affected time range. The durable memory of the system is the aggregate layer, not the raw firehose.

We are building on this property: a bring-your-own-stack mode, still in development, where InfraSage pulls aggregates from your existing Prometheus, Datadog, or CloudWatch on a schedule and fetches incident evidence from your logging and tracing backends at question time, storing no raw telemetry at all. If you'd like to be a design partner for this mode, contact us.

Why would I ingest telemetry directly instead of connecting my existing observability stack?

Direct ingestion buys five things that querying an external stack cannot fully match:

  1. Evidence that works during your worst hour. Incidents are exactly when your observability stack is likely to be degraded too: a log storm slowing Elasticsearch, an API rate limit during a traffic spike. Locally ingested evidence answers in milliseconds regardless of what else is on fire.
  2. Deeper root-cause analysis. An agentic RCA runs dozens of log, trace, and metric queries per investigation. Local queries are fast and free, so the agent can afford to be thorough; external APIs add seconds of latency, rate limits, and a per-query cost that quietly pushes analyses to be shallower.
  3. Cross-signal analysis. Linking a metric spike to the specific traces inside it, discovering service topology from trace pairs, and mining log templates for novel-error detection all require the signals to live side by side. This is much of what turns "latency is up" into "this query, on this pod, since this deploy."
  4. Unsampled, unfiltered fidelity. What sits in an existing stack is post-processing: traces head-sampled at 1 to 10%, logs pre-filtered by cost-saving exclusion rules. Ingesting from the source (OpenTelemetry) builds detection baselines on what actually happened.
  5. Faster detection and retroactive depth. Streaming ingest detects in near-real-time (polling an external API bounds detection latency to the poll interval), computes high-cardinality per-environment/per-instance aggregates in-flight, and can recompute aggregates historically when you add a new detection dimension, instead of starting that dimension from zero.

The two modes aren't exclusive. A practical path many teams take: connect your existing stack first, then move your most incident-prone services onto direct OpenTelemetry ingestion, where the sharper detection and stack-independent evidence matter most.

If I ingest telemetry, who has custody of my data?

You do. Self-hosted InfraSage keeps everything inside your environment, and RCA sends only structured analytical summaries to the LLM provider, never raw logs or traces (see Data Residency). Raw telemetry itself is transient; long-term storage is the compact aggregate layer, with retention configurable per Retention Policy.

Integrations

Can I use InfraSage with my existing Prometheus setup?

Yes. InfraSage exposes a Prometheus remote-write endpoint at /api/v1/prometheus/remote_write. Add it as a remote_write target in your Prometheus config to forward metrics automatically.

Does InfraSage replace Prometheus + Grafana?

Not necessarily. InfraSage focuses on anomaly detection, RCA, and runbook automation. Many teams run InfraSage alongside Prometheus and Grafana: Grafana for dashboards and ad-hoc querying, InfraSage for AI-driven alerting and incident response.

Does InfraSage support OpenTelemetry?

Yes. The Ingestion Gateway accepts OTLP over HTTP and gRPC. See OpenTelemetry Integration.

Can I ingest from AWS CloudWatch?

Yes. InfraSage's integrationPoller polls CloudWatch metrics from EC2, RDS, Lambda, ALB, DynamoDB, S3, and SNS. See AWS CloudWatch.

Pricing

What is the difference between Free, Pro, and Enterprise?

FreeProEnterprise
Events/day100K10MUnlimited
Users325Unlimited
Tenants15Unlimited
RCA
Runbooks
SLANone99.9%99.99%

See Billing Plans for the full feature comparison.

What counts as an "event"?

Each individual telemetry record counts as one event: a metric data point, a log line, a trace span, or a custom event. Batch submissions count each item in the batch individually.

What does the Anthropic API cost?

InfraSage is built to use fewer LLM tokens than other AI SRE tools. Deterministic systems do the work before any model is called: the origin resolver, change enrichment, and anomaly scoring are all pure computation. The LLM investigates from evidence that has already been distilled, not from raw telemetry dumps. RCA runs only when a human or webhook asks (never automatically on every alert), lighter models handle ranking and drafting, responses are cached, and daily budget circuit breakers plus per-tenant rate limits bound the spend. Actual cost per analysis and 30-day spend are metered on the Insights page of your own console. Measure it there rather than trusting anyone's brochure, including ours. See Cost Optimization.

Anomaly detection & RCA

Why am I getting too many false-positive anomalies?

The most common cause is a Z-score threshold that's too low, or not enough baseline data. Try:

  1. Raise WATCHDOG_Z_SCORE_THRESHOLD to 3.5 or 4.0
  2. Wait 48 to 72 hours for adaptive thresholds to build a proper baseline
  3. Check if the affected service has irregular traffic patterns (cron jobs, batch processes)

See Anomaly Detection.

How long does RCA take?

Typically 15 to 30 seconds from anomaly declaration to a finished RCA. That covers causal graph construction, which is local and fast, and the LLM call, which takes roughly 10 to 20 seconds depending on Anthropic API latency.

Can I disable RCA for specific services?

Yes:

curl -X PUT http://infrasage:8080/api/v1/tenants/my-tenant/services/my-service/config \
-H "Authorization: Bearer $JWT" \
-d '{"rca_enabled": false}'

Does RCA work without the Anthropic API?

Yes. With LLM_PROVIDER=none, InfraSage still builds the causal graph, scores blast radius, and identifies affected services. The only thing skipped is the natural-language explanation.

Operations

How do I upgrade InfraSage?

helm repo update
helm upgrade infrasage infrasage/infrasage -n infrasage -f values.yaml

Check the Changelog for breaking changes before upgrading major versions.

What happens if ClickHouse goes down?

Ingestion buffers in Kafka (default 24-hour retention). Once ClickHouse recovers, the Telemetry Operator drains the backlog automatically. No telemetry data is lost within the Kafka retention window.

How do I scale InfraSage horizontally?

The Ingestion Gateway and AIops Engine are stateless, so you scale them by raising replica counts. ClickHouse scales vertically (larger nodes) or horizontally via sharding. See Scale Profiles.