Export user activity with OpenTelemetry

You can send the same daily aggregate user activity metrics to your OpenTelemetry-compatible collector. Kiro pushes credits, overage credits, messages, conversations, and per-model message counts once a day at 02:00 UTC. The export is configured by an administrator and can't be configured by individual users.

Kiro supports OTLP/gRPC and OTLP/HTTP with protobuf encoding. gRPC is the default. In the Kiro console, the HTTP option is labeled HTTP/protobuf.

The OpenTelemetry export and the CSV report in Amazon S3 are independent. You can enable either format or both. Kiro stores only the ARN of your AWS Secrets Manager secret and reads the collector endpoint and authentication header from the secret at export time.

Choose the protocol, endpoint, and single authentication header that your destination accepts before you create the secret. Use the following destination configurations:

Replace deployment, region, collector-host, and environment with values from your destination. Replace the credential placeholder in the header with your ingestion credential.

Use an ingestion credential rather than an administrative credential. For Honeycomb, use the combined ingest key ID and secret, not the key ID alone. For Elastic, base64-encode id:api_key. For Datadog, use an API key, not an application key. For Dynatrace, use an access token with metrics.ingest permission. Amazon CloudWatch requires a bearer API key because Kiro can't sign the export with AWS Signature Version 4 (SigV4). To create the key, see Setting up bearer token authentication for Metrics in the Amazon CloudWatch User Guide.

Create a symmetric customer managed AWS KMS key for encryption and decryption. The default aws/secretsmanager key can't be used because Kiro reads the secret from another AWS account. The KMS key, Secrets Manager secret, and Kiro profile must be in the same AWS Region.

Add the following statement to the KMS key policy. Replace region with the Region of your Kiro profile. This grants the q.amazonaws.com service principal permission to decrypt the secret through Secrets Manager in that Region.

{
  "Sid": "AllowKiroDecryptViaSecretsManager",
  "Effect": "Allow",
  "Principal": {
    "Service": "q.amazonaws.com"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "secretsmanager.region.amazonaws.com"
    }
  }
}

Save the policy. You select this key as the encryption key when you create the secret.

In the same Region as your Kiro profile, create an Other type of secret in AWS Secrets Manager. On the Plaintext tab, enter a JSON object with exactly these keys:

{
  "OTEL_EXPORTER_OTLP_ENDPOINT": "https://collector-host:443",
  "OTEL_EXPORTER_OTLP_HEADERS": "Header-Name=token"
}

• OTEL_EXPORTER_OTLP_ENDPOINT is your collector's OTLP endpoint.
• OTEL_EXPORTER_OTLP_HEADERS is one authentication header in Name=value format. Kiro splits the string on the first =, so base64 padding such as == in the value is preserved.

Your collector endpoint must be reachable from the public internet and use a publicly trusted TLS certificate. Kiro rejects self-signed certificates. Use a hostname rather than an IP address because Kiro verifies the certificate hostname.

For Encryption key, select the customer managed KMS key that you created. Don't select aws/secretsmanager. Add the following resource policy to the secret so Kiro can read its value:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowKiroGetSecretValue",
      "Effect": "Allow",
      "Principal": {
        "Service": "q.amazonaws.com"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}

Store the secret and copy its secret ARN, which has the format arn:aws:secretsmanager:region:accountId:secret:secretName-randomSuffix.

1. Sign in to the AWS console.

2. Switch to the Kiro console. You must have the permissions in Policy: Allow administrators to configure Kiro and subscribe users.

3. Choose Settings.

4. Under Kiro user activity reports, choose Edit.

5. Choose the OpenTelemetry (OTel) export format.

6. Enter the Secrets Manager secret ARN.

7. Select the protocol that your collector accepts: gRPC or HTTP/protobuf.

8. Choose Enable.

The first export runs during the next 02:00 UTC cycle. Metrics for an activity date are sent the following day, and Kiro doesn't send data to your collector when you save the configuration.

Kiro doesn't send success or failure notifications. Confirm delivery in your destination by querying kiro.daily.credits or another exported metric and filtering on the resource attribute service.name = kiro-enterprise.

A successful export has these characteristics:

• kiro.daily.credits and kiro.daily.messages are present.
• For each exported metric, expect one daily datapoint per active user and client type. kiro.daily.model_messages has one datapoint per model.
• The date attribute identifies the activity date, which is the day before the export ran.
• Each datapoint includes at least kiro.user.id, kiro.client.type, and kiro.user.new.

Prometheus-based backends can replace periods in metric names with underscores. For example, kiro.daily.credits can appear as kiro_daily_credits.

Check the destination because Kiro treats a request accepted by the collector as successful even if the collector later rejects its datapoints.

Each resulting time series receives one daily datapoint. If a range query returns no data, use a narrow window around the export time and a fine step, such as 60 seconds. A metric name can remain in an index or autocomplete after its datapoints fall outside the selected time window, so confirm that the query returns datapoints rather than only a metric name.

All exported metrics are monotonic OTLP Sum counters in the kiro.daily.* namespace.

Each kiro.daily.model_messages datapoint includes kiro.model.name, which identifies the model represented by the corresponding dynamic CSV column.

Each datapoint can include the following attributes:

Each export also includes these resource attributes:

• Kiro retries transient failures automatically, with up to three attempts for an activity date.
• If all attempts fail, Kiro doesn't resend or automatically backfill that date. The destination has a gap for that day.
• If a date is exported again, Kiro doesn't deduplicate the datapoints at your collector. The collector receives them a second time.
• A request accepted by your collector counts as successful even if the collector later rejects some or all datapoints. Verify the metrics at the destination.
• Configuration errors repeat until you correct them. After you update the secret, Kiro uses the new value during the next 02:00 UTC cycle.
• Selecting gRPC for an HTTP-only endpoint, or HTTP/protobuf for a gRPC-only endpoint, prevents delivery. Kiro doesn't notify you of the failure.

If no metrics arrive, verify that the secret and KMS key are in the Kiro profile's Region. Confirm that q.amazonaws.com has secretsmanager:GetSecretValue on the secret and kms:Decrypt and kms:DescribeKey on the KMS key. Then verify the protocol, endpoint reachability, TLS certificate, and authentication header required by your destination.