Skip to main content

Observability Integrations

Observability tools provide real-time system insights, metric analysis, and automated troubleshooting capabilities. 

Integrated observability tools can be used by an agent team with the Observability Agent skill. 

Multi-integration configuration

You can configure multiple instances of the same type of observability integration.

To add an additional integration, click + Add Instance on the integration configuration page.

The following observability integrations are available:

AppDynamics

The Biggy AppDynamics integration is used for full-stack/APM monitoring.

To configure the Biggy AppDynamics integration, populate the following fields:

Field

Description

AppD Controller URL

Enter the controller URL for your AppDynamics instance. (For example, https://xyz.saas.appdynamics.com)

Client ID

Your AppDynamics Client ID is a combination of the client name and account name in this format: [CLIENT_NAME]@[ACCT_NAME]

Client Secret

Auto-generated AppDynamics client secret.

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. 

Deployment Type

Select whether your AppDynamics integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

Agent Notes

Add notes to help Biggy understand your AppDynamics environment.

We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. 

For example, if your logs contain a specific field that is used to identify the type of application or service, provide that information here.

AWS CloudWatch Logs

The Biggy AWS CloudWatch Logs integration lets Biggy discover log groups and run CloudWatch Logs insights queries in your AWS account.

AWS CloudWatch Logs credentials are account-scoped, so add one instance per AWS account you want Biggy to search. We recommend connecting through an IAM role with short-lived credentials, so there is nothing to store or rotate. Access keys remain available as a legacy option.

The integration is read-only. Biggy cannot create, modify, or delete anything in your AWS account.

Query-based access

Biggy reads your logs only on demand with CloudWatch Logs Insights queries and bounded event reads. Nothing is streamed, exported, or stored in Biggy, and subscription filters or Firehose deliveries are never created. Every query scans data in your account, so Biggy narrows by log group and time window before it reads anything.

Required permissions

Grant the IAM role the following read-only CloudWatch Logs actions:

  • logs:DescribeLogGroups

  • logs:StartQuery

  • logs:GetQueryResults

  • logs:StopQuery

  • logs:FilterLogEvents

Grant logs:DescribeLogGroups and logs:StopQuery on "Resource": "*". AWS does not support resource-level permissions for either action, so an ARN-scoped grant denies them and Biggy can neither list log groups nor stop a long-running query. You can narrow logs:StartQuery, logs:GetQueryResults, and logs:FilterLogEvents to specific log group ARNs if you prefer IAM to bound what Biggy can search.

Configure the AWS CloudWatch Logs integration

To configure the integration with the recommended IAM Role method:

  1. In the AWS Cloudwatch Logs web app integration page, go to the Connections section and copy the External ID.

  2. In the AWS account you want to connect, open IAM > Roles > Create role and choose Custom trust policy. The trust policy names the Biggy AWS account as the trusted principal, pins the exact Biggy role that may assume yours, and requires the External ID.

    IAM Role method

    The IAM Role method is available only when your Biggy deployment publishes an AWS principal for your account to trust. If the method is unavailable on your deployment, use the Access Keys method, or contact BigPanda support.

  3. Attach an inline policy to the role that grants the five read-only CloudWatch Logs actions Biggy calls. This policy cannot write, delete, or reconfigure anything in your account:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BiggyCloudWatchLogsRead",
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogGroups",
        "logs:StartQuery",
        "logs:GetQueryResults",
        "logs:StopQuery",
        "logs:FilterLogEvents"
      ],
      "Resource": "*"
    }
  ]

    Narrowing the scope

    You can narrow logs:StartQuery, logs:GetQueryResults, and logs:FilterLogEvents to specific log group ARNs if you prefer IAM to bound what Biggy can search. 

    Keep logs:DescribeLogGroups and logs:StopQuery on "Resource": "*" in a second statement. AWS does not support resource-level permissions for either action, so an ARN-scoped grant denies them, and Biggy can neither list groups nor stop a long-running query. The optional log group prefix allowlist is a Biggy-side convenience on top of IAM, never a substitute for it.

The following fields in the web app must be populated regardless of the selected authentication method:

Field

Description

Instance Name

A human-readable name to identify this instance in the list. (For example, Production AWS CloudWatch Logs)

Routing Instructions (Optional)

Describe what this instance covers so Biggy can route queries to it. (For example, EU production accounts) Routing instructions are recommended, and required for multiple instances.

Agent Notes (Optional)

Add notes to help Biggy understand your CloudWatch Logs environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which AWS account this is, which log groups belong to which applications, naming conventions, and which fields your logs use for request IDs or error codes.

Authentication Method

Select how Biggy authenticates with AWS. 

IAM Role (recommended) - Biggy assumes a role in your account through AWS STS, using its published principal and the External ID generated for this instance. Credentials are short-lived and refreshed automatically, with nothing long-lived to rotate. 

