We're in the process of upgrading our indexer cluster, with the plan ultimately being to phase out the old indexer cluster. At issue is that the new indexers have a mix of SSD's and HDD's that are on two separate volumes, and the old indexers only have one HDD volume. We had planned to use the "cluster fixup" method to do this migration, wherein we add the new indexers as cluster peers to the existing cluster, fix up the entire environment to replicate buckets onto the new indexers, take out one of the old indexers from the cluster, fix up the cluster again to replicate more buckets onto the new indexers, rinse and repeat until only the new indexers remain. The problem with this method lies with a disparity in where the indexed data will be stored between the old and new indexers. Since the new indexers have two volumes (that we will call /data/ssd and /data/hdd) and the old indexers only have one volume (that we will call /data), the homePath and coldPath for the indexes will be different within the indexer cluster. Example: OLD HOME PATH: /data/some_index/db NEW HOME PATH: /data/ssd/some_index/db OLD COLD PATH: /data/some_index/colddb NEW COLD PATH: /data/hdd/some_index/colddb How, if at all, can I have the cluster handle this? Some preliminary ideas: - Have a local indexes.conf on the new indexers that explicitly defines every index path during the migration and overrides what the CM distributes - Take a (big) outage on the cluster and manually move all the data within the old indexers to mimic the new structure (e.g. mv /data/some_index/db /data/ssd/some_index/db) ... View more

How would I show which users have accessed a particular dashboard in a given time frame? For instance, I want to see which users have looked at the Foobar dashboard this week. ... View more

I ingested a CSV into our dev environment, had it create the props stanza with the field extractions I wanted, and copied this over into our prod props.conf. This works as expected in dev; I can reliably add more logs that it picks up the fields on and does the extracts correctly. When the logs are ingested in prod, however, the source type is picked up but the extracts aren't being done. I open up the Source Types UI in both environments and they're identical. These are both using 6.4.3 (we're upgrading soon), and Splunk is not barking at me on restart that there are errors in my conf files. The only difference in environments is that dev is a standalone all-in-one, and prod is clustered search heads and non-clustered indexers. Stanza that was created in dev below: [obfuscated_stanza] DATETIME_CONFIG = FIELD_NAMES = Timestamp,Method,Timing,TransactionID,TrackingNumber,TransactionName,processID,threadID INDEXED_EXTRACTIONS = csv KV_MODE = none NO_BINARY_CHECK = true SHOULD_LINEMERGE = false category = Custom disabled = false pulldown_type = true ... View more

I'm in a setup with a license/deployment server, three clustered search heads and a deployer, and three non-clustered indexers. Per the documentation on setting up the DMC, I'm setting it up on the deployer. It picked up the indexers, but I can't get it to pick up my search heads and I'm not sure why. When I turn on forwarder monitoring, my search heads show up as heavy forwarders. How do I get the search heads to show up in the DMC? ... View more