Observability Dev Services
We are already familiar with Dev Service concept, but in the case of Observability we need a way to orchestrate and connect more than a single Dev Service, usually a whole stack of them; e.g. a metrics agent periodically scraping application for metrics, pushing them into timeseries database, and Grafana feeding graphs of this timeseries data.
With this in mind, we added a new concept of Dev Resource, an adapter between Dev Service concept and Testcontainers. And since we now have fine-grained services - with the Dev Resource per container, we can take this even further, allowing the user to choose the way to use this new Dev Resource concept:
Each Dev Resource implementation is an @QuarkusTestResourceLifecycleManager implementation as well
|
-
leave it to Dev Services to pick-up various Dev Resources from classpath, and apply Dev Service concept to it
-
explicitly disable Dev Services and enable Dev Resources and use less-heavy concept of starting and stopping Dev Resources
-
explicitly disable both Dev Services and Dev Resources, and use Quarkus'
@QuarkusTestResource
testing concept (see Note)
You can either add Observability extension dependency along with needed Dev Resources dependencies, or you use existing sinks
- pom.xml files which add Observability extension dependency along with other required dependencies for certain technology stacks; e.g. victoriametrics
sink would have quarkus-observability-devresource-victoriametrics
and quarkus-victoriametrics-client
dependencies already included in the pom.xml
.
Make sure you set the
|
Let’s see how all of this looks in practice, with the usual all-in-one
Grafana usage, in the form of OTel-LGTM Docker image.