Open Architecture

Keep the agents. Change the backend.

Point the agents you already run at Kloudfuse and keep going. No new instrumentation, no re-deploying a fleet, no six-month migration before anyone sees a dashboard.

kloudfuse / ingest / live Running in your VPC
agentdatadog-agent v7 unchanged · endpoint repointed
agentotel-collector · prometheus · fluent bit
queryPromQL · LogQL · TraceQL · FuseQL
outwebhook → slack · pagerduty · ms teams
your agents stay · your data lands in your own lake

Most observability migrations die in the same place. Before anyone can evaluate the new platform, someone has to re-instrument the entire fleet.


Repoint one endpoint. Keep everything else.

Kloudfuse speaks the wire protocols your collectors already emit. Repoint the endpoint and the data arrives, with the same tags, the same metric names and the same fidelity.

Datadog Agent
metrics · logs · traces · events — native wire protocol
OpenTelemetry
collector · SDKs · zero-code
Prometheus
remote write · pushgateway
New Relic
trace ingestion — via OTel-compatible export
Elastic
APM agent · Filebeat — via OTel-compatible export
VictoriaMetrics
vmagent metrics
Fluent Bit · Fluentd
log pipelines
AWS · Azure · GCP
cloud service telemetry

Open at every layer, not just the ingest.

An open front door is easy to claim. What matters is whether your dashboards, your query languages and your data are still yours once the telemetry is inside.

Seamless integration

No new agents. No re-instrumentation.

Your collectors are already deployed, already tuned, and already approved by whoever had to sign off on them. Kloudfuse accepts what they send, so switching backends is a configuration change rather than a project.

  • Point an existing agent at a Kloudfuse endpoint and telemetry starts landing. Nothing to rebuild in your application code.
  • Run side by side during evaluation. Send to both backends, compare the same incident in each, and cut over when you are convinced.
  • Mixed fleets are the normal case. Datadog on one cluster, OpenTelemetry on another, Prometheus in front of everything, all correlated in one lake.
  • Because the agents do not change, neither does the security review you already passed to deploy them.
existing agent → kloudfuse → your lake
Your existing collectors
Datadog · OTel · Prometheus · Elastic · Fluent Bit
your VPC
Kloudfuse ingest
native protocol support, no translation layer to maintain
Unified data lake
one store · every signal · your RBAC
No-code migration

Your dashboards and alerts come with you.

The real cost of switching is not the data. It is the years of tuning inside dashboards and alert rules that nobody wants to rebuild by hand. Kloudfuse converts them rather than asking you to start over.

  • Existing dashboards and alerts convert without writing code, so the panels your on-call team knows are there on day one.
  • Grafana-compatible dashboards mean the ones you already maintain keep working against Kloudfuse as a data source.
  • Organizational knowledge survives the move. The thresholds someone tuned after a bad quarter are still the thresholds.
  • Onboarding is measured in days, not the quarters a hand-rebuilt migration usually takes.
migration · what carries over
01Dashboards · converted, not rebuilt
02Alert rules · thresholds preserved
03Metric names and tags · unchanged
04Agent config · endpoint only
05Runbooks · still valid

What you do not carry over: the per-host bill.

Open query languages

Query it in the language your team already knows.

A proprietary query language is a hiring problem and a lock-in problem at the same time. Kloudfuse ships its own analytics language, then supports the open ones your engineers learned somewhere else.

  • PromQL for metrics, LogQL for logs and TraceQL for traces, so existing queries, recording rules and dashboards keep working.
  • FuseQL for the analytics the open languages cannot express, including aggregation, parsing, joins across log fields and scheduled searches.
  • A GraphQL API and per-signal REST APIs for anything you want to drive programmatically.
  • New engineers are productive on the query surface immediately, because most of it is not ours.
