- The open source Prometheus Pushgateway is a cache for metrics. Because the
Collector is a proxy, it forwards metric payloads to the Chronosphere backend
instead of caching metrics. This distinction means:
- HTTP
DELETErequests aren’t supported. - HTTP
PUTandPOSTrequests are semantically the same. - The Query API, or
GETrequests, aren’t supported.
- HTTP
- Neither the Prometheus Pushgateway nor the Collector support any aggregation.
- The Collector only supports GZIP compressed payloads. Snappy-compressed payloads aren’t supported.
- Transport Layer Security (TLS) isn’t supported. All traffic to the Collector is in plain text, but traffic to the Chronosphere backend is always encrypted.
- Ensure that at least one of the labels are unique to the instance of the calling job so that time series don’t collide. If the label IDs are sufficiently high in cardinality, you might want to aggregate the labels.
- Push metrics periodically, ideally when a job shuts down.
- Run Collectors as sidecars (where all traffic is over
localhost), or as a formal Kubernetes service.
Examples
The following examples show how to send traffic with the Prometheus Pushgateway to the Collector, assuming that the listen address is running on port3030.
Using curl
When running thiscurl command, replace <collector-ip> with the IP address of your
Collector.
localhost instead of the IP address for a Collector that’s
running locally (such as for testing purposes), you need to enable port forwarding
first. If your Collector is running as a Kubernetes DaemonSet or as a Kubernetes
Deployment, run the following command to enable port forwarding, where
<chronocollector-pod-name> is the name of the Kubernetes pod where the Collector is
running:
curl command and use localhost instead of the
Collector IP address.