It appears that we do not have the syslog_drain_binder templates as Mike mentioned — thanks guys! We’ll update that and give ‘er a go. Josh Ghiloni Senior Consultant 303.932.2202 o |

Mike, I don't want to speak to the possibility, but I can explain why we decided against app affinity. Basically, it comes down to sharding over a dynamic pool. As Doppler instances come and go,

daniel.jones(a)engineerbetter.com> wrote: Ok. I don't think that should cause a problem. That's weird, but might happen. Some thoughts on how to see what's happening. Apologizes in advance as

Hi Dan, Thanks for getting back to me. Sadly I can't reproduce the issue on my local Cloud Foundry instance, so I suspect the issue has something to do with the state of the client's CF's blob

For what it's worth, these aren't logs from Jetty. They're from the gorouter, note the "[RTR]" tag. Logs from your app would be prefixed with "[APP/#]". You might want to look around with `cf files

I would expect this to be possible. The easiest thing would probably be to write a shell script that both runs your application, and also starts a script that does the netstat output. Then set that

You'll need to increase cc.maximum_app_disk_in_mb in your bosh deployment manifest. That defines the maximum disk an app is allowed to request. Joseph Palermo CF Runtime Team

I'm trying to increase the disk quota in the manifest to 10G to try deploy the original big jar and I'm seeing the following error: E:\src\samples\cloudfoundry\modules>cf push En utilisant le fichier

Yeah, I get Jetty logs as below: 2015-06-11T04:27:46.34+0200 [RTR] OUT modules-popeyed-nonascetic.10.244.0.34.xip.io - [11/06/2015:02:27:46 +0000] "GET / HTTP/1.1" 200 1098 "-" "curl/7.29.0"

Or better yet support a syslog endpoint in an app container that sends to loggregator. Then we can get full stack traces in a single event. :) Mike

Hello Mike, Quite reasonable. I'll put a story in the backlog. Thank you, Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc.

Actually, this might explain why some of our customers are so frustrated trying to read their stack traces in Splunk. :\ So each line of a stack trace could go to a different Doppler. That means each

Oops, wrong link. Should be https://github.com/cloudfoundry/loggregator/blob/develop/src/metron/main.go#L188-L197 . Sorry about that! – John Tuley

Mike, Metron chooses a randomly-available Doppler for each message <https://www.pivotaltracker.com/story/show/96801752>. Availability prefers same-zone Doppler servers: - If a Metron instance

One of the really nice features of the V2 Service Broker API is the ability to broker multiple services from a single process. Each service provides its unique id in the broker catalog. The Cloud

Metron's documentation [1] says "All Metron traffic is randomly distributed across available Dopplers." How random is this? Based on observation, it appears that logs for an individual application

Thanks for your interest. We are close to supporting all current routing experimental features but we recently experienced some personnel issues which will caused us to lower NoRouter priority for a

That is a good question. Looking through a manifest it is difficult to pick out which keys/passwords should be rotated. A quick perusal found these candidates: * UAA/CC DB passwords can probably be

Makes perfect sense. I really like the NoRouter because of its simplicity. I really hope CloudFoundry adopts it and makes it part of its official release so that NoRouter stays in step with GoRouter

The issue was likely the disk. The staging_disk_limit_mb tells the cloud controller how much disk space is needed for staging an app (unless the app asks for more). This is normally much higher than