debezium/dbz#1897 Add support for exposing Pipelines metrics to Prometheus via OTel Collector#409
debezium/dbz#1897 Add support for exposing Pipelines metrics to Prometheus via OTel Collector#409mfvitale wants to merge 6 commits into
Conversation
…theus via OTel Collector Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
| } | ||
|
|
||
| private Runtime createRuntime() { | ||
| var metricsBuilder = new MetricsBuilder() |
There was a problem hiding this comment.
Could you refactor with a strategy this portion of code?
There was a problem hiding this comment.
I think we should keep it as it's generally a good idea to show what the UI looks like in the readme.
There was a problem hiding this comment.
Good catch. I forget to update the "updated" image with also the "Connections"
| 4. [Optional] PostgreSQL database used by conductor to store its data. | ||
| 5. [Optional] Strimzi operator: operator for creating Kakfa cluster. In case you want to use a Kafka destination in you | ||
| pipeline. | ||
| 6. OpenTelemetry Operator: manages the OpenTelemetry Collector used for pipeline monitoring. |
There was a problem hiding this comment.
Suggestion (non-blocking): Just to make it super clear:
When monitoring is enabled, the chart also creates:
1. An `OpenTelemetryCollector` custom resource, which requires the OpenTelemetry Operator to already be installed.
2. [Optional] A `ServiceMonitor`, which requires the Prometheus Operator to already be installed.
There was a problem hiding this comment.
@pxcamus Isn't this covered in the Monitoring section below?
There was a problem hiding this comment.
Yes, it was just to reinforce, since people (me included) tend to skim the README.
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
| * via CDI and applies them based on their applicability. | ||
| */ | ||
| @ApplicationScoped | ||
| public class MetricsExporterStrategyManager { |
There was a problem hiding this comment.
instead of using this class, you could use a jakarta producer that generate the MetricsExporterStrategy based on configuration/input parameter. You will have only one bean and you can use directly in PipelineMapper.
I think also that you can use an implicit strategy which generate directly the Runtime.
There was a problem hiding this comment.
Only one point here. At the end, when the full implementation will be completed ( FE part too), there will be only the OTel enabled on the Platform and no more. Do you think improving this still make sense?
In any case I'll investigate the producer way.
There was a problem hiding this comment.
instead of using this class, you could use a jakarta producer that generate the MetricsExporterStrategy based on configuration/input parameter. You will have only one bean and you can use directly in PipelineMapper
Currently both strategy are active at the same time. Is this something doable with the producer?
There was a problem hiding this comment.
Only one point here. At the end, when the full implementation will be completed ( FE part too), there will be only the OTel enabled on the Platform and no more. Do you think improving this still make sense?
In any case I'll investigate the
producerway.
With this in mind, I think it's worth to investigate the creation with a producer of Runtime or a class that handle the Runtime. In this way when you have to remove the code, you don't have to touch the pipeline but the jakarta producer
There was a problem hiding this comment.
I used the producer to create the Metrics object.
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
6 participants
Fixes debezium/dbz#1897
Description
Add built-in monitoring support to the Debezium Platform using OpenTelemetry and Prometheus
monitoring.otel.enabled: true), the Helm chart deploys anOpenTelemetryCollectorCR and optionally aServiceMonitorfor Prometheus integrationCollector → Prometheus
Helm chart changes
OpenTelemetryCollectorCR template with configurable receivers (OTLP gRPC/HTTP), batch processor, and Prometheus exporterServiceMonitortemplate for automatic Prometheus scrapingPIPELINE_MONITORING_OTEL_ENABLED,PIPELINE_MONITORING_OTEL_ENDPOINT) injected into the conductor deployment when monitoring is enabledNOTES.txt,values.schema.json, and documentationConductor changes
MonitoringConfigGroupconfig interface for OTel settingsPipelineMapper.createRuntime()conditionally enables OpenTelemetry on the DebeziumServer CRD with a configurable collector endpoint (defaults tohttp://localhost:4318)Why the OTel Operator and Prometheus Operator are not included as subcharts
The OTel Operator was initially included as a subchart dependency but removed due to the following reasons:
(unable to build kubernetes objects from current release manifest: resource mapping not found for name helm/helm#11120)). The OTel Operator chart uses templated CRDs (in
templates/rather thancrds/), so on helm install theOpenTelemetryCollectorCRD is not yet registered when Helm tries to validate the collector CR, causing the resource mapping to fail. Unlike the Debezium Operator which places CRDs incrds/(processed first by Helm), there is no workaround that doesn't involve multiple install steps.
Instead, the chart creates only the CRs (OpenTelemetryCollector, ServiceMonitor) and documents the operators as prerequisites.
PR Checklist
main