Access Keys - a legacy option that authenticates with the access keys of a read-only IAM user.

Role ARN

This option only appears if you selected IAM Role as the authentication method.

The ARN of the IAM role in your account whose trust policy names the Biggy principal and the External ID. (For example, arn:aws:iam::<your_account_id>:role/BiggyCloudWatchLogs) Required for the IAM Role method.

External ID

This option only appears if you selected IAM Role as the authentication method.

Auto-generated by Biggy for this instance. Add it to the role trust policy's sts:ExternalId condition. Click Regenerate to issue a new External ID. If you do, update the trust policy to match.

Access Key ID

This option only appears if you selected Access Keys as the authentication method.

Enter the access key ID of the read-only AWS IAM user account.

Secret Access Key

This option only appears if you selected Access Keys as the authentication method.

Enter the secret access key of the read-only AWS IAM user account.

Default AWS Region

The region Biggy queries when a question does not name one, and the region Verify Connection probes. GovCloud regions are not available with the IAM Role method yet.

Connectivity

After entering the authentication details and default region, click Verify Connection to confirm that the connection to AWS CloudWatch Logs is established.

Additional regions (Optional)

Regions Biggy may also query when a question or a discovered log group ARN points there. The default region is always included.

Log group prefix allowlist (Optional)

Enter one log group prefix per line. When set, Biggy only lists and queries log groups whose names start with one of these prefixes. Leave empty to let the IAM policy alone decide what Biggy can see. (For example, /aws/lambda/)

AWS Health

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy AWS Health integration monitors AWS events that affect your account. This includes service issues, scheduled changes, and account notifications, and the specific resources each event affects. The integration is read-only, so Biggy cannot create, modify, or acknowledge anything in your AWS account.

The AWS Health API is account-scoped, so add one instance per AWS account you want Biggy to monitor. Each instance connects with the access keys of a read-only IAM user created in that account.

A support plan with Health API access is required

The Health API is the account-specific event feed behind the AWS Health Dashboard, and is only available for accounts on a support plan that includes it.

Required permissions

Required permissions 

Grant the read-only IAM user the following AWS Health actions:

  • health:DescribeEvents 

  • health:DescribeEventDetails 

  • health:DescribeAffectedEntities 

  • health:DescribeEventTypes 

Grant all four actions on "Resource": "*". AWS does not support resource-level permissions for the Health API.

Configure the AWS Health integration

To configure the AWS Health integration:

  1. In the AWS account you want to connect, open IAM > Users > Create user. Grant programmatic access only, and leave console access switched off.

  2. Attach an inline policy to the user that grants the four read-only Health actions Biggy calls. This policy cannot write, mutate, or acknowledge anything in the account:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BiggyAwsHealthRead",
      "Effect": "Allow",
      "Action": [
        "health:DescribeEvents",
        "health:DescribeEventDetails",
        "health:DescribeAffectedEntities",
        "health:DescribeEventTypes"
      ],
      "Resource": "*"
    }
  ]
}

    Why the resource is *

    AWS does not support resource-level permissions for the Health API. The health:Describe* actions accept only "Resource": "*". Narrowing the policy to specific ARNs makes every call fail rather than scoping it. With the * permission applied, the actions are still read-only, and the account boundary is the scope.

  3. On the user's Security credentials tab, create an access key for a third-party service. AWS displays the secret access key only once, so copy both the Access Key ID and the secret access key before you leave the page.

  4. In the web app AWS Health integration page, populate the fields described below, then click Verify Connection to test the connection.

Rotating keys

Access keys do not rotate on their own. When you rotate them in AWS, edit this instance with the new pair and click Verify Connection again. Biggy holds no cached copy of the old credentials, so reads start failing as soon as you deactivate the old key.

Populate the following fields in the web app to set up the integration:

Field

Description

Instance Name

A human-readable name to identify this instance in the list. (For example, US East Production)

Access Key ID

The Access Key ID of the read-only IAM user you created for Biggy.

Secret Access Key

The secret access key that pairs with the Access Key ID. Biggy encrypts both values at rest and masks them in the form. An administrator editing the instance can reveal them.

Connectivity

After entering the Access Key ID and Secret Access Key, click Verify Connection to confirm that the connection to AWS Health is established.

Routing Instructions

Describe when this AWS Health instance should be used. (For example, This is the US East production account. Use for any queries about US-based production services.) 

Routing instructions are only necessary when multiple instances of AWS Health are configured.

AWS Health Agent Notes

Add notes to help Biggy understand your AWS Health environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. 

For example, if your alerts contain a specific field that is used to identify the type of application or service, provide that information here. Click Generate with AI to draft these notes automatically.

Azure Data Explorer

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy Azure Data Explorer integration lets Biggy run read-only Kusto Query Language (KQL) queries on your databases.

