Issue 20852: Flooring number down to whole second

[igoristic]

Summary

Resolves #20852

formatMetric was rounding float seconds to whole numbers, so something like: 59500ms (59.5 seconds) would equal to 60 seconds

To see Shard Activity go to: Stack Monitoring > Elasticsearch Overview > then scroll all the way down

Please note you might not see any Shard Activity initially, so increase From Now time span at the top right. If you still don't see any activity try ingesting a decent amount of new data into ES

[elasticmachine]

Pinging @elastic/stack-monitoring

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[chrisronline]

@igoristic Would you including testing steps, including which UIs/views we should expect to see the change?

[chrisronline]

I'm not sure this is the right fix.

Here is the UI for me, prefix:

Here is what I see with your PR:

[igoristic]

@chrisronline I couldn't reproduce this. I don't think my change is significant enough to cause such a drastic behavior, since all it does is rounds down eg: floor(ms / 1000). Is it possible that the ms times changed to less than 1000 when testing with my branch? in which case it would indeed be 0s

Also, can you post your shardActivity from x-pack/plugins/monitoring/public/components/elasticsearch/overview/overview.js by doing something like:
JSON.stringify(shardActivity)

[chrisronline]

[{
  "translog": {
    "total_on_start": 0,
    "recovered": 0,
    "total": 0,
    "total_time_in_millis": 30,
    "percent": "100.0%"
  },
  "verify_index": {
    "total_time_in_millis": 0,
    "check_index_time_in_millis": 0
  },
  "stop_time_in_millis": 1560350805932,
  "index": {
    "size": {
      "total_in_bytes": 0,
      "reused_in_bytes": 0,
      "percent": "0.0%",
      "recovered_in_bytes": 0
    },
    "total_time_in_millis": 65,
    "files": {
      "total": 0,
      "recovered": 0,
      "percent": "0.0%",
      "reused": 0
    },
    "target_throttle_time_in_millis": 0,
    "source_throttle_time_in_millis": 0
  },
  "source": {},
  "type": "EMPTY_STORE",
  "target": {
    "transport_address": "127.0.0.1:9301",
    "ip": "127.0.0.1",
    "host": "127.0.0.1",
    "name": "Elastic-MBP",
    "id": "ZYoB7yGiSYivEVu_mqLl0Q"
  },
  "stage": "DONE",
  "total_time_in_millis": 109,
  "start_time_in_millis": 1560350805823,
  "id": 0,
  "index_name": ".monitoring-es-7-2019.06.12",
  "primary": true
}, {
  "translog": {
    "total_on_start": 0,
    "recovered": 0,
    "total": 0,
    "total_time_in_millis": 30,
    "percent": "100.0%"
  },
  "verify_index": {
    "total_time_in_millis": 0,
    "check_index_time_in_millis": 0
  },
  "stop_time_in_millis": 1560350803518,
  "index": {
    "size": {
      "total_in_bytes": 0,
      "reused_in_bytes": 0,
      "percent": "0.0%",
      "recovered_in_bytes": 0
    },
    "total_time_in_millis": 73,
    "files": {
      "total": 0,
      "recovered": 0,
      "percent": "0.0%",
      "reused": 0
    },
    "target_throttle_time_in_millis": 0,
    "source_throttle_time_in_millis": 0
  },
  "source": {},
  "type": "EMPTY_STORE",
  "target": {
    "transport_address": "127.0.0.1:9301",
    "ip": "127.0.0.1",
    "host": "127.0.0.1",
    "name": "Elastic-MBP",
    "id": "ZYoB7yGiSYivEVu_mqLl0Q"
  },
  "stage": "DONE",
  "total_time_in_millis": 120,
  "start_time_in_millis": 1560350803398,
  "id": 0,
  "index_name": ".monitoring-kibana-7-2019.06.12",
  "primary": true
}]

The issue is if the total_time_in_millis is less than 1s, these changes will always show 0:00:00 which isn't entirely accurate, as there are some milliseconds we can show there.

[chrisronline]

Disregard my last statements. I was confusing myself with the current functionality.

This LGTM!!

[igoristic]

Backport:
7.x: 6bf25b5
7.2: 0c80579
6.8: 4b5ebdd