Repository navigation
Implement GET /_prometheus/api/v1/status/buildinfo - #150235
Conversation
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
|
Hi @felixbarny, I've created a changelog YAML for you. |
🔍 Preview links for changed docs |
ℹ️ Important: Docs version tagging👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version. We use applies_to tags to mark version-specific features and changes. Expand for a quick overviewWhen to use applies_to tags:✅ At the page level to indicate which products/deployments the content applies to (mandatory) What NOT to do:❌ Don't remove or replace information that applies to an older version 🤔 Need help?
|
|
Hi @felixbarny, I've updated the changelog YAML for you. |
✅ Elastic Docs Style Checker (Vale)No issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
The scoped /_prometheus/{index}/api/v1/status/buildinfo route
requires reading the index parameter so Elasticsearch does not
reject the request as containing an unrecognized parameter.
Avoid an intermediate String when sending the Prometheus buildinfo JSON response; RestResponse already accepts XContentBuilder.
…nto promql-buildinfo
Grafana calls this endpoint when connecting to any Prometheus-compatible data source. Without it, two things break:
The fix is a static endpoint that returns ES build info (version, git hash, build date) in the standard Prometheus buildinfo shape, with
application: "Elasticsearch"so Grafana correctly identifies the backend as vanilla Prometheus rather than Mimir or Cortex — ensuring it doesn't attempt to use the Ruler API or other Mimir-specific features that we don't support.