-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[receiver/journald]: add support for matches
configuration
#20852
Changes from 6 commits
e9d0953
87c4345
0e81f08
2fd4a2e
3c89455
b788bce
5d3a40b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,16 @@ | ||
# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | ||
change_type: enhancement | ||
|
||
# The name of the component, or a single word describing the area of concern, (e.g. filelogreceiver) | ||
component: journaldreceiver | ||
|
||
# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
note: add support for `matches` configuration | ||
|
||
# One or more tracking issues related to the change | ||
issues: [20295] | ||
|
||
# (Optional) One or more lines of additional information to render under the primary note. | ||
# These lines will be padded with 2 spaces and then inserted directly into the document. | ||
# Use pipe (|) for multiline entries. | ||
subtext: |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,13 +14,15 @@ The `journald_input` operator will use the `__REALTIME_TIMESTAMP` field of the j | |
| `output` | Next in pipeline | The connected operator(s) that will receive all outbound entries. | | ||
| `directory` | | A directory containing journal files to read entries from. | | ||
| `files` | | A list of journal files to read entries from. | | ||
| `units` | | A list of units to read entries from. | | ||
| `priority` | `info` | Filter output by message priorities or priority ranges. | | ||
| `units` | | A list of units to read entries from. See [Multiple filtering options](#multiple-filtering-options) examples, if you want to use it together with `matches` and/or `priority`. | | ||
| `matches` | | A list of matches to read entries from. See [Matches](#matches) and [Multiple filtering options](#multiple-filtering-options) examples. | | ||
| `priority` | `info` | Filter output by message priorities or priority ranges. See [Multiple filtering options](#multiple-filtering-options) examples, if you want to use it together with `units` and/or `matches`. | | ||
| `start_at` | `end` | At startup, where to start reading logs from the file. Options are `beginning` or `end`. | | ||
| `attributes` | {} | A map of `key: value` pairs to add to the entry's attributes. | | ||
| `resource` | {} | A map of `key: value` pairs to add to the entry's resource. | | ||
|
||
### Example Configurations | ||
|
||
```yaml | ||
- type: journald_input | ||
units: | ||
|
@@ -33,7 +35,65 @@ The `journald_input` operator will use the `__REALTIME_TIMESTAMP` field of the j | |
- type: journald_input | ||
priority: emerg..err | ||
``` | ||
#### Simple journald input | ||
|
||
#### Matches | ||
|
||
The following configuration: | ||
|
||
```yaml | ||
- type: journald_input | ||
matches: | ||
- _SYSTEMD_UNIT: ssh | ||
- _SYSTEMD_UNIT: kubelet | ||
_UID: "1000" | ||
sumo-drosiek marked this conversation as resolved.
Show resolved
Hide resolved
|
||
``` | ||
|
||
will be passed to `journalctl` as the following arguments: `journalctl ... _SYSTEMD_UNIT=ssh + _SYSTEMD_UNIT=kubelet _UID=1000`, | ||
which is going to retrieve all entries which match at least one of the following rules: | ||
|
||
- `_SYSTEMD_UNIT` is `ssh` | ||
- `_SYSTEMD_UNIT` is `kubelet` and `_UID` is `1000` | ||
|
||
#### Multiple filtering options | ||
|
||
In case of using multiple following options, conditions between them are logically `AND`ed and within them are logically `OR`ed: | ||
|
||
```text | ||
( priority ) | ||
AND | ||
( units[0] OR units[1] OR units[2] OR ... units[U] ) | ||
AND | ||
( matches[0] OR matches[1] OR matches[2] OR ... matches[M] ) | ||
``` | ||
|
||
Consider the following example: | ||
|
||
```yaml | ||
- type: journald_input | ||
matches: | ||
- _SYSTEMD_UNIT: ssh | ||
- _SYSTEMD_UNIT: kubelet | ||
_UID: "1000" | ||
units: | ||
- kubelet | ||
- systemd | ||
priority: info | ||
``` | ||
|
||
The above configuration will be passed to `journalctl` as the following arguments | ||
`journalctl ... --priority=info --unit=kubelet --unit=systemd _SYSTEMD_UNIT=ssh + _SYSTEMD_UNIT=kubelet _UID=1000`, | ||
which is going to effectively retrieve all entries which matches the following set of rules: | ||
|
||
- `_PRIORITY` is `6`, and | ||
- `_SYSTEMD_UNIT` is `kubelet` or `systemd`, and | ||
- entry matches at least one of the following rules: | ||
|
||
- `_SYSTEMD_UNIT` is `ssh` | ||
- `_SYSTEMD_UNIT` is `kubelet` and `_UID` is `1000` | ||
|
||
Note, that if you use some fields which aren't associated with an entry, the entry will always be filtered out. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it worth noting that this configuration will not emit ssh or systemd logs because of the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Added additional note to explicitly say that the example configuration won't get any entries for |
||
|
||
### Simple journald input | ||
|
||
Configuration: | ||
```yaml | ||
|
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.
Should there be a mechanism to prevent specifying both
units:
andmatches:
configuration for a single input?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 really sure about it, as you can do it in
journalctl
as wellThere 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.
My testing with
journalctl
trying to use bothunits
andmatches
syntax gave unexpected results - specifically NO LOG DATA. At a minimum, there should be a warning in the docs that mixingunits
andmatches
could lead to unexpected results.journalctl --utc --output=short --follow --priority info --unit ssh.service
journalctl --utc --output=short --follow --priority info _TRANSPORT=kernel PRIORITY=5
journalctl --utc --output=short --follow --priority info _SYSTEMD_UNIT=ssh.service + _TRANSPORT=kernel PRIORITY=5
journalctl --utc --output=short --follow --priority info --unit ssh.service _TRANSPORT=kernel PRIORITY=5
journalctl --utc --output=short --follow --priority info --unit ssh.service + _TRANSPORT=kernel PRIORITY=5
"+" can only be used between terms
journalctl --utc --output=short --follow --priority info _TRANSPORT=kernel PRIORITY=5 --unit ssh.service
journalctl --utc --output=short --follow --priority info _TRANSPORT=kernel PRIORITY=5 + --unit ssh.service
"+" can only be used between terms
Tested on Ubuntu 20.04 host with a noisy iptables LOG rule (kernel log stream) and inbound SSH probes.
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 wouldn't say the the behavior fully unexpected. Look at the following example:
How I understand the behavior is:
1
Having both matches and units can be actually helpful, if you want to select multiple units with the same additional parameter, so you can do it in the following way:
instead of:
Anyway, I would allow either
matches
orunits
to avoid confusion and non-well documented behavior. It will be also easier to deal with it if we decide to go with jorunald gateway pathThere 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 don't agree that the results are unexpected - in fact, they are exactly what I would expect. The
units
andmatches
conditions are AND-ed, same aspriority
andunits
are AND-ed in the current version of the receiver.I don't agree with this. Both
matches
andunits
should be possible to set together, as this makes perfect sense - as you have described in your comment @sumo-drosiek, and as it is possible injournalctl
. The argument about journald gateway doesn't make much sense, as thematches
configuration as implemented is already incompatible with the journald gateway (which apparently only accepts a flat list of AND-ed conditions). We are already not compatible with the journald gateway with thematches
and I think it makes most sense to allow the user to do the same thing as they can do withjournalctl
.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.
We are compatible with
journald-gateway
and will be anyway, as we are able to get all entries based on the configuration (there is no requirement to do it in one query). Only thing is that allowing to have bothmatches
andunits
introduces some logic complexity which could be avoided.