Hi Jayaraj, Yes, you need to generate a new manifest for each upgrade of a CF version. Properties might be added, jobs may change, new resource pools may be required, older ones may be removed, etc be

Those properties are used to specify the etcd machines to loggregator. Those typically get auto-filled by spiff and you don't need to specify them explicitly in the properties section [1]. Did you not

OK cool. The error which you are getting now is different from what you had originally posted. You need to include the following property in your deployment and it should get fixed: properties: metron

Can you also list the commands on how you are creating, uploading and deploying the release? jayark(a)cisco.com> wrote:

Did you make sure to run "scripts/update" after cloning the cf-release repo? Can you run "find . -type d -maxdepth 2" from within the "src/loggregator" directory in cf-release and reply with what you

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

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

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

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

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

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

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

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

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

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

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

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

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

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-

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