PromQLLogQLTraceQLFuseQLGraphQL API
one lake · four query surfaces
PromQL
metrics, recording rules, existing dashboards
LogQL
log selectors and range aggregations
TraceQL
span search across distributed traces
FuseQL
parsing, aggregation and scheduled search over the same store

Same data lake · same RBAC · same retention.


Open on the way out, not just on the way in.

Telemetry that can only be looked at inside one console is still locked in. Kloudfuse pushes results into the tools where your team actually works, and exposes query endpoints for everything else.

The channels you already use

Alerts route to Slack, email and PagerDuty through standard contact points, so nobody has to watch a second console to find out something broke.

Webhooks and query endpoints

Send alerts to any endpoint you control, and pull results programmatically to drive custom workflows, reporting or an internal tool of your own.

Scheduled and shared

Schedule searches and reports so recurring questions answer themselves, and share the output with people who will never open the platform.


Future-proof

Your telemetry outlives your observability vendor.

Kloudfuse runs on an open observability data lake inside your own environment. The value of that shows up later, when someone asks a question the observability product was never built to answer.

  • The lake is yours. Point analytics, custom applications or an LLM at the same data without exporting it or paying to read it back.
  • Built on open standards throughout, so the data model is documented rather than reverse-engineered.
  • Service topology is derived from the telemetry itself, so dependency maps stay current without anyone maintaining them by hand.
  • Retention and archival are set by you, because the storage is in your account.
Explore the observability data lake
one lake · many consumers
your VPC
Observability data lake
metrics · logs · traces · events · RUM · profiles
Observability
dashboards, alerts, investigation
Custom workflows
webhooks, APIs, internal tooling
Analytics and AI
your own models, your own queries

Open by architecture. Verifiable on day one.

Most platforms are open at the edges they had to be and closed everywhere it matters commercially. These are the places that difference shows up.

  Proprietary stack Kloudfuse
Getting data in Their agent, deployed across your fleet The agents you already run, repointed
Cost of switching Re-instrument first, evaluate later Run side by side, then cut over
Dashboards and alerts Rebuilt by hand in the new tool Converted, with no code to write
Query language Proprietary, and only useful there PromQL, LogQL and TraceQL, plus FuseQL for the rest
Getting data out Export limits, egress fees, or no path at all Webhooks, query endpoints and a GraphQL API over your own store
Where the data lives The vendor's account, at the vendor's retention Your VPC, your storage, your retention policy
Reuse beyond observability Locked to the product that ingested it Open lake, available to analytics, applications and AI

What teams ask before they repoint an agent.

Do we have to replace our Datadog or OpenTelemetry agents?

No. Kloudfuse accepts what those agents already emit, so the change is the endpoint they send to. Your instrumentation, tags and metric names stay as they are.

Can we run Kloudfuse alongside our current platform during evaluation?

Yes, and it is the usual way teams start. Fan the same telemetry out to both backends, work a real incident in each, and decide with evidence rather than a bake-off deck.

What happens to the dashboards and alerts we have already tuned?

They convert without code. Kloudfuse is also Grafana-compatible as a data source, so dashboards your team maintains there keep working against the new backend.

Do we have to learn a new query language?

Only where you want more than the open languages give you. PromQL, LogQL and TraceQL work against the same store, and FuseQL covers the parsing, aggregation and scheduled search that sit outside them.

What is FuseQL?

FuseQL is Kloudfuse's query language for log analytics that open standards don't cover — parsing, aggregation, pattern extraction and scheduled search. It runs against the same lake as PromQL, LogQL and TraceQL, under the same access controls.

Can we get our data out again?

The data never left. Kloudfuse runs inside your VPC and stores telemetry in your own account, so access to it is a matter of your permissions rather than an export request.

Which notification channels are supported?

Standard contact points including Slack, email and PagerDuty, plus webhooks to any endpoint you control for anything that is not on that list.



Bring an incident. We'll bring the platform.

Thirty minutes on your telemetry. The cause, before the call ends.