Biggy connects to your Azure Data Explorer (ADX) cluster using a Microsoft Entra app registration and queries only the databases you list. Queries against any other database are rejected before they reach the cluster.

The integration is read-only. Biggy cannot create, modify, or delete anything in your cluster. The app is granted only the Database Viewer role, which permits table reads and .show tables / .show table schema. Management and write commands are blocked before they reach the cluster, and every query carries a server-side timeout and row cap.

Required permissions

The Microsoft Entra app registration needs a Directory (tenant) ID, an Application (client) ID, and a client secret. No Microsoft Graph API permissions or admin consent are required.

In Azure Data Explorer, grant the app the Database Viewer role on each database you want Biggy to query. This role grants table reads and the .show tables and .show table schema commands. No Admin, Ingestor, or User role is required.

Configure the Azure Data Explorer integration

To configure the integration:

  1. In Microsoft Entra ID, go to App registrations and select New registration to register an app for Biggy.

  2. Copy the Directory (tenant) ID and Application (client) ID, then create a client secret under Certificates & secrets and copy its value.

  3. In the Azure Data Explorer query editor, grant the app the Viewer role on each database Biggy should query:

    .add database ['<database>'] viewers ('aadapp=<client-id>;<tenant-id>')

    Run this command for every database Biggy should query. 

  4. Copy the cluster URI from the cluster overview page (for example, https://<cluster>.<region>.kusto.windows.net).

  5. Populate the following fields in the web app to set up the integration:

Field

Description

Instance Name

A human-readable name to identify this instance in the list. (For example, Production Azure Data Explorer)

Routing Instructions (Optional)

Describe what this instance covers so Biggy can route queries to it. (For example, EU production accounts) Routing instructions are recommended, and become required once a second instance exists.

Agent Notes (Optional)

Add schema nuances or tips so Biggy can better interact with your Azure Data Explorer instance. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note timestamp columns, naming conventions, and which services map to which tables.

Cluster URL

The cluster query URI from the Azure Data Explorer cluster overview page. (For example, https://<cluster>.<region>.kusto.windows.net)

Azure Cloud

Selects the Microsoft Entra sign-in authority and which cluster hostnames are accepted. Choose Azure (public cloud), or the matching cloud if the cluster is in US Government or China.

Microsoft Entra Tenant ID

The Directory (tenant) ID of the Microsoft Entra tenant that owns the app registration.

Application (client) ID

The Application (client) ID of the app registration you created for Biggy.

Client Secret

The client secret created for the app registration. Biggy encrypts this value at rest and masks it in the form.

Allowed Databases

Enter one database per line, or comma-separated. Biggy can only query the databases listed here. Queries against any other database are rejected before they reach the cluster.

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

On-premises instance

Enable this toggle when the Azure Data Explorer instance is only reachable from inside your network, such as a cluster reachable only over Private Link. Requests then route through a relay client assigned on the Relay Clients page.

Connectivity

After entering the connection details, click Verify Connection to confirm that the connection to Azure Data Explorer is established.

Azure Monitor

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy Azure Monitor integration gives Biggy read-only access to log analytics, including Kusto Query Language (KQL) queries, metrics, resource health, and service health.

Azure Monitor is connected per Azure subscription. Each instance signs in as a Microsoft Entra app registration and is scoped to exactly one subscription, so add one instance per subscription you want Biggy to see.

Everything Biggy calls is read-only. Biggy cannot create, modify, restart, or delete anything in your subscription.

Required permissions

Grant the Microsoft Entra app registration the following built-in read-only roles:

  •  Reader on the subscription: resource list, subscription probe, resource health, and service health.

  •  Monitoring Reader on the subscription: metric definitions and metric data.

  •  Log Analytics Reader on each listed log analytics workspace: KQL queries, including workspace-based application Insights tables.

All three are built-in read-only roles. None of them can change, restart, or delete a resource.

Configure the Azure Monitor integration

To configure the integration:

  1. Register an app for Biggy. In Microsoft Entra ID > App registrations > New registration, create a single-tenant app. No redirect URI is needed. Copy the Directory (tenant) ID and Application (client) ID from the app's Overview page.

  2. Create a client secret. Under Certificates & secrets, select New client secret, pick an expiry that your rotation policy allows, and copy the secret Value immediately, because Azure shows it only once. Note the expiry date: when the secret lapses, Verify Connection reports a credential failure until you paste a new secret.

  3. Assign read-only roles on the subscription. Open the subscription's Access control (IAM) page and select Add role assignment to grant the app the Reader and Monitoring Reader roles. Both are built-in read-only roles, so nothing here can change, restart, or delete a resource. You can also assign the roles with the Azure CLI:

    # Sign in, then assign the two subscription roles to the app registration
az login
APP_ID=<application-client-id>
SUBSCRIPTION_ID=<subscription-id>
az role assignment create --assignee "$APP_ID" --role "Reader" --scope "/subscriptions/$SUBSCRIPTION_ID"
az role assignment create --assignee "$APP_ID" --role "Monitoring Reader" --scope "/subscriptions/$SUBSCRIPTION_ID"

# Optional: for each Log Analytics workspace Biggy should query
WORKSPACE_RESOURCE_ID=<workspace-resource-id>
az role assignment create --assignee "$APP_ID" --role "Log Analytics Reader" --scope "$WORKSPACE_RESOURCE_ID"

  4. (Optional) You can choose to allow log analytics workspaces. For each workspace Biggy can query, grant the app the Log Analytics Reader role on the workspace and on the workspace Overview page, copy its Workspace ID, GUID. Workspace-based Application Insights resources write into a workspace, so their App* tables are covered by the same role. Leave the list empty to connect metrics and health only.

  5. Populate the following fields in the web app:

Field

Description

Instance Name

A human-readable name to identify this instance in the list. (For example, Production Azure Monitor)

Routing Instructions (Optional)

Describe what this instance covers so Biggy can route queries to it. (For example, EU production accounts) Routing instructions are recommended and are required for multiple instances.

Agent Notes (Optional)

Add notes to help Biggy understand your Azure Monitor environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which resource groups or workspaces back which applications, and any custom log conventions.

Microsoft Entra Tenant ID

The Directory (tenant) ID of the Microsoft Entra tenant that owns the app registration.

Application (client) ID

The Application (client) ID of the app registration. This GUID is on the app registration's Overview page.

Subscription ID

The ID of the Azure subscription this instance is scoped to.

Client Secret

The client secret value created for the app registration. Biggy encrypts this value at rest and masks it in the form.

Azure Cloud

Selects the Microsoft Entra, Azure Resource Manager, and Log Analytics endpoints. Leave on Azure (public) unless the subscription lives in a sovereign cloud, such as Azure Government or Azure China.

Log Analytics Workspace IDs (Optional)

Enter one Workspace ID GUID per line, taken from each workspace's Overview page rather than the workspace name. Only listed workspaces can be queried, and the app needs the Log Analytics Reader role on each. Leave empty to enable metrics and health only.

On-premises instance

Enable this toggle when the Azure Monitor instance is only reachable from inside your network, such as a Log Analytics workspace reachable only over Private Link. Requests then route through a relay client assigned on the Relay Clients page. Public Azure endpoints need no relay.

Connectivity

After entering the connection details, click Verify Connection to confirm that the connection to Azure Monitor is established.

Datadog

The Biggy Datadog integration is used for full-stack monitoring.

Beta integration

The Biggy Datadog integration is currently in Beta release status.

In Datadog, ensure the following permissions/scopes have been enabled:

  • apm_api_catalog_read

  • apm_read

  • apm_remote_configuration_read

  • apm_retention_filter_read

  • apm_service_catalog_read

  • apm_service_ingest_read

  • audience_management_read

  • continuous_profiler_pgo_read

  • continuous_profiler_read

  • debugger_read

  • error_tracking_read

  • events_read

  • incident_read

  • logs_read_data

  • logs_read_index_data

  • metrics_read

  • monitors_read

  • reference_tables_read

  • rum_apps_read

  • rum_retention_filters_read

  • rum_session_replay_read

  • synthetics_global_variable_read

  • synthetics_private_location_read

  • synthetics_read

  • timeseries_query

To configure the Datadog integration, populate the following fields:

Field

Description

Datadog Region

The region of your Datadog instance.

If you access Datadog via datadoghq.eu, select EU.

If not, choose your US region. Select from US, US3, or US5.

API Key

Your Datadog API key.

Application Key

Your Datadog application key with required read-only scopes.

Agent Notes

Add notes to help Biggy understand your Datadog environment.

We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. 

For example, if your logs contain a specific field that is used to identify the type of application or service, provide that information here.

Downdetector

Use the Downdetector integration to give Biggy access to crowd-sourced outage signals on popular services.

To configure the Downdetector integration:

  1. In Downdetector, obtain an API token.

  2. In the web app Downdetector integration page, configure the following fields:

    Field

    Description

    Instance Name

    A human-readable name to identify this instance in the list. 

    Agent Notes

    Add notes to help Biggy understand your Downdetector environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results.

    Downdetector API Token

    Enter the API token from Downdetctor, obtained in step 1.

    On-premises Instance

    Enable this toggle when the Downdetector instance is only reachable from inside your network, such as a cluster reachable only over Private Link. Requests then route through a relay client assigned on the Relay Clients page.

  3. In the Connectivity section, click Verify Connection to test the connection before you save.

  4. Click Save Instance. 

Dynatrace

The Biggy Dynatrace integration is used for application performance monitoring.

Ensure the following Dynatrace scopes/permissions have been enabled:

API v1 Scopes 

  • DataExport

  • ReadConfig

  • ExternalSyntheticIntegration

  • ReadSyntheticData

API v2 Scopes 

  • entities.read

  • events.read

  • metrics.read

  • problems.read

  • settings.read

  • logs.read

  • syntheticLocations.read

  • syntheticExecutions.read

To configure the Dynatrace integration, populate the following fields:

Field

Description

Dynatrace URL

The URL of your Dynatrace instance.

API Key

Your Dynatrace API key.

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. 

Deployment Type

Select whether your Dynatrace integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

Agent Notes

Add notes to help Biggy understand your Dynatrace environment.

We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. 

For example, if your logs contain a specific field that is used to identify the type of application or service, provide that information here.

Elasticsearch

The Biggy Elasticsearch integration is used for metrics monitoring. 

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

Populate the following fields to set up the integration:

Field

Description

Authentication Method

Choose how you'd like to authenticate with this integration. The following methods are available:

  • Basic Authentication - authenticate using an Elasticsearch username and password

  • API Key Authentication - authenticate using an Elasticsearch API key

  • Bearer Token Authentication - authenticate using an Elasticsearch bearer token

Elasticsearch Instance URL

Enter the base URL of the inbound Elasticsearch instance. Include the port if applicable. (For example, https://<inbound-ip>:9200)

Credentials

Enter the credentials that allow the integration to authenticate.

If you selected the Basic Authentication method, enter your Elasticsearch username and password.

If you selected API Key Authentication, enter an Elasticsearch API key.

If you selected Bearer Token Authentication, enter an Elasticsearch bearer token.

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. 

Deployment

Select whether your Elasticsearch integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

Elasticsearch Agent Notes

Add notes to help Biggy understand your Elasticsearch environment.

We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results.

For example, if your logs contain a specific field that is used to identify the type of application or service, provide that information here.

Grafana

Use the Biggy Grafana integration for metrics monitoring. Use this integration for action plans, such as the Observability Agent.Observability Agent

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

Populate the following fields to set up the integration:

Field

Description

Authentication Method

Choose how you'd like to authenticate with this integration. The following methods are available:

  • Basic Authentication - authenticate using a Grafana username and password

  • Bearer Token Authentication - authenticate using a Grafana bearer token

Grafana Instance URL

Enter the base URL of the inbound Grafana instance. Include the port if applicable. (For example, https://myinstance.grafana.net).

Credentials

Enter the credentials that allow the integration to authenticate.

If you selected the Basic Authentication method, enter your Grafana username and password.

If you selected Bearer Token Authentication, enter a Grafana bearer token.

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

Deployment Type

Select whether your Grafana integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

Connectivity

After entering the authentication method, instance URL, and credentials, click Verify Connection to ensure that the connection to Grafana is established.

Click Update Data Schema to allow Biggy to retrieve and store relevant schema information for this integration. This helps Biggy understand how your data is structured, allowing for more accurate and efficient information retrieval.

Grafana Agent Notes

Add notes to help Biggy understand your Grafana environment.

We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results.

For example, if your logs contain a specific field that is used to identify the type of application or service, define the purpose and function of that field here.

LogicMonitor

The LogicMonitor integration is used for infrastructure monitoring and observability.

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

To configure the LogicMonitor integration, populate the following fields:

Field

Description

Authentication Method

Choose how you'd like to authenticate with this integration. The following methods are available:

  • LMv1 (Access Key)

  • Bearer token

LogicMonitor URL

URL of your LogicMonitor instance. (for example https://your-company.logicmonitor.com)

Credentials

If you selected LMv1 (Access Key) as your authentication method, enter the Access ID and Access Key of the LogicMonitor account that Biggy should use for API interactions.

If you selected Bearer Token as your authentication method, enter your LogicMonitor Bearer Token. 

Deployment Type

Select whether your LogicMonitor integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

LogicMonitor Agent Notes

Add notes to help Biggy understand your LogicMonitor environment.

We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results.

For example, enter explanations of custom fields and when or how they should be used to handle user queries.

New Relic

The New Relic - Biggy integration is used to retrieve data from application performance monitoring (APM), metrics, logs, and infrastructure telemetry.

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

Required Permissions

To ensure Biggy has the access it needs to perform necessary functions, either the New Relic Read Only role must be granted, or a custom role containing the following permissions:

  • NRQL query execution 

  • Entity read (APM, Infrastructure, Browser, Mobile, Synthetics, Workloads, Dashboards) 

  • Alert policies read 

  • Alert issues and incidents read 

  • Synthetics monitor read 

  • Topology read 

To configure the New Relic integration:

  1. In New Relic, create or choose a dedicated integration user with access to the account that the Biggy should query.

  2. In the New Relic API Keys page, generate a user API key for the user selected in step 1 and copy it.

    API key restrictions

    Do not use License, Browser, Mobile, or retired REST API keys

  3. In New Relic Account Settings, copy the target New Relic account ID. 

  4. Populate the following fields in the web app New Relic integration page:

    Field

    Description

    New Relic API Base URL

    Base URL for your New Relic region. (For example, https://api.newrelic.com for US or https://api.eu.newrelic.com for EU)

    New Relic Account ID

    New Relic account ID copied in step 3.

    New Relic User Key

    User API key copied in step 2.

    Custom Headers (optional)

    Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

    Deployment Type

    Select whether your New Relic integration is Cloud or On-Prem.

    Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

    Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

    New Relic Agent Notes

    Add notes to help Biggy understand your New Relic environment.

    We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results.

    For example, enter explanations of custom fields and when or how they should be used to handle user queries.

OpsRamp

The OpsRamp integration is used for hybrid IT infrastructure monitoring, alerting, and resource management.

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

Required permissions

The following OpsRamp permissions must be enabled to use the integration:

  • Alerts: View, Search

  • Resources: View, Search

  • Metrics: View, Query

  • Incidents/Tickets: View, Search

  • Service Maps: View

  • Topology: View

To configure the integration:

  1. In OpsRamp, go to Setup > Integrations and install a custom integration. Be sure to copy your Key, Secret, and API Endpoint.

  2. Go to Setup > Accounts and copy your Tenant ID.

  3. In the web app, configure the following fields:

    Field

    Description

    OpsRamp API Endpoint

    The API endpoint from your custom integration, copied from the integration setup page in step 1. (for example, https://api.opsramp.com)

    Integration Key

    OpsRamp integration key, copied from the integration setup page in step 1.

    Integration Secret

    OpsRamp integration secret, copied from the integration setup page in step 1.

    Tenant ID

    OpsRamp tenant ID, copied from the OpsRamp Accounts page in step 2.

    Custom Headers

    Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

    Deployment Type

    Select whether your OpsRamp integration is Cloud or On-Prem.

    Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

    Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

    OpsRamp System/Schema Nuances

    Add notes to help Biggy understand your OpsRamp environment.

    We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results.

    For example, enter explanations of custom fields and when or how they should be used to handle user queries.

Prometheus

The Biggy Prometheus integration is used for metrics monitoring. 

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

Configure the following fields to set up the integration:

Field

Description

Prometheus Instance URL

Enter the base URL of the inbound Prometheus instance. Include the port, if applicable.

(For example, https://<prometheus-dns-name>.io or https://<prometheus-ip>:9090).

Username and Password

Add credentials of the Prometheus account that Biggy should use for API interactions.

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. 

Deployment Type

Select whether your Prometheus integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

Connectivity

After entering the instance URL, credentials, and deployment type, click Verify Connection to ensure that the connection to Prometheus is established.

Click Update Data Schema to allow Biggy to retrieve and store relevant schema information for this integration. This helps Biggy understand how your data is structured, allowing for more accurate and efficient information retrieval.

Prometheus Agent Notes

Add notes to help Biggy understand your Prometheus environment.

We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results.

For example, if your logs contain a specific field that is used to identify the type of application or service, define the purpose and function of that field here.

SiteScope

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy OpenText SiteScope integration gives Biggy live monitor, group, and target status from your SiteScope server.

Biggy connects to the SiteScope REST API with a dedicated read-only user and reads the status of the monitor groups you grant it access to. Biggy only reads, so no edit, enable, disable, or run permission is needed.

Requirements

To use the integration, you need:

  • A SiteScope release that exposes the REST API under /SiteScope/api. SOAP-only releases are not supported.

  • A dedicated SiteScope user with a role that grants View permission on the monitor groups Biggy should investigate. No edit, enable, disable, or run permission is needed.

OpenText Operations Bridge (OBM) is a separate product and is not covered by this integration.

Configure the SiteScope integration

To configure the integration:

  1. In SiteScope, open Preferences and select User Management Preferences. Create a dedicated user for Biggy with a role that grants View on the monitor groups Biggy should investigate. 

  2. Populate the following fields in the web app to set up the integration:

Field

Description

Instance Name

A human-readable name to identify this instance in the list. (For example, Production SiteScope)

Routing Instructions (Optional)

Describe what this instance covers so Biggy can route queries to it. (For example, EU production accounts) Routing instructions are recommended, and are required for multiple instances.

Agent Notes (Optional)

Add notes to help Biggy understand your SiteScope environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which groups map to which services or sites, naming conventions, and the monitors that matter most during an incident.

SiteScope URL

Enter the SiteScope server address, including its port. (For example, https://sitescope.example.com:8080) Biggy calls the REST API under /SiteScope/api. Pasting the /SiteScope path also works.

Username

The dedicated read-only user you created in SiteScope for Biggy.

Password

The password for the SiteScope user. Biggy encrypts this value at rest and masks it in the form.

Custom CA Certificate (PEM) (Optional)

If your SiteScope server uses a private or self-signed certificate, paste the CA certificate chain (PEM) so Biggy can verify the server TLS certificate.

System Time Zone

Select the system time zone configured in your SiteScope instance. This ensures dates and times are interpreted correctly.

On-premises instance

Enable this toggle when the SiteScope instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

After entering the connection details, click Verify Connection to confirm that the connection to SiteScope is established.

SolarWinds

The SolarWinds - Biggy integration is used for observability and monitoring.

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

To configure the SolarWinds integration, populate the following fields:

Field

Description

SolarWinds Query Endpoint

Enter a SolarWinds Information Service (SWIS) URL and port. (for example, https://your-solarwinds-instance.com:1774)

Username

Username of the SolarWinds account Biggy should use for API interactions.

Password

Password of the SolarWinds account Biggy should use for API interactions.

Trusted CA Certificate (optional)

If your SolarWinds instance uses a private or self-signed certificate, provide a trusted CA certificate. If not, TLS verification should be disabled.

Deployment Type

Select whether your SolarWinds integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

SolarWinds Agent Notes

Add notes to help Biggy understand your SolarWinds environment.

We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results.

For example, enter explanations of custom fields and when or how they should be used to handle user queries.

Splunk

The Biggy Splunk integration is used for log monitoring. 

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

Configure the following fields to set up the integration:

Field

Description

Authentication Method

Choose how you'd like to authenticate with this integration. The following methods are available:

Basic Authentication - authenticate using a Splunk username and password.

Bearer Token Authentication - authenticate using a Splunk bearer token.

Splunk Instance URL

Enter the Base URL and Port of the inbound Splunk instance.

Note: When configuring Splunk Enterprise (on-prem), you must include port 8089 in the base URL. (For example, https://<inbound-ip>:8089)

Credentials

Enter the credentials that allow the integration to authenticate.

If you selected the Basic Authentication method, enter the Username and Password of the Splunk account that Biggy should use for API interactions.

If you selected the Bearer Token Authentication method, enter a Splunk Bearer Token.

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. 

Deployment Type

Select whether your Splunk integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

Splunk Agent Notes

Add notes to help Biggy understand your Splunk environment.

We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. 

For example, if your logs contain a specific field that is used to identify the type of application or service, provide that information here.

Splunk Observability Cloud

The Biggy Splunk Observability Cloud integration is used for full-stack observability and application performance monitoring (APM).

Connect Splunk Observability Cloud (formerly SignalFx) so Biggy can investigate metrics with SignalFlow analytics, detectors and active alerts, APM services and traces, and infrastructure entities. Distinct from the Splunk integration, which searches logs/events in Splunk Enterprise/Cloud via SPL.

Biggy queries Splunk Observability Cloud when investigating an issue. It does not ingest, copy, or retain Splunk Observability Cloud telemetry in Biggy for long-term storage.

The integration is read-only. Biggy cannot create, modify, or delete Splunk Observability Cloud resources such as detectors, dashboards, access tokens, or notification policies.

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

To configure the Splunk Observability Cloud integration:

  1. In Splunk Observability Cloud, open Settings > Access Tokens.

  2. Create an organization access token.

  3. Select the API authorization scope.

  4. Assign a read-only role that provides access to the telemetry you want Biggy to investigate.

  5. Store the token securely until you enter it in Biggy.

  6. In Splunk Observability Cloud, go to Settings > My Profile > Organizations to find your realm.

  7. In the web app Splunk Observability Cloud configuration page, enter the Realm and Org Access Token.

ThousandEyes

Configure the ThousandEyes integration for network monitoring, application availability, BGP analysis, and endpoint metrics.

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

Required permissions

To ensure Biggy has the access it needs to perform necessary functions, either the ThousandEyes Regular User role must be granted, or a custom role containing the following permissions:

  • API access

  • Internet Insights - Catalog settings

  • View agents in account group

  • View alert rules

  • View alert suppression windows

  • View BGP monitors

  • View connectors and operations

  • View dashboards

  • View endpoint agent data

  • View endpoint agent settings

  • View endpoint tests

  • View labels

  • View tests

ThousandEyes GenAI required

To use the integration, your organization must not have opted out of ThousandEyes GenAI features.

To check your organization's status, log in to the ThousandEyes dashboard and go to Manage > Account Settings > Organization Settings > AI Features.

See the ThousandEyes documentation for more information.

To configure the ThousandEyes integration:

  1. Log in to the ThousandEyes dashboard.

  2. Navigate to Account Settings > Users and Roles > Profile > User API Tokens.

  3. Create a new bearer token and copy it.

  4. In the web app ThousandEyes integration page, populate the following:

Field

Description

ThousandEyes MCP URL (optional override)

Optionally, enter a ThousandEyes MCP URL to use as an override.

ThousandEyes API Bearer Token

ThousandEyes bearer token copied in step 3.

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

Deployment Type

Select whether your ThousandEyes integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

ThousandEyes Agent Notes

Add notes to help Biggy understand your ThousandEyes environment.

We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. 

For example, if your logs contain a specific field that is used to identify the type of application or service, provide that information here.

Wiz

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy Wiz integration brings cloud security issues, affected cloud resources, and Common Vulnerabilities and Exposures (CVE) findings into Biggy.

Biggy connects to the Wiz GraphQL API with a read-only service account and reads only the projects you grant it access to.

Required permissions

Grant the Wiz service account only the following read scopes:

  • read:issues

  • read:vulnerabilities

  • read:resources

No write or admin scopes are needed. If you scope the service account to specific projects, Biggy only sees those projects.

Configure the Wiz integration

To configure the integration:

  1. In the Wiz portal, go to Settings > Access Management > Service Accounts and create a Custom Integration (GraphQL API) service account. Copy the Client ID and Client Secret. The secret is shown only once.

  2. Grant only the read scopes Biggy uses: read:issues, read:vulnerabilities, and read:resources. No write or admin scopes are needed. If you scope the account to specific projects, Biggy only sees those projects.

  3. Populate the following fields in the web app:

Field

Description

Instance Name

A human-readable name to identify this instance in the list. (For example, Production Wiz)

Routing Instructions (Optional)

Describe what this instance covers so Biggy can route queries to it. (For example, EU production accounts) Routing instructions are recommended, and are required for multiple instances.

Agent Notes (Optional)

Add notes to help Biggy understand your Wiz environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which projects map to which applications or environments.

Wiz GraphQL API URL

Your tenant API endpoint, found on the Tenant page under Settings in the Wiz portal. Commercial (app.wiz.io), FedRAMP (app.wiz.us), and GovCloud (gov.wiz.io) hosts are accepted. (For example, https://api.<region>.app.wiz.io/graphql)

Wiz OAuth Token URL

The token endpoint for the same Wiz environment as the API URL. Tenants that still authenticate at https://auth.wiz.io/oauth/token can keep that URL. (For example, https://auth.app.wiz.io/oauth/token)

Client ID

The service account Client ID from Wiz.

Client Secret

The service account Client Secret from Wiz. Biggy encrypts this value at rest and masks it in the form. The secret is shown only once in Wiz, so copy it when you create the service account.

OAuth Audience (Optional)

Leave empty to use wiz-api. The value beyond-api is applied automatically for the legacy auth.wiz.io token host. Set a value only if Wiz support told you to.

After entering the connection details, click Verify Connection to confirm that the connection to Wiz is established.

Zscaler ZDX

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy Zscaler ZDX integration lets Biggy view digital-experience alerts, app scores, users, devices, and Cloud Path data from Zscaler Digital Experience (ZDX).

Biggy connects to the ZDX API with an API key and reads within the tenant's ZDX license scope.

Collection delay

ZDX telemetry arrives with an estimated 20-minute collection delay, and most reports cover 2-hour windows. Biggy states this on every answer rather than presenting the data as live.

Prerequisites

To use the integration, you need:

  • A ZDX subscription with API access. The API key inherits the tenant's ZDX license scope.

  • A ZDX API Key ID and Key Secret, created under Administration > Authentication > API Key Management.

ZDX enforces a rate limit of 5 requests per second on every tier. Biggy runs long lookbacks sequentially to stay within it.

Configure the Zscaler ZDX integration

To configure the integration:

  1. Create an API key in the ZDX Admin Portal. Go to Administration > Authentication > API Key Management and create an API key, or download the key file. Copy the Key ID and Key Secret. The secret is shown only once.

  2. Populate the following fields in the web app:

Field

Description

Instance Name

A human-readable name to identify this instance in the list. (For example, Production Zscaler ZDX)

Routing Instructions (Optional)

Describe what this instance covers so Biggy can route queries to it. (For example, EU production accounts) Routing instructions are recommended, and required for multiple instances.

Agent Notes (Optional)

Add notes to help Biggy understand your ZDX environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which ZDX applications map to which business services, department or location naming, and the ZDX Score thresholds that matter to you.

ZDX API URL

The ZDX API base for your Zscaler cloud, including the version your tenant is provisioned for. Your cloud is the one in your Admin Portal address, admin.<cloud>.net. (For example, https://api.zdxcloud.net/v1, or /v2)

API Key ID

The ZDX API Key ID created in the Admin Portal.

API Key Secret

The ZDX API Key Secret. Biggy encrypts this value at rest and masks it in the form. The secret is shown only once in the Admin Portal, so copy it when you create the key.

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

After entering the connection details, click Verify Connection to confirm that the connection to Zscaler ZDX is established.

In this section: