avoid JVM metric conflicts with explicit cast#244151
Merged
SylvainJuge merged 5 commits intoelastic:mainfrom Dec 10, 2025
Merged
avoid JVM metric conflicts with explicit cast#244151SylvainJuge merged 5 commits intoelastic:mainfrom
SylvainJuge merged 5 commits intoelastic:mainfrom
Conversation
Contributor
|
Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services) |
jbudz
approved these changes
Nov 25, 2025
Contributor
|
Pinging @elastic/obs-presentation-team (Team:obs-presentation) |
jennypavlova
approved these changes
Dec 4, 2025
Member
jennypavlova
left a comment
There was a problem hiding this comment.
LGTM, just one question ⬇️
rmyz
approved these changes
Dec 10, 2025
Contributor
|
Starting backport for target branches: 9.2 |
Contributor
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Async chunks
History
cc @SylvainJuge |
kibanamachine
added a commit
to kibanamachine/kibana
that referenced
this pull request
Dec 10, 2025
In JVM runtime metrics, when micrometer is used in the application, the following metrics are also produced by micrometer, which creates a conflict with the OpenTelemetry metrics that are produced with the instrumentation agent (EDOT and upstream). Adding a proper cast allows to work-around this issue for metrics where this issue is known to happen, for now two metrics are impacted: - `jvm.memory.used` - `jvm.memory.committed` The only change applied by this PR is adding an explicit type cast `::long` to those metrics when they are referenced in ES|QL queries. Reviewing this PR can be done by using `git diff --color-words` to highlight the changes. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 77b5c55)
Contributor
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
kibanamachine
added a commit
that referenced
this pull request
Dec 10, 2025
# Backport This will backport the following commits from `main` to `9.2`: - [avoid JVM metric conflicts with explicit cast (#244151)](#244151) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"SylvainJuge","email":"763082+SylvainJuge@users.noreply.github.com"},"sourceCommit":{"committedDate":"2025-12-10T11:20:08Z","message":"avoid JVM metric conflicts with explicit cast (#244151)\n\nIn JVM runtime metrics, when micrometer is used in the application, the\nfollowing metrics are also produced by micrometer, which creates a\nconflict with the OpenTelemetry metrics that are produced with the\ninstrumentation agent (EDOT and upstream).\n\nAdding a proper cast allows to work-around this issue for metrics where\nthis issue is known to happen, for now two metrics are impacted:\n- `jvm.memory.used`\n- `jvm.memory.committed`\n\nThe only change applied by this PR is adding an explicit type cast\n`::long` to those metrics when they are referenced in ES|QL queries.\nReviewing this PR can be done by using `git diff --color-words` to\nhighlight the changes.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"77b5c5570f56f1c0c13154825ceebc3728ba6c44","branchLabelMapping":{"^v9.3.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","backport:version","v9.3.0","Team:obs-presentation","v9.2.3"],"title":"avoid JVM metric conflicts with explicit cast","number":244151,"url":"https://github.com/elastic/kibana/pull/244151","mergeCommit":{"message":"avoid JVM metric conflicts with explicit cast (#244151)\n\nIn JVM runtime metrics, when micrometer is used in the application, the\nfollowing metrics are also produced by micrometer, which creates a\nconflict with the OpenTelemetry metrics that are produced with the\ninstrumentation agent (EDOT and upstream).\n\nAdding a proper cast allows to work-around this issue for metrics where\nthis issue is known to happen, for now two metrics are impacted:\n- `jvm.memory.used`\n- `jvm.memory.committed`\n\nThe only change applied by this PR is adding an explicit type cast\n`::long` to those metrics when they are referenced in ES|QL queries.\nReviewing this PR can be done by using `git diff --color-words` to\nhighlight the changes.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"77b5c5570f56f1c0c13154825ceebc3728ba6c44"}},"sourceBranch":"main","suggestedTargetBranches":["9.2"],"targetPullRequestStates":[{"branch":"main","label":"v9.3.0","branchLabelMappingKey":"^v9.3.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/244151","number":244151,"mergeCommit":{"message":"avoid JVM metric conflicts with explicit cast (#244151)\n\nIn JVM runtime metrics, when micrometer is used in the application, the\nfollowing metrics are also produced by micrometer, which creates a\nconflict with the OpenTelemetry metrics that are produced with the\ninstrumentation agent (EDOT and upstream).\n\nAdding a proper cast allows to work-around this issue for metrics where\nthis issue is known to happen, for now two metrics are impacted:\n- `jvm.memory.used`\n- `jvm.memory.committed`\n\nThe only change applied by this PR is adding an explicit type cast\n`::long` to those metrics when they are referenced in ES|QL queries.\nReviewing this PR can be done by using `git diff --color-words` to\nhighlight the changes.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"77b5c5570f56f1c0c13154825ceebc3728ba6c44"}},{"branch":"9.2","label":"v9.2.3","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: SylvainJuge <763082+SylvainJuge@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In JVM runtime metrics, when micrometer is used in the application, the following metrics are also produced by micrometer, which creates a conflict with the OpenTelemetry metrics that are produced with the instrumentation agent (EDOT and upstream).
Adding a proper cast allows to work-around this issue for metrics where this issue is known to happen, for now two metrics are impacted:
jvm.memory.usedjvm.memory.committedThe only change applied by this PR is adding an explicit type cast
::longto those metrics when they are referenced in ES|QL queries. Reviewing this PR can be done by usinggit diff --color-wordsto highlight the changes.