Skip to content

[juniper_srx] extract IP from RPD_IFD_NOTIFICATION events#18927

Open
ilyannn wants to merge 6 commits into
mainfrom
juniper_srx-system-pipeline-tweaks
Open

[juniper_srx] extract IP from RPD_IFD_NOTIFICATION events#18927
ilyannn wants to merge 6 commits into
mainfrom
juniper_srx-system-pipeline-tweaks

Conversation

@ilyannn

@ilyannn ilyannn commented May 9, 2026

Copy link
Copy Markdown
Contributor

Summary

  • 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.
  • Map juniper.srx.interface_index (the IFD/SNMP interface index) to ECS observer.ingress.interface.id, for consistency with the existing interface_nameobserver.ingress.interface.name rename (interface up/down events carry no flow direction).
  • Drop the redundant juniper.srx.system.if_trace: the generic k-v extractor surfaces it from IF_TRACE: messages, but it just duplicates message (message minus the IF_TRACE: prefix). Also drop juniper.srx.system when the cleanup leaves it empty.
  • Guard the juniper.srx.messagemessage rename with ctx.message == null so it does not fail (rename errors on an existing target) or overwrite the message already populated from the event's free text.
  • Add a RPD_IFD_NOTIFICATION test case with fictional values.
  • Bump version to 1.28.0.

Test plan

  • elastic-package test pipeline -C packages/juniper_srx --data-streams log — all cases PASS.
  • New RPD_IFD_NOTIFICATION test event in test-system.log produces host.ip: ["175.16.199.0"], related.ip: ["175.16.199.0"], and observer.ingress.interface.id: "508".
  • elastic-package check -C packages/juniper_srx passes (lint + build, README regenerated).

🤖 Partially generated with Claude Code under my supervision.

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>
@ilyannn ilyannn requested a review from a team as a code owner May 9, 2026 17:08
@ilyannn ilyannn marked this pull request as draft May 9, 2026 17:09
@github-actions

github-actions Bot commented May 9, 2026

Copy link
Copy Markdown
Contributor

✅ 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.

@elastic-vault-github-plugin-prod

Copy link
Copy Markdown

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

@andrewkroh andrewkroh added documentation Improvements or additions to documentation. Applied to PRs that modify *.md files. Integration:juniper_srx Juniper SRX labels May 11, 2026
@ilyannn ilyannn self-assigned this May 18, 2026
Resolves conflicts in manifest.yml (keep 1.28.0) and changelog.yml
(keep both 1.28.0 enhancement and 1.27.1 bugfix entries).
@ilyannn ilyannn marked this pull request as ready for review May 18, 2026 19:17
@ilyannn ilyannn added enhancement New feature or request Team:Integration-Experience Security Integrations Integration Experience [elastic/integration-experience] and removed documentation Improvements or additions to documentation. Applied to PRs that modify *.md files. labels May 18, 2026
@infra-vault-gh-plugin-prod

Copy link
Copy Markdown

Pinging @elastic/integration-experience (Team:Integration-Experience)

@andrewkroh andrewkroh added the documentation Improvements or additions to documentation. Applied to PRs that modify *.md files. label May 18, 2026

@taylor-swanson taylor-swanson 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.

A few comments, and merge conflicts will need to be resolved.

Comment on lines +426 to +427
- name: if_trace
type: keyword

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.

Do we really need if_trace? Could we drop the field instead? It seems to basically be the same as what's in message

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Good point, I've dropped it.

Comment on lines +527 to +528
- name: interface_index
type: keyword

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.

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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"

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.

Are we getting complaints about overwriting an existing message?

@ilyannn ilyannn Jul 1, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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.

@ilyannn ilyannn Jul 1, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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: |
        mesagge

This 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.

ilyannn and others added 2 commits July 1, 2026 20:06
…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>
@ilyannn ilyannn requested a review from taylor-swanson July 1, 2026 19:12
@andrewkroh andrewkroh removed the documentation Improvements or additions to documentation. Applied to PRs that modify *.md files. label Jul 1, 2026
@ilyannn ilyannn enabled auto-merge (squash) July 3, 2026 13:41
@elastic-vault-github-plugin-prod

Copy link
Copy Markdown

✅ All changelog entries have the correct PR link.

@vera-review-bot

Copy link
Copy Markdown

No issues across the latest commits b934903, 363ff7a.

A new commit triggers another review — at most once every 15 minutes. I skip the PR while it's approved or has merge conflicts.

🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills

⚠️ Automated review — verify suggestions before applying.

@infra-vault-gh-plugin-prod

Copy link
Copy Markdown

💚 Build Succeeded

History

cc @ilyannn

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:juniper_srx Juniper SRX Team:Integration-Experience Security Integrations Integration Experience [elastic/integration-experience]

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants