Red Hat Summit이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 107. Observability Services
The Camel Observability Services component provides a set of opinionated components and configuration which simplify operations such as observability on cloud environments. Although the component is mainly targeted for cloud, it can be used in any other environment, giving to the Camel application the ability to expose a set of observability features by default.
107.1. Dependencies
When using camel-observability-services with Red Hat build of Camel Spring Boot, add the following Maven dependency to your pom.xml to have support for auto configuration:
<dependency>
<groupId>org.apache.camel.springboot</groupId>
<artifactId>camel-observability-services-starter</artifactId>
</dependency>107.2. Usage
107.2.1. Auto-detection from classpath
All you need to do is to add the camel-observability-services dependency to the classpath. There’s no need to add any further configuration. Each component will be configured using each own default setting, except the endpoint which will be exposed in /observe/<service> by default.
If you need to customize each of the different components provided within this service, then, you can specify in the application.properties each of the configuration as it would be done normally when you provide the individual component.
NOTE: The customization of the configuration for this component is not available for Spring Boot runtime due to a known limitation. You can use this component in Spring Boot runtime with the default settings only. If you need to provide any customization, you’ll need to configure each component separately.
107.3. Components available
The presence of this dependency will provide the following components:
- camel-health
- camel-management
- camel-micrometer-prometheus
- camel-opentelemetry
107.3.1. List of known endpoints
The presence of this dependency will expose the following endpoints:
| Endpoint | Description |
|---|---|
|
| startup probe endpoint |
|
| liveness probe endpoint |
|
| readiness probe endpoint |
|
| metrics exposed as in Micrometer Prometheus Registry |
107.4. OpenTelemetry configuration
The presence of this component will provide the required instrumentation to easily enable the collection of OpenTelemetry metrics.
107.4.1. Testing OpenTelemetry collector
If you need a quick way to verify the configuration of OpenTelemetry traces, you can start a local collector by running a Docker service:
docker run -p 4318:4318 otel/opentelemetry-collector-contrib:0.113.0
This service will expose the port 4318 to localhost which is the default setting expected by the agent. You can change this configuration accordingly.
107.4.2. OpenTelemetry Agent configuration
To collect the metrics exposed by the application, and, depending on the runtime of choice, you will need to start your Camel application with a Java agent. The Java agent goal is to push those metrics to the OpenTelemetry compatible collector server. Follow the instructions provided in OpenTelemetry Java Agent configuration.
NOTE: Due to a flaw in the alignment of OpenTelemetry dependencies in Spring Boot runtime, you may hit a runtime error until the Spring Boot BOM dependencies is aligning the OpenTelemetry dependencies. Be mindful of the required workaround required for this to work until the issue is fixed.
107.5. JMX configuration
The presence of this component implies the presence of camel-management component. This is in charge to include information about Camel application status in JMX format.
NOTE: The presence of this component automatically enables the collection of the JMX metrics. This should be negligible from performance point of view. However, you may want to disable that running the application with -Dorg.apache.camel.jmx.disabled=true JVM option.
107.5.1. Testing JMX
An easy way to test the JMX configuration is to run a JMX client such as jconsole. Execute it from the same machine where the Camel application you want to monitor is running, and you can quickly verify the status of the application (selecting the local process). There is the possibility to expose the JMX remotely as well.
Exposing remote JMX would require some security setting in place to avoid disclosing sensitive information. Also mind that it may not be suitable for cloud development, i.e., Kubernetes, due to possible limitations within the binary protocols used by the JMX technology. In this case, it is recommended the usage of a JSR 160 compatible Java agent.
107.5.2. JMX Agent configuration
When dealing with JMX, you may want to expose the information available via HTTP(S) protocol which would make JMX more suitable to cloud-based development. A possible way to expose the information is to use a JSR 160 compatible Java agent, whose goal is to interact as an adapter interface towards JMX, exposing an HTTP-based service instead. Follow the instructions provided in JMX Java Agent configuration .
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}