Firetiger Setup

Firetiger Setup

Onboard this project to Firetiger with minimal user interaction: subscribe, wire up telemetry, connect integrations, register deployments, let discovery map the system, and create a monitoring agent. Make changes automatically; pause only when genuinely uncertain. Firetiger also ships two built-in MCP prompts — onboard-firetiger (this whole flow) and integrate-firetiger (SDK instrumentation) — that mirror these steps.

Step 1 — Authenticate & provision

Call get_ingest_credentials. It auto-provisions the org backend (credentials, storage) if needed and returns the OTLP endpoint + username/password. If the MCP tools aren't available, tell the user to connect the Firetiger MCP server (https://api.cloud.firetiger.com/mcp/v1) and sign in (Claude Code: /mcp → Firetiger → sign in), then retry. Build the Basic auth header as base64(username:password) for Step 3.

Step 2 — Subscribe

Check get_subscription_status:

• active / trialing → continue.
• none / canceled / past_due → call get_checkout_url (plan bootstrap is the free tier; growth is paid), open it for the user, and wait for them to finish before continuing.

(These tools appear only on deployments with billing enabled; skip this step if they're absent.)

Step 3 — Detect the stack

Explore the codebase to find telemetry sources and services Firetiger can connect to:

• Deployment platforms (log/trace drains): Vercel, Cloudflare, AWS, GCP.
• Telemetry sources: OpenTelemetry (@opentelemetry/*, opentelemetry-*, go.opentelemetry.io), Datadog (dd-trace, datadog), Prometheus (prometheus.yml), Vector (vector.toml).
• Databases: PostgreSQL / MySQL (Prisma, SQLAlchemy, connection strings), ClickHouse, Trino, Elasticsearch.
• Event & incident sources: GitHub (.git/config), SendGrid, Convex, Kafka, incident.io, PagerDuty.
• Language/framework (for OTEL auto-instrumentation): package.json → Node.js; requirements.txt / pyproject.toml → Python; go.mod → Go.

Step 4 — Wire up telemetry ingestion

Pick the path that matches what you detected. The ingest endpoint is https://ingest.cloud.firetiger.com, and all ingest is HTTP Basic auth with the Step 1 credentials ($USERNAME / $PASSWORD, or $AUTH_HEADER = base64(user:pass)). The full source menu — with endpoint paths — is in references/ingest-sources.md.

Step 5 — Connect integrations (incl. pull-based sources)

Integrations are Connections. Many customers rely on pull-based connections most of all — Firetiger queries into their existing Datadog, Prometheus, GCP metrics, and databases rather than ingesting from them. The full catalog, per-type config, and connect mechanism is in references/connections.md.

• A client agent creates most connections directly — schema (collection connections), then create with the connection_type and its config (DSN, API key, region…). Only GitHub/Slack/Linear differ: they use the OAuth tools onboard_github / onboard_slack / onboard_linear.
• GitHub first — required for deploy monitoring and discovery.
• Proactively connect pull-based sources you detected: databases (Postgres/MySQL/ClickHouse), observability backends (Datadog/PromQL/GCP Monitoring), cloud (AWS/GCP). Once connected, agents query them through the query tool — see the firetiger-query "Querying connected sources" reference.
• Action integrations: ask once — "Which do you use? Slack, Linear, PagerDuty, incident.io" — then connect.
• Any vendor without a dedicated connector (e.g. Axiom): use a generic OPENAPI/HTTP connection with a bearer token. Private databases need a NetworkTransport (Tailscale). Both in the reference.
• Warn about gaps. No integrations → the agent can monitor and analyze but can't act (Slack alerts, GitHub issues). Note specifics: no Slack → no alerts; no GitHub → no codebase search, no deploy tracking, no discovery.

Step 6 — Register deployments

Call get_deploy_credentials and wire a CI/CD step that POSTs deploy events (repository, environment, sha) to the returned endpoint with Basic auth, so monitors verify each release. Details in firetiger-monitor-deploy.

Step 7 — Let discovery run

Once GitHub + a telemetry/query source are connected (the "qualifying" pair), Firetiger auto-discovers Services (the customer's own software boundaries) and Providers (external dependencies — Postgres, Vercel, OpenAI, etc.) by triangulating connections, OTEL signals, and the connected repos, and recommends what to monitor. You don't build this by hand — connecting the qualifying pair unlocks it.

Step 8 — Create a monitoring agent

Use create_agent_with_goal with a goal tailored to the stack (or install a prebuilt catalog agent — see firetiger-create-agent):

• Next.js/React: "Monitor this Next.js app for API route errors, slow page loads, and DB query issues. Alert on error-rate spikes and p95 latency increases."
• Python API: "Monitor this Python API for request errors, slow endpoints, and exception patterns. Track DB performance and alert on anomalies."
• Go service: "Monitor this Go service for errors, goroutine issues, and latency; alert on degradation."

If the planner asks a question, answer from what you detected via send_agent_message on the plan session.

Step 9 — Summary

Show: files changed, env vars needed in prod, connections configured, telemetry sources wired, deploys registered, the agent created and its focus, discovered services/providers, and a dashboard link.

Common Mistakes

Related

• OTLP SDK instrumentation: firetiger-instrument.
• Deploy monitoring & the deployments API: firetiger-monitor-deploy.
• Agent & catalog configuration: firetiger-create-agent.
• Firetiger integration docs: https://docs.firetiger.com.