So I'm doing a bit of research prior to rolling out Deployment Server & Clients... and I was thinking about leveraging Client Name in identifying different server classes to apply to various clients. In reviewing documentation, I came across this note:
Important: Client names should be unique.
While by default this is the same as the instance GUID, it seems that instanceID/guid is a separate field from clientName as recorded on the deployment server, as can be seen from this search:
| rest /services/deployment/server/clients splunk_server=local | fields - applications.* eai:* serverClasses.*
What consequences are there if we were to have identical client names across hosts that perform the same role in the environment? What benefits are gained with unique client names?
The DS will by default use the hostname of your forwarders if no client name is set.
I think its generally accepted hostnames should be unique (more in a sec..)
If you have systems which may be hosted by a 3rd party, and therefore have no control over the hostname, you can set the client name to match a format of your choosing. The DS will prefer the client name if its set, so I regard this as a 'hostname override'. For the same reasons I think the expectation is that these are also therefore, unique.
What is more critical is that the GUID is unique - it is this which determines how many clients the DS 'sees'.
We recently had a situation where hostnames were different but all clients shared a GUID (whoops) - The DS saw these as one client.
However, as long as GUIDS are distinct, duplicated hostnames (or client names) will show as separate clients in the forwarder management console. I have this very situation (not deliberately) and it works as you would expect, however clearly they will always get the same serverclasses, and Its not ideal from a search perspective either, but given the caveats above, I have not had any issues or limitations with duplicated named beyond what you would expect (although I do plan to fix it)
The DS will by default use the hostname of your forwarders if no client name is set.
I think its generally accepted hostnames should be unique (more in a sec..)
If you have systems which may be hosted by a 3rd party, and therefore have no control over the hostname, you can set the client name to match a format of your choosing. The DS will prefer the client name if its set, so I regard this as a 'hostname override'. For the same reasons I think the expectation is that these are also therefore, unique.
What is more critical is that the GUID is unique - it is this which determines how many clients the DS 'sees'.
We recently had a situation where hostnames were different but all clients shared a GUID (whoops) - The DS saw these as one client.
However, as long as GUIDS are distinct, duplicated hostnames (or client names) will show as separate clients in the forwarder management console. I have this very situation (not deliberately) and it works as you would expect, however clearly they will always get the same serverclasses, and Its not ideal from a search perspective either, but given the caveats above, I have not had any issues or limitations with duplicated named beyond what you would expect (although I do plan to fix it)
In the scenario where GUIDs were the same, but hostnames/client names were different... while your reporting views in the DS were all kinds of wonky, did the different hostnames get their appropriate distinct sets of apps? or were they all the same type of server thus no differing sets of apps?
In my case, all of the duplicate guids were the same type (VDI workstations) and the duplication occurred during the clone. - As a result all of the dupes were supposed to get the same apps anyway so everything worked perfectly, and we were none-the-wiser. I only noticed when i needed to target something at a specific machine, and i wondered why i could only see one in the console instead of 300 🙂