LATEST VERSION: 1.9 - CHANGELOG
Pivotal Cloud Foundry v1.9

Overview of the Loggregator System

Page last updated:

Loggregator is the next generation system for aggregating and streaming logs and metrics from all of the user apps and system components in an Elastic Runtime deployment.

View the Loggregator repository on GitHub.

Using Loggregator

The main use cases are as follows:

  • 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 Cloud Foundry components.

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

Loggregator Components

Loggregator Overview of Loggregator components

Source

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

Metron

Metron agents are co-located with sources. They collect logs and forward them to the Doppler servers.

Doppler

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

Handles client requests for logs. Gathers and collates messages from all Doppler servers, and provides external API and message translation (as needed for legacy APIs). Exposes the Firehose.

Firehose

The Firehose is a WebSocket endpoint which streams all the event data coming from an 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 via rsyslog configuration.

Because the data coming from the Firehose may contain sensitive information, such as customer information in the application logs, the Firehose is only accessible by users who have the right permissions.

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.

The address of the traffic controller can be discovered by hitting the info endpoint on the API and getting the value of the doppler_logging_endpoint.

Example output for a BOSH Lite CF environment:

 $ cf curl /v2/info | jq .doppler_logging_endpoint
 wss://doppler.192.0.2.34.xip.io:443

Difference Between Logs and Metrics

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

  • Metrics
    • Report a measurement from or 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

Nozzles

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. For example:

  • The Datadog nozzle publishes metrics coming from the Firehose to Datadog.
  • The Syslog nozzle filters out log messages coming from the Firehose and sends it to a syslog server.

See our Nozzle Tutorial.

Was this helpful?
What can we do to improve?
View the source for this page in GitHub