Skip to content

Conversation

@liustve
Copy link
Contributor

@liustve liustve commented May 18, 2025

Supporting ADOT auto instrumentation to handle LLO log events.

Description of changes:

  1. Adds AwsBatchLogRecordProcessor a backwards compatible custom logs BatchProcessor which has the following invariants:
    • The unserialized, uncompressed data size of exported batches will ALWAYS be <= 1 MB except for the case below:
    • If the data size of an exported batch is ever > 1 MB then the batch size is always length 1
  2. OTLPAwsLogExporter: Adds a new behavior for Retry delay based on server-side response of Retry-After header. Injects the LLO header flag if the size of the exported data > 1 MB.
  3. Customize the auto instrumentation to use the new AwsBatchLogRecordProcessor

Testing:

TODO:

  1. Add unit tests to validate behavior of AwsBatchLogRecordProcessor and OTLPAwsLogExporter
  2. E2E testing to validate any performance hits and compatibility with: BedrockAgentCore LLO Support in ADOT SDK #361

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@liustve liustve requested a review from a team as a code owner May 18, 2025 00:14
@liustve liustve force-pushed the sigv4_genai_logs branch from 770f906 to b370cb0 Compare May 18, 2025 00:25
@liustve liustve marked this pull request as draft May 18, 2025 00:36
@yiyuan-he
Copy link
Contributor

Thanks! Looks good overall.

Couple of small things:

  • Could you rebase again - seems like there are some extra changes not related to the processor.
  • Print statement cleanup.
  • We can just add a TODO for the retry logic and raise another PR.

@@ -0,0 +1,4 @@
BASE_LOG_BUFFER_BYTE_SIZE = 2000
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where does this number come from?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ran an e2e test with the Gen AI sample app and subtracted the size of the body content from the size of the entire log itself. I then multiplied by 3 and added a bit of extra buffer to account for larger logs.

Comment on lines 122 to 128
if isinstance(val, Sequence):
for content in val:
size += AwsBatchLogRecordProcessor._get_size_of_any_value(content)

if isinstance(val, Mapping):
for _, content in val.items():
size += AwsBatchLogRecordProcessor._get_size_of_any_value(content)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need these? The Gen AI Events we are emitting from the Span pipeline only contain primitive data types.

This recursive approach traverses the entire object graph depth-first, which could become expensive for:

  • Deeply nested JSON structures
  • Large arrays of complex objects
  • Circular references (would cause infinite recursion if present)
  • Dictionary keys aren't counted in the size calculation (potential underestimation)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This processor will have to account for more than just gen ai events. All logs emitted by the application will be processed through this so we have to account for more than primitive types.

@liustve liustve marked this pull request as ready for review May 19, 2025 23:09
@liustve liustve merged commit f1c49fe into aws-observability:genesis-dev-v2 May 19, 2025
@liustve liustve changed the title [WIP] Support for handling LLO in OTLP AWS Logs Exporter Support for handling LLO in OTLP AWS Logs Exporter May 19, 2025
@liustve liustve deleted the sigv4_genai_logs branch May 19, 2025 23:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants