DEV Community: Bronto

Fixing Observability Pricing for the AI Era

Patrick Londa — Wed, 29 Jul 2026 18:57:51 +0000

Authored by Trevor Parsons

Today, we're announcing new pricing for Bronto.

TL;DR:

$0.10 per GB ingested, $1 per TB searched — for any signal: logs, traces, or metrics. No per-host or per-metric charges. Retained for 12 months, always hot, with sub-second search.
It's designed to be disruptive, simple, predictable, and to align cost with customer value. It's over 100x more efficient than legacy pricing.

We're addressing a foundational issue our industry has failed to tackle: current pricing models aren't fit for purpose. They're out of whack from an overall cost perspective, don't align cost with value, and are designed to favor the vendor, not the customer. They're also hard to understand and wildly unpredictable, with teams regularly getting hit with nasty overage surprises.

Cost has been the biggest issue for observability customers for the past 15+ years, and vendors continue to willfully ignore it.

Observability costs routinely run at 20–30% of total infra spend. That leads to a familiar set of workarounds: dropping high-volume logs, cutting retention to 3, 7, or 15 days, sampling, archiving and rehydrating, building pipelines just to throw data away before it lands, or rolling your own observability on open source and inheriting all the management overhead.

One example that stuck with us: a company resized its hosts onto bigger AWS instances just to fight per-host pricing — even though that wasn't the right architecture for their system. They changed their infrastructure to suit their observability bill. That's how distorted this pricing has become.

Instead of tackling the problem head-on, vendors keep adding "features" on top of datastores that aren't fit for purpose. The latest wave is AI agents and automated workflows. Those capabilities are genuinely powerful and will help teams manage complex systems, reduce MTTR, and improve root-cause analysis — but if you build AI capabilities on top of fundamentally broken foundations, the cost problem only gets worse, especially as AI workloads drive even higher data volumes.

Legacy Pricing Is Broken

There are two core problems with legacy pricing.

First, it's roughly 10x too expensive no matter how you slice it. Vendors charge dollars per GB ingested and stored, when per-GB pricing needs to be at the level of cents per GB — so teams stop architecting around the cost. Observability spend should drop from ~30% of infra spend to under 5%, low enough that you stop engineering around it. On top of that, dollar-per-GB pricing is typically for only days of hot retention, meaning you're paying dearly for access to a sliver of your data — again, at least an order of magnitude off for an AI world where historical analysis over months or years should be the norm.

Second, it's a value problem. You pay to ingest and store, so the vendor gets paid whether or not you ever get value from the data. You may never log in, search, or add an alert — the vendor still gets paid. In logging especially, people describe their provider as an expensive datastore they never actually use. The model was built for the vendor, not the customer.

Enter Bronto — Pricing Built for the Customer, Not the Vendor

Built on BrontoDB, our custom-built observability datastore, Bronto drives massive efficiency in ingesting, storing, and analyzing observability data.

Bronto pricing: cents per GB, not dollars per GB.

$0.10 per GB ingested — any signal, logs, traces, or metrics. No per-host or per-metric charges. Retained for 12 months, always hot, with sub-second search.
$1 per TB searched — 5x cheaper than scanning the same data on AWS Athena, which runs $5 per TB.

If you ingest data and never search it, you pay very little. You pay more only when you get more value by searching across more data — incentives that line up with yours, not against them.

For enterprise plans, typical DevOps usage at scale comes in under a combined ingest-and-search cost of about $0.20 per GB (roughly $0.10 for ingest, ~$0.10 for search at the $1/TB rate). A free trial lets you verify exactly where you'd land with your own data.

100x–1000x More Efficient

Bronto's entry plan is built for startups, solo builders, and teams building something new: $25/month for 1TB ingested with 20x search, at 12-month retention — roughly $0.025 per GB for any signal, with no per-host costs.

Datadog runs about $2.60 per GB for 30-day retention. A team ingesting 1TB/month might pay around $2,600 with Datadog for 30 days of retention versus $25 with Bronto — 100x cheaper, with over 10x the retention on top, which works out to roughly 1000x more efficient. That's before even factoring in cost explosions from things like high-cardinality metrics.

At larger volumes, Bronto's $0.10/GB ingested plus $1/TB searched comes out to around $0.20 per GB all-in for a typical DevOps profile, with 12 months of retention — versus Datadog's $2.60 per GB at 30 days (assuming ~1KB events and 100% log indexing). Roughly 100x more efficient.

Simple. Predictable. No surprises.

Simple — one per-GB cost for any signal ingested, one per-TB cost for what you search, with 12-month retention by default.
Predictable — entry plans have generous built-in headroom; larger plans get a usage dashboard or direct support from the team.
No surprises — built-in usage tracking and alerting mean no end-of-month shocks, and data never stops flowing when you hit a limit — you'll just get a heads-up.

What Bronto Delivers

All your data in one place, with full coverage and no blind spots. Always-hot data at 12-month default retention. Seamless cross-correlation across logs, traces, and metrics without hopping between separate datastores (think Prometheus, Tempo, and Loki, each limited and disjointed in its own way). And AI on top, via Bronto's MCP server, Bronto Vibe, or Bronto's built-in investigation capabilities.

Try Bronto Today

Spin up a free trial and run the numbers against your own data, or read the full details at bronto.io/pricing.

Trust, Discovery, Context, Consistency: What AWS DevOps Agent Looks For in a Telemetry Layer

Patrick Londa — Wed, 29 Jul 2026 18:49:57 +0000

Authored by Stephen Crowley

AWS DevOps Agent was built for modern software environments: engineering teams running heterogeneous infrastructure, juggling multiple observability tools, and without enough bandwidth to manually investigate every service incident. Its GA announcement highlighted reductions in mean time to resolution from two hours to thirty minutes — but that kind of improvement only happens when the underlying telemetry data is clean, structured, and fast to query.

This is where Bronto comes in. Not as a point integration built specifically for AWS DevOps Agent, but as a telemetry layer designed from the ground up around the principles that make any AI-driven investigation successful: trust in every result, discovery before every query, full context in every response, and consistent behaviour across every dataset.

We put this to the test directly. In a side-by-side evaluation, the same system — the OpenTelemetry demo application — sent data simultaneously to Bronto, Elasticsearch/Lucene (via OpenSearch), and Grafana Loki, all exposed via their respective MCP integrations. AWS DevOps Agent ran the same incident investigation against all three, then we asked it to judge.

We gave it a deliberately neutral prompt, designed to let the agent reach its own conclusions based on what it had just experienced:

Compare Bronto, Elasticsearch/OpenSearch, and Grafana Loki for use by AI agents (like AWS DevOps Agent) performing incident investigation. Focus the comparison on what matters for AI agents, NOT human usability. Include Recommendations for AWS DevOps Agent. Do NOT focus on: Query syntax complexity (AI handles nested JSON fine), Human readability of responses, Nesting depth.

The prompt explicitly told the agent to ignore the things Bronto is often praised for by humans — simple query syntax, flat response structure, readable output. We wanted to know what mattered to the agent itself, working from its own experience querying all three systems during a live investigation.

Its verdict was unambiguous. For incident investigation, Bronto is the clear winner. The evaluation identified four factors that actually determine whether an AI agent can investigate reliably:

Silent failure risk — Does the system fail quietly with wrong results?
Data discovery — Can the agent explore before querying?
Response completeness — Does one query return enough context?
Deterministic behavior — Does the same query always produce the same behavior?

System	AI Agent Suitability	Primary Issue
Bronto	High (9.4/10)	None significant
Elasticsearch/Lucene	Medium (5.3/10)	Silent failures from case/mapping issues
Grafana Loki	Low (4.6/10)	Limited discovery, minimal context

1. Silent Failure Risk

The most critical factor for AI agents is not whether they can express a query — it's whether they can trust the result. When a query returns empty results, the agent must decide: is there genuinely no matching data, or did the query fail silently for some other reason? Unlike a human analyst who might notice something feels off and try a different approach, an AI agent treats an empty result as ground truth and continues its investigation on that basis.

Elasticsearch/Lucene uses case-sensitive keyword field matching by default. A filter written as { "term": { "service.name": "Checkout" } } returns zero results if the indexed value is checkout — and it does it silently, with no error. The same silent failure applies to wrong field types (.keyword vs analyzed), fields that exist in the data but weren't mapped at index setup time, and any variation in field naming between indices. The agent concludes "no data" when the reality is "query did not match."

Loki has fewer mapping complexities, but labels are case-sensitive and log content grep is case-sensitive by default. An agent querying {service_name="Checkout"} when the label value is checkout gets zero results with no signal that the label exists with a different casing.

Bronto returns a clear error for unknown field names. Its ILIKE operator handles any casing — $service.name = 'Checkout' matches checkout, CHECKOUT, and any other variant. When Bronto returns empty results, the agent can treat that as a trustworthy signal that no matching data exists.

Failure Type	Bronto	Elasticsearch/Lucene	Loki
Wrong case in query value	Still works (ILIKE)	Silent empty result	Silent empty result
Wrong case in field name	Clear error	Silent empty result	Silent empty result
Field doesn't exist	Clear error	Silent empty result	Silent empty result
Wrong field type (`.keyword` vs analyzed)	N/A (consistent)	Silent wrong results	N/A
Typo in field name	Clear error	Silent empty result	Silent empty result

In our evaluation, Elasticsearch/Lucene returned zero events for every error and warning query across cart, payment, and ad services — even though the events existed in the index. An agent relying on those results would have proceeded under the conclusion that no active errors existed, while multiple services were actively failing. Bronto returned all of them.

System	When Query Returns Empty	Agent Concludes	Actually Correct?
Bronto	No matching data exists	"No errors found"	Likely correct
Elasticsearch/Lucene	Unknown reason	"No errors found"	May be wrong
Loki	Unknown reason	"No errors found"	May be wrong

2. Data Discovery

