The syslog_daemon_config properties for the metron_agent job are used to configure rsyslogd.

p=,,,20,0,0,0::relevance,,syslog+agent,20,2,0,26724357 https://github.com/cloudfoundry/cf-deployment/blob/master/operations/experimental/add-syslog-agent.yml

We do not presently plan to offer this, for a couple reasons: 1) The add-syslog-agent.yml ops file has existed as an opt-in for some time. 2) The new architecture will change which

/jobs/metron_agent/templates/metron_agent_ctl.erb#L22-L24 <https://github.com/cloudfoundry/loggregator/blob/a6890ed17c9a4d1bd7ce9203df027858047aa030/src/metron/syslog_daemon_config/

Those values will configure the syslog_forwarder.conf.erb template that accompanies the metron_agent job to emit syslog to that different address and port.

To implement that strategy, we want to introduce some process on the diego cell (maybe integrated in the loggregator agent aka metron agent), that will forward each application log

The actual syslog forwarder config with the syslog_daemon_config is installed by the metron_agent job template, but that comes from cf-release and is also on all the CF jobs.

/jobs/syslog_drain_binder ./jobs/dea_logging_agent ./jobs/loggregator-acceptance-tests ./jobs/metron_agent ./bin ./git-hooks .

to etcd - trafficcontroller, metron agents : to find healthy dopplers to access to) ============= Note that I am also doubting the following errors in the "syslog_drain_binder.stdout.log

So we probably don't need to worry about syslog then.

-->For CF component syslog: We can send cf component syslog via metron to custom syslog endpoint (followed by parsing and other mining stuff) On the operator side how can we store "

And yes other components like trafficcontroller and metron agents should also error out. How many ETCDs were running at the time of these errors?

Looking at https://github.com/cloudfoundry/loggregator/blob/develop/manifest-templates/cf-lamb.yml we later determined that we also needed the syslog_drain_binder and metron_agent templates

The complete list of deprecated flags is: traffic_controller.debug doppler.debug metron_agent.debug syslog_drain_binder.debug Thanks Adam

The logs are emitted by the DEA agent to metron, which forwards them to doppler servers.

batch_size=1000 HTTP/1.1", upstream: "http://unix:/var/vcap/sys/run/cloud_controller_ng/cloud_controller.sock:/v2/syslog_drain_urls?

Several components in cf-release talk to etcd: - doppler - metron_agent - syslog_drain_binder - loggregator_trafficcontroller - routing-api (not router) - hm9000 Please let us know

For product like Wily Introscope (now known as APM), which is agent based monitoring approach, and I think these agents right now only support Java/.Net technologies, which sends such

I think the easy way is to use the provided logs system by CF, so deaagent-> metron -> dopler -> Firehose consumer - forwarder -> Willy Will be strange that Willy agent / or server

As far as your comment John about having our applications send their syslogs to a remote syslog server.