There is a particular kind of tired that comes from installing a second version of something you already run. You already have logs going somewhere. You already have metrics scraping. It all works, you built it, and then a new tool shows up and wants to stand up its own copy of the exact same thing right next to yours. Now you have two log stores to reason about, two places a query might live, two things to keep alive on day two. That is not observability, that is duplication with extra steps.

Burrow does not make you do that. If you already run Loki for your logs or Prometheus for your metrics, Burrow can connect to what you already operate and query it, instead of installing a parallel stack beside it. Your agent gets read access to the logs and metrics you already keep, and it answers "how is my app doing?" and "why is my app slow?" from your real data. This post is about the connect path: when to reach for it, what it gives you, and how it respects the infrastructure you already own.

Two honest modes, not one blessed way

There is a companion piece to this one about installing Burrow's built in logs and metrics addons from scratch. That path is the right call when you are starting fresh and do not want to design a monitoring stack by hand: one command stands up VictoriaLogs for logs, another stands up VictoriaMetrics for metrics, and you are querying in a minute. It is genuinely nice when you have nothing yet.

But plenty of people are not starting from nothing. They already run Loki. They already run Prometheus. That stuff is load bearing, it is tuned, and the last thing they want is a tool telling them to rip it out. So Burrow ships two modes and treats them as equals:

  • Install a fresh addon. You have no logs or metrics backend yet, and you want Burrow to stand one up on the nodes you already pay for. VictoriaLogs for logs, VictoriaMetrics (with a small collector) for metrics. Nothing to design, nothing to wire.
  • Connect a backend you already run. You already operate Loki or Prometheus, and you want Burrow to point at it and query it, rather than install a second one. Your existing store stays the source of truth. Burrow just gets read access to it.

Both modes shipped in v0.4, and neither is the "real" one with the other as a fallback. If you have already built your logging and metrics, connecting to it is the first class path, not a consolation prize. The whole point is that you should not have to choose between using Burrow and keeping the tools you already invested in.

When to install, and when to connect

The decision is usually easy once you name it honestly.

Install the addon when you are greenfield. No log aggregation yet, no metrics collector, and you would rather not spend a weekend assembling one. Let Burrow stand up the built in stack on your own nodes and move on. You get a searchable log store and a metrics collector without designing a pipeline, and it costs you nothing beyond the nodes you are already running.

Connect when you already run the thing. You have a Loki instance your team relies on, or a Prometheus that is already scraping half your infrastructure. Do not install a second copy. Point Burrow at what you have. Your existing retention, your existing dashboards, your existing alerts all keep working exactly as they did, untouched, and Burrow reads from the same store your team already trusts.

Mix and match if that is your reality. Nothing forces you to pick one mode for both signals. It is completely normal to already run Prometheus for metrics but have no central logging yet. In that case you connect your Prometheus and install the logs addon. The two decisions are independent: choose per signal, based on what you already have, not based on some rule that both must match.

The rule of thumb is simple: if you already operate it, connect to it; if you do not have it yet and do not want to build it, install it. There is no penalty for either, and no lock in that makes the choice hard to reverse later.

What "connect" actually gives your agent

Connecting a backend is not about handing Burrow the keys to your monitoring stack. It is narrower and calmer than that. What connect gives your agent is read access to query, and nothing more. Burrow can ask your Loki "show me the error lines from the web app in the last hour" and ask your Prometheus "what is the request rate right now," read the answers back, and turn them into a plain language explanation for you. It does not reconfigure your store, it does not change your retention, it does not touch your alert rules. It reads.

That read access is what turns an agent from a guesser into something that can actually look. An AI coding agent is often great at writing your app and then goes blind the moment the code is running, because it cannot see what the live app is doing. Give it a way to query the logs and metrics you already keep, and the questions you care about get real answers from real data:

  • "Show me any 500 errors from my web app and figure out what happened."
  • "How is my app doing?"
  • "Why is my app slow?"

None of those require you to open a dashboard and go digging through panels. The agent runs the query against your connected backend, reads what comes back, and tells you in plain English: the endpoint that is throwing, the error that keeps repeating, the moment the latency climbed. You asked a question in words, you got an answer in words, and behind it was your own Loki or your own Prometheus doing the work it was already doing anyway.

And because it is reading your existing store, the answers are consistent with everything else you look at. The agent is not working from a private copy of the data that might drift from what your dashboards show. It is querying the same Loki your team greps, the same Prometheus your alerts fire from. When the agent says error rate is climbing, you can open your own grafana and see the same climb, because it is the same numbers.

The credentials stay where credentials should

Connecting to a backend means Burrow needs to authenticate to it, and that raises a fair question: where do those credentials live, and does the agent get to see them? The answer is the important part of this whole design.

