​
Who This Guide Is For

This guide is for observability and platform teams who currently rely on Coralogix and are looking for a simpler, more cost-effective way to retain and search log data over time, without disrupting existing pipelines or workflows.

You might be here because:

  • You’ve built a solid observability stack around Coralogix, but need a better long-term log storage strategy—something that’s searchable, scalable, and doesn’t involve cold storage or rehydration delays.
  • You’re sending logs through the OpenTelemetry Collector and want to keep using it, but without being tied to a single vendor or locked into proprietary extensions.
  • You’ve had to drop or exclude logs because of ingestion or retention costs, even though those logs could be valuable for audit, security, or debugging down the line.
  • You want to avoid duplicating infrastructure or workflows, and are looking for a drop-in complement to your existing setup, not a replacement.

Bronto is designed to work alongside Coralogix. With a small configuration change to your OpenTelemetry Collector, you can route a copy of your logs to Bronto without rearchitecting your environment. Alerts, dashboards, and telemetry pipelines stay the same. You just get more retention, better search, and fewer blind spots.

​
Quick Start: Set Up Bronto in 30 Minutes

​
Generate Your Bronto API Key

  1. Log in to Bronto → Settings → API Keys
  2. Create a key and copy it to a secure location. How to generate an API Key

​
Pick a Collection and Dataset

These determine how your logs are organized in Bronto.

Example: X-Bronto-Collection: ecommerce, X-Bronto-Dataset: checkout-api

​
Update Your OpenTelemetry Collector Config

Add Bronto as an OTLP/HTTP exporter. Use your API key and headers. See example config: Connect OpenTelemetry to Bronto.

​
Restart the Collector

Apply your config changes and restart your collector or redeploy if running in Kubernetes.

​
Confirm Logs Are Flowing

Go to Bronto > Search and filter by service.name, env, or a known recent event. How to search logs in Bronto

​
(Optional) Build a Dashboard Widget

Use the “Visualize as” panel to chart trends or group logs. See dashboard instructions: Bronto Dashboards

​
2. Getting Logs into Bronto

Bronto integrates easily with your existing OpenTelemetry Collector setup. Migration involves a simple change: add Bronto as an HTTP destination alongside Coralogix.

​
Example OTEL Collector Config

exporters:
  bronto:
    endpoint: "https://ingestion.us.bronto.io/v1/otel"
    headers:
      Authorization: "Bearer <YOUR_BRONTO_API_KEY>"
      X-Bronto-Collection: "ecommerce"
      X-Bronto-Dataset: "checkout-api"
receivers:
  otlp:
    protocols:
      http:
processors:
  batch: {}
service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [coralogix, bronto]

Confirm ingestion by logging into Bronto and searching by service.name, env, or timestamp. For full configuration examples, see Bronto OTEL Setup Docs

​
3. Organizing and Tagging Logs in Bronto

Bronto uses two elements to route logs:

  • X-Bronto-Collection: top-level grouping (e.g., application, business unit)
  • X-Bronto-Dataset: service or log stream (e.g., checkout-api)

Routing is defined by these headers, not log content.

Bronto automatically extracts structured metadata from:

  • JSON log bodies
  • OpenTelemetry resource attributes

Common fields:

  • service.name
  • deployment.environment
  • version, region, user_id, etc.

You can also enrich logs post-ingestion via:

  • Bronto UI
  • Bronto API

​
4. Search in Bronto

All logs are indexed by default. No rehydration, cold tiers, or field selection rules. Everything is hot and searchable.

​
Bronto supports two modes of search:

​
Simple Mode

Use key:value and full-text queries:

level:error service.name:auth-api "login failed"

​
SQL Mode

SQL Mode in Bronto is used to define filters over your logs using a SQL-style syntax. Bronto does not support SELECT, FROM, GROUP BY, or aggregation logic inside the query itself.

Example of a valid SQL Mode filter:

"status"='200' AND "method"!='PATCH'

Once you’ve written a valid SQL Mode filter, use the Visualize as panel in the UI to:

  • Choose a chart type (bar, pie, line, top list)
  • Set an aggregation (e.g., count)
  • Group results by a log field (e.g., referer, status_code, service.name)

See Bronto docs: SQL Search Mode and Visualization

​
5. Workflow Migration: What to Mirror, What to Keep

​
Mirror in Bronto:

  • Long-term investigations
  • Security and compliance logs
  • Logs dropped for cost reasons
  • Anything beyond Coralogix’s hot retention

​
Keep in Coralogix:

  • Real-time alerts and dashboards
  • Live Tail and on-call debugging
  • SLO monitoring and anomaly detection

Bronto gives you more of Coralogix: more history, more logs, more context.

​
Correlating Metrics and Traces

Use shared fields like trace_id, request_id, or user_id to connect dashboards or alerts in Coralogix to detailed logs in Bronto. Construct pre-filtered Bronto URLs for dashboards or alert links.

Native trace support is coming soon

​
Recreating Dashboards in Bronto

Bronto dashboards are purpose-built for analyzing trends in log data, especially over long time ranges.

If you’re migrating Coralogix dashboards that use logs (rather than metrics or traces), most panels can be recreated directly in Bronto using its dashboard editor.

​
Example Panel: 5xx Errors by Referer

​
In Coralogix:

  • Filter: status_code >= 500, method = POST
  • Group by: referer
  • Time range: 1 day
  • Visualization: line chart

​
In Bronto:

  1. Go to Dashboards > Add Widget
  2. Choose visualization: Line
  3. Apply filter:
status_code:>=500 method:POST
  1. Set aggregation: Count of events
  2. Grouped by: referer
  3. Set time range: 1 day
  4. Title your widget and save

Bronto automatically queries your logs using these filters and groups results in the chart.

No SQL or saved search required.

​
What You Can and Cannot Do

Supported Today:

  • Filter by any field
  • Count-based aggregation
  • Grouping by log field (e.g., service, status code, user agent)
  • Visual types: bar, line, area, top list, table, tree map

Not Yet Supported:

  • Real-time metric streaming
  • Metric math (e.g., rate, percent change)
  • Trace overlays or alert annotations

​
Tips for Migrating Coralogix Panels

  • Rebuild log-based widgets first (e.g., errors by service, login failures)
  • Use the Group by UI to replicate breakdowns
  • For panels comparing services, use a shared filter (e.g., env:prod) and group by service.name
  • Avoid SQL Mode unless needed for advanced use cases

See Bronto Dashboard Documentation