Skip to content

system/data_stream/syslog: Message Parsing issue and exclusion of files in syslog datastream - #8621

Merged
ishleenk17 merged 13 commits into
elastic:mainfrom
ishleenk17:system_syslog
Dec 1, 2023
Merged

ishleenk17 merged 13 commits into
elastic:mainfrom
ishleenk17:system_syslog

Conversation

@ishleenk17

@ishleenk17 ishleenk17 commented Nov 30, 2023 •

Copy link
Copy Markdown
Member

Proposed commit message

There are 2 changes as part of the PR.
1. Making the exclude_files configurable for the user asd user might want to exclude different type of files.
2. Resolving the message parsing issue in Syslog

Checklist

  • I have reviewed tips for building integrations and this pull request is aligned with them.
  • I have verified that all data streams collect metrics or logs.
  • I have added an entry to my package's changelog.yml file.
  • I have verified that Kibana version constraints are current according to guidelines.

Related issues

@ishleenk17 ishleenk17 added the enhancement New feature or request label Nov 30, 2023
@ishleenk17
ishleenk17 requested review from a team as code owners November 30, 2023 17:49
@elasticmachine

elasticmachine commented Nov 30, 2023 •

Copy link
Copy Markdown

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2023-12-01T08:57:03.770+0000

  • Duration: 18 min 29 sec

Test stats 🧪

Test Results
Failed 0
Passed 158
Skipped 0
Total 158

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

@elasticmachine

elasticmachine commented Nov 30, 2023 •

Copy link
Copy Markdown

🌐 Coverage report

Name Metrics % (covered/total) Diff
Packages 100.0% (3/3) 💚
Files 100.0% (4/4) 💚 15.385
Classes 100.0% (4/4) 💚 15.385
Methods 67.857% (57/84) 👎 -21.973
Lines 98.426% (3002/3050) 👍 9.212
Conditionals 100.0% (0/0) 💚

@devamanv devamanv changed the title Message Parsing issue and exclusion of files in syslig datastream Message Parsing issue and exclusion of files in syslog datastream Nov 30, 2023
@devamanv

devamanv commented Nov 30, 2023 •

Copy link
Copy Markdown
Contributor

@ishleenk17 Quick question: if we are trying to make sure that the message field doesn't already exist, could we just check for message == null in the second rename processor(if a check like that is possible), instead of adding a new remove processor?
Rest looks good to me

Comment thread packages/system/data_stream/syslog/manifest.yml Outdated
@shmsr shmsr changed the title Message Parsing issue and exclusion of files in syslog datastream system/data_stream/syslog: Message Parsing issue and exclusion of files in syslog datastream Nov 30, 2023
@shmsr

shmsr commented Nov 30, 2023

Copy link
Copy Markdown
Member

@ishleenk17 Quick question: if we are trying to make sure that the message field doesn't already exist, could we just check for message == null in the second rename processor(if a check like that is possible), instead of adding a new remove processor? Rest looks good to me

++

In the rename processor, if we add the on_failure i.e., it'd fail if event.original != null? So, with on_failure we can pass the remove processor with no condition. Is this gonna work? If yes, removal would happen in fewer processing.

@efd6 efd6 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In looking for context, I can see that the literal .gz$ is used everywhere for this pattern. Probably there should be an issue for this.

Comment thread packages/system/data_stream/syslog/manifest.yml Outdated
@ishleenk17

Copy link
Copy Markdown
Member Author

@ishleenk17 Quick question: if we are trying to make sure that the message field doesn't already exist, could we just check for message == null in the second rename processor(if a check like that is possible), instead of adding a new remove processor? Rest looks good to me

That won;t suffice as we want to remove the message field

@ishleenk17

Copy link
Copy Markdown
Member Author

@ishleenk17 Quick question: if we are trying to make sure that the message field doesn't already exist, could we just check for message == null in the second rename processor(if a check like that is possible), instead of adding a new remove processor? Rest looks good to me

++

In the rename processor, if we add the on_failure i.e., it'd fail if event.original != null? So, with on_failure we can pass the remove processor with no condition. Is this gonna work? If yes, removal would happen in fewer processing.

Yes, that would work as well. We are following this remove practice. See elastic/package-spec#583.

show_user: false
description: The files to be excluded by the Agent. See [exclude_files](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-log.html#filebeat-input-log-exclude-files) for details.
default:
- \.gz$

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the original issue,.bz2 is also highlighted. Do you want to consider bz2 also in the default exclusion list?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, that would be left to the user. As mostly users exclude .gz files

if: 'ctx.event?.original != null'
field: message
ignore_missing: true
description: 'The `message` field is no longer required if the document has an `event.original` field.'

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just wanted to know, in instances where event.original is already present, such as when it comes from Logstash, we wouldn't alter the event.original field, and it wouldn't be replaced(as per expected state description here). Is there a chance in these situations for the data in the message and event.original fields to be different? If so, I believe we should refrain from removing the message field in those cases and consider adding a check to account for this scenario.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once it enters the pipeline event.original and message would be same. Hence we would like to avoid having duplicates. Thats why deletion is important immediately after the rename of event original to message field.

There can be a case where message field it used after the removal as seen in syslog datastream. So that also gets handled by the removal of message field before this.

Comment thread packages/system/data_stream/syslog/manifest.yml
Comment thread packages/system/data_stream/syslog/manifest.yml Outdated
ishleenk17 and others added 2 commits December 1, 2023 11:58
Co-authored-by: subham sarkar <sarkar.subhams2@gmail.com>
Comment thread packages/system/changelog.yml Outdated

@devamanv devamanv left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Co-authored-by: muthu-mps <101238137+muthu-mps@users.noreply.github.com>
@ishleenk17
ishleenk17 merged commit 6ac94ad into elastic:main Dec 1, 2023
@elasticmachine

Copy link
Copy Markdown

Package system - 1.50.0 containing this change is available at https://epr.elastic.co/search?package=system

1 similar comment
@elasticmachine

Copy link
Copy Markdown

Package system - 1.50.0 containing this change is available at https://epr.elastic.co/search?package=system

@ishleenk17
ishleenk17 deleted the system_syslog branch February 7, 2025 03:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request Integration:system System

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants