Mapping of Gigamon Metadata Attributes to ECS#14665
Mapping of Gigamon Metadata Attributes to ECS#14665apps-elastic-gigamon wants to merge 2 commits intoelastic:mainfrom
Conversation
apps-elastic-gigamon
commented
Jul 23, 2025
apps-elastic-gigamon
commented
- Enhancement
- Have mapped the Gigamon metadata attributes which are required for creating AMI starter Pack dashboards to ECS fields
- Tested the changes by adding the relevant metadata fields to test-ami.json and validating the corresponding expected results json.
|
💚 CLA has been signed |
andrewkroh
added
documentation
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
|
/test |
1 similar comment
|
/test |
💔 Build Failed
Failed CI StepsHistory
|
apps-elastic-gigamon
force-pushed
the
main
branch
from
66865e7 to
f43839f
Compare
apps-elastic-gigamon
changed the title
packages/gigamon/changelog.yml
Outdated
| changes: | ||
| - description: Mapped Gigamon Metadata attributes to ECS fields | ||
| type: enhancement | ||
| link: |
There was a problem hiding this comment.
| link: | |
| link: https://github.com/elastic/integrations/pull/14665 |
| - gigamon.ami.smb_filename | ||
| - gigamon.ami.smb_host | ||
| - gigamon.ami.smb_path | ||
| if: ctx.tags == null || !(ctx.tags.contains('preserve_duplicate_custom_fields')) | ||
| ignore_missing: true |
There was a problem hiding this comment.
Don't remove any of the gigamon.ami.* custom fields before updating dashboards, because these are still being used inside dashboards and the default value of preserve_duplicate_custom_fields is false. So, all these custom fields will be deleted by default, which we don't want to happen yet resulting in empty dashboards.
| - set: | ||
| field: gigamon.ami.dns.tunneling | ||
| tag: set_dns_tunneling | ||
| copy_from: gigamon.ami.dns_tunneling | ||
| if: ctx.gigamon?.ami?.dns_tunneling != null |
There was a problem hiding this comment.
Both gigamon.ami.dns_tunneling and gigamon.ami.dns.tunneling are custom fields. There is no difference between them other than extra nesting (_ vs .). If you use a set processor here, you will have both fields.
Why to create 2 custom fields here populating the same value?
If you want to only have the field named gigamon.ami.dns.tunneling (i.e., with nesting), you could use a rename processor instead. Rename processor renames the existing field itself, instead of copying value into another field (like set processor).
Example of rename processor:
- rename:
field: gigamon.ami.dns_tunneling
tag: rename_dns_tunneling
target_field: gigamon.ami.dns.tunneling
ignore_missing: trueAlso, I suggest if you take this approach you (extra nesting with .), then do this consistently. You shouldn't have some custom fields with gigamon.ami.dns_xyz and others with gigamon.ami.dns.xyz and same for other apps also http, ssl, etc.
| - set: | ||
| field: source.ip | ||
| tag: set_source_ip | ||
| copy_from: gigamon.ami.src_ip | ||
| if: ctx.gigamon?.ami?.src_ip != null |
There was a problem hiding this comment.
After populating source.ip, apply these 4 processors (2 geoip, 2 rename) so that appropriate ECS geo fields are also populated.
| - set: | ||
| field: destination.ip | ||
| tag: set_destination_ip | ||
| copy_from: gigamon.ami.dst_ip | ||
| if: ctx.gigamon?.ami?.dst_ip != null |
There was a problem hiding this comment.
After populating destination.ip, apply these 4 processors (2 geoip, 2 rename) so that appropriate ECS geo fields are also populated.
| - set: | ||
| field: destination.ip | ||
| tag: set_destination_ip | ||
| copy_from: gigamon.ami.dst_ipv6 |
There was a problem hiding this comment.
What if both dst_ip and dst_ipv6 are available in data? Which one should take preference for populating destination.ip?
Similarly for src_ip and src_ipv6 .
| - name: http | ||
| type: group | ||
| fields: | ||
| - name: response.content_encoding | ||
| type: keyword | ||
| - name: response.headers.set_cookie | ||
| type: keyword | ||
| - name: snmp | ||
| type: group | ||
| fields: | ||
| - name: version | ||
| type: keyword |
There was a problem hiding this comment.
This is exactly how we shouldn't name the custom fields. If ECS fields are created with these exact name in future, there could be mapping conflicts.
What if you just put them all under gigamon.ami just like other custom fields?
| - name: gigamon.ami | ||
| type: group | ||
| fields: | ||
| # base fields | ||
| - name: dns.tunneling | ||
| type: keyword |
There was a problem hiding this comment.
I am curious with the approach here. If we are nesting custom fields inside gigamon.ami anyway, then is there any reason to call the field dns.tunneling over dns_tunneling (i.e., what we already have)?
I just don't want some custom fields to be called gigamon.ami.http_xyz and some other gigamon.ami.http.xyz. We need consistent naming whichever approach we choose (_ underscore vs . dot).
All fields inside fields.yml uses _ underscore, and all fields inside ecs-custom.yml uses . dot. This is highly inconsistent. I am starting to believe you don't need to add file ecs-custom.yml at all.
I suggest you continue to use underscore _ (instead of . dot) inside custom fields names and add any missing custom fields into fields.yml itself.
andrewkroh
added
Integration:system
apps-elastic-gigamon
force-pushed
the
main
branch
from
8d6e72b to
6aca538
Compare
* Add links panel to System Dashboards * Update changelog and manifest for system integration * Add PR link to changelog * Update minor version system --------- Co-authored-by: Linu-Elias <linu.elias@elastic.co>
apps-elastic-gigamon
force-pushed
the
main
branch
from
6aca538 to
9666a26
Compare
|
Messed up with commits and amend. Will raise a new PR addressing these comments |
5 participants
