See inside any stack.
Full-stack observability.
See inside any stack, any app, at any scale, anywhere. Monitor metrics, traces, and logs across your entire infrastructure. Built on OpenTelemetry and Prometheus. No vendor lock-in, ever.
MODE: KERNEL SOCKET DISCOVERY
Autonomous Sentinel
Continuously observing kernel sockets, client sessions, message streams, and agent tools.
Zero-Code Linux Kernel Observability
Kernel-level auto-discovery of microservices, TCP/UDP sockets, gRPC calls, and database transactions with zero application re-compilation.
The problem
The bill keeps growing.
The outage still takes all night.
Most teams did not choose a fragmented stack. It accumulated, a tool per signal, a vendor per contract, an agent per host, and every one of them is now load-bearing.
Every incident starts with a tab hunt
Metrics in one tool, traces in another, logs in a third. Correlating them is manual, it happens at 3am, and it is the part of an outage that takes the longest.
The bill scales faster than the traffic
Per-host and per-seat pricing turns growth into a procurement conversation, and proprietary agents mean the instrumentation you paid to write does not leave with you.
AI spend is invisible until the invoice
Model calls are the fastest-growing line item in most engineering budgets and the least instrumented. A runaway prompt is discovered by finance, not by monitoring.
The answer
One pipeline. Every signal. No black boxes.
Logs, metrics, traces and LLM calls travel the same durable path into the same store, so correlating them is a query rather than a project. Every layer is a technology you can read about, benchmark, and run yourself.
HTTP, gRPC, remote-write and zero-code eBPF tracing with <1% CPU overhead. Instrument with open SDKs or instant kernel-level capture.
One durable, replayable pipeline for every signal, paired with an intelligent edge collector for hosts and AI runtimes.
Columnar storage with materialized-view rollups; BM25 full-text search over logs.
The same stack, self-hosted with Docker Compose or Kubernetes whenever you want it.
Correlation is built in
A trace links to its own logs and metrics because they arrived together, not because someone configured a join.
Leaving costs you nothing
Open SDKs in, open formats out. The instrumentation you write here keeps working anywhere it is pointed.
Engineered for the hardest observability challenges
Explore how aiAxonIQ combines zero-code eBPF kernel instrumentation, streaming Kafka pipelines, real user monitoring, and Model Context Protocol (MCP) agents to defend reliability.
Closed-Loop Telemetry & Autonomous Agent Action
Synchronized telemetry pipeline connecting kernel-level eBPF probes, streaming message buffers, ClickHouse analytics, and AI agent execution.
The product
Three jobs, done properly
Tracing, log search and AI spend are where platforms are usually slow, expensive or missing, and under them, eleven surfaces reading the same data.
Kernel telemetry with eBPF zero-code
Capture HTTP, gRPC, database, and Redis socket calls directly from the Linux kernel using safe eBPF kprobes. Zero SDK modifications, zero container restarts, and sub-0.3% CPU overhead.
Explore axonIQzerocodeKeep every trace, not a sample
Store spans in ClickHouse columnar storage with materialized-view rollups, so dashboards stay fast over high-volume telemetry, and the trace you need at 3am is still there, fully correlated with its logs.
Explore APM & TracingReal user monitoring & Web Vitals
Measure Core Web Vitals (LCP, INP, CLS) across actual browser sessions. Session replay with client-side text masking correlates user UI hiccups directly to backend distributed spans.
Explore RUMAI insights & MCP agent tools
Connect Claude Code, Cursor, and autonomous engineering agents directly to your telemetry plane over the Model Context Protocol (2026-07-28 spec) with 25 secure, cost-guarded tools.
Explore MCP ServerReal-time metric pipelines
Ship metrics over OTLP or Prometheus remote-write into ClickHouse columnar storage. Materialized-view rollups keep aggregations fast over high-volume telemetry.
Learn more- Prometheus remote_write compatible ingestion
- ClickHouse storage with 1-minute and 1-hour rollups
- Multi-dimensional labels and aggregations
- Kafka-backed pipeline: durable and replayable
AI that shows its working
It tells you why, not just that
Detection is the easy half. The expensive part of an incident is the twenty minutes spent deciding which of forty graphs mattered, so that is the part the models work on.
Root cause, ranked and evidenced
Signals that moved together at onset are correlated into candidate causes, ordered by confidence, each one linked back to the traces, logs and metrics it came from. Never a single unexplained verdict.
Anomalies found statistically
Z-score and IQR detectors over your own baselines, plus Prophet forecasting for capacity planning. Methods you can name, argue with, and tune.
Ask in English, get SQL
Natural-language querying compiles to a query you can read before it runs, and retrieval over your own runbooks suggests the next step rather than inventing one.
Ranked hypotheses with the signals behind each. Every candidate links back to the traces, logs and metrics it was derived from.
Integrations
It already works with your stack
If it speaks OpenTelemetry or Prometheus remote-write, it works, every major language, framework and cloud, with no proprietary agent to install.
For the enterprise
Built multi-tenant. Not retrofitted.
Isolation, roles and audit trails are properties of the architecture rather than a tier that unlocks them. The controls a security review asks about are the same ones the free plan runs on.
Certifications, sub-processors and the current security posture are documented rather than badged.
Tenant isolation at ingest
Separation is enforced where data arrives, not filtered at query time. Per-tenant rate limits included.
RBAC with four roles
Owner, admin, editor and viewer, with team invites. SSO and SAML on the Enterprise plan.
Immutable audit log
Every tenant action recorded append-only, so a reliability or security review has something to read.
Runs in your own cluster
The same stack via Docker Compose or Kubernetes. Data residency becomes a deployment choice, not a negotiation.
For developers
Your first trace, in about two minutes
Open standards all the way down. Instrument with the OpenTelemetry SDK you would use anyway, point it at aiAxonIQ, and keep the instrumentation if you ever leave.
Install
npm install @opentelemetry/api @opentelemetry/auto-instrumentations-nodeConfigure
export OTEL_EXPORTER_OTLP_ENDPOINT="https://app.aiaxoniq.com/otlp"
export OTEL_EXPORTER_OTLP_HEADERS="x-license-key=YOUR_LICENSE_KEY"
export OTEL_SERVICE_NAME="my-service"Run
node --require @opentelemetry/auto-instrumentations-node/register your-app.jsIt is --require rather than an import at the top of your entry file: the hook has to install instrumentation before your application modules resolve. An import runs after the modules it needs to patch are already loaded, and produces an app that starts cleanly and emits nothing.
Install
pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a installopentelemetry-bootstrap inspects what you already import and installs instrumentation only for those libraries, so the list stays in step with your dependencies rather than with a snapshot of them.
Configure
export OTEL_EXPORTER_OTLP_ENDPOINT="https://app.aiaxoniq.com/otlp"
export OTEL_EXPORTER_OTLP_HEADERS="x-license-key=YOUR_LICENSE_KEY"
export OTEL_SERVICE_NAME="my-service"Run
opentelemetry-instrument python your_app.pyDownload the agent
curl -L -O https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jarConfigure
export OTEL_EXPORTER_OTLP_ENDPOINT="https://app.aiaxoniq.com/otlp"
export OTEL_EXPORTER_OTLP_HEADERS="x-license-key=YOUR_LICENSE_KEY"
export OTEL_SERVICE_NAME="my-service"Run
java -javaagent:./opentelemetry-javaagent.jar -jar your-app.jarInstall
go get go.opentelemetry.io/otel \
go.opentelemetry.io/otel/sdk \
go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttpGo has no runtime agent, the SDK is wired up in code. The environment variables below are still read by the exporter, so configuration stays identical to every other target.
Configure
export OTEL_EXPORTER_OTLP_ENDPOINT="https://app.aiaxoniq.com/otlp"
export OTEL_EXPORTER_OTLP_HEADERS="x-license-key=YOUR_LICENSE_KEY"
export OTEL_SERVICE_NAME="my-service"Run
go run .Install
dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocolConfigure
export OTEL_EXPORTER_OTLP_ENDPOINT="https://app.aiaxoniq.com/otlp"
export OTEL_EXPORTER_OTLP_HEADERS="x-license-key=YOUR_LICENSE_KEY"
export OTEL_SERVICE_NAME="my-service"Run
dotnet runAdd the collector
# values.yaml
config:
exporters:
otlphttp:
endpoint: https://app.aiaxoniq.com/otlp
headers:
x-license-key: YOUR_LICENSE_KEYOne collector per cluster receives from every pod, so applications keep talking to localhost and the credential lives in exactly one Secret.
Install
helm install otel-collector open-telemetry/opentelemetry-collector -f values.yamlAdd a remote-write target
# prometheus.yml
remote_write:
- url: https://app.aiaxoniq.com/otlp/api/v1/prom/write
headers:
x-license-key: YOUR_LICENSE_KEYAdditive: your existing Prometheus keeps scraping and storing exactly as it does now, and starts forwarding a copy. Nothing to migrate, and nothing to undo if you stop.
Reload
curl -X POST http://localhost:9090/-/reloadFull instrumentation guides, ingest endpoints and troubleshooting live in the SDK documentation.