Credentials for a connected backend flow through Burrow's own API. They do not travel through the agent channel, and they are never logged. When your agent runs a query, it is asking Burrow to run the query on its behalf, and Burrow holds the credential and makes the connection. The agent gets the results back. It never gets the secret that unlocked them. So the thing that can read your Loki is Burrow, acting on a request, not a credential sitting in the agent's context waiting to leak into a transcript.

This matters because the agent channel is the chattiest, most copied, most logged surface in the whole system. Prompts get saved, conversations get reviewed, context gets passed around. A credential that lives there is a credential that ends up in a dozen places you did not intend. Keeping backend credentials on Burrow's side of the line, out of the agent path entirely, is how connecting to your existing store stays a safe thing to do rather than a quiet way to spread secrets around. You keep root, you keep the credential, and Burrow uses it narrowly to read on your behalf.

Your database watches itself, either way

One nice thing carries over from the install path to the connect path without any extra effort. If you have attached a Postgres database to your app, you get database health for free the moment metrics are present, whether those metrics come from an installed collector or a connected Prometheus.

Postgres always exports its own metrics. So once there is a metrics backend in the picture, your database is scraped automatically: connection and transaction health, plus slow query statistics. You do not wire anything up for this. If you connected your existing Prometheus, and it is set up to scrape your Postgres the way most Prometheus setups are, that data is right there for the agent to query alongside everything else.

This closes a blind spot that trips up a lot of debugging. When a page feels slow, "is it the app or the database?" is usually a guess, and a guess is a bad place to start an investigation. With metrics present and Postgres exporting itself, it stops being a guess. The agent can look at connection health and slow query stats and tell you whether the database is fine or whether it is the thing dragging. That is the difference between "might be the database" and "the database is fine, it is this endpoint."

Respecting the infrastructure you already own

Underneath all of this is a posture worth saying out loud, because it is the reason the connect path exists at all. Burrow runs on your cluster, on nodes you already pay for. It is open source and self hosted, and you keep root the whole way through. That is the ownership story, and connecting to your existing backends is that story applied to observability.

Contrast it with the platform as a service shape, where you ship your app to someone else's platform and, along the way, ship your logs and metrics into their observability product too. That can be convenient, and for one small app it is genuinely simple. But it also means your operational data lives on their side, priced their way, retained on their terms, and if you ever leave you leave that history behind. The data about how your app behaves ends up owned by the platform, not by you.

Burrow's version keeps all of that on your side. The addons run on your own nodes. The connected backends are stores you already operate. Nothing about your logs or your metrics has to leave the infrastructure you control for the agent to read them. You are not renting visibility into your own app from a vendor. You already own the visibility. Burrow just makes it queryable in plain language, by you and by the agent you already trust, without inventing a single number that was not already there.

That last part is a promise worth being explicit about: Burrow does not fabricate metrics. Everything the agent reports comes from your connected store or your installed collector. If a number is not being collected, the agent will not conjure it. When it tells you the error rate, that is your Prometheus's count. When it shows you a log line, that is a real line from your Loki. There is no synthetic layer in between dressing things up. What you see is what your infrastructure actually recorded.

The shape of it, start to finish

Here is how the whole thing hangs together in practice, without pretending it is more complicated than it is.

If you are greenfield, you install:

burrow addon install logs
burrow addon install metrics

If you already run your own stack, you connect to it instead, and then the queries you and your agent run do not change. The commands that read logs and metrics stay the same whether the data lives in a Burrow installed addon or in the Loki and Prometheus you already operate. Only what sits behind them differs. That symmetry is deliberate: the surface your agent talks to is stable, so switching a backend from installed to connected, or the other way around, does not break the way you work.

And the everyday experience is a question, not a query language. You do not have to memorize log filters or metrics syntax to get value out of this. You ask:

burrow app logs web

for the recent output straight from the running app, which always works with nothing installed and nothing connected, and beyond that you just talk to your agent. "Show me any 500 errors from my web app and figure out what happened" goes to your connected backend, reads the real lines, and comes back with what happened. "Why is my app slow?" pulls the real numbers and points at the bottleneck. The connected store does the work; the agent does the translation; you get an answer in plain English.

Bring what you have

The honest summary is this. If you have already built your logging and metrics, you have done real work, and Burrow's job is to use that work, not duplicate it. Connect your Loki, connect your Prometheus, and your agent can query the exact stores you already trust, in plain language, without a second parallel stack quietly running beside the first. Credentials stay on Burrow's side, out of the agent path, never logged. The data stays on your nodes, owned by you. Your database gets watched for free the moment metrics are present. And if you are starting fresh instead, the install path is right there, one command per signal, on the infrastructure you already own.

Either way, the point is the same: "how is my app doing?" should always have a real answer close at hand, drawn from data you own, whether you are the one asking or your agent is the one answering. You should not have to run two of everything to get there.