Tag logs with the current pod information about fluent-plugin-kubernetes_metadata_filter HOT 7 CLOSED

@sami9gag I'm not certain what you are eluding to here; that is the point of this plugin. It adds pod metadata to a log entry that is specific to the pod.

from fluent-plugin-kubernetes_metadata_filter.

@jcantrill Hmm.. maybe my explanation wasn't quite clear. In the current form the plugin takes the log name and parses the source pod from the log name. Then it fetches the pod metadata for that pod and adds it to the log entry.

What I'm suggesting is a feature that always takes the current pod (the pod that is running fluentd) and adds that information to the log entry.

from fluent-plugin-kubernetes_metadata_filter.

@sami9gag that seems useful if you have multiple fluentd instances deployed assigning each to some 'application' The way this plugin is used, at least in OpenShift, is to deploy one fluentd instance per node and it is responsible for all the container logs on that node. This keeps users needing to know anything about the logging infrastructure.

from fluent-plugin-kubernetes_metadata_filter.

@jcantrill Right and that is what we are doing for the most parts as well. But there are certain legacy applications that can't really handle writing to stdout/stderr for docker to capture the output. Instead we have to resort to a set of tricks to capture the logs, but that also means that we lose all context from the logs.

from fluent-plugin-kubernetes_metadata_filter.

To try and help get some traction on this, would it be possible to add your syslog as a source, like the container logs are defined?

https://github.com/fabric8io/docker-fluentd-kubernetes/blob/0026081281fc0c13e6205a573747542f2a8ad802/fluent.conf#L104

You could then tag it kubernetes.* and the filter would catch it?

from fluent-plugin-kubernetes_metadata_filter.

That's a good idea, but in practice it's not really a viable option.

Input in that example is actually JSON formatted and contains some fields that the parser depends on. In my case I'm in practice using Log4J to pass the data to fluentd, so in order to add the required fields I would need to modify the log4j component to do a query to kubernetes master and then pass the data to fluentd.

With that it would actually make more sense to add the parsing to log4j and pass the data directly to our central fluentd bypassing the sidecar fluentd instance completely. But that would solve just one of our use cases.

The reason why it works with the current rule, is that the logger that is writing the log already has all the information and can simply write it to the logfile. If there is an easy way of getting the information from within a pod without talking to the master, then we might be able to use a generic passthrough process that adds the information (without that much additional overhead).

from fluent-plugin-kubernetes_metadata_filter.

not sure, but I believe this use case is supported in current versions of the plugin

from fluent-plugin-kubernetes_metadata_filter.