[Stack Monitoring] Elasticsearch version displays incorrect version

[hendry-lim]

Kibana version: 8.0.0 8.0.1

Elasticsearch version: 8.0.0 8.0.1

Steps to reproduce:

1. Configure Elasticsearch monitoring with Metricbeat with xpack.enabled: true
2. Go to Kibana > Stack Monitoring
3. Observe that the Elasticsearch version under Elasticsearch overview is displayed as 29363 for 8.0.1.

Expected behavior:
The version should display the correct Elasticsearch version, which in 8.0.1, it should be 8.0.1.

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[hendry-lim]

in 8.1.0 (before Kibana was upgraded).

(after Kibana was upgraded)

[bwright1558]

I'm having a similar issue. I have three different elasticsearch clusters, all of them on version 8.1.1. Kibana is displaying a different "Version" in Stack Monitoring for each of the clusters.

Cluster 1 is showing version 882308.
Cluster 2 is showing version 57096.
Cluster 3 is showing version 36278.

I would expect it to display version 8.1.1. This all started happening after upgrading from version 7.17.0 to 8.1.0.

[bvader]

Just a bit another couple data points.

Self Managed 8.1.2 : Version Odd at initial Startup

Elastic Cloud 8.1.2 : Version OK at initial Startup / Configuration

Then several Minutes Later
Elastic Cloud 8.1.2 : Version NOT OK

[matschaffer]

I seem to recall @gigerdo (or maybe @s-nel ) mentioning there are a few internal monitoring documents that show up before metricbeat data starts flowing on cloud. Wonder if that's what got the correct version on the first pass.

[s-nel]

there are a few internal monitoring documents that show up before metricbeat data starts flowing on cloud

Yes immediately after enabling logs & metrics delivery internal collection will be on, then as the rolling restart plan change progresses each node disables internal collection and enables Metricbeat collection after restart.

[matschaffer]

Gotcha, thanks @s-nel.

Internal collection gets it right so looks like this is probably a beats bug.

I'll leave this issue here though since it's sort of the main repo for our team, and there might be some interplay with how kibana is querying.