Standalone OpenMetrics Text Parser

OpenMetrics, when adopted widely, will be the export format of various endpoints that need to be auto-discovered and scraped. Currently, there isn't an official parser library for OpenMetrics other than the ongoing work on Prometheus. Prometheus provides discovery and scraping libraries to enable non-Prometheus programs to discover and scrape Prometheus endpoints. But the these libraries report data points as deltas and makes the consumer to build a state machine and aggregate the deltas in order to report the collected series. This sometimes makes it hard to write new tools to discover, parse and ingest metrics. To avoid some of these problems, I propose that we should build a standalone OpenMetrics parser so the adoption is not limited.

Challenges

A standalone parser would be useful in the following cases:

• When metrics are needed to be scraped by intermediate tools. There are a variety of tools that want to rely on user metrics for better decisions. For example, load balancers can rely on custom user metrics. Autoscalers can dynamically scale the number of replicas based on user metrics.
• In large clusters, aggregation of collected metrics is a common approach before reporting them. Collecting OpenMetrics metrics, aggregating them in a custom intermediate component and exposing them to metric collection backend is a path we should enable.
• When running very tiny workloads or while being in limited compute environments, running collection backends is not always an option. It'd be good to be able to parse the metrics to lightweight intermediate components to temporary store, aggregate and export to metrics collection backend is not possible.

Proposal

Let’s create a standalone parser library that will parse the text format to Protocol Buffers. Consumers of OpenMetrics can rely on the parser library if proto exposition is not available. If metrics are exposed in protos, scraper should prefer to fetch them in proto instead of parsing the text format.

Alternatives Considered

• Building a standalone parser library based on components from the Prometheus source code. But maintainability-wise, this is not the right approach and it may require forks of unexported components. Forking the Prometheus project should be discouraged.
• Making protobuf a mandatory export format but this would limit the adoption of OpenMetrics.

Start by reviewing the proposal and the existing Prometheus discovery and scraping libraries it references. Define the standalone parser's scope, including text-format parsing and conversion to Protocol Buffers, then compare that design with the stated alternatives. Done means the project has an agreed implementation plan and acceptance criteria for the parser library.