Correct, the datadog-firehose-nozzle has its own custom client which makes REST calls to the datadog API. It doesn't use the datadog statsd agent. A similar approach should work for you. Thanks, Rohit

Hi Marco, We instrumented the collector and found that none of the existing CF components provide any tags which would be overridden by the latest collector change. So this change shouldn't affect any

Answers to your questions: 1. That error might be caused if your doppler servers aren't healthy and therefore not listed in etcd. The traffic-controller polls etcd to discover dopplers. 2. You do need

The noaa library also lets you consume data from the loggregator firehose. The firehose sample app <https://github.com/cloudfoundry/noaa/blob/master/firehose_sample/main.go> shows how you can do this.

Hi Guangcai, The log messages are coming from the syslog_drain_binder process which is colocated with dopplers. The syslog_drain_binder is used to poll the CloudController for active syslog drain URLs

Hi Amit, The default timeout for the election is 15 seconds, so I would expect those log lines to show up at that interval. The syslog_drain_binder election code was written before my time on Loggrega

Quick correction: the default legacy metron port is 3456 [1]. The legacy forwarder only supports log messages. https://github.com/cloudfoundry/loggregator/blob/develop/bosh/jobs/metron_agent/spec#L28-

It isn't possible to throttle logging output on a per application basis. It is possible to configure the message_drain_buffer_size [1] to be lower than the default value of 100, which will reduce the

Does `cf logs --recent` work for you? The recent logs request goes over HTTP. If that goes through that means only the websocket requests to loggregator servers are a problem. Rohit

Hi Kyle, How many nodes do you have in your ETCD cluster? Also can you check whether the ETCD servers listed in the metron config match the IP addresses of the machines in your cluster. The config fil

Hi Mike, As Erik mentioned in the last thread, multi-line logging is something which the loggregator team would like to solve. But there are a few questions to answer before we can come up with a clea

We have thrown around one approach which solves the problem but would require changes in the runtime. That solution would expose a socket to the container where the application could emit logs. The ap

The API endpoint to get recent logs is present on the loggregator trafficontroller. You can get the URL for your traffic controller by running: cf curl /v2/info | jq .doppler_logging_endpoint Note tha

You should use the value coming from "doppler_logging_endpoint" not the "logging_endpoint". What version of cf-release are you using? Alternatively if you don't have a "doppler_logging_endpoint" in th

Hi Deepak, Do you have access to the loggregator_trafficcontroller machines from bosh? If so, can you `bosh ssh` into the machines attach the logs for the loggregator_trafficcontroller job? They are p

Hi Lon, The traffic controller takes a subscription ID as a parameter whenever a firehose connection is made. If you use the same subscription ID on each nozzle instance, the firehose will evenly dist

Both of the nozzles will get all the events coming from the firehose.

which are running on PCF which is on AWS ? I would imagine that would only be possible if your on-premises services have a publicly accessible endpoint. in CF? We have quite a bit of documentation on

Is there any reason why you can't profile the binary on a linux machine with the same architecture and go version as deployed on CF? I have generally had problems with the Go profiler when it comes to

Hi Ramon, Can you confirm if your installation has the 4443 port open for loggregator? One quick way of finding out would be to issue a curl to the traffic controller. Can you run the following comman