[
https://issues.apache.org/jira/browse/CAMEL-24051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095893#comment-18095893
]
Claus Ibsen commented on CAMEL-24051:
-------------------------------------
There is already camel-test-infra-jaeger/
And you have camel tui that has a otel spans tab that can show your tracing
directly in the tui, or you can use jaeger already.
So please take a closer look before doing more
> camel-test-infra: add an "observability" service (Grafana/Tempo/Loki
> OTel-LGTM stack) for local dev and E2E, mirroring OpenShift's observability
> stack
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24051
> URL: https://issues.apache.org/jira/browse/CAMEL-24051
> Project: Camel
> Issue Type: New Feature
> Components: test-infra
> Reporter: Federico Mariani
> Assignee: Federico Mariani
> Priority: Major
>
> h3. Problem / Motivation
> Camel's local dev loop ({{camel run --dev}}) and the Kubernetes export path
> already wire up {{camel-observability-services}} (Micrometer/Prometheus
> metrics, health checks, OpenTelemetry tracing) when targeting
> Kubernetes/OpenShift. However, there is no local backend to receive or
> visualize that telemetry: {{camel infra run}} can start backing services like
> Postgres or Artemis, but nothing analogous exists for observability.
> As a result, developers only find out whether traces, metrics, and logs
> actually work correctly (correct span correlation, meaningful dashboards,
> sane metric cardinality, etc.) once the application is deployed to a real
> OpenShift cluster, which typically provides the Red Hat build of
> OpenTelemetry, the Tempo Operator, Loki/OpenShift Logging, and the Cluster
> Observability Operator (Grafana). Telemetry problems surface late, in a
> shared cluster environment, rather than at dev/E2E time on a laptop or in CI.
> h3. Proposed Solution
> Add a new {{camel-test-infra}} service, invocable as {{camel infra run
> observability}} (same UX as the existing {{camel infra run postgres}} /
> {{camel infra run artemis}} services), that starts a local all-in-one
> observability stack via Testcontainers -- for example the
> {{grafana/otel-lgtm}} image, which bundles an OTel collector plus Prometheus,
> Tempo, Loki, and Grafana.
> The service should be wired to the same OTLP endpoint / ports / paths that
> {{camel-observability-services}} already exports (metrics, health, tracing),
> so that the dashboards, traces, and logs a developer sees locally when
> running {{camel run --dev}} against this service are the same shape as what
> they will see after deploying to OpenShift. This closes the
> local-vs-production observability gap and gives a fast, zero-cluster feedback
> loop for validating telemetry during the inner dev loop and in E2E test
> workflows.
> h3. Scope
> * New test-infra module/service following the existing test-infra patterns
> (e.g. an {{*InfraService}}, {{*LocalContainerService}}, and
> {{*ServiceFactory}} for the {{grafana/otel-lgtm}} container).
> * Wire the new service into the {{camel-jbang-core}} {{infra}} command so
> {{camel infra run observability}} works like other {{camel infra run
> <service>}} commands.
> * Out of scope for this ticket: any changes to
> {{camel-observability-services}} itself, and cluster-side
> OpenShift/Kubernetes tooling (traits, {{camel kubernetes doctor}},
> PodMonitor/PrometheusRule generation) -- those are separate, larger efforts.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
