LATEST VERSION: 1.11 - CHANGELOG
Metrics Forwarder for PCF v1.11

Service Architecture

This topic describes the architecture of Metrics Forwarder for Pivotal Cloud Foundry (PCF).

High Availability Topology

In a highly available resource configuration, Metrics Forwarder for PCF uses the following:

If you want to reduce the number of VMs used in the deployment, you can scale down the Metrics Forwarder API resources to one.

Metric Types

Metrics Forwarder for PCF supports two types of metrics:

  • Gauge. A gauge metric is a 64-bit floating-point number used to represent a value at a point in time.

  • Counter. A counter metric is a 64-bit integer used to represent count values. Metrics Forwarder does not increment or decrement the value of a counter metric.

Data Persistence

Metrics that are emitted to the Metrics Forwarder API are not persisted. They are immediately converted into a format accepted by Loggregator and then emitted. To persist metrics that have been emitted to Metrics Forwarder, you can read the metrics directly from the Firehose or use a nozzle to consume Loggregator data.

Rate Limiting

Metrics Forwarder for PCF enables operators to configure rate limits. You can set the number of HTTP requests and metrics that a bound app is allowed to send to Metrics Forwarder per minute. This increases the level of service reliability and prevents apps from overwhelming Loggregator with high volumes of metrics data.

Metrics Forwarder for PCF applies rate limits to all requests received by the Metrics Forwarder API. The following HTTP headers are present in each response from the Metrics Forwarder API.

HTTP Header Description
x‑ratelimit‑limit Total number of HTTP requests that a bound app is allowed to send per minute. See x‑ratelimit‑period.
x‑ratelimit‑metrics‑limit Total number of metrics that a bound app is allowed to send per minute. See x‑ratelimit‑period.
x‑ratelimit‑metrics‑remaining Remaining number of metrics that a bound app can send during the current 60-second interval. See x‑ratelimit‑retry‑after.
x‑ratelimit‑period 60-second interval during which all limits are applied.
x‑ratelimit‑remaining Remaining number of HTTP requests that a bound app can send during the current 60-second interval. See x‑ratelimit‑retry‑after.
x‑ratelimit‑retry‑after Number of seconds remaining until the current one-minute interval ends.

The following example applies to the default Unlimited plan.

x-ratelimit-limit: unlimited
x-ratelimit-metrics-limit: unlimited
x-ratelimit-metrics-remaining: unlimited
x-ratelimit-period: 60
x-ratelimit-remaining: unlimited
x-ratelimit-retry-after: 0
Create a pull request or raise an issue on the source for this page in GitHub