Add prometheus exporter

[bernd]

This implements a prometheus exporter that maps the internal dropwizard
metrics to prometheus compatible metric names and labels.

The metric mapping is configurable via config files.

Fixes #9914

TODO

• Add some tests
• Register our default exporter port in the prometheus default port registry
• Check for TODOs and commented code
• Check that the metrics filter works correctly
• Add error handling and constant for the built-in resource file
• Add HTTP endpoint that returns a JSON payload for the file based discovery in prometheus
• Test with a real prometheus

[danotorrey]

@bernd I really like the approach and design here. It's a nice improvement, which allows for configurability, and improves the definition of the mappings (both core and custom). I really did not like how the mappings definitions were explicitly defined in Java code in the first implementation. YML works very well as far as I can see here.

I still need to do more review and testing, but it does appear to work. I will take one more pass through with deeper testing. I left a few questions from the first look.

[danotorrey]

Well done! I tested this with a Prometheus instance running, and it works. The live refresh of the core/custom mappings is really cool. I am sure users will love that. It also looks like the existing mappings and label are being processed correctly and appear correct in Prometheus as they did with the original Cloud implementation.

From testing, I found a few items that I gave some feedback on. Once this is ready for review, I will do one last final pass through the code.

[danotorrey]

Looks good to me! Thanks a lot for the fixes. All tests successfully. I am merging this now.

I noticed one interesting aspect worth mentioning. Now that the defaults are not specified for the file, the edge case I mentioned is probably extremely hard to hit. Without defaults, the FilePathReadableValidator.class config validator seems to prevent nonexistent files from being specified on startup - effectively preventing the problematic situation. I think the defaults were exempt from the validation :D It's fine as is now since there's extra protection around it.

[fungusakafungus]

Shouldn't these be underscores instead?

[danotorrey]

@fungusakafungus You are absolutely right. Thank you very much for seeing this. #10904 has been created, and we will fix this.

[danotorrey]

This has been fixed in #10905 and will be included in the 4.1 release.