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.
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.
To see a larger version of this diagram, click here.
Note: The Loggregator system now 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 co-located 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.
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.
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
The Firehose carries both logs and metrics, which differ as follows:
- 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 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 JMX Bridge OpenTSDB Firehose Nozzle, which installs with JMX Bridge
- 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.