Can the agent explore what data exists and verify a query will work before it runs it? This determines whether the agent enters an investigation with confidence or proceeds on assumptions that may silently be wrong.

Bronto treats discovery as a first-class workflow — and critically, it works across all data in Bronto, not just OpenTelemetry. The agent calls get_datasets() to get a named catalogue of every dataset. It calls get_keys(log_id="checkout") to list all searchable fields. It calls get_key_values(log_id="checkout", key="$severity_text") to enumerate the actual values present — ["INFO", "ERROR", "WARN"]. By the time the agent issues its first search query, it knows the field exists, knows what values are in it, and can form that query with confidence.

Elasticsearch/Lucene's discovery path is complex and unreliable. GET _cat/indices returns a raw index list. GET logs-checkout-*/_mapping returns hundreds of lines of nested JSON that describe field types but not values. To discover what values actually exist in a field, the agent must run a separate aggregation query — and must already know whether the field is .keyword or analyzed to construct it correctly.

Loki's discovery is limited to labels. list_loki_label_names() typically returns three or four labels: pod, service_name, stream. There is no way to discover the fields inside log content.

Capability	Bronto	Elasticsearch/Lucene	Loki
List available datasets	`get_datasets` (all sources)	`_cat/indices` (raw list)	Via labels only
List searchable fields	`get_keys` (simple list)	`_mapping` (complex nested JSON)	Labels only (3–5 fields)
List field values	`get_key_values`	Terms aggregation query	Label values only
Verify field exists before query	Easy, explicit	Must parse mapping	Cannot for log content
Works across non-OTEL data sources	Yes	Varies by index config	Not applicable
Zero-knowledge start	Yes	No	No

3. Response Completeness

Does a single query return enough context for the agent to understand what happened, identify impact, and decide what to investigate next?

Bronto returns row-based dense JSON where every event is a self-describing object. A single error event reliably includes service name, service version, pod name, node name, namespace, trace ID, and user ID:

{
  "@raw": "exporter export timeout: rpc error: code = Unavailable",
  "@time": "2026-05-04 11:36:56.845 UTC",
  "@status": "error",
  "attributes": {
    "$service.name": "checkout",
    "$service.version": "2.2.0",
    "$k8s.pod.name": "checkout-f86478f-xgclj",
    "$k8s.node.name": "ip-192-168-46-190.ec2.internal",
    "$trace_id": "367379916186c4759c7c226a0350408f",
    "$user_id": "dea7494c-4867-11f1-ab4e-6edbf8c21e43"
  }
}

In our live test, Bronto found 15 real error events in 3 queries, with root cause visible immediately: high memory usage causing exporter timeouts. Trace IDs were present on every event, allowing the agent to pivot to trace correlation without an additional query.

Elasticsearch/Lucene's response completeness depends entirely on what was mapped when the index was created. The response also wraps every hit in metadata (_index, _id, _score, _shards) that the agent must parse past before reaching the actual log data.

Loki returned zero application errors in the same test — only synthetic canary logs. Where it does return results, all structured context is embedded inside the raw log line string.

Context Needed	Bronto	Elasticsearch/Lucene	Loki
Error message	`@raw` field	`message` field	Log line
Service name	`$service.name`	If mapped	If label exists
Service version	`$service.version`	If mapped	Rarely available
Pod / node name	Indexed	If mapped	Rarely available
Trace ID	`$trace_id`	If mapped	Must parse log line
User ID	`$user_id`	If mapped	Must parse log line
Timestamp	Human-readable	ISO format	Nanoseconds

Investigation Task	Bronto	Elasticsearch/Lucene	Loki
Find error + full context	1 query	1–3 queries	3–5+ queries
Correlate with trace	0 additional (trace_id included)	0–1 additional	2+ additional
Identify user impact	0 additional (user_id included)	0–1 additional	2+ additional
Find related logs by trace	1 query	1 query	5+ queries (per service)

4. Deterministic Behavior

Does the agent's investigative workflow work consistently across different services and datasets, or must it learn a different approach for each index it encounters?

What is consistent in Bronto is the workflow the agent uses to deal with variation. Discovery is the deterministic part: get_datasets() always returns the catalogue, get_keys(log_id) always returns the actual fields present in that dataset, and get_key_values(log_id, key) always returns the actual values. That same three-call pattern works identically for an OTEL dataset, a syslog dataset, or a custom JSON ingest:

# OTEL service
get_keys("checkout") → [$service.name, $severity_text, $trace_id, ...]
search: "$severity_text ILIKE 'error'"

# Custom JSON ingest with a different schema
get_keys("legacy-app") → [app_name, log_level, request_id, ...]
search: "log_level ILIKE 'error'"

# Syslog
get_keys("network-devices") → [host, facility, severity, message, ...]
search: "severity ILIKE 'err' OR severity ILIKE 'crit'"

The fields differ but the workflow does not — so the agent never has to guess.

Elasticsearch/Lucene cannot make this guarantee. There is no enforced standard for field naming — one index might store service name as service.name.keyword, another as serviceName (analyzed), another as svc. Two indices with the same conceptual data can require materially different agent logic.

Aspect	Bronto	Elasticsearch/Lucene	Loki
Discovery workflow	Same 3 calls for any dataset	`_mapping` shape varies	Labels-only
Field types	Consistent within a dataset	Varies by mapping	N/A
Query behavior	Predictable	Depends on analyzers	Depends on labels
Cross-dataset patterns	Discover then query — works for any source	Per-index logic likely needed	Per-stream logic likely needed

What Each Platform Was Built For

Each of these platforms reflects the use case it was designed for — and none of them, except Bronto, were designed with AI agents in mind.

Elasticsearch/Lucene was built around a human at a dashboard. The Query DSL is JSON because it was meant to be assembled by Kibana on behalf of an analyst clicking through visualisations. Hand the same API to an agent, and the assumptions invert: silent case-sensitivity, mapping-dependent matching, and relevance ranking that buries rare events become failure modes.

Grafana Loki was built around a single bet on cost — index only labels, store everything else as opaque log lines, charge less than indexed alternatives. The same minimalism that keeps Loki cheap keeps it opaque to an agent that needs to discover fields, correlate by trace ID, or filter on high-cardinality attributes. The cost argument has weakened independently: Loki Cloud lists $0.50/GB ingested versus Bronto's $0.10/GB.

Bronto was built for AI agent investigation from the ground up. Discovery as a first-class workflow, case-insensitive matching by default, dense self-describing JSON responses, deterministic discovery patterns across heterogeneous data sources.

Factor	Weight	Bronto	Elasticsearch/Lucene	Loki
Silent failure risk	30%	9/10	4/10	5/10
Data discovery	25%	10/10	5/10	4/10
Response completeness	20%	10/10	7/10	3/10
Deterministic behavior	15%	9/10	5/10	5/10
Query simplicity	10%	9/10	6/10	7/10
Weighted total		9.4/10	5.3/10	4.6/10

Connecting Bronto to AWS DevOps Agent is straightforward: deploy Bronto's hosted MCP server, route your telemetry to it, and authorise the agent. Both are built on the same open standards, so it works the first time, with no custom skills or pre-configuration.

See It in Action

We recorded AWS DevOps Agent running a live incident investigation against Bronto — no pre-configuration, no custom skills, just the hosted MCP server connected and pointed at the OpenTelemetry demo.

The investigation completed in under a minute. Once started, the agent generated its investigation plan within eight seconds. Within sixty seconds, it had queried Bronto, identified that the ad service was experiencing a high error rate, followed the statement IDs to the specific log lines causing failures, and surfaced the symptom: ads were failing to load. After further analysis — scanning the full codebase and correlating what Bronto's logs revealed — the agent returned its root cause: the adFailure feature flag was controlled entirely by an external flagd service.

From alert to root cause, with the data layer doing exactly what it was designed to do.

Set Up AWS DevOps Agent with Bronto

Building on Vercel? Your Logs Now Have a Better Home

Patrick Londa — Wed, 22 Jul 2026 18:50:39 +0000

Authored by Adam Ogórek

Vercel is one of the breakout stories of the AI boom. From being a scrappy deployment tool on launch ten years ago, it is now the platform of choice for over 6 million developers, with 100,000 new signups every month. No surprise that it is now touching on Decacorn status at a $9.3B valuation.

That kind of adoption doesn't happen by accident — it's the result of a genuinely exceptional developer experience. Instant deployments, per-branch preview environments, a global CDN that just works, and a framework-defined model that deploys your app without you writing a line of config.

And the scope keeps widening. What started as the home for Next.js now covers most of the modern frontend ecosystem, zero-config backends for popular Python and TypeScript frameworks, and a full AI Cloud on top. If you're building a web or agentic app, Vercel is the obvious home for it.

Vercel's built-in observability is purpose-built for the deployment workflow — real-time, per-request, fast. Observability Plus includes up to 30 days of retention (with a 14-day query window) and richer performance breakdowns. What it doesn't cover is everything else telemetry data gets pulled into: investigating an incident that started three releases ago, running analytical queries over months of traffic, or letting an AI agent dig through raw events on your behalf.

That's where Bronto comes in.

Bronto + Vercel

Bronto now integrates directly with Vercel. Once your drain is configured, your logs and traces land alongside every other source in your stack, with:

12 months of hot retention, no sampling — every log fully indexed, queryable the same way at day one or day 300
Sub-second search over terabytes — the difference between running the query and deciding it's not worth the wait
Dashboards built for scale — long-range comparisons, percentile breakdowns, and an AI widget creator that builds charts from a plain-English prompt
AI investigation built in — when a monitor fires, Bronto can investigate autonomously and deliver a root-cause report as a follow-up; BrontoScope does the same for any error event, on demand
A richer exploration UI — SQL search, auto-parsing, automatic error detection, and live tail
Native tracing at scale — ingest traces from Vercel and other external sources alongside your logs, then pivot between them in a click

Setting It Up

Vercel exposes log data through log drains — a webhook-style forward of runtime logs, build logs, edge function output, and more to a custom endpoint. You can also drain web analytics data (page views, custom events, real user performance metrics) using the same setup.

Full setup instructions are on the Bronto Vercel docs page.

Note: Vercel log drains require a Pro or Enterprise plan.

What You Can Do with Bronto

Once your Vercel logs are in Bronto, they behave like any other log source.

Long-Term Performance Tracking

With web analytics data flowing in alongside your logs, you can track Core Web Vitals — TTFB, FCP, LCP, INP, CLS — over months rather than days. That's the difference between reacting to a spike and actually understanding whether your performance is trending in the right direction across releases.

Multi-Deployment Debugging

Some bugs don't show up in the last 30 minutes — they emerge gradually across a series of deployments. With a year of log history, you can search across deployment boundaries, correlate error rate changes with specific releases, and build a clearer picture of how your system has evolved over time.

Headless Access via MCP

Connect Claude (or any MCP-compatible agent) to your Bronto data and run natural-language analysis directly against your Vercel logs. Bronto's hosted MCP server streamlines common DevOps tasks like investigating unusual traffic.

Custom Instrumentation

You can also generate your own logs from within your Vercel application and ship them to Bronto alongside the platform logs — giving you far more flexibility than Vercel's built-in observability. If you're running an AI feature, you can track token usage, model costs, and recent prompts directly in a Bronto dashboard.

Build the Interface You Actually Want

When your data is in Bronto, you're not locked into a single UI. The Bronto REST API exposes everything our own interface is built on, which means you can build custom views on top of your Vercel data using whatever tool fits your workflow.

It's the same idea as with our Lovable integration: remix the baseline project, point it at your Vercel datasets, and prompt your way to a dashboard specific to your application. Want a scheduled weekly report of your Core Web Vitals? A view that correlates deployment events with error rate changes? Build it — the API is there.

A Note on Cost

Vercel charges $0.50/GB for data leaving through log drains — a platform cost regardless of where the logs end up. The good news: Bronto is priced as low as $0.10/GB at scale, which is 50–90% cheaper than incumbent solutions. So even with Vercel's egress factored in, you're still coming out well ahead of what you'd pay to keep the same data in a traditional log platform.

And because Bronto doesn't sample, index-select, or shunt old data into cold tiers, the cost you see is the cost of keeping everything hot, searchable, and retained for a year.

Connect your Vercel logs to Bronto in just a few minutes — no agents, no sampling, no surprises.

Read the Integration Guide

Bronto Hosted MCP Server

Patrick Londa — Mon, 08 Jun 2026 13:46:19 +0000

Authored by Ciaran McGauran

An earlier post, Bronto MCP Server, introduced Bronto's local MCP server and showed how AI clients can use log data to answer operational questions. That post focused on the developer-managed local setup: run the server yourself, connect it to Bronto with an API key, and let clients like Claude Code query logs through MCP tools.

We now support a hosted MCP experience. Instead of running the MCP server yourself, you enable MCP access in the Bronto UI, sign in with your existing Bronto login method (OAuth, SSO, or Google Social), and connect supported MCP clients directly to Bronto's hosted MCP endpoint.

The result is a much simpler setup for teams that want the benefits of MCP without managing a local server process or distributing API keys to individual developers.

Why a Hosted MCP Server?

The local MCP server is still a good fit for individual developers — it's flexible, easy to inspect, and quick to wire up locally. But a hosted model solves a different set of problems:

No local server repos to clone, install, run, or keep up to date
No user-managed API keys for routine MCP access
Sign-in uses the same login methods already managed in Bronto
Access can be governed centrally in the Bronto UI
Teams can standardize on one managed MCP endpoint
Enables Bronto in environments and platforms that only support remote MCP (e.g. AWS DevOps Agent)

In short: the local version is better for local experimentation. The hosted version is better when you want Bronto to manage authentication and access, and when administrators need clear control over who can connect.

What Changes Compared to the Local Version?

At a tool level, the experience is familiar. Clients still get access to Bronto datasets, keys, values, log search, and metrics. What changes is how access is granted:

Administrators enable MCP login and control which sign-in methods are allowed
Users sign in through Bronto's normal authentication flow
MCP clients complete a browser-based OAuth flow
Bronto issues and validates the MCP access tokens

This keeps the user experience close to a normal SaaS sign-in flow, while still exposing Bronto data through MCP.

Setting Up the Hosted MCP Server

To enable MCP for your Bronto account and connect an MCP client, follow the instructions at docs.bronto.io/ai-features/hosted-mcp.

What Can You Ask It? Five CDN Log Examples

CDN logs are a particularly good example for the hosted MCP workflow: high volume, operationally important, and often the first place teams look when users report latency, origin instability, or unusual traffic. The examples below use Claude Opus 4.6.

Example 1: Find the Right CDN Datasets

Prompt:

Which datasets contain production CDN logs for our edge or delivery layer?

Teams often have multiple CDN-related datasets with non-obvious names. Before asking for regressions or cache behavior, you first want to know which datasets are actually carrying the production traffic.

The hosted MCP flow surfaced two production CDN and edge-layer datasets immediately:

Example 2: Look for Elevated Error Responses

Prompt:

In the last 30 minutes, look through our CDN logs for elevated 5xx responses and group them by host, path, and status code.

This is one of the fastest ways to distinguish between a widespread origin issue, a bad deploy affecting one route, a customer-specific path problem, and noisy but low-impact isolated errors.

Example 3: Investigate Latency Regressions

Prompt:

Compare CDN response-time metrics for the last hour against the previous hour and identify the hosts or paths with the largest regression.

Especially useful when users report "the site feels slower" but there's no obvious outage. Compare time windows, identify the worst regressions, and narrow quickly to the hosts and paths driving the slowdown.

Example 4: Look for Cache Effectiveness Problems

Prompt:

Search our CDN logs for cache-related fields and show whether cache miss rates increased in the last 24 hours.

This kind of question is often hard to answer quickly if you don't already know the exact field names in the dataset. MCP helps by discovering the relevant keys first, then narrowing the search. Identify where cache misses are increasing, see which paths are driving origin load, and determine whether the issue is broad or concentrated.

Example 5: Investigate Unusual Traffic

Prompt:

Use CDN logs from the last 15 minutes to find unusual request-volume spikes by client IP, user agent, host, and path.

Helps with bot traffic, scraper spikes, attack reconnaissance, and accidental client retry storms. Isolate sudden spikes, see which IPs or paths dominate, and decide quickly whether you're looking at bots, scrapers, or retry storms.

Closing Thoughts

The original Bronto MCP Server post showed that log data is a strong MCP use case. The hosted version makes that workflow much easier to operationalize.

Instead of asking users to install and run infrastructure locally, Bronto now provides the MCP endpoint directly — with sign-in and access managed through the product itself, just like the UI or direct API.

CDN logs are exactly the kind of data where this shines: large volumes, fast-moving operational questions, and investigations that benefit from moving fluidly from dataset discovery to raw search to concrete explanations.

If the first phase of MCP was proving that AI clients can be useful on top of log data, the hosted phase is about making that capability practical for more teams.

Set Up the Hosted MCP Server

How to Use A2A to Access Multiple Data Stores

Patrick Londa — Fri, 05 Jun 2026 17:44:21 +0000

Authored by David Tracey

This is Part 3 of a three-part series on the Agent2Agent (A2A) protocol. Part 1 introduced A2A concepts. Part 2 showed how to use MCP servers with Claude to query multiple data sources. This post extends that scenario by replacing Claude as the coordinator with a proper A2A "SuperAgent" that autonomously discovers and orchestrates specialist agents.

The scenario is the same: an employee leaves a company, and IT needs to verify their details have been removed from all systems — an HR database and a logging platform.

Architecture Overview

We'll build:

An A2A agent wrapping the Bronto MCP server (GetUsersAgent, port 9998)
An A2A agent wrapping the SQLite MCP server (GetEmployeesAgent, port 9999)
A "SuperAgent" (port 9000) that discovers both agents via their Agent Cards and routes requests
An A2A client that sends queries to the SuperAgent

Step 1: Create the A2A Bronto Agent

Each A2A agent has two files: __main__.py (Agent Card + server setup) and agent_executor.py (the actual logic).

`main.py`

import uvicorn
from a2a.server.apps import A2AStarletteApplication
from a2a.server.request_handlers import DefaultRequestHandler
from a2a.server.tasks import InMemoryTaskStore
from a2a.types import AgentCapabilities, AgentCard, AgentSkill
from agent_executor import BrontoAgentExecutor

if __name__ == '__main__':
    skill = AgentSkill(
        id='bronto_user_info',
        name='GetUsersAgent',
        description='Returns Information on Bronto Users',
        tags=['bronto users'],
        examples=['David', 'Gary'],
    )

    public_agent_card = AgentCard(
        name='GetUsersAgent',
        description='Uses Bronto REST API to get all users in an org',
        url='http://localhost:9998/',
        version='1.0.0',
        default_input_modes=['text'],
        default_output_modes=['text'],
        capabilities=AgentCapabilities(streaming=True),
        skills=[skill],
        supports_authenticated_extended_card=True,
    )

    request_handler = DefaultRequestHandler(
        agent_executor=BrontoAgentExecutor(),
        task_store=InMemoryTaskStore(),
    )

    server = A2AStarletteApplication(
        agent_card=public_agent_card,
        http_handler=request_handler,
    )

    uvicorn.run(server.build(), host='0.0.0.0', port=9998)

`agent_executor.py`

from a2a.server.agent_execution import AgentExecutor, RequestContext
from a2a.server.events import EventQueue
from a2a.utils import new_agent_text_message
from fastmcp import Client

