Repository navigation
Nightly dependency update: OpenTelemetry 2.32.0/1.61.0 - #1462
Conversation
|
Claude finished @aws-application-signals-bot's task in 21s —— View job Claude Code Review
Review SummaryThis is a routine nightly dependency bump:
The version strings are consistent across both files and the snapshot version is correctly incremented one minor ahead of the stable version, matching the existing pattern. No code logic changes. Note: The linked CI run is reported as failing. The diff itself is sound, so the failure is likely from upstream instrumentation changes in v2.32.0 (muzzle / contract-test / smoke-test fallout) rather than from the version bump edits themselves. A maintainer should check the CI logs to confirm whether any adapter code needs adjustment for v2.32.0. No new substantive issues to flag on the diff. |
aws-application-signals-bot
changed the title
|
Claude finished @vastin's task in 26s —— View job Claude Code Review
Review SummaryRoutine nightly dependency bump — version strings are consistent and correctly structured:
No code logic changes, no new substantive issues to flag on the diff itself. Note: The linked CI run is reported as failing. The diff itself is sound, so any failure is likely from upstream instrumentation changes in v2.32.0 (muzzle / contract-test / smoke-test fallout) rather than from the version bump edits. A maintainer should review the CI logs to determine whether adapter code needs adjustment for v2.32.0. |
- contrib patch: bump version.gradle.kts hunk to 1.61.0-adot1. - lambda aws-otel-java-instrumentation patch: bump otelVersion to 2.32.0-adot-lambda1. - lambda opentelemetry-java-instrumentation patch: rebase onto v2.32.0. Upstream added its own getXrayTraceId() lookup to AwsLambdaFunctionInstrumenter; keep ADOT's ParentContextExtractor (which also falls back to the system property / env var) in place of it. Port the extract(lambdaRequest, context) call into the rewritten events-2.2 SQS advice, and point upstream's new useXrayTraceIdFromAwsContext test at the ADOT extract path.
…h targets
Upstream 2.32.0 changed JmxMetricInsightInstaller to only load its
built-in target systems; it no longer resolves otel.jmx.target.system
entries to jmx/rules/<target>.yaml on the classpath. The ADOT-only
kafka, kafka-consumer, and kafka-producer rules were therefore silently
ignored ("JMX target system kafka is not supported"), and the Kafka JMX
contract tests timed out waiting for metrics.
Add AwsJmxRulesInstaller, an AgentListener that reads the same jmx
config as the upstream installer and loads the ADOT rules for those
targets into a separate JmxTelemetry. jvm and tomcat are still handled
by the upstream installer.
|
Claude finished @vastin's task in 1m 56s —— View job Claude Code Review
Review SummaryThe dependency bump itself (
Minor nits (non-blocking)
Lambda layer patch ( Rebase onto upstream 2.32.0 looks correct: it preserves the ADOT-specific change of threading the Lambda Nothing blocking from me. The CI failure is almost certainly from upstream smoke/contract tests rather than the diff itself — worth a maintainer's eyes on the logs before merge. |
Upstream 2.32.0 loads jmx/rules/<system>.yaml as its built-in stable rules and enables their unstable metrics for legacy target systems. With ADOT's rules in jmx/rules/, that meant: - the jvm target, also used by Application Signals runtime metrics, gained 7 upstream jvm metrics. - the tomcat target gained 8 upstream tomcat metrics. - ADOT's tomcat rules loaded even with no target system set. Loading upstream's jvm rules next to ADOT's is not an option either: both define jvm.cpu.time, in s and ns, which the CloudWatch agent maps to JVMCpuTime. Move the ADOT rules to jmx/aws/rules/. Move the ADOT target systems (jvm, tomcat, kafka, kafka-consumer, kafka-producer) from otel.jmx.target.system to otel.aws.jmx.target.system, and load their rules in AwsJmxRulesInstaller, with the same discovery delay as the upstream installer. The other target systems are left to the upstream installer. JMX metrics for the ADOT target systems are the same as with the current release, with or without Application Signals or the AWS JMX exporter. RuntimeMetricsTest now also checks the units and "name" attribute values that the CloudWatch agent relies on to produce the Application Signals runtime metrics, so changes of the underlying metrics that would break them fail the test. Additional metrics are still allowed.
|
Claude finished @vastin's task in 1m 50s —— View job Claude Code Review
Review SummaryRoutine nightly dependency bump plus the follow-up fixes to keep ADOT's JMX metrics unchanged after upstream OTel instrumentation 2.32.0 stopped loading classpath-provided JMX target systems. The substantive diff — The only change since that review is No new substantive issues to flag. Note: The linked CI run is reported as failing. The author's call-outs in the commit messages ( |
…dates # Conflicts: # awsagentprovider/src/test/java/software/amazon/opentelemetry/javaagent/providers/AwsApplicationSignalsCustomizerProviderTest.java
|
Claude finished @vastin's task in 2m 17s —— View job Claude Code Review
Review SummaryThe substantive work in this PR — Changes since that review:
No new substantive issues. Note: The linked CI run is reported as failing. The commit messages ( |
Automated update of OpenTelemetry dependencies.
Build Status: ❌ failure
Updated versions:
Upstream releases with breaking changes:
Note: the mechanism to detect upstream breaking changes is not perfect. Be sure to check all new releases and understand if any additional changes need to be addressed.
opentelemetry-java-instrumentation:
opentelemetry-java-contrib: