Filebeat autodiscover advanced pod log shipping with container specific actions

Elastic Stack Beats
1

Hi!
I know autodiscover for Kubernetes/Docker is quite new.
In a pod context where a pod has several containers, is it possible to specify a sidecar configuration from kubernetes metadata in terms of achieving logging with a more specific type than docker? =)

I'm aware that a possible workaround is to use Docker labels with docker autodiscover, but the goal is to do this from a kubernetes deployment manifest.

Example idea in a kubernetes deployment:

metadata:
  labels: ...
  annotations:
    log-service: spring
    log-type: json
    log-token: XXXXXXXXXXXX
    sidecars:
      -  redis:
           log-service: redis
           log-type: log
           log-token: XXXXXXXXXXXX
           log-module: redis
      -  nginx
           log-service: nginx
           log-type: log
           log-token: XXXXXXXXXXXX
           log-module: nginx

Is this possible? Or are pods limited/restricted to using the same output type for all containers in the pod? Does anyone have different ideas about how to approach this use case?

Edit: Would this case be solvable with annotations and raw input?

2

Hi @havlan,

You can have a different configuration for each container in the pod using hint-based autodiscover. Look at the section about multiple containers in the documentation.

For your case I think you could have something like this (not tested :slight_smile: ):

annotations:
  co.elastic.logs.nginx/module: nginx
  co.elastic.logs.nginx/fileset.stdout: access
  co.elastic.logs.nginx/fileset.stderr: error
  co.elastic.logs.redis/module: redis
  ...

(Being redis and nginx the name of the containers in the pod)

3

Do you have an idea on how this will interact with processors or a fields entry? I would still need to extract data from metadata labels, would this require using the raw annotation field?
(I either need to rename kubernetes labels or add those labels as fields for further processing)

4

In filebeat there are two places where you can put processors, at the top-level configuration and at the input configuration. Processors at the top-level configuration are applied to all events, it doesn't matter if they where collected by an input configured from autodiscover hints. If they are defined in the input configuration, then they are only applied to events collected from this input.

On beats 6.4 there will be the possibility of configuring processors using hints too. And if you need to define an input with something not supported by hints (like fields at the moment) there will also be the option of using the raw annotation to define any configuration.

5

Alright, thanks for clarifying. I think a global processor (rename) would be the solution in our case.

6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.