How Logging Works in Cloud Foundry

The Cloud Foundry logging system is called Loggregator. Loggregator collects logs and metrics from apps, aggregates them, and routes them to any clients or services that request them. Loggregator automatically collects logs from any and all apps, as long as those apps print their logs to standard output.

Loggregator has the following architecture:

  1. Apps generate logs which are collected by Sources.
  2. Sources forward logs to Metrons, which are agents running on the same node as the Sources they log.
  3. Metrons forward logs to Dopplers, which are servers that collect and store logs in temporary buffers.
  4. A Traffic Controller handles requests from external logging clients and services. The Traffic Controller exposes a Firehose, which is a WebSocket endpoint capable of streaming logs and metrics to remote services.

The Firehose is the most important aspect of this architecture, since it creates an access point for applications and services (called nozzles) to access the log stream. You can learn more about nozzles from the Cloud Foundry nozzle tutorial. In this next section, we’ll explain how LogDNA uses the Firehose to ingest logs.

Use the LogDNA Nozzle to send logs to Cloud Foundry

The LogDNA nozzle streams events from your entire Cloud Foundry deployment to LogDNA. The nozzle runs as an app within Cloud Foundry, making it easy to deploy and manage. In minutes, all of your Cloud Foundry app logs will begin appearing in LogDNA.
Start by downloading the latest release of the LogDNA nozzle:

$ git clone
$ cd logdna-cloudfoundry

Before connecting any nozzle to the Firehose, you must first authenticate the nozzle as a User Account and Authentication (UAA) client. Access to the Firehose is controlled by the doppler.firehose scope. To learn more about nozzle authentication and permissions, read the Cloud Foundry nozzle documentation.

Once your nozzle is authorized, you can push it to Cloud Foundry. We’ll name ours firehose-to-logdna so that it’s easy to identify in the app list. The –no-start parameter specifies that we don’t want to run the app after pushing it:

$ cf push firehose-to-logdna --no-start

Next, we need to set several environment variables. These provide the app with the data needed to authenticate not just to with Firehose, but with LogDNA. They include:

  • API_ENDPOINT Your Cloud Foundry system domain.
  • DOPPLER_ENDPOINT Your Cloud Foundry system domain.
  • INGESTION_KEY Your LogDNA ingestion key.
  • FIREHOSE_CLIENT_ID The ID of the LogDNA UAA client.
  • FIREHOSE_CLIENT_SECRET The secret associated with the UAA client.
  • SYSLOG_ENDPOINT An optional endpoint for a syslog server.

You can set each of these variables using the Cloud Foundry CLI:

$ cf set-env firehose-to-logdna API_ENDPOINT [your API_ENDPOINT]
$ cf set-env firehose-to-logdna DOPPLER_ENDPOINT [your DOPPLER_ENDPOINT]
$ cf set-env firehose-to-logdna INGESTION_KEY [your INGESTION_KEY]
$ cf set-env firehose-to-logdna FIREHOSE_CLIENT_ID [your FIREHOSE_CLIENT_ID]
$ cf set-env firehose-to-logdna SYSLOG_ENDPOINT [your optional SYSLOG_ENDPOINT]

Finally, push the nozzle to your Cloud Foundry deployment:

$ cf push firehose-to-logdna

Updated about a year ago


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.