Overview of the Loggregator System

Page last updated:

Loggregator gathers and streams logs and metrics from user apps in a Pivotal Cloud Foundry (PCF) deployment as well as metrics from PCF components. See the Loggregator repository on GitHub.

Using Loggregator

The primary use cases for Loggregator include the following:

  • App developers can tail their application logs or dump the recent logs from the Cloud Foundry Command Line Interface (cf CLI), or stream these to a third-party log archive and analysis service.

  • Operators and administrators can access the Loggregator Firehose, the combined stream of logs from all apps, and the metrics data from PCF components.

  • Operators can deploy nozzles to the Firehose. A nozzle is a component that monitors the Firehose for specified events and metrics, and streams this data to external services.

Loggregator Architecture

The diagram below shows the architecture of Loggregator, including the PCF components that it interacts with.


View a larger version of this image.

Note: The Loggregator system uses gRPC for communication between the Metron Agent and the Doppler, and between the Doppler and the Traffic Controller. This improves the stability and the performance of the Loggregator system, but it may require operators to scale their Dopplers.


Sources are logging agents that run on the Cloud Foundry components.


Metron Agents are colocated with sources. They collect logs and forward them to the Doppler servers.


Dopplers gather logs from the Metron Agents, store them in temporary buffers, and forward them to the Traffic Controller or to third-party syslog drains.

Traffic Controller

The Traffic Controller handles client requests for logs. It gathers and collates messages from all Doppler servers, and provides external API and message translation as needed for legacy APIs. The Traffic Controller also exposes the Firehose.


The Firehose is a WebSocket endpoint that streams all the event data coming from a n Elastic Runtime deployment. The data stream includes logs, HTTP events and container metrics from all applications, and metrics from all Elastic Runtime system components. Logs from system components such as Cloud Controller are not included in the firehose and are typically accessed through rsyslog configuration.

Because the data coming from the Firehose may contain sensitive information, such as customer information in the application logs, only users with the correct permissions can access the Firehose.

The Traffic Controller serves the Firehose over WebSocket at the /firehose endpoint. The events coming out of the Firehose are formatted as protobuf messages conforming to the dropsonde protocol.

You can discover the address of the Traffic Controller by hitting the info endpoint on the API and retrieving the value of the doppler_logging_endpoint.

Example for a BOSH Lite CF environment:

$ cf curl /v2/info | jq .doppler_logging_endpoint

Difference Between Logs and Metrics

The Firehose carries both logs and metrics, which differ as follows:

  • Metrics
    • Report a measurement from a VM, or the status of a VM, at its timestamp time
    • Follow dropsonde or statsd protocol
    • Can route to a monitoring platform to trigger alerts
  • Logs
    • Report events detected, actions taken, errors, or any other messages the operator or developer wanted to generate
    • Follow the syslog standard
    • Are not used to trigger alerts

Scalable Syslog

This section describes the Scalable Syslog components of Loggregator.

Reverse Log Proxy (RLP)

RLPs are BOSH jobs colocated with the Traffic Controller that collect logs from Dopplers and forward them to Syslog Adapters. You can scale this component based on your overall log volume.

Syslog Adapter

Syslog Adapters are BOSH VMs that manage connections with and write to syslog services, or drains. You can scale this component based on the number of drains. For more information about Syslog Adapter capacity planning, see Scaling Loggregator.

This section provides information about the components that are related to the Loggregator system.


Nozzles are programs which consume data from the Loggregator Firehose. Nozzles can be configured to select, buffer, and transform data, and forward it to other applications and services. Example nozzles include the following:

  • The JMX Bridge OpenTSDB Firehose Nozzle, which installs with JMX Bridge
  • The Datadog nozzle, which publishes metrics coming from the Firehose to Datadog
  • The Syslog nozzle, which filters out log messages coming from the Firehose and sends it to a syslog server

For more information about nozzles, see the Nozzle Tutorial.

Create a pull request or raise an issue on the source for this page in GitHub