class BrontoAgent:
    def __init__(self, mcp_server_url: str = "http://localhost:8080/sse"):
        self.mcp_client = Client(mcp_server_url)

    async def invoke(self) -> str:
        async with self.mcp_client as client:
            try:
                await client.ping()
                mcp_response = await client.call_tool("get_bronto_users")
                return f"A2A Server received: MCP Server replied: {mcp_response}"
            except Exception as e:
                return f"Error calling MCP server: {str(e)}"


class BrontoAgentExecutor(AgentExecutor):
    def __init__(self):
        self.agent = BrontoAgent()

    async def execute(self, context: RequestContext, event_queue: EventQueue) -> None:
        result = await self.agent.invoke()
        await event_queue.enqueue_event(new_agent_text_message(result))

    async def cancel(self, context: RequestContext, event_queue: EventQueue) -> None:
        raise Exception('cancel not supported')

The Employee DB A2A agent uses the same structure — just updating the MCP URL to port 8081, changing the tool name to get_employees, and updating the Agent Card name/description accordingly.

Step 2: Create the A2A SuperAgent

The SuperAgent discovers sub-agents via their Agent Cards and routes requests based on the query it receives.

`agent_executor.py` (key parts)

import httpx
import asyncio
from uuid import uuid4
from a2a.server.agent_execution import AgentExecutor, RequestContext
from a2a.server.events import EventQueue
from a2a.utils import new_agent_text_message
from a2a.client import A2ACardResolver, A2AClient
from a2a.types import MessageSendParams, SendMessageRequest

# Sub-agent URLs
sub_agents = [
    "http://localhost:9999",  # bronto get users
    "http://localhost:9998"   # get employees db
]

class SuperAgent:
    def __init__(self):
        self.subordinate_urls = sub_agents
        self.agent_registry = {}

    async def invoke(self) -> str:
        await self._discover_agents()
        return 'Agent Discovery Complete'

    async def _discover_agents(self):
        async with httpx.AsyncClient() as httpx_client:
            for url in self.subordinate_urls:
                resolver = A2ACardResolver(httpx_client=httpx_client, base_url=url)
                try:
                    public_card = await resolver.get_agent_card()
                    self.agent_registry[public_card.name] = {
                        "card": public_card,
                        "skills": [s.description for s in public_card.skills]
                    }
                    print(f"Discovered: {public_card.name}")
                except Exception as e:
                    print(f"Failed to discover agent at {url}: {e}")

    def bronto_agents(self):
        return [
            name for name, info in self.agent_registry.items()
            if any("bronto" in (s or "").lower() for s in info['skills'])
        ]

    def a2a_get_text_from_response(self, response) -> str:
        try:
            return response.root.result.parts[0].root.text
        except (AttributeError, IndexError) as e:
            return f"Could not extract text: {e}"


class SuperAgentExecutor(AgentExecutor):
    def __init__(self):
        self.agent = SuperAgent()

    async def execute(self, context: RequestContext, event_queue: EventQueue) -> None:
        await self.agent.invoke()

        async with httpx.AsyncClient() as client:
            agent_cmd = context.message.parts[0].root.text

            if "GetAllUserDetails" in agent_cmd:
                merged = await self.call_all_bronto_agents(client, event_queue)
                await event_queue.enqueue_event(new_agent_text_message(merged))
            elif "GetUsers" in agent_cmd:
                response = await self.call_named_agent(client, "GetUsersAgent")
                await event_queue.enqueue_event(new_agent_text_message(str(response)))
            elif "GetEmployees" in agent_cmd:
                response = await self.call_named_agent(client, "GetEmployeesAgent")
                await event_queue.enqueue_event(new_agent_text_message(str(response)))
            else:
                await event_queue.enqueue_event(
                    new_agent_text_message(f"Agent not found for {agent_cmd}")
                )

    async def call_named_agent(self, client, agent_name: str) -> str:
        target_agent = self.agent.agent_registry.get(agent_name)
        if not target_agent:
            return f"Unable to find '{agent_name}'."

        a2a_client = A2AClient(httpx_client=client, agent_card=target_agent["card"])

        request = SendMessageRequest(
            id=str(uuid4()),
            params=MessageSendParams(message={
                'role': 'user',
                'parts': [{'kind': 'text', 'text': 'bronto_user_info'}],
                'messageId': uuid4().hex,
            })
        )

        response = await a2a_client.send_message(request)
        return self.agent.a2a_get_text_from_response(response)

    async def call_all_bronto_agents(self, client, event_queue) -> str:
        names = self.agent.bronto_agents()
        if not names:
            return "No Bronto Agents found"

        results = await asyncio.gather(*(self.call_named_agent(client, n) for n in names))
        return "\n\n".join(f"--- Report from {n} ---\n{r}" for n, r in zip(names, results))

    async def cancel(self, context: RequestContext, event_queue: EventQueue) -> None:
        raise Exception('cancel not supported')

Step 3: Create the A2A Client

# client.py
import sys, asyncio, logging
from uuid import uuid4
import httpx
from a2a.client import A2ACardResolver, A2AClient
from a2a.types import MessageSendParams, SendMessageRequest, SendStreamingMessageRequest, Message, TextPart

async def main() -> None:
    base_url = 'http://localhost:9000'
    query_param = sys.argv[1] if len(sys.argv) > 1 else "GetAllUserInfo"

    async with httpx.AsyncClient() as httpx_client:
        resolver = A2ACardResolver(httpx_client=httpx_client, base_url=base_url)
        agent_card = await resolver.get_agent_card()

        client = A2AClient(httpx_client=httpx_client, agent_card=agent_card)

        user_message = Message(
            role='user',
            parts=[TextPart(text=query_param)],
            message_id=str(uuid4())
        )

        request = SendMessageRequest(
            id=str(uuid4()),
            params=MessageSendParams(message=user_message)
        )

        response = await client.send_message(request)
        print(response.model_dump_json(indent=2, exclude_none=True))

if __name__ == '__main__':
    asyncio.run(main())

Running the Full Demo

With the MCP servers running (from Part 2), start the A2A agents:

# Terminal 1: Bronto A2A agent (wraps Bronto MCP server)
cd bronto-get-users && uv run .

# Terminal 2: Employee DB A2A agent (wraps SQLite MCP server)
cd bronto-get-employees && uv run .

# Terminal 3: SuperAgent
cd superagent && uv run .

# Terminal 4: A2A Client
uv run . GetEmployees      # routes to Employee DB agent
uv run . GetUsers          # routes to Bronto agent
uv run . GetAllUserDetails # calls all agents and merges responses

The SuperAgent discovers available agents via their Agent Cards, then routes requests accordingly — without any hardcoded knowledge of what each agent does.

Summary

This three-part series has demonstrated that:

A2A standardizes agent communication — any A2A agent can discover and call any other A2A agent, regardless of who built it
MCP and A2A work together — MCP handles tool access, A2A handles agent-to-agent orchestration
Data doesn't need to move — logs stay in Bronto (optimized for high-volume fast search), HR data stays in SQL, each accessed by purpose-built agents

A more advanced SuperAgent could pass all Agent Card descriptions to an LLM for smarter routing, or filter/aggregate data from sub-agents before sending it to an LLM — reducing token usage and avoiding LLM hallucination from large raw datasets. The PostHog blog on optimizing agent costs illustrates why this matters.

Whether A2A becomes the universal standard for agent collaboration or the ecosystem remains a patchwork of custom MCP integrations remains to be seen — but Bronto's high-performance logging platform will be a first-class citizen in whichever world emerges.

Explore Bronto's AI Features

How to Use MCP Agents to Access Multiple Data Stores

Patrick Londa — Fri, 05 Jun 2026 17:43:54 +0000

Authored by David Tracey

This is Part 2 of a three-part series on the Agent2Agent (A2A) protocol and agentic data querying. Part 1 introduced A2A concepts and showed how to build a basic agent. This post demonstrates how easy it is to create two simple MCP agents to query different data sources and then analyse their outputs using Claude.

The scenario: when an employee leaves a company, the IT department needs to verify their details and access have been removed from all systems — in this case, an HR database and a logging platform. Traditionally, an IT person would check each system separately using custom tools. We'll show how MCP makes this dramatically simpler.

Architecture Overview

We'll create:

A Bronto REST API client to fetch users from Bronto
A SQLite database server representing HR data
Two MCP servers wrapping each data source
A demonstration of Claude using both MCP servers to answer a query

You can set up a 14-day free trial to test the Bronto REST API client used here.

Step 1: Create a Bronto REST API Client

# bronto_client.py
import json
import logging
from requests import Session
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

ADMIN_API_KEY = "SomeKey"
DATA_STORAGE_REGION = 'us'  # swap for your region

def get_users(s: Session) -> None:
    response = s.get(
        f"https://api.{DATA_STORAGE_REGION}.brontobytes.io/users",
        headers={'X-BRONTO-API-KEY': ADMIN_API_KEY}
    )
    print(json.dumps(response.json(), indent=4))

if __name__ == '__main__':
    session = Session()
    session.mount(
        f'https://api.{DATA_STORAGE_REGION}.brontobytes.io',
        HTTPAdapter(max_retries=Retry(total=3, backoff_factor=1,
                                      status_forcelist=[500, 502, 503, 504]))
    )
    get_users(session)

Run it:

python -m venv ./env && source ./env/bin/activate && pip install requests
python bronto_client.py

This returns a JSON response with all users in your Bronto account:

{
  "users": [
    {
      "id": "00000ffff",
      "first_name": "Paul",
      "last_name": "McCartney",
      "email": "paul@beatles.io",
      "roles": ["1111", "Admin"],
      "status": "ACTIVE",
      "tags": { "team": "fabfour" }
    }
  ]
}

Step 2: Create a Simple Employee Database

Install SQLite (or use brew install sqlite on Mac), then create the database:

sqlite3 bronto_employee.db

