Coralogix
Bronto and Coralogix: A Practical Guide to Scaling Log Management
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
- Log in to Bronto → Settings → API Keys
- 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
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.
Metadata for Search
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:
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:
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:
- Go to Dashboards > Add Widget
- Choose visualization: Line
- Apply filter:
- Set aggregation: Count of events
- Grouped by:
referer
- Set time range: 1 day
- 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 byservice.name
- Avoid SQL Mode unless needed for advanced use cases