Add ingress nginx controller fileset

[ChrsMark]

Resolves: #8451

This PR adds fileset for ingress-nginx controller logs. Log patterns could be found on the controllers' docs.

In order to add the new pipeline a new setting called "version" is being introduced also in this PR. See the sum-up of the discussion on this comment.

How to test this

Filebeat

0. in /tmp/testnginx one can use the sample logs(see test.log file) used for automated testing.
1. Enable nginx Filebeat module
2. Configure the fileset.

- module: nginx
  # Access logs
  ingress_controller:
    enabled: true
    var.paths: ["/tmp/testnginx"]

3. Setup the pipelines in ES: ./filebeat setup
4. Start Filebeat and verify that events are properly shown in Kibana. NOTE: set the time window properly in Kibana so as to display the events in the timeline since the events have timestamps which will be in the past.

k8s environment

1. Deploy an ingress managed sample app on Minikube following the official k8s docs
2. check that ingress controller logs are being populated when doing curls (like described in k8s docs). Ingress controller pod lies under kube-system namespace and you will be able to check its logs with sth like nginx-ingress-controller-6fc5bcc8c9-zm8zv.
3. Redirect pods' logs to a temporary file: kubectl -n kube-system logs -f nginx-ingress-controller-6fc5bcc8c9-zm8zv >> /tmp/ingresspod
4. Inside minikube configure nginx module like:

- module: nginx
  # Ingress-nginx controller logs. This is disabled by default. It could be used in Kubernetes environments to parse ingress-nginx logs
  ingress_controller:
    enabled: true

    # Set custom paths for the log files. If left empty,
    # Filebeat will choose the paths depending on your OS.
    var.paths: ["/tmp/ingresspod"]

5. Run filebeat and check that logs are parsed correctly and shown in Kibana properly.
6. Visit http://hello-world.info/v2 so as to create new log entries.

[ChrsMark]

Even if the status is still "in-progress", reviews are more than welcome since the missing part has only to do with autodiscover feature (hence standalone part).

[ChrsMark]

Hey @exekias and @kvch! A first review on this would be helpful so as to confirm the approach before moving on to adding tests and docs 🙂 .

[exekias]

This is looking good, I have some concerns about how this would be treated in the future by the agent. @ruflin how do you feel about this concept of version?

[ruflin]

Thinking of how this will work within a package and the new indexing strategy I also have some concerns. Let me share some background on why.

With packages and the new indexing strategy, ingest pipelines are never defined by the beat / agent but are already assigned to the index the data ends up in. Sending data to two different ingest pipelines based on some Beats logic will not be possible anymore.

But we have examples where there are JSON and non json logs that we send and the ingest pipeline makes the decision how to do the processing. An example can be found here: https://github.com/elastic/beats/blob/master/filebeat/module/elasticsearch/slowlog/ingest/pipeline.json#L21 This also works with our future model.

What this means for the above is that we need something in the event to detect which ingest pipeline it should route the events to. Few ideas:

• There is a special field in the event that allows us to already detect it
• A field contains a special string we can detect
• We add a config option which adds a field so we can detect it

Comment on naming: Coming from ECS if I see a config or field named "version" I expect it to have a format like 1.4.3. So I would rather use a different term for it.

[exekias]

I'm leaning towards making this just another fileset for now (ie ingress-controller), have it disabled by default and make it clear that this is specific for kubernetes deployments. What do you folks think?

[ChrsMark]

Changes applied.
Added testing notes.
Manually tested in k8s env and worked as expected.

[exekias]

Can you please add a changelog?