> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superblocks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Observability destinations

export const Alert = ({type, title, children}) => {
  const variant = ["info", "success", "warning", "danger", "note"].includes(type) ? type : "note";
  return <div className={`alert alert--${variant}`}>
      <div className="alert-icon" />
      <div className="alert-content">
        {title && <div className="alert-title">{title}</div>}
        <div className="alert-body">{children}</div>
      </div>
    </div>;
};

Cloud-Prem always writes full telemetry to AWS services in your Cloud-Prem account. You can also send each signal (logs, metrics, and traces) to your own observability tool, so your team can monitor Superblocks alongside the rest of your stack.

Adding a destination does not change what Superblocks receives. Superblocks continues to receive the base telemetry it needs to operate and support your deployment.

## How destinations work

```mermaid theme={null}
flowchart LR
  CP["Cloud-Prem services"] --> CW["CloudWatch<br/>logs and metrics"]
  CP --> XR["AWS X-Ray<br/>traces"]
  CP --> SB["Superblocks<br/>base telemetry"]
  CP -.-> DEST["Your destination<br/>Datadog, OTLP, or Prometheus<br/>per signal"]
```

* **Your AWS account always gets everything.** Logs and metrics go to Amazon CloudWatch and traces go to AWS X-Ray, whether or not you add a destination.
* **Each signal is configured on its own.** Logs, metrics, and traces can each go to one additional destination, and each signal can use a different one. For example, you can send logs to Datadog and traces to an OTLP endpoint.
* **You own the settings; Superblocks applies them.** You store destination settings and credentials in AWS Secrets Manager in your Cloud-Prem account. Superblocks applies them at the next deployment.

## Choose a destination

| Destination | Setup | Best when |
| - | - | - |
| **Datadog** | Built in, configured per signal | Your team already uses Datadog |
| **OpenTelemetry and Prometheus** | Built in, configured per signal | You use Grafana Cloud or another tool that accepts OTLP for traces and logs, and Prometheus remote write for metrics |
| **Forward from your AWS account** | You build and own the forwarding | Your tool isn't supported directly, or you already forward CloudWatch and X-Ray data centrally |

## Configure a destination

