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.

Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

Index This | What travels the world but is also stuck in place?

April 2026 Edition  Hayyy Splunk Education Enthusiasts and the Eternally Curious!   We’re back with this ...

Discover New Use Cases: Unlock Greater Value from Your Existing Splunk Data

Realizing the full potential of your Splunk investment requires more than just understanding current usage; it ...

Continue Your Journey: Join Session 2 of the Data Management and Federation Bootcamp ...

As data volumes continue to grow and environments become more distributed, managing and optimizing data ...