Metric visualization top hit no value found

[raged]

We are running Kibana 7.3.0, and are noticing some weird behaviors with visualizations.

In this example system.uptime.duration.ms is showing up in discover for the machine I am after:

However, it shows a value of '-' when I try to show that value using the metric visualization:

I have gone to the index pattern for metricbeat-* and refreshed the field list, and tried removing the filter on the metric visualization, but nothing has resolved it.

Any ideas?

Thanks.

[Marius_Dragomir]

If you run the same aggregation in Visual Builder / TSVB does it show no results? I'm trying to pinpoint the root cause of this.
Also, can you copy the query and result from the Inspect menu in the Visualisation?

[raged]

When doing the same aggregation in TSVB I see no results either:

However, in discover it shows data:

Not sure why it thinks the machine has been up for 50 years, but that's a different issue all together.

Here is the Request for the metric visualization:

{
  "aggs": {
    "1": {
      "top_hits": {
        "docvalue_fields": [
          {
            "field": "system.uptime.duration.ms",
            "format": "use_field_mapping"
          }
        ],
        "_source": "system.uptime.duration.ms",
        "size": 1,
        "sort": [
          {
            "@timestamp": {
              "order": "desc"
            }
          }
        ]
      }
    }
  },
  "size": 0,
  "_source": {
    "excludes": []
  },
  "stored_fields": [
    "*"
  ],
  "script_fields": {},
  "docvalue_fields": [
    {
      "field": "@timestamp",
      "format": "date_time"
    },
    {
      "field": "ceph.monitor_health.last_updated",
      "format": "date_time"
    },
    {
      "field": "docker.container.created",
      "format": "date_time"
    },
    {
      "field": "docker.healthcheck.event.end_date",
      "format": "date_time"
    },
    {
      "field": "docker.healthcheck.event.start_date",
      "format": "date_time"
    },
    {
      "field": "docker.image.created",
      "format": "date_time"
    },
    {
      "field": "event.created",
      "format": "date_time"
    },
    {
      "field": "event.end",
      "format": "date_time"
    },
    {
      "field": "event.start",
      "format": "date_time"
    },
    {
      "field": "file.ctime",
      "format": "date_time"
    },
    {
      "field": "file.mtime",
      "format": "date_time"
    },
    {
      "field": "kubernetes.container.start_time",
      "format": "date_time"
    },
    {
      "field": "kubernetes.event.metadata.timestamp.created",
      "format": "date_time"
    },
    {
      "field": "kubernetes.event.timestamp.first_occurrence",
      "format": "date_time"
    },
    {
      "field": "kubernetes.event.timestamp.last_occurrence",
      "format": "date_time"
    },
    {
      "field": "kubernetes.node.start_time",
      "format": "date_time"
    },
    {
      "field": "kubernetes.pod.start_time",
      "format": "date_time"
    },
    {
      "field": "kubernetes.system.start_time",
      "format": "date_time"
    },
    {
      "field": "mongodb.replstatus.server_date",
      "format": "date_time"
    },
    {
      "field": "mongodb.status.background_flushing.last_finished",
      "format": "date_time"
    },
    {
      "field": "mongodb.status.local_time",
      "format": "date_time"
    },
    {
      "field": "mssql.transaction_log.stats.backup_time",
      "format": "date_time"
    },
    {
      "field": "nats.server.time",
      "format": "date_time"
    },
    {
      "field": "php_fpm.pool.start_time",
      "format": "date_time"
    },
    {
      "field": "php_fpm.process.start_time",
      "format": "date_time"
    },
    {
      "field": "postgresql.activity.backend_start",
      "format": "date_time"
    },
    {
      "field": "postgresql.activity.query_start",
      "format": "date_time"
    },
    {
      "field": "postgresql.activity.state_change",
      "format": "date_time"
    },
    {
      "field": "postgresql.activity.transaction_start",
      "format": "date_time"
    },
    {
      "field": "postgresql.bgwriter.stats_reset",
      "format": "date_time"
    },
    {
      "field": "postgresql.database.stats_reset",
      "format": "date_time"
    },
    {
      "field": "process.start",
      "format": "date_time"
    },
    {
      "field": "system.process.cpu.start_time",
      "format": "date_time"
    },
    {
      "field": "zookeeper.server.version_date",
      "format": "date_time"
    }
  ],
  "query": {
    "bool": {
      "must": [
        {
          "match_phrase": {
            "agent.hostname": {
              "query": "STEPS1BP1"
            }
          }
        },
        {
          "range": {
            "@timestamp": {
              "format": "strict_date_optional_time",
              "gte": "2019-08-30T12:49:53.724Z",
              "lte": "2019-09-06T12:49:53.724Z"
            }
          }
        }
      ],
      "filter": [
        {
          "match_all": {}
        }
      ],
      "should": [],
      "must_not": []
    }
  }
}

Here is the response:

{
  "took": 209,
  "timed_out": false,
  "_shards": {
    "total": 197,
    "successful": 197,
    "skipped": 103,
    "failed": 0
  },
  "hits": {
    "total": 127498,
    "max_score": null,
    "hits": []
  },
  "aggregations": {
    "1": {
      "hits": {
        "total": 127498,
        "max_score": null,
        "hits": [
          {
            "_index": "metricbeat-cltb-7.2.0-2019.09.06",
            "_type": "_doc",
            "_id": "qTe7BG0BVQQ6P_dQcXdw",
            "_score": null,
            "_source": {},
            "sort": [
              1567742455529
            ]
          }
        ]
      }
    }
  },
  "status": 200
}

Another interesting piece of this puzzle is when I go to the index pattern for metricbeat-* I see that there are mapping conflicts. Would this cause this behavior even if there are just 7 fields that it flagged as a conflict? system.uptime.duration.ms is not one of these fields that are in a conflicted status.

[raged]

@Marius_Dragomir any ideas?

[Marius_Dragomir]

That mapping conflict shouldn't make any difference in this context. Right now i'm trying to reproduce this locally as it seems to be really weird.