We're using this. We're not running the full ELK stack; rather, we've replaced Logstash with fluentd. Our devs have two choices for acting on their logs: the

We're using this. We're not running the full ELK stack; rather, we've replaced Logstash with fluentd. Our devs have two choices for acting on their logs: they can use elastalert (running in Kubernetes) to alert on events that are recorded in Elasticsearch. We've provided a sample elastalert template that can be easily customized to a developers needs. They can also deploy a custom fluentd parser/transformer in Kubernetes. To make this work, they apply a special label in their Kubernetes replication controller that specifies the name of the custom fluentd parser service. The primary fluentd service pulls the logs from Docker and when it detects this label for a particular log entry, it routes that entry to the custom parser service. This allows us to have a standard log pipeline that works out-of-the-box for most projects but also self-serve custom parsing for the apps that need it.