After upgrading our distributed environment to 10.2.x (multi-site indexer cluster, RHEL 8), the Search Head suddenly couldn't reach any of the indexer peers. Sharing the diagnosis here because the symptoms point you in the wrong direction at first. Symptoms Under Settings → Distributed Search → Search peers, all peers showed Status: Down. Searches returned no results from indexers, only local SH data. splunkd.log on the Search Head was full of peer auth / certificate errors, e.g.:     ERROR X509Verify - X509 certificate (CN=...) failed validation; error="certificate is not yet valid"WARN DistributedPeerManager - Peer:https://<indexer>:8089 is down. Replication status: Failed The "certificate is not yet valid" line was the giveaway — the cert wasn't actually bad. Root cause Clock skew. After the upgrade reboots, chronyd on several peers came back up without re-syncing to our internal NTP source, so the SH and indexers drifted apart by more than the tolerated window. Distributed search peer authentication and TLS validation both depend on synchronized clocks, so the SH read the peers' certs as "not yet valid" and marked every peer down. Nothing was wrong with Splunk itself. How to confirm     bash # Compare time across all nodes date # Check chrony sync state and offset chronyc trackingchronyc sources -vtimedatectl If chronyc tracking shows a large System time offset or Leap status: Not synchronised, that's your problem. Resolution     bash # Point chrony at your reliable NTP source (chrony.conf), then: systemctl enable --now chronydchronyc makestep # force an immediate step correction chronyc tracking # confirm offset is back near zero Once clocks were in sync across all hosts, I restarted splunkd on the affected peers and they came back Up in Distributed Search within a couple of heartbeats — no Splunk config changes needed. Takeaway If a 10.2.x upgrade leaves your Search Head unable to reach indexers and you see "certificate is not yet valid" or peer auth failures, check NTP/chrony before you start regenerating certs or touching server.conf. Add a post-upgrade step to your runbook to verify chronyc tracking on every node after reboots. ... View more

I want to exclude the (dst="10.0.0.0/8" OR dst="172.16.0.0/12" OR dst="192.168.0.0/16")  IP ranges.    my configurations: props.conf: TRANSFORMS-null = internal_Logs10, internal_Logs172, internal_Logs192 Transforms.conf: [internal_Logs10] REGEX = dst\=10\.0\.0\.0\/8 DEST_KEY = queue FORMAT = nullQueue [internal_Logs172] REGEX = dst\=172\.16\.0\.0\/12 DEST_KEY = queue FORMAT = nullQueue [internal_Logs192] REGEX = dst=192\.168\.0\.0\/16 #REGEX = dst=192\.168\.5.* DEST_KEY = queue FORMAT = nullQueue   it works perfectly for 192.168.5.* but not for subnet range. kindly share or assist with configuration around the same. ... View more

Curently our proxy logs with user having special characters inbetween. ref: DC=local/bob\, tom I have created a props.conf with SEDCMD-alter_user= s/\\,//g with which i am able to get the desired value but its too generic. ref: DC=local/bob tom Kindly assist me with the SEDCMD SEDCMD-alter_user= s/"local/"\\,//g ... View more

Our incident Review board has different view and not functioning as expected due to which we are unable to filter from the dropdown list Chrome: up to date (Version 57.0.2987.133 (64-bit)) Splunk Enterprise : 6.5.2 Splunk ES: 4.1 ... View more