quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.36k stars 2.56k forks source link

Automatically start `observability-devservices-lgtm` by default with `quarkus-opentelemetry` extension #40878

Open The-Huginn opened 1 month ago

The-Huginn commented 1 month ago

Description

Similarly to other devservices, we should start it by default with the extension added. So the user can simply start the quarkus app without adding a different extension for the observability devservices. For example as is done with OIDC, where we start a keycloak devservices.

However, I am not sure, whether quarkus wants to move away from this approach. Let me know, what you think of this idea. I would like to take a look into it if you would agree with it.

Implementation ideas

No response

quarkus-bot[bot] commented 1 month ago

/cc @brunobat (opentelemetry), @geoand (devservices), @radcortez (opentelemetry), @stuartwdouglas (devservices)

alesj commented 1 month ago

Imho this should work if you simply add io.quarkus:quarkus-observability-devservices-lgtm as a dependency to quarkus-opentelemetry ...

The-Huginn commented 1 month ago

@alesj Yes it absolutely does. However, it would be nicer to have it ran without adding new extension, such as with oidc or kafka I believe. @xstefank might want to add a comment as well.

edit: Or do you mean adding quarkus-observability-devservices-lgtm to quarkus-opentelemetry's pom.xml, i.e. into runtime module's dependencies?

alesj commented 1 month ago

Yes, to your edit. Imho, that should work.

The-Huginn commented 1 month ago

That fails with following message, probably due to incorrect order of starting deployments "Could not expand value quarkus.otel-collector.url in property quarkus.otel.exporter.otlp.traces.endpoint"

I have updated the resource a little bit, so it works correctly. However, the problem still remains in the fact, that you would not be able to stop this devservice from starting via opentelemetry extension properties, but you would need to disable it in observability-devservices. And the main issue is, that if you would like to create your own devservices stack using observability-devservices, you would not be able to switch off observability-devservices-lgtm, as it would be included in opentelemetry by default. Currently, you would just remove observability-devservices-lgtm from dependencies and include your own.

I suppose, you could use <exclusion> in your dependencies to exclude observability-devservices-lgtm from opentelemetry. This seems to work, when I tried it in local.

I am not sure, if this makes sense.

edit: Here is my branch, to what I did. I would need to update IT and docs (with the exclusion of dependency), if you think this is a correct way.

xstefank commented 3 weeks ago

Is the runtime module actual correct place where to pull devservices? Won't it be then always included in packaged artifacts?

alesj commented 2 weeks ago

Is the runtime module actual correct place where to pull devservices? Won't it be then always included in packaged artifacts?

See 2nd note:

maxandersen commented 2 weeks ago

For the lazy. The trick is that it's in provided scope.

So I'm not sure we can do this automatically?

maxandersen commented 2 weeks ago

Ie. Provided isn't transitive afaik.

brunobat commented 2 weeks ago

I think we could ship it by default. Feel free to send a PR.