# Filebeat: wrong multiline merging

**URL:** <https://discuss.elastic.co/t/filebeat-wrong-multiline-merging/225881>\
**Category:** Beats\
**Tags:** filebeat\
**Created:** [March 31, 2020, 2:11pm UTC](https://discuss.elastic.co/t/filebeat-wrong-multiline-merging/225881 "2020-03-31T14:11:04Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![agapoff](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/agapoff/32/65400_2.png) [@agapoff](https://discuss.elastic.co/u/agapoff)\
**Post date:** [March 31, 2020, 2:11pm UTC](https://discuss.elastic.co/t/filebeat-wrong-multiline-merging/225881/1 "2020-03-31T14:11:04Z")

</div>

I am trying to run filebeat daemonset in Kubernetes cluster. It is expected to honor the multiline log entries and also parse json log entries.

This is the config snippet:

```auto
    filebeat.autodiscover:
      providers:
        - type: kubernetes
          node: ${NODE_NAME}
          hints.enabled: true
          hints.default_config:
            type: container
            paths:
              - /var/log/containers/*${data.kubernetes.container.id}.log
            multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
            multiline.negate: true
            multiline.match: after
            multiline.max_lines: 50
            multiline.timeout: 3s
    processors:
      - add_cloud_metadata:
      - drop_event:
          when:
            or: 
              - equals:
                  kubernetes.namespace: "kube-system"
              - equals:
                  kubernetes.namespace: "metallb-system"
      - decode_json_fields:
          fields: ["message"]
          process_array: false
          max_depth: 1
          target: ""
          overwrite_keys: true

```

Everything works as desired except for one issue: some json logs are being merged together when this is not expected:

 ![multiline](https://us1.discourse-cdn.com/elastic/original/3X/e/d/edc6b991d6d0236de2bc928e6c19d2d22115deba.png)

Does anybody know how to deal with it?

---

<div class="post-metadata">

**Author:** ![ChrsMark](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/chrsmark/32/55858_2.png) [@ChrsMark](https://discuss.elastic.co/u/ChrsMark)\
**Post date:** [April 1, 2020, 10:14am UTC](https://discuss.elastic.co/t/filebeat-wrong-multiline-merging/225881/2 "2020-04-01T10:14:52Z")

</div>

Hey!

Are you sure that your `multiline.pattern` is correct? I guess that this might cause the issue.

---

<div class="post-metadata">

**Author:** ![agapoff](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/agapoff/32/65400_2.png) [@agapoff](https://discuss.elastic.co/u/agapoff)\
**Post date:** [April 1, 2020, 10:20am UTC](https://discuss.elastic.co/t/filebeat-wrong-multiline-merging/225881/3 "2020-04-01T10:20:56Z")

</div>

Hi Chris,

The `multiline.pattern` looks good. Moreover it works nice with the actual multiline entries:

 ![multiline-good](https://us1.discourse-cdn.com/elastic/original/3X/a/e/ae3c3cb3d10bc7f475207ecee32e3c48f4d656b7.png)

Also the issue with wrong merging appears with any value of `multiline.pattern`. I have tried to fill it with some random letters and the issue persists. The issue disappears only when I completely remove the multiline config.

---

<div class="post-metadata">

**Author:** ![agapoff](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/agapoff/32/65400_2.png) [@agapoff](https://discuss.elastic.co/u/agapoff)\
**Post date:** [April 4, 2020, 10:14am UTC](https://discuss.elastic.co/t/filebeat-wrong-multiline-merging/225881/4 "2020-04-04T10:14:47Z")

</div>

No more thoughts?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [May 2, 2020, 10:14am UTC](https://discuss.elastic.co/t/filebeat-wrong-multiline-merging/225881/5 "2020-05-02T10:14:47Z")

</div>

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