CREATE TABLE Employee (
  Id INTEGER PRIMARY KEY AUTOINCREMENT,
  FirstName TEXT NOT NULL,
  LastName TEXT NOT NULL,
  HireDate DATE NOT NULL
);

INSERT INTO Employee (FirstName, LastName, HireDate) VALUES
  ('Paul', 'McCartney', '2025-07-22'),
  ('Ringo', 'Starr', '2024-10-22'),
  ('George', 'Harrison', '2024-06-01'),
  ('John', 'Lennon', '2025-11-05');

Step 3: Wrap Both Sources as MCP Servers

We'll use FastMCP to expose each data source as an MCP tool.

Bronto MCP Server

# mcp-bronto-user-get.py
import json
from requests import Session
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Bronto Users")

ADMIN_API_KEY = "SomeKey"
DATA_STORAGE_REGION = 'us'

@mcp.tool()
def get_bronto_users():
    session = Session()
    session.mount(
        f'https://api.{DATA_STORAGE_REGION}.brontobytes.io',
        HTTPAdapter(max_retries=Retry(total=3, backoff_factor=1,
                                      status_forcelist=[500, 502, 503, 504]))
    )
    response = session.get(
        f"https://api.{DATA_STORAGE_REGION}.brontobytes.io/users",
        headers={'X-BRONTO-API-KEY': ADMIN_API_KEY}
    )
    return response.json()

if __name__ == '__main__':
    mcp.run(transport="sse", host="127.0.0.1", port=8080)

Run the server:

python -m venv ./env && source ./env/bin/activate && pip install fastmcp
fastmcp run mcp-bronto-user-get-server.py:mcp --transport sse --port 8080 --host 0.0.0.0

SQLite Employee MCP Server

# sqlite-server.py
from fastmcp import FastMCP
import sqlite3

mcp = FastMCP("Employee DB")

@mcp.tool()
def get_employees():
    conn = sqlite3.connect('/your_path/bronto_employee.db')
    cursor = conn.cursor()
    cursor.execute("SELECT LastName, FirstName FROM Employee ORDER BY HireDate DESC")
    results = cursor.fetchall()
    conn.close()
    return [{"LastName": ln, "FirstName": fn} for ln, fn in results]

if __name__ == '__main__':
    mcp.run()

Run the server on port 8081:

FastMCP run -p 8081 -t sse sqlite-test-server.py

Inspecting MCP Servers

The FastMCP CLI has a useful inspect command:

FastMCP inspect sqlite-test-server.py

This shows available tools, prompts, resources, and a full inspection log.

Step 4: Connect Both Servers to Claude

Install Claude locally, then add both MCP servers to Claude's config file. On Mac: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "EmployeeDB": {
      "command": "/your_path/mcp-env/bin/python",
      "args": ["/your_path/mcp-sqlite-server.py"],
      "description": "A simple MCP server to query employee data from a database"
    },
    "BrontoUsers": {
      "command": "/your_path/mcp-env/bin/python",
      "args": ["/your_path/mcp-bronto-user-get.py"],
      "description": "A simple MCP server to query Bronto Users"
    }
  }
}

Verify the servers are loaded in Claude under Settings → Developer → Local MCP Servers.

Step 5: Query Both Data Sources with One Prompt

Enter this prompt in Claude:

Show me Bronto employees, check if they have Bronto user accounts and summarise what you find

Claude uses both MCP servers and returns something like:

Summary of Bronto Employees and User Accounts

Employee Database: 4 employees total

Bronto User Accounts: 8 active user accounts

Employees WITH Bronto accounts (3 out of 4):

Paul McCartney — 2 accounts (@beatles.io, @wings.io) — Admin role
George Harrison — 2 accounts (@beatles.io, @wilburys.io) — Admin
John Lennon — 4 accounts (various domains) — Admin/ReadOnly roles

Employee WITHOUT Bronto account:

Ringo Starr — No user account found

Key Findings:

75% coverage — 3 of 4 employees have Bronto accounts
Most employees have multiple accounts (likely testing/different environments)
Additional users not in the employee list suggest external contractors or an incomplete employee list

Why This Matters

As this simple demo shows, MCP makes it easy to query multiple, disparate data sources from a single LLM prompt — without moving any data. Logs stay in Bronto (optimized for fast search at scale) and HR data stays in SQL (optimized for tabular queries). Each data source is accessed by an agent purpose-built for it.

This benefit compounds as the number of data stores and agents grows.

Part 3 will extend this scenario by adding A2A, giving us a "SuperAgent" that can autonomously discover and orchestrate these data source agents without relying on Claude as the coordinator.

Start a Free Bronto Trial

Introduction to A2A and Agent Search

Patrick Londa — Tue, 26 May 2026 18:32:08 +0000

Authored by David Tracey

AI is rapidly evolving from simple tools to increasingly complex agents capable of reasoning and decision making. As agents are used for more tasks, the ability to use multiple co-operating agents will become increasingly important — particularly for tasks requiring specialised knowledge or access across domains.

Large-scale, flexible solutions will require a common means for agents to communicate capabilities to each other using a trusted means of collaboration. That's what the Agent2Agent (A2A) protocol is designed to provide.

This is the first post in a three-part series:

Part 1 (this post): Introduction to A2A concepts and a "Hello World" agent
Part 2: Using MCP to query multiple data sources including Bronto's logging platform
Part 3: Combining A2A and MCP with a "SuperAgent" orchestrating multiple agents

Why A2A?

The Agent2Agent protocol — originally developed by Google and now under the Linux Foundation as an open source project — gives agents an open protocol for interaction built on HTTP. It standardizes how agents exchange messages, requests, and data, allowing agents to:

Discover each other's capabilities without exposing internal state, memory, or implementation
Negotiate interaction details (text, forms, media, etc.)
Collaborate on running tasks securely

IBM's definition of agentic AI captures it well: "Agentic AI is an artificial intelligence system that can accomplish a specific goal with limited supervision", with each agent in a multi-agent system performing a specific subtask coordinated through AI orchestration.

A2A and MCP: Complementary Protocols

MCP and A2A serve different but complementary roles:

MCP exposes tools and structured data sources to an agent. It extends an agent's capabilities by standardizing how an agent accesses databases or product APIs. It focuses on a single agent accessing tools, and lacks built-in agent authentication.
A2A provides structured agent-to-agent communication — allowing multiple autonomous agents to collaborate, delegate tasks, and exchange information using capabilities exposed via Agent Cards. It enables multi-agent interactions with secure communication and capability discovery.

MCP Tools are generally basic operations with defined inputs/outputs. A2A is designed for autonomous agents that reason, use tools, and collaborate on complex problems. The two protocols are not mutually exclusive — agents can use MCP for specific tool access and A2A for broader agent collaboration.

Part 3 of this series will show an emerging pattern where A2A agents sit in front of MCP servers.

Key A2A Concepts

Agent Card — public metadata describing an agent's capabilities, skills, URL, and authentication requirements. Other agents retrieve this card to discover what an agent can do.

A2A Server — exposes an HTTP API endpoint implementing A2A methods and executes tasks on behalf of other agents.

A2A Client — an application or agent that sends requests to an A2A server to initiate tasks.

Task — initiated by a client sending an A2A message (role: user). Each task has a unique ID and states: submitted, working, input-required, completed.

Message — contains a role (user or agent), optional metadata, and an array of parts (TextPart, FilePart, or structured JSON data).

Communication flows:

Discovery — client fetches the Agent Card via GET /.well-known/agent-card.json
Initiation — client sends a request with a task ID to the server agent
Processing — server processes the task, streaming intermediate updates via Server-Sent Events if needed

Building a Hello World A2A Agent

Installation and Setup

These examples use the official A2A samples repository. Requirements:

Python 3.12 or higher
UV (recommended Python package manager)

Running the Sample

# Clone the repo
git clone https://github.com/a2aproject/a2a-samples.git
cd a2a-samples/samples/python/agents/helloworld

# Install UV and run the server
pip install uv
uv run .

This runs __main__.py in the helloworld directory, which defines an AgentCard, AgentSkill, and extended card, then calls uvicorn to run a server on localhost:9999.

In a separate terminal, run the client:

uv run test_client.py

The Agent Card Response

The server returns its public Agent Card:

{
  "capabilities": { "streaming": true },
  "defaultInputModes": ["text"],
  "defaultOutputModes": ["text"],
  "description": "Just a hello world agent",
  "name": "Hello World Agent",
  "preferredTransport": "JSONRPC",
  "protocolVersion": "0.3.0",
  "skills": [
    {
      "description": "just returns hello world",
      "examples": ["hi", "hello world"],
      "id": "hello_world",
      "name": "Returns hello world",
      "tags": ["hello world"]
    }
  ],
  "supportsAuthenticatedExtendedCard": true,
  "url": "http://localhost:9999/",
  "version": "1.0.0"
}

Authenticated clients additionally receive an extended card with a super_hello_world skill — demonstrating how A2A supports capability tiers based on authentication level.

What's Coming in Parts 2 and 3

Part 2 will show how to build simple MCP servers for Bronto's REST API and a SQLite database, then use Claude to query both simultaneously with a natural language prompt — no data movement required.

Part 3 will extend this into a full A2A scenario with a "SuperAgent" orchestrating two A2A agents (one per data store), demonstrating how A2A and MCP work together.

The Bigger Picture: Challenges A2A Still Needs to Solve

A2A is an evolving protocol. Current areas requiring further development include:

Multi-agent orchestration — standardized support for conflict handling and failure recovery across agents from different organizations
Shared vocabulary — no agreed-upon standard definitions for common items like invoices, policies, or receipts
Trust — establishing trust between agents across organizational boundaries is key to adoption
Security — authentication is provided, but richer methods are needed for privacy across organizational/national boundaries
Enterprise readiness — standardized usage management, SLOs, SLAs, and automated negotiation

The separate open source project AGNTCY, backed by Cisco, LangChain, Galileo and others, provides the Open Agent Schema Framework (OASF) as another approach to standardizing agent capability descriptions.

Explore Bronto's AI Features

Bronto for Fastly: Real-Time CDN Logging That Actually Scales

Patrick Londa — Tue, 26 May 2026 17:04:31 +0000

Authored by Mike Neville-O'Neill

A company processing tens of TBs of Fastly logs daily through traditional logging vendors faces an impossible choice: pay enterprise prices for comprehensive logging, or fly blind with minimal retention.

That's why most teams default to a 7-day retention window. Not because they don't need historical data — because the economics don't work.

That was the exact situation for Contentstack, a leading global platform for digital experiences. They now keep a full year of logs, run unlimited queries, and report 50% cost savings versus their previous solution.

The Real Cost of Restricted Logging

Processing 10TB of Fastly logs daily can cost ~$30,000/month for ingestion alone on traditional platforms. To reduce costs, teams resort to:

Abbreviating field names (EdgeResponseStatus → ers) to save bytes
Sampling 1 in 100 requests and hoping issues appear in that sample
Keeping only 7 days of data when seasonal patterns span months
Dropping entire log categories to keep storage costs down

When ingestion and storage are expensive, comprehensive logging becomes a luxury instead of standard practice. But what if the economics actually worked?

What Changes When You Can Keep Everything

Bronto's architectural efficiency — 90% compression, optimized storage, purpose-built for logs — means you pay 50–90% less to ingest the same data. This changes everything.

Consider tracking API performance across enterprise customers:

-- Monitoring performance across multiple API customers
SELECT count(*), avg(resTime)
WHERE (apiKey = 'customer_key_1' OR apiKey = 'customer_key_2' OR apiKey = 'customer_key_3')
  AND resTime > 500
  AND cache != 'MISS, MISS'
GROUP BY shield, cache
-- Time range: 30 days

When ingestion is affordable, you can actually keep the 30 days of high-volume logs this investigation requires. No sampling, no abbreviations, no compromises.

30-Day Performance Archaeology

A customer report of intermittent slowdowns triggered a deep investigation:

SELECT max(resTime), avg(resTime), count(*)
WHERE apiKey = 'customer_12345'
GROUP BY shield, cache
LIMIT 100
-- Analyzing response times week-over-week for the past month

Analyzing max and average response times over 30 days revealed certain endpoints were gradually slowing down — a pattern invisible in a 7-day window but clear with month-long data.

The team spotted week-over-week degradation that would have caused a critical outage within weeks. With 7-day retention, they never would have seen it coming.

Multi-Month Error Forensics

When 404 errors started appearing randomly across the CDN, the team needed to know: new issue or recurring pattern?

SELECT count(*)
WHERE url ILIKE '%/api/v2/content/%'
  AND response_status = '404'
GROUP BY cache, shield, pop
LIMIT 100
-- 90-day investigation of 404 errors for content API endpoints

Filtering 90 days of complete, unsampled logs revealed what looked like random errors was actually a cache invalidation race condition — one that only occurred under specific geographic and timing conditions. With 7-day windows and aggressive sampling, this would have remained an unsolved mystery.

The Intelligence Layer: From Logs to Insights

Long-term retention unlocks intelligence — but only if you can query it. Bronto's analytics engine lets you:

Run SQL queries across months of data in seconds
Set up change detection that automatically flags when cache hit rates drop
Build filterable dashboards to click into any spike or anomaly
Use natural language with the AI dashboard builder: "Show me API response times by customer and region for the last 90 days"
Use BrontoScope to interrogate logs with context, correlating events and surfacing root causes that would take hours to piece together manually

What Becomes Possible

API customer journey mapping — track the entire API consumer lifecycle:

Which endpoints do new users test first?
How does usage scale over months?
What usage patterns precede account downgrades?

Intelligent cache optimization — with a year of data you can finally answer:

How do cache hit ratios vary by season, not just by day?
Which content genuinely needs global distribution vs. regional?
How do different shield configurations perform under various traffic patterns?

Security pattern recognition — long-term retention enables sophisticated threat detection:

Bot networks that rotate through IP ranges over weeks
Credential stuffing campaigns that evolve over months
DDoS reconnaissance that occurs weeks before an attack

Before and After Bronto

Before	After
Field names abbreviated to save bytes	Full field names: readable and searchable
Aggressive sampling: keeping 1% of logs	100% coverage: every request, response, error
Short retention: 7 days max	365-day retention: full seasonal patterns visible
Blind spots: log categories dropped to save costs	Complete visibility: CDN and compute logs

Technical Foundation: Built for Fastly's Scale

Bronto integrates with Fastly through a built-in logging endpoint. Configure it once in your Fastly service settings and logs start streaming in minutes:

# Simple Fastly Integration
name: Bronto
format: JSON
url: https://logs.bronto.io/fastly
compression: zstd  # 10:1 automatic compression
method: POST
header_name: X-Bronto-Token
header_value: ${BRONTO_TOKEN}

Why it scales:

Elastic ingestion that grows with traffic
90% data compression
Time-series optimization for CDN access patterns
Intelligent tiering keeps recent data hot, historical data accessible
Column-oriented storage for efficient aggregations

Bronto Express: From Ingestion to Insights in Minutes

Setting up this level of insight shouldn't require weeks of work. Bronto Express for Fastly uses AI to take raw log streams and dynamically build Fastly-specific queries, monitors, and dashboards personalized for your organization.

It includes pre-built dashboards for real-time performance, geographic traffic, API usage, and security monitoring; a saved searches library for common investigations; and intelligent monitors for performance degradation and error rate thresholds.

Setup is four steps:

Create your Bronto instance (selecting the Fastly Express pack)
Add Bronto as a logging endpoint in Fastly (5-minute configuration)
Watch pre-built dashboards populate with your data
Customize searches and alerts for your specific needs

No agents. No forwarders. No complex pipelines.

The Platform Effect: When Every Team Has Access

When CDN logs become affordable and accessible, every team benefits:

Engineering — debugs issues with complete historical context
Security — investigates threats across meaningful timeframes
Product — understands real usage patterns, not samples
Sales — identifies expansion opportunities from actual usage data
Finance — accurately allocates costs to business units
Support — resolves tickets with full forensic capability

This isn't just about saving money on logging (though 50–90% savings helps). It's about removing the artificial constraints that prevent teams from fully understanding their infrastructure.

See Sub-Second Search Across Your Fastly Logs

Investigation Reports: When Monitors Get Smarter

Patrick Londa — Fri, 22 May 2026 18:04:01 +0000

Authored by Marco Aquilanti

When a monitor fires, there's a familiar sequence of checks required to find the root cause. The engineers who set up the monitor usually know these steps by heart — they know the dependencies, the error codes, what to check and where. But for the on-call responder, these steps aren't always obvious. Historically, the solution was to force engineering teams to document the checks in a playbook and hope the responder would read it under pressure.

Today, we can offload these checks to an LLM, shifting the responder's role from gathering evidence to reviewing a diagnosis — significantly reducing MTTR.

Our new Investigation Reports feature does exactly this: an LLM completes the investigation and delivers a detailed report before the human even acknowledges the alert.

Investigation Reports builds on BrontoScope, our first AI-powered investigation feature — and on the positive customer feedback it generated.

BrontoScope vs. Investigation Reports

Both BrontoScope and Investigation Reports perform automated investigations and provide reports, but they work differently.

BrontoScope starts with a user request to investigate a specific error event in the logs. The investigation follows a defined workflow aimed at establishing when and where an error is occurring. The LLM guides the process and summarizes findings synchronously — the user is waiting for a response and gets it in seconds.

Investigation Reports is triggered by a system event (a monitor firing), with no user waiting for a synchronous response. This gives the LLM more time — not seconds but minutes — to query data and analyze results. Investigating an alert is also a more generic task than BrontoScope's focused error investigation, making it harder to define a single fixed workflow that succeeds in every scenario.

For these reasons, Investigation Reports lets the LLM operate more freely — giving it tools and context rather than a coded workflow.

Tools Are Easy, Context Is Hard

The tools side is straightforward: the LLM can call Bronto's APIs to perform lightning-fast log search, query key-value dictionaries, check monitor history, retrieve precomputed metrics, and more.

Context is the harder problem.

LLMs make good logical decisions when provided with relevant, well-explained context. But the context window is limited — and it's been demonstrated repeatedly that longer context leads to worse answers and higher hallucination rates. This is known as "context rot" (see research from Chroma and this arXiv paper).

For an effective investigation, the LLM needs more than just the monitor that fired. It needs historical context and an understanding of the monitored system. But dumping thousands of tokens of documentation into the prompt backfires — it drastically increases hallucination risk and degrades report accuracy.

User-Defined Investigation Context

The precise knowledge needed for a good investigation is hard for an LLM to infer autonomously — but it can be provided by the engineer who owns the monitor.

In a dedicated "Investigation Prompt" text area, the user instructs the LLM on what to check and what to do when the monitor fires. Free-form text makes the feature highly flexible, effectively letting users define an ad-hoc workflow for each specific use case.

Engineers and SREs commonly include:

List of dependencies of the affected service
Related log datasets and how to correlate/query them
Relevant keys and metrics to check
What to include in the report — affected components, customers, or users

The screenshot below shows an example investigation prompt telling the LLM to check datasets in a collection named "booking system":

And here's the Investigation Report generated when that monitor fired — the LLM followed the instructions, ran multiple queries, and produced a report with a potential root cause, diagnosis, and timeline:

Investigation Reports Beyond Incident Response

Bronto's own customer support and sales teams found an unexpected use case. They set up monitors to be notified when new organizations are created or contracts are updated in the system — keeping the team up to date on new sign-ups and customer onboarding.

Investigation Reports automates the task of fetching context about each event. Details like contract type, retention plan, company size, and location are queried across multiple logs and assembled into a report that arrives within a minute of the monitor notification. This lets the team quickly identify relevant events among routine ones.

