Basic instrumentation for Bedrock runtime Converse api

[xrmx]

Description

This is a basic implementation extending the botocore instrumentation with a bedrock-runtime specific extension. This follows genai semconv but is not implementing metrics or events yet.

This is still missing some more tests, some docs, support for tools, events, metrics and streaming but can be discussed since this would be a genai insrumentation outside instrumentation-genai dir and looking very different than the others.

This is a run of the shipped example traced:

dotenv run -- opentelemetry-instrument --traces_exporter=console --logs_exporter=none --metrics_exporter=none python converse.py

This is a short poem on OpenTelemetry:

OpenTelemetry, a tool for tracing,
A tool for tracing and monitoring,
It helps to identify and fix bugs,
And make sure the system is secure.
{
    "name": "chat amazon.titan-text-lite-v1",
    "context": {
        "trace_id": "0x801260c37f04079cb7be221fd66cee25",
        "span_id": "0x2805303fc6f3bb1e",
        "trace_state": "[]"
    },
    "kind": "SpanKind.CLIENT",
    "parent_id": null,
    "start_time": "2025-01-15T14:26:05.379154Z",
    "end_time": "2025-01-15T14:26:07.062142Z",
    "status": {
        "status_code": "UNSET"
    },
    "attributes": {
        "rpc.system": "aws-api",
        "rpc.service": "Bedrock Runtime",
        "rpc.method": "Converse",
        "aws.region": "eu-central-1",
        "gen_ai.system": "aws.bedrock",
        "gen_ai.request.model": "amazon.titan-text-lite-v1",
        "gen_ai.operation.name": "chat",
        "aws.request_id": "6f43aecb-ba21-46b5-be38-65fa656d70bb",
        "retry_attempts": 0,
        "http.status_code": 200,
        "gen_ai.usage.input_tokens": 12,
        "gen_ai.usage.output_tokens": 48,
        "gen_ai.response.finish_reasons": [
            "end_turn"
        ]
    },
    "events": [],
    "links": [],
    "resource": {
        "attributes": {
            "telemetry.sdk.language": "python",
            "telemetry.sdk.name": "opentelemetry",
            "telemetry.sdk.version": "1.29.0",
            "service.name": "opentelemetry-python-bedrock",
            "telemetry.auto.version": "0.50b0"
        },
        "schema_url": ""
    }
}

Random notes

• AWS exposes all the APIs via the boto3 library, botocore is a dependency of boto3 that contains the doc of the services from where the code is then generated at runtime
• Even if there are many different services, even if you write different instrumentations everyone will wrap the same botocore function
• botocore instrumentation has the notion of extensions that are a way to register some callback for a specific AWS service that would be then called by the common code
• Given the point above so just one span would be created using the same common tracer
• For some reason the botocore instrumentation suppresses http instrumentation so we are not getting http spans
• boto instrumentation is for the official client before the introduction of the current boto3; boto3sqs instrumentation is something specific to boto3 sqs client

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• tox -e py310-test-instrumentation-botocore

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[codefromthecrypt]

Thanks for getting this started, I'm marking approved despite you mentioning that there are some work to backfill here. Mainly, I approve of the direction, and here are my answers to comments you made in the PR desc.

On genai directory or here in boto: agree to do it in boto

Even though there is a "genai" directory, I agree this makes most sense handled as an extension with the rest of the boto instrumentation, especially to avoid problems as genai directory is released independently of the rest of contrib.

On invoke_model or converse: do both

It could be best to support both from the start as it is easier to migrate folks that way.

• openinference instruments both invoke_model and converse
• openlit and langtrace instruments converse
• openllmetry instruments invoke_model

Basically, we don't want resistance for folks moving to the new canonical instrumentation unless invoke_model is a dead api.

[karthikscale3]

Thanks for starting this