Kubernetes_metadata does not work on Kubernetes Windows

Hi Team,

I'm evaluating moving our Windows workloads to Kubernetes and would like to use filebeat for logs shipment. I've created DaemonSet where I mounted hostPathes:

  • /var/log
  • /ProgramData/docker/containers

My filebeat configuration looks like:

  - type: kubernetes
      enabled: true
        type: container
          - "C:\\var\\log\\containers\\*"
  pretty: true
  - add_host_metadata: ~
  - add_cloud_metadata: ~
  - add_kubernetes_metadata: ~
  level: debug

I can confirm that I can read from logs file from container context, but add_kubernetes_metadata processor is failing with following errors:

2020-08-19T13:10:37.084Z  DEBUG [input] log/input.go:494  Start harvester for new file: C:\var\log\containers\open-app-8fd9f9fcb-htbs8_default_open-app-09c468ee2146e47ec601e37dccbbabca246ee52dff196b2e573965225149b3ea.log
2020-08-19T13:10:37.138Z  ERROR [kubernetes]  add_kubernetes_metadata/matchers.go:91  Error extracting container id - source value does not contain matcher's logs_path 'C:\ProgramData\Docker\containers\'.
  • Version: filebeat version 7.8.1 (amd64), libbeat 7.8.1 [94f7632be5d56a7928595da79f4b829ffe123744 built 2020-07-21 15:12:43 +0000 UTC]
  • Operating System: Windows Server 2019 10.0.17763 N/A Build 17763

Hey @iusergii welcome to discuss :slight_smile:

I think that the problem is in the add_kubernetes_metadata configuration. It thinks that logs are taken from C:\ProgramData\Docker\containers\. You need to replace the matchers for your logs path, something like this might work:

  - add_kubernetes_metadata:
      default_matchers.enabled: false
        - logs_path:
            logs_path: 'C:\var\log\containers\'

Btw, what docker image are you using to deploy filebeat?

Hi @jsoriano, thank you very much, it works.

I'm only testing it so built my own, here is Dockerfile:

FROM mcr.microsoft.com/windows/servercore:ltsc2019
COPY filebeat-7.9.0-windows-x86_64 /app
ENTRYPOINT ["c:\\app\\filebeat.exe", "-c", "c:\\etc\\filebeat\\filebeat.yml", "-e"]

It quite heavy ~ 5GB, would love to move it to NanoServer, but seems there is an issue with libs compatibility: issue

1 Like