Below is the investigation prompt used by the customer support team, and an example of the automatically generated report:

Investigation Reports are a great illustration of what LLMs are genuinely good at: taking a well-framed task with relevant context and producing a structured, actionable summary faster than any human could. Every monitor notification now comes with relevant information to speed up resolution.

We'll be building further on this capability in the coming months — using AI alongside Bronto's logging platform to help teams reduce toil, resolve issues faster, and extract more value from their data.

Explore Bronto Labs

Using Dashboard Filtering to Get Customer Usage in Seconds from TBs of Data

Patrick Londa — Fri, 22 May 2026 13:53:30 +0000

Authored by Conall Heffernan

As the Customer Success lead at Bronto, I need fast, reliable insights into customer health and product usage — but I don't have time to constantly update indexes, schemas, or individual widgets just to answer new questions. I need to spot patterns, explore trends, and get answers in real time without manual overhead.

That's why Bronto's dashboards are so critical to my work. We recently added a new query filtering feature that lets me use SQL to look for any pattern across all widgets in a dashboard simultaneously — and update everything at lightning speed.

What Bronto Dashboards Provide

Rich visualisation options — time-series charts, geomaps, numeric value widgets (with units like bytes and time), top lists, treemaps, and log event lists for drilling into raw data
AI widget builder — describe what you want in natural language; an LLM builds the query and creates the widget without you needing to know the query language or which datasets to select (see the full post on this feature)
Full screen widget mode — compare different timeframes for the same query (e.g. vs. previous day, week, month)
Easy filtering — use the query builder with a searchable dropdown of top keys and values, or write SQL filters directly in the filter bar

The Power of Filtering at Scale

In many logging or observability tools, applying a filter means updating every single chart, table, or widget individually. Tedious. Time-consuming. It doesn't scale.

With Bronto, applying a filter in the main query bar instantly updates every single widget on the dashboard for your given timeframe. With a default retention period of one year, you don't need to worry about missing long-term trends — all your data is fully searchable and visualisable. Concerned about when an issue started? You can analyze trends over months, not days.

Our widgets use pre-computed log-based metrics (LBMs) for rapid responses, but the new dashboard filtering goes further — running raw log queries to filter the data in your dashboard in real time. Results come back in seconds, and you can drill down across all widgets simultaneously using SQL or by clicking from a dropdown of top keys and values.

One thing worth noting: there's no initial configuration of keys required. I can use any key I want in the filter, with no setup.

Log-Based Filtering vs. Log-Based Metrics

Log-based metrics (LBMs) deliver millisecond responses — perfect for real-time dashboards, trend analysis, and high-level views of system behavior.

When something unexpected happens or a new question comes in, we seamlessly switch to log-based filtering to investigate deeper, explore raw data, and uncover answers without being constrained by pre-defined fields or aggregations.

Log-based filtering excels because it lets you query and visualize raw logs immediately — no upfront configuration like index definitions or field extraction required. Bronto combines this with structured parsing and indexing, using the right approach for the right job.

The result: both fast, flexible investigation and high-performance queries on known fields, without forcing you to predefine every key or build parsing pipelines before you can search effectively.

How I Use Dashboard Filtering for Customer Usage

My primary use for this feature is gathering and presenting product usage data to our leadership team. Questions like:

"How much data did Org ID 54321 send over the last 6 months?"
"How much did company ACME search last month?"

