fix(traceloop-sdk): redefine histogram bucket boundaries

[minimAluminiumalism]

• I have added tests that cover my changes.
• If adding a new instrumentation or changing an existing one, I've added screenshots from some observability platform showing the change.
• PR name follows conventional commits format: feat(instrumentation): ... or fix(instrumentation): ....
• (If applicable) I have updated the documentation accordingly.

Removed LLM_OPERATION_DURATION to make it use OTel SDK's boundary defaultly. For token we're utilizing the definitions at python-contrib.

---

Important

Redefines histogram bucket boundaries for LLM_TOKEN_USAGE and removes custom boundaries for LLM_OPERATION_DURATION in metrics.py.

• Behavior:
  • Removes custom histogram boundaries for LLM_OPERATION_DURATION in metric_views().
  • Redefines histogram boundaries for LLM_TOKEN_USAGE in metric_views() with new values.
• Misc:
  • Utilizes OTel SDK's default boundaries for LLM_OPERATION_DURATION.

^{This description was created by for feb2eb6. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to feb2eb6 in 1 minute and 42 seconds. Click for details.

• Reviewed 61 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. packages/traceloop-sdk/traceloop/sdk/metrics/metrics.py:89

• Draft comment:
  Removal of the custom view for LLM_OPERATION_DURATION appears intentional to let the OTel SDK use its default boundaries. Please ensure this removal doesn't break any downstream expectations.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 30% <= threshold 50% The comment is asking the PR author to ensure that the removal doesn't break any downstream expectations, which violates the rule against asking the author to ensure behavior is intended or tested. However, it does note that the removal appears intentional, which is a valid observation. Overall, the comment leans more towards asking for confirmation rather than providing a specific suggestion or observation.

2. packages/traceloop-sdk/traceloop/sdk/metrics/metrics.py:92

• Draft comment:
  Histogram bucket boundaries for LLM_TOKEN_USAGE have been updated to integer values (1, 10, 50, ...). It would help to add an inline comment referencing the python‐contrib definitions for future maintainers.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment is about documentation, not a functional issue. The bucket boundaries themselves seem reasonable for token usage (which would naturally be integers). Adding a reference comment would be nice-to-have but not essential. The code is fairly self-explanatory - these are clearly token count boundaries. The comment could be valid if there's an important standard or convention from python-contrib that should be followed. Without seeing the python-contrib reference, we can't be sure if this is important. Even if there is a python-contrib reference, the current code is clear and functional. Documentation suggestions should be more specific if they're truly important. This comment should be deleted as it's a non-essential documentation suggestion that doesn't clearly improve code quality or functionality.

Workflow ID: wflow_ZOiVbnK9ntKlcwCb

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[nirga]

Should we define a different aggregation?

[minimAluminiumalism]

No. Since we have explicitly specified the boundary values, we should just use ExplicitBucketHistogramAggregation rather than ExponentialBucketHistogramAggregation or DefaultAggregation here.

https://github.com/open-telemetry/opentelemetry-python/blob/14401e1dd82852fdea76ecf4d720fbd74834b705/opentelemetry-sdk/src/opentelemetry/sdk/metrics/_internal/aggregation.py#L4