Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing # TYPE comment from topic metrics in Prometheus #4136

Merged
merged 1 commit into from
Apr 26, 2019

Conversation

merlimat
Copy link
Contributor

Motivation

In #2686, the logic to avoid duplicated comments was removed. The result is that TYPE comments are being duplicated and are breaking some Prometheus tools. Removing type info for topic metrics.

@merlimat merlimat added the type/bug The PR fixed a bug or issue reported a bug label Apr 25, 2019
@merlimat merlimat added this to the 2.4.0 milestone Apr 25, 2019
@merlimat merlimat self-assigned this Apr 25, 2019
@merlimat
Copy link
Contributor Author

run java8 tests
run integration tests

@jiazhai
Copy link
Member

jiazhai commented Apr 26, 2019

run java8 tests

@merlimat merlimat merged commit 7674a8f into apache:master Apr 26, 2019
@jerrypeng jerrypeng modified the milestones: 2.4.0, 2.3.2 May 21, 2019
jiazhai pushed a commit that referenced this pull request Aug 26, 2019
… fixed format issue in metricWithRemoteCluster; added test for Prometheus types (#4183)

Fixes #3112 

### Motivation

In this pull request, I set out to fix #3112, which is caused by duplicate TYPE statements in the metrics output which leads to parsing of Prometheus metrics to fail in recent versions of Prometheus. Because of this, Prometheus will report the broker target as down.

Since I started looking at this, the type definitions have been removed (#4136) from topics metric output. I think these types are useful in Prometheus and have added them back in. 

While testing this fix in my geo-replicated setup, I found a format in error (missing quote and comma) in the TopicStats.metricWithRemoteCluster method. This pull request includes a fix for that issue.

I have also added a new test to PrometheusMetricsTest.java that fails without these changes but passed with them.

### Modifications

I added a static HashMap to TopicStats to keep track of the TYPEs that have been output. All writing of the TYPE for topics and namespaces is done with the TopicStats.metricType method. I modified that method to update the HashMap and only print the TYPE out for the first occurrence of the metric name.  I also added a method reset the HashMap, which gets called in NamespaceStatsAggregator.generate. 

### Verifying this change

This change added tests and can be verified as follows:
  - Added testDuplicateMetricTypeDefinitions which checks for:
       - duplicate TYPE definitions in the Prometheus output
       - validates that no TYPE definition appears after the first metric sample
       - ensures that all metrics have a defined type

I execute the test twice to make sure the resetting of the HashMap of the already seen metric type definitions works correctly. This test passes for me reliably (both occurrences).

I have confirmed using promtool that the metrics output will now parse without error using versions 2.7.1 and 2.9.2 (which is the latest). There are many warnings around missing HELP definitions and metrics using reserved suffixes (ex. _count), but no errors.

In addition, I have patched 2.3.1 with this fix and am currently running it in my cluster. Prometheus (2.7.1) successfully parses the metrics and I am able to see namespace and topic-level metrics.
jiazhai pushed a commit that referenced this pull request Aug 28, 2019
… fixed format issue in metricWithRemoteCluster; added test for Prometheus types (#4183)

Fixes #3112

In this pull request, I set out to fix #3112, which is caused by duplicate TYPE statements in the metrics output which leads to parsing of Prometheus metrics to fail in recent versions of Prometheus. Because of this, Prometheus will report the broker target as down.

Since I started looking at this, the type definitions have been removed (#4136) from topics metric output. I think these types are useful in Prometheus and have added them back in.

While testing this fix in my geo-replicated setup, I found a format in error (missing quote and comma) in the TopicStats.metricWithRemoteCluster method. This pull request includes a fix for that issue.

I have also added a new test to PrometheusMetricsTest.java that fails without these changes but passed with them.

I added a static HashMap to TopicStats to keep track of the TYPEs that have been output. All writing of the TYPE for topics and namespaces is done with the TopicStats.metricType method. I modified that method to update the HashMap and only print the TYPE out for the first occurrence of the metric name.  I also added a method reset the HashMap, which gets called in NamespaceStatsAggregator.generate.

This change added tests and can be verified as follows:
  - Added testDuplicateMetricTypeDefinitions which checks for:
       - duplicate TYPE definitions in the Prometheus output
       - validates that no TYPE definition appears after the first metric sample
       - ensures that all metrics have a defined type

I execute the test twice to make sure the resetting of the HashMap of the already seen metric type definitions works correctly. This test passes for me reliably (both occurrences).

I have confirmed using promtool that the metrics output will now parse without error using versions 2.7.1 and 2.9.2 (which is the latest). There are many warnings around missing HELP definitions and metrics using reserved suffixes (ex. _count), but no errors.

In addition, I have patched 2.3.1 with this fix and am currently running it in my cluster. Prometheus (2.7.1) successfully parses the metrics and I am able to see namespace and topic-level metrics.

(cherry picked from commit 8d32b58)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/bug The PR fixed a bug or issue reported a bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants