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

There is currently no way for users to rotate the cc.db_encryption_key. We're going to schedule some work to look into ways to solve the problem without downtime. Any input would be great, as well as

We are also very interested in pursuing this capability. Cheers, Christopher Ferris IBM Distinguished Engineer, CTO Open Cloud IBM Software Group, Open Technologies email:

There are a lot of Keys in my CF deployment manifest. I'd like to be able to rotate them. Most of the keys I could probably just change in a deployment but would cause some downtime or a service

I believe the full crashed Warden container is kept around for an hour. The DEA keeps the Warden handle to the container. The Warden grace time only applies after all handles have been

Thinking a little more about your question Mohamed. In his presentation Mike might have made reference to people making adhoc changes to F5. In our organization today we have a handfull of engineers

Mike, Thanks for finding that. I've filed a bug <https://www.pivotaltracker.com/story/show/96801752> to get the README fixed. – John Tuley

I don't have an answer, so here are some diagnostic questions to help you debug: Have you set doppler.blacklisted_syslog_ranges to something that includes your destination? (This would be bad.) Do

We had the same problem due to missing templates in our manifest. We initially used the example manifest snippet shown at https://github.com/cloudfoundry/loggregator which mentions only the doppler