|Number of watchers on Github||35|
|Number of open issues||2|
|Average time to close an issue||about 2 months|
|Average time to merge a PR||5 days|
|Open pull requests||22+|
|Closed pull requests||38+|
|Last commit||over 1 year ago|
|Repo Created||about 2 years ago|
|Repo Last Updated||over 1 year ago|
|Organization / Author||cloudfoundry|
|Do you use loggregator? Leave a review!|
|View open issues (2)|
|View loggregator activity|
|View on github|
|Fresh, new opensource launches 🚀🚀🚀|
Trendy new open source projects in your inbox! View examples
Loggregator is the logging system used in CloudFoundry.
Loggregator uses Google's protocol buffers along with gRPC to deliver logs. Loggregator has defined (via Loggregator API) log types that are contained in a single protocol buffer type, named an
envelope. Those types are:
The Loggregator system as a whole does not have an opinion about how frequently any log type is emitted. However, there are recommendations.
Gauge logs should be emitted regularly (e.g., once a minute) so downstream consumers can easily plot the increasing total.
Event should be emitted when the corresponding action occurred and therefore should be treated as asynchronous data. These data types do not lend themselves to be plotted as a time series.
Loggregator is made up of 4 components:
The Agent is a daemon process that is intended to run on each container/VM. It is the entry point into Loggregator. Any log that is written to Loggregator is written to the Agent.
The Router takes each log and publishes it to any interested consumer. Every log is in flight, and not available for a consumer if the consumer was late to connect. It routes envelopes via the pubsub library that allows a consumer to give the Router
selectors to whitelist what logs it wants. A consumer does not connect directly to a router.
The ReverseLogProxy (RLP) has gRPC endpoints to allow consumers to read data from Loggregator. Each RLP connects to every Router to ensure it gets all the relevant logs. Each Router only gets a subset of the logs, and therefore without the RLP, a consumer would only get a fraction of the logs. The RLP only speaks V2.
The TrafficController (TC) is like the RLP, but is tuned for CloudFoundry. It authenticates via the UAA and CloudController, which are both CF components. It egresses logs via Websockets. It only speaks V1. Planned deprecation in 2018.
Loggregator chooses to drop logs instead of pushing back on producers. It does so with the diodes library. Therefore if anything upstream slows down, the diode will drop older messages. This allows producers to be resilient to upstream problems.
There is Go client library: go-loggregator. The client library has several useful patterns along with examples to interact with a Loggregator system.