Skip to content

Add OpenTelemetry metrics to DynamoDB EF Core instrumentation package #197

Description

@j-d-ha

Problem

Tracing alone does not cover the operational questions DynamoDB users need to answer across many requests, such as request volume, latency distribution, failure rates, consumed capacity, pagination volume, and batch statement errors.

The DynamoDB EF Core provider has DynamoDB-specific diagnostics data that generic EF Core OpenTelemetry instrumentation does not understand because it is relational/IDbCommand-oriented.

Goal

Extend the DynamoDB EF Core OpenTelemetry instrumentation package with metrics for provider-level DynamoDB operations.

Depends on package foundation from #196.

Scope

  • Add metrics registration extensions to the instrumentation package.
  • Consume provider diagnostics for request completion, failures, consumed capacity, paging, and batch statement errors.
  • Emit stable OpenTelemetry-compatible metrics using low-cardinality dimensions.
  • Add tests verifying metric names, measurements, and attributes.
  • Document application setup and metric meanings.

Expected API Shape

services.AddOpenTelemetry()
    .WithMetrics(builder => builder
        .AddDynamoDbEntityFrameworkCoreInstrumentation());

If tracing and metrics share one extension method name, docs should show both tracing and metrics setup clearly.

Metrics To Emit

Record metrics for:

  • operation duration
  • operation count
  • operation failures
  • consumed capacity when returned by DynamoDB
  • page/request count for paged ExecuteStatement queries
  • batch statement errors returned by successful BatchExecuteStatement responses

Candidate instruments:

  • dynamodb.efcore.client.operation.duration
  • dynamodb.efcore.client.operation.count
  • dynamodb.efcore.client.operation.errors
  • dynamodb.efcore.client.consumed_capacity
  • dynamodb.efcore.client.pages
  • dynamodb.efcore.client.batch_statement_errors

Final names should be checked against current OpenTelemetry .NET and database semantic-convention guidance before implementation.

Metric Attributes

Use stable, low-cardinality attributes only. Candidate attributes:

  • operation kind: ExecuteStatement, ExecuteTransaction, BatchExecuteStatement
  • result: success, failure, partial_failure
  • table name when known and safe
  • index name when known and safe
  • DbContext type
  • scan-like/query classification only if low-cardinality

Avoid high-cardinality values:

  • partition key values
  • sort key values
  • request ids
  • continuation token values
  • raw parameter values
  • raw statement text

Relationship To Existing Diagnostics

Relevant provider payloads include:

  • DynamoExecuteStatementExecutedEventData
  • DynamoExecuteStatementFailedEventData
  • DynamoPartiQlWriteRequestExecutedEventData
  • DynamoPartiQlWriteRequestFailedEventData
  • DynamoBatchStatementErrorsEventData

Consumed capacity metrics depend on provider requests being configured with ReturnConsumedCapacity; when DynamoDB does not return capacity data, capacity metrics should not emit misleading zero values.

Acceptance Criteria

  • Instrumentation package exposes metrics registration extension methods.
  • Metrics are emitted for operation duration, count, failures, consumed capacity, pages, and batch statement errors.
  • Metric attributes are stable and low-cardinality.
  • No sensitive values are recorded.
  • Consumed capacity is emitted only when returned by DynamoDB.
  • Tests verify emitted measurements and attributes for success, failure, pagination, consumed capacity, and batch statement errors.
  • Docs describe metric names, dimensions, and required ReturnConsumedCapacity behavior.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions