open-telemetry/opentelemetry-java-examples

Java OpenTelemetry Examples

This module contains a set of fully-functional, working examples of using the OpenTelemetry Java APIs and SDK that should all be able to be run locally. Some of them assume you have docker running on your local machine.

Example modules:

• Using the SDK AutoConfiguration module
  • This module contains a fully-functional example of using the autoconfigure SDK extension module to configure the SDK using only environment variables (or system properties).
  • Note: the opentelemetry-sdk-extension-autoconfigure module is still experimental at this time.
• Manual instrumentation of HTTP
  • This module provides an example of writing manual instrumentation for HTTP, both client and server.
  • Note more production-ready instrumentation for HTTP is provided as a part of the OpenTelemetry Java Instrumentation project.
• Configuring the Jaeger Exporter
  • This module contains a fully-functional example of configuring the OpenTelemetry SDK to use a Jaeger exporter, and send some spans to it using the OpenTelemetry API.
  • Note: this example requires having docker installed to run the example.
• Using the OpenTelemetry Java Agent
  • This module demonstrates using the OpenTelemetry Java Agent with a simple spring boot application. Traces, metrics, and logs are exported to a collector via OTLP.
• Spring native image telemetry with OpenTelemetry Spring Starter
  • This module demonstrates using the OpenTelemetry Spring Boot starter with a Graal VM native image. Traces and metrics are exported to a collector via OTLP.
• Configuring Log Appenders
  • This module demonstrates how to configure the Log4j and Logback appenders to bridge logs into the OpenTelemetry Log SDK.
• Configuring the Logging Exporters
  • This module contains a fully-functional example of configuring the OpenTelemetry SDK to use a logging exporter.
• Using the OpenTelemetry metrics API
  • This module contains examples of using the OpenTelemetry metrics APIs.
• Using OpenTelemetry Micrometer shim
  • This module contains an example of a typical micrometer setup (spring boot with spring boot actuator) configured to bridge metrics to OpenTelemetry with the micrometer shim.
  • Note: the micrometer shim is still experimental at this time.
• Setting up OTLP exporters
  • OTLP is the OpenTelemetry Protocol. This module will demonstrate how to configure the OTLP exporters, and send data to the OpenTelemetry collector using them.
  • Note: this example requires having docker installed to run the example.
• Setting up the Prometheus exporter
  • The module shows how to configure the OpenTelemetry SDK to expose an endpoint that can be scraped by Prometheus.
  • Note: the prometheus metric reader is still experimental at this time.
• Manually Configuring the SDK
  • This module shows some concrete examples of manually configuring the Java OpenTelemetry SDK for Tracing.
• Telemetry Testing
  • This module demonstrates how to test OpenTelemetry instrumentation with a MockServer.
• Setting up the Zipkin exporter
  • This module contains a fully-functional example of configuring the OpenTelemetry SDK to use a Zipkin exporter, and send some spans to a zipkin backend using the OpenTelemetry API.
  • Note: this example requires having docker installed to run the example.

Approvers and Maintainers

Superset of approvers and maintainers from the opentelemetry-java and opentelemetry-java-instrumentation repositories.

opentelemetry-java-examples's Issues

Rename this repository to opentelemetry-java-examples?

or opentelemetry-java-samples?

Need a example for SkyWalking Exporter

I really need an example for SkyWalking Exporter. When I try to explore by myself I even can not find a jar like opentelemetry-exporter-skywalking.

Remove empty objects from file configuration example when 1.31.0 is released

          what does `{}` mean? is that a yaml thing? thx

Originally posted by @trask in #207 (comment)

The requirement for empty objects will go away when opentelemetry-java#5829 is merged, likely in release 1.31.0. Update the file configuration to remove {}.

not support OTEL_EXPORTER_OTLP_HEADERS in opentelemetry-spring-boot-starter

I just configured this header to export my app metric
OTEL_EXPORTER_OTLP_HEADERS=api-key=xxx

It got this error:
Failed to export metrics. Server responded with gRPC status code 16. Error message:

module : spring-native

Migrate build from gradle to kotlin

The other java repos all prefer .kts for build scripts. Let's get this one off of groovy and over to kotlin for consistency.

Renovate is not updating spring-native `mavenBom` dependency

opentelemetry-java-examples/spring-native/build.gradle

Line 14 in cf0bda5

mavenBom 'io.opentelemetry.instrumentation:opentelemetry-instrumentation-bom-alpha:1.26.0-alpha'

It looks like this is a known issue with Renovate: renovatebot/renovate#4614

cc @jeanbisutti

io.opentelemetry.semconv.resource.attributes.ResourceAttributes can not be resolved.

There is a problem in jaeger example (https://github.com/open-telemetry/opentelemetry-java-docs/tree/main/jaeger):
io.opentelemetry.semconv.resource.attributes.ResourceAttributes can not be resolved.

https://github.com/open-telemetry/opentelemetry-java-docs/blob/main/jaeger/src/main/java/io/opentelemetry/example/jaeger/ExampleConfiguration.java:

My maven:

<dependency>
            <groupId>io.opentelemetry</groupId>
            <artifactId>opentelemetry-bom</artifactId>
            <version>1.16.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>io.opentelemetry</groupId>
            <artifactId>opentelemetry-api</artifactId>
            <version>1.16.0</version>
        </dependency>
        <dependency>
            <groupId>io.opentelemetry</groupId>
            <artifactId>opentelemetry-sdk</artifactId>
            <version>1.16.0</version>
        </dependency>
        <dependency>
            <groupId>io.opentelemetry</groupId>
            <artifactId>opentelemetry-exporter-jaeger</artifactId>
            <version>1.16.0</version>
        </dependency>
        <dependency>
            <groupId>io.opentelemetry</groupId>
            <artifactId>opentelemetry-semconv</artifactId>
            <version>1.16.0-alpha</version>
            <scope>runtime</scope>
        </dependency>

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Edited/Blocked

These updates have been manually edited so Renovate will no longer make changes. To discard all commits and start over, click on a checkbox.

• Update opentelemetry packages to v2 (major) (io.opentelemetry.javaagent:opentelemetry-javaagent, io.opentelemetry.instrumentation:opentelemetry-instrumentation-annotations, io.opentelemetry.instrumentation:opentelemetry-instrumentation-bom-alpha)

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update plugin org.springframework.boot to v3.2.2

Detected dependencies

docker-compose

javaagent/docker-compose.yml

• otel/opentelemetry-collector-contrib 0.93.0

log-appender/docker-compose.yml

• otel/opentelemetry-collector-contrib 0.93.0

otlp/docker/docker-compose.yaml

prometheus/docker-compose.yml

spring-native/docker-compose.yml

• otel/opentelemetry-collector-contrib 0.93.0

dockerfile

javaagent/Dockerfile

prometheus/Dockerfile

github-actions

.github/workflows/build.yml

• actions/checkout v4
• gradle/wrapper-validation-action v1.1.0
• actions/checkout v4
• actions/setup-java v4
• gradle/gradle-build-action v3

.github/workflows/codeql-daily.yml

• actions/checkout v4
• actions/setup-java v4
• github/codeql-action v3
• gradle/gradle-build-action v3
• github/codeql-action v3

.github/workflows/issue-management-feedback-label.yml

• actions/checkout v4

.github/workflows/issue-management-stale-action.yml

• actions/stale v9

.github/workflows/reusable-markdown-link-check.yml

• actions/checkout v4

.github/workflows/reusable-workflow-notification.yml

• actions/checkout v4

gradle

gradle.properties

settings.gradle.kts

• com.diffplug.spotless 6.25.0
• com.github.johnrengelman.shadow 8.1.1
• com.google.protobuf 0.9.4
• com.gradle.enterprise 3.16.2
• org.gradle.toolchains.foojay-resolver-convention 0.8.0

build.gradle.kts

• io.opentelemetry:opentelemetry-bom-alpha 1.34.1-alpha
• io.opentelemetry.instrumentation:opentelemetry-instrumentation-bom-alpha 1.32.0-alpha

autoconfigure/build.gradle.kts

file-configuration/build.gradle.kts

grpc/build.gradle.kts

• io.grpc:grpc-netty-shaded 1.61.0
• io.grpc:grpc-protobuf 1.61.0
• io.grpc:grpc-services 1.61.0
• io.grpc:grpc-stub 1.61.0
• com.google.protobuf:protobuf-java-util 3.25.2
• io.opentelemetry.instrumentation:opentelemetry-grpc-1.6 1.32.0-alpha
• com.google.guava:guava 33.0.0-jre
• com.google.protobuf:protoc 3.25.2
• io.grpc:protoc-gen-grpc-java 1.61.0

http/build.gradle.kts

jaeger/build.gradle.kts

javaagent/build.gradle.kts

• org.springframework.boot 2.7.18
• io.opentelemetry.javaagent:opentelemetry-javaagent 1.32.0

kotlin-extension/build.gradle.kts

• org.jetbrains.kotlin.jvm 1.9.22
• org.jetbrains.kotlinx:kotlinx-coroutines-core 1.7.3

log-appender/build.gradle.kts

• org.slf4j:slf4j-api 2.0.11
• ch.qos.logback:logback-core 1.4.14
• ch.qos.logback:logback-classic 1.4.14
• org.slf4j:jul-to-slf4j 2.0.11
• org.apache.logging.log4j:log4j-bom 2.22.1

logging/build.gradle.kts

metrics/build.gradle.kts

micrometer-shim/build.gradle.kts

• org.springframework.boot 2.7.18

otlp/build.gradle.kts

prometheus/build.gradle.kts

sdk-usage/build.gradle.kts

spring-native/build.gradle.kts

• org.springframework.boot 3.2.1
• org.graalvm.buildtools.native 0.9.28
• io.opentelemetry:opentelemetry-bom 1.34.1
• io.opentelemetry.instrumentation:opentelemetry-instrumentation-bom-alpha 1.32.0-alpha

telemetry-testing/build.gradle.kts

• org.springframework.boot 2.7.18
• io.opentelemetry.instrumentation:opentelemetry-instrumentation-annotations 1.32.0
• org.junit:junit-bom 5.10.1
• org.mock-server:mockserver-netty 5.15.0
• org.awaitility:awaitility 4.2.0
• io.opentelemetry.proto:opentelemetry-proto 0.14.0-alpha
• org.assertj:assertj-core 3.25.2
• io.opentelemetry.javaagent:opentelemetry-javaagent 1.32.0

zipkin/build.gradle.kts

gradle-wrapper

gradle/wrapper/gradle-wrapper.properties

• gradle 8.5

---

• Check this box to trigger a request for Renovate to run again on this repository

Sample applications build fails with versions older than Java 17.

Hello.

The README in this repository instructs you to run gradlew in the top directory when building the sample application. However, some sample applications do not support Java 8 or Java 11, and attempting to build with, for example, Java 8 will result in the following error:

Build with Amazon Linux 2 and OpenJDK java-1.8.0-openjdk-1.8.0.372.b07-1.amzn2.0.1.x86_64

# ./gradlew bootJar

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'opentelemetry-java-examples'.
> Could not resolve all files for configuration ':classpath'.
   > Could not resolve com.diffplug.spotless:spotless-plugin-gradle:6.20.0.
     Required by:
         project : > com.diffplug.spotless:com.diffplug.spotless.gradle.plugin:6.20.0
      > No matching variant of com.diffplug.spotless:spotless-plugin-gradle:6.20.0 was found. The consumer was configured to find a library for use during runtime, compatible with Java 8, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin.api-version' with value '8.2.1' but:
          - Variant 'apiElements' capability com.diffplug.spotless:spotless-plugin-gradle:6.20.0 declares a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component for use during compile-time, compatible with Java 11 and the consumer needed a component for use during runtime, compatible with Java 8
              - Other compatible attribute:
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.2.1')
          - Variant 'javadocElements' capability com.diffplug.spotless:spotless-plugin-gradle:6.20.0 declares a component for use during runtime, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 8)
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.2.1')
          - Variant 'runtimeElements' capability com.diffplug.spotless:spotless-plugin-gradle:6.20.0 declares a library for use during runtime, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component, compatible with Java 11 and the consumer needed a component, compatible with Java 8
              - Other compatible attribute:
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.2.1')
          - Variant 'sourcesElements' capability com.diffplug.spotless:spotless-plugin-gradle:6.20.0 declares a component for use during runtime, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 8)
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.2.1')

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Get more help at https://help.gradle.org.

BUILD FAILED in 1s

In conclusion, building with Java 17 will not pose any problems, but it would be desirable to either update the README for each sample application or make adjustments so that individual applications can be built.

Thank you.

Fix prometheus example docker networking

The prometheus example uses the docker --network="host" option, which doesn't work on macs. The example should be updated to work on macs.

Originally posted by @jkwatson in #10 (comment)

autoconfigure errors

windows 10 desktop
builds on my dos shell but doesnt run
doesnt even build on my wsl ubuntu ,same java ,gradle versions
copied the jar to wsl folder and get same errors

c:\github\opentelemetry-java-examples\autoconfigure>..\gradlew shadowJar
Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details

BUILD SUCCESSFUL in 19s
2 actionable tasks: 2 up-to-date
c:\code\github\opentelemetry-java-examples\autoconfigure>java -Dotel.traces.exporter=logging -Dotel.metrics.exporter=logging -cp build\libs\opentelemetry-examples-autoconfigure-0.1.0-SNAPSHOT-all.jar io.opentelemetry.example.autoconfigure.AutoConfigExample
Dec 07, 2023 10:43:11 PM io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdkBuilder build
INFO: Error encountered during autoconfiguration. Closing partially configured components.
Dec 07, 2023 10:43:11 PM io.opentelemetry.exporter.logging.LoggingMetricExporter shutdown
INFO: Calling shutdown() multiple times.
Dec 07, 2023 10:43:11 PM io.opentelemetry.exporter.logging.LoggingMetricExporter shutdown
INFO: Calling shutdown() multiple times.
Dec 07, 2023 10:43:11 PM io.opentelemetry.exporter.logging.LoggingSpanExporter shutdown
INFO: Calling shutdown() multiple times.
Exception in thread "main" io.opentelemetry.sdk.autoconfigure.spi.ConfigurationException: otel.logs.exporter set to "otlp" but opentelemetry-exporter-otlp not found on classpath. Make sure to add it as a dependency.
at io.opentelemetry.sdk.autoconfigure.LogRecordExporterConfiguration.configureExporter(LogRecordExporterConfiguration.java:95)
at io.opentelemetry.sdk.autoconfigure.LogRecordExporterConfiguration.configureLogRecordExporters(LogRecordExporterConfiguration.java:66)
at io.opentelemetry.sdk.autoconfigure.LoggerProviderConfiguration.configureLoggerProvider(LoggerProviderConfiguration.java:43)
at io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdkBuilder.build(AutoConfiguredOpenTelemetrySdkBuilder.java:383)
at io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdk.initialize(AutoConfiguredOpenTelemetrySdk.java:33)
at io.opentelemetry.example.autoconfigure.AutoConfigExample.main(AutoConfigExample.java:17)

c:\github\opentelemetry-java-examples\autoconfigure>java -version
openjdk version "21.0.1" 2023-10-17
OpenJDK Runtime Environment (build 21.0.1+12-29)
OpenJDK 64-Bit Server VM (build 21.0.1+12-29, mixed mode, sharing)

c:\github\opentelemetry-java-examples\autoconfigure>gradle -version

---

Gradle 8.5

Workflow failed: Update gradle wrappers (daily) (#48)

See Update gradle wrappers (daily) #48.

Getting class not found exception due to build gradle 'io.opentelemetry.example.javagent.Application'

I am getting classnotfound for 'io.opentelemetry.example.javagent.Application'

bootRun {
mainClass.set 'io.opentelemetry.example.javagent.Application'
}
Exception in thread "main" java.lang.ClassNotFoundException: 'io.opentelemetry.example.javagent.Application'

autoconfigure example fails

I built the shadowed jar and ran the autoconfigure example, but I get this output

Exception in thread "main" io.opentelemetry.sdk.autoconfigure.spi.ConfigurationException: OTLP gRPC Metrics Exporter enabled but opentelemetry-exporter-otlp not found on classpath. Make sure to add it as a dependency to enable this feature.
        at io.opentelemetry.sdk.autoconfigure.ClasspathUtil.checkClassExists(ClasspathUtil.java:17)
        at io.opentelemetry.sdk.autoconfigure.MetricExporterConfiguration.configureOtlpMetrics(MetricExporterConfiguration.java:112)
        at io.opentelemetry.sdk.autoconfigure.MetricExporterConfiguration.configureExporter(MetricExporterConfiguration.java:46)
        at io.opentelemetry.sdk.autoconfigure.MeterProviderConfiguration.configureMeterProvider(MeterProviderConfiguration.java:48)
        at io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdkBuilder.build(AutoConfiguredOpenTelemetrySdkBuilder.java:312)
        at io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdk.initialize(AutoConfiguredOpenTelemetrySdk.java:31)
        at io.opentelemetry.example.autoconfigure.AutoConfigExample.main(AutoConfigExample.java:17)

Can we monitor JVM metrics like Heap, GC, Threads in OpenTelemetry agent?

Can we monitor JVM metrics like Heap, GC, Threads in OpenTelemetry agent?
I haven't found any example to configure the metrics in agent. I can see the traces and spans exported, But not JVM metrics.

[website_docs] Questions about "Getting started", and OTel website 404s for Java docs

Where's the "Getting started" page?

We're aiming for every language SIG to have a Getting started page. Java used to have one (see open-telemetry/opentelemetry-java#3070), but then open-telemetry/opentelemetry-java#3081 dropped it and another page:

• website_docs/getting_started.md was deleted
• website_docs/automatic_instrumentation.md was deleted

I'm seeing that QUICKSTART.md, now just a placeholder, directs readers to https://opentelemetry.io/docs/java/manual_instrumentation. Might manual_instrumentation be a suitable candidate for a Getting started page? If not, what do you suggest we do to get a Getting started page for OTel Java?

/cc @theletterf -- who is looking into the topic of Getting started pages.

Addressing top OTel website 404s for Java docs

As you can see from open-telemetry/opentelemetry.io#635, the top Java 404s are for the two files mentioned above that were deleted by open-telemetry/opentelemetry-java#3081. When a page is deleted, a redirect target needs to be chosen so that readers who still have a link to the page don't get a 404, page not found error.

So my question here is, what should the redirect target be for the following OTel website paths:

• /docs/java/automatic_instrumentation/?
• /docs/java/getting_started/?
  Note that if we recreate a Getting started page, then we won't need a redirect target.

/cc @austinlparker

Delete the gRPC example

Users should use gRPC library instrumentation and definitely not do manual instrumentation of gRPC. We do get confusion because of the example though.

open-telemetry/opentelemetry-java#3610 (comment)

IIRC, this isn't the first time - I don't think we should have this example since it's not an example of usage we would expect as we have the library instrumentation.

micrometer-shim ping exception

when call /ping in logs got exception:

2023-10-29 21:46:05.682 ERROR 15468 --- [nio-8080-exec-3] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Filter execution threw an exception] with root cause

java.lang.NoClassDefFoundError: io/opentelemetry/extension/incubator/metrics/HistogramAdviceConfigurer
	at io.opentelemetry.instrumentation.micrometer.v1_5.HistogramAdviceUtil.setExplicitBucketsIfConfigured(HistogramAdviceUtil.java:36) ~[opentelemetry-micrometer-1.5-1.28.0-alpha.jar:1.28.0-alpha]
	at io.opentelemetry.instrumentation.micrometer.v1_5.OpenTelemetryTimer.<init>(OpenTelemetryTimer.java:76) ~[opentelemetry-micrometer-1.5-1.28.0-alpha.jar:1.28.0-alpha]
	at io.opentelemetry.instrumentation.micrometer.v1_5.OpenTelemetryMeterRegistry.newTimer(OpenTelemetryMeterRegistry.java:112) ~[opentelemetry-micrometer-1.5-1.28.0-alpha.jar:1.28.0-alpha]
	at io.micrometer.core.instrument.MeterRegistry.lambda$timer$2(MeterRegistry.java:318) ~[micrometer-core-1.9.16.jar:1.9.16]
	at io.micrometer.core.instrument.MeterRegistry.getOrCreateMeter(MeterRegistry.java:618) ~[micrometer-core-1.9.16.jar:1.9.16]
	at io.micrometer.core.instrument.MeterRegistry.registerMeterIfNecessary(MeterRegistry.java:570) ~[micrometer-core-1.9.16.jar:1.9.16]
	at io.micrometer.core.instrument.MeterRegistry.timer(MeterRegistry.java:316) ~[micrometer-core-1.9.16.jar:1.9.16]
	at io.micrometer.core.instrument.Timer$Builder.register(Timer.java:400) ~[micrometer-core-1.9.16.jar:1.9.16]
	at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.getTimer(WebMvcMetricsFilter.java:163) ~[spring-boot-actuator-2.7.17.jar:2.7.17]
	at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.lambda$record$0(WebMvcMetricsFilter.java:139) ~[spring-boot-actuator-2.7.17.jar:2.7.17]
	at org.springframework.boot.actuate.metrics.AutoTimer.apply(AutoTimer.java:109) ~[spring-boot-actuator-2.7.17.jar:2.7.17]
	at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.record(WebMvcMetricsFilter.java:138) ~[spring-boot-actuator-2.7.17.jar:2.7.17]
	at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.doFilterInternal(WebMvcMetricsFilter.java:108) ~[spring-boot-actuator-2.7.17.jar:2.7.17]
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117) ~[spring-web-5.3.30.jar:5.3.30]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178) ~[tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153) ~[tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201) ~[spring-web-5.3.30.jar:5.3.30]
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117) ~[spring-web-5.3.30.jar:5.3.30]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178) ~[tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153) ~[tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:168) ~[tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:481) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:130) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:390) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:928) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1794) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-9.0.82.jar:9.0.82]
	at java.lang.Thread.run(Thread.java:748) [na:1.8.0_311]

In dependencies now opentelemetry-extension-incubator:1.30.0-alpha where there is no HistogramAdviceConfigurer but it has LongHistogramAdviceConfigurer and DoubleHistogramAdviceConfigurer

need fixes

Workflow failed: Update gradle wrappers (daily) (#9)

See Update gradle wrappers (daily) #9.

Report "Unrecognized option: --add-exports" when run ../gradlew bootJar --stacktrace

Java version:
openjdk version "1.8.0_362"
OpenJDK Runtime Environment (build 1.8.0_362-8u372-gaus1-0ubuntu120.04-b09)
OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)

issue:

• Exception is:
  org.gradle.api.GradleException: Unable to start the daemon process.
  This problem might be caused by incorrect configuration of the daemon.
  For example, an unrecognized jvm option is used.
  Please refer to the User Manual chapter on the daemon at https://docs.gradle.org/8.1.1/userguide/gradle_daemon.html
  Process command line: nice -n 10 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -XX:MaxMetaspaceSize=512m --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED -Dfile.encoding=UTF-8 -Duser.country -Duser.language=en -Duser.variant -cp /home/ubuntu/.gradle/wrapper/dists/gradle-8.1.1-bin/9wiye5v2saajue4irfo8ybqfp/gradle-8.1.1/lib/gradle-launcher-8.1.1.jar -javaagent:/home/ubuntu/.gradle/wrapper/dists/gradle-8.1.1-bin/9wiye5v2saajue4irfo8ybqfp/gradle-8.1.1/lib/agents/gradle-instrumentation-agent-8.1.1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 8.1.1
  Please read the following process output to find out more:

---

Unrecognized option: --add-exports
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

    at org.gradle.launcher.daemon.client.DaemonGreeter.parseDaemonOutput(DaemonGreeter.java:38)
    at org.gradle.launcher.daemon.client.DefaultDaemonStarter.startProcess(DefaultDaemonStarter.java:195)
    at org.gradle.launcher.daemon.client.DefaultDaemonStarter.startDaemon(DefaultDaemonStarter.java:151)
    at org.gradle.launcher.daemon.client.DefaultDaemonConnector.doStartDaemon(DefaultDaemonConnector.java:222)
    at org.gradle.launcher.daemon.client.DefaultDaemonConnector.startDaemon(DefaultDaemonConnector.java:216)
    at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:164)
    at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:99)
    at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:57)
    at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:167)
    at org.gradle.launcher.cli.DefaultCommandLineActionFactory$ParseAndBuildAction.execute(DefaultCommandLineActionFactory.java:259)
    at org.gradle.launcher.cli.DefaultCommandLineActionFactory$ParseAndBuildAction.execute(DefaultCommandLineActionFactory.java:230)
    at org.gradle.launcher.cli.DebugLoggerWarningAction.execute(DebugLoggerWarningAction.java:82)
    at org.gradle.launcher.cli.DebugLoggerWarningAction.execute(DebugLoggerWarningAction.java:30)
    at org.gradle.launcher.cli.WelcomeMessageAction.execute(WelcomeMessageAction.java:96)
    at org.gradle.launcher.cli.WelcomeMessageAction.execute(WelcomeMessageAction.java:40)
    at org.gradle.launcher.cli.NativeServicesInitializingAction.execute(NativeServicesInitializingAction.java:44)
    at org.gradle.launcher.cli.NativeServicesInitializingAction.execute(NativeServicesInitializingAction.java:26)
    at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:41)
    at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:26)
    at org.gradle.launcher.cli.DefaultCommandLineActionFactory$WithLogging.execute(DefaultCommandLineActionFactory.java:361)
    at org.gradle.launcher.Main.doAction(Main.java:35)
    at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:50)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60)
    at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.gradle.launcher.GradleMain.main(GradleMain.java:34)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:35)
    at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:110)
    at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:66)

IntelliJ breaks when :opentelemetry-examples-spring-native is included

I recently imported the project into IntelliJ and it fails with a cryptic error:

Commenting out the :opentelemetry-examples-spring-native module in settings.gradle works around this.

IntelliJ version:

gRPC server example: is `Contexts.interceptCall` necessary?

The gRPC server uses Context.interceptCall instead of directly calling next.startCall. (here).

Is this necessary, or spurious? Contexts.interceptCall will carefully attach and detach the gRPC context when each of its interface methods is called, but does nothing for the OTel context.

Help appreciated.

Use Renovate instead of Dependabot

My initial motivation was that Renovate handles gradle version updates as well as dependency updates, which would make our gradle version update automation unnecessary (which is not working well anyways because the PRs it opens aren't triggering CI actions without closing/re-opening the PR).

But also, I tried Renovate out on my fork of this repo, and it found several gradle dependency updates that dependabot wasn't finding: trask#11

A few other OpenTelemetry repos are using Renovate already, so it wouldn't require any new approvals (just need to ask TC to enable it on this repository).

Broken link in micrometer-shim README

The link to "micrometer1-shim" on the line This example demonstrates a typical use case of [micrometer1-shim](https://github.com/open-telemetry/opentelemetry-java/tree/main/micrometer1-shim). in the file micrometer-shim/README.md is broken. Looks like the folder was moved. I'd open a PR to fix it but i'm not 100% sure what it's supposed to link to now.

Thanks for all the work you guys do on open-telemetry!

Prometheus example does not show metrics on localhost:9090

Following the README of prometheus example does not show metrics on prometheus backend running on localhost:9090.

How to reproduce this issue

• Follow all steps in README as-is.

Environment information

• Linux
• Docker version 20.10.21

Observed state

• Application runs successfully upon running docker-compose up. ✅
• While application is running, the application metrics are visible at http://localhost:19090/metrics. ✅
• While application is running, the metrics in prometheus are not visible at http://localhost:9090/metrics. ❌
  • http://localhost:9090/metrics fail to connect.

Expected state

• Prometheus metrics should be visible at localhost:9090.

Underlying Cause

The underlying cause for this was a permissions issue -

open /etc/prometheus/prometheus.yml: permission denied

[Contribution idea] Example showing telemetry integration testing

I would like to propose a contribution of a java code example that shows telemetry integration testing with MockServer library.
This example could help users with testing their mission critical telemetry data in applications that use OpenTelemetry Agent.

Here’s the draft code Pull Request showing the integration testing approach.
The OpenTelemetry java agent is configured to use the OTLP exporter with http/protobuf protocol and uses the default exporter endpoint which is http://localhost:4318/. The telemetry collector web server is mocked with this endpoint using MockServer library. With MockServer library we can easily retrieve the recorded requests from the mocked collector and verify the traces and metrics.

Do you think such an example would be useful in opentelemetry-java-docs? Happy to hear your thoughts on this.

Add link to opentelemetry.io under About section

Under the About section of this repo (which you can access from the main repo page -- click the gear icon next to the About title):

• Under Website, add https://opentelemetry.io

We're looking to do this uniformly for all OTel org repos.

For example:

OTEL_EXPORTER_OTLP_HEADERS is not support by opentelemetry-spring-boot-starter

Hello,

OTEL_EXPORTER_OTLP_HEADERS is not support by
opentelemetry-spring-boot-starter 1.32.0-alpha

I've tryed with environment variable
OTEL_EXPORTER_OTLP_HEADERS=api-key=xxx
and vm option
-Dotel.exporter.otlp.headers=api-key=xxx

With both got this error:
Failed to export metrics. Server responded with gRPC status code 16. Error message:

Dependencyes
<dependencyManagement> <dependencies> <dependency> <groupId>io.opentelemetry</groupId> <artifactId>opentelemetry-bom</artifactId> <version>1.34.0</version> <type>pom</type> </dependency> <dependency> <groupId>io.opentelemetry.instrumentation</groupId> <artifactId>opentelemetry-instrumentation-bom-alpha</artifactId> <version>1.32.0-alpha</version> <type>pom</type> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>io.opentelemetry.instrumentation</groupId> <artifactId>opentelemetry-spring-boot-starter</artifactId> </dependency> </dependencies>

only custom logger appender on collector

In log-appender example after running Application I found only custom appender logs in collectors logs.
Log4j, logback and also JUL logs lost.

Looks like lost setup of OpenTelemetryAppender because all work fine after adding follow code after initializeOpenTelemetry(); (https://github.com/open-telemetry/opentelemetry-java-examples/blob/main/log-appender/src/main/java/io/opentelemetry/example/logappender/Application.java#L35)

    io.opentelemetry.instrumentation.log4j.appender.v2_17.OpenTelemetryAppender.install(GlobalOpenTelemetry.get());
    io.opentelemetry.instrumentation.logback.appender.v1_0.OpenTelemetryAppender.install(GlobalOpenTelemetry.get());

Java metrics examples should use AutoConfiguredOpenTelemetrySdk

Right now the examples just use the GlobalOpenTelemetry instance, which might be noop unless a system property is set. To keep things simple, we might want to just use the AutoConfiguredOpenTelemetrySdk instead. This is probably what most users want anyway.

How to capture traceId , spanId in console logs while using the logback appender

We want to have trace information in console logs also as it is successfully appending over to OTEL.

1. pom.xml

<dependency> <groupId>io.opentelemetry.instrumentation</groupId> <artifactId>opentelemetry-logback-appender-1.0</artifactId> <version>1.30.0-alpha</version> </dependency>

`logback.xml

<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
        <pattern>
            %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} trace_id: %X{trace_id} span_id: %X{span_id} - %msg%n
        </pattern>
    </encoder>
</appender>
<appender name="OpenTelemetry"
          class="io.opentelemetry.instrumentation.logback.appender.v1_0.OpenTelemetryAppender">
    <captureExperimentalAttributes>false</captureExperimentalAttributes>
    <captureCodeAttributes>true</captureCodeAttributes>
    <captureMarkerAttribute>true</captureMarkerAttribute>
    <captureMdcAttributes>*</captureMdcAttributes>
</appender>

<root level="INFO">
    <appender-ref ref="console"/>
    <appender-ref ref="OpenTelemetry"/>
</root>

`

`code -

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

private static final Logger LOGGER = LogManager.getLogger(Controller.class);
LOGGER.info(String.format("*** Entered adapter service ***"));
`

console log output - 16:21:05.139 [http-nio-8080-exec-2] INFO c.i.i.f.i.c.Controller trace_id: span_id: - *** Entered adapter service ***

Manual Instrumentation of gRPC example does not seem to work.

The example being discussed is listed here.

The Issue

The example contained 2 programs - server and the client. While the server ran successfully and showed to be listening for requests on port 50051. The client program was not able to connect to it following the steps in the Readme for the example.

Both the server and the client were running on the same machine. When attempting the client to run using -

java -cp ./build/libs/opentelemetry-examples-grpc-0.1.0-SNAPSHOT-all.jar io.opentelemetry.example.grpc.HelloWorldClient

The following error was displayed -

WARNING: RPC failed: Status{code=UNAVAILABLE, description=io exception, cause=io.grpc.netty.shaded.io.netty.channel.AbstractChannel$AnnotatedConnectException: connect(..) failed: Invalid argument: /localhost:50051
Caused by: java.net.ConnectException: connect(..) failed: Invalid argument

Changes required to run the example

Switching up the grpc and protobuf libraries in the root build.gradle, finally worked. The solution was inspired by the accepted answer in this StackOverflow post.

The protoc, protobuf and the grpc library versions have to be compatible with each other. The compatibility matrix is listed on this gRPC project's GItHub README.

I used the latest versions listed on this page, though there have been more recent releases for both these libraries. These versions were -

1. grpc v1.30.0
2. protobuf v3.12.2

Other Information -

• The example was attempted on a machine running Java version 11.0.3 & Gradle version 7.5
• Compilation for both client and server was successful.
• There were 2 clients in the example - normal and streamed, both of them initially showed the same error and both of them started working after applying the change mentioned above.
• When run through an IDE the example ran successfully without making the changes mentioned above
  • The IDE used was IntelliJ UE.
  • The run configuration involved using gradle's compileJava task.
  • The run configuration for running the Java client and server remained similar to what is shown in the README for the original example.