OpenLiberty/open-liberty

BETA BLOG - Provide a way to send Liberty metrics to OpenTelemetry

Opened this issue · 0 comments

The information you provide here will be included in the Open Liberty beta blog post (example), which will be published on openliberty.io/blog/, and potentially elsewhere, to promote this beta feature/function of Open Liberty. For this post to be included in the beta issue please make sure that this is completed by the end of Friday following the GM (Tuesday). The beta and release blogs are created using automation and rely on you following the template's structure. DO NOT REMOVE/ALTER THE <GHA> TAGS THROUGHOUT THIS TEMPLATE.

Epic: #23337

<GHA-BLOG-SUMMARY>

Please provide a summary of the update, including the following points:

  • A sentence or two that introduces the update to someone new to the general technology/concept.

As part of this beta release, the OpenLiberty server will now be able to forward runtime component statistics captured by monitor-1.0 to the MP Telemetry 2.0 runtime (mpTelemetry-2.0 feature). The supported runtime components are: ThreadPool, Sessions, RequestTiming and Connection pools. This statistical data will be registered as metrics in the telemetry runtime and can then be forwarded to any OTLP compatible metric consumer to meet your monitoring needs.

  • The Human-readable name and short feature name for your feature- eg WebSockets feature (websockets-1.0).

mpTelemetry-2.0 auto starts monitor-1.0. NO additional feature configuration besides enabling the supported runtime components.

  • Who is the target persona? Who do you expect to use the update? eg application developer, operations.

Operations team to track the runtime statistics/metrics from the Open Liberty server when running.

  • What was the problem before and how does your update make their life better? (Why should they care?)

mpTelmetry-2.0 did not provide metric data from the OpenLiberty runtime components.

  • Briefly explain how to make your update work. Include screenshots, diagrams, and/or code snippets, and provide a server.xml snippet.

No configuration needed. This essentially relies on monitor-1.0 behavior of how to capture stats. You will need to have mpTelemetry-2.0 runtime active (which will start monitor-1.0). The associated runtime component's feature would need to be enabled too to have monitor-1.0 be able to process/track statistics. For example, ConnectionPool would require the following:

    <featureManager>
        <feature>mpTelemetry-2.0</feature>
    	<feature>jdbc-4.3</feature>
    </featureManager>
  • Where can they find out more about this specific update (eg Open Liberty docs, Javadoc) and/or the wider technology?

n/a

</GHA-BLOG-SUMMARY>

What happens next?

  • Add the label to the blog issue for the beta you're targeting (e.g. target:YY00X-beta).
  • Make sure this blog post is linked back to the Epic for this feature/function.
  • Your paragraph will be included in the beta blog post. It might be edited for style and consistency.
  • You will be asked to review a draft before publication.
    • Once you've approved the code review, close this issue.
  • If you would also like to write a standalone blog post about your update (highly recommended), raise an issue on the Open Liberty blogs repo. State in the issue that the blog post relates to a specific release so that we can ensure it is published on an appropriate date (it won't be the same day as the beta blog post).