Tags in Filebeat 7.0 - FIXED

[antawari (antawari de la Torre)]

Hello community,

Here lies my problem: so far I have been able to parse several logs from my servers into logstash using Filbeat, the issue is that I need to insert tags into each path so I'm able to then show it in different dashboards within Kibana. Documentation on Filebeat 7.0 is not very specific about this thus I've been trying to consume the logs this way in my filebeat.yml:

filebeat.inputs:
    - type: log
      paths:
        - /opt/jboss-4.2.3.GA/server/honey_dev/log/*.log
          tags: ["Piphany-DEV"]

    - type: log
      paths:
        - /opt/jboss-4.2.3.GA/server/honey_test/log/*.log
          tags: ["Pihany-TEST"]

If I loose the tags, the Filebeat sends the logs without problem, if i test config the output shows me this=>

[root@linux22 log]# filebeat test config
Exiting: error loading config file: yaml: line 17: mapping values are not allowed in this context

line 17: - /opt/jboss-4.2.3.GA/server/honey_dev/log/*.log

How can I achieve this?

EDIT:

I has able to solve the issue, the problem was the order of the declared objects. The end file turned out like this:

#----------------- Client Logs Begin
  filebeat.inputs:
    - type: log
      enabled: true
      tags: ["Piphany","DEV"]
      paths:
        - /opt/jboss-4.2.3.GA/server/honey_dev/log/*.log

    - type: log
      enabled: true
      tags: ["Pihany","TEST"]
      paths:
        - /opt/jboss-4.2.3.GA/server/honey_test/log/*.log

   - type: log
     enabled: true
     tags: ["Nikkeninc","DEV"]
     paths:
       - /opt/jboss-4.2.3.GA/server/nikkeninc_dev/log/*.log

    - type: log
      enabled: true
      tags: ["Linux22","ServiceConfig"]
      paths:
        - /home/MCOMFoundation_Docker/MCOMServiceConfig/log/*.log

[kvch (Noémi Ványi)]

Just for the record, the issue was not with the order of the settings, but the indentation. Configuration of filebeat does not care about the order of the different keys. Only time the order of the configuration keys matters when someone sets the same option multiple times. In this case the last encountered setting will win. But that is an already a bad configuration, set one option one time for each config object.