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
Added reference doc for Occurrences and Check_Dependencies #498
Conversation
|
||
The `check_dependencies` filter is included in every install of Sensu. This | ||
filter can be applied to a handler using the "filter" or "filters" handler definition | ||
attribute. The `check_dependencies` filter matches events when an even already exisits, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
events when an event
instead of events when an even
and
exists
instead of exisits
### Built-in Filters - check_dependencies {#built-in-filters-check-dependencies} | ||
|
||
The `check_dependencies` filter is included in every install of Sensu. This | ||
filter can be applied to a handler using the "filter" or "filters" handler definition |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm leery of putting "filter" in here. Best practice would be for customers to use "filters".
### Built-in Filters - occurrences {#built-in-filters-occurrences} | ||
|
||
The `occurrences` filter is included in every install of Sensu. This filter can | ||
be applied to a handler using the "filter" or "filters" handler definition attribute. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't notice this at first, but yeah, I'd recommend enforcing "filters"
This looks great! I love the examples you've used, especially the progression of example for dependencies. I'd recommend:
|
Sidenote, I feel like this would satisfy the #374 issue. It's not a full-blown guide, but it adds the requisite material. |
} | ||
{{< /highlight >}} | ||
|
||
Lastly we can specify a dependency on any `mysql` check in the `mysql_nodes` subscription: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The subscription:
prefix functionality added in sensu/sensu-extensions-check-dependencies#12 has been merged, but we haven’t cut a new release of check_dependencies extension since that time.
This means that the feature hasn’t yet shipped to customers, so we shouldn’t describe it in these versions of the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cwjohnston was this for only 0.29 or everything including 1.4?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Blue0ctober we'll need to remove references to subscription/check pairs and the subscription:
prefix for all current versions. Ideally we'll ship that feature in Sensu 1.5.
{{< /highlight >}} | ||
|
||
|
||
The `occurrences` filter uses two custom check definition attributes, `occurrences` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let’s drop the adjective “custom” here. They are more or less part of the spec IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a couple of changes are needed. Please have a look.
|
||
The `check_dependencies` filter uses a custom check definition attribute `dependencies`. | ||
`dependencies` is defined as an array with attributes such as `checks`, Sensu client/check | ||
pairs or subscription/check pairs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Blue0ctober lets rephrase this to remove or subscription/check pairs
.
@Blue0ctober is this all set? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super excited about this! Left a few comments here and in Slack. We'll also need to get an approval from @cwjohnston before GitHub will let us merge.
- [occurrences Filter Attributes](#occurrences-filter-attributes) | ||
- [check_dependencies Filter](#check-dependencies-filter) | ||
- [Defining Check Dependencies](#defining-check-dependencies) | ||
- [check_dependencies Attributes](#check-dependencies-attributes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recommend reducing this to just:
[Built-in Filters](#built-in-filters)
|
||
|
||
The `occurrences` filter uses two check definition attributes, `occurrences` | ||
and `refresh`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this sentence is a duplicate of line 327
The `dependencies` attribute should define an array containing names of checks or | ||
client/check pairs. | ||
|
||
This example showcases a check configured to depend on any check called `mysql`: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recommend changing "showcases" to "shows"
|
||
The occurrences filter lets you configure the number of occurrences and the refresh interval at the check level using two check definition attributes: `occurrences` and `refresh`. | ||
|
||
Here's an example of a check definition that passes events to the `email` handler starting with the third occurrence every 60 minutes: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs review
} | ||
} | ||
} | ||
{{< /highlight >}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand this behavior. Which event is being filtered: mysql
or web_application_api
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If mysql
check for this client is in a non-OK state, events from this client for web_application_api
check from will be filtered.
|
||
The occurrences filter lets you configure the number of occurrences and the refresh interval at the check level using two check definition attributes: `occurrences` and `refresh`. | ||
|
||
Here's an example of a check definition that passes events to the `email` handler starting with the third occurrence every 60 minutes: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't this be starting with the second occurrence every 60 minutes
? The JSON example has occurrences set to 2, so I believe it would be handled after 2 occurrences. I can test this if we aren't sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifying! That was exactly what I was wondering
|
||
The check dependencies filter is included in every install of Sensu. | ||
This filter can be applied to a handler using the `filters` handler definition attribute. | ||
The check dependencies filter lets you reduce notification noise by matching events when an event already exists, thereby only notifying for the root cause of a given failure. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part I think needs changed: by matching events when an event already exists
.
The point of dependencies is to get to the root cause quicker. So if a tomcat process isn't running, a check that tries to get to the API for an application inside of tomcat would not work. API depends on tomcat, if tomcat down only handle that event.
Maybe something like by looking to see if an event higher up in the dependency tree already exists
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Description
Adding references in core docs for built-in filters:
Closes #310
Motivation and Context
We have built-in filters, extensions included in official Sensu Core packages, which should be mentioned along site native or configuration-defined filters.
Types of changes
Checklist: