The Maven OpenTelemetry extension integration provides comprehensive visibility into all of your Maven builds. The extension generates traces for each build and performance metrics to help you understand which Maven goals or Maven submodules are run the most, how often they fail, and how long they take to complete.
The context propagation from CI pipelines (Jenkins job or pipeline) is passed to the Maven build through theTRACEPARENT andTRACESTATE environment variables that match theW3C Trace Context specification . Therefore, everything that happens in the CI platform is also shown in the traces.
You can configure your Maven project with theMaven OpenTelemetry extension . For example, you can add the following snippet to your pom.xml file:
<project> ... <build> <extensions> <extension> <groupId>io.opentelemetry.contrib</groupId> <artifactId>opentelemetry-maven-extension</artifactId> <version>1.12.0-alpha</version> </extension> </extensions> </build></project>You can now trigger to send the Maven build reporting performance data to Elastic Observability by passing the configuration details as environment variables:
export OTEL_EXPORTER_OTLP_ENDPOINT="https://elastic-apm-server.example.com:8200"export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer an_apm_secret_token"export OTEL_TRACES_EXPORTER="otlp"mvn verifyYou can instrument Maven builds without modifying the pom.xml file using the Maven command line argument “-Dmaven.ext.class.path=…”
export OTEL_EXPORTER_OTLP_ENDPOINT="https://elastic-apm-server.example.com:8200"export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer an_apm_secret_token"export OTEL_TRACES_EXPORTER="otlp"mvn -Dmaven.ext.class.path=path/to/opentelemetry-maven-extension.jar verifyYou can also trigger your Maven builds from the CI platform and visualize the end-to-end pipeline execution in Elastic Observability, including the detailed steps of your CI pipeline and the Maven build.
When invoking Maven builds with Jenkins, it’s unnecessary to use environment variables to configure the Maven build (OTEL_EXPORTER_OTLP_ENDPOINT…) to rely on the Jenkins capability to inject OpenTelemetry configuration as environment variables. For more details, refer toInstall the OpenTelemetry plugin .
To learn more, see theintegration of Maven builds with Elastic Observability .
The Ansible OpenTelemetry plugin integration provides visibility into all your Ansible playbooks. The plugin generates traces for each run and performance metrics to help you understand which Ansible tasks or roles are run the most, how often they fail, and how long they take to complete.
You can configure your Ansible playbooks with theAnsible OpenTelemetry callback plugin . It’s required to install the OpenTelemetry python libraries and configure the callback as stated in theexamples section.
The context propagation from the Jenkins job or pipeline is passed to the Ansible run. Therefore, everything that happens in the CI is also shown in the traces.
This integration feeds, out of the box, the Service Map with all the services that are connected to the Ansible Playbook. All of these features can help you quickly and visually assess your services used in your provisioning and Continuous Deployment.
The Ansible OpenTelemetry plugin integration supports Ansible AWX/Tower. To enable it, follow these steps.
AWX requires an Execution Environment with the Ansible and Python packages installed. You can use theAnsible Builder CLI tool to create the container definition. Then upload the container to an image repository accessible by AWX and define an Execution Environment using the container you created.
To inject the environment variables and service details, use custom credential types and assign the credentials to the Playbook template. This gives you the flexibility to reuse the endpoint details for Elastic APM and also standardize on custom fields for reporting purposes.
Want to learn more? Thisblog post provides a great overview of how all of these pieces work together.
otel-cli is a command-line tool for sending OpenTelemetry traces, which is useful if instrumenting your scripts explicitly when no other implicit integration is in place.
Using the otel-cli wrapper, you can configure your build scripts implemented in shell, make, or another scripting language. For example, instrumenting the Makefile below with otel-cli helps visualize every command in each goal as spans.
# see https://blog.container-solutions.com/tagging-docker-images-the-right-wayNAME := acmecorp/fooTAG := $$(git log -1 --pretty=%!H(MISSING))IMG := ${NAME}:${TAG}LATEST := ${NAME}:latestbuild: @otel-cli exec \ --name 'docker build' \ docker build -t ${IMG} . @otel-cli exec \ --name 'docker tag' \ docker tag ${IMG} ${LATEST}push: @otel-cli exec \ --name 'docker push' \ --attrs "http.url=https://docker.elastic.dev" \ docker push ${NAME}login: @otel-cli exec \ --name 'docker login' \ --attrs 'rpc.system=grpc' \ docker login -u ${DOCKER_USER} -p ${DOCKER_PASS}To invoke shell scripts that use otel-cli for tracing:
export OTEL_EXPORTER_OTLP_ENDPOINT="elastic-apm-server.example.com:8200"export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer an_apm_secret_token"export OTEL_TRACES_EXPORTER="otlp"make login build pushpytest-otel is a pytest plugin for sending Python test results as OpenTelemetry traces. The test traces help you understand test execution, detect bottlenecks, and compare test executions across time to detect misbehavior and issues.
The context propagation from CI pipelines (Jenkins job or pipeline) is passed to the Maven build through theTRACEPARENT.
OTEL_EXPORTER_OTLP_ENDPOINT=https://elastic-apm-server.example.com:8200 \OTEL_EXPORTER_OTLP_HEADERS="authorization=Bearer an_apm_secret_token" \OTEL_SERVICE_NAME=pytest_otel \pytest --otel-session-name='My_Test_cases'To configure Concourse CI to send traces, refer to thetracing docs. In the Concourse configuration, you just need to defineCONCOURSE_TRACING_OTLP_ADDRESS andCONCOURSE_TRACING_OTLP_HEADERS.
CONCOURSE_TRACING_OTLP_ADDRESS=elastic-apm-server.example.com:8200CONCOURSE_TRACING_OTLP_HEADERS=Authorization=Bearer your-secret-tokenContext propagation is supported; therefore, you can benefit from the integrations described above.
Once Concourse CI tracing is configured, Concourse CI pipeline executions are reported in Elastic Observability.
The Concourse CI doesn’t report health metrics through OpenTelemetry. However, you can use theOpenTelemetry Collector Span Metrics Processor to derive pipeline execution traces into KPI metrics like throughput and the error rate of pipelines.
Integrating automated service health checks in deployment pipelines is critical for end-to-end deployment automation, which crucially enables deployment frequency to be increased.
Elastic Observability exposes HTTP APIs to check the health of services. You can integrate these APIs in deployment pipelines to verify the behavior of newly deployed instances, and either automatically continue the deployments or roll back according to the health status.
The following example shows a canary deployment pipeline that leverages Elastic health check HTTP APIs to automate the quality check before rolling out the deployment from the canary to the entire set of instances:
Perform the health check by invoking theKIBANA_URL/internal/apm/services API to compare the transaction error rate of the service on the newly deployed instances with a threshold value. Pass the following parameters to the invocation:
start andend: time interval using theISO-8601 format (e.g. "2021-09-01T13:24:12Z" which is a UTC time)kuery: used to filter on the service name and, for example, the new version being deployed to narrow down to the canary instances. Exampleservice.name:"MY_SERVICE_NAME" AND service.version:"1.2.3"environment: the environment on which the canary instances are deployed. Example:production.To define the time range, use thestart andend parameters. These parameters are dates in ISO-8601 format. To query only one service, compose a filter in the parameterkuery, then filter by the service name using the expressionservice.name:MY_SERVICE_NAME and service.version: SERVICE_VERSION. Finally apply anenvironment filter by passing theenvironment parameter. To select all environments, useENVIRONMENT_ALL.
The API call requires authentication. We recommend to use an API Token to authenticate.
The API is subject to changes and a stable API optimized for Continuous Delivery use cases will soon be published.
def check_service_health(service_name, service_version, error_rate_threshold, kibana_url, api_token): now = datetime.now() five_minutes_ago = now - timedelta(minutes=5) params = { "start": five_minutes_ago.strftime("%Y-%m-%dT%H:%M:%SZ"), "end": now.strftime("%Y-%m-%dT%H:%M:%SZ"), "kuery": "service.name:{} and service.version:{}".format(service_name, service_version), "environment": "ENVIRONMENT_ALL" } url = "{}/internal/apm/services?{}".format(kibana_url, urllib.parse.urlencode(params)) req = urllib.request.Request(url=url, headers={"Authorization": "Bearer {}".format(api_token)}) with urllib.request.urlopen(req) as response: body = response.read().decode("utf8") obj = json.loads(body) if len(obj['items']) > 0 and obj['items'][0].transactionErrorRate > error_rate_threshold: raise Exception("Error rate for service {} is higher than threshold {}, current value is {}".format(service_name, error_rate_threshold, obj['items'][0].transactionErrorRate))© 2026 Elasticsearch B.V. All Rights Reserved.
This content is available in different formats for convenience only. All original licensing terms apply.
Elasticsearch is a trademark of Elasticsearch B.V., registered in the U.S. and in other countries. Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.
ページ先頭 
