[juniper_srx] extract IP from RPD_IFD_NOTIFICATION events#18927
[juniper_srx] extract IP from RPD_IFD_NOTIFICATION events#18927ilyannn wants to merge 6 commits into
Conversation
Add a tag-specific grok in the system pipeline to extract the interface address from RPD_IFD_NOTIFICATION messages (pattern: "address #N <IP>") into host.ip and related.ip. Declare juniper.srx.system.if_trace and juniper.srx.interface_index fields surfaced by the message k-v extractor. Also avoid overwriting an already-populated message field when renaming juniper.srx.message. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
✅ Elastic Docs Style Checker (Vale)No issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
🚀 Benchmarks reportTo see the full report comment with |
Resolves conflicts in manifest.yml (keep 1.28.0) and changelog.yml (keep both 1.28.0 enhancement and 1.27.1 bugfix entries).
|
Pinging @elastic/integration-experience (Team:Integration-Experience) |
taylor-swanson
left a comment
There was a problem hiding this comment.
A few comments, and merge conflicts will need to be resolved.
| - name: if_trace | ||
| type: keyword |
There was a problem hiding this comment.
Do we really need if_trace? Could we drop the field instead? It seems to basically be the same as what's in message
There was a problem hiding this comment.
Good point, I've dropped it.
| - name: interface_index | ||
| type: keyword |
There was a problem hiding this comment.
I would prefer this to go to an ECS field, if possible, but the only two options for interface index would be (as a closest match):
- observer.egress.interface.id
- observer.ingress.interface.id
Two issues I see:
- Is interface.id mean the same thing as interface index?
- Can we determine the direction of traffic flow from this log?
There was a problem hiding this comment.
Sure, it seems to be the IFD/SNMP index which matches interface.id. This seems to be an interface up/down event without a direction, but since we don't have interface.id at the root level, I've used observer.ingress.interface.id for consistency with the existing processor:
- rename:
tag: rename_juniper_srx_interface_name_to_observer_ingress_interface_name_4023c7b6
field: juniper.srx.interface_name
target_field: observer.ingress.interface.name
ignore_missing: true
| target_field: message | ||
| ignore_missing: true | ||
| if: "ctx.juniper?.srx?.message != null" | ||
| if: "ctx.juniper?.srx?.message != null && ctx.message == null" |
There was a problem hiding this comment.
Are we getting complaints about overwriting an existing message?
There was a problem hiding this comment.
No, I just did not want to let juniper.srx.message field:
"message": "<Up Broadcast Multicast> agg_parent 0 address #0 175.16.199.0",
clobber the message field that is set in a different part:
"message": "IF_TRACE: EVENT <UpDown> st0.60 index 508 <Up Broadcast Multicast> agg_parent 0 address #0 175.16.199.0",
They come from two different places, one the key message and one the free text after the []:
<30>1 ... RPD_IFD_NOTIFICATION [junos@1111.1.1.1.1.111 ... message="<Up Broadcast Multicast> ..."] IF_TRACE: EVENT <UpDown> st0.60 index 508 <Up Broadcast Multicast> ...
Without the guard the rename just fails.
There was a problem hiding this comment.
We can fix the rename failure (clear the message first), but since we do have juniper.srx.message field in fields.yml it looked like we might want to use that field as well. The description of that field is not very helpful:
- name: message
type: keyword
description: |
mesaggeThis field is present in test-atp.log, for example:
"juniper": {
"srx": {
"message": "malware analysis detected host downloaded a malicious_file with score 9, sha256 ABC123",
and we don't rename it to message there.
…peline-tweaks # Conflicts: # packages/juniper_srx/changelog.yml # packages/juniper_srx/data_stream/log/_dev/test/pipeline/test-system.log # packages/juniper_srx/data_stream/log/_dev/test/pipeline/test-system.log-expected.json # packages/juniper_srx/manifest.yml
…index to ECS - Drop juniper.srx.system.if_trace: the generic k-v extractor surfaces it from IF_TRACE messages but it duplicates `message` (message minus the "IF_TRACE: " prefix). Remove the field and its declaration. - Also drop juniper.srx.system when the cleanup leaves it empty. - Map juniper.srx.interface_index (SNMP/IFD index) to ECS observer.ingress.interface.id, alongside the interface name that already lands under observer.ingress for these events. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
✅ All changelog entries have the correct PR link. |
|
No issues across the latest commits b934903, 363ff7a.
🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
|
💚 Build Succeeded
History
cc @ilyannn |
Summary
grokin thesystempipeline to extract the interface address fromRPD_IFD_NOTIFICATIONmessages (patternaddress #N <IP>) intohost.ipandrelated.ip.juniper.srx.interface_index(the IFD/SNMP interface index) to ECSobserver.ingress.interface.id, for consistency with the existinginterface_name→observer.ingress.interface.namerename (interface up/down events carry no flow direction).juniper.srx.system.if_trace: the generic k-v extractor surfaces it fromIF_TRACE:messages, but it just duplicatesmessage(message minus theIF_TRACE:prefix). Also dropjuniper.srx.systemwhen the cleanup leaves it empty.juniper.srx.message→messagerename withctx.message == nullso it does not fail (renameerrors on an existing target) or overwrite themessagealready populated from the event's free text.RPD_IFD_NOTIFICATIONtest case with fictional values.1.28.0.Test plan
elastic-package test pipeline -C packages/juniper_srx --data-streams log— all cases PASS.RPD_IFD_NOTIFICATIONtest event intest-system.logproduceshost.ip: ["175.16.199.0"],related.ip: ["175.16.199.0"], andobserver.ingress.interface.id: "508".elastic-package check -C packages/juniper_srxpasses (lint + build, README regenerated).🤖 Partially generated with Claude Code under my supervision.