I am getting error "Cannot get username when all users are selected" on the splunkweb when i ran any search. I have tried deleting cookies, it didnt work. I am using AWS ELB for load balancing the 3 clustered indexers. Is there any issue regarding load balancing configuration?
I solved this issue with a client by ensuring that the the load balancer (f5 in our case), sitting in front of our search head cluster, had session persistence set.
"Configure the load balancer so that user sessions are "sticky" or "persistent." This ensures that the user remains on a single search head throughout their session."
quick google led me here:
Just to clarify, you mention you are load balancing the 3 clustered INDEXERS?
Does this just mean you are load balancing the splunk web sessions (ie port 8000) to these indexers? Or are you sitting an LB in front of your indexing port (ie 9997) ?? (this is generally a "No-No").
Yes, I'm load balancing the splunk web sessions (ie port 8000) to these indexers.
I have checked with my client and ensured the stickness enabled by doing following configurations:
To enable duration-based sticky sessions for a load balancer using the console
But still the error is not resolved..
did you ensure to log out of all the SH and clear your browser cache? Just a thought.
Would have to look into the aws elb configs to understand if the settings you shared are enough. Will try and have a look.
I have ensured logging out all SH and also cleared browser cache. It did not work.
I have a doubt- when the load balancer bounces to other node(server) why is it not prompting to splunk login page?
Because it should be an authenticated session not requiring login....did you get it fixed?
Thanks mmodestino! Issue resolved by including duration based stickiness settings in the AWS ELB. Previously, Our AWS team configured these settings to different ELB.
ha! thats funny, our LB team thought they configured it too, and had to go back and double check! Glad you are up and running!
just had the same error message on a standalone test instance in a VM.
looking at internal log, the root cause is disk space