<Steps>
  <Step title="Gather your destination details">
    Collect the values for each signal you want to send. You only need values for the signals you are configuring.

    <Tabs>
      <Tab title="Datadog">
        | Value | Description |
        | - | - |
        | API key | A Datadog API key. One key is used for every signal you send to Datadog |
        | Site | Your Datadog site, such as `datadoghq.com` or `datadoghq.eu` |
      </Tab>

      <Tab title="OpenTelemetry and Prometheus">
        | Signal | Endpoint type | Example (Grafana Cloud) |
        | - | - | - |
        | Metrics | Prometheus remote write | `https://prometheus-prod-01-eu-west-0.grafana.net/api/prom/push` |
        | Traces | OTLP | `https://otlp-gateway-prod-eu-west-0.grafana.net/otlp` |
        | Logs | OTLP | `https://otlp-gateway-prod-eu-west-0.grafana.net/otlp` |

        For each endpoint, also collect the `Authorization` header value it expects, including the scheme, such as `Basic <credentials>`.
      </Tab>
    </Tabs>
  </Step>

  <Step title="Create the secret in AWS Secrets Manager">
    In your Cloud-Prem AWS account, create a secret named exactly `superblocks-main/superblocks/customer_exporter`. Include only the signals you want to send, and write every value as a string, including `"true"`.

    <Tabs>
      <Tab title="Datadog">
        ```bash theme={null}
        aws secretsmanager create-secret \
          --name "superblocks-main/superblocks/customer_exporter" \
          --secret-string '{
            "DATADOG_API_KEY": "<your-datadog-api-key>",
            "DATADOG_SITE": "datadoghq.com",
            "DATADOG_METRICS_ENABLED": "true",
            "DATADOG_TRACES_ENABLED": "true",
            "DATADOG_LOGS_ENABLED": "true"
          }'
        ```
      </Tab>

      <Tab title="OpenTelemetry and Prometheus">
        ```bash theme={null}
        aws secretsmanager create-secret \
          --name "superblocks-main/superblocks/customer_exporter" \
          --secret-string '{
            "MIMIR_ENABLED": "true",
            "MIMIR_ENDPOINT": "https://prometheus-prod-01-eu-west-0.grafana.net/api/prom/push",
            "MIMIR_AUTHORIZATION": "Basic <metrics-credentials>",
            "TEMPO_ENABLED": "true",
            "TEMPO_ENDPOINT": "https://otlp-gateway-prod-eu-west-0.grafana.net/otlp",
            "TEMPO_AUTHORIZATION": "Basic <traces-credentials>",
            "OTLP_LOGS_ENABLED": "true",
            "OTLP_LOGS_ENDPOINT": "https://otlp-gateway-prod-eu-west-0.grafana.net/otlp",
            "OTLP_LOGS_AUTHORIZATION": "Basic <logs-credentials>"
          }'
        ```
      </Tab>
    </Tabs>

    See the [secret reference](#secret-reference) for every supported key.
  </Step>

  <Step title="Tell Superblocks">
    Let your Superblocks deployment team know the secret is ready. Superblocks applies the configuration at the next deployment.
  </Step>

  <Step title="Verify data is arriving">
    After the deployment completes, check your destination for new data from each signal you configured.
  </Step>
</Steps>

<Alert type="info">
  If your Cloud-Prem account restricts outbound traffic, allow connections from the Cloud-Prem account to your destination's endpoints before you verify.
</Alert>

### Send signals to different destinations

To split signals across destinations, combine keys from both in the same secret and enable each signal for only one destination. This example sends logs to Datadog and traces to an OTLP endpoint, and leaves metrics in your AWS account only:

```json theme={null}
{
  "DATADOG_API_KEY": "<your-datadog-api-key>",
  "DATADOG_SITE": "datadoghq.com",
  "DATADOG_LOGS_ENABLED": "true",
  "TEMPO_ENABLED": "true",
  "TEMPO_ENDPOINT": "https://otlp-gateway-prod-eu-west-0.grafana.net/otlp",
  "TEMPO_AUTHORIZATION": "Basic <traces-credentials>"
}
```

## Forward from your AWS account

If you'd rather route telemetry yourself, use AWS features to forward it from your Cloud-Prem account. Superblocks doesn't configure or manage this forwarding.

| Signal | Where it lands | How to forward it |
| - | - | - |
| Logs | Amazon CloudWatch Logs | [Subscription filters](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions.html) to Amazon Data Firehose, Kinesis, or Lambda |
| Metrics | Amazon CloudWatch | [Metric streams](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html) to Amazon Data Firehose or a supported partner |
| Traces | AWS X-Ray | Your observability tool's X-Ray integration, or the [X-Ray APIs](https://docs.aws.amazon.com/xray/latest/api/Welcome.html) |

You can combine approaches. For example, send traces to an OTLP endpoint through the secret and forward logs yourself with a subscription filter.

## Change or remove a destination

To change the secret, replace its value with the full, updated JSON, then tell your Superblocks deployment team:

```bash theme={null}
aws secretsmanager put-secret-value \
  --secret-id "superblocks-main/superblocks/customer_exporter" \
  --secret-string '{ ... }'
```

* **Change a destination:** update its endpoint, credentials, or site.
* **Stop sending a signal:** set that signal's `_ENABLED` key to `"false"`.
* **Stop sending all signals:** set every `_ENABLED` key to `"false"`, or delete the secret.

Changes take effect at the next deployment. Your CloudWatch and X-Ray data, and the base telemetry Superblocks receives, are unaffected.

## Troubleshooting

If data isn't arriving after the deployment completes, check:

* **Secret name:** the secret is named exactly `superblocks-main/superblocks/customer_exporter` and is in your Cloud-Prem account.
* **Secret contents:** the secret is valid JSON, uses the exact key names in the [secret reference](#secret-reference), and every value is a string (`"true"`, not `true`).
* **One destination per signal:** a signal isn't enabled for both Datadog and an OpenTelemetry or Prometheus endpoint.
* **Credentials:** the API key or `Authorization` value is valid, includes the scheme (such as `Basic`), and has permission to write data.
* **Datadog site:** the site matches your Datadog account.
* **Network access:** outbound traffic from the Cloud-Prem account can reach your destination's endpoints.

If everything checks out, contact your Superblocks deployment team.

## Secret reference

All values are strings.

### Datadog

| Key | Description |
| - | - |
| `DATADOG_API_KEY` | Datadog API key, used for every signal sent to Datadog |
| `DATADOG_SITE` | Datadog site, such as `datadoghq.com` or `datadoghq.eu` |
| `DATADOG_METRICS_ENABLED` | `"true"` to send metrics to Datadog |
| `DATADOG_TRACES_ENABLED` | `"true"` to send traces to Datadog |
| `DATADOG_LOGS_ENABLED` | `"true"` to send logs to Datadog |

### OpenTelemetry and Prometheus

| Key | Signal | Description |
| - | - | - |
| `MIMIR_ENABLED` | Metrics | `"true"` to send metrics to a Prometheus remote write endpoint |
| `MIMIR_ENDPOINT` | Metrics | Prometheus remote write URL |
| `MIMIR_AUTHORIZATION` | Metrics | `Authorization` header value, including the scheme |
| `TEMPO_ENABLED` | Traces | `"true"` to send traces to an OTLP endpoint |
| `TEMPO_ENDPOINT` | Traces | OTLP endpoint URL |
| `TEMPO_AUTHORIZATION` | Traces | `Authorization` header value, including the scheme |
| `OTLP_LOGS_ENABLED` | Logs | `"true"` to send logs to an OTLP endpoint |
| `OTLP_LOGS_ENDPOINT` | Logs | OTLP endpoint URL |
| `OTLP_LOGS_AUTHORIZATION` | Logs | `Authorization` header value, including the scheme |