How to configure props.conf and transforms.conf to replace host with FQDN in syslog events?

[_smp_]

Hello,

New Splunk user here. I have a syslog input consuming messages from a bunch of different hosts. Most PTR records resolve just fine and the host is correctly assigned. But I have a couple of IPs whose PTR records do not resolve, and for reasons outside my control, I cannot fix them.

For these hosts, Splunk is populating the host field with the IP address. I'd like to change that to be a statically assigned name that I choose. I've been doing some reading and it seems there a quite a variety of techniques to do this, but I'm not sure which one is appropriate for this case. Ultimately my goal is to simply find these events using host=.

Is the props/transforms approach the right one here? If so, is there a generally-accepted regex to use for this case? Since Splunk has already correctly picked out the IP address, I'm not sure if 'assigning host based on event content' is applicable here.

[jrodman]

You can use props & transforms to alter the text of the event if you want, and you can also or independently use props & transforms to modify the host key. One or both might be your priority.

I think this is the only mechanism to have the events land in the index with the new text or new host values initially. There are a variety of means to, at search time, translate IP addresses to the current mapped hostname, or a historical mapped hostname, but it might not really be a "first class" experience. It somewhat depends upon the searches you plan to write how important this is.

The down side of this type of approach is it's going to be a bit of a burden to maintain those props & transforms in Splunk if you have a significant number of translations to make. One alternative is to do something like allow rsyslog to accept the data and splay it out on disk by sending hostname. It might be easier to do special case rules in rsyslog or in the inputs layer of your Splunk configuration for setting the host= values.

[_smp_]

Thanks for the response. I think what I want to do is to use "props & transforms to modify the host key". In fact, I was doing a little testing after I posted this and I achieved what I needed with the following props/transforms:

[host::<IP address>]
TRANSFORMS-<hostname>=<hostname>_override

[<hostname>_override]
REGEX = (.*)
DEST_KEY = MetaData:Host
FORMAT = host::<FQDN>

Does that seem like a reasonable thing to do with only two or three hosts?

[jrodman]

It might be helpful to amend your question to include the scenario you expand here , so we can have a clearer question/answer.

That aside, yes, if the reverse dns behavior is stable, and the host set is not very dynamic, then this may well be the best way for you to handle it.

As a caveat, I'd like to mention two possible concerns about rdns host:

• For syslog, we try to get the host out of the text events by default in a transform. If you have that behavior on, try to ensure that your transform happens second. I prefer to do this by making the TRANSFORMS-x setting a list, e.g. TRANSFORMS = syslog-host-thing , your_override I forget our default name. You can alternate rely on our default ordering but it relies on the name of the TRANSFORMS setting so be careful.
• If that's not happening (for some reason, or you configured it off), and you are relying on the reverse DNS behavior of data-accept, then be aware that many people end up turning this off if they don't have reliably good-performance DNS access. Slow DNS queries can slow data acceptance.

[_smp_]

Thank again for your continued assistance.

It might be helpful to amend your question
I tried, but my reputation is not high enough yet to post more than two questions/day.

There's much about your reply that I do not yet understand:

If you have that behavior on
How do I know if I have that behavior on?

I understand what you mean by making the TRANSFORMS-x setting a list and specifying my stanza second. But when I look at my default/transforms.conf, I see two transforms related syslog hosts. How would I figure out which one I should put ahead of mine?
[syslog-host]
[syslog-host-full]

you are relying on the reverse DNS behavior of data-accept
Not sure what that means exactly. I have this statement in my inputs.conf - is this what you mean by having it configured on or off? In your experience if people "turn it off" because of slow DNS, do they typically just deal with host= in their queries? Or do they use the technique I'm using?
connection_host = dns