Services that want to expose Prometheus metrics simply need to expose an HTTP endpoint (usually at /metrics) that provides metrics in Prometheus' text-based exposition format. The output of such an endpoint is human-readable and can look like this in its simplest form:

# HELP http_requests_total The total number of processed HTTP requests.
# TYPE http_requests_total counter
http_requests_total{status="200"} 8556
http_requests_total{status="404"} 20
http_requests_total{status="500"} 68

# HELP process_open_fds Number of open file descriptors.
# TYPE process_open_fds gauge
process_open_fds 32

In this example, the endpoint exposes an HTTP request counter that is split up by the response status code, as well as the number of open file descriptors of the target process.

To see live metrics from a "real" target in your browser, have a look at the metrics endpoint of a demo service that we run.

The commented # HELP and # TYPE lines provide an optional documentation string and metric type metadata about a metric name. Each non-commented line in this format represents a single sample consisting of a metric name, optional labels, and a sample value. This line-based format makes it easy to expose metrics from systems and services.

Take a look at the Prometheus documentation for full details on the exposition format. The Prometheus metrics exposition format is also being evolved into an open standard called OpenMetrics, which Prometheus supports as well.

You can learn more about how to track and expose these kinds of metrics from your own application code in our "Instrumenting Applications (Native)" training. In addition, our "Building Exporters" training teaches you how to expose metrics for third-party systems that you cannot instrument directly.