New Feature Proposals #loggregator


Adam Hevenor
 

Here is the correct link for noisy neighbor - https://docs.google.com/document/d/19CI185yhEAD4wcdHoYTLJQZFkBhWZ4c17yBMxJ4yT-U/edit


Rozenszajn, Sergio
 

This is an important change. In our environment we experience quite a few Loggregator server crashes. I believe this change will improve the situation.

In addition it should be possible to specify for what time window logs should be returned. For example cf logs myApp -- recent 10  (minutes). Sometimes it is very annoying to wait until a long useless list of logs is returned (and also consumes band width).

 

Thanks, Sergio

 

From: cf-dev@... [mailto:cf-dev@...] On Behalf Of Adam Hevenor
Sent:
יום ד 08 נובמבר 2017 23:15
To: cf-dev@...
Subject: [cf-dev] New #Loggregator Feature Proposals

 

The Loggregator team is planning work on two new feature epics and would love your feedback and input on either. Feel free to comment here or in the documents. 

Problem Summary - Noisy Neighbors

Currently if a single application produces logs fast enough, and consistently enough it can exhaust resource throughout the Loggregator system and cause other application logs, or component metrics to be dropped. There is not specific monitoring tools for identifying this occurrence, and isolating the application can be challenging and impactful to operators.

See the Improve Mean Time to Determine "Noisy Neighbor" Applications Feature Proposal.

Problem Summary - Scaling Limitations from Persistance Architecture

Deployments with large number of dopplers experience latent and incomplete responses when executing the command cf logs --recent. This is because the implementation of recent logs collects all logs for a particular app across each of the dopplers, and reassembles them to construct the response. This same architecture applies to container metrics so this latency affects the cf push in addition to cf logs recent. It also effectively limits the upper limit of the number of dopplers a deployment could handle.

See the improved persistance architecture feature proposal.

 

Thanks
Adam 


Adam Hevenor
 

The Loggregator team is planning work on two new feature epics and would love your feedback and input on either. Feel free to comment here or in the documents. 

Problem Summary - Noisy Neighbors

Currently if a single application produces logs fast enough, and consistently enough it can exhaust resource throughout the Loggregator system and cause other application logs, or component metrics to be dropped. There is not specific monitoring tools for identifying this occurrence, and isolating the application can be challenging and impactful to operators.

See the Improve Mean Time to Determine "Noisy Neighbor" Applications Feature Proposal.


Problem Summary - Scaling Limitations from Persistance Architecture

Deployments with large number of dopplers experience latent and incomplete responses when executing the command cf logs --recent. This is because the implementation of recent logs collects all logs for a particular app across each of the dopplers, and reassembles them to construct the response. This same architecture applies to container metrics so this latency affects the cf push in addition to cf logs recent. It also effectively limits the upper limit of the number of dopplers a deployment could handle.

See the improved persistance architecture feature proposal.

 
Thanks
Adam