Check license expiry date zero value

[ycombinator]

Resolves #14541.

Users using Metricbeat to monitor an Elasticsearch cluster with a Basic license will not be able to access that cluster in the Stack Monitoring UI. This is because the elasticsearch/cluster_stats metricset is recording a Basic license's expiration date as 0, which the UI considers to a sentinel value for an expired license.

This PR fixes this bug by not recording the expiration date field at all, if its value is 0. This mimics what internal monitoring collection is doing.

Testing this PR

1. Spin up an Elasticsearch node with a Basic license.
2. Build Metricbeat with this PR.

   cd $GOPATH/src/github.com/elastic/beats
   mage build
   

3. Enable the elasticsearch-xpack Metricbeat module.

   ./metricbeat modules enable elasticsearch-xpack
   

4. Run Metricbeat.

   ./metricbeat -e
   

5. Verify that the latest document in .monitoring-es-*-mb-* of type: cluster_stats does not record the license expiration date in ms.

   http://localhost:9200/.monitoring-*-mb-*/_search?q=type:cluster_stats&sort=timestamp:desc&size=1&filter_path=hits.hits._source.license
   

[elasticmachine]

Pinging @elastic/stack-monitoring (Stack monitoring)

[chrisronline]

I tested this functionality, and it LGTM!

POST .monitoring-es-7-mb-2019.11.18/_search?filter_path=hits.hits._source.license
{
  "size": 1,
  "sort": [
    {
      "timestamp": {
        "order": "desc"
      }
    }
  ],
  "query": {
    "term": {
      "type": {
        "value": "cluster_stats"
      }
    }
  }
}

yields:

{
  "hits" : {
    "hits" : [
      {
        "_source" : {
          "license" : {
            "status" : "active",
            "issued_to" : "elasticsearch",
            "issue_date_in_millis" : 1573845929339,
            "max_nodes" : 1000,
            "issue_date" : "2019-11-15T19:25:29.339Z",
            "start_date_in_millis" : -1,
            "issuer" : "elasticsearch",
            "cluster_needs_tls" : false,
            "id" : "4c776e8e-8795-43f4-b74e-f0b6c1303e44",
            "type" : "basic"
          }
        }
      }
    ]
  }
}

[ycombinator]

I made this change for two reasons:

1. It's consistent with a similar logging behavior seen in the elasticsearch/enrich metricset:

   beats/metricbeat/module/elasticsearch/enrich/enrich.go

   Line 82 in ee5a4e7

   m.Logger().Debug(enrichUnavailableMessage)

2. By changing the log level to debug here (instead of warn), this check in the system test doesn't fail:

   beats/metricbeat/module/elasticsearch/test_elasticsearch.py

   Line 141 in ee5a4e7

   self.assert_no_logged_warnings()

[ycombinator]

@kaiyan-sheng Thanks for the review. I had to make a couple of changes to the PR since your review to make the system test pass. Would you mind re-reviewing, please? Thanks!

[kaiyan-sheng]

LGTM, thanks for explaining the change from warn to debug.

[ycombinator]

Travis CI is green and Jenkins CI failures are unrelated. Merging.