Knowledge Management

Can a search macro have a default value for a parameter?

dsollen
Explorer

The question statement says it all. I was wondering if I can create search macro where some of the fields are predefined. If the caller of my macro gives me one argument, I use the default value for the second argument. If I'm given two, I overwrite the default value for the second argument with whatever is provided. In the off chance that my actual use case is relevant, it's below, but frankly, you probably don't need to read it to understand the question 🙂

I'm writing a simple search macro, which will create field which specifies, rather, a given ip address is ipv4 or ipv6. so roughly this:

eval $ip_type_field_name$ = if(`is_ipv4($ip_addr$)`, "ipv4", if(`is_ipv6($ip_addr$)`, "ipv6", "invalid format"))

This is intended to be a very generic macro so many people can reuse it, so I'm allowing them to decide what the name of the new field created is rather then overwriting it. They could, for example, use the macro twice like this:

`my_complex_search_here` | `get_ip_type(src_ip, "src_ip_type")` | `get_ip_type(dest_ip, "dest_ip_type")`

However, most of the time that extra flexibility isn't needed. I could pick some name, like "ip_type" for the field I create and 80% of the time someone using this macro will be happy creating the field with that name, and I actual prefer standardizing to a standard name for everyone using the macro just to keep fields having consistent names when possible.

I would prefer for someone to call 'get_ip_type', and if they pass in a single IP, I create the "ip_type" field with my type string. If they need more flexibility, they can call with a second argument and that argument will define what I name the field created by the macro.

1 Solution

sideview
SplunkTrust
SplunkTrust

What I do in these situations is define two macros, one that takes the second argument and one that does not. Then you can make the one that does not simply refer to the more explicit macro, passing in the default explicitly.

[get_ip_type(2)]
args = ip_addr, ip_type_field_name
definition = eval $ip_type_field_name$ = if(`is_ipv4($ip_addr$)`, "ipv4", if(`is_ipv6($ip_addr$)`, "ipv6", "invalid format"))

[get_ip_type(1)]
args = ip_addr
definition = `get_ip_type($ip_addr$, "ip_type")`

You can of course take this further and declare a third version that takes no arguments, etc.

View solution in original post

sideview
SplunkTrust
SplunkTrust

What I do in these situations is define two macros, one that takes the second argument and one that does not. Then you can make the one that does not simply refer to the more explicit macro, passing in the default explicitly.

[get_ip_type(2)]
args = ip_addr, ip_type_field_name
definition = eval $ip_type_field_name$ = if(`is_ipv4($ip_addr$)`, "ipv4", if(`is_ipv6($ip_addr$)`, "ipv6", "invalid format"))

[get_ip_type(1)]
args = ip_addr
definition = `get_ip_type($ip_addr$, "ip_type")`

You can of course take this further and declare a third version that takes no arguments, etc.

Get Updates on the Splunk Community!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...