-
Notifications
You must be signed in to change notification settings - Fork 678
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom tagging/source on logs sent to Syslog (feature) #163
Comments
Would love to see this as well. The Docker Cloud service (formerly Tutum) seems to set the |
I've been exploring the code; although it's written in GO and there's little to no documentation, it is possible that setting the SYSLOG_HOSTNAME environment variable will do this. I'm running some tests. If it does, then SYSLOG_PRIORITY, SYSLOG_TAG, and possible SYSLOG_STRUCTURED_DATA will be able to work as well... |
tutum/syslogger suggests this can be done - but I've tried passing the host in as an environment variable and it doesn't seem to take effect. But I agree - it should be feasible to pass in tags using a similar method. |
Tests seem to show that SYSLOG_TAG defaults to the container name (which is good) and SYSLOG_HOSTNAME defaults to the container ID (which is bad). It does not affect the syslog source as sent by the Syslog protocol, but it does change the syslog message:
In this example , the SYSLOG_HOSTNAME was set to "Rancher:" , and the container name is "rancher-agent". The source is still 10.10.25.149 (the IP address of the Docker host), though. Not ideal, but closer. |
I ran into a similar requirement. We run containers on mesos/marathon so container IDs and names are not very meaningful so wanted to add a set of arbitrary tags to each container so that we can later do some grouping and parsing (we use ELK as a central log repository). We we ended up doing is use the SYSLOG_TAG env variable on each container and added the tags we want as key value pairs for example: We then ran logspout like this: This ended up outputting a message that looked like the following: We then parse SYSLOG_TAG with a kv filter in logstash. Hope this helps someone. |
In case it helps someone...
|
Apologies if this is redundant, however is it possible to get the hostname of the parent host running the container? I am attempting to use PaperTrail, and having the Container ID isn't really useful. I'd like to set
I need this dynamically, so wondering if something similar to |
@derks Try configuring the hostname for logspout (using dockers --hostname flag) and the set |
I ran into a similar requirement. We run containers on mesos/marathon so container IDs and names are not very meaningful so wanted to add a set of arbitrary tags to each container so that we can later do some grouping and parsing (we use ELK as a central log repository). We we ended up doing is use the SYSLOG_TAG env variable on each container and added the tags we want as key value pairs for example: We then ran logspout like this: This ended up outputting a message that looked like the following: We then parse SYSLOG_TAG with a kv filter in logstash. Hope this helps someone. ================= Can get a real example, step by step? For example, portainer docker? |
We have a number of Docker hosts that may be sending logs to Syslog via logspout. These logs appear in syslog with the Docker host IP as the source. However, we are only interested in the cluster source, not the specific host.
It would be useful to have an optional env var that can be set when starting the Logspout container, whereby you can specify the Source to use in the Syslog feed (and/or a tag to prepend to the syslog entry). In this way, the logs would arrive at syslog with a common Source of (eg) 'cluster A' rather than one of the various IP addresses of the cluster members.
Also, being able to use the Container name or ID to prepend the log entry would help in analysis where the central log server gets thousands of such logs a second.
As Docker infrastructures grow in size, this could be come a very useful feature to have available.
The text was updated successfully, but these errors were encountered: