Our two heavy-forwarders serve as intermediate for our hundreds of universal forwarders. I'm working on overriding/fixing hostnames to 6 of them. Here's the issue:
Six of the UFs have hostnames with "-NEW" at the end. We want to remove that "-NEW" at parsing/indexing phase (not SH phase). Instead of working with the sysadmins of those 6 servers over a Zoom web conference to fix the hostname at the UF's system-local end, we decided to push a deployment-app to the 2 intermediate heavy-forwarders. The app contains these configs:
# transforms.conf
# Of course, I'm using Dragon Ball Z characters as server names so that I don't get fired
[hostname_overrider]
DEST_KEY = MetaData:Host
SOURCE_KEY = MetaData:Host
REGEX = host::^(GOKU|VEGITA|GOHAN|GOTEN|TRUNKS|BULMA)(?:\-NEW)$
FORMAT = host::$1
# props.conf
[default]
TRANSFORMS-hostname_overrider = hostname_overrider
My thinking is that the transforms and props configs will apply to all UFs but will only catch the 6 servers because of the specific REGEX pattern and override the hostname.
This method is not working. Any thoughts on why and which is the better approach to take?
There is a better way of doing this from UF itself if your UF is managed by deployment server.
you need to deploy an App which will override host in inputs.conf of deployment client.
you can avoid all the events coming from those UF going through the transform you created.
I agree that it is a better solution. However, I thought of using this approach to be more future-proof. Sending deployment-app containing inputs.conf with the proper hostname entails 6 deployment apps. What if the problem happens to 350 UFs? I will have to create 350 deployment-apps each containing inputs.conf with the proper hostname.
Or I may be wrong and there's a better way to do it. 🙂
You are right. You will end up to have apps as many wrong hostnames you have.
I have given you solution based on your existing problem.
but I recommend to correct issue at the source if possible.