Hello everybody, after a lot of deliberation and many good conversations, we came to the conclusion that we will go ahead and remove the firehose endpoint in six months. So, in the first release publi

Hi Neil, Thanks for the feedback. We actually created PRs for both, firehose-exporter[0] and to firehose-to-syslog[1]. We will continue working with the maintainers to get these pulled in. Best, Johan

Hi everybody, thanks for the continuous stream of feedback. We are definitely going to support the firehose-exporter and firehose-to-syslog projects off the firehose to the RLP. The stories in our bac

Hi there, we haven't heard from anyone who is currently consuming the /containermetrics endpoint. We went ahead an removed it. It will be gone as of loggregator release 105. Please let us know if you

Thank you all for the feedback. This is very helpful. I understand your concern about the short timeframe. I am very open to extending the timeframe to allow everybody to move of the firehose in a non

Hi there, Following the last thread about the deprecation of the /containermetrics endpoint, the Loggregator team would like to continue on its path of deprecations. Next on the chopping block is the

Hi there, the loggregator team would like to remove the /containermetrics endpoint on the loggregator_trafficcontroller (see here: https://github.com/cloudfoundry/loggregator-release/blob/master/docs/

Hi there, the loggregator team has come across a few cases where in a big cf deployment with over 9k application-bound syslog drains the scalable syslog adapter is reaching its scaling limits (pun int

Hi Sundar, These first metrics that you enumerate are not from the BoshHMForwarder, but are just normal ValueMetrics or CounterEvents from the components itself (the components send these metrics dire

That is not quite true. From the Firehose you can get ContainerMetrics for an app as long as you have access to that app. The Firehose CLI plugin for example shows all application related messages - l

No, that is 100 as in 100 log lines. Given that a log line is transported as a UDP package and the UDP max package size is 64k, with a buffer of 100 log lines you require 6.3MB of memory per app on yo

We (the Logging and Metrics team) recently spent a lot of time working with the firehose and writing nozzles. While doing that, we found ourselves in the need for an easy way to access the firehose, s

Ben, I guess I am working under the assumption that the current upstream schema is not going to see a terrible amount of change. The StatsD protocol has been very stable for over four years, so I don'

The current way of sending metrics as either Values or Counters through the pipeline makes the development of a downstream consumer (=nozzle) pretty easy. If you look at the datadog nozzle[0], it just

Hi Swatz, In your config file, you will have to use 'datadog-firehose-nozzle' as the username and the password you specified when you created the uaa client. And no, there is no need to restart UAA.

Hi Stephan, I managed to get an instiki(instiki.org) instance up and running on PWS. I had to change a few things to get it to work and even with those changes, it isn't great yet. For example, upload