# Copy\_fields and Syslog parsing out of order

**URL:** <https://discuss.elastic.co/t/copy-fields-and-syslog-parsing-out-of-order/350418>\
**Category:** Beats\
**Tags:** beats-development, filebeat\
**Created:** [January 5, 2024, 12:31am UTC](https://discuss.elastic.co/t/copy-fields-and-syslog-parsing-out-of-order/350418 "2024-01-05T00:31:26Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Hythloday-zero](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/hythloday-zero/32/130547_2.png) [@Hythloday-zero](https://discuss.elastic.co/u/Hythloday-zero)\
**Post date:** [January 5, 2024, 12:31am UTC](https://discuss.elastic.co/t/copy-fields-and-syslog-parsing-out-of-order/350418/1 "2024-01-05T00:31:27Z")

</div>

When I use a Custom TCP Logs integration with Syslog parsing, I expect that

> Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See [Processors](https://www.elastic.co/guide/en/beats/filebeat/current/filtering-and-enhancing-data.html) for details.

..however, I experience the opposite. E.g. I apply

```
  - copy_fields:
      fields:
        - from: message
          to: event.original
      fail_on_error: false
      ignore_missing: true

```

to my Processors block when editing my integration and I end up getting all the syslog fields parsed from 'message' field and _then_ 'event.original' is copied from the remaining post-parsed 'message' field. I would expect to see 'event.original' looking like normal syslog and 'message' to look like the message payload contained within the syslog record.

Can we call this a bug and submit a GH issue against it, or am I doing something incorrectly?

---

<div class="post-metadata">

**Author:** ![strawgate](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/strawgate/32/131008_2.png) [@strawgate](https://discuss.elastic.co/u/strawgate)\
**Post date:** [January 22, 2024, 6:39pm UTC](https://discuss.elastic.co/t/copy-fields-and-syslog-parsing-out-of-order/350418/2 "2024-01-22T18:39:14Z")

</div>

My understanding of how this works is that when you check the syslog parsing field in the integration settings all it's doing is placing the `syslog` processor first in the list of processors.

You can see this behavior by pressing `Actions` \> `View Agent Policy` on the agent policy where you've configured the integration, if you look at the resulting yaml you'll see what is actually getting passed down to agent.

When i configure the custom tcp integration with syslog parsing, it renders this  
(among other things):

```auto
        processors:
          - syslog:
              field: message

```

And when we add your copy\_fields block the agent policy looks like this:

```auto
        processors:
          - syslog:
              field: message
          - copy_fields:
              fields:
                - from: message
                  to: event.original
              fail_on_error: false
              ignore_missing: true

```

So as you've noted your processor is getting added after the syslog parsing, and by that point the original message has been mutated with the timestamp, priority, etc stripped out.

To achieve the behavior you're looking for I think all you'd have to do is disable the `syslog parsing` check in the custom tcp logs integration and add the syslog processor after your copy\_fields processor like this:

```auto
  - copy_fields:
      fields:
        - from: message
          to: event.original
      fail_on_error: false
      ignore_missing: true
  - syslog:
      field: message

```

---

<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:** [February 19, 2024, 8:39pm UTC](https://discuss.elastic.co/t/copy-fields-and-syslog-parsing-out-of-order/350418/3 "2024-02-19T20:39:24Z")

</div>

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