Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update winlogbeat-options.asciidoc #2919

Merged
merged 3 commits into from
Nov 4, 2016
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -149,6 +149,24 @@ winlogbeat.event_logs:
event_id: 4624, 4625, 4700-4800, -4735
--------------------------------------------------------------------------------

[WARNING]
Copy link
Contributor

Choose a reason for hiding this comment

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

This is not the usual way to create warnings, but it might be difficult in this case because you have code section in it. I'll wait for @dedemorton to suggest something.

Copy link
Contributor

Choose a reason for hiding this comment

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

This is valid asciidoc tagging. You could add [source,yaml] above the dashed line that starts the example to format the code correctly.

Copy link
Author

Choose a reason for hiding this comment

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

Keeping [WARNING] and added [source,yaml]

=======================================
There is a limit on the query depth to prevent the possibility of a stack overflow from deep recursive queries. This limit is actually set to 22 filters.
Copy link
Member

Choose a reason for hiding this comment

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

actually could be dropped.

Copy link
Contributor

Choose a reason for hiding this comment

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

We need to avoid repeating content from other websites verbatim (the content is likely copyrighted). This sentence is taken directly from the Microsoft website: "There is a limit on the query depth to prevent the possibility of a stack overflow from deep recursive queries."

It would be better anyhow to state this limitation in terms of what the user specifies in the Winlogbeat config. How about something like this:

You can specify up to 22 event IDs. Specifying more than 22 event IDs may produce deep recursive queries that could result in a stack overflow. For more information, see https://support.microsoft.com/en-us/kb/970453.

I didn't suggest edits to the text about the workaround because it sounds like you are still discussing the best approach to solving this issue.

Copy link
Author

Choose a reason for hiding this comment

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

Fixed.


More than 22 event id's should be handled with multiple monitors to the same name:
Copy link
Member

Choose a reason for hiding this comment

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

s/id/ID/

Copy link
Author

Choose a reason for hiding this comment

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

FIXED


--------------------------------------------------------------------------------
Copy link
Contributor

Choose a reason for hiding this comment

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

you can add [source,yaml] on this to get syntax highlighting.

Copy link
Author

Choose a reason for hiding this comment

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

Done

winlogbeat.event_logs:
Copy link
Member

Choose a reason for hiding this comment

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

I investigated automatically splitting up the event IDs across two queries. It gets complicated due to the interactions with the suppress filters (e.g. -1, -2). I think we should wait until #1491 (comment) is implemented and in the meantime use the drop_event processor as a workaround to either include or exclude events.

I don't want to recommend creating duplicate Security event log consumers because it can potentially result in data loss in some conditions. And in the future we may want to disallow duplicate names to prevent the aforementioned condition (but that's TBD).

- name: Security
event_id: 4624, 4625, 4700-4800, -4735 ....
- name: Security
event_id: 4624, 4625, 4700-4800, -4735 ....
--------------------------------------------------------------------------------

For more information around this, please visit https://support.microsoft.com/en-us/kb/970453.
=======================================


===== event_logs.level

A list of event levels to include. The value is a comma-separated list of
Expand Down