# API Keys
Source: https://docs.bronto.io/Account-Management/API-Keys
Create, manage, and rotate Bronto API keys to authenticate integrations and route telemetry to the correct service in your organization.
## Manage API Keys
Navigate to the the `Settings > API Keys` item from the application sidebar to manage your API Keys.
## Create a new API Key
## API Key Roles
Bronto allows users to specificy roles in order to limit what resources an api key can access. We currently provide the following roles:
| Role Name | Description | Required for following features |
| - | - | - |
| Admin | Access to all read write permissions on an account | Creating API Keys |
| Search | Read permissions for an accounts data | Interacting with [REST API](/api-reference/introduction) |
| Ingestion | Used for writing and sending data to a service in your account | Data ingestion |
## Best practices
* Create a separate API key for each service that sends data to Bronto.
* Give each key the least-privileged role it needs. Services that only send data need the Ingestion role.
* Never embed API keys in client-side code, such as browser or mobile apps, and don't share keys between teams.
* Rotate keys on a schedule, and rotate a key at once if you suspect it has been exposed. To rotate a key, create a new key, update the service to use it, then delete the old key.
* Delete keys that are no longer in use.
## Edit API Keys
* Within the API Key page, hover over a key you wish to edit, click pencil icon that appears on the right side
* Here you can edit the roles assocaited with the key and the key name
* Under Permissions we list the various part of the product this given key can interact with
## Deleting API Keys
* Within the API Key page hover over a key you wish to permenantly delete
* Select the trash icon to delete
* **Note:** Deleting a key will permanently impact any services currently using it and revoke any access where it is being used.
# Access Control
Source: https://docs.bronto.io/Account-Management/Access-Control
Bronto offers a flexible access management system that allows you to customize the level at which you control access to your Bronto resources.
## Role Based Access Control
Roles categorize users and define what account permissions those users have, such as what data they can read or what account assets they can modify. By default, Bronto offers three roles.
| Role Name | | Description |
| - | - | - |
| Administrator | | The Administrator Role grants individuals full access and control over the application. |
| Standard | | The standard role grants full access over all non sensitive areas of the application. |
| Read-Only | | The read only role grants read access to non sensitive areas of the application. |
## Custom Roles
Create custom roles to combine multiple permissions into new, tailored roles. A custom role allows you to assign various CRUD permissions across Access Management, API Key Management, Billing and Usage, Dashboards, Integrations, Limits, Log Management, Monitors, and Tags Management.
Once a role is created, you can assign or remove permissions directly by updating the role in the Organization Roles Settings page.
You can assign granular permissions across:
* Access Management
* API Key Management
* Billing & Usage
* Dashboards
* Integrations
* Limits
* Log Management
* Monitors
* Tag Management
You can manage roles in **Organization Settings → Roles**.
#### Note:
Permissions for roles in Bronto are additive — if a user is assigned multiple roles, they receive the union of all permissions from those roles.
For example, if one role grants permission to create monitors and another does not, the user will still be allowed to create monitors.
However, for dataset access permissions, **denials take precedence**: if a dataset or collection is explicitly forbidden, access will be denied even if another role permits it.
***
## Fine-Grained Access with Dataset Restrictions
Bronto supports access restrictions for datasets and collections.
These allow you to:
* Restrict a role to **only access datasets or collections**
* Deny access to specific datasets or collections (even if the role has general read permissions)
### Example Use Cases
* A security team role that only provides access to the `security` collection
* An external auditor role that cannot access PII-related datasets
***
## Best Practices
* Use built-in roles for general access and admin controls.
* Use custom roles to create scoped access patterns (e.g., Billing-only, Security-only).
* Always test new roles with limited users before broad rollout.
***
# Bring Your Own Key (BYOK)
Source: https://docs.bronto.io/Account-Management/BYOK
Encrypt Bronto data at rest using your own AWS KMS customer-managed key (BYOK) for tighter compliance, key rotation, and access control.
## Overview
Bronto supports **Bring Your Own Key (BYOK)** for **encryption at rest**.
When enabled, Bronto encrypts your data using **your own AWS KMS key**, giving you full control over key ownership, lifecycle, and access.
Bronto **never stores or manages your encryption key material**.
When BYOK is enabled:
* Newly ingested data stored in Bronto is encrypted at rest.
* You retain full control over key rotation, disablement, and deletion.
## Enabling Encryption Keys
Encryption keys are an **enterprise feature** and must be enabled by **Bronto Support**.
Once enabled, an **Encryption Keys** section becomes available in your organization settings.
## Creating the key in AWS
### 1) Create a customer-managed KMS key
1. Open **AWS Console → Key Management Service (KMS)**
2. Go to **Customer managed keys**
3. Click **Create key**
4. Choose:
* **Key type:** Symmetric
* **Key usage:** Encrypt and decrypt
* **Region:** **Multi-Region key (Mandatory)**
5. Click **Next**
### 2) Set alias and rotation
1. Choose a key alias, for example:
* `alias/bronto-archive-prod`
2. (Recommended) Enable **automatic key rotation**
3. Click **Next**
### 3) Set key administrators
1. Select your internal AWS admins or security team
2. These users can **rotate, disable, or delete** the key
3. Click **Next**
### 4) Set the key policy (Required)
Replace the default policy with the following customer key policy **(or add the second statement to the default)**.
This policy:
* Keeps full control with your AWS account root
* Allows Bronto to use the key only for encryption and decryption
```json theme={"dark"}
{
"Version": "2012-10-17",
"Id": "key-consolepolicy-3",
"Statement": [
{
"Sid": "EnableIAMUserPermissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxx:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "AllowBrontoKmsUsage",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::637423326566:role/BrontoByok"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
### 5) Copy the KMS Alias ARN
After creation:
1. Open the key in **KMS**
2. Go to the **Aliases** tab
3. Copy the **alias ARN**, for example:
```text theme={"dark"}
arn:aws:kms:eu-west-1:026090548703:alias/bronto-archive-prod
```
## Adding an Encryption Key in Bronto
To add a key once enabled on your account:
1. Go to **Settings → Encryption Keys**
2. Click **Add Encryption Key**
3. Enter:
* **Display Name (optional)** — for identification inside Bronto
* **AWS KMS Alias ARN** — the alias ARN of the KMS key you created in AWS
4. Click **Create**
The key will not be used until it has been activated and Bronto begins storing data for the organization.
***
## Activating the Key
To enable encryption at rest:
1. Open the key
2. Click **Activate Key**
3. Confirm the warning
Once activated:
* All newly ingested data is encrypted using this key.
* The **Last used** date of the key will indicate when this is working.
* The key **cannot be deactivated or replaced via the UI**.
* Reversal requires contacting **Bronto Support**.
* This action is intentional and treated as **permanent**.
***
## Important warnings
Bronto has no control over your KMS key.
Disabling or deleting the key immediately breaks access to encrypted data.
Bronto cannot recover data if the key is permanently lost.
You are responsible for monitoring and managing key lifecycle.
# Multi-Organisation
Source: https://docs.bronto.io/Account-Management/Multi-Org
Operate multiple independent organisations within a single Bronto account, with centralised governance, role-based access, and isolated data.
This guide covers:
* What multi-organisation support does (and does not do)
* How to enable it
* How access works with users and groups
## 1. What Multi-Organisation Support Does
When enabled, multi-organisation support allows you to:
* Create separate organisations under a single parent (management) organisation
* Assign users or groups to each organisation with specific roles
* Cleanly isolate data, dashboards, monitors, and integrations between organisations
* Switch between organisations using a selector in the interface
Each organisation functions as an independent workspace, while the management organisation retains control over access and configuration.
## 2. What Multi-Organisation Support Does Not Do
To avoid confusion, multi-organisation support has the following limitations:
* You **cannot query multiple organisations at the same time**
* All searches, dashboards, monitors, and API requests operate only on the **currently selected organisation**
* There is **no cross-organisation aggregation**, federated querying, or unified analytics view
* Switching organisations fully changes context, including:
* Data
* Dashboards
* Monitors
* Integrations
* Usage
## 3. Enabling Multi-Organisation Mode
To enable multi-organisation support:
1. Go to **Settings → Organisations**
2. Open the **General** tab
3. Toggle **Multi-Organisation Setup** to enable it
You will then see two additional options:
### Create New Management Organisation
* Creates a new, empty parent (management) organisation
* If **disabled**, your current organisation becomes the management organisation
* If **enabled**, you will be prompted to provide a name for the new management organisation
### Grant All Users Access
* Retains access for all existing users after migration
* If disabled, only you (the administrator) retain access initially
* This operation **cannot be undone** without contacting support
> **Note:**\
> The administrator who enables multi-organisation support is automatically added as an **Admin** to:
>
> * The management organisation
> * Any newly created child organisations
### Sign-in Required
After enabling multi-organisation support, **log out and back in** to refresh your session.
## 4. The Organisation Switcher
After signing back in, an organisation selector appears in the **top-left of the navigation menu**.
This dropdown shows every organisation you have access to. Selecting an organisation switches your entire Bronto workspace to that context.
> **Note:**\
> The management organisation is denoted by a **crown icon**.
## 5. Groups: Managing Access at Scale
Groups simplify managing access across multiple organisations.
A **group** is a platform-level collection of users that can be granted roles on one or more organisations.
### Creating a Group
1. Go to **Settings → Groups**
2. Click **Create Group** and provide a name
3. Open the group and add users using the **Edit** button
Groups are:
* Global across the platform
* Visible and manageable **only from the management organisation**
## 6. Assigning Users and Groups to Organisations
To manage organisation access:
1. Go to **Settings → Organisations**
2. Select an organisation
3. Click **Edit Organisation**
You can then:
* Add users directly
* Add groups
* Assign roles to each (e.g. **Viewer**, **Editor**, **Admin**)
### Group Access Behaviour
When adding a group:
* All users in the group automatically gain access
* Permissions are determined by the role assigned to the group
* Access persists until:
* The user is removed from the group, or
* The group’s organisation assignment is changed
> **Roles are additive**\
> A user’s effective permissions are the combined permissions from all roles they hold across direct and group assignments.
## 7. Notes and Behaviour
* **Groups** and **Organisations** settings are only available in the **management organisation**
* Users can belong to multiple organisations with different roles in each
* Removing a user from a group immediately removes their inherited organisation access
* Child organisations **cannot** create or modify groups
# Data Retention
Source: https://docs.bronto.io/Account-Management/Retention
Configure how long Bronto retains your data at the organisation and dataset level to control storage costs and meet compliance requirements.
## Overview
Bronto lets you control how long your data is stored — both as a global default across your organisation and as custom overrides per dataset.
Data marked for deletion will enter a grace period and remains queryable before expiration.
## Organisation Policy
The **Organisation Policy** sets the default retention period applied to all datasets that don't have a custom override. Your plan determines the maximum retention available.
To update the default:
1. Go to **Settings → Plan → Retention**.
2. Under **Organization Policy**, select a retention period from the **Default Retention** dropdown.
3. Click **Save Default**.
Available retention periods are **30 days**, **90 days**, **180 days**, and **365 days**, up to your plan maximum.
## Custom Retention Overrides
You can override the default retention for individual datasets — useful when certain data needs to be kept longer or can be discarded sooner.
To apply a custom override:
1. Under **Filter Datasets**, search for the dataset you want to configure.
2. Select it — it will appear as a **Dataset Rule** tag.
3. Choose a retention period from the **Set retention...** dropdown.
4. Click **Save**.
The dataset will move from **Using Default Retention** into the **Custom Retention Overrides** list, showing its specific policy.
To remove a custom override and revert a dataset to the organisation default, clear the rule from the Custom Retention Overrides list.
## Viewing Retention by Dataset
The right panel shows all datasets grouped by their retention status:
* **Custom Retention Overrides** — datasets with a specific retention rule applied, and the count of datasets affected.
* **Using Default Retention** — all remaining datasets inheriting the organisation default. Expand any namespace to see the individual datasets within it.
# SSO Overview
Source: https://docs.bronto.io/Account-Management/SSO/SSO-Overview
Configure single sign-on (SSO) so users log in to Bronto through your identity provider using SAML or OIDC, instead of a password.
## Overview
Single sign-on (SSO) lets your users log in to Bronto through your existing identity provider (IdP) instead of a Bronto password. Bronto supports both **SAML** and **OIDC** providers.
For step-by-step instructions for a specific provider, see:
* [Google SAML IdP](/Account-Management/SSO/google-saml)
* [Okta OIDC](/Account-Management/SSO/okta-oidc)
* [Microsoft Entra ID](/Account-Management/SSO/entra-id) (SAML or OIDC)
## Add an identity provider
1. In Bronto, go to **Settings** > **Authentication** > **Login Methods**.
2. In the **SSO** section, click **Add Provider** to launch the setup wizard.
At the top of the wizard, set **Choose protocol** to **SAML** or **OIDC**. The wizard then has four steps: **Name**, **Upload** (SAML) or **Provide** (OIDC), **Email**, and **Map**.
### Name
Pick a unique name for this IdP within your organisation.
### Upload (SAML) / Provide (OIDC)
Provide the connection details for your chosen provider:
* **SAML** — Upload the IdP metadata XML from your provider.
* **OIDC** — Enter the **Client ID**, **Client Secret**, and **Issuer URL** from your provider.
The **Paste these into your IdP** panel shows the values you need to configure on the provider side — for SAML the **ACS URL**, **Entity ID**, and **Default Relay State**; for OIDC the **Redirect URI** and **Start URL**. See your IdP-specific documentation for where to enter them.
### Email
Choose the email domains associated with this IdP. They are used to recognise which IdP to use for a given account, and the field is prepopulated with your organisation's email domain. Type a domain and press **Enter** to add it.
Each domain may only be associated with a single IdP — ensure they do not repeat across providers.
### Map
Map your IdP's attributes to Bronto's. The attributes required by Bronto are **First Name**, **Last Name**, and **Email**. Input the matching provider attribute name, as configured in your IdP, in each row (e.g. `given_name` → First Name).
If you wish to use [role mapping](/Account-Management/SSO/SSO-Role-Mapping), also add a mapping to the **custom:member\_of** attribute — click **+ Add role mapping** if a row for it isn't already shown.
Click **Save** to create and enable the IdP.
## Manage providers
Your new IdP is enabled automatically and appears in the **SSO** list on the **Login Methods** page, where you can enable or disable it, view its details, edit it, or delete it. You control which login methods are enabled from the same page — you must always have at least one login method enabled.
If your organisation sends telemetry from a PCI DSS environment, Bronto strongly recommends disabling password login to meet PCI DSS v4.0.1 requirements. Disable it after you confirm that SSO sign-in works, so every user signs in through your identity provider and its MFA.
To view a provider's connection details again (ACS URL, Entity ID, Start URL, etc.), open the provider from the **SSO** list.
## Next steps
If you wish to use role mapping, configure it on the **SAML Role Mappings** tab. See [SSO Role Mapping](/Account-Management/SSO/SSO-Role-Mapping) for more information.
# SSO Role Mapping
Source: https://docs.bronto.io/Account-Management/SSO/SSO-Role-Mapping
Map SAML attributes from your identity provider to Bronto user roles so user permissions are provisioned automatically from your IdP.
## Prerequisites
In order to set up role mapping, you must first create an attribute mapping to **custom:member\_of** in at least one of your IdPs. This can be done when creating a new IdP or by editing an existing one. Go to the [SSO Overview](/Account-Management/SSO/SSO-Overview) for more information on creating an IdP.
## Map SAML attributes to Bronto Roles
1. Go to **Settings**, open **Authentication**, and click the **SAML Role Mappings** tab.
**NOTE:** If the role mappings list is not visible, you likely don't have the **custom:member\_of** attribute mapping configured in your IdPs. Verify this is configured, and contact support in case of any issues.
1. Click the **+ New Mapping** button in the top right corner to begin creating new role mappings. A popup should appear.
2. In the popup, fill in the possible value of the **custom:member\_of** attribute and the appropriate Bronto role from the dropdown. Each user with a matching value, will be given the corresponding role.
3. If you wish, you can use the **add new row** button to configure multiple mappings in one go.
4. Press **Create** to create and enable the mappings.
5. If you wish to edit an existing mapping, hover over it in the list and press the pencil(**Edit**) button.
If you configure multiple mappings with the same value, only the latest one will be in effect.
When a user with a specified identity provider attribute logs in, they will be given the appropriate Bronto role. Likewise if the attribute is removed, their role will also be removed.
If a user doesn't match any attribute mappings, they will be given the **Standard** role by default.
Map every identity provider group that signs in to Bronto to a role explicitly, so no user falls through to the Standard role unintentionally. Give each group the least-privileged role it needs, which can be a custom role you've created. PCI DSS v4.0.1 expects access to be deny-by-default, and the Standard role still grants access to non-sensitive areas.
# Microsoft Entra ID
Source: https://docs.bronto.io/Account-Management/SSO/entra-id
Configure Microsoft Entra ID (formerly Azure AD) as a SAML or OIDC single sign-on provider for Bronto, and map Entra ID groups to Bronto roles.
## Overview
Microsoft Entra ID can be configured as an identity provider for Bronto using either **SAML** or **OIDC**. Both options let your users sign in to Bronto with their existing Microsoft credentials, and both support [role mapping](/Account-Management/SSO/SSO-Role-Mapping) so Bronto permissions are provisioned automatically from your Entra ID group membership.
Choose the option that matches your organization's preference:
* **SAML** — Configure Bronto as a SAML application in Entra ID. Best if your organization standardizes on SAML for enterprise apps.
* **OIDC** — Register Bronto as an app registration and authenticate through OpenID Connect.
Before you begin you need a Microsoft Entra ID tenant and an account with the **Global Administrator**, **Cloud Application Administrator**, or **Application Administrator** role.
For Microsoft's own reference, see [Microsoft Entra ID documentation](https://learn.microsoft.com/en-us/entra/identity/).
If you intend to use role mapping, first create an attribute mapping to **custom:member\_of** when configuring the IdP in Bronto. See [SSO Role Mapping](/Account-Management/SSO/SSO-Role-Mapping).
## Manage SSO providers in Bronto
You configure and manage identity providers from **Settings** > **Authentication** > **Login Methods**. The **SSO** section lists your existing SAML and OIDC providers and lets you add new ones.
Each provider row shows its type (SAML or OIDC), associated email domains, user count, and last login, with controls to enable/disable, view details, edit, or delete it. Click **Add Provider** to launch the setup wizard. On the first step you set **Choose protocol** to **SAML** or **OIDC**; the wizard then has four steps — **Name**, **Upload** (SAML) or **Provide** (OIDC), **Email**, and **Map**.
## SAML authentication
### Step 1: Create the Enterprise Application in Entra ID
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).
2. Navigate to **Identity** > **Applications** > **Enterprise applications**.
3. Click **New application**, then **Create your own application**.
4. Enter a name (e.g. "Bronto"), select **Integrate any other application you don't find in the gallery (Non-gallery)**, and click **Create**.
See Microsoft's [Add an enterprise application](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/add-application-portal) and [Configure SAML-based single sign-on](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/add-application-portal-setup-sso) for full details.
### Step 2: Configure SAML in Entra ID
1. In the new application, open **Single sign-on** and select **SAML**.
2. Edit the **Basic SAML Configuration** and enter the following values from Bronto. They appear in the **Paste these into your IdP** panel on the **Upload** step of the Bronto wizard (see Step 4), and again whenever you open the provider from the **SSO** list:
* **Identifier (Entity ID)** — Use the **Entity ID** from Bronto.
* **Reply URL (Assertion Consumer Service URL)** — Use the **ACS URL** from Bronto.
* **Relay State** — Use the **Default Relay State** from Bronto.
3. Click **Save**.
### Step 3: Configure attributes and claims
Bronto requires **First name**, **Last name**, and **Email** attributes. In **Attributes & Claims**, map the Entra ID source attributes to the attribute names you configured when creating the IdP in Bronto. Entra ID's defaults are:
| Bronto attribute | Entra ID source attribute |
| - | - |
| First name | `user.givenname` |
| Last name | `user.surname` |
| Email | `user.mail` |
To use role mapping, add a **group claim** that emits group membership and map it to the attribute mapped to **custom:member\_of** in Bronto:
1. In **Attributes & Claims**, click **Add a group claim**.
2. Select which groups to emit (e.g. **Groups assigned to the application**).
3. Under **Source attribute**, choose **Group ID**. Bronto matches role mappings on the group's **Object ID** (a GUID in the form `00000000-0000-0000-0000-000000000000`), so the claim must emit group IDs rather than display names.
4. Set the claim name to match the source attribute you mapped to **custom:member\_of** in Bronto.
For details, see Microsoft's [Configure group claims for applications](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims). Then see [Map Entra ID groups to Bronto roles](#map-entra-id-groups-to-bronto-roles) below.
### Step 4: Configure the IdP in Bronto
1. In Entra ID, download the **Federation Metadata XML** from the **SAML Certificates** section.
2. In Bronto, go to **Settings** > **Authentication** > **Login Methods** and click **Add Provider** in the **SSO** section.
3. Work through the wizard:
* **Name** — Give the provider a unique name and set **Choose protocol** to **SAML**.
* **Upload** — Upload the Federation Metadata XML. The **Paste these into your IdP** panel shows the **ACS URL**, **Entity ID**, and **Default Relay State** to configure on the Entra ID side (Step 2).
* **Email** — Add the email domains to route to this provider.
* **Map** — Map your IdP attributes to Bronto's required **First Name**, **Last Name**, and **Email**. To use role mapping, click **+ Add role mapping** and map your group claim to **custom:member\_of**.
4. Click **Save** to create and enable the IdP.
### Step 5: Assign users or groups
1. In the Enterprise Application, go to **Users and groups**.
2. Click **Add user/group** and select the users or security groups who should have access to Bronto.
3. Click **Assign**.
Assigning a security group is recommended over individual users for easier ongoing access management.
## OIDC authentication
### Step 1: Register the application in Entra ID
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).
2. Navigate to **Identity** > **Applications** > **App registrations** and click **New registration**.
3. Enter a name (e.g. "Bronto").
4. Under **Redirect URI**, select **Web** and enter the URI for your Bronto region:
* **EU:** `https://auth.eu.bronto.io/oauth2/idpresponse`
* **US:** `https://auth.us.bronto.io/oauth2/idpresponse`
5. Click **Register**.
6. From the app **Overview**, note the **Application (client) ID** and your **Directory (tenant) ID**.
7. Go to **Certificates & secrets**, create a **New client secret**, and note its value.
See Microsoft's [Register an application with the Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app) for full details.
### Step 2: Configure SSO in Bronto
In Bronto, go to **Settings** > **Authentication** > **Login Methods**, click **Add Provider** in the **SSO** section, and work through the four steps of the wizard.
#### Name
Enter a unique **Provider name** for this IdP within your organisation (e.g. "EntraIDtest") and select **OIDC** as the **Identity Provider type**.
#### Provide
The **Paste these into your IdP** panel on the right shows the values Bronto generates for your account and region. Use these in your Entra ID app registration first:
* **Redirect URI** — e.g. `https://auth.eu.bronto.io/oauth2/idpresponse` (or `auth.us.bronto.io` for US). This matches the Redirect URI you set in Step 1.
* **Start URL** — used for IdP-initiated sign-in.
Then paste your Entra ID values into the fields on the left:
* **Client ID** (from Step 1)
* **Client Secret** (from Step 1)
* **Issuer URL:** `https://login.microsoftonline.com//v2.0`, where `` is your **Directory (tenant) ID** from Step 1.
#### Email
Add the email domains that should route to this provider (e.g. `contoso.com`, `contoso.onmicrosoft.com`). Type each domain and press **Enter**.
#### Map
Tell Bronto where to find each user attribute in the OIDC payload. Entra ID's defaults are:
| IdP attribute | Bronto attribute |
| - | - |
| `email` | Email *(required)* |
| `family_name` | Last Name *(required)* |
| `given_name` | First Name *(required)* |
| `groups` | `custom:member_of` *(for role mapping)* |
| `sub` | — |
To use role mapping, add a row mapping the **`groups`** IdP attribute to **`custom:member_of`**. Click **Save** to create and enable the IdP.
### Step 3: Configure the Homepage URL for IDP-initiated login (optional)
To launch Bronto directly from the Microsoft My Apps portal, set the application's Homepage URL to the IDP-initiated login URL:
1. In the [Microsoft Entra admin center](https://entra.microsoft.com), open the linked **Enterprise Application** for your app registration (from the app **Overview**, click the link next to **Managed application in local directory**).
2. Go to **Properties** and paste the Start URL from Bronto (or an equivalent constructed login URL) into the **Homepage URL** field.
3. Set **Enabled for users to sign-in?** and **Visible to users?** to **Yes**, then click **Save**.
My Apps can take up to 10 minutes to reflect changes after setup. If the tile does not appear immediately, wait a few minutes and hard-refresh the page.
## Map Entra ID groups to Bronto roles
Role mapping uses the **custom:member\_of** attribute. When you emit Entra ID group membership into that attribute (a group claim for SAML, or the groups claim for OIDC), Bronto matches each group value to a Bronto role.
Bronto matches on the Entra ID group's **Object ID** — the GUID assigned to the group in Entra ID, not its display name. You can find a group's Object ID in the [Microsoft Entra admin center](https://entra.microsoft.com) under **Identity** > **Groups** > select the group > **Overview**.
1. Ensure the **custom:member\_of** attribute mapping is configured for your Entra ID IdP, and that Entra ID emits group **Object IDs** into it (see Step 3 of SAML, or Step 2 of OIDC above).
2. In Bronto, go to **Settings** > **Authentication** > **SAML Role Mappings**.
3. Click **+ New Mapping** and create a mapping for each group, selecting the Bronto **Role** and entering the group's Object ID as the **Provider Value** (the **Provider Key** is `custom:member_of`).
For example, to grant the Administrator role to a group, set the **Provider Value** to that group's Object ID (a GUID in the form `00000000-0000-0000-0000-000000000000`) and select **Administrator Role**.
For full details on creating and editing mappings, see [SSO Role Mapping](/Account-Management/SSO/SSO-Role-Mapping).
If a user doesn't match any role mapping, they will be given the **Standard** role by default.
## Troubleshooting
* **Authentication fails:** Verify the Client ID and Client Secret (OIDC) or the Entity ID, ACS URL, and certificate (SAML) are correct.
* **Redirect errors:** Ensure the redirect URI exactly matches the region-specific value configured in Entra ID.
* **User cannot access the application:** Check user and group assignments in the Enterprise Application.
* **Missing user information:** Verify attribute mapping in both Entra ID and Bronto.
* **Roles not applied:** Confirm the group claim emits group **Object IDs** and is mapped to **custom:member\_of**, and that matching Object IDs exist as the **Provider Value** in **SAML Role Mappings**.
* **"Need admin approval":** An administrator must grant consent for the app in **Enterprise Application** > **Permissions** > **Grant admin consent**.
For questions about your Bronto SSO parameters or configuration, contact [support@bronto.io](mailto:support@bronto.io).
# Google SAML IdP
Source: https://docs.bronto.io/Account-Management/SSO/google-saml
Configure Google Workspace as a SAML identity provider for Bronto so users can sign in with their existing Google accounts via single sign-on.
Configure Google Workspace as a SAML identity provider so your users can sign in to Bronto with their existing Google accounts. You start the provider in Bronto to obtain the values to paste into Google, configure the Google SAML app, then finish the Bronto wizard.
## Step 1: Start the provider in Bronto
In Bronto, go to **Settings** > **Authentication** > **Login Methods** and click **Add Provider** in the **SSO** section. Set **Choose protocol** to **SAML**.
### Name
Pick a unique name for this IdP within your organisation (e.g. "Google").
### Upload
On the **Upload** step, the **Paste these into your IdP** panel shows the values you need to configure the Google SAML app — the **ACS URL**, **Entity ID**, and **Default Relay State**. Keep this open while you configure Google in Step 2, then upload the metadata XML that Google gives you back into this step.
## Step 2: Configure the SAML app in Google
[View the dedicated Google instructions](https://support.google.com/a/answer/6087519?hl=en#zippy=%2Cstep-add-the-custom-saml-app)
### Service Provider Details
* **Application Name -** Can be anything
* **Description -** Can be anything
* **ACS URL -** Use the **ACS URL** from the Bronto **Upload** step.
* **Entity ID -** Use the **Entity ID** from the Bronto **Upload** step.
* **Start URL -** Use the **Default Relay State** from the Bronto **Upload** step.
* **Signed Response -** Leave unchecked
* **Name ID -** Select **Basic Information** and **Primary Email**
### Attribute Mapping
Bronto requires a First name, Last name and Primary Email attributes from Basic Information. These can map to any fields, as long as you match the names used when configuring the IdP in Bronto.
If you wish to use role mapping, you must also configure attribute mapping from group membership to the attribute mapped to **custom:member\_of**. See [SSO Role Mapping](/Account-Management/SSO/SSO-Role-Mapping).
## Step 3: Finish the wizard in Bronto
Back in Bronto, upload the metadata XML from Google on the **Upload** step, then complete the remaining steps.
### Email
Add the email domains that should route to this provider (e.g. `bronto.io`). Type each domain and press **Enter**.
### Map
Map your Google attributes to Bronto's required **First Name**, **Last Name**, and **Email**, matching the attribute names you configured in Google. To use role mapping, click **+ Add role mapping** and map your group membership attribute to **custom:member\_of**.
Click **Save** to create and enable the IdP.
# Okta OIDC
Source: https://docs.bronto.io/Account-Management/SSO/okta-oidc
Configure Okta as an OIDC single sign-on provider for Bronto so users authenticate through your existing identity provider with centralised access.
## Overview
OpenID Connect (OIDC) Single Sign-On allows your organization to manage authentication through your existing identity provider. This integration streamlines user access, enhances security, and simplifies user management across your organization. This page covers configuring Okta as an OIDC provider; for other providers see the [SSO Overview](/Account-Management/SSO/SSO-Overview).
### Step 1: Create an OIDC Application in Okta
See Okta's [Create OIDC app integrations](https://help.okta.com/en-us/content/topics/apps/apps_app_integration_wizard_oidc.htm) for full details.
1. Sign in to your Okta Admin Dashboard
2. Navigate to **Applications** > **Applications**
3. Click **Create App Integration**
4. Select **OIDC - OpenID Connect** as the Sign-in method
5. Choose **Web Application** as the Application type
6. Click **Next**
7. Enter an Application name (e.g., "Bronto")
8. Add the following Redirect URI which will depend on your Bronto accounts region:
* **EU:** `https://auth.eu.bronto.io/oauth2/idpresponse`
* **US:** `https://auth.us.bronto.io/oauth2/idpresponse`
9. Under "Allowed grant types," ensure "Authorization Code" is selected
10. Under "Assignments," select which users or groups should have access
11. Click **Save**
12. Note the **Client ID** and **Client Secret** from the application details
### Step 2: Configure the provider in Bronto
Navigate to **Settings** > **Authentication** > **Login Methods** and click **Add Provider** in the **SSO** section. Set **Choose protocol** to **OIDC**, then work through the wizard:
1. **Name** — Pick a unique provider name within your organisation (e.g. "Okta").
2. **Provide** — Enter the **Client ID** and **Client Secret** from Step 1, and the **Issuer URL** (`https://your-okta-domain.okta.com`). The **Paste these into your IdP** panel shows the **Redirect URI** (which matches the one you set in Step 1) and the **Start URL** — copy the Start URL for Step 3.
3. **Email** — Add the email domains to route to this provider (e.g. `your-company.io`).
4. **Map** — Map Okta's attributes to Bronto's required fields. Okta's defaults are `given_name` (First Name), `family_name` (Last Name), and `email` (Email). To use role mapping, click **+ Add role mapping** and map your group claim to **custom:member\_of**.
5. Click **Save** to create and enable the IdP.
### Step 3: Add the Start URL to Okta
1. Go to the Okta app created above and select **Edit** next to **General Settings**.
2. Paste the **Start URL** from Step 2 into the **Initiate login URI** field and save.
3. Ensure **Login initiated by** is set to **Either Okta or App**.
4. Ensure **Display application icon to users** is enabled.
### Troubleshooting
* **Authentication fails:** Verify the Client ID and Client Secret are correct
* **Redirect errors:** Ensure the redirect URI exactly matches what's configured in Okta
* **User cannot access the application:** Check group assignments in Okta
* **Missing user information:** Verify attribute mapping in both Okta and Bronto
* **App Missing from Okta panel:** Ensure "Login initiated by" setting is set to "Either Okta or App", is assigned to users and "Application visibility" is set to "Display application icon to users"
# Security
Source: https://docs.bronto.io/Account-Management/Security
Learn how Bronto protects your data with SOC 2 Type II compliance, encryption at rest and in transit, role-based access controls, and audit logging.
## Certifications and Compliance
* **SOC 2 Type I and Type II:** Bronto has completed both its SOC 2 Type I and SOC 2 Type II audits, and maintains SOC 2 Type II compliance through recurring audits. Current SOC 2 reports and bridge letters are available on request from the [Bronto Trust Center](https://trust.bronto.io).
* **GDPR Compliance:** Ensures the privacy and protection of personal data for customers in the EU, adhering to the General Data Protection Regulation.
* **CCPA Compliance:** Guarantees the privacy and protection of personal data for customers in California, in accordance with the California Consumer Privacy Act (CCPA). Requests related to CCPA can be addressed by contacting [support@bronto.io](mailto:support@bronto.io).
* **Continuous Compliance Monitoring:** Utilizes advanced tools and systems to continuously monitor compliance with security standards and regulations, promptly addressing any gaps.
For the current list of certifications, security controls, audit reports, and sub-processors, see the [Bronto Trust Center](https://trust.bronto.io).
## Comprehensive Security Measures
Bronto employs a comprehensive approach to data security, encompassing encryption, penetration testing, system protection, and robust organizational measures.
## Data Encryption
At Bronto, data is encrypted both at rest and in transit, adhering to industry standards and undergoing regular audits to ensure maximum security.
* **Data at rest** is stored within Amazon Web Services (AWS) infrastructure and secured with AES-256 bit encryption provided by AWS technologies.
* **Data in transit** is protected using AES-256 bit encryption and TLS to secure network traffic.
## Data Residency
Bronto currently offers two regional environments: one where data is ingested and stored in the EU, and one where data is ingested and stored in the US. You select your region when creating your Bronto account.
The EU and US environments are isolated from each other. Data sent to the EU environment remains in EU data centres, and data sent to the US environment remains in US data centres.
After selecting a region, configure your agents, collectors, and integrations to send data to the matching Bronto ingestion endpoint. See [Ingestion Endpoints](/getting-started/bronto-endpoints) and [Connect OpenTelemetry Collector to Bronto](/agent-setup/open-telemetry) for regional endpoint details.
## Penetration Testing
Bronto conducts regular vulnerability scans and third-party penetration tests to proactively identify and mitigate potential security threats. The latest penetration test reports are available on request from the [Bronto Trust Center](https://trust.bronto.io).
## System Protection and Resilience Against Failure
Bronto systems are segmented into separate networks and protected by restrictive firewalls and Virtual Private Networks (VPNs) to secure network traffic and prevent unauthorized access. Network segmentation isolates sensitive data and systems. Regular backups and tested data recovery procedures ensure business continuity. Additionally, vulnerability assessments and patch management processes are in place to guard against known vulnerabilities.
## Organisational Security Practices
Bronto's commitment to security extends beyond technological measures to include comprehensive organizational practices:
* **Employee Training:** All employees receive regular training on security best practices, including phishing awareness, data handling procedures, and incident response protocols.
* **Stringent Security Requirements:** We enforce stringent security measures such as encrypted storage and two-factor authentication.
* **Security Policies:** Our comprehensive and regularly updated policies cover all aspects of data protection and compliance, ensuring robust governance.
* **Incident Response:** A thorough response plan is in place for the prompt identification, assessment, mitigation, and remediation of security incidents, with predefined procedures for effective handling.
* **Continuous Monitoring:** We utilize Intrusion Detection Systems (IDS) for real-time threat detection and analysis.
## Sub-processors
Bronto collaborates with a limited number of trusted sub-processors. For a complete list, see [Sub-processors](https://trust.bronto.io/subprocessors). We regularly review all third parties to ensure they meet our high security standards.
## Report Vulnerabilities
Bronto takes all reports seriously and follows a responsible disclosure process. Please submit any vulnerabilities via email to [security@bronto.io](mailto:security@bronto.io).
# User Management
Source: https://docs.bronto.io/Account-Management/User-Management
Invite, edit, and remove users in your Bronto organisation, assign roles, and review access permissions from the Users settings page.
From the `Users` page, you can edit the roles of existing users, their name and view what access permissions they currently have.
## Passwords
If you don't sign in through SSO, you sign in to Bronto with your email address and a password.
A password on its own is the weakest way to sign in. Use [SSO](/Account-Management/SSO/SSO-Overview) with your identity provider enforcing MFA, or add [MFA](#multi-factor-authentication-mfa) to your Bronto login. Administrators choose which login methods are enabled in **Settings** > **Authentication** > **Login Methods**.
### Password requirements
Your Bronto password must:
* be at least 8 characters long
* include at least one uppercase letter, one lowercase letter, one number, and one symbol
### When to change your password
If you sign in with a password only, without SSO or MFA:
* Change your password periodically.
* Change your password straight away if:
* you suspect or know that it has been compromised
* someone else may have seen it
* you signed in on a shared device and are leaving that device
If you suspect your password has been compromised, also tell your organisation administrator.
To change your password, go to the Settings page from the left sidebar, select Profile, then select the Security tab.
## Multi-Factor Authentication (MFA)
Multi-Factor Authentication (MFA) requires a user to present more than one type of verification to authenticate to a system.
We support most authenticator apps including Google Authenticator, Microsoft Authenticator, Duo Security and more.
* To setup MFA for your login visit the Settings page from the left sidebar
* Select Profile, then from under the Security tab select the Password and Authentication option
* From here Click Add to be presented with a QR code to scan with your desired Authentication app
* Once Scanned, click next and enter the code from your authenticator app and click next.
If you sign in through SSO, configure MFA in your identity provider.
Each user enables MFA for their own login. Administrators can't require MFA for all users in Bronto. To enforce MFA across your organisation, use [SSO](/Account-Management/SSO/SSO-Overview) with MFA enforced by your identity provider.
If your organisation sends telemetry from a PCI DSS environment, Bronto strongly recommends using SSO with MFA enforced by your identity provider, and disabling password login, to meet PCI DSS v4.0.1 requirements. See [Manage providers](/Account-Management/SSO/SSO-Overview#manage-providers).
## Teams
It is possible to create teams in Bronto. From within Organisation Settings you will find a Team menu option where you can manage teams and their assigned users.
### Assign Datasets to a Team
Once a team is created for your organisation, you can tag a dataset to associate it with a specific team.
* Navigate to the Logs page
* Highlight a Dataset you wish to associate with a team
* Click the "Dataset Settings" option
* Fill out the required fields
* Save Changes
### Monthly Ingestion Limit
Bronto allows setting ingestion limits per team. Setting an ingestion limit (in Bytes, GB, TB etc) will restrict the amount of data that can be ingested each month by datasets assigned to a given team. To set a limit, navigate to the team page then select the edit icon next to a team you wish to set a limit for.
# FAQ
Source: https://docs.bronto.io/FAQ
Answers to common questions about the Bronto observability platform, including ingestion, retention, querying, integrations, and account configuration.
## Why didn't sending metrics or traces create a dataset?
Datasets and collections are for **logs only**. OpenTelemetry metrics sent to `/v1/metrics` appear in the [Metric Explorer](/metrics/explore-metrics), and traces sent to `/v1/traces` appear in [Explore Traces](/tracing/explore-traces). They do not create or appear in datasets or collections, even when the request includes `x-bronto-dataset` or `x-bronto-collection`.
`service.name` and `service.namespace` still provide useful service identity on metrics and traces, but their Dataset and Collection mapping applies only to log records.
## Do I need to create a log dataset before sending data?
No. When Bronto successfully receives a log event with a dataset and collection name, it creates that log destination automatically if it does not already exist. If you are sending metrics or traces, check the corresponding explorer instead of waiting for a dataset to appear.
# My Data
Source: https://docs.bronto.io/My-Data/My-Data
Manage your Bronto data, review collections and datasets, monitor data quality, and explore ingestion and search usage from the My Data page.
Use **My Data** to manage the data in your Bronto account and understand how it is being used. The page combines dataset management, parser visibility, data quality, usage summaries, and usage explorers in one place.
From **My Data**, you can:
* Review collections and datasets.
* Track monthly ingest volume and search quota usage.
* Check parser coverage and data quality.
* Open the ingestion and search usage explorers.
* Create usage alerts for monthly search or ingestion thresholds.
## Collections and datasets
The **Collections and Datasets** table lists the data available in your account. Use it to search collections or datasets, inspect volume, see parser assignments, review team and tag metadata, and add new data sources.
Top-level summary cards show ingest volume, search quota usage, and data quality. Use the **Explore** actions on the ingest and search cards to open the corresponding usage explorer.
## Usage Dataset
Bronto automatically provides a usage dataset for both Search and Ingestion when an account is created, enabling you to monitor key metrics.
* Search: Metrics are logged every 2 minutes, capturing usage per dataset and collection.
* Ingestion: Metrics are also logged every 2 minutes, tracking ingestion usage per dataset and collection.
## Usage explorers
Usage is accessed from **My Data**. Use the ingestion and search explorers to analyze usage patterns, compare datasets and collections, and understand quota consumption.
### Ingestion Explorer
The **Ingestion Explorer** shows total ingestion volume, average daily ingestion, and a grouped breakdown over the selected time range. Toggle between **Volume** and **Cost** views, group by dataset, collection, team, or tag, and apply filters to narrow the results.
### Search usage
The search usage view helps you understand how search quota is being consumed across datasets, collections, teams, tags, and users. Use it to identify high-volume searches and monitor quota usage during the month.
## Usage alerts
From **My Data**, click **Usage Alerts** to view existing alerts or create a new usage alert. Alerts can notify you when monthly search or ingestion usage exceeds a threshold that you define.
To create an alert, provide an alert name, description, threshold value, and destination. Bronto can deliver usage alerts to an email address or an existing webhook.
## REST API
Use the [Usage API](https://docs.bronto.io/api-reference/usage/get-the-usage-over-a-period-of-time-for-a-log-id) to retrieve usage data for a specific dataset over a defined timeframe.
## Calculations
The displayed usage values vary depending on the endpoint and feature. Below are the units of measurement and how they are calculated:
* Usage API: Displays data usage in Bytes.
* Usage Dataset: Displays data usage in Bytes.
* My Data ingest volume: Data usage is calculated in GB (1 GB = 1,000,000,000 Bytes).
* My Data usage explorers: Data usage is displayed in GB (1 GB = 1,000,000,000 Bytes).
# Dashboards
Source: https://docs.bronto.io/Search-and-Visualize/Dashboards
Build Bronto dashboards from metrics and other telemetry to visualize application performance, track trends, and share live views with your team.
## Overview
Navigate to the Dashboard page in Bronto by clicking on the "Dashboards" item in the application sidebar.
## Create a new Dashboard
To create a new Dashboard, click on the "New Dashboard" button in the application sidebar.
1. Choose a name for your Dashboard.
2. Once the dashboard is created, click Add Widgets.
3. Choose a visualization type for your metric (e.g. Bar, Line, Area, Query Value, Top List, or Tree Map).
4. Select the data you want to associate with the widget. For a metric query, select the metric and aggregation function.
5. Apply a filter. For more details, see the [Search Syntax help page](/query-syntax/search-syntax).
6. Lastly, give the widget a title and select Save. Save up to 50 widgets per dashboard.
## Add Queries and Formulas to Widgets
Use **+ Add Query** and **+ Add Formula** to build a widget from more than one query result. Each query has a name, such as `bytes` or `events`, which you can reference in a formula.
### Add a Query
Select **+ Add Query** to add another independently configured query to the widget. The new query can use a different scope, filter, aggregation, or grouping from the first query.
For Sum, Summary, and Histogram metrics, select **Rate of sum** to display the sum of metric values per second, or **Rate of count** to display the number of observations or metric points per second. For details and examples, see [Aggregation functions](/metrics/explore-metrics#aggregation-functions).
For example, to prepare a widget that visualizes the average number of bytes per event:
1. Configure query `bytes` to return the sum of `bytes_total`.
2. Select **+ Add Query**.
3. Configure query `events` to return the sum of `event_count`.
The widget now has the total bytes in `bytes` and the total event count in `events`.
### Add a Formula
Select **+ Add Formula** to calculate a value from numbers, query results, or a combination of both. Reference a query by entering its query name in the formula.
Formulas support:
* Parentheses: `(` and `)`
* Addition, subtraction, multiplication, and division: `+`, `-`, `*`, and `/`
* Numerical constants, including decimals, such as `100`, `5`, or `1.5`
* Variables that match the names of queries in the widget
Variable names must be alphanumeric and start with a letter. Only variables based on query names in the widget are allowed. You can reference any number of variables in a formula, and each widget can include up to six queries.
You can also use `+` and `-` as unary operators to explicitly set the sign of a value. For example, `bytes + -5`, `-events + 1000`, and `bytes + +events` are valid formulas.
Continuing the bytes-per-event example:
1. Select **+ Add Formula**.
2. Enter `bytes / events` to divide the total bytes by the total event count.
3. Select a visualization type and save the widget.
The widget displays the average number of bytes per event.
## Normalize series
For line, area, and other time series widgets with at least three queries, use the **Normalize** toggle to compare trends across series with different magnitudes. Normalization scales each series in the selected time range from its own minimum and maximum values into a `0`-to-`1` range.
Normalization affects how the widget is displayed. It does not change the underlying query, metric, formula, or raw values. Use it when the shape of each series matters more than comparing absolute values, such as comparing request volume and latency trends on the same chart.
When comparing two queries, Bronto uses a dual-axis chart automatically if each series has a different unit selected.
Units do not affect normalization results, but they do format the values displayed in tooltips.
## AI Widget Creator
Bronto includes an AI assistant that can create dashboard widgets for you from a plain English prompt. This removes the need to manually configure datasets, aggregations, filters, and visualization types — useful when you're unfamiliar with the underlying data.
### How to use it
1. Open an existing dashboard and click **Add Widget**.
2. At the top of the widget creation form, enter a prompt describing what you want to see. For example: *"show me the errors in my data in the last hour"*.
3. The AI will automatically populate the form fields below — dataset selection, visualization type, aggregation, filters, and widget name.
4. The preview updates instantly so you can see the result before saving.
5. If the output looks right, click **Save**. If not, adjust the form fields manually or send a follow-up prompt to refine it further.
### Real-time feedback
As soon as you submit a prompt you'll see live status updates showing what the AI is doing — loading context, processing your request, validating the widget — before it replies with an explanation of what it created.
### Iterating on a widget
If the first result isn't quite right you have two options:
* **Manually adjust** the form fields directly.
* **Continue the conversation** by sending a follow-up prompt with more context. The assistant retains the session so it understands your previous messages.
## Visualization Types
Visualization types are the various charts you can include in your widget to display your data.
### **Bar Graph**
A bar graph is a visual representation of data that helps analyze and interpret the frequency, volume, or other metrics associated with your data. Example usages include showing error frequency over time, log volume by source, and request counts by status code.
### **Line Graph**
A line graph is a graphical representation of information that changes over a period of time. It is a chart made by joining points using line segments. Line graphs are particularly effective for showing trends and patterns over a continuous period. They are ideal for understanding how metrics change over time. Example usage includes error rates over time, throughput over time, and displaying response times.
### **Area Graph**
An Area Graph is a visual representation of data that utilizes both lines and filled areas to convey information over a period of time. This type of chart is particularly effective in showcasing data trends and variations over a specified period or across different categories.
### **Query Value**
This widget can display the latest value from your various search queries across a specific time window.
### **Top List**
The top list visualization enables you to display a list of search values with the most or least of any metric or event value. Examples include graphing CPU usage, disk space, or costs of particular services.
### **Tree Map**
Tree maps are used to represent hierarchical data as nested rectangles. They help in understanding the structure and distribution of data within a hierarchy. Examples include log volume by source and type, error distribution across services, resource allocation, and other hierarchical metrics.
### **Percentiles**
Analyze your data with percentile views, including P75, P90, P95, and P99, for deeper insights into performance and trends.
## **Full-Screen Mode**
In full-screen widget mode, when using bar, line, or area visualizations, you can now chart and compare previous time periods by days, weeks, months, or years.
The full-screen mode toggle is located in the top right of each widget, next to the edit options. You can also select or deselect keys to customize the data displayed on the graph.
# Log Search
Source: https://docs.bronto.io/Search-and-Visualize/Log-Search
Explore millions of log events in Bronto with the Search page, using a single search syntax with autocomplete and SQL-style filtering to analyze your data.
You can refine your search results and filter out irrelevant events using Bronto's [search syntax](/query-syntax/search-syntax), which combines autocomplete with SQL-style filtering for both quick searches and more advanced queries.
## Overview
To start searching logs, click on the "Logs" item in the application sidebar.
1. Select the logs you wish to search from the log selector on the left side of the page. One or more logs may be selected. Alternatively, turn on [Auto-resolve](#auto-resolve-datasets) and Bronto picks the datasets for you based on your query.
2. Select the time range to execute your search on.
3. Enter a search query in the search bar to filter results, or leave it empty to return all log events. Learn more about our search syntax [here](/query-syntax/search-syntax).
## Auto-resolve datasets
Instead of choosing datasets yourself, you can let Bronto choose them from your query. Turn on the **Auto-resolve** switch to the right of the dataset selector, then write your query as usual. Bronto finds the datasets your query could match and searches only those.
### How datasets are chosen
Auto-resolve uses every field your query names:
* **Search filter**: Bronto picks the datasets your filter could match. For example, `status >= 500` only picks datasets that have a `status` field.
* **Calculate and Group by**: in time series views, fields used in a calculation (such as the `duration_ms` in an average) or in **Group by** narrow the choice to datasets that also have those fields.
Auto-resolve doesn't work with [full text search](/query-syntax/search-syntax#free-text-search). Bare words such as `error` match text anywhere in an event rather than a field, so Bronto can't use them to choose datasets. For full text searches, turn Auto-resolve off and select your datasets yourself.
The chosen datasets update as you build your query: when you finish a condition (by typing a space, picking a suggestion, pasting, or clicking away from the search bar), when you remove a condition, and when you change **Calculate** or **Group by**. Bronto shows **Resolving…** while it works. Your current results stay on screen until you run the search.
If your query doesn't name any fields, Bronto keeps the datasets it last chose. When nothing has been chosen yet, it prompts you to add a field to your query, and the **Calculate** and **Group by** field lists include fields from all of your datasets so you have somewhere to start.
### Reviewing and adjusting the chosen datasets
The chosen datasets appear as chips next to the dataset selector, grouped by collection, along with a count of how many datasets will be searched. To adjust them:
* Click a chip to see the datasets it contains and deselect any you don't want.
* Remove a chip to drop its datasets from the search.
* Use the dataset selector to add or remove datasets. Auto-resolve stays on.
* Click **Clear** to empty the selection. Auto-resolve stays on and picks datasets again the next time you edit your query.
Adjustments apply to the query on screen. When you edit the query, Bronto picks the datasets again and replaces your adjustments.
### Key matching
Open the arrow next to the **Auto-resolve** switch to change how field names in your query are matched against the fields in your datasets. The panel shows how many datasets currently match.
| **Setting** | **Options** |
| - | - |
| **Match** | **Exact** (default): a dataset's field name must match the name in your query. **Partial**: a dataset's field name only needs to contain it, so `status` also matches `http.status_code`. |
| **Case** | **Sensitive** (default) or **Ignore**. |
| **Include synonyms** | Also matches datasets that store the same information under a different field name. Bronto lists the synonyms it found; click one to replace a field in your query with it. **Partial** matching is unavailable while synonyms are on. |
A dot on the arrow shows that you've changed these settings from their defaults.
### When no datasets match
If no dataset matches your query, Bronto shows which field it couldn't find and doesn't run the search. Check the field's spelling, or open **Key matching** and try **Partial** matching, **Ignore** case or **Include synonyms**. If your filter matches datasets but none of them have a field used in **Calculate** or **Group by**, Bronto names that field so you can change or remove it.
If the datasets couldn't be resolved, for example because of a network error, click **Retry**.
### Turning Auto-resolve off
Turn the **Auto-resolve** switch off to go back to choosing datasets yourself. The datasets that were chosen stay selected, so you can carry on from them.
Bronto remembers whether Auto-resolve is on for each organization in your browser. Saved searches open with the datasets they were saved with, as do links to searches where the datasets were chosen by hand; turn the switch on if you want Bronto to choose instead. Auto-resolve can't be changed while Live Tail is running.
## Search Result
### Timeline
A time series showing where the results fall across the search time range is displayed immediately below the search bar.
### Event Results
The log entries returned by the search are displayed in tabular format below the summary. The table has a column for each field that was configured in the fields textbox, by default all fields are shown.
Clicking on any row in the table opens a sliding panel which displays various tabs related to the event which include Event Attributes, Resource Attributes and the Raw Event. From this pane you can can use keyboard arrows to view previous/next event.
### Click-to-filter from table cells
Click a value in a List or Table view cell to quickly refine your results. Select **Add Filter** to add the field and value to your current query, or **Replace Filter** to replace the current query with that condition.
### View Context
Use **View context** on an event to open a context view centered on the selected log entry. This lets you inspect the events immediately before and after the selected event so you can understand what happened around it without rebuilding the search manually.
In the context view, Bronto keeps the selected event as the anchor and loads surrounding events in chronological order. You can also jump back to the original context event from the context view header.
### Time Series Results
The time series views allow you to compute statistical functions over a specified time range, enabling deeper insights into your event data by visualizing trends and patterns.
The following functions are supported:
| **Function** | | **Description** |
| - | - | - |
| **Count** | | The total number of events within the specified time range. |
| **Average** | | The average value of a specified numeric attribute in your events. |
| **Min** | | The minimum value of a specified numeric attribute in your events. |
| **Max** | | The maximum value of a specified numeric attribute in your events. |
| **Sum** | | The total sum of a specified numeric attribute your events. |
| **Median** | | The median value of a specified numeric attribute in your events. |
Additionally, the time series results supports grouping data by multiple dimensions (up to 5).
Group-by results are exact for up to 1000 unique groups. For example, if you group by user and action, the combination of alice, login and alice, logout counts as two distinct groups. When there are more than 1000 unique groups, an approximation is used, returning the most frequent groups.
### Automatic Parsing
#### Errors & Warnings
Bronto automatically detects errors and warnings in your logs enabling you to jump directly into your data for deeper analysis and faster troubleshooting.
For HTTP-like logs, status codes are automatically categorized: 5xx as Error and 4xx as Warn.
For application logs without a defined log level, errors are identified from stack traces, Kubernetes klog errors and Kernel Out of Memory errors.
## BrontoScope: AI Error Investigation
When you spot an error event in your logs, BrontoScope can investigate it for you automatically. Click any error event to open the event panel, then select **Investigate with AI** to generate an AI-powered investigation report with supporting evidence.
For the full workflow, capabilities, and best practices, see [BrontoScope](/ai-features/brontoscope).
#### Parsing Of Attributes
Bronto automatically parses the attributes in your log data for common log formats (e.g., json, syslog, apache, java gc, etc.).
For uncommon unstructured or custom log formats, Bronto will parse the attributes in your log data according to the following specification for key-value pairs:
A key value pair consists of a key, followed by a separator, and then a value:
```
```
* A `` is one or more of the following characters: "` `" (space), "`,`" (comma), "`\t`" or "`\r`" or "`\n`" or "`\r\n`".
* A `` is any sequence of: the alphanumeric characters, "`_`", "`.`", "`$`", and "`@`".
Other characters are not allowed unless they are escaped using quotation marks, e.g., `"key[1]"` for the attribute named key\[1].
Additionally, a key must have at least one non-numeric character.
* A `` is the character "=" or ":". It can be preceded and/or followed by a space.
* A `` is any sequence of: the alphanumeric characters, "-", \_", ".", "\$", and "@".
Quotation marks can be used to escape values with special characters, e.g., `key="hello world"` for the value "hello world".
For example the following log event
```
timestamp="2025-07-15T14:32:18Z" level=INFO service="auth-service" userId=98765 ip="192.168.12.45" action=login
```
Will be parsed as
* The `timestamp` attribute has the value `2025-07-15T14:32:18Z`
* The `level` attribute has the value `INFO`
* The `service` attribute has the value `auth-service`
* The `userId` attribute has the value `98675`
* The `ip` attribute has the value `192.168.12.45`
* The `action` attribute has the value `login`
### Custom Parser
If your log format needs more than Bronto's automatic field extraction, use **Custom Parser** to turn unstructured events into structured, queryable data tailored to your dataset.
For setup, supported formats, and implementation details, see [Custom Parser](/core-features/custom-parser).
### Top Key Sampling
Bronto automatically tracks the most frequently occurring keys and attributes identified during regular dataset sampling. This helps Bronto understand the most frequently occurring keys and attributes in your log data.
These top keys are used to populate dropdown menus across search, dashboards, and Bronto’s monitoring features.
**Note:** Less common keys may not appear in the top list. In such cases, users can manually type the desired key in auto-populated fields.
### PII Masking
You can enable PII masking in Bronto to hide any personal identifiable information that may be present in your log data.
To enable PII masking you must create a [custom role](https://docs.bronto.io/Account-Management/Access-Control#custom-roles) with the `Read PII Data` permission disabled, and associate the role with individual users.
Users will see `********` in place of potentially sensitive information, for example:
```
user="******** ********" ip="********" msg="Hello, I'm interested in your Positive Psychology course. Please send more information to my email ********. Thanks!"
```
Currently Bronto masks the following PII by default:
* Full Names
* Email addresses
* IPV4 & IPV6 addresses
* Phone numbers
Reach out to support if you require masking for other types of PII.
### Sort By Column
In the "List of Events" view, you can sort events by any column in either ascending or descending order.
Once sorted, the events will be displayed in the selected order. However, please note the following limitations:
* If more than 25,000 events match your filter, only the first 25,000 matches will be included in the sort.
In that case, the timeline will show a greyed-out section representing the portion of the time range that was excluded.
* To sort over a larger time range, try refining your filter to match 25,000 events or fewer.
For example, if you are interested in the slowest response times in some logs, you could filter using conditions like `duration_ms>2000` or `duration_ms>4000` to reduce the number of matching events.
* You can view up to a maximum of 1000 events from the overall sorted set of events.
Attributes are sorted alphabetically or numerically, depending on which datatype is more common for that attribute.
Events that don't have the selected attribute are excluded from the sorted results.
## Timestamps & Out-of-Order Ingestion
### How Bronto Handles Timestamps
Bronto attempts to parse the timestamp directly from each log event and use it for indexing. TThe timestamp must be provided in a key called timestamp or Timestamp. Common formats such as ISO 8601 are supported. If a timestamp is absent, unrecognized, or too far in the past, Bronto falls back to the **ingestion timestamp** — the time the event arrived at the platform.
#### Batching Window
Bronto accepts out-of-order events with timestamps up to **2 hours in the past**. Events with timestamps older than this window may not be indexed against their original event timestamp.
### Default Behavior: Parallel Ingestion
By default, when multiple ingestion requests are processed in parallel, events for a dataset may arrive out of order. In this case, Bronto may reassign some timestamps during indexing to avoid adding an ingestion delay. This is acceptable for most analytical use cases — such as CDN or HTTP access logs — where aggregate patterns matter more than the precise sequence of individual events.
However, in scenarios where multiple agents are batching events over longer intervals (e.g. OpenTelemetry collectors with long flush windows), this default behavior can cause spikes where many events are indexed with the same timestamp. If accurate per-event timestamps are important to you, **Out-of-Order Handling** can be enabled.
### Out-of-Order Handling
When Out-of-Order Handling is enabled, Bronto will never overwrite the timestamp parsed from a log event. Instead of reassigning timestamps, Bronto sorts events before indexing them, preserving their original order.
This is particularly useful for:
* Logs sent in large and sparse batches by multiple agents
* Any pipeline where there is a meaningful delay between event creation and delivery
With Out-of-Order Handling enabled, there may be a delay before events appear in search results and dashboards, as incoming data is sorted prior to indexing. For high-volume log sources receiving events in a heavily unordered fashion, Bronto may need to delay and batch the sorting process, resulting in a maximum ingestion delay of up to **5 minutes** under normal circumstances.
### Expected Ingestion Latency
Even under normal conditions, data travels via different components that may introduce lag. This includes:
* Batching interval at source (e.g. an OTel batch processor)
* Network transit time
* Pipeline processing and parsing
An end-to-end delay of up to 30 seconds is expected under normal conditions. Delays may increase during severe load spikes or incidents. No data loss will occur for packets accepted by the Bronto ingestion endpoint — acceptance is confirmed by an HTTP 200 response.
### Enabling Out-of-Order Handling
Out-of-Order Handling configuration will be available directly in the Bronto UI shortly. In the meantime, contact support to have it enabled for your organisation.
# Visualization
Source: https://docs.bronto.io/Search-and-Visualize/Log-Visualization
Visualize your data in Bronto with charts, time series, and aggregations driven by SQL queries to expose trends, errors, and performance issues.
Read our [search syntax](/query-syntax/search-syntax) documentation for more information on how to write search queries.
## Overview
Visualizations is a feature that allows users to displayed the data returned from searches. Using the search query editor you can select from List, Timeseries, Table, Top List, Pie Chart and Tree Map views to visualize your data.
## List
List displays the results that are returned from your search query. This alows you to review a group of events. From here you can toggle to full screen mode, table view and sort results by oldest first.
In List view selecting the options menu will display several toggle features which you can choose from the following options: Timeline graph, Wrap lines, date column, content column. From this option page you can also add further columns based on your results.
## Timeseries
Visualize your data over a selected timeframe. Toggle between viewing as Line graph or Bar chart. Adding further groups, the timeline will plot and graph the key and values.
## Table
A table view is a way to represent your data in a structured, tabular format. This format allows users to quickly scan and understand the data by organizing it into rows and columns depending on the fields selected.
## Pie Chart
A pie chart can be used to visualize the distribution of various events or categories, making it easier to understand the relative frequency or importance of different types of data.
## Top List
A top list chart is used to display the most frequent or critical events, errors, or sources, helping prioritize issues that need attention.
## Tree Map
Tree maps help visualize hierarchical data, showing proportions and relationships within the data set and gain valuable insights into the hierarchical structure and distribution of your data, aiding in performance monitoring, resource allocation, and issue detection.
# Data Organization
Source: https://docs.bronto.io/Search-and-Visualize/Partitions
Organize log data in Bronto using datasets, collections, tags, and partition tags to scope queries, control access, and manage retention efficiently.
## Core Concepts: Datasets & Collections
Log events in the Bronto Logging Platform are organized and stored in **datasets** and **collections**.
Datasets, collections, dataset tags, and partition tags apply to **logs only**. Metrics and traces are not stored in datasets or collections: view metrics in the [Metric Explorer](/metrics/explore-metrics) and traces in [Explore Traces](/tracing/explore-traces). The `x-bronto-dataset`, `x-bronto-collection`, and `x-bronto-tags` headers therefore control log routing only.
### Datasets
A **Dataset** (named `log` in the current API) is the fundamental unit of storage. It acts as a container for log events that share a similar format and origin, such as:
* `application-logs`
* `nginx-access`
Key characteristics:
* All events within the same dataset are always queried together.
* The dataset **must be specified at ingestion time** by configuring the agent or integration.
* The dataset and its collection are created automatically when the first log event arrives; you do not need to create them beforehand.
* Dataset names must be **unique within a collection**.
To learn how to configure datasets during ingestion, see the [agent setup documentation](https://docs.bronto.io/agent-setup/agent-intro).
> **Note**\
> Bronto supports up to **5,000 unique datasets per organization**.
***
### Collections
A **Collection** (named `logset` in the current API) is a logical grouping of datasets.
Think of a collection as a folder that helps you organize related datasets and distinguish between datasets that may share the same name but come from different environments.
Key points:
* Collections improve discoverability and organization.
* The collection can be specified using the `x-bronto-collection` HTTP header (or equivalent).
* Collection configuration is described in the [agent setup documentation](https://docs.bronto.io/agent-setup/agent-intro).
***
## Tags
**Tags** are key-value pairs assigned to datasets to categorize them across your system, for example:
* `team:backend`
* `env:production`
* `type:gc`
* `service:catalog`
Tags make it easier to:
* Select datasets in the UI
* Query multiple datasets together
* Build precise dashboards and monitors at scale
Proper tagging is essential when managing thousands of datasets.
## Assigning Tags
You can assign tags to datasets in three ways:
* **Via UI**: apply or remove tags from the Logs screen
* **Via API**: create tags and assign them programmatically
* **At ingestion**: automatically attach tags to ingested data via the `x-bronto-tags` HTTP header (agent-level)
### Assign tags via the UI (Logs screen)
Use the UI when you want to quickly apply tags to a dataset.
1. In the left navigation, open **Logs**.
2. Click **Select Data** dropdown.
3. Expand the relevant **Collection**.
4. Hover over the **Dataset** you want to tag.
5. Click the settings icon.
6. Select **Manage Tags**.
7. Fill out Tag Name and Value.
8. Click **Add / Apply** to confirm.
### Assign tags via the API
Create a tag (and then assign/use it in your workflows) using the Tags API:
* [https://docs.bronto.io/api-reference/tags/create-a-tag](https://docs.bronto.io/api-reference/tags/create-a-tag)
### Assign tags at ingestion (agent-level)
Use ingestion tagging when you want tags applied automatically as data enters Bronto.
Tags must be specified at the **agent level** using the `x-bronto-tags` HTTP header (or your agent’s equivalent configuration). For example:
* Set `x-bronto-tags` to a comma-separated list of tags (example format may vary by agent).
* The agent attaches those tags to any data it ingests.
For step-by-step setup instructions (agent-specific), see:
* [https://docs.bronto.io/agent-setup/agent-intro](https://docs.bronto.io/agent-setup/agent-intro)
**Note:** Each dataset can have up to **10 tags**.
Tags can be used simply as labels to add metadata and context, or as part of a more advanced data organization strategy using **partition tags**.
***
## Partition Tags
**Partition Tags** are a special subset of tags defined at the **organization level**. They allow Bronto to automatically organize your data in a consistent and scalable way.
Partition tags are especially useful for:
* Large environments
* Structured infrastructures
* Reducing agent configuration complexity
* Enforcing consistent collection and dataset placement
### How Partition Tags Work
* Bronto uses partition tags to determine how incoming data is grouped into collections and datasets.
* If a collection header is explicitly set, it **takes precedence** and overrides partition tag logic.
* To fully leverage partition tags, omit the collection header during ingestion.
### Setup Flow: UI + Ingestion Headers
1. In **Settings -> Partition Tags**, enable partition tags and define the hierarchy order (broadest to most specific).
2. Update your ingestion agent config so `x-bronto-tags` includes the same tag keys you configured as partition tags.
```bash theme={"dark"}
x-bronto-tags: environment=production,region=us-east-1,service=api-gateway
```
Defining partition tags in the UI is not enough by itself. Bronto can only apply the partition hierarchy when those keys are present at ingestion time via the `x-bronto-tags` header.
If partition tag keys are missing in incoming logs, data will not be grouped into the expected partition hierarchy and can appear under unexpected dataset groupings.
3. Open **Logs** and verify the partition tags appear in the dataset selector.
***
## Choosing Your Partition Tags
Partition tags define your data hierarchy, so they should be chosen carefully—ideally during the initial account configuration.
### Characteristics of Good Partition Tags
Partition tags should:
* Be **low-cardinality**
* Represent attributes that are **intrinsically tied to the data source**
* Remain **stable over time**
**Good examples:**
* `environment`
* `region`
* `datacenter`
* `account`
* `cluster`
* `service`
* `product`
**Bad examples:**
* `team`\
Teams and responsibilities change frequently. Team ownership is valuable metadata, but not suitable for defining data hierarchy.
* High-cardinality or volatile attributes such as:
* `hostname`
* `instance_id`
* `pod_id`
* `ip_address`
These attributes change often and can lead to excessive dataset creation. They also do not make sense as dataset tags and should instead be included at the **log event level**.
> **Warning**\
> While partition tags can be modified at any time, changing them on live data is a **sensitive operation**. Updates may cause new datasets to be created for existing streams, potentially breaking dashboards, monitors, and saved queries.
***
## Example: Designing Partition Tags
### Context
Your infrastructure includes:
* **Environments**: `staging`, `production`
* **Regions**: `eu`, `us`
* **Services**: `catalog`, `checkout`, `payment`, `cart`
* **Teams**: `team-a`, `team-b`
Each service produces multiple log streams, such as:
* Syslog
* Application logs
* Garbage collection logs
### Recommended Partition Tags
* environment
* region
* service
Why this works:
* These descriptors are stable and directly tied to where and what generates logs.
* They clearly identify the source of the data.
* They scale well as your infrastructure grows.
In this setup:
* The **dataset name** should represent the log stream (e.g., `application`, `gc`, `syslog`).
* Collections and datasets are automatically and consistently organized.
### Why Not Use `team` as a Partition Tag?
Team ownership changes over time. If a service moves from `team-a` to `team-b`:
* The partition tag combination changes
* New datasets are created for the same service
* Old datasets stop receiving data
* Existing dashboards, monitors, and queries may break or return incomplete results
**Best practice:**\
Use `team` as a **regular tag**, not a partition tag. This allows you to update ownership metadata without disrupting your data organization or historical visibility.
# Saved Searches
Source: https://docs.bronto.io/Search-and-Visualize/Saved-Searches
Save search queries, filters, and column layouts as Saved Searches in Bronto so your team can quickly switch between troubleshooting contexts.
## Overview
The Saved Searches panel groups your searches into **Favourites**, **Created by Me** and **Created by Others**, so you can separate your own work from searches shared across your account. A **By Tag** group also appears once any of your saved searches are tagged.
A saved search stores the selected data, the search query, any visualisation you had selected, and your column selection and ordering.
**From the Saved Searches panel you can:**
* Load or reload a saved search.
* Edit, add to favourites, or delete a saved search from its `...` menu.
**How to create a Saved Search:**
* Run a search using the conditions you want to save or share.
* Click **Save Current Search** at the top of the panel. A new panel will appear where you can enter a name for your saved search.
* Enter a name and click Save to confirm.
Column selection and ordering have been stored with saved searches since July 2025. Searches created before then have no stored column layout, so Bronto derives a sensible default from the log type when you load them.
# Agent Setup
Source: https://docs.bronto.io/agent-setup/agent-intro
Configure a telemetry agent to collect and forward log data to Bronto. Supports OpenTelemetry, Fluent Bit, Fluentd, Logstash, Datadog Agent, and Vector.
Bronto supports multiple telemetry agents for log collection and forwarding. Choose the agent that fits your existing infrastructure — each guide covers configuration and verification, and links out to the agent's own installation documentation.
### Generate an API Key
Before configuring your chosen agent, create an [API Key](/Account-Management/API-Keys). Store it securely — Bronto does not display the full key again after generation.
You must have admin privileges to create API keys.
## Supported Agents
| Agent | Description |
| - | - |
| [OpenTelemetry](/agent-setup/open-telemetry) | Vendor-neutral observability framework for collecting logs, metrics, and traces |
| [Odigos](/agent-setup/odigos) | Kubernetes-native platform that auto-instruments workloads with eBPF and forwards their traces, metrics, and logs |
| [Fluent Bit](/agent-setup/fluent-bit) | Lightweight, high-performance log processor and forwarder |
| [Fluentd](/agent-setup/fluentd) | Open-source data collector for unified logging |
| [Logstash](/agent-setup/logstash) | Data processing pipeline from the Elastic stack |
| [Datadog Agent](/agent-setup/datadog-agent) | Forward logs via the Datadog Agent to Bronto |
| [Vector](/agent-setup/vector) | High-performance observability data pipeline |
## Choose Agent
# Configure Datadog Agent
Source: https://docs.bronto.io/agent-setup/datadog-agent
Forward logs to Bronto using the Datadog Agent, ideal for migrating existing Datadog-based pipelines without changing your application instrumentation.
The Datadog Agent can forward logs to Bronto in addition to Datadog using the `additional_endpoints` configuration. This page covers configuration only.
For installation instructions, see the [Datadog Agent documentation](https://docs.datadoghq.com/agent/).
## Endpoint and authentication
Use the ingestion endpoint for your Bronto region:
| Region | Host |
| - | - |
| EU | `ingestion.eu.bronto.io` |
| US | `ingestion.us.bronto.io` |
Set `api_key` to your [Bronto API key](/Account-Management/API-Keys#create-a-new-api-key).
## Configuration
Edit `~/.datadog-agent/datadog.yaml` to add Bronto as an additional log endpoint:
```yaml datadog.yaml theme={"dark"}
logs_config:
additional_endpoints:
- api_key: ""
host: "ingestion..bronto.io"
port: 443
is_reliable: true
```
By default, the dataset and collection where logs are sent are derived from the `service` and `source` tags reported by the Datadog Agent. These can be overridden with the `br_dataset` and `br_collection` log attributes if required.
Add Bronto as an additional endpoint by upgrading the Datadog Agent Helm chart:
```bash theme={"dark"}
helm upgrade datadog-agent -f datadog-values.yaml datadog/datadog
```
```yaml datadog-values.yaml theme={"dark"}
datadog:
podAnnotationsAsTags:
kubernetes.annotations.logs.bronto.io/collection: br_collection
logs:
enabled: true
customAgentConfig:
logs_config:
additional_endpoints:
- api_key: ""
host: "ingestion..bronto.io"
port: 443
is_reliable: true
```
Add the `kubernetes.annotations.logs.bronto.io/collection` annotation to pods whose logs should be forwarded to Bronto. Set its value to a unique identifier for the cluster, e.g. `--`. The `podAnnotationsAsTags` entry maps this annotation to the `br_collection` log attribute, which Bronto uses to determine which collection to save the log data under.
For the full `additional_endpoints` configuration reference, see the [Datadog Agent log forwarding documentation](https://docs.datadoghq.com/agent/logs/?tab=tailfiles#send-logs-to-a-custom-endpoint).
## Verify Log Collection
Once you have applied your configuration and restarted the Datadog Agent, you can expect to see your log data being ingested to Bronto and accessible via the [Search](https://app.bronto.io/search) page.
# Connect Fluent Bit to Bronto
Source: https://docs.bronto.io/agent-setup/fluent-bit
Configure the Fluent Bit log processor to collect application and system logs, batch them, and forward to Bronto over HTTP for search and analysis.
Fluent Bit forwards logs to Bronto using its built-in HTTP output plugin. This page covers Fluent Bit configuration only.
For installation instructions, see the [Fluent Bit installation guide](https://docs.fluentbit.io/manual/installation/getting-started-with-fluent-bit). For the full Fluent Bit configuration reference, see the [Fluent Bit documentation](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit).
## Endpoint and authentication
Use the ingestion endpoint for your Bronto region:
| Region | Host |
| - | - |
| EU | `ingestion.eu.bronto.io` |
| US | `ingestion.us.bronto.io` |
Every request requires these headers:
| Header | Required | Description |
| - | - | - |
| `x-bronto-api-key` | Required | Your [Bronto API key](/Account-Management/API-Keys#create-a-new-api-key). |
| `x-bronto-dataset` | Required | The dataset to route logs to. |
| `x-bronto-collection` | Required | The collection to group datasets under. |
| `x-bronto-tags` | Optional | Key-value tag pairs (e.g. `env=prod,team=platform`). See [Partitions](/Search-and-Visualize/Partitions). |
## Minimal configuration
Tail a single log file and forward to Bronto.
```ini fluent-bit.conf theme={"dark"}
[SERVICE]
flush 1
daemon off
log_level info
[INPUT]
name tail
path /path/to/your/logs
tag app.logs
refresh_interval 5
mem_buf_limit 5MB
skip_long_lines on
[OUTPUT]
name http
tls on
match *
host ingestion..bronto.io
port 443
format json_lines
compress gzip
header x-bronto-api-key
header x-bronto-dataset
header x-bronto-collection
```
For the full HTTP output configuration reference, see the [Fluent Bit HTTP output documentation](https://docs.fluentbit.io/manual/pipeline/outputs/http).
## Parsing unstructured logs
Rather than building Fluent Bit parsers for unstructured text, ship raw log lines to Bronto and use the [Bronto Custom Parser](/core-features/custom-parser) to extract structured fields server-side. The Custom Parser uses LLMs to generate parsers automatically and ships with built-in support for Apache, IIS, HAProxy, Syslog, key-value, and custom formats — no regex maintenance required.
## Common patterns
The patterns below cover configuration concerns most Bronto customers run into.
### Adding metadata to every log
Use the `record_modifier` filter to inject metadata — e.g. a deployment identifier, branch name, or region — from environment variables. Export the variable from your CI/CD pipeline or container runtime, then reference it in your Fluent Bit config.
```bash theme={"dark"}
export APP_GIT_BRANCH="feature-branch-name"
```
```ini fluent-bit.conf theme={"dark"}
[FILTER]
name record_modifier
match *
record branch ${APP_GIT_BRANCH}
```
### Multi-line logs (stack traces)
Multi-line application output — like Java, Python, or Ruby stack traces — must be reassembled at the input stage so each stack trace ships as a single log record. Use the `multiline.parser` directive on `[INPUT]`. Fluent Bit ships with parsers for `java`, `python`, `ruby`, `go`, `dotnet`, and others.
```ini fluent-bit.conf theme={"dark"}
[INPUT]
name tail
path /var/log/app.log
tag app.logs
multiline.parser python
```
`multiline.parser` at the `[INPUT]` level requires Fluent Bit 1.8 or later.
### Routing multiple log sources to separate datasets
A single Fluent Bit instance can ship logs from multiple applications to different Bronto datasets. Tag each `[INPUT]` distinctly, then use `Match` on each `[OUTPUT]`.
```ini fluent-bit.conf theme={"dark"}
[INPUT]
name tail
path /var/log/api.log
tag api.logs
[INPUT]
name tail
path /var/log/worker.log
tag worker.logs
[OUTPUT]
name http
tls on
match api.logs
host ingestion..bronto.io
port 443
format json_lines
compress gzip
header x-bronto-api-key
header x-bronto-dataset api-service
header x-bronto-collection
[OUTPUT]
name http
tls on
match worker.logs
host ingestion..bronto.io
port 443
format json_lines
compress gzip
header x-bronto-api-key
header x-bronto-dataset worker-service
header x-bronto-collection
```
The `Match` field is the routing mechanism — a filter or output with `Match api.logs` will never apply to `worker.logs`, and vice versa. A filter with `Match *` applies to every stream.
### Kubernetes
For Kubernetes deployments, install Fluent Bit as a DaemonSet via the [official Helm chart](https://github.com/fluent/helm-charts) and use the `x-bronto-collection` header to identify the cluster. Dataset names are inferred from Kubernetes metadata.
```ini fluent-bit.conf theme={"dark"}
[INPUT]
name tail
path /var/log/containers/*.log
multiline.parser docker, cri
tag kube.*
mem_buf_limit 5MB
skip_long_lines on
[FILTER]
name kubernetes
match kube.*
k8s-logging.parser on
k8s-logging.exclude on
[OUTPUT]
name http
tls on
match kube.*
host ingestion..bronto.io
port 443
format json_lines
compress gzip
header x-bronto-api-key
header x-bronto-collection --
```
## Verify log collection
Once you have applied your configuration and restarted Fluent Bit, you can expect to see your log data being ingested to Bronto and accessible via the [Search](https://app.bronto.io/search) page.
## Further reading
* [Fluent Bit installation](https://docs.fluentbit.io/manual/installation/getting-started-with-fluent-bit)
* [Fluent Bit configuration reference](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit)
* [Multiline parsing](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/multiline-parsing)
* [Fluent Bit Helm chart](https://github.com/fluent/helm-charts) — for Kubernetes
* [Bronto Custom Parser](/core-features/custom-parser) — extract structured fields from unstructured logs
# Connect Fluentd to Bronto
Source: https://docs.bronto.io/agent-setup/fluentd
Configure the Fluentd open-source data collector to tail application log files and forward structured events to Bronto over HTTP with batching and retries.
Fluentd forwards logs to Bronto using its built-in `http` output plugin. This page covers Fluentd configuration only.
For installation instructions, see the [Fluentd installation guide](https://docs.fluentd.org/installation). For the full Fluentd configuration reference, see the [Fluentd documentation](https://docs.fluentd.org/configuration).
## Endpoint and authentication
Use the ingestion endpoint for your Bronto region:
| Region | Endpoint |
| - | - |
| EU | `https://ingestion.eu.bronto.io:443` |
| US | `https://ingestion.us.bronto.io:443` |
Every request requires these headers:
| Header | Required | Description |
| - | - | - |
| `x-bronto-api-key` | Required | Your [Bronto API key](/Account-Management/API-Keys#create-a-new-api-key). |
| `x-bronto-dataset` | Required | The dataset to route logs to. |
| `x-bronto-collection` | Required | The collection to group datasets under. |
| `x-bronto-tags` | Optional | Key-value tag pairs (e.g. `env=prod,team=platform`). See [Partitions](/Search-and-Visualize/Partitions). |
## Minimal configuration
Tail a JSON log file and forward to Bronto.
```xml /etc/fluent/fluentd.conf theme={"dark"}
@type tail
path /path/to/your/logs
tag app.logs
refresh_interval 5s
@type json
pos_file /var/log/td-agent/buffer/fluentd.pos
@type http
endpoint https://ingestion..bronto.io:443
http_method post
@type file
path /var/log/td-agent/buffer/http
flush_interval 10s
chunk_limit_size 5MB
overflow_action block
@type json
headers {"x-bronto-api-key": "", "x-bronto-dataset": "", "x-bronto-collection": ""}
```
For the full HTTP output configuration reference, see the [Fluentd HTTP output documentation](https://docs.fluentd.org/output/http).
## Parsing unstructured logs
Rather than building Fluentd parsers for unstructured text, ship raw log lines to Bronto and use the [Bronto Custom Parser](/core-features/custom-parser) to extract structured fields server-side. The Custom Parser uses LLMs to generate parsers automatically and ships with built-in support for Apache, IIS, HAProxy, Syslog, key-value, and custom formats — no regex maintenance required.
## Common patterns
### Adding metadata to every log
Use the `record_transformer` filter to inject metadata into every record. Values can be expressions (Ruby) or environment variables.
```xml theme={"dark"}
@type record_transformer
hostname "#{Socket.gethostname}"
branch "#{ENV['APP_GIT_BRANCH']}"
```
### Routing multiple log sources to separate datasets
Tag each `` distinctly, then use a separate `` block for each tag with the appropriate `x-bronto-dataset` header.
```xml theme={"dark"}
@type tail
path /var/log/api.log
tag api.logs
@type json
pos_file /var/log/td-agent/buffer/api.pos
@type tail
path /var/log/worker.log
tag worker.logs
@type json
pos_file /var/log/td-agent/buffer/worker.pos
@type http
endpoint https://ingestion..bronto.io:443
http_method post
@type json
headers {"x-bronto-api-key": "", "x-bronto-dataset": "api-service", "x-bronto-collection": ""}
@type http
endpoint https://ingestion..bronto.io:443
http_method post
@type json
headers {"x-bronto-api-key": "", "x-bronto-dataset": "worker-service", "x-bronto-collection": ""}
```
## Verify log collection
Once you have applied your configuration and restarted Fluentd, you can expect to see your log data being ingested to Bronto and accessible via the [Search](https://app.bronto.io/search) page.
## Further reading
* [Fluentd installation](https://docs.fluentd.org/installation)
* [Fluentd configuration reference](https://docs.fluentd.org/configuration)
* [`http` output plugin](https://docs.fluentd.org/output/http)
* [Buffering](https://docs.fluentd.org/configuration/buffer-section)
* [Bronto Custom Parser](/core-features/custom-parser) — extract structured fields from unstructured logs
# Connect Logstash to Bronto
Source: https://docs.bronto.io/agent-setup/logstash
Configure the Logstash data processing pipeline with an HTTP output to enrich, transform, and forward log events from your applications to Bronto.
Logstash forwards logs to Bronto using its built-in `http` output plugin. This page covers Logstash configuration only.
For installation instructions, see the [Logstash installation guide](https://www.elastic.co/guide/en/logstash/current/installing-logstash.html). For the full Logstash configuration reference, see the [Logstash documentation](https://www.elastic.co/guide/en/logstash/current/configuration.html).
## Endpoint and authentication
Use the ingestion endpoint for your Bronto region:
| Region | Endpoint |
| - | - |
| EU | `https://ingestion.eu.bronto.io` |
| US | `https://ingestion.us.bronto.io` |
Every request requires these headers:
| Header | Required | Description |
| - | - | - |
| `x-bronto-api-key` | Required | Your [Bronto API key](/Account-Management/API-Keys#create-a-new-api-key). |
| `x-bronto-dataset` | Required | The dataset to route logs to. |
| `x-bronto-collection` | Required | The collection to group datasets under. |
| `x-bronto-tags` | Optional | Key-value tag pairs (e.g. `env=prod,team=platform`). See [Partitions](/Search-and-Visualize/Partitions). |
## Minimal configuration
Tail a log file and forward to Bronto.
```ruby /etc/logstash/conf.d/bronto.conf theme={"dark"}
input {
file {
id => "app_input"
path => "/path/to/your/logs"
}
}
output {
http {
id => "bronto_output"
url => "https://ingestion..bronto.io"
http_method => "post"
format => "json"
headers => {
"x-bronto-api-key" => ""
"x-bronto-dataset" => ""
"x-bronto-collection" => ""
}
}
}
```
For the full HTTP output configuration reference, see the [Logstash HTTP output documentation](https://www.elastic.co/guide/en/logstash/current/plugins-outputs-http.html).
## Parsing unstructured logs
Rather than building grok patterns inside Logstash, ship raw log lines to Bronto and use the [Bronto Custom Parser](/core-features/custom-parser) to extract structured fields server-side. The Custom Parser uses LLMs to generate parsers automatically and ships with built-in support for Apache, IIS, HAProxy, Syslog, key-value, and custom formats — no regex maintenance required.
## Common patterns
The patterns below cover configuration concerns most Bronto customers run into.
### Adding metadata to every log
Use the `mutate` filter to inject metadata — e.g. a deployment identifier, branch name, or region — into every event. Values can be referenced from environment variables via `${VAR}`.
```ruby theme={"dark"}
filter {
mutate {
add_field => {
"branch" => "${APP_GIT_BRANCH}"
"environment" => "${APP_ENV}"
}
}
}
```
### Multi-line logs (stack traces)
Multi-line application output — like Java, Python, or Ruby stack traces — must be reassembled at the input stage so each stack trace ships as a single log record. Use the `multiline` codec on the input.
```ruby theme={"dark"}
input {
file {
id => "app_input"
path => "/var/log/app.log"
codec => multiline {
pattern => "^\s"
what => "previous"
}
}
}
```
The pattern above appends any line beginning with whitespace to the previous line — a common heuristic for stack traces. Adjust the pattern for your log format. See the [multiline codec documentation](https://www.elastic.co/guide/en/logstash/current/plugins-codecs-multiline.html) for details.
### Routing multiple log sources to separate datasets
A single Logstash instance can ship logs from multiple applications to different Bronto datasets. Tag each input distinctly, then use a conditional on each output.
```ruby /etc/logstash/conf.d/bronto.conf theme={"dark"}
input {
file {
id => "api_input"
path => "/var/log/api.log"
tags => ["api"]
}
file {
id => "worker_input"
path => "/var/log/worker.log"
tags => ["worker"]
}
}
output {
if "api" in [tags] {
http {
id => "bronto_api"
url => "https://ingestion..bronto.io"
http_method => "post"
format => "json"
headers => {
"x-bronto-api-key" => ""
"x-bronto-dataset" => "api-service"
"x-bronto-collection" => ""
}
}
}
if "worker" in [tags] {
http {
id => "bronto_worker"
url => "https://ingestion..bronto.io"
http_method => "post"
format => "json"
headers => {
"x-bronto-api-key" => ""
"x-bronto-dataset" => "worker-service"
"x-bronto-collection" => ""
}
}
}
}
```
## Verify log collection
Once you have applied your configuration and restarted Logstash, you can expect to see your log data being ingested to Bronto and accessible via the [Search](https://app.bronto.io/search) page.
## Further reading
* [Logstash installation](https://www.elastic.co/guide/en/logstash/current/installing-logstash.html)
* [Logstash configuration reference](https://www.elastic.co/guide/en/logstash/current/configuration.html)
* [`http` output plugin](https://www.elastic.co/guide/en/logstash/current/plugins-outputs-http.html)
* [`multiline` codec](https://www.elastic.co/guide/en/logstash/current/plugins-codecs-multiline.html)
* [Bronto Custom Parser](/core-features/custom-parser) — extract structured fields from unstructured logs
# Connect Odigos to Bronto
Source: https://docs.bronto.io/agent-setup/odigos
Configure Odigos to auto-instrument Kubernetes workloads with eBPF and forward their traces, metrics, and logs to Bronto over OTLP.
Odigos auto-instruments Kubernetes workloads with eBPF and forwards their traces, metrics, and logs to Bronto via OTLP/HTTP. Unlike the other agents on this page, it also **generates** the telemetry: your applications need no SDK, no code changes, and no rebuilt images. This page covers Odigos destination configuration only.
For installation instructions, see the [Odigos installation guide](https://docs.odigos.io/setup/installation).
## Endpoint and authentication
Use the endpoints for your Bronto region:
| Region | Logs endpoint | Metrics endpoint | Traces endpoint |
| - | - | - | - |
| EU | `https://ingestion.eu.bronto.io/v1/logs` | `https://ingestion.eu.bronto.io/v1/metrics` | `https://ingestion.eu.bronto.io/v1/traces` |
| US | `https://ingestion.us.bronto.io/v1/logs` | `https://ingestion.us.bronto.io/v1/metrics` | `https://ingestion.us.bronto.io/v1/traces` |
Bronto authenticates with a header rather than basic auth or a bearer token, so the API key goes in the destination's `OTLP_HTTP_HEADERS` field:
| Header | Required | Scope | Description |
| - | - | - | - |
| `x-bronto-api-key` | Required | All signals | Your [Bronto API key](/Account-Management/API-Keys#create-a-new-api-key). |
| `x-bronto-dataset` | Optional | Logs only | Overrides `service.name` as the log dataset. |
| `x-bronto-collection` | Optional | Logs only | Overrides `service.namespace` as the log collection. |
## Minimal configuration
Create a `Destination` resource in the `odigos-system` namespace. `OTLP_HTTP_HEADERS` takes a JSON array of `{"key": ..., "value": ...}` objects.
```yaml bronto-destination.yaml theme={"dark"}
apiVersion: odigos.io/v1alpha1
kind: Destination
metadata:
name: bronto
namespace: odigos-system
spec:
type: otlphttp
destinationName: bronto
signals:
- TRACES
- METRICS
- LOGS
data:
OTLP_HTTP_ENDPOINT: "https://ingestion..bronto.io"
OTLP_HTTP_TRACES_ENDPOINT: "https://ingestion..bronto.io/v1/traces"
OTLP_HTTP_METRICS_ENDPOINT: "https://ingestion..bronto.io/v1/metrics"
OTLP_HTTP_LOGS_ENDPOINT: "https://ingestion..bronto.io/v1/logs"
OTLP_HTTP_COMPRESSION: "gzip"
OTLP_HTTP_TLS_ENABLED: "true"
OTLP_HTTP_HEADERS: '[{"key":"x-bronto-api-key","value":""}]'
```
```bash theme={"dark"}
kubectl apply -f bronto-destination.yaml
```
The same destination can be added through the Odigos UI (`odigos ui`) by selecting **OTLP http** and entering the endpoints and header.
Odigos does not treat custom headers as secret, so the API key is stored in plain text in the `Destination` resource rather than in a Kubernetes `Secret`. Restrict RBAC on the `odigos-system` namespace, and avoid committing the manifest to source control.
## Send only the signals you need
`spec.signals` controls which pipelines Odigos builds. Remove any of `TRACES`, `METRICS`, or `LOGS` to stop sending that signal; the corresponding endpoint field can be removed with it.
Bronto supports sums, gauges, summaries, and explicit histograms. Sum and histogram metrics can be ingested as delta or cumulative, but delta is strongly recommended to get the best value from the current set of supported functions. Exponential histograms are not supported. For Sum, Summary, and Histogram metrics, the Metric Explorer provides [per-second rate functions](/metrics/explore-metrics#aggregation-functions).
## Instrumenting workloads
Odigos only instruments workloads you mark as sources:
```bash theme={"dark"}
odigos sources create -src \
--workload-kind=Deployment \
--workload-name= \
--workload-namespace= \
-n
```
Odigos rolls the affected pods once to attach instrumentation. Confirm agents are attached with `kubectl -n get instrumentationinstances`.
Odigos derives `service.name` from the workload name and attaches it to every signal. For logs, this becomes the Bronto dataset name. Traces and metrics are not stored in datasets or collections; use `service.name` and the Kubernetes attributes as filters in [Explore Traces](/tracing/explore-traces) and the [Metric Explorer](/metrics/explore-metrics). Every span is enriched with `k8s.deployment.name`, `k8s.namespace.name`, `k8s.pod.name`, `k8s.node.name`, and `k8s.container.name`, so you can scope traces to a workload, namespace, or node.
## Verify delivery
Once the destination is applied and your sources are instrumented:
* Traces appear in [Explore Traces](/tracing/explore-traces).
* Metrics appear in the Metric Explorer.
* Logs appear in [Search](https://app.bronto.io/search).
To confirm the exporter was generated, inspect the gateway collector's configuration:
```bash theme={"dark"}
kubectl -n odigos-system get cm odigos-gateway \
-o jsonpath='{.data.collector-conf}' | grep -A6 bronto
```
Export failures are logged by the gateway. A `401` means the API key or the region is wrong — a region mismatch returns the same status as an invalid key.
```bash theme={"dark"}
kubectl -n odigos-system logs -l odigos.io/collector-role=CLUSTER_GATEWAY --tail=200 | grep -i "error\|failed"
```
## Further reading
* [Odigos documentation](https://docs.odigos.io) — sources, actions, and destination reference
* [Zero-code instrumentation with eBPF](/opentelemetry/ebpf) — instrument without adopting a platform
* [Connect OpenTelemetry Collector to Bronto](/agent-setup/open-telemetry) — if you already run your own Collector
* [Send Traces to Bronto](/tracing/send-traces) — including direct SDK export
* [Send Metrics to Bronto](/metrics/send-metrics) — supported metric types and limitations
# Connect OpenTelemetry Collector to Bronto
Source: https://docs.bronto.io/agent-setup/open-telemetry
Deploy the OpenTelemetry Collector with OTLP exporters to receive, process, and forward logs, metrics, and traces to Bronto, including on Kubernetes.
The OpenTelemetry Collector forwards logs, metrics, and traces to Bronto via OTLP/HTTP. This page covers Collector configuration only.
For installation instructions, see the [OpenTelemetry Collector documentation](https://opentelemetry.io/docs/collector/installation/). For SDK-based instrumentation, see Bronto's [language-specific OpenTelemetry guides](/opentelemetry/overview).
## Getting your data into the Collector
The Collector only forwards the telemetry it **receives** — deploying it does not automatically discover your logs. If you've configured the Collector but aren't seeing all the logs you expect, the source usually hasn't been wired up to send data to it yet. There are two categories of source:
* **Application logs, metrics, and traces** — instrument your application with the OpenTelemetry SDK so it exports OTLP to the Collector (or directly to Bronto). See [Ingest OpenTelemetry data](/opentelemetry/overview) for per-language setup. Alternatively, point the `filelog` receiver at the log files your application already writes.
* **Infrastructure and service logs** — each source has its own setup. See [Ingesting Infrastructure and Database Logs](/integrations/infrastructure-overview) for the full list (Kubernetes, Docker, NGINX, databases, message brokers, and more), and [Collecting Windows OS Logs and Metrics](/integrations/azure-windows-logs) for Windows Event Log, IIS, and Windows performance-counter metrics.
The receiver examples on this page show the Collector-side plumbing; the source guides above show what each source emits and where it writes its logs.
## Endpoints
Use the endpoints for your Bronto region:
| Region | Logs endpoint | Metrics endpoint | Traces endpoint |
| - | - | - | - |
| EU | `https://ingestion.eu.bronto.io/v1/logs` | `https://ingestion.eu.bronto.io/v1/metrics` | `https://ingestion.eu.bronto.io/v1/traces` |
| US | `https://ingestion.us.bronto.io/v1/logs` | `https://ingestion.us.bronto.io/v1/metrics` | `https://ingestion.us.bronto.io/v1/traces` |
The OTel Collector uses `service.name` and `service.namespace` as shared resource identity across all three signals. For logs, Bronto also uses them to select the dataset and collection. Only the API key header is required; the rest are optional log-routing overrides:
Datasets and collections apply only to logs. Metrics appear in the [Metric Explorer](/metrics/explore-metrics), and traces appear in [Explore Traces](/tracing/explore-traces). Neither signal creates a dataset or collection, and the log-routing headers below do not organize them.
| Header | Required | Scope | Description |
| - | - | - | - |
| `x-bronto-api-key` | Required | All signals | Your [Bronto API key](/Account-Management/API-Keys#create-a-new-api-key). |
| `x-bronto-dataset` | Optional | Logs only | Overrides `service.name` as the log dataset. |
| `x-bronto-collection` | Optional | Logs only | Overrides `service.namespace` as the log collection. |
| `x-bronto-tags` | Optional | Logs only | Key-value dataset tags (e.g. `env=prod,team=platform`). See [Partitions](/Search-and-Visualize/Partitions). |
## Logs, metrics, and traces
Run all three pipelines through a single Collector. Tail log files via the `filelog` receiver, accept OTLP metrics and traces from your applications via the `otlp` receiver, and ship each signal to its Bronto endpoint.
The example uses the standard OTLP receiver ports: `4317` for gRPC and `4318` for HTTP. Applications on the same host commonly use `localhost`; containers, Kubernetes workloads, remote Collectors, and TLS-enabled deployments require an address and scheme appropriate to that environment. Keep the SDK exporter and Collector receiver settings aligned.
```yaml /etc/otel/config.yaml theme={"dark"}
receivers:
filelog/app:
include:
- /path/to/your/logs
resource:
service.name:
service.namespace:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
cumulativetodelta:
initial_value: drop
exporters:
otlphttp/brontologs:
logs_endpoint: "https://ingestion..bronto.io/v1/logs"
compression: gzip
headers:
x-bronto-api-key:
otlphttp/brontometrics:
metrics_endpoint: "https://ingestion..bronto.io/v1/metrics"
compression: gzip
headers:
x-bronto-api-key:
otlphttp/brontotraces:
traces_endpoint: "https://ingestion..bronto.io/v1/traces"
compression: gzip
headers:
x-bronto-api-key:
service:
pipelines:
logs:
receivers: [filelog/app]
processors: [batch]
exporters: [otlphttp/brontologs]
metrics:
receivers: [otlp]
processors: [cumulativetodelta, batch]
exporters: [otlphttp/brontometrics]
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/brontotraces]
```
The `service.name` and `service.namespace` resource attributes are shared across all three signals. Bronto uses them to route **logs** to the correct dataset and collection; the log exporter can override them with the `x-bronto-dataset` and `x-bronto-collection` headers. For metrics and traces, the attributes remain source identity and filters, without creating datasets or collections.
Bronto supports sums, gauges, summaries, and explicit histograms. Sum and histogram metrics can be ingested as delta or cumulative, but delta is strongly recommended to get the best value from the current set of supported functions. Exponential histograms are not supported. For Sum, Summary, and Histogram metrics, the Metric Explorer provides [per-second rate functions](/metrics/explore-metrics#aggregation-functions).
For signal-specific details, see [Send Metrics to Bronto](/metrics/send-metrics) and [Send Traces to Bronto](/tracing/send-traces).
## Send only the signals you need
Collector pipelines are independent. To send only one signal or a subset, remove the unused signal pipelines and exporters. You do not need a separate Collector.
## Windows hosts
On Windows, the `filelog` receiver picks up file-based logs (IIS, SQL Server, application files), but most platform and service diagnostics are written to the **Windows Event Log** and need the Windows-only `windowseventlog` receiver instead. See [Collecting Windows OS Logs and Metrics](/integrations/azure-windows-logs) for the receiver configuration, the event channels worth collecting, XPath filtering for noisy channels, Windows `filelog` gotchas (UTF-16 encoding, multi-line stack traces), and running the Collector as a Windows service.
## Parsing unstructured logs
Rather than building parser operators in the Collector for unstructured text, ship raw log lines to Bronto and use the [Bronto Custom Parser](/core-features/custom-parser) to extract structured fields server-side. The Custom Parser uses LLMs to generate parsers automatically and ships with built-in support for Apache, IIS, HAProxy, Syslog, key-value, and custom formats — no regex maintenance required.
## Kubernetes
For Kubernetes deployments, install the Collector using the [OpenTelemetry Helm chart](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-collector).
```bash theme={"dark"}
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install otel-collector open-telemetry/opentelemetry-collector \
--values values.yaml
```
Use the `x-bronto-collection` header on the **logs exporter** to identify the cluster (e.g. `cluster1-prod-us-east-1`). Bronto infers log dataset names from log resource attributes, so per-service log routing is handled automatically. Metrics and traces retain Kubernetes and service resource attributes for filtering in their respective explorers.
```yaml values.yaml theme={"dark"}
mode: daemonset
config:
receivers:
filelog:
include:
- /var/log/pods/*/*/*.log
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
cumulativetodelta:
initial_value: drop
k8sattributes:
exporters:
otlphttp/brontologs:
logs_endpoint: "https://ingestion..bronto.io/v1/logs"
compression: gzip
headers:
x-bronto-api-key:
x-bronto-collection: --
otlphttp/brontometrics:
metrics_endpoint: "https://ingestion..bronto.io/v1/metrics"
compression: gzip
headers:
x-bronto-api-key:
otlphttp/brontotraces:
traces_endpoint: "https://ingestion..bronto.io/v1/traces"
compression: gzip
headers:
x-bronto-api-key:
service:
pipelines:
logs:
receivers: [filelog]
processors: [k8sattributes, batch]
exporters: [otlphttp/brontologs]
metrics:
receivers: [otlp]
processors: [k8sattributes, cumulativetodelta, batch]
exporters: [otlphttp/brontometrics]
traces:
receivers: [otlp]
processors: [k8sattributes, batch]
exporters: [otlphttp/brontotraces]
```
The `k8sattributes` processor enriches logs, metrics, and traces with pod, namespace, and node metadata. See the [OpenTelemetry Demo Kubernetes deployment guide](https://opentelemetry.io/docs/demo/kubernetes-deployment/#bring-your-own-backend) for further context on backend configuration.
## Verify delivery
Once your configuration is applied and the Collector is restarted:
* Logs appear in [Search](https://app.bronto.io/search).
* Metrics appear in the Metric Explorer.
* Traces appear in [Explore Traces](/tracing/explore-traces).
## Further reading
* [OpenTelemetry Collector configuration](https://opentelemetry.io/docs/collector/configuration/) — full receiver/processor/exporter reference
* [OpenTelemetry Helm chart](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-collector) — for Kubernetes
* [Send Traces to Bronto](/tracing/send-traces) — including direct SDK export
* [Send Metrics to Bronto](/metrics/send-metrics) — supported metric types and limitations
* [Bronto OpenTelemetry SDK guides](/opentelemetry/overview) — language-specific instrumentation
* [Bronto Custom Parser](/core-features/custom-parser) — extract structured fields from unstructured logs
# Connect Vector to Bronto
Source: https://docs.bronto.io/agent-setup/vector
Configure the Vector observability data pipeline to collect, transform, and forward host, container, and application logs to Bronto over HTTP.
Vector forwards logs to Bronto using its built-in HTTP sink. This page covers Vector configuration only.
For installation instructions, see the [Vector installation guide](https://vector.dev/docs/setup/installation/).
## Endpoint and authentication
Use the ingestion endpoint for your Bronto region:
| Region | Host |
| - | - |
| EU | `https://ingestion.eu.bronto.io:443` |
| US | `https://ingestion.us.bronto.io:443` |
Every request requires these headers:
| Header | Required | Description |
| - | - | - |
| `x-bronto-api-key` | Required | Your [Bronto API key](/Account-Management/API-Keys#create-a-new-api-key). |
| `x-bronto-dataset` | Required | The dataset to route logs to. |
| `x-bronto-collection` | Required | The collection to group datasets under. |
| `x-bronto-tags` | Optional | Key-value tag pairs (e.g. `env=prod,team=platform`). See [Partitions](/Search-and-Visualize/Partitions). |
## Minimal configuration
Tail a log file and forward to Bronto.
```yaml /etc/vector/vector.yaml theme={"dark"}
sources:
app_logs:
type: file
include:
- /path/to/your/logs
sinks:
bronto:
type: "http"
inputs: ["app_logs"]
uri: "https://ingestion..bronto.io:443/"
compression: "gzip"
encoding:
codec: "json"
framing:
method: "newline_delimited"
method: "post"
request:
headers:
x-bronto-api-key:
x-bronto-dataset:
x-bronto-collection:
```
For the full HTTP sink configuration reference, see the [Vector HTTP sink documentation](https://vector.dev/docs/reference/configuration/sinks/http/).
## Verify Log Collection
Once you have applied your configuration and restarted Vector, you can expect to see your log data being ingested to Bronto and accessible via the [Search](https://app.bronto.io/search) page.
# AI Investigation Reports
Source: https://docs.bronto.io/ai-features/ai-investigation-reports
Run automated AI investigations when a Bronto monitor fires, with prompt-guided analysis and reports covering likely causes, impact, and next steps.
AI Investigation Reports let Bronto run an automated investigation when a monitor fires. Instead of starting from a blank page after an alert, responders receive an AI-generated report shaped by the context you provide in the monitor configuration.
***
## Overview
When enabled on a monitor, Bronto sends the alert context and your **Investigation Prompt** into an AI-driven investigation workflow. The report is delivered as a follow-up to the monitor notification and is designed to help responders move from alert to diagnosis faster.
This feature is best suited to recurring operational issues where the monitor already points to a meaningful failure signal, but responders still need help checking dependencies, related datasets, or likely impact.
***
## How It Works
1. Create or edit a monitor in Bronto
2. Enable **AI Investigation Report**
3. Enter an **Investigation Prompt**
4. Save the monitor and configure notifications as usual
5. When the monitor fires, Bronto runs an investigation automatically
6. Review the report that follows the alert notification
***
## What To Configure
### AI Investigation Report
Toggle **AI Investigation Report** on for the monitor to enable automated analysis when the alert triggers.
### Investigation Prompt
The **Prompt** field tells the AI what to look for while investigating the alert. This prompt gives the model operational context, guidance on related systems, and instructions for what the report should include.
Use the prompt to describe things like:
* Dependencies of the affected service
* Related datasets, logs, traces, or systems to inspect
* Relevant keys, fields, or metrics to compare
* Expected baselines or time windows
* The output you want in the report, such as impact, timeline, or likely cause
Example prompt:
> When investigating this error, check recent deployment logs, verify database connection pool status, and compare current resource usage with baseline metrics from the past 7 days.
***
## What The Report Can Include
Based on the prompt and alert context, the resulting investigation report may include:
* A likely diagnosis or root-cause hypothesis
* Affected services, components, or users
* A timeline of the issue
* Related evidence gathered from your telemetry
* Suggested next steps for responders
The exact contents depend on the quality of the prompt and the telemetry available in Bronto.
***
## Writing Effective Prompts
The strongest prompts are short, specific, and operationally grounded.
Good prompts usually:
* Name the service or workflow involved
* Identify dependencies worth checking
* Point to important datasets or fields
* Ask for concrete outputs such as impact, timeline, or probable cause
Avoid prompts that are too broad or generic. The goal is to guide the investigation, not document every troubleshooting step.
***
## When To Use It
Use AI Investigation Reports when you want alert notifications to include an immediate starting point for triage, especially for:
* Repeating production incidents
* Monitors tied to a critical service or workflow
* On-call handoffs where context is often missing
* Alerts that require checking multiple related systems
For event-level investigation started directly from the log viewer, see [BrontoScope](/ai-features/brontoscope).
***
## Limitations
* Results depend on the data available to Bronto at the time the monitor fires
* Better prompts produce better reports
* AI-generated diagnoses are investigative guidance, not guaranteed root cause
***
## Related Pages
* [Monitoring Overview & Threshold Monitors](/core-features/monitors)
* [BrontoScope](/ai-features/brontoscope)
# AI Overview
Source: https://docs.bronto.io/ai-features/ai-welcome
Connect AI agents and MCP clients to Bronto, run AI-driven investigations, and turn raw telemetry into structured, queryable observability data.
Bronto gives you multiple ways to bring AI into your observability workflows — and to observe the AI your own applications run.
Whether you want to connect an MCP client, run the server locally, investigate production issues with AI, instrument an LLM-powered application, or automatically structure raw telemetry, this section will help you get started.
Connect Claude or another MCP-compatible client directly to Bronto’s hosted endpoint. No local server required.
Install Bronto's Cursor plugin or Claude Code plugin workflows so coding agents understand Bronto MCP and logging tasks.
Run the Bronto MCP server on your own machine with Python and connect it to Claude Code or another compatible agent.
Automatically investigate events and issues with AI and get scope, likely causes, next steps, and supporting evidence in seconds.
Attach AI-generated investigation reports to monitor alerts using a prompt that tells Bronto what to check.
Capture prompts, responses, token usage, and model metadata from your own LLM-powered applications using the OpenTelemetry GenAI semantic conventions, and search them in Bronto.
Use AI to turn unstructured telemetry into structured, queryable events with custom parsers tailored to your data.
Build custom observability interfaces with tools like Lovable and v0 on top of Bronto APIs.
## What you can do
Give agents access to datasets, keys, field values, search, and aggregated analysis workflows through MCP.
Use BrontoScope to automatically assess impact, identify likely causes, and surface recommended next steps.
Add AI Investigation Reports to monitors so alerts arrive with automated analysis and recommended follow-up.
Start quickly with Hosted MCP, or choose Local MCP when you need more control over how the server runs.
Instrument applications that call OpenAI, Anthropic, Amazon Bedrock, or LangChain with the OpenTelemetry GenAI semantic conventions and send that telemetry to Bronto.
Create custom parsers that extract fields from application, system, and custom data formats so your data is easier to search and analyze.
Use Bronto APIs to create workflow-specific dashboards, service maps, and operational views.
## Recommended workflows
### 1. Connect an agent to Bronto
Start with one of the MCP options:
* Choose **Hosted MCP** for the simplest setup
* Choose **Local MCP** if you want to run the server yourself
Managed by Bronto. Best for the fastest path to an MCP connection.
Runs locally with Python. Best when you need control or a self-managed setup.
### 2. Investigate a production issue
When you hit an unfamiliar issue, use BrontoScope to get an immediate starting point for your investigation.
Ideal for quickly understanding impact, likely causes, and the next queries to run.
### 3. Add AI analysis to monitor alerts
If you want investigations to run automatically when alerts fire, configure AI Investigation Reports on the monitor itself.
Best for monitor-driven workflows where responders need a diagnosis attached to the alert.
### 4. Improve the quality of your data
If your data is hard to search because it is unstructured, create a parser first.
Transform raw telemetry into structured fields that are easier to search, group, and analyze.
### 5. Instrument an LLM-powered application
If your own application calls an LLM — directly, via Amazon Bedrock/AgentCore, or through LangChain — capture that as GenAI telemetry rather than plain logs.
Best for teams shipping LLM or agent features who want prompts, responses, token usage, and model metadata searchable in Bronto.
# Amazon Bedrock AgentCore observability with OpenTelemetry
Source: https://docs.bronto.io/ai-features/aws-agentcore
Send OpenTelemetry logs, metrics, and traces from Amazon Bedrock AgentCore Runtime agents to Bronto, including agent-loop spans, token usage, and tool calls.
This page covers capturing the telemetry an agent produces while running on the [Amazon Bedrock AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html) Runtime and sending it to Bronto. Where [Amazon Bedrock LLM observability](/ai-features/aws-bedrock) instruments a single `Converse` call, an agent on AgentCore runs a multi-step reasoning loop with tool calls — producing deep, nested traces following the [OpenTelemetry GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md).
AgentCore, Strands, and the GenAI conventions evolve quickly. Commands and instrumentation behavior here were verified on **July 17, 2026** with `bedrock-agentcore-starter-toolkit`; AWS also offers a newer `agentcore-cli` with a different command set.
For the broader ingestion picture (direct OTLP vs. a Collector, and where AgentCore fits among AWS services), see [Amazon Bedrock AgentCore Logs, Metrics and Traces](/integrations/aws-agentcore). For the attributes Bronto surfaces and how to search them, see [LLM Observability](/ai-features/llm-observability).
This page uses Python with the [Strands](https://strandsagents.com/) agent framework, which emits GenAI spans through the tracer provider you configure. The same approach applies to any agent runtime: you disable AgentCore's managed telemetry pipeline and point the OpenTelemetry SDK at Bronto.
## How AgentCore observability works
AgentCore Runtime ships with a **managed OpenTelemetry pipeline** (the AWS Distro for OpenTelemetry) that, by default, delivers agent telemetry to **Amazon CloudWatch** GenAI Observability. To send logs, metrics, and traces to Bronto instead, you **disable the managed pipeline** and configure the OpenTelemetry SDK inside your agent to export OTLP to Bronto through an OTel Collector (or, where you don't run one, directly).
## Prerequisites
* Python 3.10 or later, and `pip`
* An agent deployed to AgentCore Runtime (this guide uses the [Strands](https://strandsagents.com/) framework and the `bedrock-agentcore` SDK)
* The AgentCore CLI: `pip install bedrock-agentcore-starter-toolkit`
* A running OTel Collector configured to forward to Bronto — see [Connect OpenTelemetry to Bronto](/agent-setup/open-telemetry) or, on AWS, [ADOT](/integrations/aws-adot). AgentCore's managed public network mode must reach it over a public endpoint; a private VPC-only address is not reachable. Export [directly to Bronto](#direct-export-vs-a-collector) when you do not operate a public Collector endpoint.
* A Bronto ingestion API key — held by the Collector, or sent as the `x-bronto-api-key` header when exporting directly. See [API Keys](/Account-Management/API-Keys) for how to create one with ingestion permissions.
## Disable the managed pipeline
Two switches take AWS's managed observability out of the way so your own exporters own the signal:
* At configure time, pass `--disable-otel`.
* At runtime, set `DISABLE_ADOT_OBSERVABILITY=true` — passed to the deployed agent with `--env` (see [Configure OTLP export](#configure-otlp-export) below).
```bash theme={"dark"}
agentcore configure -e agent.py -n my_agent -r eu-west-1 \
-rf requirements.txt --disable-otel --non-interactive
```
## Install dependencies
```bash theme={"dark"}
pip install \
opentelemetry-sdk \
opentelemetry-exporter-otlp-proto-http \
opentelemetry-instrumentation-botocore \
strands-agents strands-agents-tools \
bedrock-agentcore
```
## Configure OTLP export
Point the agent's OTLP exporters at your Collector, which holds the Bronto credential and forwards each signal to Bronto's per-signal endpoints.
The agent runs in a managed container, so plain shell `export` only reaches it during local development — for the deployed runtime, pass the same variables with repeated `--env` flags on `agentcore deploy`:
```bash Deployed (agentcore deploy) theme={"dark"}
# AgentCore public network mode needs an internet-reachable HTTPS endpoint,
# such as ADOT on ECS behind a public ALB. Private VPC DNS won't work.
agentcore deploy \
--env DISABLE_ADOT_OBSERVABILITY=true \
--env OTEL_EXPORTER_OTLP_ENDPOINT=https:// \
--env OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
--env OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental,gen_ai_tool_definitions
```
```bash Local development theme={"dark"}
# localhost works here because the agent and the Collector
# share your machine — a deployed agent cannot reach it.
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental,gen_ai_tool_definitions
```
`agentcore deploy --env` values are not automatically reused by a later deployment. Put every required telemetry flag in your deployment script and pass them on every redeploy, or the runtime can silently return to AWS's managed telemetry pipeline.
Keeping the exporters pointed at a Collector keeps the agent code vendor-neutral and the Bronto API key out of the runtime config. If no Collector is reachable from the runtime, export straight to Bronto instead — see [Direct export vs. a Collector](#direct-export-vs-a-collector) below.
Resource attributes such as `service.name` and `service.namespace` are set in code on a shared `Resource`, exactly as in the [standard Python setup](/opentelemetry/python#configure-the-environment). `StrandsTelemetry` accepts a pre-configured tracer provider carrying that `Resource`, so all three signals share one identity with no environment variables to keep in sync. For logs only, Bronto also maps these attributes to the dataset and collection; metrics and traces remain outside datasets and collections.
Bootstrap the three signal providers at startup — **before** the agent framework or any instrumented library is imported:
```python telemetry.py theme={"dark"}
import logging, os
# Use the current Strands GenAI shape and include tool definitions.
os.environ.setdefault(
"OTEL_SEMCONV_STABILITY_OPT_IN",
"gen_ai_latest_experimental,gen_ai_tool_definitions",
)
from opentelemetry import metrics, trace
from opentelemetry._logs import set_logger_provider
from opentelemetry.exporter.otlp.proto.http._log_exporter import OTLPLogExporter
from opentelemetry.instrumentation.botocore import BotocoreInstrumentor
from opentelemetry.sdk._logs import LoggerProvider, LoggingHandler
from opentelemetry.sdk._logs.export import BatchLogRecordProcessor
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.exporter.otlp.proto.http.metric_exporter import OTLPMetricExporter
def setup_telemetry() -> None:
# One Resource shared by logs, metrics, and traces — the same pattern as the
# standard Python setup (/opentelemetry/python#configure-the-environment).
resource = Resource.create({
"service.name": "my-agent", # shared service identity; log dataset
"service.namespace": "agents", # shared namespace; log collection
})
# Traces: hand Strands a tracer provider built on the shared resource.
# Strands creates its spans from the *global* provider, and only registers
# one itself when you don't pass your own — so set it globally here.
tracer_provider = TracerProvider(resource=resource)
trace.set_tracer_provider(tracer_provider)
from strands.telemetry import StrandsTelemetry
StrandsTelemetry(tracer_provider=tracer_provider).setup_otlp_exporter()
# Logs: bridge Python logging so structured `extra=` fields arrive as
# first-class, queryable attributes in Bronto.
logger_provider = LoggerProvider(resource=resource)
logger_provider.add_log_record_processor(BatchLogRecordProcessor(OTLPLogExporter()))
set_logger_provider(logger_provider)
logging.getLogger().addHandler(LoggingHandler(logger_provider=logger_provider))
logging.getLogger().setLevel(logging.INFO)
# Metrics: export instruments emitted by the application and its libraries.
metric_reader = PeriodicExportingMetricReader(OTLPMetricExporter())
metrics.set_meter_provider(
MeterProvider(resource=resource, metric_readers=[metric_reader])
)
# Trace the boto3 calls to AgentCore primitives (Memory, Code Interpreter,
# Gateway) as child spans of the agent invocation.
BotocoreInstrumentor().instrument()
```
Call `setup_telemetry()` at the very top of your entrypoint, before importing Strands:
```python agent.py theme={"dark"}
from telemetry import setup_telemetry
setup_telemetry()
from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent
# ...
```
## What you get on the trace
A single agent invocation becomes one trace with nested spans:
| Span | Source | Notes |
| - | - | - |
| Agent invocation / loop | Strands | Root span for the reasoning loop |
| `chat` | Strands GenAI instrumentation | One per model call, carrying `gen_ai.*` attributes; the model id is an attribute |
| Tool calls | Strands | One child span per tool the agent invokes |
| AgentCore primitive calls | `BotocoreInstrumentor` | Memory, Code Interpreter, and Gateway (MCP) calls as child spans |
Useful GenAI attributes on the model spans:
| Attribute | Example | Notes |
| - | - | - |
| `gen_ai.request.model` | `eu.amazon.nova-pro-v1:0` | Requested model / inference profile |
| `gen_ai.usage.input_tokens`, `gen_ai.usage.output_tokens` | `412`, `173` | Token usage (numeric — chart and sum these) |
| `gen_ai.operation.name` | `chat` | Operation type |
| `gen_ai.response.finish_reasons.0` | `end_turn` | Why generation stopped |
These are first-class, queryable fields in Bronto. See [LLM Observability](/ai-features/llm-observability) for the full recommended attribute set.
Strands tool-call spans use standard attributes including `gen_ai.tool.name` and `gen_ai.tool.call.id`; exact coverage varies by Strands version. AgentCore-primitive spans from `BotocoreInstrumentor` (Memory, Code Interpreter, Gateway) instead carry AWS SDK attributes such as `rpc.method` and `aws.request_id`. Inspect a real trace before building version-sensitive dashboards.
## Capturing prompt, response, and tool IO
Strands captures message content by default and does not use `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT`. To put content directly on span attributes for backends that cannot read OTel events, add `gen_ai_span_attributes_only` to `OTEL_SEMCONV_STABILITY_OPT_IN`. Treat this data as sensitive. You can also log each agent result as structured GenAI attributes:
```python theme={"dark"}
import logging
log = logging.getLogger(__name__)
# after the agent produces its answer:
log.info(
"agent.result",
extra={
"event.name": "agent.result",
"gen_ai.request.model": model_id,
"gen_ai.output.messages": response_text, # full response as a queryable field
"session.id": session_id,
},
)
```
Avoid printf-style logging (`log.info("tokens=%s", n)`) for data you want to query — that produces a flat message string rather than structured fields. See [LLM Observability](/ai-features/llm-observability) for the recommended attribute names.
## Verify in Bronto
Trigger an invocation of the deployed agent:
```bash theme={"dark"}
agentcore invoke '{"prompt": "What is the weather in Dublin?"}'
```
**Traces** — open [Explore Traces](/tracing/explore-traces) and filter by your `service.name`. Open the newest trace and confirm the nesting from the table above: the agent loop at the root, a `chat` span per model call, and tool-call / AgentCore-primitive spans beneath it.
**Logs** — open [Log Search](https://app.bronto.io/search) and filter by the same `service.name`.
**Metrics** — open **Metric Explorer**, select a recently emitted metric, and confirm that it carries the same `service.name`. Exponential histograms are not supported. For Sum, Summary, and Histogram metrics, the Metric Explorer provides [per-second rate functions](/metrics/explore-metrics#aggregation-functions).
Bronto indexes log-record attributes with a `$` prefix. Query the structured fields by name — for example `"$event.name"` or `"$gen_ai.request.model"`.
Because the searchable body of a structured event is the event name, search agent content with **field predicates** rather than full-text:
```
"$event.name" = 'agent.result'
```
```
"$gen_ai.output.messages" ILIKE '%degraded%'
```
Token usage is numeric, so you can aggregate it — for example average output tokens per model, or total tokens over time — in aggregate views and [Visualizations](/Search-and-Visualize/Log-Visualization).
## Direct export vs. a Collector
* **Via an OTel Collector** (recommended) — the agent exports OTLP to a Collector that holds the Bronto credential and forwards each signal. This keeps the agent code vendor-neutral, gives you a place to add processors / sampling / fan-out, and matches how Bronto ingests other AWS telemetry. See [Amazon Bedrock AgentCore Logs, Metrics and Traces](/integrations/aws-agentcore) and [ADOT](/integrations/aws-adot).
* **Direct OTLP to Bronto** — when no Collector is reachable from the runtime, or for short-lived jobs: set `OTEL_EXPORTER_OTLP_ENDPOINT` to the Bronto ingestion base (EU `https://ingestion.eu.bronto.io`, US `https://ingestion.us.bronto.io`) and add your [API key](/Account-Management/API-Keys) as the `x-bronto-api-key` header. No Collector, VPC, or sidecar required.
```bash theme={"dark"}
agentcore deploy \
--env DISABLE_ADOT_OBSERVABILITY=true \
--env OTEL_EXPORTER_OTLP_ENDPOINT=https://ingestion.eu.bronto.io \
--env OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
--env OTEL_EXPORTER_OTLP_HEADERS="x-bronto-api-key="
```
## References
* [Amazon Bedrock AgentCore Logs, Metrics and Traces](/integrations/aws-agentcore)
* [Amazon Bedrock LLM observability](/ai-features/aws-bedrock)
* [LLM Observability](/ai-features/llm-observability)
* [Amazon Bedrock AgentCore documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html)
* [OpenTelemetry GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md)
# Amazon Bedrock LLM observability with OpenTelemetry
Source: https://docs.bronto.io/ai-features/aws-bedrock
Capture token usage, model metadata, and prompt/response content from Amazon Bedrock calls with OpenTelemetry GenAI auto-instrumentation in Bronto.
This page covers instrumenting an application that calls the Amazon Bedrock `Converse` / `InvokeModel` APIs so that GenAI telemetry — token usage, model, latency, finish reason, and prompt/response content — flows to Bronto following the [OpenTelemetry GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/aws-bedrock.md).
The conventions and instrumentation are in active development. This page was verified on **July 17, 2026**.
For the broader ingestion picture (the Collector and where Bedrock fits among AWS services), see [Amazon Bedrock Logs, Metrics and Traces](/integrations/aws-bedrock). For the attributes Bronto surfaces and how to search them, see [LLM Observability](/ai-features/llm-observability).
## Prerequisites
* Python 3.9 or later, and `pip`
* An application that calls Amazon Bedrock via `boto3` (the `bedrock-runtime` client)
* A running OTel Collector configured to forward to Bronto — see [Connect OpenTelemetry to Bronto](/agent-setup/open-telemetry) or, on AWS, [ADOT](/integrations/aws-adot)
## Install dependencies
```bash theme={"dark"}
pip install \
opentelemetry-sdk \
opentelemetry-exporter-otlp-proto-http \
opentelemetry-instrumentation-botocore \
boto3
```
**Version matters for Bedrock.** The Bedrock GenAI extension lives in `opentelemetry-instrumentation-botocore`, and it was added relatively recently. Older releases (for example `0.50b0`) ship **no Bedrock extension at all** — Bedrock calls are then traced only as generic AWS API spans (`rpc.system`, `rpc.method=Converse`, `aws.request_id`) with **no token usage, model, or prompt/response**. If your traces are missing GenAI data, this is almost always the cause.
Use `opentelemetry-instrumentation-botocore>=0.55b0`; this guide was validated with `0.64b0` and `opentelemetry-sdk==1.43.0`.
## Enable Bedrock GenAI instrumentation
The botocore instrumentation patches the `bedrock-runtime` client automatically. To include message content in its trace-correlated log events, set this before instrumentation starts:
```bash theme={"dark"}
# Capture prompt and response content (off by default)
export OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=true
```
Instrument either with the zero-code wrapper:
```bash theme={"dark"}
opentelemetry-instrument python app.py
```
…or programmatically at startup (set the environment variables **before** this runs):
```python instrument.py theme={"dark"}
from opentelemetry.instrumentation.botocore import BotocoreInstrumentor
BotocoreInstrumentor().instrument()
```
With this in place, recognized Bedrock models produce a client span named like `chat ` carrying GenAI attributes. Unrecognized or newly introduced inference-profile IDs can retain the generic `Bedrock Runtime.Converse` name; inspect the attributes rather than relying only on the span name.
## What you get on the span
Botocore `0.64b0` emits the following span attributes when the corresponding value is available:
| Attribute | Example | Notes |
| - | - | - |
| `gen_ai.system` | `aws.bedrock` | Provider identifier emitted by this botocore release |
| `gen_ai.operation.name` | `chat` | `chat` for most calls; `text_completion` for Amazon Titan text completion via `InvokeModel` |
| `gen_ai.request.model` | `eu.amazon.nova-micro-v1:0` | Requested model or inference-profile ID |
| `gen_ai.request.max_tokens` | `512` | Maximum output tokens requested |
| `gen_ai.request.temperature` | `0.7` | Sampling temperature |
| `gen_ai.request.top_p` | `0.9` | Top-p sampling value |
| `gen_ai.request.stop_sequences` | `["END"]` | Array of requested stop sequences |
| `gen_ai.usage.input_tokens` | `9` | Input tokens reported by Bedrock; estimated for some model-specific `InvokeModel` responses |
| `gen_ai.usage.output_tokens` | `36` | Output tokens reported by Bedrock; estimated for some model-specific `InvokeModel` responses |
| `gen_ai.response.finish_reasons` | `["end_turn"]` | Array containing the response stop reason |
| `server.address` | `bedrock-runtime.eu-west-1.amazonaws.com` | Bedrock Runtime endpoint |
| `server.port` | `443` | Endpoint port |
| `error.type` | `ValidationException` | Present when the operation ends with an error |
The span is a `CLIENT` span and is normally named `chat ` or `text_completion `. Request parameters, usage, and finish reason are conditional: botocore omits a field when the request or selected model does not expose it.
The general-purpose `BotocoreInstrumentor` also adds AWS SDK attributes such as `rpc.system = aws-api`, `rpc.method`, `rpc.service`, and `aws.request_id`. The request ID is useful for correlating the span with CloudTrail and other AWS-side logs. Inspect a real span with a Collector `debug` exporter or a local `ConsoleSpanExporter` before relying on version-sensitive AWS attributes.
## Metrics emitted by botocore
When an OpenTelemetry meter provider is configured, the same instrumentation emits:
| Metric | Unit | Dimensions |
| - | - | - |
| `gen_ai.client.operation.duration` | Seconds | `gen_ai.system`, `gen_ai.operation.name`, `gen_ai.request.model`, `server.address`, `server.port`, and `error.type` on failures |
| `gen_ai.client.token.usage` | Tokens | The same dimensions plus `gen_ai.token.type` to distinguish input and completion tokens |
## Capture input and output content
### Automatic content events
Botocore `0.64b0` records messages as trace-correlated OTel log events rather than `gen_ai.input.messages` / `gen_ai.output.messages` span attributes. Depending on the request, it emits `gen_ai.system.message`, `gen_ai.user.message`, `gen_ai.assistant.message`, `gen_ai.tool.message`, and `gen_ai.choice`. With content capture disabled, these events can still be emitted but their message bodies are empty.
Prompts, responses, system instructions, and tool data can contain sensitive information. Enable content capture only after applying appropriate access controls, redaction, and retention policies.
### Put input messages on the Bedrock span
If you need the current `gen_ai.input.messages` field directly on the botocore-created Bedrock client span, add a `request_hook`. The hook runs while that span is active. Use this setup instead of the basic `BotocoreInstrumentor().instrument()` call above. This example normalizes text messages sent through `Converse` or `ConverseStream` and stores the structured value as JSON:
```python theme={"dark"}
import json
from opentelemetry.instrumentation.botocore import BotocoreInstrumentor
def bedrock_request_hook(span, service_name, operation_name, api_params):
if service_name != "bedrock-runtime" or operation_name not in {
"Converse",
"ConverseStream",
}:
return
messages = []
for message in api_params.get("messages", []):
parts = [
{"type": "text", "content": block["text"]}
for block in message.get("content", [])
if "text" in block
]
messages.append({"role": message["role"], "parts": parts})
if messages:
span.set_attribute("gen_ai.input.messages", json.dumps(messages))
BotocoreInstrumentor().instrument(request_hook=bedrock_request_hook)
```
Extend the normalizer if your requests include images, documents, tool calls, or tool results. `InvokeModel` request bodies are provider-specific and require model-specific parsing.
Botocore already records generated output in the `gen_ai.choice` content event. An application can additionally add `gen_ai.output.messages` to an enclosing application span or a structured log after the response has been consumed. This is often simpler for streaming responses, because their final output is not available when the initial botocore response hook runs.
## Verify in Bronto
After running your application, open [Log Search](https://app.bronto.io/search) and filter by the `service.name` you set on your resource. Find all Bedrock spans emitted by botocore:
```sql theme={"dark"}
"$gen_ai.system" = 'aws.bedrock'
```
Find calls to a particular model or inference profile:
```sql theme={"dark"}
"$gen_ai.system" = 'aws.bedrock'
AND "$gen_ai.request.model" = 'eu.amazon.nova-micro-v1:0'
```
Find calls that stopped because the model completed its turn. Botocore emits an array on the span; Bronto indexes its first element as `.0`:
```sql theme={"dark"}
"$gen_ai.response.finish_reasons.0" = 'end_turn'
```
Find unusually large responses:
```sql theme={"dark"}
"$gen_ai.usage.output_tokens" > 1000
```
For captured request content, search the structured body of the emitted user-message event:
```sql theme={"dark"}
"$event.name" = 'gen_ai.user.message'
AND "$content.0.text" ILIKE '%refund%'
```
For captured response content, search the choice event:
```sql theme={"dark"}
"$event.name" = 'gen_ai.choice'
AND "$message.content.0.text" ILIKE '%refund approved%'
```
If you installed the request hook above, search the input attribute on the Bedrock span directly:
```sql theme={"dark"}
"$gen_ai.input.messages" ILIKE '%refund%'
```
In aggregate views, select **Sum**, **Average**, **Median**, or a percentile for `$gen_ai.usage.input_tokens` or `$gen_ai.usage.output_tokens`, then group by `$gen_ai.request.model`. This compares token usage across Bedrock models using fields botocore emits today. See [Visualizations](/Search-and-Visualize/Log-Visualization) for dashboard options.
## Direct export to Bronto
If you are not running a Collector (for local development or short-lived jobs), export OTLP straight to Bronto by adding your API key. See the [direct export section](/opentelemetry/python#direct-export-to-bronto) on the Python page; point the exporters at the Bronto ingestion endpoints:
| Region | Traces endpoint | Logs endpoint | Metrics endpoint |
| - | - | - | - |
| EU | `https://ingestion.eu.bronto.io/v1/traces` | `https://ingestion.eu.bronto.io/v1/logs` | `https://ingestion.eu.bronto.io/v1/metrics` |
| US | `https://ingestion.us.bronto.io/v1/traces` | `https://ingestion.us.bronto.io/v1/logs` | `https://ingestion.us.bronto.io/v1/metrics` |
Exponential histograms are not supported. For Sum, Summary, and Histogram metrics, the Metric Explorer provides [per-second rate functions](/metrics/explore-metrics#aggregation-functions).
## References
* [Amazon Bedrock Logs, Metrics and Traces](/integrations/aws-bedrock)
* [LLM Observability](/ai-features/llm-observability)
* [Semantic conventions for AWS Bedrock](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/aws-bedrock.md)
* [opentelemetry-instrumentation-botocore](https://pypi.org/project/opentelemetry-instrumentation-botocore/)
# AWS DevOps Agent Integration
Source: https://docs.bronto.io/ai-features/aws-devops-agent
Register Bronto's hosted MCP server with the AWS DevOps Agent so it can search your Bronto logs while investigating and operating workloads in AWS.
## Overview
The [AWS DevOps Agent](https://aws.amazon.com/) is an AI assistant for operating AWS workloads. By registering Bronto's hosted MCP server as a **Capability Provider**, the DevOps Agent can search your Bronto **log datasets** and call Bronto's time-series and schema-discovery tools while it investigates issues — grounding its reasoning in your actual log data instead of just AWS service state. Metrics and traces are not stored in datasets or collections; view them in Bronto's Metric Explorer and Explore Traces.
This page walks through registering the Bronto MCP server in the AWS DevOps Agent console using API-key authentication. For the underlying AWS workflow, see the [AWS documentation on connecting MCP servers](https://docs.aws.amazon.com/devopsagent/latest/userguide/configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.html).
## Prerequisites
* A Bronto account with data being ingested. If you haven't sent data yet, [set up an agent](/agent-setup/agent-intro) first.
* A Bronto API key with search permissions. See [API Keys](/Account-Management/API-Keys).
* Access to the AWS DevOps Agent in your AWS account, with permission to register Capability Providers.
* The Bronto hosted MCP endpoint for your region — see [Hosted MCP Server](/ai-features/hosted-mcp).
| Region | Hosted MCP Endpoint URL |
| - | - |
| US | `https://mcp.us.bronto.io/mcp` |
| EU | `https://mcp.eu.bronto.io/mcp` |
## Register the Bronto MCP server
In the AWS DevOps Agent console, open **Capability Providers** and start the **Register MCP Server** flow.
Enter the server details:
| Field | Value |
| - | - |
| **Name** | `BrontoMCPServer` (or any name you prefer) |
| **Endpoint URL** | The hosted MCP endpoint for your region (see above) |
| **Description** | Optional |
Bronto's hosted MCP server implements the **Streamable HTTP** transport, which is what the DevOps Agent requires.
Click **Next**.
Select **API Key** as the authorization flow. The Bronto hosted MCP server authenticates incoming requests via a static API-key header, so this is the correct option — not OAuth or AWS SigV4.
Click **Next**.
Enter the API-key configuration that Bronto expects:
| Field | Value |
| - | - |
| **API Key Name** | `BrontoAPIKey` (display name only) |
| **API Key Header** | `X-BRONTO-API-KEY` |
| **API Key Value** | Your Bronto API key |
The header name **must** be `X-BRONTO-API-KEY` — Bronto's MCP server reads the API key from this header and will reject requests sent under any other header name.
Click **Next**.
Confirm the MCP server details and authorization configuration, then click **Add**.
## Select MCP server tools
After registration, the DevOps Agent prompts you to choose which Bronto tools it is allowed to call. The Bronto hosted MCP server exposes a set of read-only tools that cover log schema discovery, log search, time-series analysis over log data, and saved searches. These dataset tools do not query metrics or traces.
The recommended setup is to enable **all** Bronto tools. They are all read-only and cooperative — for example, the agent typically uses `get_datasets` and `get_keys` to discover the right dataset and schema before issuing a `search_logs` or `timeseries` query.
For full descriptions of each tool, see [Hosted MCP Server — Capabilities](/ai-features/hosted-mcp#capabilities).
As shown in the AWS UI, only enable MCP tools that are **read-only**. All Bronto tools listed here are read-only — they query log data and metadata without modifying anything in your Bronto account.
Click **Save** to finish.
## Verify the connection
Open an Agent Space in the AWS DevOps Agent console and ask a question that requires Bronto data, for example:
```
List the datasets I have in Bronto.
```
The agent should call `get_datasets` against the Bronto MCP server and return the datasets in your account.
Once that works, you can move on to investigation-style prompts — searching recent error logs or comparing time windows. See [Hosted MCP Server — Example Prompts](/ai-features/hosted-mcp#example-prompts) for inspiration.
## Example use cases
Once the Bronto Capability Provider is attached to an Agent Space, the DevOps Agent can combine AWS service state with Bronto telemetry in a single investigation. A few common workflows:
### Root-cause a service incident with log context
When a service is misbehaving — elevated errors, failing health checks, customer reports, or a triggered alert — the agent can identify the affected resource in AWS and then call `search_logs` against the Bronto dataset for that service to surface the errors driving the incident. That includes stack traces, request IDs, and downstream-dependency failures that aren't visible from AWS service state alone.
### Investigate latency regressions in access logs
Ask the agent to compare request-duration fields in your log datasets with a baseline window using `timeseries`, then drill into the slowest log events with `search_logs`. Use Bronto's Explore Traces page when the investigation requires span-level trace data.
### Correlate deployments with error spikes
Point the agent at a recent ECS, EKS, or Lambda deployment and ask whether errors increased after the rollout. The agent uses AWS to identify the deploy window and Bronto to count and sample errors before and after — giving you a quick verdict on whether to roll back.
### Diagnose noisy or failing AWS Lambda functions
For a specific Lambda function, the agent can fetch recent invocations from AWS and then call `search_logs` with the function name as a filter to summarise the dominant error patterns. Useful when a function is silently retrying, timing out, or hitting a downstream rate limit.
### Investigate elevated 5xx responses behind ALB or API Gateway
Combine AWS ALB or API Gateway metrics with Bronto access logs to find the host, path, and upstream service driving a 5xx spike. The agent can use `get_keys` to discover the right fields in your dataset before grouping and filtering — without you having to remember the schema.
### Follow a request through correlated logs
When you have a request ID, trace ID, or user ID from an AWS support case, ask the agent to find related log events in Bronto. The agent searches log datasets to assemble a timeline from correlated logs. To inspect the spans in a distributed trace, open Explore Traces in Bronto.
## Troubleshooting
**Authentication errors when the agent calls Bronto.** Double-check that the API Key Header is exactly `X-BRONTO-API-KEY` and that the API key value is valid and has search permissions. Also confirm you registered the endpoint for the correct region (US vs EU) — a mismatched region returns an authentication error.
**The agent does not call Bronto tools.** Confirm the tools were enabled on the **Select MCP server tools** step, and that the Bronto Capability Provider is attached to the Agent Space where you are prompting from.
# Bronto Agent Skills
Source: https://docs.bronto.io/ai-features/bronto-agent-skills
Install Bronto's agent skills and plugins for Cursor or Claude Code so coding agents can investigate telemetry and improve logging workflows.
Bronto Agent Skills is a GitHub repository that packages Bronto-specific instructions and plugin metadata for AI coding assistants.
Use it when you want an agent to understand Bronto's MCP tools, investigate log datasets from your editor, or run Bronto's Claude Code logging workflow. Metrics and traces are viewed in their dedicated Bronto explorers rather than through dataset search.
The Cursor plugin and Claude Code plugin currently solve different jobs. The
Cursor plugin installs the Bronto MCP configuration and Bronto investigation
skill. The Claude Code marketplace plugin currently provides the
`bronto-logging` workflow for adding stable statement IDs to logging calls.
Repository:
```text theme={"dark"}
https://github.com/brontoio/bronto-agent-skills
```
## What's included
Teaches an agent how to use Bronto MCP for log-dataset discovery, schema
inspection, timeseries analysis, raw log search, trace IDs, latency, and
production debugging.
Bundles the Bronto hosted MCP server configuration for US and EU regions
with the Bronto investigation skill.
Adds the `bronto-logging` Claude Code plugin, including a statement ID
supervisor skill and worker agent for updating logging calls across a
codebase.
Defines hosted MCP endpoints for `bronto-us` and `bronto-eu`. OAuth is the
default, with regional API keys available as an optional alternative.
## Before you start
You need:
* A Bronto account in the correct data region, US or EU
* MCP access enabled by a Bronto administrator under **Settings → Authentication**
* Optionally, a Bronto API key if you prefer API-key authentication to OAuth
* Cursor or Claude Code, depending on the workflow you are setting up
If you choose API-key authentication, create or manage keys in [API Keys](../Account-Management/API-Keys).
Use the MCP endpoint that matches your Bronto organization:
| Region | Hosted MCP endpoint |
| - | - |
| US | `https://mcp.us.bronto.io/mcp` |
| EU | `https://mcp.eu.bronto.io/mcp` |
## Use with Cursor
The Cursor plugin is the most direct way to use this repository for Bronto telemetry investigation from an IDE. It installs:
* `mcp.json` with `bronto-us` and `bronto-eu` hosted MCP servers
* `skills/bronto/SKILL.md`, which tells the agent how to investigate Bronto telemetry
* Reference material for query shapes, MCP tool order, and investigation patterns
The plugin is also listed in the [Cursor Plugin Directory](https://cursor.directory/plugins/bronto). See the [Cursor plugin README](https://github.com/brontoio/bronto-agent-skills/tree/main/.cursor-plugin) for the latest installation and configuration details.
Start the Cursor Agent CLI with `agent`, run:
```text theme={"dark"}
/plugin
```
Paste `https://github.com/brontoio/bronto-agent-skills.git` into plugin
search, then install it at user or project scope.
Open **Customize → MCPs**, select `bronto-us` or `bronto-eu` for your
organization's region, then select **Login** and complete the browser
authentication flow. Disable the unused regional server.
If you do not want to use OAuth, open the installed Bronto plugin in
**Customize**, select **Configure**, and set `US_BRONTO_API_KEY` or
`EU_BRONTO_API_KEY` for your organization's region.
Run **Developer: Reload Window** from the command palette.
Open Cursor's MCP status and confirm that either `bronto-us` or `bronto-eu`
is connected. Disable or ignore the region you do not use.
Try a prompt like:
```text theme={"dark"}
Use Bronto to list the datasets available in this organization, then show the keys for the production API logs.
```
## Use with Claude Code
There are two Claude Code paths, depending on what you want to do.
### Investigate Bronto telemetry
For telemetry investigation in Claude Code, connect Claude directly to Bronto's hosted MCP endpoint.
```bash theme={"dark"}
claude mcp add --transport http bronto https://mcp.eu.bronto.io/mcp
```
Use the US endpoint instead if your Bronto account is hosted in the US:
```bash theme={"dark"}
claude mcp add --transport http bronto https://mcp.us.bronto.io/mcp
```
Then run:
```text theme={"dark"}
/mcp
```
Select Bronto and complete the authentication flow. See [Hosted MCP Server](./hosted-mcp) for the full setup guide.
### Use the Claude Code logging plugin
The Claude Code marketplace in `bronto-agent-skills` exposes the `bronto-logging` plugin. Use it when you want Claude Code to add or update stable `stmt_id` values on logging statements across a codebase.
```text theme={"dark"}
/plugin
```
Choose **Add Marketplace**, then enter:
```text theme={"dark"}
brontoio/bronto-agent-skills
```
Go to **Manage and uninstall plugins**, select
**bronto-claude-code-plugins**, then enable **bronto-logging**.
Ask Claude Code to add statement IDs to logging calls in a directory:
```text theme={"dark"}
Use the Bronto logging plugin to add stable statement IDs to logging calls under src/.
```
The plugin discovers logging calls, dispatches worker agents by file, and merges the generated mapping into `statementIds.json`.
## How the Bronto investigation skill works
The Bronto skill gives agents a repeatable query workflow:
1. Discover datasets with `get_datasets` or `get_datasets_by_name`.
2. Inspect fields with `get_keys`.
3. Inspect useful dimensions with `get_key_values`.
4. Use `timeseries` first for counts, rates, percentiles, group-bys, regressions, and top offenders.
5. Use `search_logs` for representative raw examples, exact trace IDs, event IDs, pasted errors, and payload drill-down.
This prevents the agent from guessing field names, querying every dataset, or jumping straight to raw logs before it has an aggregate view.
## Verify the setup
After installing either integration, ask the agent:
```text theme={"dark"}
List the Bronto datasets I can access, then show the available keys for one production dataset.
```
A working setup should return dataset names, collections, dataset IDs, and field names from the correct Bronto region.
If authentication fails, check:
* You are using the endpoint for the correct Bronto region
* The matching regional API key is configured if using API-key auth
* MCP login is enabled in Bronto if using OAuth
* Cursor third-party plugins, skills, and configs are enabled if using Cursor
# BrontoScope
Source: https://docs.bronto.io/ai-features/brontoscope
Investigate error events automatically with BrontoScope, an AI-powered tool that identifies scope, root causes, and next steps without writing queries.
BrontoScope enables **automatic AI-powered error investigation** directly from your logs. Instead of manually querying and correlating data, BrontoScope analyzes error events for you and delivers a structured report in seconds.
No prompts. No setup. Just click and investigate.
***
## Overview
When you encounter an error event in your logs, BrontoScope can:
* Analyze the event across multiple dimensions
* Correlate signals from logs, services, and infrastructure
* Identify patterns and anomalies
* Generate a clear, actionable report
All in **under 10 seconds**.
***
## How It Works
1. Navigate to your logs and locate an error event
2. Click the event to open the **event panel**
3. Select **Investigate with AI**
4. BrontoScope automatically runs a multi-step analysis
5. Review the generated report and supporting data
***
## What BrontoScope Analyzes
### 1. Problem Scope
BrontoScope determines the full impact of the error, including:
* When the issue started
* Whether the issue is ongoing or resolved
* Affected:
* Users
* Services
* Hosts
* Regions (if applicable)
This helps you quickly understand **blast radius and urgency**.
***
### 2. Likely Causes
The AI evaluates patterns and correlations to suggest potential root causes, such as:
* Network instability or latency spikes
* Sudden traffic increases or load imbalance
* Recent deployments or configuration changes
* Application-level bugs or exceptions
These insights are **hypothesis-driven**, not guesses — each is backed by observed data patterns.
***
### 3. Recommended Next Steps
BrontoScope provides actionable guidance to move forward, including:
* Suggested queries to run
* Services or systems to inspect
* Metrics to validate
* Additional logs or time windows to review
This reduces time-to-resolution by guiding your investigation.
***
### 4. Supporting Evidence
Every conclusion is backed by transparent data:
* Underlying queries executed by the AI
* Relevant log samples
* Generated charts and trends
* Time-based comparisons
You can **validate, refine, or extend** the investigation at any time.
***
## Key Benefits
### No Prompt Required
BrontoScope requires **zero input from the user**. It:
* Understands the context of the selected error
* Determines relevant queries automatically
* Executes a full investigation workflow
***
### Fast Time to Insight
* Results delivered in **under 10 seconds**
* Eliminates manual querying and correlation
* Reduces mean time to detection (MTTD) and resolution (MTTR)
***
### Explainable AI
Unlike black-box systems, BrontoScope shows:
* How conclusions were reached
* What data was used
* Which queries were executed
This ensures **trust and auditability**.
***
## When to Use BrontoScope
Use BrontoScope whenever you:
* Encounter a new or unfamiliar error
* Need to quickly assess impact
* Want to validate whether an issue is widespread
* Are debugging production incidents
* Need a starting point for deeper investigation
***
## Best Practices
* Start with the **first occurrence** of an error for cleaner insights
* Compare multiple investigations if the issue evolves over time
* Use the generated queries to drill deeper into specific hypotheses
* Combine with dashboards and alerts for full observability coverage
***
## Limitations
* Results depend on available log and telemetry data
* AI-generated causes are **probabilistic**, not guaranteed root causes
* Complex multi-system failures may require further manual investigation
***
## Summary
BrontoScope transforms error investigation from a manual, time-consuming process into an **instant, AI-driven workflow**.
By combining automated analysis, clear explanations, and actionable insights, it enables teams to:
* Detect issues faster
* Understand impact immediately
* Resolve incidents more efficiently
# Hosted MCP Server
Source: https://docs.bronto.io/ai-features/hosted-mcp
Connect Claude and other MCP clients to Bronto's hosted MCP endpoint to query log data, no local server required, using your existing Bronto login.
Hosted MCP is available to all Bronto accounts. MCP access is governed by the
same login controls used across the rest of the product.
## Overview
Bronto now supports a **hosted MCP experience**. Instead of running an MCP server yourself, you can enable MCP access directly in the Bronto UI, sign in with your existing Bronto login method (OAuth, SSO, or Google Social), and connect supported MCP clients to Bronto's hosted MCP endpoint.
This makes the setup feel much closer to connecting any other SaaS integration than bootstrapping local developer infrastructure. User and access management for MCP is identical to any other access to your Bronto account.
***
## Enabling MCP in the UI
The first step is to enable MCP access inside Bronto. Hosted MCP access is intentionally tied to the same login controls used by the rest of the product — if a login method is not enabled for MCP, authorization requests using that method will be rejected.
This gives admins a clear, centralised way to control:
* Whether MCP access is allowed at all
* Which login methods are valid for MCP
* Which users can successfully complete the MCP OAuth flow
Navigate to **Settings → Authentication** in the Bronto UI. You will see the
MCP login method listed as an available option on this page.
Toggle the MCP login method to **Enabled**.
Click **Configure** on the MCP card to open the configuration panel.
Review the available SSO providers and any other supported login methods
that should be permitted for MCP access.
Click **Save** to apply the configuration. MCP access is now enabled for the
selected login methods.
***
## Connecting an MCP Client
Once MCP is enabled in the UI, client setup is significantly simpler than the local-server approach. Instead of pointing the client at a locally running process, you configure it to use Bronto's hosted MCP endpoint. The client then performs the standard OAuth flow.
Open a terminal and run the following command to register the Bronto MCP
server and launch Claude CLI:
```bash theme={"dark"}
claude mcp add --transport http bronto https://mcp.eu.bronto.io/mcp && claude
```
Once Claude CLI is open, enter the following command:
```
/mcp
```
Select **Bronto** from the list and press **Enter** to open the MCP
authentication flow.
```
──────────────────────────────────────
Manage MCP servers
1 servers Local MCPs
❯ bronto · △ needs authentication
```
In Claude Desktop or Claude Web, go to **Settings → Connectors** and
select **Add custom connector**.
Enter a name for the connector, then provide the hosted MCP endpoint URL
for the region where your Bronto account is located:
| Region | MCP Endpoint URL |
| - | - |
| US | `https://mcp.us.bronto.io/mcp` |
| EU | `https://mcp.eu.bronto.io/mcp` |
Select the **Connect** button beside the Bronto MCP entry in the
connectors list to open the authentication flow.
***
## Authentication Flow
After adding the connection, you must authenticate with Bronto. The flow is the same regardless of which client you use.
Your MCP client opens the Bronto MCP authorization URL in a browser window.
Sign in using an allowed Bronto login method — OAuth, SSO, or Google Social,
whichever has been enabled for MCP by your admin.
Review and approve the requested permission scopes.
Bronto redirects back to your MCP client and issues an access token. Your
client is now connected.
The authentication flow mirrors the standard OAuth 2.0 pattern. Once
connected, token refresh is handled automatically by the client.
***
## API Key Access
The hosted MCP endpoint also supports **API key-based access** for clients that can send custom headers directly. This is useful when an MCP client only supports local stdio servers but you want to connect it to a remote hosted endpoint.
### Using mcp-remote
[mcp-remote](https://www.npmjs.com/package/mcp-remote) is a bridge utility that translates stdio-based MCP clients to remote HTTP endpoints with support for custom auth headers.
```json theme={"dark"}
{
"mcpServers": {
"bronto-eu": {
"command": "npx",
"args": [
"mcp-remote",
"https://mcp.eu.bronto.io/mcp",
"--header",
"X-BRONTO-API-KEY:${AUTH_TOKEN}"
],
"env": {
"AUTH_TOKEN": ""
}
}
}
}
```
Never hardcode your API key directly in configuration files that may be
committed to version control. Use environment variables as shown above.
### Direct Header Attachment
For clients that support `streamable-http` transport and custom headers natively, such as [Kiro](https://kiro.dev/), you can attach the API key header directly without mcp-remote:
```json theme={"dark"}
{
"mcpServers": {
"bronto-us": {
"type": "streamable-http",
"url": "https://mcp.us.bronto.io/mcp",
"headers": {
"Accept": "application/json, text/event-stream",
"X-BRONTO-API-KEY": ""
},
"autoApprove": [],
"disabled": false
}
}
}
```
***
## Endpoint Reference
| Region | Hosted MCP Endpoint URL |
| - | - |
| US | `https://mcp.us.bronto.io/mcp` |
| EU | `https://mcp.eu.bronto.io/mcp` |
Use the endpoint that matches the data region where your Bronto account is hosted. Connecting to the wrong region will result in an authentication error.
***
## Capabilities
The Bronto hosted MCP server exposes a set of tools to connected clients, covering the full workflow: discover schema, search and aggregate log data, save and re-run queries, manage alerting monitors, and audit coverage and usage.
A typical investigation moves through these in sequence: use `get_datasets` to identify the right data source, `get_keys` to understand its schema, `get_key_values` to build precise filters, then `search_logs` for raw event investigation or `timeseries` for aggregated trend analysis. From there you can preserve a query as a saved search, turn a finding into a monitor, and check where you have coverage or blind spots.
### Discovery & search
Returns the available field names for every dataset you can access. Use this
to quickly understand the schema across all datasets before running searches
or aggregations.
Lists all available datasets, including each dataset's name, collection,
unique dataset ID, and tags. Use this when you need to discover what data
sources are available.
Finds datasets by exact dataset name and collection name. Use this when you
know the dataset you want and need its metadata or dataset ID.
Returns the available values for a specific field in a specific dataset. Use
this to discover common field values and build more precise filters.
Returns the available field names for a specific dataset. Use this to
inspect a dataset's schema before querying it.
Searches raw log events in one or more datasets over a time range. Supports
dataset IDs or a dataset selection expression, optional filters, result
limits, and sorting. Best for investigations and event-level troubleshooting.
Computes aggregated metrics and time-series trends from log data. Supports
COUNT, SUM, AVG, percentile calculations, grouping, time bucketing, and
comparison windows. Best for summaries and trend analysis.
### Saved searches
Lists and reads saved searches, with optional filtering by text, tag, or
field. Use this to discover existing saved searches before creating a new one.
Creates one or more saved searches. As well as the query, it can set how the
saved search renders — list, timeseries, table, top-list, pie, treemap, or a
geomap of values by country. Supports batch creation.
Executes a saved search by id and returns its results, identical to running
the query directly. Optionally run it over a different time window.
### Monitors & coverage
Finds existing monitors and, for a given monitor, its recent trigger and
recovery history. Useful for retrospectives and avoiding duplicate alerts.
Creates monitors (always muted for review before they can alert). Supports
threshold and no-data alerting (fire when a log goes quiet) and an
investigation prompt that Bronto runs automatically when the monitor fires.
Health-checks your existing monitors by re-running each backing query, so you
can spot alarms that have silently broken or stopped receiving data.
Reports, per dataset, whether it is monitored, searched, and still ingesting —
surfacing blind spots such as a live dataset with no alert watching it.
### Usage & health
Returns org-wide error and warning totals with a per-dataset breakdown.
Precomputed, so it costs no search quota to run.
Reports per-dataset ingestion and search usage against your monthly limits,
and whether each dataset is actively ingesting or dormant.
***
## Example Prompts
The best hosted MCP workflows start with dataset discovery, narrow the search space, then ask focused operational questions. CDN logs are a strong example: high-volume, operationally important, and often the first place teams look when users report latency, origin instability, or unusual traffic.
The following prompts demonstrate useful fault-finding and analysis workflows using Claude and Opus 4.6.
### Example 1 — Find the right CDN datasets
```
Which datasets contain production CDN logs for our edge or delivery layer?
```
Teams often have multiple CDN-related datasets with non-obvious names, causing delays while users search for the right sources or query more than they need to. The hosted MCP server identifies likely datasets first, then surfaces log IDs, collections, and tags needed to scope all later queries correctly.
The result should immediately surface the production CDN and edge-layer datasets in your account — confirming which datasets are actually carrying production CDN traffic before any deeper analysis begins.
### Example 2 — Look for elevated error responses
```
In the last 30 minutes, look through our CDN logs for elevated 5xx responses
and group them by host, path, and status code.
```
**What to look for in CDN logs:**
* Spikes in 5xx status codes
* Concentration on a single hostname, service, or path
* Whether failures are broad or isolated
* Whether only a subset of POPs or edge nodes are affected
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, or low-impact isolated errors.
### Example 3 — Investigate latency regressions
```
Compare CDN response-time metrics for the last hour against the previous hour
and identify the hosts or paths with the largest regression.
```
**What to look for in CDN logs:**
* Increases in origin time or total response time
* Regressions concentrated on one host or endpoint
* Whether the issue appears at the edge or upstream
* Whether the timing aligns with a deploy or traffic change
This is especially useful when users report the site feeling slower but there is no obvious outage. The workflow makes it straightforward to 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
```
Search our CDN logs for cache-related fields and show whether cache miss rates
increased in the last 24 hours.
```
**What to look for in CDN logs:**
* Cache hit vs miss patterns
* Sudden increases in origin fetches
* Path prefixes with poor cache efficiency
* Changes following a release or cache-key adjustment
This type of question is often hard to answer quickly without knowing the exact field names in the dataset. MCP discovers the relevant keys first, then narrows the search — making it easier to see which paths are driving origin load and whether the issue is broad or concentrated.
### Example 5 — Investigate abusive or unusual traffic
```
Use CDN logs from the last 15 minutes to find unusual request-volume spikes
by client IP, user agent, host, and path.
```
**What to look for in CDN logs:**
* Sudden traffic concentration from a small set of IPs
* Repeated hits to a small set of endpoints
* Suspicious user-agent patterns
* Abnormal request mix compared with baseline traffic
This helps identify bot traffic, scraper spikes, attack reconnaissance, or accidental client retry storms. The workflow makes it easier to isolate sudden spikes, see which IPs or paths dominate the burst, and decide quickly whether you are looking at bots, scrapers, or retry storms.
***
## Frequently Asked Questions
**Which login methods are supported for MCP?**
Hosted MCP supports the same login methods available across the rest of Bronto: OAuth, SSO, and Google Social. Your admin controls which are enabled for MCP access via the Authentication settings page.
**Can I restrict which users can connect via MCP?**
Yes. Because MCP access is tied to the same login controls as the rest of the product, disabling a login method for MCP prevents users who rely on that method from completing the MCP OAuth flow, giving admins fine-grained control over who can access Bronto via MCP.
**Do I need to run anything locally?**
No. With the hosted MCP endpoint there is no local server to install or manage. The only exception is if you are using mcp-remote as a bridge for stdio-only clients — but even then, mcp-remote is a lightweight npx invocation rather than a persistent service you need to maintain.
**Which header carries the API key?**
Pass the API key in the `X-BRONTO-API-KEY` request header.
**What is the difference between the US and EU endpoints?**
The endpoints correspond to the data region where your Bronto account is hosted. Use `mcp.us.bronto.io` for US accounts and `mcp.eu.bronto.io` for EU accounts. Connecting to the wrong region will result in an authentication error.
# LLM Observability
Source: https://docs.bronto.io/ai-features/llm-observability
Capture, send, and search OpenTelemetry GenAI telemetry in Bronto — prompts, responses, token usage, model metadata, and tool calls from LLM apps.
LLM observability in Bronto is built on the [OpenTelemetry GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md) — a standard set of `gen_ai.*` attributes for model calls. Any application emitting these attributes on spans or log records gets first-class, searchable prompt/response, token usage, and model fields in Bronto automatically — no Bronto-specific SDK.
This documentation was verified on **July 17, 2026** and uses the latest OpenTelemetry GenAI semantic conventions available on that date. GenAI instrumentation evolves rapidly: current library releases may add the latest conventions while retaining legacy output for compatibility, so the schema emitted by default can vary by library and version.
## Convention version and opt-in
To avoid breaking existing dashboards and queries, instrumentation libraries are not required to switch their default output when a newer Development convention is released. Where supported, enable the current convention with this OpenTelemetry migration opt-in:
```bash theme={"dark"}
export OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental
```
Support for this opt-in is **instrumentation-specific**, not universal. Check the relevant [language instrumentation page](/opentelemetry/overview) and your installed package version before relying on it. Some libraries already emit the current fields by default, some require a different setting, and some still emit an older schema even when this variable is present.
## 1. Instrument your application
Pick your language for the generic `gen_ai.*` mechanics — auto-instrumentation where it exists, manual spans where it doesn't, and the experimental content-capture flags:
GenAI auto-instrumentation for supported Python model clients.
Auto-instrumentation for OpenAI, plus alternatives.
Javaagent-based GenAI coverage (also covers Kotlin).
.NET, Go, Ruby, PHP, Rust, C++, Swift, Erlang/Elixir.
Using a specific framework or cloud GenAI service? These pages cover the OTel setup and the telemetry available from each integration:
`Converse` / `InvokeModel` via botocore instrumentation.
Agent-loop traces with the Strands framework.
Broad provider and framework instrumentation from Traceloop.
Chain instrumentation, with optional LangSmith OTel routing.
Agent and LLM telemetry from Foundry apps, exported straight to Bronto.
## 2. Send it to Bronto
Export through an OTel Collector or directly — see [Connect OpenTelemetry to Bronto](/agent-setup/open-telemetry) or the "Direct export to Bronto" section on any language page.
## 3. Know what you'll see
The most useful `gen_ai.*` attributes:
| Attribute | What it represents | Good for |
| - | - | - |
| `gen_ai.provider.name` | Model provider, e.g. `openai`, `aws.bedrock` | Filtering and grouping by provider |
| `gen_ai.operation.name` | Operation type, e.g. `chat` | Breaking down traffic by operation |
| `gen_ai.request.model` / `gen_ai.response.model` | Requested / actual model served | Comparing usage by model |
| `gen_ai.input.messages` / `gen_ai.output.messages` | Prompt / response payload | Inspecting exact input and generated output |
| `gen_ai.system_instructions` | System prompt or instruction block | Auditing assistant behavior |
| `gen_ai.response.finish_reasons` | Array of finish reasons, e.g. `["stop"]` | Spotting truncation or unusual stops |
| `gen_ai.response.time_to_first_chunk` | Seconds from issuing a streaming request until the first response chunk arrives | Measuring perceived streaming latency on individual spans |
| `gen_ai.usage.input_tokens` / `gen_ai.usage.output_tokens` | Token counts | Cost and usage analysis |
| `gen_ai.usage.cache_read.input_tokens` / `gen_ai.usage.cache_creation.input_tokens` | Provider-managed prompt-cache usage | Understanding cache effectiveness and billed input |
| `gen_ai.usage.reasoning.output_tokens` | Reasoning tokens, when reported | Analyzing reasoning-model usage |
| `gen_ai.response.id` | Provider response ID | Tracing a specific completion |
OpenTelemetry also defines latency metric instruments for aggregate analysis:
| Metric | What it measures | When to use it |
| - | - | - |
| `gen_ai.client.operation.time_to_first_chunk` | Time from issuing a request until the client receives the first response chunk | Client-side histogram for streaming responses only |
| `gen_ai.client.operation.duration` | Total time from issuing a request until the operation completes | Streaming and non-streaming responses; this is the time-to-completion measure for non-streaming responses |
| `gen_ai.server.time_to_first_token` | Time from receiving a request until the model server generates its first output token | Server-side model instrumentation, when available |
Instrumentation does not yet use these boundaries consistently. Traceloop and Strands releases may emit `gen_ai.server.time_to_first_token` from client or framework instrumentation, while Amazon Bedrock publishes a separate CloudWatch `TimeToFirstToken` metric for streaming APIs. Preserve the field emitted by your instrumentation and confirm its unit and measurement boundary before comparing providers.
Content capture is instrumentation-specific and can expose sensitive data. Official Python, JavaScript, and Java instrumentations generally default it off; Traceloop and Strands differ. Prefer a supported span-attribute mode such as Python OpenAI v2's `span_only` so `gen_ai.input.messages` / `gen_ai.output.messages` are queryable on traces. Where content is emitted as OTel log events—or no span-attribute mode exists—emit a structured **log record** correlated by `trace_id`:
```python theme={"dark"}
logger.info(
"chat.completion",
extra={
"gen_ai.provider.name": "openai",
"gen_ai.operation.name": "chat",
"gen_ai.request.model": "gpt-4o-mini",
"gen_ai.input.messages": prompt,
"gen_ai.output.messages": response_text,
"gen_ai.usage.input_tokens": 33,
"gen_ai.usage.output_tokens": 74,
},
)
```
Setting attributes manually on a span (no auto-instrumentation for your provider)? Same idea:
```python theme={"dark"}
with tracer.start_as_current_span("chat gpt-4o-mini") as span:
span.set_attribute("gen_ai.provider.name", "openai")
span.set_attribute("gen_ai.operation.name", "chat")
span.set_attribute("gen_ai.request.model", "gpt-4o-mini")
span.set_attribute("gen_ai.usage.input_tokens", 33)
span.set_attribute("gen_ai.usage.output_tokens", 74)
span.set_attribute("gen_ai.response.finish_reasons", ["stop"])
```
## 4. Search and aggregate
Open [Log Search](https://app.bronto.io/search) and use field predicates to select GenAI calls. For example, select Bedrock calls that report input-token usage:
```sql theme={"dark"}
"$gen_ai.provider.name" = 'aws.bedrock'
AND "$gen_ai.usage.input_tokens" > 0
```
Build token-usage views with `$gen_ai.provider.name` as the group-by field:
| Analysis | Aggregation | Numeric field | Group by |
| - | - | - | - |
| Total input-token usage | **Sum** | `$gen_ai.usage.input_tokens` | `$gen_ai.provider.name` |
| Total output-token usage | **Sum** | `$gen_ai.usage.output_tokens` | `$gen_ai.provider.name` |
| Typical tokens per call | **Median** | `$gen_ai.usage.input_tokens` or `$gen_ai.usage.output_tokens` | `$gen_ai.provider.name` |
| High-token calls | **P75**, **P90**, **P95**, or **P99** | `$gen_ai.usage.input_tokens` or `$gen_ai.usage.output_tokens` | `$gen_ai.provider.name` |
| Prompt-cache activity | **Sum** | `$gen_ai.usage.cache_read.input_tokens` or `$gen_ai.usage.cache_creation.input_tokens` | `$gen_ai.provider.name` |
| Reasoning-token usage | **Sum** | `$gen_ai.usage.reasoning.output_tokens` | `$gen_ai.provider.name` |
Bronto time-series views also provide **Count**, **Average**, **Min**, **Max**, **Sum**, and **Median**; median is the 50th percentile. Dashboard percentile views provide **P75**, **P90**, **P95**, and **P99**. Use a median to compare typical token consumption and the higher percentiles to find providers or models producing unusually large responses.
For streaming latency on spans, apply the same median and percentile views to `$gen_ai.response.time_to_first_chunk`, grouped by `$gen_ai.provider.name`. If your instrumentation exports metrics, chart `gen_ai.client.operation.time_to_first_chunk` for client-observed streaming latency, `gen_ai.client.operation.duration` for total completion time, or `gen_ai.server.time_to_first_token` for model-server TTFT.
`gen_ai.response.finish_reasons` remains an OpenTelemetry array attribute. Bronto indexes its first element as `$gen_ai.response.finish_reasons.0`; `.0` is not part of the semantic-convention name and is not normally added by the Collector.
See [Visualizations](/Search-and-Visualize/Log-Visualization) for building these views into a dashboard.
## References
* [Connect OpenTelemetry to Bronto](/agent-setup/open-telemetry)
* [OpenTelemetry GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md)
* [OpenTelemetry GenAI metric conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-metrics.md)
* [Log Search](/Search-and-Visualize/Log-Search)
* [Custom Parser](/core-features/custom-parser)
# Local MCP Server
Source: https://docs.bronto.io/ai-features/local-mcp
Run the open-source Bronto MCP server locally with Python and connect Claude Code or any MCP agent to your datasets, API keys, and search tools.
The local MCP server is open source and available on
[GitHub](https://github.com/brontoio/bronto-mcp-server). If you prefer not
to run infrastructure locally, see the [Hosted MCP Server](./hosted-mcp)
instead.
## Overview
The Bronto MCP server is a local Python server that exposes Bronto's log-dataset and search capabilities to any MCP-compatible AI agent. Dataset search covers logs; metrics and traces are not stored in datasets or collections and are viewed in their dedicated explorers. Once running, it gives agents the tools to answer questions against your live log data, for example:
> *"Can you provide some log events from datasets in the ingestion collection, except for the ones related to garbage collection? The data should be between 2025-05-10 16:05:45 and 2025-05-10 16:25:05."*
The server has been tested with Claude Code and should work with any agent that supports the MCP protocol.
***
## Prerequisites
* Python 3 installed on your machine
* A Bronto API key (see [API Keys](../Account-Management/API-Keys))
* Your Bronto API endpoint URL
***
## Installation
Check out the project from GitHub:
```bash theme={"dark"}
git clone https://github.com/brontoio/bronto-mcp-server.git
cd bronto-mcp-server
```
Create a Python virtual environment at the root of the project:
```bash theme={"dark"}
python3 -m venv env
```
Install the required packages into the virtual environment:
```bash theme={"dark"}
env/bin/pip install -r requirements.txt
```
***
## Configuration
The MCP server is configured using environment variables. Set both before starting the server.
| Variable | Description | Example |
| - | - | - |
| `BRONTO_API_KEY` | A valid Bronto API key | `68ba7ae3-...` |
| `BRONTO_API_ENDPOINT` | The Bronto API endpoint for your region | `https://api.eu.bronto.io` |
| Region | API Endpoint |
| - | - |
| US | `https://api.us.bronto.io` |
| EU | `https://api.eu.bronto.io` |
***
## Starting the Server
Run the following command from the root of the project, substituting your API key and endpoint:
```bash theme={"dark"}
BRONTO_API_KEY= \
BRONTO_API_ENDPOINT=https://api.eu.bronto.io \
PYTHONPATH=src/main/ \
env/bin/python src/main/brmcpserver/main.py
```
The server starts on `http://localhost:8000` by default.
Keep your terminal session open while using the MCP server. Closing it will
stop the server and disconnect any connected agents.
***
## Connecting Claude Code
Once the server is running, register it with Claude Code using the following command:
```bash theme={"dark"}
claude mcp add --transport http bronto http://localhost:8000
```
This makes the Bronto MCP server available for your current project folder. To make it available globally across all projects, add the `--scope user` flag:
```bash theme={"dark"}
claude mcp add --transport http bronto http://localhost:8000 --scope user
```
Full documentation on managing MCP servers in Claude Code is available at
[docs.anthropic.com](https://docs.anthropic.com/en/docs/claude-code/mcp).
### Verify the connection
Launch Claude Code and run the `/mcp` command to confirm the Bronto MCP server is available and connected:
```
/mcp
──────────────────────────────────────
Manage MCP servers
1 servers Local MCPs
❯ bronto · ✓ connected
```
***
## Capabilities
Once connected, the server exposes the following tools to your AI agent.
| Tool | Description | When to use |
| - | - | - |
| `get_datasets` | Fetches all datasets in your Bronto account, including name, collection, dataset ID, and tags. Tags such as `description`, `service`, `team`, and `environment` are especially useful for understanding dataset contents. | When you need to discover what data sources are available, or find datasets by owner or environment. |
| `get_datasets_by_name` | Fetches a specific dataset by its exact name and collection name. A dataset is uniquely identified by the combination of both. | When you already know the dataset and collection name and need its log ID or tag metadata. |
| `get_keys` | Returns all field names present in a specific dataset, identified by its log ID. | To inspect a single dataset's schema before querying or filtering it. |
| `get_all_datasets_keys` | Returns a map of dataset IDs to their field names across all datasets. | To identify which datasets contain a particular field, or to determine the exact field name from a description. |
| `get_key_values` | Returns the available values for a specific field in a specific dataset. | To discover valid field values and build precise filters before running a search. |
| `search_logs` | Searches raw events across one or more datasets over a time range. Supports SQL-style `WHERE` filters, multiple dataset IDs, and returns full events including the `@raw` field. | Event-level investigations where you need to inspect individual entries — for example, finding errors or warnings in a specific service. |
***
## Frequently Asked Questions
**Which AI agents are supported?**
The server implements the MCP protocol and should work with any MCP-compatible agent. It has been tested with Claude Code.
**Can I make the server available across all my projects?**
Yes. Add `--scope user` when registering the server with Claude Code and it will be available globally rather than only for the current project folder.
**Where do I find my API key?**
API keys can be created and managed in **Settings → API Keys** in the Bronto UI. See [API Keys](../Account-Management/API-Keys) for details.
**What is the difference between the local server and the hosted MCP server?**
The local server runs on your machine and requires Python, a virtual environment, and a running terminal session. The [hosted MCP server](./hosted-mcp) is managed by Bronto — there is nothing to install or run locally. For most teams the hosted option is simpler; the local server is useful if you need to run in an air-gapped environment or want to inspect or modify the server code directly.
# Microsoft Foundry observability with OpenTelemetry
Source: https://docs.bronto.io/ai-features/microsoft-foundry
Send logs, metrics, and traces from Microsoft Foundry apps and agents to Bronto over OTLP — gen_ai spans, token usage, tool calls, and multi-agent traces.
Apps and agents built on [Microsoft Foundry](https://learn.microsoft.com/en-us/azure/foundry/) (formerly Azure AI Foundry) are already OpenTelemetry-instrumented: the supported SDKs and agent frameworks emit spans following the [OpenTelemetry GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md) — model calls, token usage, tool invocations, and multi-agent task hierarchies.
Because that telemetry is standard OpenTelemetry, one initialisation block sends **logs, metrics, and traces** from your Foundry app straight to Bronto over OTLP/HTTP — no Bronto-specific SDK involved.
This page covers the app-level signal. For general Azure platform, diagnostic, and activity logs from the same subscription, see [Ingesting Azure Data into Bronto](/integrations/azure-overview); for the attributes Bronto surfaces and how to search them, see [LLM Observability](/ai-features/llm-observability).
GenAI instrumentation moves quickly. The package names, environment variables, and default attribute shapes below reflect the instrumentation available at the time of writing — confirm them against the release you deploy, and inspect a real trace before building version-sensitive dashboards.
## Prerequisites
* A Microsoft Foundry project with an instrumented app or agent
* Python 3.10 or later, and `pip`
* A Bronto ingestion API key — see [API Keys](/Account-Management/API-Keys#create-a-new-api-key) for how to create one with ingestion permissions
* Your Bronto region: `eu` or `us`
* A service name and namespace for the app's telemetry. These resource attributes identify all three signals; for logs only, `service.name` selects the dataset and `service.namespace` selects the collection. Metrics and traces do not appear in datasets or collections.
## Choose an OpenTelemetry-native instrumentation
Every framework in the Foundry ecosystem has more than one way to produce GenAI telemetry: vendor distributions such as [OpenLLMetry](/integrations/openllmetry) or OpenInference wrap the framework in their own SDK, while the OpenTelemetry-native route uses either upstream OpenTelemetry instrumentation or the telemetry the framework emits itself.
This page assumes the OpenTelemetry-native route. It keeps `gen_ai.*` attributes aligned with the upstream semantic conventions, puts no vendor SDK in the request path, and means the exporter configuration below is the only Bronto-specific code you write.
| Framework | OpenTelemetry-native route | Documentation |
| - | - | - |
| OpenAI SDK / Azure OpenAI | `opentelemetry-instrumentation-openai-v2`, an upstream OpenTelemetry contrib package | [opentelemetry-python-contrib](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation-genai/opentelemetry-instrumentation-openai-v2) |
| Semantic Kernel | Emits OpenTelemetry traces, metrics, and logs itself — no instrumentation package, but its GenAI diagnostics are behind an experimental switch | [Observability in Semantic Kernel](https://learn.microsoft.com/en-us/semantic-kernel/concepts/enterprise-readiness/observability/) |
| Microsoft Agent Framework | Emits OpenTelemetry telemetry itself, enabled through the framework's own observability setup | [Agent Framework observability](https://learn.microsoft.com/en-us/agent-framework/user-guide/observability/) |
| OpenAI Agents SDK | Its own tracing layer with pluggable processors; bridge it to OpenTelemetry with an OTel trace processor | [OpenAI Agents SDK tracing](https://openai.github.io/openai-agents-python/tracing/) |
| LangChain / LangGraph | OTLP export, either via an OpenTelemetry instrumentation package or LangSmith's OTLP endpoint routing | [LangChain](/integrations/langchain), [LangSmith OpenTelemetry](https://docs.smith.langchain.com/observability/how_to_guides/opentelemetry) |
| Foundry Agent Service (`azure-ai-agents`) | An instrumentor shipped with the Azure SDK, covering agent runs and tool calls | [Observability in generative AI](https://learn.microsoft.com/en-us/azure/foundry/concepts/observability) |
Whichever you choose, everything below is identical — the exporter, the endpoints, the credential, the resource attributes — because all of these emit through the OpenTelemetry providers you configure.
Verify the exact package name, import path, and enablement call for your framework against its own documentation before copying this table into a runbook. Only the OpenAI SDK row is exercised by the code samples below.
## Install the SDK and instrumentation
```bash theme={"dark"}
pip install \
opentelemetry-sdk \
opentelemetry-exporter-otlp-proto-http \
opentelemetry-instrumentation-openai-v2
```
Swap the last package for the instrumentation your framework uses, or drop it entirely for a framework that emits OpenTelemetry itself.
## Endpoints and authentication
Bronto has one OTLP/HTTP endpoint per signal, per region. Every request carries the API key in the `x-bronto-api-key` header.
| Signal | EU region | US region |
| - | - | - |
| Logs | `https://ingestion.eu.bronto.io/v1/logs` | `https://ingestion.us.bronto.io/v1/logs` |
| Metrics | `https://ingestion.eu.bronto.io/v1/metrics` | `https://ingestion.us.bronto.io/v1/metrics` |
| Traces | `https://ingestion.eu.bronto.io/v1/traces` | `https://ingestion.us.bronto.io/v1/traces` |
The SDK appends `/v1/logs`, `/v1/metrics`, and `/v1/traces` to `OTEL_EXPORTER_OTLP_ENDPOINT` automatically, so configure the **base** URL and let one setting cover all three signals:
```bash theme={"dark"}
export OTEL_EXPORTER_OTLP_ENDPOINT="https://ingestion..bronto.io" # eu or us
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_EXPORTER_OTLP_HEADERS="x-bronto-api-key="
export OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE="delta"
# Shared signal identity; these select the dataset and collection for logs only.
export OTEL_SERVICE_NAME="foundry-agent"
export OTEL_RESOURCE_ATTRIBUTES="service.namespace=ai-apps,deployment.environment=production"
```
## Configure logs, metrics, and traces
Add this module to your project and call `configure_bronto_telemetry()` once, at the very top of your entrypoint — before the instrumented client is constructed and before your first log statement or span.
```python otel_bronto.py theme={"dark"}
import logging
from opentelemetry import metrics, trace
from opentelemetry._logs import set_logger_provider
from opentelemetry.exporter.otlp.proto.http._log_exporter import OTLPLogExporter
from opentelemetry.exporter.otlp.proto.http.metric_exporter import OTLPMetricExporter
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk._logs import LoggerProvider, LoggingHandler
from opentelemetry.sdk._logs.export import BatchLogRecordProcessor
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
def configure_bronto_telemetry() -> tuple[TracerProvider, MeterProvider, LoggerProvider]:
# Reads OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES — one identity for
# all three signals, which is what makes them correlate in Bronto.
resource = Resource.create()
# Traces — GenAI spans from your instrumentation land here.
tracer_provider = TracerProvider(resource=resource)
tracer_provider.add_span_processor(BatchSpanProcessor(OTLPSpanExporter()))
trace.set_tracer_provider(tracer_provider)
# Metrics — GenAI metric instruments plus anything your app records.
reader = PeriodicExportingMetricReader(OTLPMetricExporter())
meter_provider = MeterProvider(resource=resource, metric_readers=[reader])
metrics.set_meter_provider(meter_provider)
# Logs — bridges the standard logging module, so structured `extra=` fields
# arrive as queryable attributes and existing log statements are unchanged.
logger_provider = LoggerProvider(resource=resource)
logger_provider.add_log_record_processor(BatchLogRecordProcessor(OTLPLogExporter()))
set_logger_provider(logger_provider)
logging.getLogger().addHandler(LoggingHandler(logger_provider=logger_provider))
logging.getLogger().setLevel(logging.INFO)
return tracer_provider, meter_provider, logger_provider
```
The exporters take no arguments because they read the endpoint, protocol, and headers from the environment. To keep configuration in code instead, pass the **full** signal path to each one — `OTLPSpanExporter(endpoint="https://ingestion..bronto.io/v1/traces", headers={"x-bronto-api-key": ...})`, and likewise for logs and metrics.
Enable instrumentation after the providers are registered, and build your client after that:
```python app.py theme={"dark"}
import os
from otel_bronto import configure_bronto_telemetry
tracer_provider, meter_provider, logger_provider = configure_bronto_telemetry()
# Instrumentation attaches to the registered providers.
from opentelemetry.instrumentation.openai_v2 import OpenAIInstrumentor
OpenAIInstrumentor().instrument()
from openai import AzureOpenAI
client = AzureOpenAI(
azure_endpoint=os.environ["AZURE_OPENAI_ENDPOINT"],
api_key=os.environ["AZURE_OPENAI_API_KEY"],
api_version="",
)
response = client.chat.completions.create(
model="",
messages=[{"role": "user", "content": "Summarise today's incidents."}],
)
```
Any log emitted inside an active span automatically carries that span's `trace_id` and `span_id`, so you can jump from a log line to the model call that produced it with no manual context propagation.
**Short-lived processes.** The batch processors and the metric reader export on a timer, so a script, job, or evaluation run that exits immediately can drop its last batch. Shut the providers down before exit:
```python theme={"dark"}
tracer_provider.shutdown()
meter_provider.shutdown()
logger_provider.shutdown()
```
**Framework spans without code changes.** Install the `opentelemetry-instrumentation-` packages for your web framework and HTTP client and run your app with `opentelemetry-instrument python app.py`. The CLI configures the providers itself from the same `OTEL_*` variables above, so use it *instead of* `otel_bronto.py` — and add `opentelemetry-instrumentation-logging` so standard-library logs are still bridged. See [Python zero-code instrumentation](https://opentelemetry.io/docs/zero-code/python/).
## Capturing prompts and responses
Two environment variables control whether the text of prompts and completions is captured, and in what shape:
```bash theme={"dark"}
export OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=span_only
export OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental
```
* `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT` turns content capture on. It is **off by default** in the official instrumentations. `span_only` writes content to `gen_ai.input.messages` and `gen_ai.output.messages` as span attributes, which Bronto surfaces as searchable trace fields. The legacy `true` setting emits content as separate log records correlated by `trace_id`, where it is not queryable on the span itself — prefer `span_only` where your instrumentation supports it. Either way the content reaches Bronto, because the setup above exports logs as well as traces.
* `OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental` opts into the current GenAI convention shape. Instrumentation libraries keep emitting an older schema by default so they don't break existing dashboards, and support for this opt-in is **instrumentation-specific** — some libraries already emit the current fields, some need a different setting, some ignore it entirely.
Exercise caution when capturing prompts and responses — depending on the nature of your application they may include sensitive data.
Semantic Kernel and Microsoft Agent Framework do not use `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT` — each has its own switch for sensitive-data capture. See their observability documentation, linked in the table above, for the exact variable names.
## What you'll see in Bronto
### Traces
One app or agent invocation becomes one trace with nested spans:
| Span | Source | Notes |
| - | - | - |
| Request / invocation | Your app or web framework instrumentation | Root span for the request |
| Agent or task span | Agent framework | One per agent step; multi-agent runs nest handoffs beneath the orchestrator |
| `chat` | GenAI instrumentation | One per model call, carrying `gen_ai.*` attributes |
| Tool call | Agent framework | One child span per tool the agent invokes |
The attributes worth knowing on the model spans:
| Attribute | Example | Notes |
| - | - | - |
| `gen_ai.provider.name` | `openai` | Provider — filter and group by this |
| `gen_ai.operation.name` | `chat` | Operation type |
| `gen_ai.request.model` / `gen_ai.response.model` | `gpt-4o-mini` | Requested model / model actually served |
| `gen_ai.usage.input_tokens` / `gen_ai.usage.output_tokens` | `412`, `173` | Numeric — sum, average, and chart these |
| `gen_ai.response.finish_reasons.0` | `stop` | Bronto indexes the first element of the array attribute |
| `gen_ai.tool.name` / `gen_ai.tool.call.id` | `get_weather` | On tool-call spans, where the framework emits them |
| `gen_ai.input.messages` / `gen_ai.output.messages` | — | Only present when content capture is enabled |
Open [Explore Traces](/tracing/explore-traces) and filter by the `service.name` you set. Open the newest trace and confirm the nesting above: the invocation at the root, a `chat` span per model call, and tool-call spans beneath it.
### Metrics
Where your instrumentation implements the [GenAI metric conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-metrics.md), the meter provider exports aggregate instruments alongside the spans:
| Metric | What it measures |
| - | - |
| `gen_ai.client.operation.duration` | Total time from issuing a request until the operation completes |
| `gen_ai.client.token.usage` | Token usage per call, as a histogram |
| `gen_ai.client.operation.time_to_first_chunk` | Client-observed streaming latency |
| `gen_ai.server.time_to_first_token` | Model-server time to first token, where the server reports it |
Open **Metric Explorer** and select a recently emitted metric to confirm it carries the same `service.name`. Coverage of these instruments varies by library and version — spans are the reliable source of token counts, metrics the cheaper source of aggregate latency. See [Explore Metrics](/metrics/explore-metrics) for building views.
### Logs
Application logs from the bridged `logging` module arrive with `trace_id` and `span_id` attached, so they line up with the trace that produced them. Log structured GenAI fields with `extra=` and they become queryable attributes:
```python theme={"dark"}
import logging
log = logging.getLogger(__name__)
log.info(
"agent.result",
extra={
"event.name": "agent.result",
"gen_ai.request.model": "",
"session.id": session_id,
},
)
```
Avoid printf-style logging (`log.info("tokens=%s", n)`) for data you want to query — that produces a flat message string rather than structured fields.
### Search and aggregate
Bronto indexes attributes with a `$` prefix, so query them in [Log Search](https://app.bronto.io/search) as field predicates:
```sql theme={"dark"}
"$gen_ai.provider.name" = 'openai'
AND "$gen_ai.usage.input_tokens" > 0
```
```sql theme={"dark"}
"$gen_ai.output.messages" ILIKE '%rate limit%'
```
Token usage is numeric, so it aggregates: **Sum** of `$gen_ai.usage.output_tokens` grouped by `$gen_ai.request.model` gives per-model consumption; the **P95** of the same field finds unusually large responses. See [LLM Observability](/ai-features/llm-observability) for the full set of aggregations and [Visualizations](/Search-and-Visualize/Log-Visualization) for building them into a dashboard.
## Troubleshooting
| Symptom | Likely cause |
| - | - |
| `401` / `403` from the exporter | Header name must be exactly `x-bronto-api-key`, and the key needs ingestion permissions. In `OTEL_EXPORTER_OTLP_HEADERS`, use `key=value` with no quotes or spaces around the `=`. |
| `404` from the exporter | Path mismatch. `OTEL_EXPORTER_OTLP_ENDPOINT` takes the **base** URL and the SDK appends `/v1/logs`, `/v1/metrics`, `/v1/traces`; an explicit `endpoint=` argument takes the **full** signal path. |
| Connection or protocol errors | Use the `opentelemetry-exporter-otlp-proto-http` exporters with `OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf`. Bronto's ingestion endpoints are OTLP/HTTP on port `443`; the gRPC exporter will not reach them. |
| Exports succeed but nothing appears | Wrong region — an EU key against `ingestion.us.bronto.io` (or the reverse) will not land in your account. Check the region of the endpoint against the region of the key. |
| Traces arrive, metrics don't | Exponential histograms are rejected. Leave the default explicit-bucket aggregation, and set `OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=delta`. See [Send Metrics to Bronto](/metrics/send-metrics). |
| No spans at all | Instrumentation was enabled before the providers were registered, the instrumented client was constructed before either, or the instrumentation package isn't installed. Register the providers first, instrument second, build clients third. |
| Signals appear in long runs but not in jobs | The process exits before the batch processors flush. Call `shutdown()` on each provider before exit. |
| Spans arrive, prompts and responses are empty | Content capture is off by default. See [Capturing prompts and responses](#capturing-prompts-and-responses) — and confirm your framework honours that variable. |
| Attribute names don't match this page | Your instrumentation is emitting an older convention. Try `OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental`, and inspect a real trace to see what the installed version actually emits. |
## Node.js and TypeScript
The pattern is the same: build the three providers with the OTLP/HTTP exporters from `@opentelemetry/exporter-trace-otlp-proto`, `@opentelemetry/exporter-metrics-otlp-proto`, and `@opentelemetry/exporter-logs-otlp-proto`, pointed at the same base endpoint with the same `x-bronto-api-key` header, then register your framework's instrumentation. See [Send Node.js logs, metrics, and traces to Bronto](/opentelemetry/nodejs) for the full setup.
## References
* [LLM Observability](/ai-features/llm-observability)
* [OpenTelemetry on Azure](/integrations/azure-otel)
* [Send Python logs, metrics, and traces to Bronto](/opentelemetry/python)
* [Send Metrics to Bronto](/metrics/send-metrics)
* [Microsoft Foundry documentation](https://learn.microsoft.com/en-us/azure/foundry/)
* [Observability in generative AI](https://learn.microsoft.com/en-us/azure/foundry/concepts/observability)
* [OpenTelemetry GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md)
* [OpenTelemetry GenAI metric conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-metrics.md)
***
For assistance or questions, contact [support@bronto.io](mailto:support@bronto.io).
# n8n Integration
Source: https://docs.bronto.io/ai-features/n8n
Connect Bronto to n8n workflows to query logs, trigger automations on observability data, and build AI-assisted incident response pipelines.
[n8n](https://n8n.io) is an open-source workflow automation platform that lets you connect APIs, services, and AI agents without writing glue code. The Bronto n8n node gives workflows direct access to your log data — so you can query, filter, aggregate, and act on observability data from inside any n8n pipeline.
Together, Bronto and n8n let you close the loop between your observability data and the rest of your stack: pull log context into incident tickets, route anomaly data to AI agents, enrich alerts with search results, or schedule regular health-check queries without maintaining custom scripts.
## Use cases
### Incident response automation
Trigger an n8n workflow from a Bronto monitor alert webhook. The workflow queries Bronto for recent errors or anomalies around the alert window, formats a summary, and creates a ticket in Linear, Jira, or PagerDuty — with log context already attached.
### AI-assisted log investigation
Use the Bronto node as an [AI tool node](https://docs.n8n.io/advanced-ai/examples/understand-tools/) inside an n8n AI agent workflow. The agent calls Bronto search at runtime to look up relevant logs, then synthesizes findings and posts a summary to Slack or email.
### Scheduled health checks
Run a recurring n8n workflow that queries Bronto for error rates, latency distributions, or specific log patterns on a schedule. Compare results against thresholds and notify your team when something drifts.
### Log-driven data pipelines
Extract structured fields from Bronto log events and push them to a data warehouse, spreadsheet, or analytics tool. Useful for compliance exports, capacity planning, or building custom dashboards outside of Bronto.
### Cross-tool correlation
Combine Bronto log data with data from other systems in the same workflow — query deployment events from GitHub, pull error counts from Bronto, and correlate them to detect regressions after releases.
## Minimal install
The Bronto node is a verified community node hosted on npm and the n8n community node registry.
**Requirements**
* n8n v0.187.0 or later (self-hosted or n8n Cloud)
* Instance owner access to install community nodes
**Install from the n8n UI**
1. Open **Settings → Community nodes**
2. Click **Install a community node**
3. Enter the package name: `n8n-nodes-bronto`
4. Confirm and restart n8n if prompted
**Install manually (self-hosted)**
```bash theme={"dark"}
cd /usr/local/lib/node_modules/n8n # adjust to your n8n install path
npm install n8n-nodes-bronto
```
Source code and issue tracker: [github.com/brontoio/n8n-nodes-bronto](https://github.com/brontoio/n8n-nodes-bronto)
## Credential setup
After installing the node, create a **Bronto API** credential in n8n:
1. Go to **Credentials → Add credential → Bronto API**
2. Enter your Bronto API key — create one under **Account Management → API Keys** with search permissions
3. Select your region: **EU** or **US**
The region determines the base URL the node uses (`https://api.eu.bronto.io` or `https://api.us.bronto.io`).
## Node reference
The Bronto node has a single **Search** operation that queries the Bronto search API.
### Source
Choose how to identify which logs to search:
| Source type | Description |
| - | - |
| **Logs** | Select one or more log datasets from a dropdown populated from your Bronto account |
| **Tags** | Filter by tag key:value pairs (e.g. `env:production service:api`) |
### Search parameters
| Parameter | Description | Example |
| - | - | - |
| **Time range** | Relative time window | `Last 1 hour`, `Last 2 days` |
| **Where** | SQL-like filter expression | `level:error AND duration_ms>2000` |
| **Select** | Fields or aggregate functions to return | `*, @raw` or `count(), avg(duration_ms)` |
| **Groups** | Fields to group aggregate results by | `service, region` |
| **Limit** | Maximum number of results (1–6666) | `50` |
### Additional options
| Option | Description |
| - | - |
| **From / To timestamp** | Absolute time bounds in Unix milliseconds |
| **Most recent first** | Sort order — newest events first (default: true) |
| **Number of slices** | Time buckets for time-series aggregate queries |
| **Paginate** | Automatically follow `next_page_url` to fetch all matching results |
### Output
The node maps the API response to n8n items in one of three shapes depending on the query:
* `events[]` — individual log events from a raw search
* `groups[]` — grouped rows from an aggregate query
* `result[]` — other result arrays
Each item is available to downstream nodes as a standard n8n JSON object.
## Use as an AI tool node
The Bronto node supports n8n's `usableAsTool` flag, meaning it can be connected directly to an AI agent node without wrapping. When used this way, the agent decides at runtime when and how to call the Bronto search — passing a query, time range, and filter based on context from the conversation or workflow.
This is the recommended pattern for AI-assisted log investigation workflows where the query is not known in advance.
# OpenClaw Integration
Source: https://docs.bronto.io/ai-features/openclaw
Instrument OpenClaw agents with OpenTelemetry to send AI agent logs, metrics, and traces to Bronto for observability, debugging, and cost tracking.
## Overview
[OpenClaw](https://openclaw.ai) is a self-hosted personal AI assistant.
Its gateway includes a built-in [`diagnostics-otel`](https://docs.openclaw.ai/gateway/opentelemetry) plugin that exports OpenTelemetry logs, metrics, and traces over OTLP/HTTP.
Pointed at Bronto, every model call your assistant makes lands in Bronto with full token, model, provider, and (optionally) prompt/response context.
You can ship telemetry to Bronto in one of two ways:
1. **Through an OpenTelemetry Collector that forwards to Bronto** *(recommended)*. More reliable and easier to debug when something doesn't show up in Bronto.
2. **Directly from the `diagnostics-otel` plugin to Bronto's OTLP endpoints**. Fewer moving parts, but harder to troubleshoot.
This page applies wherever you run the OpenClaw gateway — Docker, a VM, or a managed host — and does not assume any particular cloud.
If you've tried the direct route and don't see data in Bronto, use the OpenTelemetry Collector path.
* The Collector batches and retries on OpenClaw's behalf
* Its `debug` exporter prints every signal it receives. This is a reliable way to tell whether a missing signal is OpenClaw failing to emit it or Bronto-side configuration (API key, region, headers) being wrong.
* The Collector logs failures with full details so network-level problems surface immediately.
## Before you start
You will need:
* A running OpenClaw gateway. The configuration is the same wherever the gateway runs - only the path to `openclaw.json` and `~/.openclaw/.env` differs.
* A Bronto API key — see [API Keys](/Account-Management/API-Keys).
* Your Bronto region (`eu` or `us`) — see [Bronto Ingestion Endpoints](/getting-started/bronto-endpoints).
The `diagnostics-otel` plugin must be installed and enabled on the gateway:
```bash theme={"dark"}
openclaw plugins install clawhub:@openclaw/diagnostics-otel
openclaw plugins enable diagnostics-otel
```
## Recommended: OpenTelemetry Collector
### 1. Run a Collector next to OpenClaw
Install the OpenTelemetry Collector on the same host as the OpenClaw gateway, or anywhere the gateway can reach over the network. The [OpenTelemetry Collector installation docs](https://opentelemetry.io/docs/collector/installation/) cover Docker, Linux packages, Homebrew, Windows, and Kubernetes; see also [Connect OpenTelemetry Collector to Bronto](/agent-setup/open-telemetry) for richer Bronto-specific configuration.
Use the config below as your starting point.
* It accepts OTLP/HTTP on port `4318`
* It prints every received signal to the Collector's standard output via the `debug` exporter
* It forwards everything to Bronto.
The `debug` exporter is included intentionally, as it is a useful tool for confirming that signals are reaching the Collector, and what they look like.
**Recommended for initial setup**, but remove it from the `exporters` block and from each pipeline once telemetry is flowing reliably into Bronto.
```yaml otel-collector-config.yaml theme={"dark"}
receivers:
otlp:
protocols:
http:
endpoint: "0.0.0.0:4318"
processors:
batch:
exporters:
debug:
verbosity: detailed
otlphttp/brontotraces:
traces_endpoint: "https://ingestion..bronto.io/v1/traces"
compression: gzip
headers:
x-bronto-api-key:
otlphttp/brontometrics:
metrics_endpoint: "https://ingestion..bronto.io/v1/metrics"
compression: gzip
headers:
x-bronto-api-key:
otlphttp/brontologs:
logs_endpoint: "https://ingestion..bronto.io/v1/logs"
compression: gzip
headers:
x-bronto-api-key:
x-bronto-dataset: openclaw
x-bronto-collection: openclaw-demo
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [debug, otlphttp/brontotraces]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [debug, otlphttp/brontometrics]
logs:
receivers: [otlp]
processors: [batch]
exporters: [debug, otlphttp/brontologs]
```
Replace `` with `eu` or `us` and `` with your Bronto API key. Per-signal endpoints (`traces_endpoint`, `logs_endpoint`, `metrics_endpoint`) are required because Bronto's OTLP host does not follow the default OTLP path convention.
The dataset and collection headers are intentionally present only on the logs exporter. OpenClaw logs appear in the `openclaw-demo/openclaw` dataset, metrics appear in the Metric Explorer, and traces appear in Explore Traces. Metrics and traces do not create datasets or collections.
### 2. Point OpenClaw at the Collector
Add a `diagnostics` block at the **top level** of your `~/.openclaw/openclaw.json`, alongside the existing top-level keys (`gateway`, `agents`, `models`, `plugins`, etc..., not nested inside any of them).
```json openclaw.json theme={"dark"}
{
// ...other top-level keys: "gateway", "agents", "models", "plugins", etc.
"diagnostics": {
"enabled": true,
"otel": {
"enabled": true,
"endpoint": "http://localhost:4318",
"protocol": "http/protobuf",
"serviceName": "openclaw-gateway",
"captureContent": true,
"traces": true,
"logs": true,
"metrics": true,
"sampleRate": 1,
"flushIntervalMs": 10000
}
}
// ...
}
```
Set `endpoint` to wherever the Collector's OTLP/HTTP receiver is reachable from the gateway.
`http://localhost:4318` is correct when both run on the same host.
If they run as separate containers on a shared Docker network, use the Collector's service or container name instead (e.g. `http://otel-collector:4318`).
Add the following to your `~/.openclaw/.env`:
```bash ~/.openclaw/.env theme={"dark"}
OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental
OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=delta
```
`OTEL_SEMCONV_STABILITY_OPT_IN` opts the gateway in to the stable GenAI semantic-convention attributes (`gen_ai.request.model`, `gen_ai.usage.input_tokens`, etc.).
It is an environment variable and cannot be set in `openclaw.json`.
Without it, spans carry only OpenClaw's own `openclaw.*` attributes.
Restart the gateway to pick up the new configuration. Use whichever of the following matches your setup:
```bash theme={"dark"}
openclaw gateway restart
```
```bash theme={"dark"}
docker compose restart openclaw-gateway
```
```bash theme={"dark"}
docker restart
```
```bash theme={"dark"}
# systemd
systemctl restart openclaw
# launchd (macOS)
launchctl kickstart -k "gui/$(id -u)/openclaw"
# pm2
pm2 restart openclaw
```
### 3. Confirm signals are flowing
Send your OpenClaw assistant a message, then watch the Collector's output. The `debug` exporter writes to the Collector's standard output, so where you find that depends on how you launched it:
* **Docker** — `docker logs -f `.
* **Foreground terminal** — if you launched the Collector binary directly in a shell, debug lines appear in that terminal.
* **systemd** — `journalctl -u otelcol -f` (or `otelcol-contrib -f` for the contrib build).
* **Other supervisors** — wherever you redirected the Collector's stdout / stderr (for example `/var/log/otelcol/otelcol.log`).
In the output, every signal type appears with its own line prefix:
| Prefix | Signal |
| - | - |
| `Span #` | Trace span |
| `LogRecord #` | Log record |
| `Metric #` | Metric |
If you see all three after sending a message to the assistant, OpenClaw is emitting telemetry correctly. The next thing to verify is that it has reached Bronto:
* **Traces** — open [Traces](/tracing/explore-traces) and check that traces for the openclaw-gateway service are visible.
* **Logs** — open [Log Search](/Search-and-Visualize/Log-Search) and check for data in the `openclaw-demo/openclaw` dataset.
If signals appear in the Collector output but not in Bronto.
If they do not appear in the Collector output at all, the failure is upstream of the Collector (plugin not enabled, gateway not restarted, no model activity).
See [Troubleshooting](#troubleshooting)
## Alternative: export directly from OpenClaw to Bronto
If you cannot run a Collector alongside the gateway, the `diagnostics-otel` plugin can send to Bronto's OTLP endpoints directly. This works, but it gives limited visibility so debugging is harder.
### 1. Configure `openclaw.json`
Add a `diagnostics` block at the **top level** of your `~/.openclaw/openclaw.json`. Authenticate with the `x-bronto-api-key` header.
```json openclaw.json theme={"dark"}
{
// ...other top-level keys: "gateway", "agents", "models", "plugins", etc.
"diagnostics": {
"enabled": true,
"otel": {
"enabled": true,
"endpoint": "https://ingestion.eu.bronto.io",
"tracesEndpoint": "https://ingestion.eu.bronto.io/v1/traces",
"logsEndpoint": "https://ingestion.eu.bronto.io/v1/logs",
"metricsEndpoint": "https://ingestion.eu.bronto.io/v1/metrics",
"protocol": "http/protobuf",
"serviceName": "openclaw-gateway",
"headers": {
"x-bronto-api-key": "${BRONTO_API_KEY}",
"x-bronto-dataset": "openclaw",
"x-bronto-collection": "openclaw-demo"
},
"captureContent": true,
"traces": true,
"logs": true,
"metrics": true,
"sampleRate": 1,
"flushIntervalMs": 10000
}
}
}
```
Replace `eu` with `us` if your account is in the US region. The `${BRONTO_API_KEY}` interpolation keeps the secret out of committed config — OpenClaw resolves the variable at load time and fails fast if it is unset.
The plugin applies its `headers` object to every signal. Bronto uses `x-bronto-dataset` and `x-bronto-collection` only for the logs request; the same headers do not route metrics or traces into that dataset or collection.
OpenClaw's `logs` toggle defaults to `false`, so set `"logs": true` to send log records alongside traces.
### 2. Configure `~/.openclaw/.env`
```bash ~/.openclaw/.env theme={"dark"}
BRONTO_API_KEY=YOUR_API_KEY
OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental
OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=delta
```
| Variable | Purpose |
| - | - |
| `BRONTO_API_KEY` | Resolved into the `x-bronto-api-key` header at gateway load. |
| `OTEL_SEMCONV_STABILITY_OPT_IN` | Opts in to stable GenAI semantic-convention attributes (`gen_ai.*`). Required for most LLM-observability tooling. Cannot be set in `openclaw.json`. |
| `OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE` | Required by Bronto. |
### 3. Restart and verify
Restart the gateway, then send the assistant a message and check Bronto:
* **Traces** — open [Traces](/tracing/explore-traces) and check that traces for the openclaw-gateway service are visible.
* **Metrics** — open the [Metric Explorer](/metrics/explore-metrics) and filter for the openclaw-gateway service.
* **Logs** — open [Log Search](/Search-and-Visualize/Log-Search) and check for data in the `openclaw-demo/openclaw` dataset.
The gateway logs only emit a `logs exporter enabled` line on startup — they do **not** log a traces exporter line, and they do **not** log export failures.
## Reference
### Endpoints by region
| Region | Traces | Logs |
| - | - | - |
| EU | `https://ingestion.eu.bronto.io/v1/traces` | `https://ingestion.eu.bronto.io/v1/logs` |
| US | `https://ingestion.us.bronto.io/v1/traces` | `https://ingestion.us.bronto.io/v1/logs` |
### Headers
| Header | Scope | Description |
| - | - | - |
| `x-bronto-api-key` | All signals | Bronto ingestion API key (required). |
| `x-bronto-dataset` | Logs only | Log dataset name. |
| `x-bronto-collection` | Logs only | Collection containing the log dataset — e.g. `production`. |
### Notable `openclaw.json` diagnostics fields
| Key | Notes |
| - | - |
| `protocol` | Must be `http/protobuf`. OpenClaw ignores gRPC. |
| `serviceName` | Identifies the source in Bronto — appears as `service.name`. |
| `traces` / `logs` | Both default to enabled-with-export, but `logs` requires explicit `true` in some plugin versions. |
| `captureContent` | Set `true` to attach prompt and response content to spans. Off by default. |
| `sampleRate` | Root-span sampling ratio, `0.0`–`1.0`. Use `1` to capture every model call. |
| `flushIntervalMs` | How often the exporter flushes batched signals. |
## Troubleshooting
### Step one: isolate where the failure is
Before checking individual settings, determine which side of the pipeline is failing. The Collector path makes this trivial — its `debug` exporter prints every signal it receives.
* **If using the Opentelemetry Collector:** Tail the Collector's output (see [Confirm signals are flowing](#3-confirm-signals-are-flowing)) and send the assistant a message.
* Signals **appear** in the Collector output but **not** in Bronto → the failure is between the Collector and Bronto. Check the API key, region, and headers in `otel-collector-config.yaml`.
* Signals **do not appear** in the Collector output → the failure is upstream of the Collector. The plugin is not enabled, the gateway has not been restarted, or no model activity is being generated.
* **If sending telemetry directly:** Test network and auth as described in the next section. If that fails switch to the OpenTelemetry Collector and run the same check. This is by far the fastest way to narrow the failure down - without it, you cannot see what OpenClaw is (or isn't) emitting.
### Network and auth test
Use this to check for networking or auth failures between the Collector and Bronto. Run both checks from the same host as the Collector (or your OpenClaw agent, if sending telemetry directly).
The examples target the EU region — swap `eu` for `us` if your account is in the US region.
**1. DNS resolution.** Empty output means DNS is broken locally (split-DNS on a corporate VPN, misconfigured `resolv.conf` inside a container, captive portal, etc.).
```bash theme={"dark"}
dig +short ingestion.eu.bronto.io
```
**2. End-to-end POST.** In the Bronto UI, go to
**My Data** (sidebar) → **Add Data** → **Test Connection** (bottom of the page).
Bronto generates a `curl` command pre-filled with a hello-world payload and your API key — copy-paste it into a shell on the Collector's host.
A `200` proves both connectivity and that the API key is valid for this region.
If it fails, re-run with `-vvv` for the full request, TLS handshake, and response, and Google the specific error.
### Common issues
**API key incorrect.** Especially common when an AI agent edited the config - agents frequently mis-substitute the key (dropped characters, wrapped in extra quotes, replaced with a placeholder like ``). Re-paste the key by hand and confirm it matches exactly.
**Logs arrive in Bronto but no traces or metrics.** This is a known intermittent issue with the `diagnostics-otel` plugin. Fully restart the gateway service — `docker compose restart openclaw-gateway`, or restart the OpenClaw container / supervised process for native installs. A simple reload is not enough.
**Traces arrive but no logs.** OpenClaw's `logs` toggle defaults to `false` in some plugin versions. Set `"logs": true` explicitly in `openclaw.json`.
**Wrong region.** The API key is region-scoped. EU keys do not work against `us` endpoints and vice versa. Confirm the key's region in Bronto and use the matching `ingestion..bronto.io` host.
**Spans arrive but `gen_ai.*` attributes are missing.** Set `OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental` in `~/.openclaw/.env` and restart the gateway. Without it, OpenClaw emits only its own `openclaw.*` attributes.
**No prompt/response content on spans.** Expected unless `captureContent` is `true` in the `diagnostics.otel` block.
**Plugin not exporting at all.** Confirm `diagnostics-otel` is in `plugins.allow`, the plugin is enabled, and both `diagnostics.enabled` and `diagnostics.otel.enabled` are `true`.
**`protocol` ignored / nothing exported.** The `protocol` field must be `http/protobuf`. OpenClaw ignores gRPC.
## Configure with AI (experimental)
If you'd rather have an OpenClaw up to Bronto for you itself, paste one of the prompts below into an agent with access to your OpenClaw host (or your local checkout of `~/.openclaw/`). Substitute occurrences of `` with your Bronto API key before sending.
**Treat AI-generated configuration as untrusted until you've verified it.**
**This approach is not recommended. Use at the risk of wasting your time**
Coding agents routinely:
* mis-substitute secrets (drop characters from the API key, wrap it in extra quotes, or leave the literal placeholder `` in place);
* hallucinate config keys, env-var names, CLI flags, or endpoint paths that look plausible but don't exist;
* skip steps, run them out of order, or silently overwrite parts of `openclaw.json` / `.env` that they think are irrelevant.
After the agent finishes, **diff what changed**, open `~/.openclaw/.env` and `otel-collector-config.yaml` (if using the Collector), and confirm by hand that the API key, region, and field names match this page exactly. If telemetry doesn't show up in Bronto, start with [Troubleshooting](#troubleshooting) - and assume the agent's work is the cause until proven otherwise.
````text theme={"dark"}
**Set up OpenTelemetry collection from OpenClaw and forward it to Bronto.**
**Bronto details:**
- API Key: ``
- Region: EU
- Log dataset: `openclaw`
- Log collection: `openclaw-demo`
- Service name: `openclaw-gateway`
**Steps:**
1. Install and enable the `diagnostics-otel` plugin:
```
openclaw plugins install clawhub:@openclaw/diagnostics-otel
openclaw plugins enable diagnostics-otel
```
2. Add the `diagnostics` block to `~/.openclaw/openclaw.json` (top level, merge with existing — don't nuke anything):
```json
{
"diagnostics": {
"enabled": true,
"otel": {
"enabled": true,
"endpoint": "https://ingestion.eu.bronto.io",
"tracesEndpoint": "https://ingestion.eu.bronto.io/v1/traces",
"logsEndpoint": "https://ingestion.eu.bronto.io/v1/logs",
"metricsEndpoint": "https://ingestion.eu.bronto.io/v1/metrics",
"protocol": "http/protobuf",
"serviceName": "openclaw-gateway",
"headers": {
"x-bronto-api-key": "${BRONTO_API_KEY}",
"x-bronto-dataset": "openclaw",
"x-bronto-collection": "openclaw-demo"
},
"captureContent": true,
"traces": true,
"logs": true,
"metrics": true,
"sampleRate": 1,
"flushIntervalMs": 10000
}
}
}
```
3. Set up `~/.openclaw/.env` — add (don't overwrite existing vars):
```
BRONTO_API_KEY=
OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental
OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=delta
```
4. Restart the gateway.
**Important:** Merge configs — don't clobber existing `openclaw.json` or `.env` contents. Read first, then update.
````
````text theme={"dark"}
**Set up OpenTelemetry collection from OpenClaw with an OTel Collector sidecar and forward it to Bronto.**
**Bronto details:**
- API Key: ``
- Region: EU
- Log dataset: `openclaw`
- Log collection: `openclaw-demo`
- Service name: `openclaw-gateway`
**Steps:**
1. Install and enable the `diagnostics-otel` plugin:
```
openclaw plugins install clawhub:@openclaw/diagnostics-otel
openclaw plugins enable diagnostics-otel
```
2. Create an OpenTelemetry Collector config file (e.g. `otel-collector-config.yaml`) with the following content. This accepts OTLP/HTTP on port `4318`, prints everything to stdout via the `debug` exporter (useful for confirming signals are flowing — remove it once telemetry is stable), and forwards everything to Bronto:
```yaml
receivers:
otlp:
protocols:
http:
endpoint: "0.0.0.0:4318"
processors:
batch:
exporters:
debug:
verbosity: detailed
otlphttp/brontotraces:
traces_endpoint: "https://ingestion.eu.bronto.io/v1/traces"
compression: gzip
headers:
x-bronto-api-key:
otlphttp/brontometrics:
metrics_endpoint: "https://ingestion.eu.bronto.io/v1/metrics"
compression: gzip
headers:
x-bronto-api-key:
otlphttp/brontologs:
logs_endpoint: "https://ingestion.eu.bronto.io/v1/logs"
compression: gzip
headers:
x-bronto-api-key:
x-bronto-dataset: openclaw
x-bronto-collection: openclaw-demo
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [debug, otlphttp/brontotraces]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [debug, otlphttp/brontometrics]
logs:
receivers: [otlp]
processors: [batch]
exporters: [debug, otlphttp/brontologs]
```
3. Start the OTel Collector with this config. Install method varies (Docker, Homebrew, Linux package, Kubernetes — see [OTel Collector installation docs](https://opentelemetry.io/docs/collector/installation/)). Example with Docker:
```
docker run --rm -p 4318:4318 -v $(pwd)/otel-collector-config.yaml:/etc/otelcol/config.yaml otel/opentelemetry-collector:latest --config=/etc/otelcol/config.yaml
```
4. Add the `diagnostics` block to `~/.openclaw/openclaw.json` (top level, merge with existing — don't nuke anything):
```json
{
"diagnostics": {
"enabled": true,
"otel": {
"enabled": true,
"endpoint": "http://localhost:4318",
"protocol": "http/protobuf",
"serviceName": "openclaw-gateway",
"captureContent": true,
"traces": true,
"logs": true,
"metrics": true,
"sampleRate": 1,
"flushIntervalMs": 10000
}
}
}
```
If the Collector and gateway run as separate Docker containers on a shared network, change `endpoint` to the Collector's service/container name (e.g. `http://otel-collector:4318`).
5. Add the following to `~/.openclaw/.env` (merge — don't overwrite existing vars):
```
OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental
OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=delta
```
6. Restart the gateway:
```
openclaw gateway restart
```
````
Hand the agent this prompt if telemetry isn't showing up in Bronto after running one of the setup prompts above.
````text theme={"dark"}
### Step 1: Isolate where the failure is
**If using an OTel Collector sidecar:**
1. Tail the Collector's stdout/logs.
2. Send the assistant a message.
3. Check what appears:
- Signals appear in Collector output but **not** in Bronto → failure is between Collector and Bronto (check API key, region, headers in `otel-collector-config.yaml`).
- Signals **don't appear** in Collector output at all → failure is upstream (plugin not enabled, gateway not restarted, no model activity).
**If sending telemetry directly (no Collector):**
Test network and auth (step 2 below). If that fails, switch to a Collector setup — it's the fastest way to narrow down where the pipeline breaks. Without it, you can't see what OpenClaw is (or isn't) emitting.
### Step 2: Network and auth test
Run these from the same host as the Collector (or the OpenClaw gateway if sending directly). Region is EU — swap to `us` if needed.
**DNS resolution** — empty output means DNS is broken (corporate VPN, misconfigured `resolv.conf`, captive portal, etc.):
```bash
dig +short ingestion.eu.bronto.io
```
### Step 3: Check common issues
Go through these in order:
| Symptom | Likely cause | Fix |
|---------|-------------|-----|
| No data at all | API key mangled (AI agents love to drop chars, add extra quotes, or replace with ``) | Re-paste the key by hand, confirm it matches exactly |
| Logs arrive but no traces or metrics | Known intermittent issue with `diagnostics-otel` plugin | Fully restart the gateway service (not just a reload) — `docker compose restart openclaw-gateway` or restart the container/supervised process |
| Traces arrive but no logs | `logs` toggle defaults to `false` in some plugin versions | Set `"logs": true` explicitly in `openclaw.json` |
| Wrong region errors | API key is region-scoped — EU keys don't work against US endpoints and vice versa | Confirm key's region in Bronto, use matching `ingestion..bronto.io` |
| Spans arrive but missing `gen_ai.*` attributes | Missing semconv opt-in | Set `OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental` in `~/.openclaw/.env` and restart gateway |
| No prompt/response content on spans | `captureContent` not enabled | Set `"captureContent": true` in `diagnostics.otel` block |
| Plugin not exporting at all | Plugin not properly enabled | Confirm `diagnostics-otel` is in `plugins.allow`, plugin is enabled, and both `diagnostics.enabled` and `diagnostics.otel.enabled` are `true` |
| `protocol` ignored / nothing exported | Wrong protocol value | `protocol` must be `http/protobuf` — OpenClaw ignores gRPC |
**Important:** Read `openclaw.json` and `.env` before making changes. Merge — don't nuke existing config.
````
# Vibe Building with Bronto
Source: https://docs.bronto.io/ai-features/vibe-building
Build custom observability interfaces with Lovable, v0, and Bronto APIs for workflows such as usage dashboards, service maps, and focused operational views.
## Overview
You can build a custom service map, focused operational view, or workflow-specific interface on top of Bronto data.
In this context, **vibe building** means using AI-assisted UI generation tools such as [Lovable](https://lovable.dev) and [v0](https://v0.dev) to build a frontend quickly while Bronto provides the observability data and APIs behind it.
The fastest way to start is to remix Bronto's [Lovable baseline template](https://lovable.dev/projects/af3702ca-a831-411d-9620-789e05cf8e20), which already wires up Search, tracing, dashboards, and usage views against the Bronto API. If you prefer Vercel, the [BrontoVibe v0 example](https://v0-brontovibe.vercel.app/) is a deploy-your-own version of the same idea — ship it to Vercel, then refine it with the v0 agent in the Vercel platform using natural-language prompts. For a full walkthrough, see the [BrontoVibe blog post](https://bronto.io/blog/brontovibe).
The examples on this page are starting points, not limits. Once you can query Bronto data and shape it into a UI, you can build many different workflow-specific experiences on top of the platform.
## Prerequisites
This guide assumes you already have a Bronto account and have sent data to Bronto. If you haven't ingested data yet, [set up an agent](/agent-setup/agent-intro) first.
You will also need:
* a **Bronto API key** with access to the features your interface uses. The baseline template uses Search, tracing, dashboards, and usage, so generate a key with full access. See [API Keys](/Account-Management/API-Keys).
* a UI generation or app-building tool such as [Lovable](https://lovable.dev) or [v0](https://v0.dev), or your own frontend stack.
## When to use this approach
Vibe building works best when you want to create a workflow-specific experience on top of Bronto data, for example:
* a team-specific dashboard
* a customer or tenant-specific operational view
* a custom service map that links directly into your investigation workflow
This approach works especially well when you want to simplify a repeated workflow, present only the most relevant data for one audience, or embed observability into another tool.
## Core building blocks
Most custom interfaces built on top of Bronto use a small set of platform concepts. See the [glossary](/getting-started/glossary) for full definitions:
* [API Key](/getting-started/glossary#api-key) — authenticate your custom UI or internal app
* [Search](/getting-started/glossary#search) — query Bronto data for custom tables, charts, filtered views, and workflow screens
* [My Data](/getting-started/glossary#my-data) — understand datasets, ingestion, and search usage
* [Dataset](/getting-started/glossary#dataset) — the unit of log storage your log queries run against
* [Trace](/getting-started/glossary#trace) — derive service maps and trace-linked workflows from OpenTelemetry data
## Recommended setup flow
Remix Bronto's [Lovable baseline template](https://lovable.dev/projects/af3702ca-a831-411d-9620-789e05cf8e20) to start with Search, tracing, dashboards, and usage already wired up. To deploy your own to Vercel instead, start from the [BrontoVibe v0 example](https://v0-brontovibe.vercel.app/) and refine it with the v0 agent in the Vercel platform using natural-language prompts.
Create a dedicated [API key](/Account-Management/API-Keys) for the app and give it access to the features your interface uses.
Describe the workflow-specific interface you want and let the tool generate it on top of Bronto data. See [Recommended prompt inputs](#recommended-prompt-inputs) for what to include.
Keep the custom UI focused. When users need more context, link them back to Bronto search or trace exploration.
## Recommended prompt inputs
When using Lovable or v0, prompts work best when they clearly define:
* the user or team the UI is for
* the exact workflow the UI should support
* which Bronto API should supply the data
* the filters, charts, tables, or graph views the page should include
* where the UI should link back into Bronto
## Example: user-built custom service map
A strong pattern is a custom service map built with Lovable on top of OpenTelemetry trace data already in Bronto.
This is useful when you want a workflow-specific topology view instead of a general-purpose tracing UI. For example, a team may want to highlight only production services, emphasize error-heavy edges, or make each node link into a trace investigation flow.
What this usually looks like in practice:
* a node graph of services and dependencies
* edge labels showing call volume or protocol
* color or emphasis based on latency or error rate
* a side panel for the selected service
* direct links into traces or related logs
Typical elements include:
* nodes for services, queues, gateways, and external dependencies
* edges representing calls between services
* span count, average latency, and error rate on each node or edge
* filters for environment, time range, transaction type, or service group
* click-through actions that open traces or related logs for the selected service
Here is an example of a service-flow view a Bronto user built with Lovable on top of trace data already stored in Bronto:
### Example prompt
```text theme={"dark"}
Build a custom service map for Bronto.
Use OpenTelemetry trace data in Bronto to derive service-to-service relationships.
Render services and dependencies as a graph.
Display latency, span volume, and error rate on nodes and edges.
Support filtering by environment and time range.
Include a side panel that links from a selected service to trace and log investigation views in Bronto.
```
## Additional examples
The same setup pattern can support many other interfaces beyond the main example above.
### Usage and cost view
While Bronto already includes in-product usage tooling, some teams may still want to embed usage and cost data into another internal tool, team portal, or customer-specific view using the [Usage API](/api-reference/usage/overview).
```text theme={"dark"}
Build a usage and cost view on top of the Bronto Usage API.
Show ingestion and search usage for a selected team or environment.
Include a trend chart, top datasets, and threshold indicators.
Keep the layout compact and easy to embed into another internal page.
```
### Support-facing operational view
A support team can build a focused screen that shows recent customer-facing errors, affected services, and links into the relevant logs or traces without exposing the full Bronto experience to every user.
```text theme={"dark"}
Build a support-facing operational dashboard for Bronto.
Show recent production errors, top affected services, and links to related traces.
Add filters for environment, customer segment, and severity.
Keep the layout simple and optimized for quick triage during support workflows.
```
### Release-health screen
A delivery or platform team can build a deployment-window view that focuses on regressions immediately after a release, combining search results, error trends, and service-level indicators in one place.
```text theme={"dark"}
Build a release-health screen on top of Bronto.
Show errors, latency changes, and affected services for a selected deployment window.
Include a time-series chart, a recent errors table, and links into detailed Bronto searches.
Make the page easy to scan during release validation.
```
## Best practices
* start with one narrow workflow instead of trying to recreate the full Bronto UI
* create a dedicated API key for each custom app
* link back into Bronto whenever users need deeper context or broader exploration
# Check if user or group has access to org
Source: https://docs.bronto.io/api-reference/access/check-if-user-or-group-has-access-to-org
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /organizations/{orgId}/access/{entityType}/{entityId}/check
# Grant access to a user or group
Source: https://docs.bronto.io/api-reference/access/grant-access-to-a-user-or-group
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /organizations/{orgId}/access/{entityType}/{entityId}
# List all members who have access to this organization
Source: https://docs.bronto.io/api-reference/access/list-all-members-who-have-access-to-this-organization
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /organizations/{orgId}/access
# Revoke access from a user or group
Source: https://docs.bronto.io/api-reference/access/revoke-access-from-a-user-or-group
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /organizations/{orgId}/access/{entityType}/{entityId}
# Switch active organization for a user
Source: https://docs.bronto.io/api-reference/access/switch-active-organization-for-a-user
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /organizations/{orgId}/access/user/{userId}/switch
Sets the specified organization as the active organization for the user. The user must already have access to this organization.
# Ask AI to give hints regarding a particular error
Source: https://docs.bronto.io/api-reference/ai/ask-ai-to-give-hints-regarding-a-particular-error
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /explain-error
# Ask AI to provide a widget based on a prompt request
Source: https://docs.bronto.io/api-reference/ai/ask-ai-to-provide-a-widget-based-on-a-prompt-request
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /widget-creation-assistant
# Create a new API key
Source: https://docs.bronto.io/api-reference/api-keys/create-a-new-api-key
post /api-keys
Create a new Bronto API key with one or more role scopes such as IngestionApi or SearchApi, and an optional TTL, for authenticating REST API requests.
# Delete an API key
Source: https://docs.bronto.io/api-reference/api-keys/delete-an-api-key
delete /api-keys/{apiKeyId}
Revoke a Bronto API key by its unique identifier to immediately invalidate it so any clients still using it can no longer authenticate REST API requests.
# API Key Authentication
Source: https://docs.bronto.io/api-reference/api-keys/overview
Authenticate Bronto API requests with API keys passed in the X-BRONTO-API-KEY header. Roles assigned to each key control which endpoints are available.
# Retrieve a list of API keys
Source: https://docs.bronto.io/api-reference/api-keys/retrieve-a-list-of-api-keys
get /api-keys
List every Bronto API key in your organization with its name, assigned roles, creation time, and TTL so you can audit and rotate keys.
# Update an API key
Source: https://docs.bronto.io/api-reference/api-keys/update-an-api-key
patch /api-keys/{apiKeyId}
Update the name, role assignments, or expiration of an existing Bronto API key without rotating the key value or breaking active integrations.
# Retrieve a list of collections
Source: https://docs.bronto.io/api-reference/collections/retrieve-a-list-of-collections
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /collections
# Retrieve contextual information for a given sequence and log
Source: https://docs.bronto.io/api-reference/context/get-context
get /context
Retrieve the log events immediately before, after, or surrounding a specific event of interest to investigate incidents and reconstruct request timelines.
# Context API
Source: https://docs.bronto.io/api-reference/context/overview
Use the Bronto Context REST API to retrieve log events surrounding a specific event of interest, before, after, or both, for faster troubleshooting.
# Retrieve contextual information for a given sequence and log
Source: https://docs.bronto.io/api-reference/context/retrieve-contextual-information-for-a-given-sequence-and-log
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /context
# Get the customer record for the current organization
Source: https://docs.bronto.io/api-reference/customers/get-the-customer-record-for-the-current-organization
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /customer
# Update the customer record for the current organization
Source: https://docs.bronto.io/api-reference/customers/update-the-customer-record-for-the-current-organization
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml patch /customer
# Append widgets to a dashboard
Source: https://docs.bronto.io/api-reference/dashboards/append-widgets-to-a-dashboard
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /dashboards/{dashboardId}/widgets
# Create a dashboard
Source: https://docs.bronto.io/api-reference/dashboards/create-a-dashboard
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /dashboards
# Delete a dashboard by ID
Source: https://docs.bronto.io/api-reference/dashboards/delete-a-dashboard-by-id
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /dashboards/{dashboardId}
# Detach a dashboard from a template
Source: https://docs.bronto.io/api-reference/dashboards/detach-a-dashboard-from-a-template
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /dashboards/{dashboardId}/detach-from-template
# Get a single Dashboard by ID
Source: https://docs.bronto.io/api-reference/dashboards/get-a-single-dashboard-by-id
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /dashboards/{dashboardId}
# Get all dashboards for an organisation
Source: https://docs.bronto.io/api-reference/dashboards/get-all-dashboards-for-an-organisation
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /dashboards
# List dashboards associated with a log
Source: https://docs.bronto.io/api-reference/dashboards/list-dashboards-associated-with-a-log
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /logs/{logId}/dashboards
# Partially update a dashboard by ID, allowing either a name change or modification of widget IDs (append or remove)
Source: https://docs.bronto.io/api-reference/dashboards/partially-update-a-dashboard-by-id-allowing-either-a-name-change-or-modification-of-widget-ids-append-or-remove
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml patch /dashboards/{dashboardId}
# Remove a widget from a dashboard
Source: https://docs.bronto.io/api-reference/dashboards/remove-a-widget-from-a-dashboard
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /dashboards/{dashboardId}/widgets/{widgetId}
# Assign a parser to a dataset
Source: https://docs.bronto.io/api-reference/datasets/assign-a-parser-to-a-dataset
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml put /datasets/{datasetId}/parser
# Create a new dataset
Source: https://docs.bronto.io/api-reference/datasets/create-a-new-dataset
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /datasets
# Get the parser assigned to a dataset
Source: https://docs.bronto.io/api-reference/datasets/get-the-parser-assigned-to-a-dataset
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /datasets/{datasetId}/parser
# Resolve data sets
Source: https://docs.bronto.io/api-reference/datasets/resolve-data-sets
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /datasets/resolve
Resolve datasets based on criteria such as keys and "from" expressions
# Retrieve a list of datasets
Source: https://docs.bronto.io/api-reference/datasets/retrieve-a-list-of-datasets
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /datasets
# Unassign the parser from a dataset
Source: https://docs.bronto.io/api-reference/datasets/unassign-the-parser-from-a-dataset
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /datasets/{datasetId}/parser
# Create a new monitor downtime
Source: https://docs.bronto.io/api-reference/downtimes/create-a-new-monitor-downtime
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /monitors/downtimes
Create a downtime to silence monitors periodically
# Delete a monitor downtime
Source: https://docs.bronto.io/api-reference/downtimes/delete-a-monitor-downtime
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /monitors/downtimes/{downtimeId}
# Retrieve all monitor downtimes
Source: https://docs.bronto.io/api-reference/downtimes/retrieve-all-monitor-downtimes
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /monitors/downtimes
Retrieves the list of currently configured downtimes
# Update a monitor downtime
Source: https://docs.bronto.io/api-reference/downtimes/update-a-monitor-downtime
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml put /monitors/downtimes/{downtimeId}
update an existing downtime
# Create a new encryption key
Source: https://docs.bronto.io/api-reference/encryption-keys/create-a-new-encryption-key
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /encryption-keys
# Delete an encryption key
Source: https://docs.bronto.io/api-reference/encryption-keys/delete-an-encryption-key
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /encryption-keys/{keyId}
Delete an encryption key. Keys can only be deleted when their status is CREATED.
# Retrieve a list of encryption keys
Source: https://docs.bronto.io/api-reference/encryption-keys/retrieve-a-list-of-encryption-keys
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /encryption-keys
# Retrieve a specific encryption key
Source: https://docs.bronto.io/api-reference/encryption-keys/retrieve-a-specific-encryption-key
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /encryption-keys/{keyId}
# Update an existing encryption key
Source: https://docs.bronto.io/api-reference/encryption-keys/update-an-existing-encryption-key
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml patch /encryption-keys/{keyId}
Update an encryption key's display name and/or status. Only name and status can be updated. Status can only transition from CREATED to ACTIVE.
# return the list of monitor events
Source: https://docs.bronto.io/api-reference/events/return-the-list-of-monitor-events
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /monitors/{monitorId}/events
# Create a new export
Source: https://docs.bronto.io/api-reference/exports/create-a-new-export
post /exports
Creates an export from either explicit log ids in `from` or a dataset selector in `from_expr`. When `from_expr` is supplied, it is resolved at creation time and the resulting log ids are persisted in `search_details.from` for export processing.
# Delete an export by ID
Source: https://docs.bronto.io/api-reference/exports/delete-an-export
delete /exports/{exportId}
Delete a Bronto export job by ID to cancel an in-progress export or remove the download URL for a completed export from your organization.
# Delete an export by ID
Source: https://docs.bronto.io/api-reference/exports/delete-an-export-by-id
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /exports/{exportId}
# Retrieve an export by ID
Source: https://docs.bronto.io/api-reference/exports/get-export-by-id
get /exports/{exportId}
Poll the status and progress percentage of an asynchronous Bronto export job by ID, and retrieve the signed download URL once the export completes.
# Exports API
Source: https://docs.bronto.io/api-reference/exports/overview
Use the Bronto Exports REST API to download large volumes of log data asynchronously, filtered by query, with status polling and direct download URLs.
The Bronto Export API allows you to efficiently download large volumes of log data for further analysis. The data to be exported can be filtered by entering the search parameters "from", "where" and "time\_range" as per a normal query in the "search\_details" object.
To export data the following steps are required:
1. Create an export using a POST request, which will return an "export\_id", "status" and "progress".
2. Use the export id to get the status of the export task by sending a GET request, which will return "status" and "progress" with a value of percentage completed. When the export is completed, the "status" will be "COMPLETE"
3. Once the export task has completed you can download your data using curl (or similar) from the "location" URL returned in the GET response.
# Retrieve a list of exports
Source: https://docs.bronto.io/api-reference/exports/retrieve-a-list-of-exports
get /exports
List every Bronto data export job in your organization, including IDs, statuses, and progress, so you can monitor running exports and access past downloads.
# Retrieve an export by ID
Source: https://docs.bronto.io/api-reference/exports/retrieve-an-export-by-id
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /exports/{exportId}
# Create a new forward config to archive your logs in another system
Source: https://docs.bronto.io/api-reference/forward/create-a-new-forward-config-to-archive-your-logs-in-another-system
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /forward-configs
Create a forward config, to forward log events outside the Bronto system (e.g. archive logs in an S3 bucket)
# Create a new forward config to archive your logs in another system
Source: https://docs.bronto.io/api-reference/forward/create-new-config
post /forward-configs
Create a forward config, to forward log events outside the Bronto system (e.g. archive logs in an S3 bucket)
This feature allows users to forward log events outside of Bronto. A common use case would be archiving your log data to an AWS S3 bucket.
# Delete a forward config
Source: https://docs.bronto.io/api-reference/forward/delete-a-config
delete /forward-configs/{forwardId}
Delete a Bronto log forwarding configuration by ID to stop archiving matching log events to the configured S3, GCS, or HTTP destination.
# Delete a forward config
Source: https://docs.bronto.io/api-reference/forward/delete-a-forward-config
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /forward-configs/{forwardId}
# Retrieve forward configs
Source: https://docs.bronto.io/api-reference/forward/retrieve-forward-configs
get /forward-configs
Retrieves the list of all forward configs set up for the account
# Test access to the destination
Source: https://docs.bronto.io/api-reference/forward/test-access-to-destination
post /forward-configs/test-destination
Check access to the destination. A test file will be created and deleted to make sure Bronto can access your destination
# Test access to the destination
Source: https://docs.bronto.io/api-reference/forward/test-access-to-the-destination
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /forward-configs/test-destination
Check access to the destination. A test file will be created and deleted to make sure Bronto can access your destination
# Update an existing forward config
Source: https://docs.bronto.io/api-reference/forward/update-an-existing-forward-config
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml put /forward-configs/{forwardId}
Update a forward config, to forward log events outside the Bronto system (e.g. archive logs in an S3 bucket)
# Update an existing forward config
Source: https://docs.bronto.io/api-reference/forward/update-existing-config
put /forward-configs/{forwardId}
Update a forward config, to forward log events outside the Bronto system (e.g. archive logs in an S3 bucket)
# Add members to a group
Source: https://docs.bronto.io/api-reference/groups/add-members-to-a-group
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /groups/{groupId}/members
# Create a new group
Source: https://docs.bronto.io/api-reference/groups/create-a-new-group
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /groups
# Delete a group
Source: https://docs.bronto.io/api-reference/groups/delete-a-group
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /groups/{groupId}
# Get a specific group
Source: https://docs.bronto.io/api-reference/groups/get-a-specific-group
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /groups/{groupId}
# List all user groups in the organization
Source: https://docs.bronto.io/api-reference/groups/list-all-user-groups-in-the-organization
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /groups
# List groups a member belongs to
Source: https://docs.bronto.io/api-reference/groups/list-groups-a-member-belongs-to
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /users/{userId}/groups
# List members of a group
Source: https://docs.bronto.io/api-reference/groups/list-members-of-a-group
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /groups/{groupId}/members
# Remove members from a group
Source: https://docs.bronto.io/api-reference/groups/remove-members-from-a-group
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /groups/{groupId}/members
# Update a group
Source: https://docs.bronto.io/api-reference/groups/update-a-group
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml patch /groups/{groupId}
# Create a Slack Integration Resource
Source: https://docs.bronto.io/api-reference/integrations/create-a-slack-integration-resource
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /integrations/slack
# Create a Webhook Integration Resource
Source: https://docs.bronto.io/api-reference/integrations/create-a-webhook-integration-resource
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /integrations/webhooks
# Delete a Slack Integration Resource
Source: https://docs.bronto.io/api-reference/integrations/delete-a-slack-integration-resource
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /integrations/slack/{slack_id}
# Delete a Slack workspace resource; note this does not uninstall the bronto.io app from Slack
Source: https://docs.bronto.io/api-reference/integrations/delete-a-slack-workspace-resource;-note-this-does-not-uninstall-the-brontoio-app-from-slack
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /integrations/slack/workspaces/{workspace_id}
# Delete a webhook Integration Resource
Source: https://docs.bronto.io/api-reference/integrations/delete-a-webhook-integration-resource
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /integrations/webhooks/{webhook_id}
# Get all Slack Integration Resources for an organisation
Source: https://docs.bronto.io/api-reference/integrations/get-all-slack-integration-resources-for-an-organisation
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /integrations/slack
# Get all Slack workspace resources for an organisation
Source: https://docs.bronto.io/api-reference/integrations/get-all-slack-workspace-resources-for-an-organisation
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /integrations/slack/workspaces
# Get all Webhook Integration Resources for an organisation
Source: https://docs.bronto.io/api-reference/integrations/get-all-webhook-integration-resources-for-an-organisation
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /integrations/webhooks
# Update a Slack Integration Resource
Source: https://docs.bronto.io/api-reference/integrations/update-a-slack-integration-resource
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml put /integrations/slack/{slack_id}
# Update a webhook Integration Resource
Source: https://docs.bronto.io/api-reference/integrations/update-a-webhook-integration-resource
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml put /integrations/webhooks/{webhook_id}
# Bronto API
Source: https://docs.bronto.io/api-reference/introduction
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml
Manage logs, run searches, control users and access, and automate workflows in Bronto using a RESTful API authenticated with API keys or bearer tokens.
# Bronto API
The **Bronto API** is a RESTful interface for managing logs, monitoring system activity, and automating key workflows within the Bronto platform.
## Overview
The Bronto API enables developers and engineering teams to:
* **Retrieve data** with flexible querying and filtering
* **Manage users** and control access programmatically
* **Monitor systems** and automate operational workflows
* **Control log retention** policies and visualization settings
## Base Information
| Property | Value |
| - | - |
| API Version | 1.0.0 |
| Protocol | HTTPS |
| Style | RESTful |
| License | Commercial |
| Auth | API Key / Bearer Token |
## OpenAPI Specification
The full machine-readable specification is available for download or direct consumption by API clients and LLM tools.
## Key Capabilities
### Log Management
Search and manage log data at scale.
### Data Retrieval
Query and filter log data with precision. Retrieve results in real time or batch mode depending on your use case.
### User & Access Management
Create and manage users, assign roles, and control permissions programmatically across your organisation.
### System Monitoring
Access system health metrics, activity feeds, and operational data to power dashboards and alerting pipelines.
### Automation & Workflows
Integrate the Bronto API into CI/CD pipelines, observability stacks, or internal tooling to reduce manual overhead.
## Getting Started
1. **Obtain credentials** — Sign in to Bronto and create a new [API key](https://docs.bronto.io/Account-Management/API-Keys).
2. **Review the OpenAPI spec** — Download the YAML above or explore the interactive reference in the sidebar.
3. **Make your first request** — Use any HTTP client (curl, Postman, SDKs) against the base URL.
4. **Explore the guides** — See the sidebar for authentication, pagination, error handling, and endpoint references.
## Licensing
License: `Commercial`
# Create a new limit
Source: https://docs.bronto.io/api-reference/limits/create-a-new-limit
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /limits
Create a limit
# Delete a limit by ID
Source: https://docs.bronto.io/api-reference/limits/delete-a-limit-by-id
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /limits/{limitId}
# Get a Limit
Source: https://docs.bronto.io/api-reference/limits/get-a-limit
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /limits/{limitId}
# Retrieve limits
Source: https://docs.bronto.io/api-reference/limits/retrieve-limits
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /limits
Retrieves the list of limits configured for the organisation. Limits define thresholds and constraints applied to resources within your account.
# Update a limit
Source: https://docs.bronto.io/api-reference/limits/update-a-limit
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml patch /limits/{limitId}
update an existing limit
# Initiate a live tail job
Source: https://docs.bronto.io/api-reference/live-tail/initiate-a-live-tail-job
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /live-tail
# Poll a live tail job
Source: https://docs.bronto.io/api-reference/live-tail/poll-a-live-tail-job
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /live-tail
# Create a new log
Source: https://docs.bronto.io/api-reference/logs/create-a-new-log
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /logs
# Create a new log
Source: https://docs.bronto.io/api-reference/logs/create-log
post /logs
Create a new Bronto log dataset to receive timestamped events, with a configurable name, parser, retention, and metadata for routing ingested data.
# Retrieve a list of logs
Source: https://docs.bronto.io/api-reference/logs/get-logs
get /logs
Retrieve the list of log datasets in your Bronto organization with metadata such as IDs, names, and retention settings to inspect or build search queries.
# Logs API
Source: https://docs.bronto.io/api-reference/logs/overview
Use the Bronto Logs REST API to create new log datasets and retrieve metadata for logs that can be searched, filtered, and aggregated across your organization.
# Retrieve a list of log views
Source: https://docs.bronto.io/api-reference/logs/retrieve-a-list-of-log-views
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /logs/views
# Retrieve a list of logs
Source: https://docs.bronto.io/api-reference/logs/retrieve-a-list-of-logs
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /logs
# Retrieve the list of metrics metadata sent to Bronto
Source: https://docs.bronto.io/api-reference/metrics/retrieve-the-list-of-metrics-metadata-sent-to-bronto
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /metrics
# Retrieve the metadata of an ingested metric
Source: https://docs.bronto.io/api-reference/metrics/retrieve-the-metadata-of-an-ingested-metric
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /metrics/{metric_id}
# Retrieve the top keys and sample values for a metric
Source: https://docs.bronto.io/api-reference/metrics/retrieve-the-top-keys-and-sample-values-for-a-metric
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /metrics/{metric_id}/top-keys
Returns the keys (attributes) received for a metric within a time window,
together with each key's data type and a sample of the values seen for it.
Use this to discover which dimensions you can filter or group a metric by.
Set the time window in one of two ways:
- `time_range`, a relative range such as `last 20 minutes`, **or**
- `from_ts` and `to_ts` together, as an absolute range in Unix milliseconds.
If no time window is provided, the most recent keys and values are returned.
The response is an object keyed by key name. Values are a sample, not an
exhaustive list.
# Create a new monitor
Source: https://docs.bronto.io/api-reference/monitors/create-a-new-monitor
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /monitors
Create a monitor to be notified when a log-based or metric-based condition is met
# Create a new monitor template
Source: https://docs.bronto.io/api-reference/monitors/create-a-new-monitor-template
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /monitors/templates
Create a monitor template to be notified when a log-based or metric-based condition is met
# Delete a monitor
Source: https://docs.bronto.io/api-reference/monitors/delete-a-monitor
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /monitors/{monitorId}
# Delete a monitor template
Source: https://docs.bronto.io/api-reference/monitors/delete-a-monitor-template
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /monitors/templates/{templateId}
# Get a monitor
Source: https://docs.bronto.io/api-reference/monitors/get-a-monitor
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /monitors/{monitorId}
# Get a monitor template
Source: https://docs.bronto.io/api-reference/monitors/get-a-monitor-template
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /monitors/templates/{templateId}
# List monitors associated with a log
Source: https://docs.bronto.io/api-reference/monitors/list-monitors-associated-with-a-log
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /logs/{logId}/monitors
# Retrieve monitor templates
Source: https://docs.bronto.io/api-reference/monitors/retrieve-monitor-templates
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /monitors/templates
Retrieves the list of monitor templates
# Retrieve monitors
Source: https://docs.bronto.io/api-reference/monitors/retrieve-monitors
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /monitors
Retrieves the list of currently configured monitors
# return the list of monitor notifications
Source: https://docs.bronto.io/api-reference/monitors/return-the-list-of-monitor-notifications
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /monitors/{monitorId}/notifications
# Update a monitor
Source: https://docs.bronto.io/api-reference/monitors/update-a-monitor
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml put /monitors/{monitorId}
Update an existing monitor
# Update a monitor template
Source: https://docs.bronto.io/api-reference/monitors/update-a-monitor-template
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml put /monitors/templates/{templateId}
Update an existing monitor template
# Update monitor status
Source: https://docs.bronto.io/api-reference/monitors/update-monitor-status
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /monitors/{monitorId}/status
Update the status of a monitor - only supports muting/unmuting
# Get Pattern templates for logs matching search criteria
Source: https://docs.bronto.io/api-reference/patterns/get-pattern-templates-for-logs-matching-search-criteria
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /patterns
Returns the Pattern IDs, templates, and source log ID for all logs matching the given search criteria.
# Retrieve permissions
Source: https://docs.bronto.io/api-reference/permissions/retrieve-permissions
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /permissions
Retrieves a list of all available permissions grouped by resource. Permissions define the individual actions that can be performed within the system, such as reading API keys or managing monitors. Permissions are assigned to roles, which in turn are assigned to users and API keys. Use the `/roles` endpoint to see how permissions are grouped into roles.
# List policies by resource
Source: https://docs.bronto.io/api-reference/policies/list-policies-by-resource
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /policies/resources/{resource_type}/{resource_id}
# Create a new role
Source: https://docs.bronto.io/api-reference/roles/create-a-new-role
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /roles
Creates a new role with specified permissions in the organization. Roles define sets of permissions that can be assigned to users to control their access to various system features and resources. The role must have a unique identifier and include at least one permission.
# Delete a role
Source: https://docs.bronto.io/api-reference/roles/delete-a-role
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /roles/{role_id}
Deletes a role by its ID.
# Retrieve a list of roles
Source: https://docs.bronto.io/api-reference/roles/retrieve-a-list-of-roles
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /roles
Retrieves a list of all roles in the organization along with their assigned permissions. A role groups together a set of permissions from the available permissions (see `/permissions`) and can be assigned to users and API keys to control access. Each role includes its full list of permissions, allowing you to understand exactly what actions a user or API key with that role can perform.
# Retrieve a specific role
Source: https://docs.bronto.io/api-reference/roles/retrieve-a-specific-role
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /roles/{role_id}
Retrieves a specific role by its ID, including the full list of permissions assigned to it. Permissions define what actions users or API keys with this role can perform. See `/permissions` for the complete list of available permissions, and `/roles` to list all roles.
# Update an existing role
Source: https://docs.bronto.io/api-reference/roles/update-an-existing-role
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml put /roles/{role_id}
Updates a role's properties and assigned permissions.
# Cancel an asynchronous search
Source: https://docs.bronto.io/api-reference/search/delete-search
delete /search/status/{statusId}
Cancel a long-running asynchronous Bronto search by its status identifier to stop the query and free up search capacity for other workloads.
# Execute a query
Source: https://docs.bronto.io/api-reference/search/execute-a-query
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /search
You can execute queries on your log data by using Bronto's syntax based on a subset of SQL as
described in the documentation https://docs.bronto.io/query-syntax/overview.
Bronto supports both the GET and POST methods for executing a query, however the POST method is
preferred as it avoids problems related to maximum URL length when the query parameters are very long.
In the context of the REST API, there are three distinct types queries which determine which parts of the
response object are populated:
+ Event search queries return a list of events matching the specified filter.
The response will be paginated if more than `limit` (default 50) matching events are returned.
+ Aggregate queries apply aggregate functions such as count(), sum(), max(), avg()
to your log data, and return a number or a timeseries of numbers.
+ Group by aggregate queries return numerical results grouped according to the values for the
attributes specified in the group by clause.
The query type is determined by the combination of the `select` and `groups` parameters.
# Execute a query
Source: https://docs.bronto.io/api-reference/search/execute-a-query-1
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /search
You can execute queries on your log data by using Bronto's syntax based on a subset of SQL as
described in the documentation https://docs.bronto.io/query-syntax/overview
Bronto supports both the GET and POST methods for executing a query, however the POST method is
preferred as it avoids problems related to maximum URL length when the query parameters are very long.
In the context of the REST API, there are three distinct types queries which determine which parts of the
response object are populated:
+ Event search queries return a list of events matching the specified filter.
The response will be paginated if more than `limit` (default 50) matching events are returned.
+ Aggregate queries apply aggregate functions such as count(), sum(), max(), avg()
to your log data, and return a number or a timeseries of numbers.
+ Group by aggregate queries return numerical results grouped according to the values for the
attributes specified in the group by clause.
The query type is determined by the combination of the `select` and `groups` parameters.
# Get asynchronous search status
Source: https://docs.bronto.io/api-reference/search/get-search-status
get /search/status/{statusId}
Poll the status, progress, and partial results of an asynchronous Bronto search query by its status identifier to track long-running search jobs.
# Execute a query
Source: https://docs.bronto.io/api-reference/search/post-search
post /search
You can execute queries on your log data by using Bronto's syntax based on a subset of SQL as
described in the documentation https://docs.bronto.io/query-syntax/overview
Bronto supports both the GET and POST methods for executing a query, however the POST method is
preferred as it avoids problems related to maximum URL length when the query parameters are very long.
In the context of the REST API, there are three distinct types queries which determine which parts of the
response object are populated:
+ Event search queries return a list of events matching the specified filter.
The response will be paginated if more than `limit` (default 50) matching events are returned.
+ Aggregate queries apply aggregate functions such as count(), sum(), max(), avg()
to your log data, and return a number or a timeseries of numbers.
+ Group by aggregate queries return numerical results grouped according to the values for the
attributes specified in the group by clause.
The query type is determined by the combination of the `select` and `groups` parameters.
# Execute a query
Source: https://docs.bronto.io/api-reference/search/search
get /search
You can execute queries on your log data by using Bronto's syntax based on a subset of SQL as
described in the documentation https://docs.bronto.io/query-syntax/overview.
Bronto supports both the GET and POST methods for executing a query, however the POST method is
preferred as it avoids problems related to maximum URL length when the query parameters are very long.
In the context of the REST API, there are three distinct types queries which determine which parts of the
response object are populated:
+ Event search queries return a list of events matching the specified filter.
The response will be paginated if more than `limit` (default 50) matching events are returned.
+ Aggregate queries apply aggregate functions such as count(), sum(), max(), avg()
to your log data, and return a number or a timeseries of numbers.
+ Group by aggregate queries return numerical results grouped according to the values for the
attributes specified in the group by clause.
The query type is determined by the combination of the `select` and `groups` parameters.
# Create a tag
Source: https://docs.bronto.io/api-reference/tags/create-a-tag
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /tags
Create a tag and associate it with an entity.
# Delete a tag
Source: https://docs.bronto.io/api-reference/tags/delete-a-tag
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /tags
# List tags
Source: https://docs.bronto.io/api-reference/tags/list-tags
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /tags/search
Retrieve a list of tags, optionally filtered by name, value, or entity type.
# Update a tag
Source: https://docs.bronto.io/api-reference/tags/update-a-tag
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml put /tags
Update the value of a tag.
# Retrieve the timeseries for a metric definition.
Source: https://docs.bronto.io/api-reference/timeseries/retrieve-the-timeseries-for-a-metric-definition
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /timeseries/{metric_definition_id}
# Run an ad-hoc timeseries query
Source: https://docs.bronto.io/api-reference/timeseries/run-an-ad-hoc-timeseries-query
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /timeseries/search
Execute a one-off timeseries query or formula directly. This is not saved. Use for interactive mode or metrics explorer.
# Retrieve top keys for logs
Source: https://docs.bronto.io/api-reference/top-keys/get-top-keys
get /top-keys
Retrieves the most frequently occurring keys (field names) from log events within a specified time range. This is useful for understanding the structure and common fields present in your log data. If no log ID is specified, top keys are returned for all accessible logs.
# Top Keys API
Source: https://docs.bronto.io/api-reference/top-keys/overview
Use the Bronto Top Keys REST API to retrieve the most frequent keys and values for a dataset to understand cardinality and inform query design.
# Retrieve top keys for logs
Source: https://docs.bronto.io/api-reference/top-keys/retrieve-top-keys-for-logs
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /top-keys
Retrieves the most frequently occurring keys (field names) from log events within a specified time range. This is useful for understanding the structure and common fields present in your log data. If no log ID is specified, top keys are returned for all accessible logs.
# Get the usage over a period of time for a log id.
Source: https://docs.bronto.io/api-reference/usage/get-usage-for-log-id
get /usage/organizations/logs
Retrieve Bronto ingestion and search usage for a specific log dataset over a chosen timeframe to monitor costs, capacity, and billing trends per log ID.
# Get the usage over a period of time for a user per log id.
Source: https://docs.bronto.io/api-reference/usage/get-usage-for-user-per-log-id
get /usage/users
Retrieve Bronto ingestion and search volume broken down by user and log dataset over a chosen timeframe to attribute usage and identify heavy consumers.
# Usage API
Source: https://docs.bronto.io/api-reference/usage/overview
Use the Bronto Usage REST API to track ingestion and search volume per dataset over a chosen timeframe and drill into per-user or per-log breakdowns.
# Create a new user
Source: https://docs.bronto.io/api-reference/users/create-a-new-user
post /users
Invite a new user to your Bronto organization with name, email, and an Admin, Standard, or ReadOnly role that controls their permissions across the platform.
# Deactivate a user
Source: https://docs.bronto.io/api-reference/users/deactivate-a-user
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /users/{userId}/deactivate
# Delete a user by ID
Source: https://docs.bronto.io/api-reference/users/delete-a-user-by-id
delete /users/{userId}
Permanently removes a user from the system. This action cannot be undone. All associated data and permissions for this user will be removed. Only administrators can delete users.
# Retrieve a user by ID
Source: https://docs.bronto.io/api-reference/users/get-a-single-user-by-id
get /users/{userId}
Retrieves detailed information for a specific user using their unique identifier. Returns all user attributes including profile information, roles, and status.
# Get user preferences
Source: https://docs.bronto.io/api-reference/users/get-user-preferences
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /users/{userId}/preferences
Returns the stored user preferences for the specified organization and user.
# List all organizations this user has access to
Source: https://docs.bronto.io/api-reference/users/list-all-organizations-this-user-has-access-to
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /users/{userId}/access
# Users API
Source: https://docs.bronto.io/api-reference/users/overview
Use the Bronto Users REST API to create, list, update, and delete users and assign Admin, Standard, or ReadOnly roles that control their permissions.
* "Admin" role has permission for all actions on all entities in the application.
* "Standard" role allows Read/Write and Delete actions on entities in non-sensitive areas of the application.
* "ReadOnly" role allows only read actions and only on entities in non-sensitive areas of the application.
# Patch user preferences
Source: https://docs.bronto.io/api-reference/users/patch-user-preferences
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml patch /users/{userId}/preferences
Sets or updates specific user preferences without overwriting others.
# Reactivate a user
Source: https://docs.bronto.io/api-reference/users/reactivate-a-user
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /users/{userId}/reactivate
# Resend a user's invitation email
Source: https://docs.bronto.io/api-reference/users/resend-a-users-invitation-email
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /users/{userId}/resend-invite
# Retrieve a list of users
Source: https://docs.bronto.io/api-reference/users/retrieve-a-list-of-users
get /users
List every user in your Bronto organization with their email, assigned role, and status to audit access or sync directory information into your tooling.
# Retrieve a list of users
Source: https://docs.bronto.io/api-reference/users/retrieve-a-list-of-users-1
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /users/all
# Retrieve a user by ID
Source: https://docs.bronto.io/api-reference/users/retrieve-a-user-by-id
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /users/{userId}
Retrieves detailed information for a specific user using their unique identifier. Returns all user attributes including profile information, roles, and status.
# Update a user
Source: https://docs.bronto.io/api-reference/users/update-a-user
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml patch /users/{userId}
Updates the specified user's information. Only the fields provided in the request body will be modified; other fields will remain unchanged. Users can typically update their own profiles, while administrators may update any user.
# Update a user
Source: https://docs.bronto.io/api-reference/users/updates-a-user
patch /users/{userId}
Updates the specified user's information. Only the fields provided in the request body will be modified; other fields will remain unchanged. Users can typically update their own profiles, while administrators may update any user.
# Append widgets to a widget
Source: https://docs.bronto.io/api-reference/widgets/append-widgets-to-a-widget
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /widgets/{id}/widgets
# Create a widget
Source: https://docs.bronto.io/api-reference/widgets/create-a-widget
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml post /widgets
# Delete a widget
Source: https://docs.bronto.io/api-reference/widgets/delete-a-widget
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /widgets/{id}
# Partially update a widget by ID
Source: https://docs.bronto.io/api-reference/widgets/partially-update-a-widget-by-id
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml patch /widgets/{id}
# Remove a widget from a widget
Source: https://docs.bronto.io/api-reference/widgets/remove-a-widget-from-a-widget
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml delete /widgets/{id}/widgets/{widgetId}
# Retrieve a widget
Source: https://docs.bronto.io/api-reference/widgets/retrieve-a-widget
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /widgets/{id}
# Retrieve all the widgets
Source: https://docs.bronto.io/api-reference/widgets/retrieve-all-the-widgets
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml get /widgets
# Update a widget
Source: https://docs.bronto.io/api-reference/widgets/update-a-widget
https://s3.eu-west-1.amazonaws.com/docs.brontobytes.io/redocusaurus/brontobytes.yaml put /widgets/{id}
# Changelog
Source: https://docs.bronto.io/changelog
Read the latest Bronto product updates, new features, integrations, and announcements, with release notes for log management, tracing, and AI features.
Bronto Tracing is now generally available.
You can now send OpenTelemetry traces to Bronto, explore service and operation health, and investigate latency, errors, and trace volume from the Tracing UI.
To get started, see [Send Traces to Bronto](/tracing/send-traces) and [Explore Traces](/tracing/explore-traces).
# Change Detection Monitors
Source: https://docs.bronto.io/core-features/change-detection
Detect spikes, drops, and shifts in metrics or telemetry with Bronto change detection monitors that compare current values against historical baselines.
Change detection monitors allow you to receive alerts when the value of a query changes significantly compared to a previous point in time.
This feature is useful for catching unexpected spikes, drops, or shifts in your data trends.
## Creating a Change Detection Monitor
To create a change detection monitor:
1. Navigate to **Monitors** and select **+ New Monitor**.
2. Choose **Change Detection** as the monitor type.
From here, you will configure the data source, query conditions, and alert thresholds.
## How Change Detection Works
A change detection monitor compares two queries over time:
1. The monitor first runs a query for the current evaluation window (e.g. the last 15 minutes).
2. It then runs the same query offset by a chosen timeframe in the past (e.g. 1 hour ago).
3. The monitor computes the difference between the two query results.
4. If the difference exceeds the defined threshold, an alert notification is triggered.
## Change Types
When configuring your monitor, you can specify how the change is measured:
* **Change**: The raw difference between the current and past values.
$$
a - b
$$
* **% Change**: The percentage difference relative to the past value.
$$
\frac{(a - b)}{b} \times 100
$$
## Alert Conditions
In the **Set Alert Conditions** step, you define the threshold for triggering an alert.
The following operators are supported:
* **Above**
* **Below**
* **Above or Equal**
* **Below or Equal**
An alert will be sent if the computed change meets the specified condition.
Note: When monitoring for drops (using a **below** operator), the threshold value should usually be negative.
For example, to alert on a 50% drop in volume, set the threshold to `-50` rather than `50`.
This sends an alert notification when the percentage change falls below `-50%`, in other words, there has been a 50% drop.
## Configuration Options
When creating a change detection monitor, you’ll need to configure the following:
1. **Source Dataset** – Select the dataset(s) on which the queries will be run.
2. **Filters** – (Optional) Narrow down results by applying filters.
3. **Aggregation Function** – Define how data points are aggregated (e.g. `count`, `average`, `max`, `sum`).
4. **Change Type** – Choose between **Change** or **% Change**.
5. **Evaluation Window** – The time period over which the aggregation is calculated (N minutes, hours, days, weeks, up to maximum of 1 month).
6. **Timeframe Offset** – How far back in time the comparison query should be run (N minutes, hours, days, weeks, up to maximum of 1 month ago).
This example shows the following conditions: The **% change** for the **count** of events with **response\_status:200** over the past **1 hour** compared to **4 hours ago**.
## Example Use Cases
* Detecting unusual traffic spikes compared to the same time yesterday.
* Monitoring error rates that suddenly increase compared to the previous hour.
* Tracking a drop in transaction volume relative to the past week.
# Custom Parser
Source: https://docs.bronto.io/core-features/custom-parser
Generate custom log parsers automatically with LLMs to extract structured fields from Apache, IIS, HAProxy, Syslog, and custom log formats in Bronto.
## Overview
Bronto's Custom Parser feature, powered by LLMs, enables you to automatically create custom log parsers for your specific data formats and requirements. Build, configure, and manage parsers that extract structured data from raw logs, transforming unstructured text into queryable, analyzable log events. Whether you're working with application logs, system logs, or custom formats, our custom parsing tool provides the flexibility to handle a diverse range of log data.
## Key Features
### Parser Creation and Configuration
Create custom parsers with intuitive naming and description fields to help your team understand each parser's purpose and functionality. Define exactly what data you want to extract and how it should be structured.
### Real-Time Log Processing
View raw log samples and see immediate parsing results as you configure your parser. Test your parsing logic against actual data before deploying to ensure accuracy and completeness.
### Structured Data Extraction
Transform unstructured log data into structured, columnar formats with configurably defined fields.
### Multi-Format Support Out of the Box
Built-in parsers for common log formats including:
* **Apache HTTP Server logs** – Extract client IPs, authentication details, timestamps, HTTP request elements, response codes, and transfer sizes.
* **Key-Value Pair logs** – Parse structured messages with field names, values, delimiters, and attribute groupings.
* **Microsoft IIS logs** – Process IIS server logs with timestamps, client/server IPs, request details, and processing times.
* **HAProxy logs** – Capture extended HAProxy data including client info, request/response details, timing metrics, and cookies.
* **Linux Syslog** – Extract timestamps, hostnames, process names, PIDs, users, and log messages.
### Dataset Management
Organize your parsing rules with dataset management:
* Browse raw datasets and parsed results
* Search and filter by dataset names
* View data volumes and processing statistics
* Track parser assignments and usage
### Performance Monitoring
Monitor parser performance with detailed metrics:
* Parse success rates
* Processing volume over time
* Parser efficiency analytics
See our [Parser Metrics API endpoint](https://docs.bronto.io/api-reference/parsers/get-the-parsers-usage-metrics-over-a-period-of-time-for-a-log-id-1) for details.
## Technical Details
Bronto uses **AWS Bedrock** as a managed service to access LLMs such as Claude. The infrastructure automatically selects the most appropriate model for each task and sends a structured prompt — for example, the AI log parser builds a prompt that instructs the model which patterns to avoid and how to handle keys such as timestamps. Model selection and prompt construction are handled automatically, so users can get started immediately without configuration.
AWS Bedrock also provides the following security and compliance benefits relevant to a SaaS environment:
* **Content safety** – Built-in safeguards to detect and filter harmful content
* **Data privacy** – It never stores or uses our data to train models
* **Network isolation** – All data remains within the AWS network
* **Native integration** – Works seamlessly with Lambda, S3, and other AWS services, allowing AI capabilities to be incorporated without rearchitecting existing systems
## Getting Started
1. Navigate to the **Parsing** section from the main Bronto navigation menu.
2. Select **"Dataset List"** to view available parsers or create new ones.
3. Choose a dataset from your data sources.
4. Configure your parser with appropriate field mappings.
5. Test with sample data to verify parsing accuracy. Ensure the dataset includes a minimum of **100 events from the last 24 hours**.
6. Deploy and monitor your parser's performance.
If you configure a custom parser, any dashboards, saved searches, or monitors
that rely on specific key names in the log may stop working if those keys are
renamed.
# Log Forwarding
Source: https://docs.bronto.io/core-features/log-forwarding
Forward Bronto log events to an external Amazon S3 bucket for archiving, long-term storage, compliance workflows, or downstream processing.
## Overview
Bronto supports outbound log forwarding so you can send log events outside of Bronto for archiving, long-term storage, compliance workflows, or downstream processing.
Forwarding is configured through the Bronto API. A forward config defines the destination, the logs to forward, optional filters, compression, and batching limits. The currently supported destination type is Amazon S3. If S3 does not fit your needs, contact support to request integrations with other destinations.
Common uses include:
* Archiving selected log events to your own S3 bucket
* Keeping an external copy of all current and future logs
* Sending only matching events, such as warnings and errors, to a long-term store
* Feeding downstream data processing or compliance review workflows
## How It Works
A forward config can forward either all logs or a specific list of log IDs.
When `all_logs` is set to `true`, Bronto forwards all logs in the account and automatically includes logs created in the future. When `all_logs` is set to `false`, provide the `log_ids` you want to forward.
You can also add a `filter` to forward only matching events. Filters use Bronto search syntax, so you can target specific severities, services, environments, or any indexed event fields.
Forwarded events are buffered and sent to S3 in payloads or batches. Depending on the volume of matching data and the batching configuration, it may take some time for enough events to be collected and uploaded. If data does not appear in S3 immediately after you create a forward config, wait for the next payload to be prepared and delivered.
Before creating a forward config, allow Bronto to write to the target S3 bucket. Add a bucket policy like the following, replacing `` with the name of the bucket where you want to receive forwarded log data:
```json theme={"dark"}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow Bronto to write data to the S3 bucket",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::637423326566:role/BrontoForwarder"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::",
"arn:aws:s3:::/*"
]
}
]
}
```
After updating the bucket policy, use the test destination endpoint to confirm Bronto can write to the target S3 bucket.
## Configure Forwarding
Use the API reference to create, test, update, retrieve, or delete forwarding configurations:
* [Create a new forward config](/api-reference/forward/create-new-config)
* [Test access to the destination](/api-reference/forward/test-access-to-destination)
* [Retrieve forward configs](/api-reference/forward/retrieve-forward-configs)
* [Update an existing forward config](/api-reference/forward/update-existing-config)
* [Delete a forward config](/api-reference/forward/delete-a-config)
## Destination Options
For S3 destinations, configure:
* `bucket`: the target S3 bucket name
* `prefix`: an optional key prefix, such as `bronto/archives/`
* `storage_class`: the S3 storage class for forwarded objects
Bronto supports `ZSTD`, `GZIP`, or no compression. `ZSTD` is recommended for reducing payload size.
# Monitoring Overview & Threshold Monitors
Source: https://docs.bronto.io/core-features/monitors
Create threshold monitors in Bronto to evaluate logs or metrics on a schedule and alert teams via email, webhooks, Slack, or PagerDuty.
## Overview
Bronto gives you the ability to create monitors that actively evaluate logs or metrics and notify your teams via email or custom webhooks.
## Create Monitors
To create monitors in Bronto:
Navigate to **Monitors** > **New Monitor**.
Choose a data source. Select **Datasets** to monitor log search results, or **Metrics** to monitor an OpenTelemetry metric.
Configure the query. For dataset monitors, select the dataset scope and apply a **filter** using Bronto's [search syntax](/query-syntax/search-syntax). For metric monitors, search for and select the metric you want to evaluate, then choose its aggregation function.
Evaluate the query or formula over the desired time from the predefined options in **minutes**, **hours** or **days**.
Set Alert Conditions. Configure monitors to trigger if the query or formula value crosses a threshold.
Lastly, give the monitor a **name**, **description** , **email address** which can be an existing user or a custom email or select an existing webhook where the notification will be sent to.
## Add Queries and Formulas
Use **+ Add Query** and **+ Add Formula** to build a monitor from more than one query result. Each query has a name, such as `errors`, `requests`, or `cpu`, which you can reference in a formula.
If a monitor includes more than one query, add a formula to combine the query results before configuring the alert condition.
### Add a Query
Select **+ Add Query** to add another independently configured query to the monitor. The new query can use a different data source, scope, filter, metric, aggregation, or grouping from the first query.
For Sum, Summary, and Histogram metrics, select **Rate of sum** to evaluate the sum of metric values per second, or **Rate of count** to evaluate the number of observations or metric points per second. For details and examples, see [Aggregation functions](/metrics/explore-metrics#aggregation-functions).
For example, to prepare a monitor that tracks the HTTP error rate:
1. Configure query `errors` to count requests with a status code of `500` or higher.
2. Select **+ Add Query**.
3. Configure query `requests` to count all requests.
The monitor now has the failed request count in `errors` and the total request count in `requests`.
### Add a Formula
Select **+ Add Formula** to calculate a value from numbers, query results, or a combination of both. Reference a query by entering its query name in the formula.
Formulas support:
* Parentheses: `(` and `)`
* Addition, subtraction, multiplication, and division: `+`, `-`, `*`, and `/`
* Numerical constants, including decimals, such as `100`, `5`, or `1.5`
* Variables that match the names of queries in the monitor
Variable names must be alphanumeric and start with a letter. Only variables based on query names in the monitor are allowed. You can reference any number of variables in a formula, and each monitor can include up to six queries.
You can also use `+` and `-` as unary operators to explicitly set the sign of a value. For example, `errors + -5`, `-requests + 1000`, and `errors + +requests` are valid formulas.
Continuing the HTTP error-rate example:
1. Select **+ Add Formula**.
2. Enter `errors / requests * 100` to calculate the percentage of requests that returned server errors.
3. Configure the alert condition against the formula result. For example, trigger the monitor when the error rate is above `5`.
This alerts when more than 5% of requests return server errors.
For metrics, formulas work the same way. For example, configure query `usage` as a CPU utilization metric and query `limit` as a CPU limit metric, then use `usage / limit * 100` to alert on percentage utilization.
## Setting Alert Conditions
The alert conditions can be configured to trigger if the query or formula value reaches a predefined threshold.
* Evaluate the query or formula over the last: *5 minutes*, *10 minutes*, *30 minutes*, *1 hour*, *2 hours*, *4 hours* or *1 day*. Evaluation is across a rolling time window in groups aligned from midnight.
* Evaluate if query is *above*, *above or equal to*, *below*, or *below or equal* to the threshold.
* Trigger if Alert Threshold literal value is matched.
For metric monitors, threshold unit selection is a display helper. It lets you enter the threshold in a convenient unit and formats the preview chart, but it does not change the trigger logic. Bronto translates the selected unit into the raw value used to create and evaluate the monitor.
Available aggregations depend on the query source and metric type. Metric monitors support the same aggregation functions as Metrics and Dashboards, including **Average**, **Count**, **Max**, **Min**, **Sum**, **Median**, **P25**, **P75**, **P90**, **P95**, **P99**, and **P999**, where supported by the selected metric type. Sum, Summary, and Histogram metrics also support **Rate of sum** and **Rate of count**. Rate functions are not available for Gauge metrics. The **Histogram** function and histogram views are not available in monitors; they are available in Dashboards and Metrics.
## Configure notifications
Configure your notification messages to include the information you are most interested in and specify which user, email or webhook to send these alerts to.
* Monitor Name.
* Monitor Description.
* View a preview of what the notification will look like.
If you are sending monitor alerts to a webhook, see [Sample Payload Schema](/integrations/webhooks#sample-payload-schema) for the available variables and JSON template options.
## Manage Monitors
Manage Monitors by editing, creating, bulk deleting and searching monitors all in the same place. From here you can easily view what email or webhook is associated to each monitor.
## View Monitor Details & Status
Selecting a monitor to review from your list allows you to see its details which include its filter, source and recipients. From this page you can also view the status and event history
## AI Investigation Reports
When a monitor fires, Bronto can automatically run an investigation and deliver a detailed report. This helps responders move from alert to diagnosis faster by attaching AI-generated analysis directly to the monitoring workflow.
Enable **AI Investigation Report** in the monitor configuration, then provide an **Investigation Prompt** to tell the AI what to check when the alert triggers.
For the full workflow, prompt guidance, and feature details, see [AI Investigation Reports](/ai-features/ai-investigation-reports).
# Patterns
Source: https://docs.bronto.io/core-features/patterns
Use Bronto Patterns to automatically group structurally similar log messages, search with precision, and analyze log frequency and volume.
## Overview
Patterns automatically identify the common message structures in your log data as it is ingested. No configuration, schema definitions, or instrumentation changes are required.
Log messages usually contain a static structure and dynamic values. For example, these events have the same structure even though their hostnames and retry counts differ:
```text theme={"dark"}
Connection to db-1.prod failed after 3 retries
Connection to db-2.prod failed after 7 retries
```
Bronto represents both events with a Pattern:
```text theme={"dark"}
Connection to hostname: failed after num_retries:
```
Each unique Pattern receives a stable Pattern ID. When an ingested log event matches a Pattern, Bronto writes the Pattern ID to the event as an attribute before storing it. The ID remains unchanged for the retention period of the associated log data.
Pattern IDs are first-class fields. You can use them to:
* Filter searches to a specific message structure
* Build logical query expressions
* Group events and graph Pattern frequency over time
* Identify the log statements generating the most volume
* Create monitor filters that continue to target the intended log structure
## How Pattern Discovery Works
Bronto automatically trains Patterns on up to the most recent **1 million events** in a dataset. If the dataset contains fewer events, Bronto trains on the events available.
Training typically completes within a few minutes of data first arriving, but there is no guaranteed completion time. After training completes, new events that match a discovered Pattern are annotated with its Pattern ID during ingestion.
Events ingested before Pattern training completes are not retroactively assigned
a Pattern ID.
Patterns that first appear after the training sample was collected may not be identified. A retraining mechanism may be added in the future to discover later message structures.
## Search and Analyze Patterns
Patterns let you search by message structure instead of relying only on text shared by potentially unrelated log messages.
For example, a text search for `timeout` might match several different code paths:
```text theme={"dark"}
Request to payments timed out after 10s
Lock acquisition timed out for key:checkout
Client connection timed out:192.0.2.10
```
With Patterns, you can select or query the specific message structure you want to investigate. Because the Pattern ID is stored as an event attribute, Pattern queries use Bronto's indexing and can be combined with other attributes.
For example:
```sql theme={"dark"}
("$pattern_id" IN ('66fadcfb98d5c032', '4a465fe8dd5fbecd') AND response_code >= 500)
OR ("$pattern_id" != '7c23016da7db413e' AND error IS NOT NULL)
```
See [Search Syntax](/query-syntax/search-syntax) for details about building queries.
### Group and Visualize
Group by the Pattern ID to see the distinct message structures in a dataset and compare their frequency. This can help you:
* Understand the normal behavior of an unfamiliar service
* Identify Patterns that appear only during errors
* Spot high-volume or noisy log statements
* Track changes in log volume and investigate ingestion costs
## Use Patterns in Monitors
You can use a Pattern ID in a monitor's filter to target a specific log structure. This avoids matching new, unrelated log messages that happen to contain the same words as the original event.
For example, a text filter for `payment failed` could later match a recoverable `payment failed, retrying in 5s` message. A filter using the original Pattern ID continues to match only the selected message structure.
See [Monitoring Overview & Threshold Monitors](/core-features/monitors) for information about creating monitor queries.
There is currently no dedicated Pattern-based alerting workflow in the UI.
Bronto does not yet provide alerts for a newly discovered Pattern or an
anomalous change in a Pattern's frequency.
## Inferred Value Types
Bronto attempts to infer the type of each dynamic value and replaces it with a corresponding placeholder.
| Placeholder | Description |
| - | - |
| `<*>` | A wildcard used when a more specific type cannot be inferred, typically when a value can be a string or number |
| `` | A UUID |
| `` | A URL |
| `` | A timestamp |
| `` | A Boolean value |
| `` | An IPv4 address |
| `` | A semantic version, such as `4.7.12` |
| `` | A number followed by a time unit, such as `10ms`, `2m`, or `5h` |
| `` | A floating-point number |
| `` | A value observed as both a float and an integer |
| `` | An integer |
| `` | A value from the event's hostname field |
| `` | A default AWS EC2 hostname, such as `ip-123-123-123-123` |
| `` | A string |
## Getting Started
Patterns are enabled automatically for logs sent to Bronto. No changes to your logging configuration are required.
1. Send log data to a Bronto dataset.
2. Allow Pattern training to complete. This typically takes a few minutes after data first arrives.
3. Search or group by the `$pattern_id` event attribute.
4. Use a Pattern ID in queries, visualizations, or monitor filters like any other event field.
Detected Patterns are also available through the `/patterns` API endpoint.
# Service Level Objectives (SLOs)
Source: https://docs.bronto.io/core-features/service-level-objectives
Create trace-based service level objectives in Bronto using availability or latency indicators, targets, time windows, and notifications.
Service Level Objectives (SLOs) turn request tracing data into measurable reliability targets for individual services and endpoints. In Bronto, you can measure availability or latency, set a target over a time window, and optionally send a notification when attainment reaches a threshold.
## SLO concepts
| Term | Meaning |
| - | - |
| **Service Level Indicator (SLI)** | The measurement used to evaluate service behavior, such as the percentage of successful or sufficiently fast requests. |
| **Service Level Objective (SLO)** | The target value an SLI should meet over a selected time window. |
| **Attainment** | The percentage of valid requests that currently meet the objective. |
| **Error budget** | The percentage of valid requests allowed to miss the objective. A 99% target provides a 1% error budget. |
SLOs use request entry spans. Before creating one, make sure the service is sending traces with a `service.name`, endpoint information, request duration, and the status attributes needed to identify errors. See [Send Traces to Bronto](/tracing/send-traces).
## Find SLO candidates
Select **SLOs** from the left navigation. Bronto analyzes request spans from the previous 28 days and suggests services and endpoints that may benefit from an objective.
Each candidate summarizes its:
* service and endpoint
* success rate
* p95 latency
* request volume
* recent error-rate or latency trend
Use the service filter to narrow the list, or select **Rescan** to refresh the candidates. Select **Set an objective** beside a candidate to prefill its service and endpoint. To start without a candidate, select **New objective manually**.
## Create an objective
Select a service and endpoint.
Choose **Availability** or **Latency** as the SLI.
Set the target percentage and select a rolling or calendar window.
Name the objective and optionally configure a notification.
Review the live preview and objective summary, then select **Create objective**.
### Choose an SLI
Availability measures the share of valid requests that did not fail. Bronto evaluates one designated entry span per request.
Select the service and endpoint, then define the **Error Indicator** that identifies a failed request. For example, `NOT ("http.response.status_code" < 500)` treats responses with a status code of `500` or greater as errors.
Latency measures the share of valid requests completed faster than a threshold you set.
Select the service and endpoint, then enter the **Latency Threshold** in milliseconds. Requests faster than this threshold count as good requests.
### Set the target and window
Enter the percentage of requests that must meet the SLI. For example, a target of `99%` requires 99 out of every 100 valid requests to be successful or faster than the selected threshold.
Choose how Bronto evaluates the target:
* **Rolling** continuously evaluates the most recent window.
* **Calendar** evaluates the selected calendar-aligned window.
Select the required window length from the available options, such as 7, 28, or 30 days.
### Configure notifications
Give the objective a descriptive name. To receive an alert, enable **Notify me when attainment hits a threshold**, then select a configured notification channel and destination, such as a Slack channel. See [Slack notifications](/integrations/slack) for setup instructions.
The **Live preview** and **Objective Summary** update as you configure the objective. Use them to confirm the scope, SLI, target, window, and notification settings before creating it.
Nothing is saved until you select **Create objective**. After creation, the error budget can take up to two minutes to become available.
# Bronto Ingestion Endpoints
Source: https://docs.bronto.io/getting-started/bronto-endpoints
Reference for Bronto's ingestion endpoints, including supported formats, OTLP and HTTP routes, regional URLs, authentication, and when to use each.
## Overview
Bronto exposes two distinct endpoint types. Using the wrong one is the most common cause of `400` errors — confirm which applies to your agent before configuring.
We recommend routing logs, metrics, and traces through the OpenTelemetry Collector rather than sending HTTP requests directly. The Collector handles batching, compression, and retries on failure. Log forwarders such as Fluent Bit, Logstash, and Vector remain a good choice for log-only sources. Direct HTTP is supported for cases where running an agent isn't practical.
| Endpoint | Accepts | Typical clients | Where the signal appears |
| - | - | - | - |
| `ingestion.eu.bronto.io` / `ingestion.us.bronto.io` | Logs in JSON, syslog, logfmt, CEF, or raw text | Fluent Bit, Logstash, FireLens, EventBridge, custom HTTP | A dataset and collection in Log Search |
| `ingestion.eu.bronto.io/v1/logs` / `ingestion.us.bronto.io/v1/logs` | OTLP protobuf or OTLP/JSON logs | OpenTelemetry Collector or SDK | A dataset and collection in Log Search |
| `ingestion.eu.bronto.io/v1/metrics` / `ingestion.us.bronto.io/v1/metrics` | OTLP protobuf or OTLP/JSON metrics | OpenTelemetry Collector or SDK | [Metric Explorer](/metrics/explore-metrics); not a dataset or collection |
| `ingestion.eu.bronto.io/v1/traces` / `ingestion.us.bronto.io/v1/traces` | OTLP protobuf or OTLP/JSON traces | OpenTelemetry Collector or SDK | [Explore Traces](/tracing/explore-traces); not a dataset or collection |
## Authentication
All endpoints accept the Bronto API key header:
```
x-bronto-api-key:
```
The base ingestion endpoint also supports HTTP Basic authentication for products that provide a fixed authentication menu instead of custom headers:
| Field | Value |
| - | - |
| Username | Any non-empty value, such as `bronto` |
| Password | Your Bronto API key with the Ingestion role |
```bash Basic authentication theme={"dark"}
curl -u "bronto:" \
-H "Content-Type: application/json" \
--data-binary '{"message":"authenticated with HTTP Basic"}' \
"https://ingestion..bronto.io/?service_namespace=&service_name="
```
The username is ignored; the API key must be the password. Basic authentication applies to the base endpoint used for logs. Continue to use the `x-bronto-api-key` header for OTLP logs, metrics, and traces.
See [API Keys](/Account-Management/API-Keys) for how to generate a key.
***
## Base Endpoint
The base endpoint (no path) accepts any payload format and performs no schema validation. It is the right choice for any agent that sends JSON, plain text, or structured log lines over HTTP.
### Automatically parsed formats
For the following formats, Bronto detects and extracts fields automatically — no configuration required.
| Format | Fields extracted |
| - | - |
| **Structured JSON** (Logrus, Winston, etc.) | All top-level key-value fields |
| **Nested JSON** | Nested objects flattened to dot notation — e.g. `context.user`, `context.request_id` |
| **RFC 5424 Syslog** | `pri`, `facility`, `severity`, `hostname`, `appname`, `procid`, `msgid`, `timestamp`, `version` |
| **Logfmt** | All key=value pairs — e.g. `level`, `msg`, `user`, `duration`. Also parsed when logfmt appears as the value of a JSON `message` field |
| **GELF** | `version`, `host`, `short_message`, `level`, and underscore-prefixed custom fields |
| **Log4j2 JSON** | `level`, `loggerName`, `message`, `thread`, `instant.epochSecond`, `instant.nanoOfSecond`, nested `thrown` fields |
| **CEF** | CEF version and extension key-value pairs — e.g. `src`, `dst`, `suser` |
### Formats stored verbatim
Other formats — RFC 3164 BSD syslog, Apache Common Log, Docker JSON, raw text — are accepted and stored as-is. Most log forwarders and the OpenTelemetry Collector can parse or transform these into structured fields before sending. If you are sending data directly, use the [custom parser](/core-features/custom-parser) to define extraction rules.
***
## OTLP Endpoints
The `/v1/logs`, `/v1/metrics`, and `/v1/traces` endpoints accept OTLP over HTTPS on port `443` in **both protobuf and JSON encoding**. The OpenTelemetry Collector handles OTLP serialisation, batching, and retry automatically.
| Signal | EU | US |
| - | - | - |
| Logs | `https://ingestion.eu.bronto.io/v1/logs` | `https://ingestion.us.bronto.io/v1/logs` |
| Metrics | `https://ingestion.eu.bronto.io/v1/metrics` | `https://ingestion.us.bronto.io/v1/metrics` |
| Traces | `https://ingestion.eu.bronto.io/v1/traces` | `https://ingestion.us.bronto.io/v1/traces` |
Dataset and collection routing applies only to logs. Metrics and traces retain OpenTelemetry resource attributes such as `service.name`, but they do not create or appear in datasets or collections. Use the Metric Explorer for metrics and Explore Traces for traces.
### Encodings
Set `Content-Type` to match the encoding you send. Protobuf remains the default for the Collector and the OTel SDKs, and is the more compact option on the wire.
| Encoding | `Content-Type` |
| - | - |
| OTLP protobuf | `application/x-protobuf` |
| OTLP/JSON | `application/json` |
OTLP/JSON is useful when a client cannot produce protobuf — a script, a serverless function, or a platform that only emits JSON over HTTP. The body must be a single JSON object matching the OTLP request schema for that signal (for example `ExportLogsServiceRequest` for `/v1/logs`), not NDJSON.
```bash OTLP/JSON logs theme={"dark"}
curl -X POST https://ingestion.eu.bronto.io/v1/logs \
-H "x-bronto-api-key: " \
-H "Content-Type: application/json" \
--data-binary '{
"resourceLogs": [{
"resource": {
"attributes": [
{"key": "service.name", "value": {"stringValue": ""}},
{"key": "service.namespace", "value": {"stringValue": ""}}
]
},
"scopeLogs": [{
"logRecords": [{
"timeUnixNano": "1705314600000000000",
"severityText": "INFO",
"body": {"stringValue": "user login successful"}
}]
}]
}]
}'
```
To send OTLP/JSON from an OpenTelemetry Collector, set `encoding: json` on the `otlphttp` exporter:
```yaml otel-config.yaml theme={"dark"}
exporters:
otlphttp:
endpoint: https://ingestion.eu.bronto.io
encoding: json
headers:
x-bronto-api-key:
```
OTel SDKs select the encoding through the exporter protocol — `http/protobuf` or `http/json`, set with `OTEL_EXPORTER_OTLP_PROTOCOL`. Not every language SDK implements `http/json`; check your SDK before switching.
Bronto supports OTLP sums, gauges, summaries, and explicit histograms. Exponential histograms are not currently supported. You can calculate per-second rates for Sum, Summary, and Histogram metrics after ingestion; see [Aggregation functions](/metrics/explore-metrics#aggregation-functions).
Trace data must go to `/v1/traces`. Sending traces to the base endpoint stores them as log events — trace correlation and the traces UI will not work.
***
## Direct HTTP Custom Ingestion
If running a log forwarder or collector isn't practical, you can POST log events directly to the base endpoint from any HTTP client or script.
### Request format
All requests must be `POST` with a JSON Lines (NDJSON) body — one JSON object per line.
**Authentication**
Authenticate with either the `x-bronto-api-key` header or HTTP Basic authentication as described above. Do not send the API key in a URL query parameter.
**Required request header**
| Header | Value |
| - | - |
| `Content-Type` | `application/json` |
**Recommended headers**
These headers control how log data is organized in Bronto. They do not route metrics or traces. See [Data Organization](/Search-and-Visualize/Partitions) for how log datasets, collections, and tags work.
| Header | Description |
| - | - |
| `x-bronto-dataset` | Dataset to ingest into |
| `x-bronto-collection` | Collection name |
| `x-bronto-tags` | Comma-separated tags to attach to events |
Products that support Basic authentication but cannot set routing headers can use `service_name` and `service_namespace` query parameters:
```text theme={"dark"}
https://ingestion..bronto.io/?service_namespace=&service_name=
```
These parameters override `x-bronto-dataset` and `x-bronto-collection` when both forms are present. Parameters named `header_x-bronto-*` are not supported.
**Other headers**
| Header | Description |
| - | - |
| `Content-Encoding` | Compression format: `gzip`, `zstd`, or `deflate` |
**Event fields**
| Field | Required | Description |
| - | - | - |
| `message` | Yes | The log content string |
| `timestamp` | Recommended | ISO 8601 timestamp — e.g. `2024-01-15T10:30:00Z` |
### Examples
```bash Uncompressed theme={"dark"}
curl -X POST https://ingestion.eu.bronto.io \
-H "x-bronto-api-key: " \
-H "Content-Type: application/json" \
--data-binary '{"timestamp":"2024-01-15T10:30:00Z","message":"user login successful","user":"alice"}
{"timestamp":"2024-01-15T10:30:01Z","message":"request completed","status":200}'
```
```bash gzip theme={"dark"}
echo '{"timestamp":"2024-01-15T10:30:00Z","message":"user login successful"}' | \
gzip | \
curl -X POST https://ingestion.eu.bronto.io \
-H "x-bronto-api-key: " \
-H "Content-Type: application/json" \
-H "Content-Encoding: gzip" \
--data-binary @-
```
```bash Zstandard theme={"dark"}
echo '{"timestamp":"2024-01-15T10:30:00Z","message":"user login successful"}' | \
zstd | \
curl -X POST https://ingestion.eu.bronto.io \
-H "x-bronto-api-key: " \
-H "Content-Type: application/json" \
-H "Content-Encoding: zstd" \
--data-binary @-
```
Zstandard offers the best compression ratio and is recommended for high-volume pipelines.
### Batch processing
For large files, split into chunks and send each one:
```bash Batch ingest from file theme={"dark"}
#!/bin/bash
FILE="logs.ndjson"
BATCH_SIZE=5000
API_KEY=""
ENDPOINT="https://ingestion.eu.bronto.io"
split -l $BATCH_SIZE "$FILE" /tmp/batch_
for batch in /tmp/batch_*; do
gzip -c "$batch" | curl -s -X POST "$ENDPOINT" \
-H "x-bronto-api-key: $API_KEY" \
-H "Content-Type: application/json" \
-H "Content-Encoding: gzip" \
--data-binary @-
echo "Sent $batch"
done
rm /tmp/batch_*
```
### Compression ratios
Compressing payloads before sending reduces transfer size significantly. Typical ratios for CDN logs:
| Algorithm | `Content-Encoding` value | Typical ratio |
| - | - | - |
| gzip | `gzip` | \~7.8% |
| Zstandard | `zstd` | \~6.0% |
| Deflate | `deflate` | \~7.8% |
### Payload limits
| Payload type | Maximum size |
| - | - |
| Uncompressed | 10 MB |
| Compressed (wire size) | 10 MB |
| Per line / entry | 256 KB (262,144 bytes) |
Exceeding the payload size limits returns an HTTP `413`.
### Response codes
| Code | Meaning |
| - | - |
| `200` | Events ingested |
| `400` | Malformed request or invalid JSON |
| `401` | Invalid or missing API key |
| `413` | Payload exceeds size limit |
| `429` | Rate limit or quota exhausted |
A `200` response means your data has been securely stored — no data will be lost. If the API returns an error, no data from that request is ingested.
# Custom Log Ingestion
Source: https://docs.bronto.io/getting-started/custom-ingestion
Send log events directly to Bronto via HTTP using the Ingestion API — with full control over compression, batching, metadata, and authentication.
The Bronto Ingestion API lets you POST log events directly to Bronto from any HTTP client or script. This is useful when you need to build a custom pipeline, integrate with an existing system, or ingest logs programmatically without an agent.
## Prerequisites
You'll need an API key with ingestion or admin permissions. See [API Keys](/Account-Management/API-Keys) for how to create one.
## Endpoints
* `https://ingestion.eu.bronto.io` — EU region
* `https://ingestion.us.bronto.io` — US region
OTLP logs can also be sent to `https://ingestion.eu.brontobytes.io/v1/logs` or `https://ingestion.us.brontobytes.io/v1/logs`.
## Request Format
All requests must be `POST` with a JSON Lines (NDJSON) body — one JSON object per line.
### Required headers
| Header | Value |
| - | - |
| `x-bronto-api-key` | Your Bronto API key |
| `Content-Type` | `application/json` |
### Recommended headers
These headers control how log data is organized in Bronto. See [Data Organization](/Search-and-Visualize/Partitions) for how log datasets, collections, and tags work.
| Header | Description |
| - | - |
| `x-bronto-dataset` | Dataset to ingest into |
| `x-bronto-collection` | Collection name |
| `x-bronto-tags` | Comma-separated tags to attach to events |
### Other headers
| Header | Description |
| - | - |
| `Content-Encoding` | Compression format: `gzip`, `zstd`, or `deflate` |
### Event schema
Each line in the request body should be a JSON object with the following fields:
| Field | Required | Description |
| - | - | - |
| `message` | Yes | The log content string |
| `timestamp` | Recommended | ISO 8601 timestamp (e.g. `2024-01-15T10:30:00Z`) |
## Send logs
### Uncompressed
```bash Send logs theme={"dark"}
curl -X POST https://ingestion.eu.bronto.io \
-H "x-bronto-api-key: " \
-H "Content-Type: application/json" \
--data-binary '{"timestamp":"2024-01-15T10:30:00Z","message":"user login successful","user":"alice"}
{"timestamp":"2024-01-15T10:30:01Z","message":"request completed","status":200}'
```
### With gzip compression
```bash Send logs with gzip theme={"dark"}
echo '{"timestamp":"2024-01-15T10:30:00Z","message":"user login successful"}' | \
gzip | \
curl -X POST https://ingestion.eu.bronto.io \
-H "x-bronto-api-key: " \
-H "Content-Type: application/json" \
-H "Content-Encoding: gzip" \
--data-binary @-
```
### With Zstandard compression
```bash Send logs with zstd theme={"dark"}
echo '{"timestamp":"2024-01-15T10:30:00Z","message":"user login successful"}' | \
zstd | \
curl -X POST https://ingestion.eu.bronto.io \
-H "x-bronto-api-key: " \
-H "Content-Type: application/json" \
-H "Content-Encoding: zstd" \
--data-binary @-
```
### With deflate compression
```bash Send logs with deflate theme={"dark"}
echo '{"timestamp":"2024-01-15T10:30:00Z","message":"user login successful"}' | \
python3 -c "import sys,zlib; sys.stdout.buffer.write(zlib.compress(sys.stdin.buffer.read()))" | \
curl -X POST https://ingestion.eu.bronto.io \
-H "x-bronto-api-key: " \
-H "Content-Type: application/json" \
-H "Content-Encoding: deflate" \
--data-binary @-
```
## Batch processing
For large files, use a shell script to split the file into chunks and send each one:
```bash Batch ingest from file theme={"dark"}
#!/bin/bash
FILE="logs.ndjson"
BATCH_SIZE=5000
API_KEY=""
ENDPOINT="https://ingestion.eu.bronto.io"
split -l $BATCH_SIZE "$FILE" /tmp/batch_
for batch in /tmp/batch_*; do
gzip -c "$batch" | curl -s -X POST "$ENDPOINT" \
-H "x-bronto-api-key: $API_KEY" \
-H "Content-Type: application/json" \
-H "Content-Encoding: gzip" \
--data-binary @-
echo "Sent $batch"
done
rm /tmp/batch_*
```
## Compression ratios
Compressing payloads before sending reduces transfer size significantly. Typical compression ratios for CDN logs:
| Algorithm | `Content-Encoding` value | Typical ratio |
| - | - | - |
| gzip | `gzip` | \~7.8% |
| Zstandard | `zstd` | \~6.0% |
| Deflate | `deflate` | \~7.8% |
Zstandard offers the best compression ratio and is recommended for high-volume pipelines.
## Payload size limits
| Payload type | Maximum size |
| - | - |
| Uncompressed | 10 MB (10,485,760 bytes) |
| Compressed (wire size) | 10 MB (10,485,760 bytes) |
Exceeding these limits returns an HTTP `413` response.
## Response codes
| Code | Meaning |
| - | - |
| `200` | Success — events ingested |
| `400` | Malformed request or invalid JSON |
| `401` | Invalid or missing API key |
| `413` | Payload exceeds size limit |
| `429` | Rate limit or quota exhausted |
| `500` | Server error |
## Reliable delivery
A `200` response means your data has been securely stored and will be ingested — no data will be lost. If the API returns an error response, no data from that request will be ingested.
Bronto is built for reliable, end-to-end delivery. Once you receive a `200`, your logs are safe.
# Glossary
Source: https://docs.bronto.io/getting-started/glossary
Definitions for Bronto-specific terms used across the documentation, including datasets, collections, partitions, monitors, and ingestion concepts.
This glossary defines the Bronto-specific terms used across the docs.
Use this page as the source of truth for product terminology. If a page uses a term differently, update that page to match the definitions below.
## A
### Agent
An **[agent](/agent-setup/agent-intro)** is software you run or configure to send log data into Bronto from hosts, services, or platforms.
### API Key
An **[API key](/Account-Management/API-Keys)** is a credential used to authenticate programmatic access to Bronto APIs and integrations such as [Local MCP](/ai-features/local-mcp).
## B
### BrontoScope
**[BrontoScope](/ai-features/brontoscope)** is Bronto’s AI investigation feature. It analyzes an error event, identifies likely causes and impact, and returns recommended next steps with supporting evidence.
## C
### Collection
A **[collection](/Search-and-Visualize/Partitions)** is a logical grouping of log datasets. Use collections to organize related log datasets and to separate datasets that may share the same name in different environments. Metrics and traces do not belong to collections.
### Custom Parser
**[Custom Parser](/core-features/custom-parser)** is Bronto’s LLM-assisted parsing feature. It converts raw, unstructured logs into structured, queryable events.
## D
### Dashboard
A **[dashboard](/Search-and-Visualize/Dashboards)** is a saved visual view of query results used to monitor systems, services, or trends over time.
### Dataset
A **[dataset](/Search-and-Visualize/Partitions)** is Bronto’s fundamental unit of log storage. It contains log events that share a similar origin or format and is always queried as a unit. Metrics and traces are stored separately and appear in the [Metric Explorer](/metrics/explore-metrics) and [Explore Traces](/tracing/explore-traces), not in datasets.
## E
### Event
An **[event](/Search-and-Visualize/Log-Search)** is a single log record stored in Bronto.
## H
### Hosted MCP
**[Hosted MCP](/ai-features/hosted-mcp)** is Bronto’s managed MCP server. It lets supported AI clients connect to Bronto over Bronto-hosted infrastructure using Bronto authentication.
## I
### Ingestion
**[Ingestion](/getting-started/quick-ingestion)** is the process of sending log data into Bronto.
## L
### Local MCP
**[Local MCP](/ai-features/local-mcp)** is Bronto’s self-hosted MCP server. You run it locally and connect AI agents to Bronto using your API key and regional API endpoint.
### Log Search
**[Log Search](/Search-and-Visualize/Log-Search)** is Bronto’s main search experience for exploring events, filtering data, and running queries across large volumes of logs.
## M
### MCP
**[MCP](/ai-features/hosted-mcp)** stands for **Model Context Protocol**. In Bronto, it refers to the protocol used to let AI tools access Bronto data and search capabilities through [Hosted MCP](/ai-features/hosted-mcp) or [Local MCP](/ai-features/local-mcp).
### My Data
**[My Data](/My-Data/My-Data)** is the Bronto page for managing collections and datasets, reviewing parser coverage and data quality, and understanding ingestion and search usage across your account.
### Monitor
A **[monitor](/core-features/monitors)** is an automated rule that evaluates a query or condition and triggers an alert when that condition is met.
## N
### Notification Channel
A **notification channel** is the destination used for [monitor](/core-features/monitors) alerts, such as [Slack](/integrations/slack) or a [webhook](/integrations/webhooks).
## O
### Organization
An **[organization](/Account-Management/Multi-Org)** is the top-level Bronto account boundary for users, settings, datasets, access controls, and billing or usage.
## P
### Partition Tag
A **[partition tag](/Search-and-Visualize/Partitions)** is a special organization-level tag used to control how incoming data is grouped into collections and datasets. Partition tags should be stable, low-cardinality attributes such as environment, region, or service.
## Q
### Query
A **[query](/query-syntax/search-syntax)** is an instruction used in Bronto to search, filter, aggregate, or analyze log data.
## S
### Saved Search
A **[saved search](/Search-and-Visualize/Saved-Searches)** preserves a query and its related view settings — including column selection and ordering — for reuse.
### Search
**[Search](/Search-and-Visualize/Log-Search)** is the act of querying log data in Bronto to find events, patterns, or trends.
### SSO
**[SSO](/Account-Management/SSO/SSO-Overview)** stands for **single sign-on**. In Bronto, it refers to centralized authentication through an identity provider.
## T
### Tag
A **tag** is a key-value label assigned to a [dataset](/Search-and-Visualize/Partitions). Tags help categorize datasets and make them easier to find, group, and query.
### Threshold Monitor
A **[threshold monitor](/core-features/monitors)** is a monitor that alerts when a query result crosses a defined value.
### Trace
A **[trace](/tracing/explore-traces)** is the end-to-end record of a request as it moves through services, captured as a set of spans. [Send traces](/tracing/send-traces) to Bronto using OpenTelemetry, then [explore](/tracing/explore-traces) them to investigate latency, errors, and service dependencies.
# Try Bronto with the OpenTelemetry Demo
Source: https://docs.bronto.io/getting-started/otel-demo
Run the OpenTelemetry Demo (Astronomy Shop) locally and route its logs, metrics, and traces to Bronto to explore real, correlated telemetry.
The [OpenTelemetry Demo](https://opentelemetry.io/docs/demo/) — the "Astronomy Shop" — is a microservices application maintained by the OpenTelemetry project. It runs around 20 services written in different languages, emits logs, traces, and metrics, and ships a built-in load generator that keeps realistic traffic flowing. It's the fastest way to see what Bronto looks like with real, correlated data when you don't yet have your own application instrumented.
Because every service in the demo already exports to a bundled **OpenTelemetry Collector**, "trying Bronto" mostly means adding a Bronto exporter to a configuration you don't have to write yourself.
## What you'll see
Once data is flowing, Bronto will show:
* **Traces** spanning the full checkout flow across services (frontend → cart → checkout → payment → shipping, and more).
* **Logs** automatically correlated to those traces via `trace_id`, so you can jump from a log line to the request that produced it.
* **Metrics** for request volume, latency, runtime behavior, and service health in the Metric Explorer.
* A `service.name` per microservice, used to filter metrics and traces and mapped to a Bronto Dataset for logs only. Metrics and traces do not appear in datasets or collections.
Exponential histograms are not supported. For Sum, Summary, and Histogram metrics, use **Rate of sum** or **Rate of count** in the Metric Explorer to visualize per-second rates.
## Prerequisites
* A Bronto API key — see [API Keys](/Account-Management/API-Keys) to create one.
* Your Bronto region (`eu` or `us`). The examples below use the EU endpoints; swap in `us` if that's your region. See [Ingestion Endpoints](/getting-started/bronto-endpoints).
* Either **Docker** (with Docker Compose) or a **Kubernetes** cluster with **Helm**.
## Step 1 — Get the demo
```bash Docker Compose theme={"dark"}
git clone https://github.com/open-telemetry/opentelemetry-demo.git
cd opentelemetry-demo
```
```bash Helm theme={"dark"}
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update
```
## Step 2 — Add Bronto as an exporter
The demo's Collector is designed to be extended. Add a Bronto `otlphttp` exporter and append it to the existing **logs**, **metrics**, and **traces** pipelines.
The OpenTelemetry Collector merges config files but **replaces** lists rather than appending to them. When you redefine a pipeline's `exporters`, you must repeat the demo's upstream exporters so they keep working alongside Bronto.
The demo provides a dedicated, normally-empty extension file for exactly this purpose. Edit `src/otel-collector/otelcol-config-extras.yml`:
```yaml src/otel-collector/otelcol-config-extras.yml theme={"dark"}
exporters:
otlphttp/bronto:
logs_endpoint: https://ingestion.eu.bronto.io/v1/logs
metrics_endpoint: https://ingestion.eu.bronto.io/v1/metrics
traces_endpoint: https://ingestion.eu.bronto.io/v1/traces
compression: none
headers:
x-bronto-api-key:
service:
pipelines:
traces:
# repeat the upstream exporters, then add Bronto
exporters: [otlp_grpc/jaeger, debug, span_metrics, otlphttp/bronto]
logs:
exporters: [opensearch, debug, otlphttp/bronto]
metrics:
# repeat the current upstream exporters, then add Bronto
exporters: [otlphttp/prometheus, debug, otlphttp/bronto]
```
Replace `` with your key and adjust the region in both endpoints if you're on US.
The upstream exporter names above (`otlp_grpc/jaeger`, `span_metrics`, `opensearch`, …) are listed in the comments at the top of `otelcol-config-extras.yml`. If a future version of the demo changes them, copy the current names from that file so you don't drop the demo's own backends.
Override the bundled Collector config through the chart's values. Create `bronto-values.yaml`:
```yaml bronto-values.yaml theme={"dark"}
opentelemetry-collector:
config:
exporters:
otlphttp/bronto:
logs_endpoint: https://ingestion.eu.bronto.io/v1/logs
metrics_endpoint: https://ingestion.eu.bronto.io/v1/metrics
traces_endpoint: https://ingestion.eu.bronto.io/v1/traces
compression: none
headers:
x-bronto-api-key:
service:
pipelines:
traces:
# repeat the upstream exporters, then add Bronto
exporters: [otlp, debug, spanmetrics, otlphttp/bronto]
logs:
exporters: [opensearch, debug, otlphttp/bronto]
metrics:
# repeat the chart's current upstream exporters, then add Bronto
exporters: [otlphttp/prometheus, debug, otlphttp/bronto]
```
The same list-replace rule applies: include the chart's existing exporters for each pipeline. Inspect the rendered defaults with `helm show values open-telemetry/opentelemetry-demo` if you're unsure of the current names.
Avoid committing your API key. Reference a Kubernetes Secret instead, or pass the key with `--set 'opentelemetry-collector.config.exporters.otlphttp/bronto.headers.x-bronto-api-key='` at install time.
## Step 3 — Start the demo
```bash theme={"dark"}
docker compose up --force-recreate --remove-orphans --detach
```
The web store is available at [http://localhost:8080](http://localhost:8080). The built-in load generator starts producing traffic automatically, so telemetry begins flowing without any manual clicks.
```bash theme={"dark"}
helm install my-otel-demo open-telemetry/opentelemetry-demo --values bronto-values.yaml
```
Follow the chart's output notes to port-forward the frontend proxy. The load generator runs in-cluster and starts traffic on its own.
## Step 4 — Explore your data in Bronto
Within a minute or two, telemetry should appear in Bronto. Here are two quick things to try.
Open [Explore Traces](/tracing/explore-traces) and pick a recent trace from the `frontend` service. Expand the spans to watch a single checkout request fan out across cart, currency, payment, and shipping. Click a span's `trace_id` to pivot into the correlated logs for that exact request.
Open the Metric Explorer and select a metric emitted by the demo. Filter by `service.name` to compare services, then use the result in a [dashboard](/Search-and-Visualize/Dashboards).
Connect the [Bronto MCP server](/ai-features/hosted-mcp) to your AI assistant and query the demo data in plain language — no query syntax required. Ask for an error summary, a latency outlier, or which service is failing, and let the assistant investigate across the demo's logs and traces.
Want to generate errors on demand? The demo includes a feature-flag service that can inject failures (such as a failing payment or cart service). Toggling those flags is a good way to see how problems surface in Bronto's traces and logs.
## Troubleshooting
If data doesn't appear:
* Confirm the endpoints match your region (`eu` vs `us`) and end in `/v1/logs`, `/v1/metrics`, and `/v1/traces`.
* Confirm the `x-bronto-api-key` header is present and the key is valid.
* Confirm you repeated the demo's existing exporters in each pipeline — a typo there can silently drop the whole pipeline.
* Check the Collector logs (`docker compose logs otel-collector`, or the collector pod) for export errors.
## Next steps
Once the demo makes sense, point your own application's OTLP traces at Bronto.
Use the language guides to add OpenTelemetry logs, metrics, and traces to your services.
# Quick Ingest
Source: https://docs.bronto.io/getting-started/quick-ingestion
Send data directly to Bronto in seconds using an API key with no agent or forwarder configuration required, ideal for testing or one-off ingestion.
Skip the agent setup and get your data into Bronto instantly. Quick Ingest gives you a guided configure page and ready-made request snippets for sending events directly to Bronto — ideal for testing, one-off ingestion, or getting up and running fast.
For production environments or continuous log forwarding, see the [Agent Setup](/agent-setup/agent-intro) guide.
## Send Data
To start quick ingestion, open **My Data** from the application sidebar, then click **Add Data**.
Bronto opens the onboarding configure page, where you can choose how you want to send data and test that events are arriving.
From the application sidebar, select **My Data**.
Click **Add Data** in the top-right of the page, which opens the onboarding configure page.
Use one of the configure page options:
**Have a telemetry agent config already?**, **Setting up with an LLM or agent?**, or **Set up with docs**.
You can also select an integration from the docs panel or click **View All** to browse the full list.
Click **Generate API Key** to create an ingestion key from the configure page, or use an existing [API key](/Account-Management/API-Keys) with ingestion permissions.
Click **Test Connection** to open a ready-made request snippet. Choose **cURL**, **HTTP**, or **Python**, add your API key, then run the snippet to send a sample event.
## Verify Ingestion
Use **Test Connection** on the onboarding configure page to send a sample event and confirm that Bronto can receive data with your API key.
The Test Connection modal includes:
* A language selector for **cURL**, **HTTP**, and **Python** snippets
* **Generate API Key** for creating an ingestion key without leaving the flow
* **Copy Snippet** for copying the generated request
* **Go to my logs** for opening Log Search after sending the sample event
After you run the snippet, wait for the "Waiting for events" status on the configure page to update, or click **Go to my logs** to inspect the ingested event directly.
# Ingest Data into Bronto
Source: https://docs.bronto.io/ingest-data/overview
Choose how to get your logs, metrics, and traces into Bronto — agents, cloud providers, CDNs, applications, infrastructure, databases, and OpenTelemetry.
## Overview
Bronto ingests logs, metrics, and traces from almost any source. Pick the section below that matches where your data lives — each one walks through the available methods and the configuration steps to get data flowing.
Each signal has its own destination in Bronto:
| Signal | Where to view it | Dataset and collection behavior |
| - | - | - |
| Logs | [Log Search](https://app.bronto.io/search) | Stored in a dataset and collection |
| Metrics | [Metric Explorer](/metrics/explore-metrics) | Not stored in a dataset or collection |
| Traces | [Explore Traces](/tracing/explore-traces) | Not stored in a dataset or collection |
New to Bronto? Start with the [Quick Ingestion](/getting-started/quick-ingestion) guide for the fastest path to sending your first events, and keep the [Bronto Endpoints](/getting-started/bronto-endpoints) reference handy for the URLs and ports each method uses.
## Choose a data source
Collect from your hosts with OpenTelemetry, Fluent Bit, Fluentd, Logstash, the Datadog Agent, or Vector.
Send logs, traces, and metrics from AWS services using S3, CloudWatch, Firehose, EventBridge, FireLens, and ADOT.
Stream telemetry from Azure services, VMs, and OpenTelemetry-instrumented workloads.
Forward edge and access logs from Akamai, Cloudflare, and Fastly.
Capture events from Auth0, Okta, GCP, Heroku, PagerDuty, Vercel, and more.
Collect from Kubernetes, Docker, proxies, message queues, identity providers, and databases like PostgreSQL, MySQL, MongoDB, and Redis.
Instrument your applications with the OpenTelemetry SDK across Python, Java, Go, .NET, Node.js, and more.
Capture distributed traces and RED metrics with no code changes, no SDK, and no redeploy, using OpenTelemetry eBPF Instrumentation (OBI).
# Akamai
Source: https://docs.bronto.io/integrations/akamai
Stream Akamai CDN logs to Bronto with DataStream 2 for real-time visibility into edge traffic, errors, cache performance, and security events.
## Overview
Akamai Datastream2 enables streaming CDN logs to third-party solutions via [HTTPS endpoints](https://techdocs.akamai.com/datastream2/docs/stream-custom-https). This guide walks you through configuring a Datastream2 *destination* to send logs to Bronto.
For the rest of the stream configuration, such as selecting which fields to be included in the log data, please refer to the [Akamai documentation](https://techdocs.akamai.com/datastream2/docs/welcome-datastream2).
### Destination Configuration
To configure a Datastream2 stream for Bronto:
1. Prepare your Bronto destination details:
* Collection (service\_namespace)
* Dataset (service\_name)
* Ingestion API key. See the [Bronto API Keys documentation page](/Account-Management/API-Keys) for details.
2. Use the following URL format for your destination:
```url theme={"dark"}
https://ingestion.eu.bronto.io/?service_name=MyBrontoDataset&service_namespace=MyBrontoCollection
```
3. In the Datastream2 configuration simply:
* Set Authentication to `None`
* Enable compression
* Add a custom header:
* Name: `x-bronto-api-key`
* Value: Your Bronto Ingestion API key
### Configuration Screenshots
# Send Auth0 events to Bronto
Source: https://docs.bronto.io/integrations/auth0
Stream Auth0 authentication and user lifecycle events — logins, MFA challenges, and password resets — to Bronto with Auth0 Event Streams.
## Overview
Auth0 emits events for every login, logout, user creation, password reset, MFA challenge, and organization change. This guide connects those events to Bronto using Auth0 Event Streams.
## Prerequisites
* A Bronto account and API key. See [API Keys](/Account-Management/API-Keys).
* Admin access to your Auth0 tenant
* Auth0 Free plan or above. Event Streams is available on all plans.
## Configure the Event Stream
In your Auth0 dashboard, navigate to **Monitoring → Event Streams** and click **+ Create Event Stream**.
From the list of stream types, select **Webhook**.
Fill in the following values:
**Stream Name**
```
Bronto
```
**Endpoint**
For EU:
```
https://ingestion.eu.bronto.io/?service_name=Auth0&service_namespace=
```
For US:
```
https://ingestion.us.bronto.io/?service_name=Auth0&service_namespace=
```
**Authentication Method**
```
Custom Header
```
**Header Key**
```
x-bronto-api-key
```
**Header Value**
```
```
Choose the Auth0 event categories you want to forward. To capture all authentication activity, enable **Select all events** under each category, or pick specific ones such as:
* `user.created`
* `user.updated`
* `organization.connection.added`
* login and logout events
Click **Save**. The stream status should show **Enabled**.
For full details on Auth0 Event Streams, see the [Auth0 Event Streams documentation](https://auth0.com/docs/customize/events/create-an-event-stream).
## Verify in Bronto
Open Bronto and go to [Search](https://app.bronto.io/search). Trigger a test event, for example by logging in to your Auth0-connected application or creating a test user, and confirm the event appears in the UI.
## What you will see in Bronto
Auth0 events arrive in CloudEvents format with:
* a top-level `type` field such as `organization.connection.updated`
* a `source` field identifying the Auth0 tenant
* a `data` object containing the event payload
Useful fields to filter on include:
* `type`
* `data.context.tenant.id`
* `data.object`
## Troubleshooting
* **No events appearing?** Check that the Event Stream shows as **Enabled** in Auth0 and confirm the endpoint URL and API key are correct.
* **Getting 401 errors?** Verify the `x-bronto-api-key` header value matches a valid Bronto API key with the Ingestion role.
* **Events landing without a dataset or collection?** Confirm the `service_name` and `service_namespace` query parameters are present and correctly spelled in the endpoint URL.
# AWS S3 Access Log
Source: https://docs.bronto.io/integrations/aws
Set up the AWS S3 access log integration in Bronto to ingest server access logs from S3 buckets and analyze object access, requests, and errors.
### Overview
Please note this In-App option is for S3 Access Log ingestion only, for all other use cases refer to our Client Side option.
To set up the AWS integration manually, create an IAM policy and IAM role in your AWS account, and configure the role with an AWS External ID generated in your Bronto account. This allows Bronto’s AWS account to query AWS APIs on your behalf, and pull data into your Bronto account. The sections below detail the steps for creating each of these components, and then completing the setup in your Bronto account.
### Setup
In the [AWS integration configuration page](https://app.eu.bronto.io/integrations/aws-cloud), click the “Add New AWS Account” button.
Enter your AWS account ID in the “AWS Account ID” field and click "Generate External ID". The ID will be generated and available for you to copy. For more information on AWS External IDs\*\*, \*\*see the [IAM user guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html).
Create a new role in the AWS [IAM Console](https://console.aws.amazon.com/iam/home#/roles).
Select **Custom trust policy** for the trusted entity type and paste the trust policy below. (**Note:** don’t forget to copy in your External ID generated on the [integration page](https://app.eu.bronto.io/integrations/aws-cloud))
Skip the permission policy section as it will be created after the role.
Name the role `BrontoBytesIntegration-AWSRole`, and provide an apt description.
Click **Create Role**.
Create an IAM policy for the BrontoBytes role in your AWS account with the necessary permissions to take advantage of every AWS integration offered by BrontoBytes. As other components are added to an integration, these permissions may change.
Go to the newly created `BrontoBytesIntegration-AWSRole` role in the [AWS IAM Console](https://console.aws.amazon.com/iam/home#/roles).
Click `Add Permissions` and choose `Create inline policy`.
Paste the **BrontoBytes Integration Policy** below.
Click **Next** to review your changes.
Name the policy `BrontoBytesIntegrationPolicy` or one of your own choosing, and provide an apt description.
Click **Create policy**.
AWS IAM permissions enable Bronto to collect metrics, tags, EventBridge events, and other data necessary to monitor your AWS environment.
To correctly set up the AWS Integration, you must attach the relevant IAM policies to the Bronto AWS Integration IAM Role in your AWS account.
### AWS Integration IAM Custom Trust Policy
Don’t forget to copy in your External ID generated on the integration page
```json theme={"dark"}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BrontoBytesAssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::637423326566:role/BrontoBytesAWSIntegration"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": ""
}
}
}
]
}
```
### Bronto Integration Policy
The below config needs to be updated first before pasting. *BUCKET\_NAME*is the name of the S3 bucket that contains the log data and *PREFIX* is the path to the parent folder where the logs are actually stored.
```json theme={"dark"}
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:List*",
"s3:Get*"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3::://*",
"arn:aws:s3:::"
]
}
]
}
```
### S3 Notifications
The final step is to enable notifications for your S3 bucket. This will allow Bronto to receive notifications when new objects are added to your bucket.
Go to the [S3 console](https://console.aws.amazon.com/s3/home) and find the bucket you want to enable notifications for.
Choose the `Properties` tab and scroll down to `Event notifications`
Click **Create event notification**
Set the event type to `All object create events`
Set the destination to `SNS Topic` and enter ARN that matches the region where your bucket is:
* ****EU West 1****
```
arn:aws:sns:eu-west-1:637423326566:brontobytes-aws-ingestion
```
* ****US East 1****
```
arn:aws:sns:us-east-1:637423326566:brontobytes-aws-ingestion
```
# AWS Distribution for OpenTelemetry (ADOT)
Source: https://docs.bronto.io/integrations/aws-adot
Send application logs, metrics, and traces from Amazon ECS, EKS, or EC2 to Bronto with AWS Distro for OpenTelemetry (ADOT), avoiding CloudWatch fees.
## When to Use ADOT
ADOT is a good fit when you are running containerised workloads on ECS or EKS and want to:
* Send application **logs, metrics, and traces** to Bronto through one Collector
* Avoid CloudWatch log ingestion fees entirely
* Use an AWS-supported, pre-built distribution of the OpenTelemetry Collector without managing it yourself
If you need full control over collector configuration — custom processors, fan-out to multiple backends, or advanced transformation — consider the [Self-Managed OTel Collector](./aws-custom-otel) instead.
***
## Supported AWS Services
ADOT collects application logs, metrics, and traces from containerised workloads on:
| Service | Data types |
| - | - |
| Amazon ECS (EC2 launch type) | Application logs, metrics, and traces (sidecar) |
| AWS Fargate (ECS) | Application logs, metrics, and traces (sidecar) |
| Amazon EKS (EC2 node groups) | Application logs, metrics, and traces (DaemonSet) |
| Amazon EKS (Fargate) | Application logs, metrics, and traces (sidecar) |
For Lambda traces, use the [ADOT Lambda Layer](./aws-adot-lambda). For non-containerised AWS services, see the [overview](./aws-overview).
ADOT forwards the telemetry your workload sends it — it does not automatically discover application telemetry. Instrument your app with the [OpenTelemetry SDK](/opentelemetry/overview) so it exports logs, metrics, and traces to the ADOT sidecar or DaemonSet.
***
## What is ADOT?
The [AWS Distribution for OpenTelemetry](https://aws-otel.github.io/) (ADOT) is an AWS-supported build of the OpenTelemetry Collector. It is available as a Docker image and can be deployed as a sidecar container (ECS) or a daemonset (EKS). It collects logs, metrics, and traces from your application via OTLP and forwards them to any OTLP-compatible backend — including Bronto.
ADOT itself is free. You pay only for the compute running the container.
***
## Bronto Ingestion Endpoints
| Signal | EU Region | US Region |
| - | - | - |
| Logs | `https://ingestion.eu.bronto.io/v1/logs` | `https://ingestion.us.bronto.io/v1/logs` |
| Metrics | `https://ingestion.eu.bronto.io/v1/metrics` | `https://ingestion.us.bronto.io/v1/metrics` |
| Traces | `https://ingestion.eu.bronto.io/v1/traces` | `https://ingestion.us.bronto.io/v1/traces` |
The `/v1/logs`, `/v1/metrics`, and `/v1/traces` endpoints accept **OTLP protobuf only**.
All requests require the header:
```
x-bronto-api-key:
```
See [API Keys](/Account-Management/API-Keys) for how to generate a key.
***
## Setup on ECS (Sidecar)
Add the ADOT container as a sidecar to your ECS task definition. The typical local defaults are `localhost:4317` for OTLP/gRPC and `localhost:4318` for OTLP/HTTP. Use the receiver address, protocol, and TLS settings configured for your task when they differ; the sidecar then forwards the telemetry to Bronto.
### ADOT Collector Configuration
Create a collector config file and make it available to the container (via S3, SSM Parameter Store, or a custom image).
```yaml theme={"dark"}
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
exporters:
otlphttp/bronto:
logs_endpoint: "https://ingestion..bronto.io/v1/logs"
metrics_endpoint: "https://ingestion..bronto.io/v1/metrics"
traces_endpoint: "https://ingestion..bronto.io/v1/traces"
compression: none
headers:
x-bronto-api-key: ${env:BRONTO_API_KEY}
service:
pipelines:
logs:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto]
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto]
```
Replace `` with `eu` or `us`. In production, do not bake the API key into the YAML. Inject it into the container from AWS Secrets Manager as `BRONTO_API_KEY`, then use `${env:BRONTO_API_KEY}` as the header value. ADOT also accepts the complete configuration through `AOT_CONFIG_CONTENT`, which can be populated from a protected SSM parameter at deployment time.
ADOT does not include every upstream Collector component. In particular, its standard image does not include the `transform` processor. For simple GenAI compatibility rewrites—such as copying or renaming legacy `gen_ai.system` to `gen_ai.provider.name`—use the `attributes` processor, or choose the upstream Collector distribution after verifying its component manifest.
### ECS Task Definition (sidecar container)
```json theme={"dark"}
{
"name": "adot-collector",
"image": "public.ecr.aws/aws-observability/aws-otel-collector:latest",
"essential": false,
"command": ["--config", "/etc/otel/config.yaml"],
"portMappings": [
{ "containerPort": 4317, "protocol": "tcp" },
{ "containerPort": 4318, "protocol": "tcp" }
]
}
```
In a multi-container task, add a container dependency so the application starts only after the Collector is healthy. Grant the **task role** (not only the execution role) any permissions the application needs for Bedrock, and grant the execution role access to the Secrets Manager/SSM values injected into the task definition.
With the receiver configuration above, an application sharing the task network can normally export to `http://localhost:4317` over gRPC or `http://localhost:4318` over HTTP. The exact host, port, protocol, and TLS settings depend on the task's network mode and your Collector configuration.
***
## Setup on EKS (DaemonSet)
Deploy ADOT as a DaemonSet so one collector pod runs per node. Application pods export telemetry to the node's collector via the node IP or a local service.
```yaml theme={"dark"}
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: adot-collector
namespace: monitoring
spec:
selector:
matchLabels:
app: adot-collector
template:
metadata:
labels:
app: adot-collector
spec:
containers:
- name: adot-collector
image: public.ecr.aws/aws-observability/aws-otel-collector:latest
args: ["--config", "/etc/otel/config.yaml"]
volumeMounts:
- name: otel-config
mountPath: /etc/otel
volumes:
- name: otel-config
configMap:
name: adot-config
```
Store the collector configuration above in a `ConfigMap` named `adot-config`.
***
## Log Data Organization
ADOT attaches OpenTelemetry resource attributes to every signal. For **logs only**, Bronto maps `service.name` to a **Dataset** and `service.namespace` to a **Collection**. Metrics and traces are not stored in datasets or collections; view them in the [Metric Explorer](/metrics/explore-metrics) and [Explore Traces](/tracing/explore-traces).
Set these in the `resource` block of your collector config:
```yaml theme={"dark"}
processors:
resource:
attributes:
- key: service.name
value:
action: upsert
- key: service.namespace
value:
action: upsert
```
You can also override **log routing** on a logs exporter using HTTP headers, which is useful when one collector ships logs to multiple datasets:
| Header | Description |
| - | - |
| `x-bronto-dataset` | Overrides `service.name` for the log dataset |
| `x-bronto-collection` | Overrides `service.namespace` for the log collection |
| `x-bronto-tags` | Comma-separated tags to attach to the log dataset |
```yaml theme={"dark"}
exporters:
otlphttp/brontologs:
logs_endpoint: https://ingestion..bronto.io/v1/logs
headers:
x-bronto-api-key:
x-bronto-dataset:
x-bronto-collection:
x-bronto-tags: env=prod,team=platform
```
***
## Cost Notes
* **No CloudWatch ingestion fees** — logs, metrics, and traces go directly from ADOT to Bronto over OTLP/HTTP.
* **Compute cost only** — you pay for the ECS task or EKS pod running the collector, which is typically small relative to CloudWatch PUT and ingestion charges at scale.
* Compare with the [CloudWatch Log Forwarder](./aws-client-cloudwatch) if your services already write to CloudWatch and the migration cost outweighs the savings.
***
For assistance, contact [support@bronto.io](mailto:support@bronto.io).
# Serverless Telemetry with ADOT Lambda Layer
Source: https://docs.bronto.io/integrations/aws-adot-lambda
Instrument AWS Lambda functions with the AWS Distro for OpenTelemetry (ADOT) Lambda Layer to send serverless logs, metrics, and traces to Bronto.
## When to Use the ADOT Lambda Layer
The ADOT Lambda Layer is the **recommended** Lambda ingestion path when your function runtime supports the OpenTelemetry SDK. It is a good fit when you want to:
* Send **logs, metrics, and traces** from AWS Lambda directly to Bronto via OTLP, without going through CloudWatch
* Avoid CloudWatch ingestion fees on Lambda log volume
* Use the same `service.name` / `service.namespace` identity across Lambda, ECS, and EKS workloads
The layer captures logs emitted through the OpenTelemetry logging API in your function code (for example, via the OTel SDK or a bridged framework logger). Lambda's automatic `stdout` / `stderr` capture still goes to CloudWatch — to also ship those, use the [CloudWatch Log Forwarder](./aws-client-cloudwatch) alongside the layer, or route your application logger through OTel.
***
## Supported AWS Services
The ADOT Lambda Layer is Lambda-specific:
| Service | Data types |
| - | - |
| AWS Lambda | Function logs (via OTel SDK) and traces (auto-instrumented via the layer) |
Supported runtimes are listed in the [ADOT Lambda documentation](https://aws-otel.github.io/docs/getting-started/lambda) — currently Node.js, Python, Java, .NET, and Go. For runtimes without OTel SDK support (Ruby, custom runtimes), use the [CloudWatch Log Forwarder](./aws-client-cloudwatch). For non-Lambda compute, see [ADOT — ECS / EKS](./aws-adot) or the [overview](./aws-overview).
***
## What is the ADOT Lambda Layer?
The [ADOT Lambda Layer](https://aws-otel.github.io/docs/getting-started/lambda) is an AWS Lambda Layer that wraps your function with an embedded OpenTelemetry Collector. It can export logs, metrics, and traces to an OTLP-compatible backend — including Bronto. The exact automatically generated signals depend on the runtime instrumentation included in the layer version.
***
## Bronto OTLP Endpoints
| Region | Logs Endpoint | Metrics Endpoint | Traces Endpoint |
| - | - | - | - |
| EU | `https://ingestion.eu.bronto.io/v1/logs` | `https://ingestion.eu.bronto.io/v1/metrics` | `https://ingestion.eu.bronto.io/v1/traces` |
| US | `https://ingestion.us.bronto.io/v1/logs` | `https://ingestion.us.bronto.io/v1/metrics` | `https://ingestion.us.bronto.io/v1/traces` |
The `/v1/logs`, `/v1/metrics`, and `/v1/traces` endpoints accept **OTLP protobuf only**.
All requests require the header:
```
x-bronto-api-key:
```
See [API Keys](/Account-Management/API-Keys) for how to generate a key.
***
## Setup
### Step 1 — Add the ADOT Lambda Layer
Add the ADOT managed Lambda Layer to your function. Layer ARNs are region- and architecture-specific. Find the latest ARN for your runtime in the [official ADOT Lambda Layer documentation](https://aws-otel.github.io/docs/getting-started/lambda#find-your-layer-arn).
Via AWS CLI:
```bash theme={"dark"}
aws lambda update-function-configuration \
--function-name \
--layers
```
Via Terraform:
```hcl theme={"dark"}
resource "aws_lambda_function" "example" {
# ... other config ...
layers = [""]
}
```
### Step 2 — Configure the collector to export to Bronto
Set the `OPENTELEMETRY_COLLECTOR_CONFIG_URI` environment variable to point to a collector config stored in S3 or SSM Parameter Store, or use inline configuration.
Minimal collector config:
```yaml theme={"dark"}
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
processors:
batch:
exporters:
otlphttp/bronto:
logs_endpoint: "https://ingestion..bronto.io/v1/logs"
metrics_endpoint: "https://ingestion..bronto.io/v1/metrics"
traces_endpoint: "https://ingestion..bronto.io/v1/traces"
compression: none
headers:
x-bronto-api-key:
service:
pipelines:
logs:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto]
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto]
```
### Step 3 — Set environment variables on your Lambda function
| Variable | Value |
| - | - |
| `OPENTELEMETRY_COLLECTOR_CONFIG_URI` | S3 URI or SSM path to your collector config |
| `AWS_LAMBDA_EXEC_WRAPPER` | `/opt/otel-handler` (or runtime-specific wrapper — see ADOT docs) |
### Step 4 — Instrument your application code
Add the OTel SDK for your runtime and configure it to export to the local collector. `localhost:4317` is the standard OTLP/gRPC default used by this example; use the actual receiver port and protocol if you customize the extension. For per-language setup instructions, see the [OpenTelemetry SDK guides](/opentelemetry/overview).
***
## Resource Identity and Log Organization
The Lambda Layer attaches OpenTelemetry resource attributes to every signal. For **logs only**, Bronto maps `service.name` to a **Dataset** and `service.namespace` to a **Collection**. Metrics and traces use these attributes for identity and filtering, but are not stored in datasets or collections.
Set these via Lambda environment variables — the OTel SDK reads them automatically:
| Variable | All signals | Additional behavior for logs only |
| - | - | - |
| `OTEL_SERVICE_NAME` | Sets `service.name` | Selects the log dataset |
| `OTEL_RESOURCE_ATTRIBUTES` | Sets additional resource attributes | `service.namespace` selects the log collection |
You can also override log routing in the collector config using HTTP headers on the logs exporter:
| Header | Description |
| - | - |
| `x-bronto-dataset` | Overrides `service.name` for the log dataset |
| `x-bronto-collection` | Overrides `service.namespace` for the log collection |
| `x-bronto-tags` | Comma-separated tags to attach to the log dataset |
```yaml theme={"dark"}
exporters:
otlphttp/brontologs:
logs_endpoint: "https://ingestion..bronto.io/v1/logs"
headers:
x-bronto-api-key:
x-bronto-dataset:
x-bronto-collection:
x-bronto-tags: env=prod,function=
```
***
## Cost Notes
* The ADOT Lambda Layer itself is free.
* Logs, metrics, and traces sent through the layer bypass CloudWatch entirely — no CloudWatch ingestion fees for those exported signals.
* Lambda's automatic `stdout` / `stderr` capture still writes to CloudWatch by default. To stop paying for that, route your application logger through the OTel SDK; to keep both paths, add the [CloudWatch Log Forwarder](./aws-client-cloudwatch) alongside the layer.
***
For assistance, contact [support@bronto.io](mailto:support@bronto.io).
# Amazon Bedrock AgentCore Logs, Metrics and Traces
Source: https://docs.bronto.io/integrations/aws-agentcore
Route the OpenTelemetry logs, metrics and traces an agent emits on Amazon Bedrock AgentCore Runtime to Bronto — via an OTel Collector or directly over OTLP.
Agents running on [Amazon Bedrock AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html) Runtime emit OpenTelemetry telemetry through a **managed pipeline** that, by default, delivers to **Amazon CloudWatch**. To send that telemetry to Bronto you disable the managed pipeline and export OTLP to Bronto — either directly from the runtime or through an OTel Collector.
Unlike log-only AWS services, there is no CloudWatch log group or Firehose stream to point at Bronto for the rich agent signal. The nested GenAI traces — model calls, token usage, tool calls, and prompt/response content — are produced by the agent framework's instrumentation running inside the runtime.
## Two requirements
Configure the OpenTelemetry SDK inside your agent and take AWS's managed observability out of the way (`agentcore configure --disable-otel` plus `DISABLE_ADOT_OBSERVABILITY=true` at runtime), so your own exporters own the signal. For the full setup — the trace/metric/log providers, GenAI attributes, and making prompt/response content searchable — see [Amazon Bedrock AgentCore observability with OpenTelemetry](/ai-features/aws-agentcore).
The instrumented runtime exports OTLP to an OTel Collector, which holds the Bronto credential and forwards each signal to Bronto. Where you don't operate a Collector, the runtime can export straight to Bronto with the credential in the request header.
## Recommended method
[**ADOT**](./aws-adot) — the AWS Distro for OpenTelemetry Collector — receives OTLP from your agent and forwards logs, metrics and traces to Bronto over OTLP/HTTP. The Collector holds the Bronto credential so it never lives in the runtime config, and it keeps `service.name` / `service.namespace` identity consistent across signals. Only logs use those attributes for dataset and collection routing. It is also where you add processors, sampling, or fan-out to multiple backends; the [Self-Managed OTel Collector](./aws-custom-otel) is the same pattern for full-control deployments.
Point the agent's OTLP exporters at the Collector (`OTEL_EXPORTER_OTLP_ENDPOINT`) rather than at Bronto directly. AgentCore's managed public network mode requires an internet-reachable endpoint; a proven pattern is ADOT on ECS Fargate behind a public HTTPS ALB. Configure the ALB health check against the Collector's health extension, not its OTLP receiver. See [Amazon Bedrock AgentCore observability with OpenTelemetry](/ai-features/aws-agentcore) for the SDK bootstrap and environment variables.
The fully-managed AgentCore Runtime does not host a Collector sidecar and cannot reach a private VPC-only Collector in its public network mode. Expose the Collector securely over HTTPS, or use direct export below.
## LLM observability for AgentCore
For the agent-specific signal — nested agent-loop traces, per-model token usage, tool calls, and prompt/response content following the OpenTelemetry GenAI semantic conventions — see [Amazon Bedrock AgentCore observability](/ai-features/aws-agentcore) under AI assisted observability.
## Alternatives
* **Direct OTLP export from the runtime** — for the fully-managed runtime with no Collector to hand, or for short-lived jobs, export OTLP straight to Bronto: set `OTEL_EXPORTER_OTLP_ENDPOINT` to the Bronto ingestion base and inject the `x-bronto-api-key` header, sourced from [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/) at startup. No Collector, VPC, NAT, or sidecar is required — the agent's telemetry ships at full fidelity straight from the runtime.
* **Keep the managed CloudWatch pipeline** — if you leave AgentCore's default observability enabled, its telemetry lands in CloudWatch; you can then forward those log groups with the [CloudWatch Log Forwarder](./aws-client-cloudwatch). This is a fallback: it does not preserve the nested trace fidelity that exporting OTLP to Bronto gives you.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon Bedrock AgentCore observability](/ai-features/aws-agentcore)
* [Amazon Bedrock AgentCore documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html)
* [AWS Distro for OpenTelemetry](https://aws-otel.github.io/)
* [OpenTelemetry GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md)
# ALB and NLB Access Logs
Source: https://docs.bronto.io/integrations/aws-alb
Ingest Application and Network Load Balancer access logs into Bronto — client IP, request details, target, latency, and response code — from an S3 bucket.
Application Load Balancers and Network Load Balancers can publish access logs to an S3 bucket. Each entry records the client IP and port, the request line, the chosen target, latency at each hop, and the response code — a comprehensive trail of the traffic that reached your load balancer.
## Recommended method
[**S3 Log Forwarder**](./aws-client-s3) — enable access logging on each load balancer with a destination bucket, then point the Bronto forwarder Lambda at the bucket. New log objects are picked up via S3 event notifications and streamed into Bronto.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Application Load Balancer — access logs](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
# Amazon API Gateway Logs
Source: https://docs.bronto.io/integrations/aws-api-gateway
Send execution and access logs from Amazon API Gateway REST and HTTP APIs to Bronto via CloudWatch, capturing request paths, latencies, and integration errors.
Amazon API Gateway emits two log streams: **execution logs** (request handling, integration latency, errors) and **access logs** (request/response details with custom format strings). Both are written to CloudWatch Log Groups.
## Recommended method
[**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — enable execution and access logging on each API stage and the Bronto forwarder Lambda subscribes to the CloudWatch Log Groups and streams events into Bronto.
## Alternatives
* [**Kinesis Firehose**](./aws-firehose-logs) — for high-volume access logs. Access logging writes to CloudWatch Logs; add a subscription filter on the access-log group targeting a Firehose stream. Choose the **JSON** access-log format so Bronto flattens fields automatically — a CLF/CSV/XML format is stored raw and requires a [custom parser](/core-features/custom-parser). See [Supported record formats](./aws-firehose-logs#supported-record-formats).
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon API Gateway — set up logging](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html)
# Amazon Bedrock Logs, Metrics and Traces
Source: https://docs.bronto.io/integrations/aws-bedrock
Collect OpenTelemetry logs, metrics, and traces from applications that call the Amazon Bedrock Converse and InvokeModel APIs via an OTel Collector.
Amazon Bedrock model invocations (the `Converse`, `ConverseStream`, `InvokeModel`, and `InvokeModelWithResponseStream` APIs) do not emit telemetry to Bronto on their own. You collect Bedrock telemetry by **instrumenting the application that calls Bedrock** with OpenTelemetry and forwarding it to Bronto through an **OTel Collector**.
This is different from log-only AWS services: there is no CloudWatch log group or Firehose stream to point at Bronto. The rich GenAI signal — model id, token usage, latency, and prompt/response content — is produced by instrumenting your code.
## Two requirements
Add the OpenTelemetry SDK and the AWS SDK auto-instrumentation to the service that calls Bedrock. The botocore/AWS SDK instrumentation traces `Converse` / `InvokeModel` calls and, on a recent enough version, enriches them with GenAI semantic-convention attributes (token usage, model, finish reason). See [Amazon Bedrock LLM observability with OpenTelemetry](/ai-features/aws-bedrock) for the full setup.
The instrumented app exports OTLP to a Collector, which adds the Bronto credentials and forwards each signal to Bronto. On AWS the recommended Collector is [ADOT](./aws-adot), run as a sidecar (ECS / Fargate) or daemonset (EKS).
## Recommended method
[**ADOT**](./aws-adot) — the AWS Distro for OpenTelemetry Collector — receives OTLP from your application and forwards logs, metrics and traces to Bronto over OTLP/HTTP, with consistent `service.name` / `service.namespace` identity. Only logs use those attributes for dataset and collection routing. The same sidecar pattern works on the [ECS / Fargate](./aws-ecs) and [EKS](./aws-eks) launch types you are likely already running your Bedrock app on.
Pair it with application instrumentation for your language:
How application instrumentation maps each signal to its Bronto destination.
Most common runtime for Bedrock apps; richest GenAI auto-instrumentation.
Instrument a Node.js service that calls the Bedrock APIs.
All OTLP-capable runtimes export to the same Collector.
## LLM observability for Bedrock
For the GenAI-specific signal — capturing token usage, model metadata, and prompt/response content following the OpenTelemetry GenAI semantic conventions — see [Amazon Bedrock LLM observability](/ai-features/aws-bedrock) under AI assisted observability.
## Alternatives
* [**Self-managed OTel Collector**](./aws-custom-otel) — when you need custom processors, sampling, or fan-out to multiple backends alongside Bronto.
* **Direct export** — for local development or short-lived jobs you can export OTLP straight from the SDK to Bronto with an API key; see the [direct export section](/opentelemetry/python#direct-export-to-bronto) on any language page.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon Bedrock Converse API](https://docs.aws.amazon.com/bedrock/latest/userguide/conversation-inference.html)
* [AWS Distro for OpenTelemetry](https://aws-otel.github.io/)
* [OpenTelemetry GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/aws-bedrock.md)
# Forwarding AWS Logs from CloudWatch
Source: https://docs.bronto.io/integrations/aws-client-cloudwatch
Forward Amazon CloudWatch Logs to Bronto with Lambda subscription filters to centralize AWS service, application, and Lambda function logs for search.
## When to Use
The CloudWatch Log Forwarder is a good fit when:
* Your AWS services already deliver logs to CloudWatch (Lambda, RDS, ECS, API Gateway, VPC Flow Logs, and others)
* You want a simple setup without changing how your services log
* You are comfortable with the CloudWatch ingestion fees that apply to your log volume
If you want to avoid CloudWatch ingestion fees for new workloads, consider [ECS FireLens](./aws-firelens), [Fluent Bit on EKS](./aws-fluent-bit-eks), or [ADOT](./aws-adot) instead. See the [overview](./aws-overview) for a full cost and method comparison.
***
## Supported AWS Services
The CloudWatch Log Forwarder is the recommended path for any AWS service that publishes logs to CloudWatch Logs:
| Service | Log type |
| - | - |
| AWS Lambda | Function `stdout` / `stderr` (for functions not using the [ADOT Lambda Layer](./aws-adot-lambda)) |
| Amazon RDS / Aurora (PostgreSQL) | Database engine and slow-query logs |
| Amazon RDS / Aurora (MySQL) | Error, slow-query, and general logs |
| Amazon API Gateway | Execution and access logs |
| Amazon ElastiCache | Engine and slow logs |
| Amazon Route 53 | DNS query logs |
| Amazon SES | Sending event logs |
| AWS Step Functions | State machine execution logs |
| Amazon Cognito | User pool authentication logs |
| VPC Flow Logs | Network flow records (CloudWatch delivery) |
| AWS WAF | Web ACL traffic logs (CloudWatch delivery) |
Any service that can deliver to a CloudWatch log group is supported. See the [AWS documentation on services that publish to CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) for the full list.
***
## How it Works
The Bronto AWS Log Forwarder is built around an AWS Lambda function that processes and forwards logs to Bronto. The function is triggered through CloudWatch [subscription filters](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html). Both log group level and [account level](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters-AccountLevel.html) subscription filters are supported.
Bronto recommends using **account level subscription filters** so all log groups are forwarded automatically without per-group configuration.
***
## Setup Instructions
Choose your preferred deployment method:
**Terraform (recommended)** — Deploys the Lambda forwarder along with the necessary IAM roles and policies. Supports routing different log types to different destinations within Bronto. Full details and usage instructions are in the [Terraform module repository](https://github.com/brontoio/brontobytes-aws-ingestion-terraform).
**CloudFormation** — Use the [CloudFormation template](https://s3.eu-west-1.amazonaws.com/brontobytes.io/integration/aws/cloudformation/1.0.0/brontoForwarder.yaml) in the AWS Console to create the stack by filling out a form.
**Manual** — The Lambda function code and a pre-packaged deployment artifact are available in the [GitHub repository](https://github.com/brontoio/brontobytes-aws-ingestion-python).
Set up account level subscription filters to automatically forward all CloudWatch log groups to the deployed Lambda function. Refer to the [AWS documentation on subscription filters](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters-AccountLevel.html) for setup steps.
***
## Data Organization
The forwarder Lambda controls how data lands in Bronto through its configuration, not via HTTP headers — it composes the `x-bronto-*` headers internally based on the log group name and the per-source mapping you provide. See [Data Organization](/Search-and-Visualize/Partitions) for how datasets, collections, and tags work in Bronto.
By default, with an account-level subscription filter (the recommended setup):
* **Dataset** is the CloudWatch log group name (e.g. `/aws/lambda/`).
* **Collection** is whatever you set as the default — `cloudwatch_default_collection` — or Bronto's default collection if not set.
* **Tags** come from the global `bronto_tags` map.
Provide a `destination_config` entry only when you want to override the defaults for a specific log group, or to apply per-source tags.
### Configure via Terraform (recommended)
Set defaults and any per-log-group overrides via the [Terraform module](https://github.com/brontoio/brontobytes-aws-ingestion-terraform#usage):
```hcl theme={"dark"}
module "bronto_aws_log_forwarding" {
source = "git::https://github.com/brontoio/brontobytes-aws-ingestion-terraform.git//aws_log_forwarder"
# ... bronto_api_key, artifact_bucket, etc.
cloudwatch_default_collection = "Cloudwatch"
account_level_cloudwatch_subscription = {
enable = true
excluded_log_groups = ["log_group1", "log_group2"]
}
# Optional — only needed to override defaults for specific log groups
destination_config = {
"/aws/lambda/" = {
dataset = ""
collection = ""
log_type = "cloudwatch_log"
tags = { team = "platform" }
}
}
bronto_tags = { environment = "production", region = "eu-west-1" }
}
```
* `cloudwatch_default_collection` sets the Bronto collection for any log group not explicitly listed in `destination_config`.
* `account_level_cloudwatch_subscription` is the recommended way to forward all log groups automatically. AWS allows only one account-level subscription, so this is only suitable if no other account-level subscription is already in place.
* `bronto_tags` apply globally; per-source `tags` inside a `destination_config` entry add or override tags for that log group only.
* For log groups that need their own subscription filter pattern, set `set_individual_subscription = true` and `subscription_filter_pattern = ""` inside the matching `destination_config` entry. A `default_subscription_filter_pattern` can be applied to every account-level subscription.
For the full variable reference, see the [Terraform module README](https://github.com/brontoio/brontobytes-aws-ingestion-terraform#usage).
### Configure direct Lambda deployments
If you deploy the [Python Lambda](https://github.com/brontoio/brontobytes-aws-ingestion-python/blob/main/README.md) directly (CloudFormation or manual), the same configuration is provided as Lambda environment variables:
| Environment variable | Purpose |
| - | - |
| `bronto_api_key` | Bronto API key |
| `bronto_endpoint` | Regional ingestion endpoint, e.g. `https://ingestion.eu.bronto.io/` |
| `cloudwatch_default_collection` | Default Bronto collection for CloudWatch log groups |
| `destination_config` | Base64-encoded JSON map of log group names to `dataset`, `collection`, `log_type: cloudwatch_log`, and optional `tags` — only needed for overrides |
| `tags` | Comma-separated `key=value` pairs applied to all datasets — e.g. `environment=production,region=eu-west-1` |
See the [Python forwarder README](https://github.com/brontoio/brontobytes-aws-ingestion-python/blob/main/README.md) for a sample `destination_config` payload and the full attribute reference.
***
## Cost Notes
* AWS charges for CloudWatch log ingestion (PUT requests and GB ingested to CloudWatch). These fees apply regardless of whether you forward the logs to Bronto.
* Lambda invocation costs for the forwarder itself are minimal.
* If CloudWatch ingestion costs are a concern at your log volume, see [ECS FireLens](./aws-firelens), [Fluent Bit on EKS](./aws-fluent-bit-eks), or [ADOT](./aws-adot) for alternatives that bypass CloudWatch entirely.
***
For assistance, contact [support@bronto.io](mailto:support@bronto.io).
# Forwarding AWS Logs from S3
Source: https://docs.bronto.io/integrations/aws-client-s3
Forward logs delivered to Amazon S3 buckets into Bronto using a Lambda-based forwarder for VPC flow, ALB, CloudFront, and other AWS service logs.
## When to Use
The S3 Log Forwarder is a good fit when:
* AWS services deliver log files directly to an S3 bucket (CloudFront, ALB, NLB, VPC Flow Logs, and others)
* You want a low-complexity setup with no CloudWatch ingestion fees
* You prefer Terraform or CloudFormation for infrastructure deployment
For application logs or traces from running workloads, see [ECS FireLens](./aws-firelens), [ADOT](./aws-adot), or the [overview](./aws-overview) for a full comparison.
***
## Supported AWS Services
The S3 Log Forwarder is the recommended path for AWS services that deliver logs directly to S3:
| Service | Log type |
| - | - |
| Amazon CloudFront | Standard access logs |
| Application Load Balancer (ALB) | Access logs |
| Network Load Balancer (NLB) | Access logs |
| VPC Flow Logs | Network flow records (S3 delivery) |
| AWS WAF | Web ACL traffic logs |
| AWS CloudTrail | Management and data event log files |
| AWS GuardDuty | Findings export |
| Amazon S3 | Server access logs |
Any other AWS service that delivers logs to an S3 bucket can use this forwarder. See the [AWS documentation on services that publish to S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) for the full list.
***
## How it Works
The Bronto AWS Log Forwarder is built around an AWS Lambda function that processes and forwards logs to Bronto. The function is triggered through S3 or EventBridge event notifications when new objects are written to your bucket.
Supported AWS log sources include AWS CloudFront, Application Load Balancer (ALB), Network Load Balancer (NLB), VPC Flow Logs, and others. See the [AWS documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) for the full list of services that deliver to S3.
***
## Setup Instructions
Choose your preferred deployment method:
**Terraform (recommended)** — Deploys the Lambda forwarder along with the necessary IAM roles and policies. Supports routing different log types to different destinations within Bronto. Full details and usage instructions are in the [Terraform module repository](https://github.com/brontoio/brontobytes-aws-ingestion-terraform).
**CloudFormation** — Use the [CloudFormation template](https://s3.eu-west-1.amazonaws.com/brontobytes.io/integration/aws/cloudformation/1.0.0/brontoForwarder.yaml) in the AWS Console to create the stack by filling out a form.
**Manual** — The Lambda function code and a pre-packaged deployment artifact are available in the [GitHub repository](https://github.com/brontoio/brontobytes-aws-ingestion-python).
Configure your S3 bucket to trigger the Lambda function when new objects are created. Refer to the [AWS documentation on S3 notifications](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-event-notifications.html) for setup steps.
***
## Data Organization
The forwarder Lambda controls how data lands in Bronto through its configuration, not via HTTP headers — it composes the `x-bronto-*` headers internally based on the per-source mapping you provide. See [Data Organization](/Search-and-Visualize/Partitions) for how datasets, collections, and tags work in Bronto.
### Configure via Terraform (recommended)
Map each S3 source (bucket name or CloudFront distribution ID) to its target dataset, collection, and log type using the `destination_config` variable on the [Terraform module](https://github.com/brontoio/brontobytes-aws-ingestion-terraform#usage):
```hcl theme={"dark"}
module "bronto_aws_log_forwarding" {
source = "git::https://github.com/brontoio/brontobytes-aws-ingestion-terraform.git//aws_log_forwarder"
# ... bronto_api_key, artifact_bucket, logging_bucket, etc.
destination_config = {
"" = {
dataset = ""
collection = ""
log_type = "s3_access_log"
}
"" = {
dataset = ""
collection = ""
log_type = "cf_standard_access_log"
}
}
bronto_tags = { environment = "production", region = "eu-west-1" }
}
```
* `dataset` / `collection` route each source's logs to a specific Bronto destination.
* `log_type` tells the forwarder which parser to apply — supported values include `s3_access_log`, `alb_access_log`, `nlb_access_log`, `clb_access_log`, `vpc_flow_log`, `cloudtrail`, `cf_standard_access_log`, `cf_realtime_access_log`, `bedrock_s3`, and `default` (no parsing, for already-structured JSON).
* `bronto_tags` apply globally to all datasets produced by this forwarder. A per-source `tags` map inside a `destination_config` entry adds or overrides tags for that source only.
* For sources whose S3 object keys don't match the default AWS naming patterns (for example, logs moved between buckets), use `paths_regex` with a `dest_config_id` capture group to map them to `destination_config` entries.
For the full variable reference, see the [Terraform module README](https://github.com/brontoio/brontobytes-aws-ingestion-terraform#usage).
### Configure direct Lambda deployments
If you deploy the [Python Lambda](https://github.com/brontoio/brontobytes-aws-ingestion-python/blob/main/README.md) directly (CloudFormation or manual), the same configuration is provided as Lambda environment variables:
| Environment variable | Purpose |
| - | - |
| `bronto_api_key` | Bronto API key |
| `bronto_endpoint` | Regional ingestion endpoint, e.g. `https://ingestion.eu.bronto.io/` |
| `destination_config` | Base64-encoded JSON mapping S3 resource names to `dataset`, `collection`, `log_type`, and optional `tags` |
| `tags` | Comma-separated `key=value` pairs applied to all datasets — e.g. `environment=production,region=eu-west-1` |
| `paths_regex` | Base64-encoded list of regex patterns for non-standard S3 key layouts |
See the [Python forwarder README](https://github.com/brontoio/brontobytes-aws-ingestion-python/blob/main/README.md) for a sample `destination_config` payload and the full attribute reference.
***
## Cost Notes
* No CloudWatch ingestion fees — logs are read directly from S3 by the Lambda function.
* You pay for S3 storage and Lambda invocations, both of which are minimal for typical log volumes.
***
For assistance, contact [support@bronto.io](mailto:support@bronto.io).
# Amazon CloudFront Real-Time Logs
Source: https://docs.bronto.io/integrations/aws-cloudfront
Stream Amazon CloudFront real-time logs to Bronto with per-viewer-request edge details such as cache status, edge location, viewer IP, and response bytes.
Amazon CloudFront can emit logs in two distinct shapes: **real-time logs** (per-request details including cache status, edge location, URI, status code, and time to first byte, streamed within seconds) and **standard access logs** (a similar shape with delayed batch delivery — minutes to hours). Standard logging is available in two versions: **v1** delivers to S3 only, while **v2** also supports CloudWatch Logs and Kinesis Data Firehose as destinations.
## Recommended method
[**Kinesis Firehose**](./aws-firehose-logs) — real-time logs deliver to a Kinesis Data Stream, which Firehose then forwards to Bronto. This is the only path that preserves the low-latency stream.
CloudFront real-time log records arrive **TAB-delimited and positional** (fields in the fixed order configured in the real-time log configuration; unselected fields rendered as `-`). Bronto stores them raw but does **not** extract fields automatically. Build a [custom parser](/core-features/custom-parser) that splits on tab and maps columns to your configured field list, in order. See [Formats requiring a custom parser](./aws-firehose-logs#formats-requiring-a-custom-parser).
## Alternatives
* [**S3 Log Forwarder**](./aws-client-s3) — for **standard access logs** (v1, or v2 routed to S3). Different schema and delayed delivery; not equivalent to real-time logs.
* [**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — for standard access logs (v2) routed to a CloudWatch Log Group.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon CloudFront — real-time logs](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/real-time-logs.html)
# AWS CloudTrail Events
Source: https://docs.bronto.io/integrations/aws-cloudtrail
Ingest AWS API activity and management events from CloudTrail into Bronto — who did what, when, and from where — via EventBridge API Destinations.
AWS CloudTrail records API activity and management events across your AWS account — who called what, when, from which source IP, and with which result. CloudTrail is the canonical audit trail and is also the underlying source for service-level activity logs ([DynamoDB](./aws-dynamodb), [Cognito](./aws-cognito), and others).
## Recommended method
[**EventBridge API Destinations**](./aws-eventbridge) — a CloudTrail-driven EventBridge rule delivers events to Bronto in real time over HTTPS, with no intermediate storage.
## Alternatives
* [**S3 Log Forwarder**](./aws-client-s3) — CloudTrail's native destination; the forwarder Lambda subscribes to the trail's bucket and ships new objects.
* [**Kinesis Firehose**](./aws-firehose-logs) — for very high event volumes. Enable *Send to CloudWatch Logs* on the trail, then add a subscription filter on the trail's log group targeting a Firehose stream. CloudTrail events are JSON, so Bronto flattens them into searchable fields automatically — no parser needed.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [AWS CloudTrail — log file examples](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-examples.html)
# Amazon CloudWatch Metrics
Source: https://docs.bronto.io/integrations/aws-cloudwatch-metrics
Ingest Amazon CloudWatch service metrics for EC2, RDS, Lambda, and load balancers into Bronto through CloudWatch Metric Streams and Amazon Data Firehose.
Amazon CloudWatch provides metrics for AWS services and resources, including EC2, RDS, Lambda, load balancers, and other managed services. Bronto ingests these metrics through a CloudWatch Metric Stream that uses the OpenTelemetry 1.0 output format and delivers to Bronto through Amazon Data Firehose.
## Recommended method
[**AWS Kinesis Firehose for CloudWatch Metrics**](./aws-firehose-cloudwatch-metrics) — create a CloudWatch Metric Stream, select the AWS metrics and namespaces you want to export, and use a Firehose HTTP destination to deliver the OpenTelemetry 1.0 payloads to Bronto.
This managed path is intended for metrics already available in CloudWatch. It requires no Lambda function and supports both Bronto EU and US environments.
Bronto supports sums, gauges, summaries, and explicit histograms. Exponential histograms are not supported. For Sum, Summary, and Histogram metrics, the Metric Explorer provides [per-second rate functions](/metrics/explore-metrics#aggregation-functions).
## Application and infrastructure metrics
For application-instrumented metrics or infrastructure metrics collected directly from hosts and containers, use [ADOT](./aws-adot) or a [Self-Managed OpenTelemetry Collector](./aws-custom-otel). These options can send logs, metrics, and traces together and avoid routing workload telemetry through CloudWatch.
See [Host Metrics](/integrations/host-metrics) and the [OpenTelemetry Collector Contrib receivers](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver) for supported infrastructure sources.
## Verify metrics
After the selected CloudWatch namespaces emit data, open **Metric Explorer** in Bronto and select a recently emitted AWS metric. Confirm that the expected AWS dimensions, timestamp, and any optional Bronto tags are present.
## Further reading
* [AWS Kinesis Firehose for CloudWatch Metrics](./aws-firehose-cloudwatch-metrics)
* [Amazon CloudWatch metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
* [Amazon CloudWatch Metric Streams](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html)
* [OpenTelemetry metrics concepts](https://opentelemetry.io/docs/concepts/signals/metrics/)
* [Send Metrics to Bronto](/metrics/send-metrics)
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
# Amazon Cognito Activity
Source: https://docs.bronto.io/integrations/aws-cognito
Ingest Amazon Cognito user pool activity — authentication events, user management operations, and token issuance — via CloudTrail.
Amazon Cognito doesn't emit logs of its own — instead, user pool authentication events, user management operations, and token issuance are recorded in [AWS CloudTrail](./aws-cloudtrail).
## Recommended method
[**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — configure CloudTrail to deliver Cognito events to a CloudWatch Log Group, and the Bronto forwarder Lambda streams them into Bronto.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon Cognito — logging API calls with CloudTrail](https://docs.aws.amazon.com/cognito/latest/developerguide/logging-using-cloudtrail.html)
# Self-Managed OpenTelemetry Collector on AWS
Source: https://docs.bronto.io/integrations/aws-custom-otel
Deploy and configure an OpenTelemetry Collector on AWS to send logs, metrics, and traces to Bronto with full control over routing and processing.
## When to Use a Self-Managed Collector
A self-managed OpenTelemetry Collector is a good fit when you need:
* **Full configuration control** — custom processors, attribute transformation, or sampling rules
* **Fan-out** — forwarding the same telemetry to multiple backends simultaneously
* **Existing OTel infrastructure** — you already operate a collector fleet and want to add Bronto as an exporter
* **Advanced log routing** — sending logs from different types or services to different Bronto datasets or collections
If you want a simpler, AWS-managed setup without manual configuration, consider [ADOT](./aws-adot) instead.
Application logs, metrics, and traces can be sent directly to Bronto, but routing through a Collector is strongly recommended for retries, batching, and compression.
***
## Supported AWS Services
A self-managed Collector can run anywhere you control compute, and supports any source that has an OpenTelemetry receiver:
| Service / Source | Data types |
| - | - |
| Amazon EC2 | Application logs, traces, metrics, and host metrics |
| Amazon ECS / Fargate | Application logs, metrics, and traces (sidecar or dedicated task) |
| Amazon EKS | Application logs, metrics, and traces (DaemonSet or Deployment) |
| Any AWS workload reachable from the Collector | Logs / traces via OTLP, file, Kafka, Kinesis, Pub/Sub, and other [OTel receivers](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver) |
Use this method when ADOT or the Bronto-managed forwarders don't cover your scenario. For Lambda traces specifically, the [ADOT Lambda Layer](./aws-adot-lambda) is simpler.
The Collector forwards only what it receives — deploying it does not automatically collect your logs. If you aren't seeing all the logs you expect:
* **Application logs, metrics, and traces** require instrumenting your app with the [OpenTelemetry SDK](/opentelemetry/overview), or tailing its log files with the `filelog` receiver.
* **Infrastructure and database logs** (web servers, proxies, databases, message brokers) each have their own Collector setup — see [Ingesting Infrastructure and Database Logs](./infrastructure-overview).
* **AWS platform and service logs** (CloudTrail, VPC Flow Logs, RDS, and other managed services) are exported through AWS-native forwarders, not the Collector — see [Ingesting AWS Data into Bronto](./aws-overview) for the per-service source-to-method mapping.
***
## Bronto Ingestion Endpoints
| Signal | EU Region | US Region |
| - | - | - |
| Logs | `https://ingestion.eu.bronto.io/v1/logs` | `https://ingestion.us.bronto.io/v1/logs` |
| Metrics | `https://ingestion.eu.bronto.io/v1/metrics` | `https://ingestion.us.bronto.io/v1/metrics` |
| Traces | `https://ingestion.eu.bronto.io/v1/traces` | `https://ingestion.us.bronto.io/v1/traces` |
The `/v1/logs`, `/v1/metrics`, and `/v1/traces` endpoints accept **OTLP protobuf only**.
All requests require the header:
```
x-bronto-api-key:
```
See [API Keys](/Account-Management/API-Keys) for how to generate a key.
***
## Collector Configuration
The core Bronto exporter configuration is the same regardless of how you deploy the collector on AWS. For full installation instructions, platform-specific configuration, and parameter reference, see the [OpenTelemetry Collector guide](/agent-setup/open-telemetry).
The minimal configuration exports logs, metrics, and traces to Bronto:
```yaml theme={"dark"}
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
exporters:
otlphttp/bronto:
logs_endpoint: "https://ingestion..bronto.io/v1/logs"
metrics_endpoint: "https://ingestion..bronto.io/v1/metrics"
traces_endpoint: "https://ingestion..bronto.io/v1/traces"
compression: none
headers:
x-bronto-api-key:
service:
pipelines:
logs:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto]
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto]
```
Replace `` with `eu` or `us` and `` with your Bronto API key.
***
## Deployment Options on AWS
### EC2
Install the OpenTelemetry Collector directly on your EC2 instances following the [official installation guide](https://opentelemetry.io/docs/collector/installation/). Place your config at `/etc/otel/config.yaml` and run the collector as a systemd service.
### ECS (Sidecar or Daemon)
Run the collector as a sidecar container alongside each application task, or as a daemon service on each ECS instance. Use the standard `otel/opentelemetry-collector-contrib` image and mount your config via S3 or SSM Parameter Store.
### EKS (DaemonSet or Deployment)
Deploy as a DaemonSet (one collector per node) for node-level log collection, or as a Deployment behind a ClusterIP service for centralised collection. Store your config in a ConfigMap and reference it as a volume mount.
```yaml theme={"dark"}
apiVersion: v1
kind: ConfigMap
metadata:
name: otel-config
namespace: monitoring
data:
config.yaml: |
# paste your collector config here
```
***
## Log Data Organization
OpenTelemetry resource attributes provide shared identity across logs, metrics, and traces. For **logs only**, Bronto maps `service.name` to a **Dataset** and `service.namespace` to a **Collection**. Metrics and traces are not stored in datasets or collections; view them in the [Metric Explorer](/metrics/explore-metrics) and [Explore Traces](/tracing/explore-traces).
Set these as resource attributes in your SDK or collector config:
```yaml theme={"dark"}
processors:
resource:
attributes:
- key: service.name
value:
action: upsert
- key: service.namespace
value:
action: upsert
```
You can also override **log routing** on a logs exporter using HTTP headers, which is useful when one collector ships logs to multiple datasets:
| Header | Description |
| - | - |
| `x-bronto-dataset` | Overrides `service.name` for the log dataset |
| `x-bronto-collection` | Overrides `service.namespace` for the log collection |
| `x-bronto-tags` | Comma-separated tags to attach to the log dataset |
```yaml theme={"dark"}
exporters:
otlphttp/brontologs:
logs_endpoint: https://ingestion..bronto.io/v1/logs
headers:
x-bronto-api-key:
x-bronto-dataset:
x-bronto-collection:
x-bronto-tags: env=prod,team=platform
```
For Kubernetes logs, set `x-bronto-collection` to your cluster name (e.g. `cluster1-prod-eu-west-1`) to identify the source cluster in Bronto.
***
For assistance or questions, contact [support@bronto.io](mailto:support@bronto.io).
# Amazon DynamoDB Events
Source: https://docs.bronto.io/integrations/aws-dynamodb
Ingest Amazon DynamoDB management and data events — API calls, table operations, and item-level activity — into Bronto through CloudTrail and EventBridge.
Amazon DynamoDB doesn't emit logs of its own — instead, table operations, control-plane API calls, and (when enabled) item-level data events are recorded in [AWS CloudTrail](./aws-cloudtrail).
DynamoDB Streams is a separate, application-facing change-data-capture feature for items in a table. This page covers operational and audit-event ingestion via CloudTrail; DynamoDB Streams is out of scope here.
## Recommended method
[**EventBridge API Destinations**](./aws-eventbridge) — a CloudTrail-driven EventBridge rule delivers DynamoDB events to Bronto in real time over HTTPS, with no intermediate storage.
## Alternatives
* [**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — when CloudTrail is configured to publish to a CloudWatch Log Group.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon DynamoDB — logging API calls with CloudTrail](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/logging-using-cloudtrail.html)
# Amazon ECS and AWS Fargate Telemetry
Source: https://docs.bronto.io/integrations/aws-ecs
Choose the right ingestion path for container logs, metrics, and traces from Amazon ECS tasks and AWS Fargate workloads — an ADOT sidecar or FireLens.
Amazon ECS and AWS Fargate emit container `stdout` / `stderr` logs from your tasks, plus distributed traces when your applications are instrumented with OpenTelemetry.
## Recommended method
[**ADOT**](./aws-adot) — run the OpenTelemetry Collector as a sidecar to send logs, metrics, and traces directly to Bronto over OTLP. It bypasses CloudWatch and gives Lambda, ECS, and EKS workloads consistent resource identity.
## Alternatives
* [**ECS FireLens**](./aws-firelens) — Fluent Bit sidecar that ships logs from your task; lighter operational footprint than a full collector.
* [**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — for tasks that already write to CloudWatch Log Groups via the `awslogs` driver.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon ECS — using FireLens for log routing](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html)
# Amazon EKS Telemetry
Source: https://docs.bronto.io/integrations/aws-eks
Choose the right ingestion path for pod logs, kubelet metrics, control plane logs, and traces from Amazon EKS — an ADOT DaemonSet or Fargate sidecar.
Amazon EKS workloads emit pod logs and application telemetry, while the kubelet exposes node, pod, container, and volume metrics. Control-plane logs are written to CloudWatch by AWS.
## Recommended method
[**ADOT**](./aws-adot) — deploy the Collector as a DaemonSet on EC2 node groups to collect pod logs, kubelet metrics, and application telemetry. On Fargate, use a per-pod sidecar because DaemonSets cannot run there. See [Kubernetes logs and metrics](/integrations/kubernetes) for the kubelet preset and RBAC requirements.
## Alternatives
* [**Fluent Bit on EKS**](./aws-fluent-bit-eks) — DaemonSet that collects container logs from every node; lighter than a full collector.
* [**Self-Managed OTel Collector**](./aws-custom-otel) — full control over the OpenTelemetry pipeline when ADOT's distribution doesn't fit.
* [**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — required path for EKS control plane logs, which are CloudWatch-only.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon EKS — control plane logs](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
# Amazon ElastiCache Logs
Source: https://docs.bronto.io/integrations/aws-elasticache
Ship Amazon ElastiCache slow logs and engine logs for Redis and Valkey clusters to Bronto to troubleshoot latency, evictions, and command usage.
Amazon ElastiCache for Redis and Valkey can publish two log streams: the **slow log** (commands that exceeded a configured execution threshold) and the **engine log** (server events). Both can be delivered to CloudWatch Log Groups or to Amazon Data Firehose. ElastiCache for Memcached doesn't emit these log streams.
## Recommended method
[**Kinesis Firehose**](./aws-firehose-logs) — enable log delivery for the slow log and/or engine log on the cluster, destination **Amazon Data Firehose**. Both log streams are supported.
Select the **JSON** log format on the AWS side. Bronto parses and flattens JSON records automatically — no parser needed. The **TEXT** format is comma-delimited and stored raw, requiring a [custom parser](/core-features/custom-parser). See [Supported record formats](./aws-firehose-logs#supported-record-formats).
## Alternatives
* [**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — enable slow log and engine log delivery to CloudWatch on the cluster, and the Bronto forwarder Lambda subscribes to the resulting log groups.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon ElastiCache — log delivery](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Log_Delivery.html)
# AWS EventBridge API Destinations
Source: https://docs.bronto.io/integrations/aws-eventbridge
Route AWS service events directly to Bronto using Amazon EventBridge API Destinations, with no Lambda function required for forwarding or transformation.
## When to Use EventBridge
EventBridge API Destinations are a good fit when you want to:
* Forward **AWS service events** into Bronto without writing or maintaining a Lambda function
* Ingest audit and compliance data such as CloudTrail events, GuardDuty findings, or AWS Config change notifications
* React to ECS task state changes, EC2 instance events, or other AWS operational events in near real-time
For application logs or traces from running workloads, use [ADOT](./aws-adot), [FireLens](./aws-firelens), or the [CloudWatch Log Forwarder](./aws-client-cloudwatch) instead.
***
## Supported AWS Services
EventBridge API Destinations work with any AWS service that publishes to the default event bus:
| Service | Log / event type |
| - | - |
| AWS CloudTrail | Management and data event audit records |
| AWS GuardDuty | Security threat findings |
| Amazon DynamoDB | Table state changes (via CloudTrail) |
| AWS Config | Resource configuration change events |
| Amazon ECS | Task and container state changes |
| Amazon EC2 | Instance state change notifications |
| AWS Health | Service health and scheduled maintenance events |
| AWS Step Functions | State machine execution events |
| AWS WAF | Rule match events (via CloudTrail) |
Any other AWS service that publishes events to EventBridge can be captured by adding the appropriate rule pattern. See the [AWS documentation on EventBridge event sources](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-service-event.html) for the full list.
***
## How it Works
[EventBridge API Destinations](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-api-destinations.html) allow EventBridge rules to POST matched events directly to any HTTP endpoint. You define:
1. A **Connection** — stores the authentication credentials (your Bronto API key)
2. An **API Destination** — points to Bronto's ingestion endpoint using the connection
3. A **Rule** — matches the AWS events you want to capture and targets the API Destination
EventBridge delivers events as JSON payloads, handled retries natively, and requires no Lambda or additional infrastructure.
***
## Bronto Ingestion Endpoint
EventBridge posts JSON payloads, so it targets the Bronto base endpoint (no path), which accepts JSON:
| Region | Endpoint |
| - | - |
| EU | `https://ingestion.eu.bronto.io` |
| US | `https://ingestion.us.bronto.io` |
Do not use the `/v1/logs` path with EventBridge. That endpoint accepts only OTLP protobuf via an OTel-compatible agent. EventBridge sends JSON and must target the base endpoint.
See [API Keys](/Account-Management/API-Keys) for how to generate a key.
***
## Setup
### Step 1 — Create an EventBridge Connection
The connection stores your Bronto API key as a custom authorisation header.
In the AWS Console, go to **EventBridge → API Destinations → Connections → Create connection**:
| Field | Value |
| - | - |
| Connection name | `bronto-connection` |
| Authorization type | `API Key` |
| API key name | `x-bronto-api-key` |
| API key value | `` |
Via AWS CLI:
```bash theme={"dark"}
aws events create-connection \
--name bronto-connection \
--authorization-type API_KEY \
--auth-parameters '{
"ApiKeyAuthParameters": {
"ApiKeyName": "x-bronto-api-key",
"ApiKeyValue": ""
}
}'
```
### Step 2 — Create an API Destination
In **EventBridge → API Destinations → Create API destination**:
| Field | Value |
| - | - |
| Name | `bronto-destination` |
| API destination endpoint | `https://ingestion..bronto.io` |
| HTTP method | `POST` |
| Connection | `bronto-connection` (from Step 1) |
| Rate limit | Set based on your expected event volume |
### Step 3 — Create an EventBridge Rule
Create a rule that matches the events you want to forward and targets the API Destination.
Example: forward all CloudTrail management events:
```json theme={"dark"}
{
"source": ["aws.cloudtrail"],
"detail-type": ["AWS API Call via CloudTrail"]
}
```
Example: forward GuardDuty findings:
```json theme={"dark"}
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"]
}
```
Set the rule target to the `bronto-destination` API Destination created in Step 2.
***
## Data Organization
EventBridge Connections support custom HTTP headers via `InvocationHttpParameters`. Use these to set Bronto's recommended headers — see [Data Organization](/Search-and-Visualize/Partitions) for how datasets, collections, and tags work.
| Header | Description |
| - | - |
| `x-bronto-dataset` | Dataset to ingest into |
| `x-bronto-collection` | Collection name |
| `x-bronto-tags` | Comma-separated tags to attach to events |
Add them when creating or updating the Connection:
```bash theme={"dark"}
aws events update-connection \
--name bronto-connection \
--auth-parameters '{
"ApiKeyAuthParameters": {
"ApiKeyName": "x-bronto-api-key",
"ApiKeyValue": ""
},
"InvocationHttpParameters": {
"HeaderParameters": [
{ "Key": "x-bronto-dataset", "Value": "", "IsValueSecret": false },
{ "Key": "x-bronto-collection", "Value": "", "IsValueSecret": false },
{ "Key": "x-bronto-tags", "Value": "env=prod,source=eventbridge", "IsValueSecret": false }
]
}
}'
```
To route different rules to different datasets, create one Connection per dataset and attach a separate API Destination to each.
***
## Cost Notes
* No Lambda compute cost — EventBridge delivers events directly.
* You pay for EventBridge custom event publishing and API Destination invocations, which are typically very low cost relative to log ingestion alternatives.
***
For assistance, contact [support@bronto.io](mailto:support@bronto.io).
# AWS Kinesis Firehose for CloudWatch Metrics
Source: https://docs.bronto.io/integrations/aws-firehose-cloudwatch-metrics
Send Amazon CloudWatch metrics to Bronto through CloudWatch Metric Streams and an Amazon Data Firehose HTTP destination — no Lambda function required.
## Overview
[CloudWatch Metric Streams](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html) can continuously export AWS service metrics to Amazon Data Firehose. Configure the metric stream to use the OpenTelemetry 1.0 output format, then configure Firehose to deliver those metrics to Bronto's dedicated AWS metrics endpoint.
This integration requires no Lambda function. Firehose handles batching, compression, and retries for delivery to Bronto.
Bronto supports sums, gauges, summaries, and explicit histograms. Exponential histograms are not supported. For Sum, Summary, and Histogram metrics, the Metric Explorer provides [per-second rate functions](/metrics/explore-metrics#aggregation-functions).
## Prerequisites
Before you begin, you need:
* a Bronto API key with the ingestion role
* your Bronto region: `eu` or `us`
* permission to create or configure Firehose delivery streams, CloudWatch Metric Streams, and their IAM service roles
See [API Keys](/Account-Management/API-Keys) for how to generate a key.
## Step 1 — Create a Firehose delivery stream
In the AWS Console, go to **Amazon Data Firehose → Create Firehose stream** and configure:
| Setting | Value |
| - | - |
| Source | **Direct PUT** |
| Destination | **HTTP Endpoint** |
| Firehose stream name | Any valid, unique name |
`cw-metrics-to-bronto` is a suggested name only. You can use a different name that follows your organization's naming conventions.
## Step 2 — Configure the Bronto HTTP endpoint
Configure the HTTP endpoint destination:
| Setting | Value |
| - | - |
| HTTP endpoint URL | `https://ingestion..bronto.io/aws/metrics` |
| Access key | A Bronto API key with the ingestion role |
| Content encoding | **GZIP** |
Replace `` with `eu` or `us`. For example, use `https://ingestion.eu.bronto.io/aws/metrics` for the EU environment or `https://ingestion.us.bronto.io/aws/metrics` for the US environment. Do not use the direct OTLP `/v1/metrics` endpoint for this Firehose workflow.
Optionally, add `x-bronto-tags` in the destination's **Parameters** section to attach comma-separated tags to the ingested metrics, for example `environment=staging,region=eu-west-1`.
Let Firehose create a service role, or select an existing role with the permissions required to deliver to the HTTP endpoint. See AWS's [HTTP endpoint destination settings](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html) for further reading.
## Step 3 — Create a CloudWatch metric stream
In the CloudWatch console, go to **Metrics → Streams**, then choose **Create metric stream**.
Choose **Custom setup with Firehose**, select the Firehose delivery stream created in Step 1, and let CloudWatch create a service role or select an existing role that can write to the stream.
Set the output format to **OpenTelemetry 1.0**. Choose **All metrics** or select only the metric namespaces and metrics you want to send. In a CloudWatch monitoring account, you can also choose to include metrics from linked source accounts. This option applies to the Region in which you create the stream.
CloudWatch Metric Streams always include the `Minimum`, `Maximum`, `SampleCount`, and `Sum` statistics. Additional statistics can be configured in CloudWatch at additional cost.
CloudWatch charges per metric update streamed, and Firehose charges for the data it processes. Streaming all metrics can be expensive in accounts with many metrics. Select only the namespaces you need when practical.
Enter a metric stream name and create the stream. `cw-metrics-stream-to-firehose` is a suggested name only; it is not required.
For AWS's complete setup instructions, including IAM and infrastructure-as-code options, see [Custom setup with Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-metric-streams-setup-datalake.html).
## Automate with AWS CloudFormation
Use the [Bronto CloudWatch Metrics deployment package](https://github.com/bronto-community/bronto-cloudwatch-metrics) to create and update filtered metric streams across multiple AWS accounts and Regions.
For each configured target, the package creates the CloudWatch Metric Stream, encrypted Firehose delivery stream and failure-backup bucket, CloudWatch delivery logs, and required IAM roles. It supports AWS CLI profiles that use direct credentials or assume roles into target accounts, and resolves the Bronto API key from AWS Secrets Manager without reading or copying it into the deployment script.
See the repository's [README](https://github.com/bronto-community/bronto-cloudwatch-metrics#readme) for prerequisites, configuration options, example targets, filtering, dry-run deployments, linked-account metrics, retention settings, and guidance for larger AWS Organizations environments.
## Verify metric ingestion
After the selected CloudWatch namespaces emit data, open **Metric Explorer** in Bronto and select a recently emitted AWS metric. Confirm that its timestamp, dimensions, and optional `x-bronto-tags` values are present. Allow for the Firehose buffering interval before troubleshooting delivery.
If delivery fails, open the `/aws/kinesisfirehose/` log group in CloudWatch Logs and inspect the `HttpEndpointDelivery` stream. Firehose records the HTTP response code and Bronto response details there. A valid Firehose endpoint response must use HTTP `200`, contain an uncompressed `application/json` body, and return the request's `requestId` with a numeric `timestamp`. See [HTTP endpoint request and response specifications](https://docs.aws.amazon.com/firehose/latest/dev/httpdeliveryrequestresponse.html) and [HTTP endpoint troubleshooting](https://docs.aws.amazon.com/firehose/latest/dev/http_troubleshooting.html).
For supported metric types, current limitations, direct OTLP configuration, and links to the upstream OpenTelemetry documentation, see [Send Metrics](/metrics/send-metrics).
## Further reading
* [Amazon CloudWatch metrics](./aws-cloudwatch-metrics)
* [Amazon CloudWatch Metric Streams](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html)
* [Custom setup with Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-metric-streams-setup-datalake.html)
* [OpenTelemetry metrics concepts](https://opentelemetry.io/docs/concepts/signals/metrics/)
* [Send Metrics to Bronto](/metrics/send-metrics)
***
For assistance, contact [support@bronto.io](mailto:support@bronto.io).
# AWS Kinesis Firehose for Logs
Source: https://docs.bronto.io/integrations/aws-firehose-logs
Stream high-volume AWS logs into Bronto with an Amazon Data Firehose delivery stream that batches and retries HTTP delivery automatically.
## Overview
Bronto's Kinesis Firehose integration lets you stream logs directly from an [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html) delivery stream into Bronto over HTTP. It is well suited to high-throughput pipelines where data already flows through Kinesis, services that deliver natively to Firehose, and CloudWatch-native services routed to Firehose through a subscription filter.
The integration requires no Lambda function. Firehose delivers data directly to Bronto's HTTP endpoint, handling batching, compression, and retries natively.
To export CloudWatch metrics rather than logs, use [AWS Kinesis Firehose for CloudWatch Metrics](./aws-firehose-cloudwatch-metrics).
## When to Use Firehose
| Situation | Recommendation |
| - | - |
| Data already in a Kinesis Data Stream | Firehose is the natural choice |
| A service that delivers natively to Firehose | Firehose captures the full-fidelity record |
| Very high event volume (GB/hour+) | Firehose scales without additional Lambda cost |
| You want managed delivery with built-in retries | Firehose handles this natively |
| Application or container logs | Use [ADOT](./aws-adot) or the [CloudWatch Log Forwarder](./aws-client-cloudwatch) instead |
For low or moderate volume sources, the [S3 Log Forwarder](./aws-client-s3) or [CloudWatch Log Forwarder](./aws-client-cloudwatch) are simpler to operate.
***
## Bronto Ingestion Endpoint
Firehose delivers to Bronto's dedicated AWS HTTP endpoint:
| Region | Endpoint URL |
| - | - |
| EU | `https://ingestion.eu.bronto.io/aws/logs/` |
| US | `https://ingestion.us.bronto.io/aws/logs/` |
Configure the delivery stream's HTTP endpoint destination as follows:
| Setting | Value |
| - | - |
| HTTP endpoint URL | `https://ingestion..bronto.io/aws/logs/` |
| Access key | Your Bronto API key — sent by Firehose in the `X-Amz-Firehose-Access-Key` header |
| Content encoding | **GZIP** |
See [API Keys](/Account-Management/API-Keys) for how to generate a key.
No `log_format` parameter is needed. Bronto auto-detects the payload shape — it unwraps CloudWatch Logs subscription envelopes and parses JSON record bodies automatically. See [Supported record formats](#supported-record-formats) below.
A successful delivery returns `200` with `Content-Type: application/json` and a body of the form `{"requestId":"","timestamp":}`. Firehose may send up to 500 records per request.
***
## Data Organization
Set Bronto's routing headers as the HTTP endpoint **Common attributes** on the delivery stream. Firehose delivers them in the `X-Amz-Firehose-Common-Attributes` JSON header. See [Data Organization](/Search-and-Visualize/Partitions) for how datasets, collections, and tags work.
| Common attribute | Description |
| - | - |
| `x-bronto-dataset` | Dataset to ingest into |
| `x-bronto-collection` | Collection name |
| `x-bronto-tags` | Comma-separated tags to attach to events |
To route different sources to different datasets, deploy a separate Firehose delivery stream per dataset and set its common attributes accordingly.
***
## Supported record formats
Bronto detects field extraction from the **record body**, not the service that produced it. Two tiers of record body are decoded automatically; delimited and positional text formats are stored raw and require a [custom parser](/core-features/custom-parser).
### CloudWatch Logs subscription format
Services that reach Firehose through **CloudWatch Logs → subscription filter → Firehose** deliver a gzip-compressed CloudWatch Logs subscription envelope (`DATA_MESSAGE` containing one or more `logEvents`). Bronto unwraps it automatically:
* One stored event per `logEvent`.
* CloudWatch Logs metadata is preserved under `$logGroup`, `$logStream`, `$messageType`, `$owner`, and related fields.
* Firehose delivery metadata is preserved under `$firehose.requestId`, `$firehose.sourceArn`, and `$firehose.timestamp`.
* Each `logEvent` message is then parsed by its own format — JSON bodies are flattened (below), delimited text is stored raw.
This covers every service that exports via a CloudWatch Logs subscription filter, including CloudTrail, RDS/Aurora, API Gateway, and Route 53 public query logging.
### JSON record bodies
Records delivered directly to Firehose as JSON objects are parsed and flattened into searchable fields, with nested keys expressed in dot notation (for example `mail.destination.0`, `answers.0.Rdata`, `httpRequest.clientIp`). No configuration is required. Verified for Amazon SES events, Route 53 Resolver query logs, AWS WAF logs (native JSON), and ElastiCache logs **when the JSON log format is selected** on the AWS side.
AWS requires a WAF logging delivery stream's name to start with `aws-waf-logs-` before WAF will accept it as a destination.
### Formats requiring a custom parser
Delimited and positional text records are accepted and stored raw (in `@raw`) but are **not** field-extracted automatically. Each requires a Bronto [custom parser](/core-features/custom-parser):
| Source | Record shape |
| - | - |
| CloudFront real-time logs | TAB-delimited, fixed field order, unselected fields rendered as `-` |
| Route 53 public query logging | Space-delimited line |
| RDS / Aurora plain-text logs | PostgreSQL `stderr`, MySQL slow-query blocks, Aurora audit CSV (heterogeneous) |
| ElastiCache TEXT format | Comma-delimited |
| VPC Flow Logs | Space-delimited v2 positional line (`version account-id interface-id srcaddr dstaddr …`) |
For positional formats (CloudFront real-time logs, VPC Flow Logs), the custom parser must be pinned to the exact field list and order configured on the AWS side — the order is fixed, but the selected subset varies per configuration, so map columns 1:1. Where a service offers a JSON log format (ElastiCache, API Gateway), prefer it to avoid writing a parser.
***
## Setup
### Step 1 — Create the Firehose delivery stream
In the AWS Console, go to **Amazon Data Firehose → Create Firehose stream**. Choose the **source** that matches your service:
* **Direct PUT** — for services that publish directly to Firehose (SES, Route 53 Resolver, ElastiCache).
* **Amazon Kinesis Data Streams** — for CloudFront real-time logs, which deliver to a Kinesis Data Stream first.
Set the **destination** to **HTTP Endpoint**.
### Step 2 — Configure the HTTP endpoint destination
| Field | Value |
| - | - |
| HTTP endpoint URL | `https://ingestion..bronto.io/aws/logs/` |
| Access key | `` |
| Content encoding | `GZIP` |
In the destination's **Parameters** section (Firehose delivers these as the `X-Amz-Firehose-Common-Attributes` header), add `x-bronto-collection`, `x-bronto-dataset`, and optionally `x-bronto-tags`. No `log_format` parameter is needed — Bronto auto-detects the payload shape.
### Step 3 — Connect the source (CloudWatch-native services)
For services that have no native Firehose export (CloudTrail, RDS/Aurora, API Gateway, Route 53 public query logging), first publish the service's logs to a CloudWatch log group, then add a **subscription filter** on that log group targeting the Firehose stream. The subscription filter needs an IAM role trusting `logs.amazonaws.com` with permission to `firehose:PutRecord*` on the delivery stream.
CloudWatch Logs already compresses subscription data with gzip. Do not add a second compression layer in the delivery stream's data transformation — set only the destination content encoding to GZIP as above.
For native-Firehose services, configure the service's own event/log destination to point at the delivery stream (see the per-service pages: [SES](./aws-ses), [CloudFront](./aws-cloudfront), [Route 53](./aws-route53), [ElastiCache](./aws-elasticache)).
***
## Cost
Firehose pricing is based on the volume of data processed through the delivery stream (per GB). There are no Lambda compute costs. Services routed through CloudWatch Logs incur standard CloudWatch Logs ingestion charges in addition to Firehose costs.
***
For assistance, contact [support@bronto.io](mailto:support@bronto.io).
# ECS Container Logs with AWS FireLens
Source: https://docs.bronto.io/integrations/aws-firelens
Route Amazon ECS container logs directly to Bronto using AWS FireLens with Fluent Bit, skipping CloudWatch and reducing AWS log ingestion costs.
## When to Use FireLens
FireLens is a good fit when you are running workloads on ECS and want to:
* Ship container `stdout` / `stderr` logs directly to Bronto without going through CloudWatch
* Keep your setup **log-focused** without the overhead of an OTel pipeline
* Use AWS's native ECS log routing rather than managing a separate collector
If you also need **metrics or traces** from your ECS workloads, use [ADOT](./aws-adot), which handles logs, metrics, and traces through one Collector.
***
## Supported AWS Services
FireLens routes logs from containers running in:
| Service | Log type |
| - | - |
| Amazon ECS (EC2 launch type) | Container `stdout` / `stderr` |
| AWS Fargate | Container `stdout` / `stderr` |
FireLens is ECS-specific. For EKS container logs, use [Fluent Bit on EKS](./aws-fluent-bit-eks). For Lambda or other AWS services, see the [overview](./aws-overview).
***
## What is FireLens?
[AWS FireLens](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html) is an ECS log routing feature that uses a Fluent Bit (or Fluentd) sidecar container as a log driver. Container logs are piped from your application containers directly to the FireLens sidecar, which forwards them to Bronto using JSON Lines over HTTPS.
FireLens runs as a sidecar in the same ECS task. No separate infrastructure is required.
***
## Bronto Ingestion Endpoint
FireLens uses Fluent Bit's `http` output, which sends JSON Lines to the Bronto base endpoint (no path):
| Region | Endpoint |
| - | - |
| EU | `ingestion.eu.bronto.io` |
| US | `ingestion.us.bronto.io` |
This is different from the OTLP endpoints (`/v1/logs`, `/v1/metrics`, `/v1/traces`), which accept only protobuf and require an OTel-compatible agent. Fluent Bit's `http` output uses JSON Lines and must target the base endpoint.
All requests require the header:
```
x-bronto-api-key:
```
See [API Keys](/Account-Management/API-Keys) for how to generate a key.
***
## Setup
### Step 1 — Add the FireLens sidecar to your task definition
Add a `log_router` container using the AWS-provided Fluent Bit image. This container acts as the log driver for all other containers in the task.
```json theme={"dark"}
{
"name": "log-router",
"image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:stable",
"essential": true,
"firelensConfiguration": {
"type": "fluentbit",
"options": {
"enable-ecs-log-metadata": "true"
}
}
}
```
### Step 2 — Configure Fluent Bit to forward to Bronto
Pass a custom Fluent Bit configuration to the sidecar via an S3 object or SSM Parameter Store. The output section targets Bronto's base ingestion endpoint using JSON Lines format.
For the full Fluent Bit configuration reference and output options, see the [Fluent Bit setup guide](/agent-setup/fluent-bit).
```ini theme={"dark"}
[OUTPUT]
Name http
Match *
Host ingestion..bronto.io
Port 443
Format json_lines
Compress gzip
tls On
tls.verify On
Header x-bronto-api-key
Header x-bronto-dataset
Header x-bronto-collection
```
Replace `` with `eu` or `us`.
### Step 3 — Point your application containers at FireLens
Update the `logConfiguration` of each application container to use the `awsfirelens` log driver:
```json theme={"dark"}
{
"logConfiguration": {
"logDriver": "awsfirelens",
"options": {
"Name": "http",
"Host": "ingestion..bronto.io",
"Port": "443",
"Format": "json_lines",
"Compress": "gzip",
"tls": "On",
"tls.verify": "On",
"Header": "x-bronto-api-key "
}
}
}
```
***
## Data Organization
Set the recommended headers in your Fluent Bit `[OUTPUT]` block to control how data lands in Bronto — see [Data Organization](/Search-and-Visualize/Partitions) for how datasets, collections, and tags work.
| Header | Description |
| - | - |
| `x-bronto-dataset` | Dataset to ingest into |
| `x-bronto-collection` | Collection name |
| `x-bronto-tags` | Comma-separated tags to attach to events |
```ini theme={"dark"}
[OUTPUT]
Name http
Match *
Host ingestion..bronto.io
Port 443
Format json_lines
Compress gzip
tls On
tls.verify On
Header x-bronto-api-key
Header x-bronto-dataset
Header x-bronto-collection
Header x-bronto-tags env=prod,team=platform
```
To route different containers in the same task to different datasets, define multiple `[OUTPUT]` blocks with different `Match` patterns and per-output `Header` directives.
***
## Cost Notes
* **No CloudWatch ingestion fees** — logs go directly from FireLens to Bronto.
* You pay only for the ECS task compute running the FireLens sidecar, which is negligible.
* Compare with [CloudWatch Log Forwarder](./aws-client-cloudwatch) if your services already write to CloudWatch.
***
For assistance, contact [support@bronto.io](mailto:support@bronto.io).
# Kubernetes Logs with Fluent Bit on EKS
Source: https://docs.bronto.io/integrations/aws-fluent-bit-eks
Deploy Fluent Bit as a DaemonSet on Amazon EKS to collect Kubernetes container logs and forward them to Bronto, a lightweight alternative to the OTel Collector.
## When to Use Fluent Bit on EKS
Fluent Bit as an EKS DaemonSet is a good fit when you want to:
* Collect **container logs** from all pods on every node without modifying application code
* Keep the setup simple — Fluent Bit is lighter and easier to configure than a full OTel Collector when you only need logs
* Avoid CloudWatch log ingestion fees
If you also need **traces** from your Kubernetes workloads, use the [Self-Managed OTel Collector](./aws-custom-otel) or [ADOT](./aws-adot) instead, as Fluent Bit does not handle trace data.
***
## Supported AWS Services
Fluent Bit on EKS collects logs from containers running in:
| Service | Log type |
| - | - |
| Amazon EKS (EC2 node groups) | Pod `stdout` / `stderr`, enriched with Kubernetes metadata |
| Amazon EKS (Fargate) | Pod `stdout` / `stderr` (via Fargate-built-in log router) |
For ECS container logs, use [ECS FireLens](./aws-firelens). For non-Kubernetes AWS services, see the [overview](./aws-overview).
***
## How it Works
A Fluent Bit DaemonSet runs one pod per node. Each pod reads container logs from the node's `/var/log/containers/` path, enriches them with Kubernetes metadata (pod name, namespace, labels), and forwards them to Bronto using JSON Lines over HTTPS.
For the full Fluent Bit configuration reference and output options, see the [Fluent Bit setup guide](/agent-setup/fluent-bit).
***
## Bronto Ingestion Endpoint
Fluent Bit's `http` output sends JSON Lines to the Bronto base endpoint (no path):
| Region | Endpoint |
| - | - |
| EU | `ingestion.eu.bronto.io` |
| US | `ingestion.us.bronto.io` |
This is different from the OTLP endpoints (`/v1/logs`, `/v1/traces`), which accept only protobuf and require an OTel-compatible agent. Fluent Bit's `http` output uses JSON Lines and must target the base endpoint.
All requests require the header:
```
x-bronto-api-key:
```
See [API Keys](/Account-Management/API-Keys) for how to generate a key.
***
## Setup
### Step 1 — Deploy Fluent Bit via Helm
The easiest way to deploy Fluent Bit on EKS is via the official Helm chart.
```bash theme={"dark"}
helm repo add fluent https://fluent.github.io/helm-charts
helm repo update
helm install fluent-bit fluent/fluent-bit \
--namespace monitoring \
--create-namespace \
--values values.yaml
```
### Step 2 — Configure the Bronto output
Create a `values.yaml` file that configures Fluent Bit to tail container logs and forward them to Bronto:
```yaml theme={"dark"}
config:
inputs: |
[INPUT]
Name tail
Path /var/log/containers/*.log
multiline.parser docker, cri
Tag kube.*
Mem_Buf_Limit 5MB
Skip_Long_Lines On
filters: |
[FILTER]
Name kubernetes
Match kube.*
Kube_URL https://kubernetes.default.svc:443
Kube_CA_File /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
Kube_Token_File /var/run/secrets/kubernetes.io/serviceaccount/token
Merge_Log On
Keep_Log Off
K8S-Logging.Parser On
K8S-Logging.Exclude On
outputs: |
[OUTPUT]
Name http
Match kube.*
Host ingestion..bronto.io
Port 443
Format json_lines
Compress gzip
tls On
tls.verify On
Header x-bronto-api-key
Header x-bronto-collection
tolerations:
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
```
Replace `` with `eu` or `us`, `` with your Bronto API key, and `` with a name that identifies this cluster in Bronto (e.g. `cluster1-prod-eu-west-1`).
### Step 3 — Verify
After deployment, logs should appear in Bronto Search. You can filter by `collection` to isolate logs from this cluster.
```bash theme={"dark"}
kubectl get pods -n monitoring -l app.kubernetes.io/name=fluent-bit
```
All pods should show `Running` status.
***
## Data Organization
Set the recommended headers in your Fluent Bit `[OUTPUT]` block to control how data lands in Bronto — see [Data Organization](/Search-and-Visualize/Partitions) for how datasets, collections, and tags work.
| Header | Description |
| - | - |
| `x-bronto-dataset` | Dataset to ingest into |
| `x-bronto-collection` | Collection name (typically your cluster name) |
| `x-bronto-tags` | Comma-separated tags to attach to events |
```ini theme={"dark"}
[OUTPUT]
Name http
Match kube.*
Host ingestion..bronto.io
Port 443
Format json_lines
Compress gzip
tls On
tls.verify On
Header x-bronto-api-key
Header x-bronto-dataset
Header x-bronto-collection
Header x-bronto-tags env=prod,team=platform
```
By default, Bronto can also infer the dataset from Kubernetes metadata (container name, pod labels). To route logs from specific namespaces or pods to different datasets, add a `rewrite_tag` filter and configure multiple `[OUTPUT]` blocks with different `Match` patterns and `x-bronto-dataset` headers. See the [Fluent Bit setup guide](/agent-setup/fluent-bit) for full routing examples.
***
## Cost Notes
* **No CloudWatch ingestion fees** — logs go directly from Fluent Bit to Bronto.
* Fluent Bit is lightweight; the DaemonSet pods typically consume less than 50MB memory per node.
***
## EKS Fargate
EKS Fargate works differently from EKS on EC2 node groups. There are no customer-managed nodes and the node filesystem isn't exposed to pods, so the DaemonSet pattern described above doesn't apply. AWS instead provides a built-in Fluent Bit log router, configured via a `ConfigMap` in the `aws-observability` namespace, that captures `stdout` / `stderr` from every Fargate pod cluster-wide.
The constraint that shapes this section is that the Fargate built-in Fluent Bit accepts only a fixed allowlist of output plugins:
* `cloudwatch` / `cloudwatch_logs`
* `firehose` / `kinesis_firehose`
* `kinesis`
* `es` (Elasticsearch / OpenSearch)
The `http` plugin — which would let Fluent Bit POST directly to Bronto's ingestion endpoint — is **not** on this allowlist, and any `ConfigMap` referencing it is rejected at admission time. This is a known AWS platform limitation tracked by [containers-roadmap#1242](https://github.com/aws/containers-roadmap/issues/1242), open since 2021. It affects every third-party log destination equally, not just Bronto.
The restriction applies only to the AWS-managed Fluent Bit router. Your own OpenTelemetry Collector — running as an ordinary Kubernetes Deployment in the cluster — has no such restriction and can send to any HTTP endpoint, including Bronto.
There are three viable paths for Fargate pod logs into Bronto. Most teams use a combination during and after migration.
### Path A — Fluent Bit → Kinesis Firehose → Bronto
The Fargate built-in Fluent Bit writes to a Kinesis Firehose delivery stream, which forwards records to Bronto.
```
EKS Fargate Pods → Built-in Fluent Bit (kinesis_firehose) → Kinesis Firehose → Bronto
```
This is the most direct path available given Fargate's constraints — a single intermediate hop, both ends managed services. It uses Bronto's [Kinesis Firehose integration](./aws-firehose-logs). The `kinesis_firehose` plugin emits one JSON record per log line, so Bronto flattens the record's Kubernetes metadata into searchable fields automatically (`kubernetes.pod_name`, `kubernetes.namespace_name`, `kubernetes.labels.*`, `stream`) — no custom parser required.
Enable `Merge_Log On` in the `kubernetes` filter so an application's structured JSON log line is merged into the record root and its fields are extracted too. Without it, the raw application line is preserved as a single `log` string.
Example `ConfigMap` output block:
```ini theme={"dark"}
[OUTPUT]
Name kinesis_firehose
Match kube.*
region
delivery_stream
```
Customers already running a Firehose pipeline (for example, currently writing logs to S3 or OpenSearch) can typically reuse the same Firehose stream by reconfiguring its destination, with no changes to the in-cluster Fluent Bit configuration.
### Path B — Fluent Bit → CloudWatch Logs → Bronto
The Fargate built-in Fluent Bit writes to a CloudWatch log group, and the [Bronto CloudWatch Log Forwarder](./aws-client-cloudwatch) ingests events from that group.
```
EKS Fargate Pods → Built-in Fluent Bit (cloudwatch_logs) → CloudWatch Logs → Bronto Forwarder → Bronto
```
The trade-off versus Path A is the additional CloudWatch ingestion cost, which can be significant at high log volume. Path A avoids that cost by skipping CloudWatch entirely, so it is generally preferred for high-volume Fargate logging.
Example `ConfigMap` output block:
```ini theme={"dark"}
[OUTPUT]
Name cloudwatch_logs
Match kube.*
region
log_group_name /aws/eks//fargate
log_stream_prefix from-fluent-bit-
auto_create_group true
```
### Path C — Application → OTel Collector → Bronto
Applications emit log records over OTLP using the OpenTelemetry logs SDK, sending them directly to your existing OTel Collector. The collector then forwards to Bronto via OTLP/HTTP — the same exporter pattern used for traces.
```
Application (OTel logs SDK) → OTel Collector → Bronto
```
This path is the recommended direction for new services and for existing services where instrumentation is feasible. It bypasses the Fluent Bit allowlist entirely and gives trace-to-log correlation automatically. Logs and traces share `service.name` / `service.namespace` identity, but only logs use those attributes for dataset and collection routing. See [Self-Managed OTel Collector](./aws-custom-otel) for collector configuration and the [OpenTelemetry SDK guides](/opentelemetry/overview) for per-language instrumentation.
Example collector logs pipeline (append `otlphttp/bronto-logs` to any existing logs pipeline):
```yaml theme={"dark"}
exporters:
otlphttp/bronto-logs:
logs_endpoint: "https://ingestion..bronto.io/v1/logs"
headers:
x-bronto-api-key: "${env:BRONTO_API_KEY}"
x-bronto-collection: ""
service:
pipelines:
logs:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlphttp/, otlphttp/bronto-logs]
```
Path C is **not** a fit for third-party container images you can't modify, short-lived init containers and jobs, runtimes where the OTel logs SDK is still maturing, or applications under heavy change-control. Workloads in those categories continue on Path A or Path B indefinitely — both remain fully supported.
### Running multiple destinations during migration
The Fargate `ConfigMap` accepts multiple `[OUTPUT]` blocks, so logs can be sent to Bronto and an existing destination in parallel during cutover:
```ini theme={"dark"}
output.conf: |
# Existing destination — kept active during migration
[OUTPUT]
Name kinesis_firehose
Match kube.*
region
delivery_stream
# New destination — Bronto via a separate Firehose stream
[OUTPUT]
Name kinesis_firehose
Match kube.*
region
delivery_stream
```
For Path C, the equivalent is listing multiple exporters in the OTel Collector's logs pipeline.
### Traces and metrics on Fargate
Traces from Fargate workloads go through your in-cluster OTel Collector exactly as on EC2 node groups — add Bronto as an OTLP/HTTP exporter on the traces pipeline. See [ADOT](./aws-adot) or [Self-Managed OTel Collector](./aws-custom-otel) for collector deployment guidance.
Add the Bronto metrics endpoint and exporter to the Collector's existing metrics pipeline. Exponential histograms are not supported. For Sum, Summary, and Histogram metrics, the Metric Explorer provides [per-second rate functions](/metrics/explore-metrics#aggregation-functions).
```yaml theme={"dark"}
exporters:
otlphttp/bronto-metrics:
metrics_endpoint: "https://ingestion..bronto.io/v1/metrics"
headers:
x-bronto-api-key:
service:
pipelines:
metrics:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto-metrics]
```
### Summary
| Signal | Path | Status |
| - | - | - |
| Logs (A) | Fluent Bit (built-in) → Kinesis Firehose → Bronto | GA |
| Logs (B) | Fluent Bit (built-in) → CloudWatch Logs → Bronto | GA |
| Logs (C) | Application (OTel logs SDK) → OTel Collector → Bronto | GA where applications can be instrumented |
| Traces | Application → OTel Collector → Bronto | GA |
| Metrics | Application → OTel Collector → Bronto | GA |
Recommended starting point on EKS Fargate:
1. Add Bronto as an exporter on your existing OTel Collector for application logs, metrics, and traces.
2. Stand up a Fluent Bit log path in parallel — Path A (Firehose) for the lowest cost, or Path B (CloudWatch) if you already have a CloudWatch pipeline — and send to both your existing destination and Bronto until you've validated coverage.
3. Adopt Path C incrementally for new services and high-value existing services. Workloads that can't be instrumented stay on Path A or Path B.
***
For assistance, contact [support@bronto.io](mailto:support@bronto.io).
# AWS GuardDuty Findings
Source: https://docs.bronto.io/integrations/aws-guardduty
Ingest AWS GuardDuty threat findings into Bronto — compromised credentials, unusual API calls, malware, and suspicious network activity — via EventBridge.
AWS GuardDuty produces findings — threat-intelligence alerts covering compromised credentials, unusual API calls, reconnaissance activity, malware on EC2 and EKS workloads, and other security events.
## Recommended method
[**EventBridge API Destinations**](./aws-eventbridge) — GuardDuty publishes findings as EventBridge events, so a rule with an API Destination delivers them to Bronto in real time over HTTPS.
## Alternatives
* [**S3 Log Forwarder**](./aws-client-s3) — for environments that already export findings to an S3 bucket via the GuardDuty findings-export feature.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [AWS GuardDuty — exporting findings](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_exportfindings.html)
# AWS Lambda Telemetry
Source: https://docs.bronto.io/integrations/aws-lambda
Compare AWS Lambda ingestion options for function logs, platform logs, metrics, and traces to choose between CloudWatch, extensions, or the ADOT layer.
AWS Lambda emits function logs (your application output), platform logs (cold starts, timeouts, out-of-memory events), and — when instrumented — distributed traces. The right ingestion path depends on your runtime and whether you also want traces.
## Recommended method
[**ADOT Lambda Layer**](./aws-adot-lambda) — sends logs, metrics, and traces directly to Bronto over OTLP on supported runtimes. The signals generated automatically depend on the ADOT layer and instrumentation versions you deploy.
## Alternatives
* [**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — captures Lambda's automatic `stdout` / `stderr` and works with runtimes the ADOT layer doesn't support (Ruby, custom runtimes).
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [AWS Lambda — monitoring with CloudWatch Logs](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html)
# Ingesting AWS Data into Bronto
Source: https://docs.bronto.io/integrations/aws-overview
An overview of the available methods for sending AWS log, trace, and metric data to Bronto, with guidance on choosing the right approach.
## Overview
Bronto supports several methods for ingesting data from AWS environments. The right choice depends on where your logs originate, whether you need trace data, your infrastructure preferences, and cost constraints.
***
## Service-to-Method Mapping
Different AWS services suit different ingestion methods. The recommended method is the simplest path that gets the data into Bronto; alternatives may be preferable depending on your existing infrastructure or cost constraints. Each service name in the table below links to a per-source landing page with a short summary of what the service emits and the configuration entry points for that data.
Where the OpenTelemetry SDK supports your runtime, prefer OTel-based instrumentation — it sends logs, metrics, and traces through one Collector, gives you consistent resource identity, and avoids CloudWatch ingestion fees. The [ADOT Lambda Layer](./aws-adot-lambda) covers Lambda; [ADOT](./aws-adot) or a [Self-Managed OTel Collector](./aws-custom-otel) cover ECS, EKS, and EC2 workloads.
| AWS Service | Recommended Method | Alternatives |
| - | - | - |
| [Amazon CloudWatch metrics](./aws-cloudwatch-metrics) | [Kinesis Firehose for CloudWatch Metrics](./aws-firehose-cloudwatch-metrics) (Metric Streams with OpenTelemetry 1.0) | [ADOT](./aws-adot) or [Self-Managed OTel Collector](./aws-custom-otel) for workload metrics |
| [AWS Lambda](./aws-lambda) (logs + traces) | [ADOT Lambda Layer](./aws-adot-lambda) (OTel-supported runtimes) | [CloudWatch Log Forwarder](./aws-client-cloudwatch) (for stdout/stderr capture or unsupported runtimes) |
| [Amazon ECS / Fargate](./aws-ecs) | [ADOT](./aws-adot) (OTel) | [ECS FireLens](./aws-firelens), [CloudWatch Log Forwarder](./aws-client-cloudwatch) |
| [Amazon EKS](./aws-eks) | [ADOT](./aws-adot) (OTel) | [Fluent Bit on EKS](./aws-fluent-bit-eks), [Self-Managed OTel Collector](./aws-custom-otel), [CloudWatch Log Forwarder](./aws-client-cloudwatch) (control plane logs) |
| [Amazon Bedrock](./aws-bedrock) (GenAI traces + logs) | [ADOT](./aws-adot) (OTel) — see [LLM observability](/ai-features/aws-bedrock) | Direct OTLP to Bronto, [Self-Managed OTel Collector](./aws-custom-otel) |
| [Amazon Bedrock AgentCore](./aws-agentcore) (agent traces + logs) | [ADOT](./aws-adot) (OTel) — see [agent observability](/ai-features/aws-agentcore) | Direct OTLP to Bronto, [Self-Managed OTel Collector](./aws-custom-otel) |
| [Amazon RDS / Aurora (PostgreSQL)](./aws-rds-postgresql) | [CloudWatch Log Forwarder](./aws-client-cloudwatch) | [Kinesis Firehose](./aws-firehose-logs) (high-volume) |
| [Amazon RDS / Aurora (MySQL)](./aws-rds-mysql) | [CloudWatch Log Forwarder](./aws-client-cloudwatch) | [Kinesis Firehose](./aws-firehose-logs) (high-volume) |
| [AWS CloudTrail](./aws-cloudtrail) | [EventBridge API Destinations](./aws-eventbridge) | [S3 Log Forwarder](./aws-client-s3), [Kinesis Firehose](./aws-firehose-logs) (high-volume) |
| [Amazon API Gateway](./aws-api-gateway) | [CloudWatch Log Forwarder](./aws-client-cloudwatch) | [Kinesis Firehose](./aws-firehose-logs) (high-volume access logs) |
| [ALB / NLB access logs](./aws-alb) | [S3 Log Forwarder](./aws-client-s3) | — |
| [VPC Flow Logs](./aws-vpc-flow-logs) | [S3 Log Forwarder](./aws-client-s3) | [CloudWatch Log Forwarder](./aws-client-cloudwatch), [Kinesis Firehose](./aws-firehose-logs) (custom parser required) |
| [AWS WAF](./aws-waf) | [S3 Log Forwarder](./aws-client-s3) | [Kinesis Firehose](./aws-firehose-logs) (native JSON), [CloudWatch Log Forwarder](./aws-client-cloudwatch) |
| [Amazon DynamoDB](./aws-dynamodb) | [EventBridge API Destinations](./aws-eventbridge) (via CloudTrail) | [CloudWatch Log Forwarder](./aws-client-cloudwatch) |
| [Amazon ElastiCache](./aws-elasticache) | [CloudWatch Log Forwarder](./aws-client-cloudwatch) | [Kinesis Firehose](./aws-firehose-logs) (high-volume) |
| [Amazon CloudFront](./aws-cloudfront) (real-time logs) | [Kinesis Firehose](./aws-firehose-logs) | [S3 Log Forwarder](./aws-client-s3) (standard logs) |
| [Amazon Route 53](./aws-route53) | [CloudWatch Log Forwarder](./aws-client-cloudwatch) (public zone query logs) | [Kinesis Firehose](./aws-firehose-logs) (Resolver query logs, JSON), [S3 Log Forwarder](./aws-client-s3) (Resolver query logs) |
| [AWS GuardDuty](./aws-guardduty) | [EventBridge API Destinations](./aws-eventbridge) | [S3 Log Forwarder](./aws-client-s3) |
| [Amazon SES](./aws-ses) | [Kinesis Firehose](./aws-firehose-logs) (full event bodies) | — |
| [AWS Step Functions](./aws-step-functions) | [CloudWatch Log Forwarder](./aws-client-cloudwatch) | [EventBridge API Destinations](./aws-eventbridge) |
| [Amazon Cognito](./aws-cognito) | [CloudWatch Log Forwarder](./aws-client-cloudwatch) | — |
***
## Ingestion Methods
Bronto supports the following AWS ingestion methods:
* [S3 Log Forwarder](./aws-client-s3) — Lambda subscribes to S3 events and forwards new log objects.
* [CloudWatch Log Forwarder](./aws-client-cloudwatch) — Lambda subscribes to CloudWatch log groups and streams events.
* [ECS FireLens](./aws-firelens) — Fluent Bit sidecar in your ECS task definitions; no Lambda required.
* [Fluent Bit on EKS](./aws-fluent-bit-eks) — Fluent Bit DaemonSet that collects container logs from every EKS node.
* [ADOT — ECS / EKS](./aws-adot) — AWS-managed OpenTelemetry Collector distribution for ECS and EKS workloads.
* [ADOT Lambda Layer](./aws-adot-lambda) — OpenTelemetry instrumentation layer for AWS Lambda functions.
* [Self-Managed OTel Collector](./aws-custom-otel) — Your own OpenTelemetry Collector deployment for full control.
* [EventBridge API Destinations](./aws-eventbridge) — Native EventBridge rule that POSTs events directly to Bronto.
* [AWS Kinesis Firehose for Logs](./aws-firehose-logs) — Direct delivery of high-volume AWS log records.
* [AWS Kinesis Firehose for CloudWatch Metrics](./aws-firehose-cloudwatch-metrics) — Delivery of OpenTelemetry 1.0 CloudWatch Metric Streams.
***
## AWS VPC Private Link
Bronto can be connected via an AWS VPC Private Link, keeping all traffic within the AWS network and avoiding public internet egress. This is available on request — contact [support@bronto.io](mailto:support@bronto.io) to set this up.
# Amazon RDS and Aurora (MySQL) Logs
Source: https://docs.bronto.io/integrations/aws-rds-mysql
Ship MySQL slow query, general, and error logs from Amazon RDS and Aurora MySQL to Bronto to diagnose slow queries, connection failures, and replication issues.
Amazon RDS and Aurora can publish MySQL logs — the slow query log, general log, and error log — to CloudWatch Log Groups, where they become available for ingestion.
## Recommended method
[**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — enable MySQL log exports on the DB instance or cluster and the Bronto forwarder Lambda subscribes to the resulting CloudWatch Log Groups and streams events into Bronto.
## Alternatives
* [**Kinesis Firehose**](./aws-firehose-logs) — for very high-volume environments. Enable MySQL log exports to CloudWatch Logs, then add a subscription filter on each log group targeting a Firehose stream. MySQL logs arrive as plain text (slow-query blocks, error and general logs), so Bronto stores them raw and a [custom parser](/core-features/custom-parser) is required to extract fields. See [Formats requiring a custom parser](./aws-firehose-logs#formats-requiring-a-custom-parser).
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon RDS — MySQL log access](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html)
# Amazon RDS and Aurora (PostgreSQL) Logs
Source: https://docs.bronto.io/integrations/aws-rds-postgresql
Ship PostgreSQL slow query, connection, and error logs from Amazon RDS and Aurora to Bronto to troubleshoot query latency, locking, and auth failures.
Amazon RDS and Aurora can publish PostgreSQL logs — slow queries, connections, errors, and autovacuum activity — to CloudWatch Log Groups, where they become available for ingestion.
## Recommended method
[**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — enable PostgreSQL log exports on the DB instance or cluster (`log_statement`, `log_min_duration_statement`, etc.) and the Bronto forwarder Lambda subscribes to the resulting CloudWatch Log Groups and streams events into Bronto.
## Alternatives
* [**Kinesis Firehose**](./aws-firehose-logs) — for very high-volume environments. Enable PostgreSQL log exports to CloudWatch Logs, then add a subscription filter on the log group targeting a Firehose stream. PostgreSQL logs arrive as plain `stderr` text, so Bronto stores them raw and a [custom parser](/core-features/custom-parser) is required to extract fields. See [Formats requiring a custom parser](./aws-firehose-logs#formats-requiring-a-custom-parser).
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon RDS — PostgreSQL log access](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.PostgreSQL.html)
# Amazon Route 53 DNS Query Logs
Source: https://docs.bronto.io/integrations/aws-route53
Ingest Amazon Route 53 public DNS query logs and Resolver query logs into Bronto to investigate DNS traffic patterns, resolver failures, and suspicious lookups.
Amazon Route 53 produces two types of query logs with different delivery options and record shapes, so they take different ingestion paths:
* **Resolver query logs** — for resolver endpoints in your VPCs. Can be delivered **directly to Kinesis Data Firehose** (also CloudWatch or S3). Records are **JSON**.
* **Public DNS query logs** — for hosted zones (which queries hit which records). Written to **CloudWatch Logs only**. Records are a **space-delimited line**.
## Recommended method
**Resolver query logs → [Kinesis Firehose](./aws-firehose-logs).** Configure the Resolver query-log configuration to deliver to a Firehose stream. Records arrive as JSON (`query_name`, `query_type`, `rcode`, `answers[]`, `srcaddr`, …) and Bronto parses and flattens them into searchable fields automatically — no parser needed.
**Public zone query logs → [CloudWatch Log Forwarder](./aws-client-cloudwatch).** Public hosted-zone query logging can only be written to CloudWatch Logs; the Bronto forwarder Lambda subscribes to the resulting log group.
Public query-log records are space-delimited, not JSON. If you route them to Firehose via a CloudWatch Logs subscription filter, Bronto stores each line raw and a [custom parser](/core-features/custom-parser) is required to extract fields. See [Formats requiring a custom parser](./aws-firehose-logs#formats-requiring-a-custom-parser).
## Alternatives
* [**S3 Log Forwarder**](./aws-client-s3) — for Resolver query logs delivered to an S3 bucket.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon Route 53 — logging DNS queries](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html)
# Amazon SES Sending Events
Source: https://docs.bronto.io/integrations/aws-ses
Send Amazon SES delivery, bounce, complaint, reject, open, and click events to Bronto to monitor email deliverability and investigate send failures.
Amazon SES emits sending-activity events — deliveries, bounces, complaints, rejects, rendering failures, opens, and clicks — through a configurable event destination on each configuration set. SES supports CloudWatch, Kinesis Data Firehose, Amazon SNS, EventBridge, and Pinpoint as event destinations.
## Recommended method
[**Kinesis Firehose**](./aws-firehose-logs) — add a **Kinesis Data Firehose event destination** to the configuration set and point it at Bronto. This delivers the full event JSON — `mail{}`, the event-specific object (`delivery{}`, `bounce{}`, `open{}`, `click{}`, …), and nested `tags{}` — which Bronto parses and flattens into searchable fields automatically.
SES's **CloudWatch** event destination publishes CloudWatch **metrics** (counts of sends, bounces, etc.), not a log group containing the event bodies. To capture the event JSON itself, use the Firehose event destination.
## Alternatives
For metric-level monitoring only, the configuration set can publish to a CloudWatch event destination, but this does not produce the per-event JSON that Bronto ingests.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [Amazon SES — monitor sending activity](https://docs.aws.amazon.com/ses/latest/dg/monitor-sending-activity.html)
# AWS Step Functions Execution Logs
Source: https://docs.bronto.io/integrations/aws-step-functions
Ingest AWS Step Functions execution history — state transitions, input/output payloads, errors, and durations — into Bronto to debug workflow failures at scale.
AWS Step Functions can emit execution-level logs — state transitions, input and output payloads, errors, and per-state durations — to CloudWatch Log Groups. State machines also publish status-change events to EventBridge.
## Recommended method
[**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — enable logging on each state machine with a destination Log Group, and the Bronto forwarder Lambda subscribes to it.
## Alternatives
* [**EventBridge API Destinations**](./aws-eventbridge) — for execution status-change events (started, succeeded, failed, timed out) when full step-by-step detail isn't required.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [AWS Step Functions — logging with CloudWatch Logs](https://docs.aws.amazon.com/step-functions/latest/dg/cw-logs.html)
# VPC Flow Logs
Source: https://docs.bronto.io/integrations/aws-vpc-flow-logs
Ingest VPC Flow Logs — IP traffic records for network interfaces in your VPC, useful for security analysis, network diagnostics, and compliance.
VPC Flow Logs capture IP traffic to and from network interfaces in your VPC — source and destination IPs and ports, protocol, packet and byte counts, and accept / reject status. They underpin security analysis, network diagnostics, and compliance use cases.
## Recommended method
[**S3 Log Forwarder**](./aws-client-s3) — configure flow logs at the VPC, subnet, or network interface level with S3 as the destination, then point the Bronto forwarder Lambda at the bucket.
## Alternatives
* [**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — when flow logs are already published to a CloudWatch Log Group.
* [**Kinesis Firehose**](./aws-firehose-logs) — for very high traffic volumes. Flow logs can be delivered directly to Firehose (or via a CloudWatch Logs subscription filter).
The default v2 flow-log record is a **space-delimited positional line** (`version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status`). Bronto stores it raw and does **not** extract these fields automatically. Build a [custom parser](/core-features/custom-parser) pinned to the exact field order configured on the flow log. See [Formats requiring a custom parser](./aws-firehose-logs#formats-requiring-a-custom-parser).
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
# AWS WAF Logs
Source: https://docs.bronto.io/integrations/aws-waf
Ingest AWS WAF web ACL traffic logs — allowed, blocked, and counted requests with rule match details — into Bronto for security monitoring and threat hunting.
AWS WAF can log every request that hits a web ACL — including the rule that matched, the action taken (allow, block, count, captcha), the source IP, and the request headers. The logs are the foundation for security analytics and rule tuning.
## Recommended method
[**S3 Log Forwarder**](./aws-client-s3) — configure logging on each web ACL with an S3 destination, then point the Bronto forwarder Lambda at the bucket.
## Alternatives
* [**Kinesis Firehose**](./aws-firehose-logs) — for very high request volumes. WAF delivers logs directly to Firehose as native JSON, so Bronto flattens them into searchable fields automatically (`action`, `httpRequest.clientIp`, `terminatingRuleId`, …) — no parser needed.
AWS requires the Firehose delivery stream name to start with `aws-waf-logs-` before WAF will allow it as a logging destination.
* [**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — when logs are routed to a CloudWatch Log Group instead.
See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.
## References
* [AWS WAF — logging](https://docs.aws.amazon.com/waf/latest/developerguide/logging.html)
# Azure Container Instances Telemetry
Source: https://docs.bronto.io/integrations/azure-aci
Choose the right ingestion path for container stdout logs, metrics, and traces from Azure Container Instances, using an OpenTelemetry Collector sidecar.
Azure Container Instances emits container `stdout` / `stderr` logs and — when your applications are instrumented with OpenTelemetry — metrics and distributed traces. Containers in the same container group share a network namespace, so a collector can run alongside your app as a sidecar.
## Recommended method
[**Self-Managed OTel Collector**](./azure-otel#self-managed-opentelemetry-collector) — run the Collector as a sidecar. A same-group application normally uses `localhost:4317` for OTLP/gRPC or `localhost:4318` for OTLP/HTTP; use the actual receiver address and security settings when your configuration differs. The Collector forwards all three signals to Bronto.
See [Ingesting Azure Data into Bronto](./azure-overview) for the full service-to-method mapping.
## References
* [Retrieve container logs and events in Azure Container Instances](https://learn.microsoft.com/en-us/azure/container-instances/container-instances-log-analytics)
# Azure Kubernetes Service Telemetry
Source: https://docs.bronto.io/integrations/azure-aks
Choose the right ingestion path for pod logs, kubelet metrics, control plane logs, and traces from Azure Kubernetes Service with a Collector DaemonSet.
AKS workloads emit pod logs and application telemetry, while the kubelet exposes node, pod, container, and volume metrics. Control-plane logs are exported through Azure Monitor diagnostic settings.
## Recommended method
[**Self-Managed OTel Collector**](./azure-otel#self-managed-opentelemetry-collector) — deploy the Collector as a DaemonSet to collect pod logs, kubelet metrics, and application telemetry. See [Kubernetes logs and metrics](/integrations/kubernetes) for the Helm preset and RBAC requirements.
For **Windows node pools**, run the Collector DaemonSet on the Windows nodes (the `opentelemetry-collector-contrib` image ships the Windows receivers) to collect Windows Event Log and IIS logs, plus Windows performance-counter and IIS metrics — see [Collecting Windows OS Logs and Metrics](./azure-windows-logs).
## Alternatives
* [**Azure Event Hub Forwarder**](./azure-client) — required path for AKS control plane / diagnostic logs, which are exported through Azure Monitor diagnostic settings to an Event Hub.
See [Ingesting Azure Data into Bronto](./azure-overview) for the full service-to-method mapping.
## References
* [Monitor Azure Kubernetes Service](https://learn.microsoft.com/en-us/azure/aks/monitor-aks)
# Azure App Service Telemetry
Source: https://docs.bronto.io/integrations/azure-app-service
Choose the right ingestion path for application logs, web server logs, platform diagnostics, and traces from Azure App Service with OpenTelemetry.
Azure App Service emits application logs (your code's `stdout` output), HTTP / web server logs, and platform diagnostic logs, and — when your application is instrumented — distributed traces. App Service does not run a node-level agent, so application telemetry is best emitted directly from the app.
## Recommended method
[**OpenTelemetry SDK**](/opentelemetry/overview) — instrument the application and send logs, metrics, and traces to Bronto, either directly or through a [Collector](./azure-otel#self-managed-opentelemetry-collector).
## Alternatives
* [**Azure Monitor OpenTelemetry Distro**](./azure-monitor-otel-distro) — if you already use Application Insights, you can forward the same standard OTLP logs, metrics, and traces to Bronto.
* [**Azure Event Hub Forwarder**](./azure-client) — for App Service platform / diagnostic logs exported through Azure Monitor diagnostic settings.
See [Ingesting Azure Data into Bronto](./azure-overview) for the full service-to-method mapping.
## References
* [Enable diagnostics logging for apps in Azure App Service](https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs)
# Azure Event Hub Forwarder
Source: https://docs.bronto.io/integrations/azure-client
Forward Azure logs to Bronto using Azure Event Hub and the Bronto log forwarder to centralize platform, diagnostic, and application telemetry.
## Bronto Log Forwarder for Azure
### How it works
The Bronto log forwarder for Azure is built around a Function App that collects log data from Azure Event Hub and sends it to Bronto.
### Steps
Set Up Event Hub Infrastructure Using Our Terraform Module: This will automatically create and configure relevant resources (e.g. Event Hub, Function App, etc), using the details from the configurations below. The creation of an Event Hub is optional with the module, to accommodate for cases where such an Event Hub would already be in place.
Stream Events from Azure services or resources to Event Hub: Using the Diagnostic setting, you can configure each Azure resource to stream certain events to an event hub: [Azure steps to stream logs to an event hub.](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/howto-stream-logs-to-event-hub?tabs=splunk#stream-logs-to-an-event-hub)
Verifying Log Data in Bronto: Once the relevant data is generated in Azure and streamed to Event Hub, shortly log events will appear in the Bronto UI. These logs will be displayed in the appropriate datasets which will be automatically created at ingestion time.
### Resources
For Terraform users, Bronto offers a module that simplifies the setup of the forwarding Function App and its associated Event Hub resources. You can access the module source at [this URL](https://releases.bronto.io/integrations/azure/terraform/1.0.1/brontoForwarder.zip).
Below is an example of how to use the Terraform module for Bronto log forwarding. This example assumes that a Resource Group, Event Hub, and all necessary resources for deploying the Bronto Function App will be created. Ensure that you replace `` with your Bronto account region (EU, US).
```javascript theme={"dark"}
module "forwarder" {
source = "https://releases.bronto.io/integrations/azure/terraform/latest/brontoForwarder.zip"
location = "canadacentral"
resource_group = {
create = true
name = "brontoforwarder"
}
eventhub = {
create = true
name = "brontoforwarder"
namespace = {
name = "brontoforwarder"
sku = "Basic"
}
retention_days = 1
}
forwarder = {
name = "brontoforwarder"
service_plan_type = "Y1"
storage_account = {
name = "brontoforwarder"
replication_type = "LRS"
tier = "Standard"
}
bronto_config = {
ingestion_endpoint = "https://ingestion..bronto.io"
ingestion_key = data.aws_kms_secrets.secrets.plaintext["bronto_ingestion_key"]
default_collection = "azure"
}
}
}
```
If an Event Hub for receiving log data is already configured in your environment, you can create only the resources related to the forwarding Bronto Function App using a configuration like the one below (not `create = false`):
```javascript theme={"dark"}
module "forwarder" {
source = "https://releases.bronto.io/integrations/azure/terraform/latest/brontoForwarder.zip"
location = "canadacentral"
resource_group = {
create = false
name = "brontoforwarder"
}
eventhub = {
create = false
name = var.eventhub.name
namespace = var.eventhub.namespace
}
forwarder = {
name = "brontoforwarder"
service_plan_type = "Y1"
storage_account = {
name = "brontoforwarder"
replication_type = "LRS"
tier = "Standard"
}
bronto_config = {
ingestion_endpoint = "https://ingestion..bronto.io"
ingestion_key = data.aws_kms_secrets.secrets.plaintext["bronto_ingestion_key"]
default_collection = "azure"
}
}
}
```
For those not using Terraform, the Function App forwarder artifact is available for download at [this URL](https://releases.bronto.io/integrations/azure/forwarders/eventhub/latest/brontoForwarder.zip).
### Streaming from a Log Analytics workspace
If your logs are already collected in an Azure Monitor Log Analytics workspace, you don't need to reconfigure each source's diagnostic settings. Use the workspace's [Data Export](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-data-export) feature to continuously stream selected tables to the same Event Hub the forwarder consumes:
1. Create a Data Export rule on the Log Analytics workspace.
2. Select the tables to export (for example, `AzureActivity` or `SigninLogs`).
3. Set the destination to the Event Hub namespace used by the Bronto forwarder.
From there, the forwarder picks up the events exactly as it does for logs streamed directly via diagnostic settings. This is useful when a source can only write to Log Analytics, or when you already centralize there and want Bronto to receive a copy.
### Troubleshooting
### Ensure and verify log events are being sent to the event hub.
* Navigate to Event Hubs on Azure.
* Search for the event hub created earlier. Here you will see an overview table for this event hub and metrics on messages being received broken down by incoming and and outgoing messages.
* If this is empty please ensure that events are being streamed to the correct event hub.
* If metrics show that data goes in and out of event hub and yet you do not see data in Bronto, please check your ingestion endpoint and region is correct (US, EU) and that your Bronto API key set as environment variables on the Function App are correct.
### Notes on event categorisation
When ingesting log data, Bronto automatically assigns it to a collection and dataset based on the information received with the payload. Azure logs forwarded through the Bronto integration are, by default, assigned to the unknown\_service dataset within the azure collection.
However, the following log types are automatically assigned to more specific collections and datasets:
* Activity Logs
* Function App Logs
* Entra ID Logs
* Network Security Perimeter Logs
If you are forwarding a log type that is not listed above and would like it assigned to a specific collection and dataset, please contact us at [support@bronto.io](mailto:support@bronto.io).
# Azure Container Apps Telemetry
Source: https://docs.bronto.io/integrations/azure-container-apps
Choose the right ingestion path for console logs, system logs, metrics, and traces from Azure Container Apps — a Collector container app or the OTel SDK.
Azure Container Apps emits console and system logs. Instrumented applications can also emit OTLP metrics and traces.
## Recommended method
[**Self-Managed OTel Collector**](./azure-otel#self-managed-opentelemetry-collector) — run the Collector as its own container app and have applications export logs, metrics, and traces to it, or export directly with the [OpenTelemetry SDK](/opentelemetry/overview).
The Container Apps environment's built-in managed OpenTelemetry agent exports only over OTLP/gRPC, which Bronto's ingestion endpoint does not accept — so it can't deliver to Bronto directly. Use a Collector container or direct SDK export instead.
## Alternatives
* [**Azure Event Hub Forwarder**](./azure-client) — for Container Apps platform / diagnostic logs exported through Azure Monitor diagnostic settings.
See [Ingesting Azure Data into Bronto](./azure-overview) for the full service-to-method mapping.
## References
* [Collect and read OpenTelemetry data in Azure Container Apps](https://learn.microsoft.com/en-us/azure/container-apps/opentelemetry-agents)
# Azure Functions Telemetry
Source: https://docs.bronto.io/integrations/azure-functions
Choose the right ingestion path for function execution logs, host logs, metrics, and distributed traces from Azure Functions — the OTel SDK or a Collector.
Azure Functions emits function execution logs (your code's output), host logs, and — when instrumented — distributed traces. The right ingestion path depends on whether you want application telemetry emitted directly from the function or the Function App's platform logs.
## Recommended method
[**OpenTelemetry SDK**](/opentelemetry/overview) — instrument the function and send logs, metrics, and traces to Bronto, either directly or through a [Collector](./azure-otel#self-managed-opentelemetry-collector).
## Alternatives
* [**Azure Monitor OpenTelemetry Distro**](./azure-monitor-otel-distro) — if you already use Application Insights, you can forward the same standard OTLP logs, metrics, and traces to Bronto.
* [**Azure Event Hub Forwarder**](./azure-client) — Function App logs streamed through Azure Monitor diagnostic settings are automatically assigned to a dedicated collection and dataset by the forwarder.
See [Ingesting Azure Data into Bronto](./azure-overview) for the full service-to-method mapping.
## References
* [Use OpenTelemetry with Azure Functions](https://learn.microsoft.com/en-us/azure/azure-functions/opentelemetry-howto)
# Azure Monitor OpenTelemetry Distro
Source: https://docs.bronto.io/integrations/azure-monitor-otel-distro
Forward logs, metrics, and traces to Bronto with Microsoft's Azure Monitor OpenTelemetry Distro when you already use Application Insights.
The [Azure Monitor OpenTelemetry Distro](https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-enable) is Microsoft's distribution of the OpenTelemetry SDK for .NET, Java, Node.js, and Python. It bundles auto-instrumentation and is a convenient way to instrument applications on Azure compute platforms such as App Service, Functions, AKS, and VMs.
The Distro is built around the Azure Monitor exporter, so it always sends telemetry to Azure Monitor / Application Insights. Because it is built on the standard OpenTelemetry SDK, you can add an OTLP exporter to forward the same logs, metrics, and traces to Bronto as well.
This is a good fit if you already use Application Insights and want the same data in Bronto. If you only need data in Bronto, a [self-managed OpenTelemetry Collector](./azure-otel#self-managed-opentelemetry-collector) or the vendor-neutral [OpenTelemetry SDK](/opentelemetry/overview) sends directly to Bronto without also routing through Azure Monitor.
## How it compares to standard OpenTelemetry
The Distro is not a separate agent — it is the upstream OpenTelemetry SDK plus Microsoft defaults: bundled auto-instrumentation, automatic Azure resource attributes, an Application Insights-aware sampler, and an always-on Azure Monitor exporter. Everything it emits is standard OpenTelemetry data, so anything you can capture with the Distro you can also capture with the plain SDK or a [Collector](./azure-otel#self-managed-opentelemetry-collector).
Two things matter when forwarding to Bronto:
* **The Azure Monitor leg can't be removed.** The Distro is built around the Azure Monitor exporter, so it always ships to Application Insights; adding an OTLP exporter sends the *same* telemetry to Bronto as well, so you pay on both sides. If you only want Bronto, use a Collector or the plain SDK.
* **Some features are Azure-only.** Live Metrics, Statsbeat, and the Profiler are proprietary to Azure Monitor and have no OTLP equivalent, so they are not forwarded to Bronto. Standard OTLP logs, metrics, and traces are.
## Adding Bronto as a destination
Add an OTLP exporter pointing at Bronto. The simplest approach is the standard OpenTelemetry environment variables, which the Distro respects for its OTLP exporter:
```bash theme={"dark"}
OTEL_EXPORTER_OTLP_ENDPOINT=https://ingestion..bronto.io
OTEL_EXPORTER_OTLP_HEADERS=x-bronto-api-key=
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
```
Replace `` with `eu` or `us` and `` with your Bronto API key. See the [Bronto ingestion endpoints](./azure-otel#bronto-ingestion-endpoints) for the full endpoint list.
Exponential histograms are not supported. For Sum, Summary, and Histogram metrics, the Metric Explorer provides [per-second rate functions](/metrics/explore-metrics#aggregation-functions).
You can also add the OTLP exporter in code (for example, an additional span processor in Node.js or `AddOtlpExporter()` in .NET); see Microsoft's [OpenTelemetry configuration guide](https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-configuration) for per-language examples.
Microsoft does not officially support the OTLP exporter or third-party backends downstream of the Azure Monitor Distro.
## Sending to both Azure Monitor and Bronto with a Collector
If your goal is to land data in **both** Application Insights and Bronto, a standard OpenTelemetry Collector can fan out to both without the Distro — and it stays fully supported upstream. Point your applications' OTLP export at the Collector and configure two exporters: the contrib [`azuremonitor`](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/azuremonitorexporter) exporter for Application Insights and `otlphttp` for Bronto.
```yaml theme={"dark"}
receivers:
otlp:
protocols:
http:
endpoint: 0.0.0.0:4318
processors:
batch:
resourcedetection/azure:
detectors: [env, azure] # use [env, aks] on AKS; adds Azure resource attributes
exporters:
azuremonitor:
connection_string: "${APPLICATIONINSIGHTS_CONNECTION_STRING}"
otlphttp/bronto:
logs_endpoint: "https://ingestion..bronto.io/v1/logs"
metrics_endpoint: "https://ingestion..bronto.io/v1/metrics"
traces_endpoint: "https://ingestion..bronto.io/v1/traces"
compression: gzip
headers:
x-bronto-api-key:
service:
pipelines:
traces:
receivers: [otlp]
processors: [resourcedetection/azure, batch]
exporters: [azuremonitor, otlphttp/bronto]
logs:
receivers: [otlp]
processors: [resourcedetection/azure, batch]
exporters: [azuremonitor, otlphttp/bronto]
metrics:
receivers: [otlp]
processors: [resourcedetection/azure, batch]
exporters: [azuremonitor, otlphttp/bronto]
```
This keeps your applications on vendor-neutral OTLP and moves the dual-destination routing into the Collector, which also adds batching, compression, and retries. The `resourcedetection` processor adds the same Azure resource attributes (VM, App Service, or AKS metadata) that the Distro would populate automatically.
## Resource identity and log routing in Bronto
Set the `service.name` and `service.namespace` resource attributes to identify the source across all three signals. For **logs only**, Bronto also maps them to the dataset and collection — see [Data Organization](/Search-and-Visualize/Partitions). Metrics and traces are not stored in datasets or collections; they appear in the Metric Explorer and Explore Traces. These are the same resource attributes the Distro already uses for Application Insights, so no Bronto-specific attributes are needed beyond the OTLP exporter.
***
For assistance or questions, contact [support@bronto.io](mailto:support@bronto.io).
# OpenTelemetry on Azure
Source: https://docs.bronto.io/integrations/azure-otel
Send application logs, metrics, and traces from Azure to Bronto using a self-managed OpenTelemetry Collector or the OpenTelemetry SDK.
Bronto ingests OpenTelemetry **logs, metrics, and traces** over OTLP/HTTP. On Azure, the recommended path is a self-managed OpenTelemetry Collector, which sends data straight to Bronto with full control over routing and processing.
Exponential histograms are not supported. For Sum, Summary, and Histogram metrics, the Metric Explorer provides [per-second rate functions](/metrics/explore-metrics#aggregation-functions).
## Choosing an Approach
| Approach | Best for | Notes |
| - | - | - |
| [Self-managed OTel Collector](#self-managed-opentelemetry-collector) **(recommended)** | AKS, VMs, Container Instances, Container Apps | Sends logs, metrics, and traces directly to Bronto with full control over processing, routing, and fan-out. |
| [OpenTelemetry SDK](/opentelemetry/overview) | Any runtime (App Service, Functions, etc.) | The vendor-neutral OpenTelemetry SDK and auto-instrumentation, exporting OTLP directly to Bronto. |
| [Azure Monitor OpenTelemetry Distro](./azure-monitor-otel-distro) | Teams already using Application Insights | Microsoft's SDK distro — a convenient option if you already run Application Insights and want to forward the same data to Bronto. See the [dedicated page](./azure-monitor-otel-distro). |
***
## Bronto Ingestion Endpoints
| Signal | EU Region | US Region |
| - | - | - |
| Logs | `https://ingestion.eu.bronto.io/v1/logs` | `https://ingestion.us.bronto.io/v1/logs` |
| Metrics | `https://ingestion.eu.bronto.io/v1/metrics` | `https://ingestion.us.bronto.io/v1/metrics` |
| Traces | `https://ingestion.eu.bronto.io/v1/traces` | `https://ingestion.us.bronto.io/v1/traces` |
The `/v1/logs`, `/v1/metrics`, and `/v1/traces` endpoints accept **OTLP protobuf over HTTP only**. Exponential histograms are not supported.
All requests require the header:
```
x-bronto-api-key:
```
See [API Keys](/Account-Management/API-Keys) for how to generate a key.
***
## Self-Managed OpenTelemetry Collector
Running your own OpenTelemetry Collector is the recommended approach: it sends logs, metrics, and traces straight to Bronto, without routing your data through any other vendor, and gives you:
* **Full configuration control** — custom processors, attribute transformation, or sampling rules
* **Fan-out** — forwarding the same telemetry to multiple backends simultaneously
* **Existing OTel infrastructure** — you already operate a collector fleet and want to add Bronto as an exporter
* **Advanced log routing** — sending logs from different types or services to different Bronto datasets or collections
Application logs, metrics, and traces can be sent directly to Bronto's ingestion endpoints, but routing through a Collector is strongly recommended. The Collector handles retries, batching, and compression.
### Supported sources
A self-managed Collector can run anywhere you control compute, and supports any source that has an OpenTelemetry receiver:
| Service / Source | Data types |
| - | - |
| Azure Virtual Machines / VM Scale Sets | Application logs, metrics, and traces |
| Azure Kubernetes Service (AKS) | Application logs, metrics, and traces (DaemonSet or Deployment) |
| Azure Container Apps | Application logs, metrics, and traces (Collector container) |
| Azure Container Instances (ACI) | Application logs, metrics, and traces (sidecar container) |
| Any Azure workload reachable from the Collector | Logs, metrics, and traces via OTLP and other [OTel receivers](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver) |
The Collector forwards only what it receives — deploying it does not automatically collect your logs. If you aren't seeing all the logs you expect:
* **Application logs, metrics, and traces** require instrumenting your app with the [OpenTelemetry SDK](/opentelemetry/overview), or tailing its log files with the `filelog` receiver.
* **Azure platform and diagnostic logs** (resource logs, activity logs) are **not** collected by the Collector — they are exported through Azure Monitor diagnostic settings via the [Event Hub Forwarder](./azure-client).
See [Ingesting Azure Data into Bronto](./azure-overview) for the full per-service source-to-method mapping, and the per-service pages — [AKS](./azure-aks), [Container Apps](./azure-container-apps), [Container Instances](./azure-aci), [App Service](./azure-app-service), [Functions](./azure-functions), [Virtual Machines](./azure-vms) — for what each service emits and how.
### Collector configuration
The core Bronto exporter configuration is the same regardless of how you deploy the collector on Azure. For full installation instructions and parameter reference, see the [OpenTelemetry Collector guide](/agent-setup/open-telemetry).
The minimal configuration exports logs, metrics, and traces to Bronto:
```yaml theme={"dark"}
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
exporters:
otlphttp/bronto:
logs_endpoint: "https://ingestion..bronto.io/v1/logs"
metrics_endpoint: "https://ingestion..bronto.io/v1/metrics"
traces_endpoint: "https://ingestion..bronto.io/v1/traces"
compression: gzip
headers:
x-bronto-api-key:
service:
pipelines:
logs:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto]
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/bronto]
```
Replace `` with `eu` or `us` and `` with your Bronto API key.
### Deployment options on Azure
#### Azure Kubernetes Service (AKS)
Deploy as a DaemonSet (one collector per node) for node-level log collection, or as a Deployment behind a ClusterIP service for centralised collection. The simplest path is the [OpenTelemetry Helm chart](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-collector):
```bash theme={"dark"}
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install otel-collector open-telemetry/opentelemetry-collector \
--values values.yaml
```
Add the `k8sattributes` processor to enrich logs, metrics, and traces with pod, namespace, and node metadata. See the [OpenTelemetry Collector guide](/agent-setup/open-telemetry#kubernetes) for a complete `values.yaml` example.
#### Azure Virtual Machines / VM Scale Sets
Install the OpenTelemetry Collector directly on your VMs following the [official installation guide](https://opentelemetry.io/docs/collector/installation/). Place your config at `/etc/otel/config.yaml` and run the collector as a systemd service. For VM Scale Sets, bake the collector into your image or install it via a custom-script extension or cloud-init so every instance starts the collector on boot.
#### Azure Container Apps
Run the OpenTelemetry Collector as its own container app and have your other apps export OTLP to it; the Collector forwards logs, metrics, and traces to Bronto over OTLP/HTTP. Alternatively, instrument each app with the [OpenTelemetry SDK](/opentelemetry/overview) to export to Bronto directly.
The Container Apps environment's built-in managed OpenTelemetry agent exports only over OTLP/gRPC, which Bronto's ingestion endpoint does not accept — so it can't deliver to Bronto directly. Use a Collector container or direct SDK export instead.
#### Azure Container Instances (ACI)
Run the collector as a sidecar container within the same container group as your application. Both containers share the group's network namespace, so the usual defaults are `localhost:4317` for OTLP/gRPC and `localhost:4318` for OTLP/HTTP. Replace them when your receiver uses different port, protocol, or TLS settings. Use the standard `otel/opentelemetry-collector-contrib` image and provide your config via a mounted Azure Files share or a secret volume.
### Collecting from Windows hosts
Windows workloads are common on Azure — VMs and VM Scale Sets, App Service on Windows plans, and Windows node pools on AKS. Windows hosts produce two distinct kinds of logs: **Windows Event Log** entries (collected with the `windowseventlog` receiver) and **file-based logs** such as IIS and SQL Server (collected with the `filelog` receiver). The same Collector you run for Linux workloads — including as an AKS DaemonSet on Windows nodes — can collect both.
See [Collecting Windows OS Logs and Metrics](./azure-windows-logs) for the receiver configuration, the channels worth collecting, XPath filtering for noisy channels, Windows `filelog` gotchas (encoding, multi-line stack traces), and installing the Collector as a Windows service.
***
## Azure Monitor OpenTelemetry Distro
If you already use Microsoft's [Azure Monitor OpenTelemetry Distro](./azure-monitor-otel-distro) with Application Insights, you can also forward the same logs, metrics, and traces to Bronto by adding an OTLP exporter. See the [dedicated page](./azure-monitor-otel-distro) for details.
***
## Log Data Organization
OpenTelemetry resource attributes provide shared identity across logs, metrics, and traces. For **logs only**, Bronto maps `service.name` to a **Dataset** and `service.namespace` to a **Collection**. Metrics and traces are not stored in datasets or collections; view them in the [Metric Explorer](/metrics/explore-metrics) and [Explore Traces](/tracing/explore-traces).
Set these as resource attributes in your SDK or collector config:
```yaml theme={"dark"}
processors:
resource:
attributes:
- key: service.name
value:
action: upsert
- key: service.namespace
value:
action: upsert
```
You can also override **log routing** on a logs exporter using HTTP headers, which is useful when one collector ships logs to multiple datasets:
| Header | Description |
| - | - |
| `x-bronto-dataset` | Overrides `service.name` for the log dataset |
| `x-bronto-collection` | Overrides `service.namespace` for the log collection |
| `x-bronto-tags` | Comma-separated tags to attach to the log dataset |
```yaml theme={"dark"}
exporters:
otlphttp/brontologs:
logs_endpoint: https://ingestion..bronto.io/v1/logs
headers:
x-bronto-api-key:
x-bronto-dataset:
x-bronto-collection:
x-bronto-tags: env=prod,team=platform
```
For Kubernetes logs, set `x-bronto-collection` to your cluster name (e.g. `cluster1-prod-eu-west-1`) to identify the source cluster in Bronto.
***
For assistance or questions, contact [support@bronto.io](mailto:support@bronto.io).
# Ingesting Azure Data into Bronto
Source: https://docs.bronto.io/integrations/azure-overview
An overview of the available methods for sending Azure log and trace data to Bronto, with guidance on choosing the right approach.
## Overview
Bronto supports several methods for ingesting data from Azure environments. The right choice depends on where your telemetry originates, your infrastructure preferences, and cost constraints. Bronto ingests OpenTelemetry **logs, metrics, and traces**.
Broadly, Azure telemetry falls into two categories:
* **Platform, diagnostic, and activity logs** — emitted by Azure services through diagnostic settings. These are streamed to Bronto via the [Azure Event Hub Forwarder](./azure-client).
* **Application logs, metrics, and traces** — emitted by your own workloads. Send these to Bronto using [OpenTelemetry on Azure](./azure-otel).
***
## Service-to-Method Mapping
Different Azure services suit different ingestion methods. The recommended method is the simplest path that gets the data into Bronto; alternatives may be preferable depending on your existing infrastructure or cost constraints. Each service name in the table below links to a per-source landing page with a short summary of what the service emits and the configuration entry points for that data.
Where the OpenTelemetry SDK supports your runtime, prefer OTel-based instrumentation — it sends logs, metrics, and traces through one Collector and gives you consistent resource identity. [OpenTelemetry on Azure](./azure-otel) covers AKS, Container Apps, Container Instances, VMs, App Service, and Functions.
| Azure Service | Recommended Method | Alternatives |
| - | - | - |
| [Azure Virtual Machines / VM Scale Sets](./azure-vms) | [OTel Collector](./azure-otel#self-managed-opentelemetry-collector) | [Azure Monitor Distro](./azure-monitor-otel-distro), [Event Hub Forwarder](./azure-client) (diagnostic logs) |
| [Azure Kubernetes Service (AKS)](./azure-aks) | [OTel Collector](./azure-otel#self-managed-opentelemetry-collector) | [Azure Monitor Distro](./azure-monitor-otel-distro), [Event Hub Forwarder](./azure-client) (control plane / diagnostic logs) |
| [Azure Container Apps](./azure-container-apps) | [OTel Collector](./azure-otel#self-managed-opentelemetry-collector) (Collector container) / [OTel SDK](/opentelemetry/overview) | [Event Hub Forwarder](./azure-client) (diagnostic logs) |
| [Azure Container Instances (ACI)](./azure-aci) | [OTel Collector](./azure-otel#self-managed-opentelemetry-collector) (sidecar) | — |
| [Azure App Service](./azure-app-service) | [OTel SDK](/opentelemetry/overview) | [Azure Monitor Distro](./azure-monitor-otel-distro), [Event Hub Forwarder](./azure-client) (diagnostic logs) |
| [Azure Functions](./azure-functions) | [OTel SDK](/opentelemetry/overview) | [Azure Monitor Distro](./azure-monitor-otel-distro), [Event Hub Forwarder](./azure-client) (Function App logs) |
| Microsoft Foundry (agent / LLM telemetry) | [OTel SDK](/ai-features/microsoft-foundry) | [OTel Collector](./azure-otel#self-managed-opentelemetry-collector) |
| Azure SQL Database | [Event Hub Forwarder](./azure-client) (diagnostic / audit logs) | — |
| Azure Monitor / Activity Logs | [Event Hub Forwarder](./azure-client) | — |
| Microsoft Entra ID (sign-in / audit logs) | [Event Hub Forwarder](./azure-client) | — |
| Network Security Perimeter Logs | [Event Hub Forwarder](./azure-client) | — |
***
## Ingestion Methods
Bronto supports the following Azure ingestion methods:
* [Azure Event Hub Forwarder](./azure-client) — A Bronto Function App subscribes to an Event Hub and forwards platform, diagnostic, and activity logs streamed to it via diagnostic settings. It can also receive logs re-exported from a Log Analytics workspace via [Data Export](./azure-client#streaming-from-a-log-analytics-workspace).
* [OpenTelemetry on Azure](./azure-otel) — Application logs, metrics, and traces via a self-managed OpenTelemetry Collector or the OpenTelemetry SDK.
* [Azure Monitor OpenTelemetry Distro](./azure-monitor-otel-distro) — Microsoft's SDK distro; a convenient option for teams already using Application Insights who want to forward the same data to Bronto.
* [Microsoft Foundry observability](/ai-features/microsoft-foundry) — Logs, metrics, and traces from Foundry apps and agents, including model calls, token usage, tool invocations, and multi-agent hierarchies.
***
For assistance or questions, contact [support@bronto.io](mailto:support@bronto.io).
# Azure Virtual Machines Telemetry
Source: https://docs.bronto.io/integrations/azure-vms
Choose the right ingestion path for system logs, application logs, host metrics, and distributed traces from Azure Virtual Machines and VM Scale Sets.
Azure Virtual Machines and VM Scale Sets emit OS / system logs and application log files, and — when your applications are instrumented — metrics and distributed traces. Because you control the compute, a collector can run directly on the instance and also scrape host metrics.
## Recommended method
[**Self-Managed OTel Collector**](./azure-otel#self-managed-opentelemetry-collector) — install the Collector as a systemd service or Windows service to collect host telemetry and accept application logs, metrics, and traces over OTLP. For VM Scale Sets, bake it into the image or install it through cloud-init or a custom-script extension.
For **host metrics** — CPU, memory, disk, filesystem, and network — add the `hostmetrics` receiver; see [Host metrics with OpenTelemetry](/integrations/host-metrics).
On **Windows** VMs, collect Windows Event Log channels (Application, System, Security) with the `windowseventlog` receiver and file-based logs such as IIS access logs with the `filelog` receiver. Windows performance counters, IIS, and SQL Server metrics have dedicated receivers — see [Collecting Windows OS Logs and Metrics](./azure-windows-logs).
## Alternatives
* [**Azure Event Hub Forwarder**](./azure-client) — for VM platform / diagnostic logs exported through Azure Monitor diagnostic settings.
See [Ingesting Azure Data into Bronto](./azure-overview) for the full service-to-method mapping.
## References
* [Monitor virtual machines with Azure Monitor](https://learn.microsoft.com/en-us/azure/azure-monitor/vm/monitor-virtual-machine)
# Collecting Windows OS Logs and Metrics
Source: https://docs.bronto.io/integrations/azure-windows-logs
Collect Windows Event Logs, IIS and SQL Server log files, and Windows performance-counter metrics with the OpenTelemetry Collector and ship them to Bronto.
Windows hosts produce two distinct kinds of logs, and each needs a different OpenTelemetry receiver:
* **Windows Event Log** — platform and service diagnostics written to the event log (visible in **Event Viewer**), collected with the `windowseventlog` receiver.
* **File-based logs** — IIS access logs, SQL Server error logs, and custom application files on disk, collected with the `filelog` receiver.
The same Collector can also send **metrics** — see [Metrics](#metrics) for Windows performance counters and the dedicated IIS and SQL Server receivers.
The `otel/opentelemetry-collector-contrib` image and the Windows Collector binary include both receivers, so the same Collector you run for Linux workloads can collect Windows logs. Once the data reaches Bronto over OTLP it is ingested the same way regardless of the source OS.
This applies to any Windows host you run a Collector on. On Azure that includes **VMs and VM Scale Sets**, **App Service on Windows plans**, and **Windows node pools on AKS** (where the Collector runs as a DaemonSet on the Windows nodes).
These examples show only the receivers and how to wire them into a logs pipeline. They assume you already run an OpenTelemetry Collector with a Bronto exporter configured — see [OpenTelemetry on Azure](./azure-otel) or the [OpenTelemetry Collector guide](/agent-setup/open-telemetry) for the base setup, endpoints, and `service.name` / `service.namespace` routing.
The `windowseventlog` receiver is Windows-only — it must run on a Windows host or in a Windows container. The `filelog` receiver works on any OS.
## Windows Event Log
Most Windows platform and service diagnostics are written to the Windows Event Log, **not** to files on disk. Collect these with the [`windowseventlog` receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/windowseventlogreceiver), one receiver per channel:
```yaml theme={"dark"}
receivers:
windowseventlog/application:
channel: Application
windowseventlog/system:
channel: System
windowseventlog/security:
channel: Security
```
`channel` accepts any event channel name, so you can scope collection to exactly the sources you care about. Channels commonly worth collecting on Windows hosts:
| Channel | Captures |
| - | - |
| `Application` | Events from installed applications and services |
| `System` | Events from Windows system components and drivers |
| `Security` | Audit events — logon, privilege use, object access (high volume) |
| `Setup` | Application install and servicing events |
| `ForwardedEvents` | Events collected from other hosts via Windows Event Forwarding (WEF) |
| `Microsoft-Windows-PowerShell/Operational` | PowerShell script-block and pipeline execution |
| `Microsoft-Windows-Sysmon/Operational` | Sysmon process / network / file telemetry (if Sysmon is installed) |
| `Microsoft-Windows-Windows Defender/Operational` | Microsoft Defender detections and scan results |
On domain controllers, also collect the `Directory Service` and `DNS Server` channels alongside `Security` for Active Directory audit events.
### Filtering noisy channels
High-volume channels — `Security` in particular — can dominate ingestion. Use the receiver's `query` option to collect only the events you need via an XPath expression, keeping volume and cost down before data leaves the host. Filter `Security` by Event ID:
```yaml theme={"dark"}
receivers:
windowseventlog/security:
channel: Security
query: |