Instead of building 10 custom dashboards (which doesn't scale as your customer base grows), I use dashboard filtering:

Navigate to our main Usage Dashboard
Enter the specific org_id in the main query filter (e.g. org_id: 54321)
Every widget updates instantly to reflect only that organization's data

That's it. A complex, multi-step data lookup becomes a quick and easy process.

The first time I tried filtering across the dashboard for an org_id, I thought something wasn't working right — the results were rendered so fast across terabytes of data. It was a genuine "wow" moment. As a customer support lead, it's great to see the under-the-hood changes we're building for customers also improving my own day-to-day.

How Bronto Dashboards Compare

Most dashboard tools are optimized for known questions: predefined fields, fixed widgets, metrics decided on ahead of time. That works for stable monitoring but breaks down when you need to explore new questions, investigate unexpected behavior, or quickly slice data in different ways.

Feature	Bronto Dashboards	Traditional Competitors
Query Scope	SQL filtering on any log value	Often restricted to predefined or indexed fields
Update Speed	Instant — all widgets update simultaneously	Manual, per-widget updates required
Performance	Terabytes rendered in seconds across all datasets	Latency issues with large datasets; often minutes to render
Setup	Schema-less — no upfront definitions or configuration	Parsing and indexing pipelines required first
Cost	Filtering included in monthly quota; faster MTTR	Slow dashboards can inflate costs by consuming more resources

Summary

Modern teams need dashboards that are fast, flexible, and easy to adapt as questions change. Bronto dashboards combine high-performance log-based metrics with instant, dashboard-wide filtering to help you explore usage, investigate issues, answer leadership questions, and quickly re-run reports as requirements evolve.

Questions like "what does this customer's usage look like over the last six months?" are answered in seconds — without upfront schemas, per-widget reconfiguration, or slow refresh cycles.

See Dashboard Filtering in Action

Your LLM Logs Deserve Better — Send Claude Code Events to Bronto

Patrick Londa — Thu, 21 May 2026 18:47:19 +0000

Authored by Conall Heffernan

In this post, I'll walk through how to integrate Anthropic's Claude Code monitoring with Bronto so you can get a clear, unified view of your AI tool usage — all in one place.

This project came out of our recent company AI sprint — a chance for me, as a technical support manager, to jump into an engineering sprint and brush up on my Python and Bash skills. After years of helping customers set up and troubleshoot their environments, it was exciting to get hands-on and demo my findings to the wider team over pizza and beers.

What You Can Send from Claude Code to Bronto

Claude Code has a built-in monitoring feature that provides a detailed view into how your teams use AI-assisted coding — from productivity metrics to cost visibility. When paired with Bronto, this data becomes even more useful.

Here's what you can do with the exported data:

Understand usage patterns — analyze how different users and teams engage with Claude Code over time
Measure productivity — track lines of code modified and models used
Monitor costs — get a clear picture of spend by team, user, or session
Audit prompts — see what users are actually asking, building, or automating; identify common use cases, detect misuse, and refine prompts based on real-world usage

Why Bronto specifically:

Centralise all event logging across your organisation for unified analysis
Visualise effortlessly — create dashboards using the AI widget creator without writing queries
Set up monitors to alert on sudden cost spikes, unusual token usage, or high session volumes from specific teams
Fast, scalable search — explore and investigate your LLM logs quickly
Handle high volume easily — Claude Code can generate massive, detailed logs; Bronto's storage and query engine handles this without breaking your budget
Long-term retention — 12 months of hot logs by default, which is increasingly important for support tracking, debugging non-deterministic LLM behavior, and EU AI Act compliance

Two Ways to Connect Claude Code to Bronto

Option 1: Direct (Simplest)

Claude Code has built-in OTel support, so it can send telemetry straight to Bronto. Just set these environment variables (full details in Claude Code's docs):

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=https://ingestion.eu.bronto.io
export OTEL_EXPORTER_OTLP_HEADERS="x-bronto-api-key=<api_key_here>,x-bronto-collection=AISprint,x-bronto-dataset=claude-code"
export OTEL_LOGS_EXPORT_INTERVAL=2000
export OTEL_LOG_USER_PROMPTS=1

With this setup, Claude Code sends structured logs directly to Bronto — no additional infrastructure to run or maintain.

Best for:

Running Claude Code locally or in a single environment
No existing centralised OTel collector
Lightweight, zero-maintenance integration

Option 2: Via an Existing OTel Collector

If your organisation already runs an OTel Collector, route Claude Code's logs through that same pipeline before forwarding to Bronto. This is the approach I used — I spun up a small AWS EC2 instance running the OTel collector, configured Claude Code to send logs to it, and had the collector forward those logs to Bronto.

Point Claude Code at your local collector:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
export OTEL_LOG_USER_PROMPTS=1

Pro tip: Persist these environment variables — otherwise starting a new terminal session will clear them and you'll wonder why nothing is flowing. Ask me how I know.

Collector receiver config:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317  # Default OTLP gRPC port
      http:
        endpoint: 0.0.0.0:4318  # Default OTLP HTTP port
        cors:
          allowed_origins:
            - "*"

Best for:

Aggregating logs from multiple sources before forwarding
Applying processors like filters
Keeping your Bronto exporter config in one place

Generating Some Log Data

To verify everything was working, I fired up Claude Code and asked it to create a simple Python script, then made a few tweaks — spin up a basic GUI, take an input value, save it locally. While I was doing this, Claude Code was generating log events in the background, flowing through my OTel collector and straight into Bronto.

Searching Claude Logs in Bronto

During testing, Claude was hitting errors because I'd been using an old revoked API key from a previous project. While the UI showed an error, I could also see the API errors flowing into Bronto. A simple error query surfaced the logs directly.

I also created a tree map to instantly visualize which models were used across the project — making it easy to see usage patterns and identify which models were most heavily used.

Token usage analysis — a multi group-by on $input_tokens and $output_tokens helps identify outliers and inefficient prompts, control API spend, and uncover latency trends tied to model size or context length.

Session duration — tracking how long each session stayed active helps identify inefficient workflows, idle connections, or hanging requests that inflate costs. It's also a signal for user engagement: shorter sessions suggest quick completions, longer ones can point to complex prompts or slow model responses.

Prompt auditing — prompts are redacted by default. To enable them, set OTEL_LOG_USER_PROMPTS=1 (already included in the config above).

Conclusion

From Claude Code to Bronto, all connected through OpenTelemetry — a few environment variables, an open source agent, and you have logs and insights flowing in. Once it's set up, you get full visibility into how your AI tooling is being used, cost metrics, and what's actually happening under the hood.

Appendix: Full OTel Collector Config

Receivers:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
        cors:
          allowed_origins:
            - "*"

Exporters:

exporters:
  otlphttp/brontobytes:
    logs_endpoint: "https://ingestion.eu.bronto.io/v1/logs"
    compression: gzip
    headers:
      x-bronto-api-key: "INGESTION_API_KEY_GOES_HERE"
    timeout: 30s
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 120s
    sending_queue:
      enabled: true
      num_consumers: 10
      queue_size: 5000

Pipelines:

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [memory_limiter, resource, batch, transform]
      exporters: [otlphttp/brontobytes]

Try Bronto Free — Send Your First Claude Logs

The 4L's of Logging — The New Standard for the AI Era

Patrick Londa — Thu, 21 May 2026 16:18:59 +0000

Authored by Noel Ruane & Trevor Parsons

Traditionally, the world of logging had 3L's — low cost, low latency, and large scale — and the accepted wisdom was that you'd have to compromise by choosing two of the three.

Until recently, the logging market bore this out. Solutions fell into one of three categories:

Expensive and fast — Datadog, ELK-type solutions
Slow and cheap(er) — index-free solutions like Grafana Loki (still relatively expensive when you actually search)
Tweeners — expensive, relatively slow, not great at scale — think CloudWatch, Google Cloud Logging

Anyone who's ever hired builders knows the iron rule: fast, cheap, or quality — pick two.

But the world has changed with the arrival of AI. As everyone builds and innovates around LLMs and agents, achieving all three L's has become more essential than ever. And AI has added a fourth requirement to the list: long-term retention.

3 Becomes 4: What Long-Term Retention Opens Up

With a short retention window — 3, 15, or 30 days, as most solutions provide — logs are accessible only for outages and system issues severe enough to warrant immediate attention.

Long-term retention opens up an entirely new set of use cases.

A common example: comparing customer API request latencies or conversion metrics month-on-month, looking at seasonality effects, or preparing data for a customer QBR. You might want to analyze customers in aggregate to spot trends, or drill into a specific customer's history.

Support issues can be recent or ongoing over months. Being able to look beyond a few days of data is often the difference between resolving a customer issue properly and leaving it half-answered.

In an AI world where agents can interrogate your data and solve problems at a completely different scale, long-term hot retention is essential — not the cumbersome, costly process of rehydrating logs from archives that most providers offer. The common workaround of dumping logs to S3 and spinning up Athena is another great example of the kind of toil that shouldn't exist in modern logging.

The importance of long-term hot data is borne out by our own customers: the longer the data retention, the more use cases open up, the longer the time periods searched, and the more value customers extract from their data. This value will only increase as agents become more powerful.

The 4L's Set a New Standard for the AI Era

Microsoft's Satya Nadella put it well: AI is at the intersection of where intelligence meets data. If you don't have the data, you can't point AI at it. The new requirements for data in the AI era map directly to the 4L's:

Large Scale — data that is always and easily accessible
Long-Term Retention — data retained so AI can analyze it and take action on it
Low Cost — storage and search must be cost-efficient as volumes see exponential growth
Low Latency — fast search and querying

As Bessemer Venture Partners notes in their Roadmap for AI Infrastructure, the volume of unstructured data is projected to reach 612 zettabytes by 2030, driven by ML/AI and synthetic data generation. Log data is one specific type where this applies acutely.

Here's why logging requirements are intensifying in the AI era:

Systems of action are replacing systems of record. As AI-native apps don't just store data but act on it, having log data accessible and hot means AI models can actually do something meaningful with it. The era of retaining logs for 30 days and locking them in cold storage is ending.

AI-led Root Cause Analysis. We're already seeing AIs perform RCA using log data to help teams solve problems faster. BrontoScope, for example, automatically runs an investigation that assesses how widespread an error is — figuring out what queries to run, assessing results, running further queries, and delivering an immediate assessment with recommendations. It can save anywhere from minutes to hours per incident. As MCP becomes standard, log data will be analyzable with additional context from other systems — replicating what engineers do manually today when piecing together evidence.

LLMs are non-deterministic. Given the unpredictable nature of LLMs, logs will play an even more important role in understanding what happened — whether from a support, debugging, audit, security, or compliance perspective. The same action can deliver different results, making logs essential for showing exactly what occurred. (See our guide to collecting Ollama logs to get started.)

Regulation. EU AI Act Article 19, for example, will require logs of certain higher-risk AI systems to be retained for at least 6 months from 2026.

A Purpose-Built Adaptive Technology for Log Data

How do you actually achieve all 4L's? The short answer: treat logs as a first-class citizen and build a purpose-built data store for them.

Until now, vendors have always repurposed existing datastores for logging:

Elasticsearch — at the core of most logging solutions for two decades. Super fast because it indexes everything, but super expensive due to data bloat and operational complexity.
ClickHouse — more recently vendors have turned to ClickHouse. Great for metrics, good for some logs — but only if you know the shape of your data in advance, which is a non-starter for a general-purpose logging platform. (Full write-up: Why ClickHouse fails as a general-purpose logging solution)
Snowflake — vendors like Observe have turned to Snowflake to address the cost problem, but customers regularly report search latency issues and burning through CPU credits when searching large data volumes.

The key learning from two decades in this space: not all log data should be treated equally. Don't just "index everything" (inverted indexes) or at the other extreme "index nothing" (index-free solutions). Instead, take a more thoughtful approach — let the system adapt and optimize based on the shape of your data and the queries you run.

These optimizations operate at every layer:

Indexing: We combine multiple patent-pending adaptive compact indexes. The platform automatically decides which to apply based on data and query patterns. Techniques include Bloom filters, summary indexes, partition indexing, automatic log-to-metric conversion, and additional patent-pending technologies.

Storage: Our storage tier routes data to the most appropriate structure based on its shape and how it will be searched — columnar store, specialized data structures, high compression, partial decoding, and storage tier coordination.

Search: Specialized algorithms applied depending on the query being run, highly parallelized to operate at any scale.

For deeper reading: Why Bronto is so fast at searching logs, or the Log Management Cost Trap series — Part 1: Ingestion, Part 2: Storage, Part 3: Search.

No Maintenance Required

One important point often overlooked: we see vendors trying to solve the cost problem by deploying within an organization's cloud (BYOC), using the customer's hardware to reduce costs. This requires deploying a logging platform into your environment and having the vendor manage it there. Unless you have tight data regulations, this feels like an overly complex backward step.

Bronto is built on a modern cloud multi-tenanted architecture. No setup, no maintenance, no management required by the customer. We take advantage of compute/storage separation and independently scaling services.

AI = the Intersection of Intelligence and Data

If your current provider is building AI capabilities on top of an old, repurposed, or expensive logging platform — one with 2 L's instead of 4 — you won't be able to take full advantage of the AI revolution.

The 4L's aren't a nice-to-have. In the AI era, they're the baseline.

See the 4L's in Action

DEV Community: Bronto

Fixing Observability Pricing for the AI Era

Legacy Pricing Is Broken

Enter Bronto — Pricing Built for the Customer, Not the Vendor

100x–1000x More Efficient

What Bronto Delivers

Try Bronto Today

Trust, Discovery, Context, Consistency: What AWS DevOps Agent Looks For in a Telemetry Layer

1. Silent Failure Risk

2. Data Discovery

3. Response Completeness

4. Deterministic Behavior

What Each Platform Was Built For

See It in Action

Building on Vercel? Your Logs Now Have a Better Home

Bronto + Vercel

Setting It Up

What You Can Do with Bronto

Long-Term Performance Tracking

Multi-Deployment Debugging

Headless Access via MCP

Custom Instrumentation

Build the Interface You Actually Want

A Note on Cost

Bronto Hosted MCP Server

Why a Hosted MCP Server?

What Changes Compared to the Local Version?

Setting Up the Hosted MCP Server

What Can You Ask It? Five CDN Log Examples

Example 1: Find the Right CDN Datasets

Example 2: Look for Elevated Error Responses

Example 3: Investigate Latency Regressions

Example 4: Look for Cache Effectiveness Problems

Example 5: Investigate Unusual Traffic

Closing Thoughts

How to Use A2A to Access Multiple Data Stores

Architecture Overview

Step 1: Create the A2A Bronto Agent

__main__.py

agent_executor.py

Step 2: Create the A2A SuperAgent

agent_executor.py (key parts)

Step 3: Create the A2A Client

Running the Full Demo

Summary

How to Use MCP Agents to Access Multiple Data Stores

Architecture Overview

Step 1: Create a Bronto REST API Client

Step 2: Create a Simple Employee Database

Step 3: Wrap Both Sources as MCP Servers

Bronto MCP Server

SQLite Employee MCP Server

Inspecting MCP Servers

Step 4: Connect Both Servers to Claude

Step 5: Query Both Data Sources with One Prompt

Why This Matters

Introduction to A2A and Agent Search

Why A2A?

A2A and MCP: Complementary Protocols

Key A2A Concepts

Building a Hello World A2A Agent

Installation and Setup

Running the Sample

The Agent Card Response

What's Coming in Parts 2 and 3

The Bigger Picture: Challenges A2A Still Needs to Solve

Bronto for Fastly: Real-Time CDN Logging That Actually Scales

The Real Cost of Restricted Logging

What Changes When You Can Keep Everything

30-Day Performance Archaeology

Multi-Month Error Forensics

The Intelligence Layer: From Logs to Insights

What Becomes Possible

Before and After Bronto

Technical Foundation: Built for Fastly's Scale

Bronto Express: From Ingestion to Insights in Minutes

The Platform Effect: When Every Team Has Access

Investigation Reports: When Monitors Get Smarter

BrontoScope vs. Investigation Reports

Tools Are Easy, Context Is Hard

`main.py`

`agent_executor.py`

`agent_executor.py` (key parts)