Correct me if I'm wrong here - I believe the right way to do the hack I'm talking about is to break the new cluster (it has no data or function as of now), then copy the buckets from the Old Indexer to one of the New (and now standalone) Indexers, then re-instantiate the cluster, which will then replicate the buckets to all its new best friends. It's not trivial to reconfigure the cluster and its associated SHC, though.  I'm trying to avoid doing the eventtypes 'porkaround' because as you say, it will break a ton of searches, and I know the people who rely on those searches are not good at SPL; it will likely fall to me to cobble it back together. That will be time-consuming, to say the least.  Reindexing is also not an option - that sounds like a nightmare, from my cursory reading.  ... View more

That's unfortunate. I have super long retention requirements, so I'd effectively be permanently keeping all the old and new data in their separate sources. I guess I'm going to go with the bucket copying hack. I don't like it, but I don't see a better way.  ... View more

Huh. It must be an issue of WHEN I crunch the case, because this does the trick and gets the results I expect. The only zero hosts now are true zeros. Success! You're the best! Thanks so much for sticking with this and holding my hand through it. I'm going to accept the post with the main query as the answer for the next person. Cheers! ... View more

Expected:  host count HOST1 11111 HOST2 22222 HOST3 33333 Actual:  host count HOST1 11111 HOST2 22222 HOST3 0 host1 0 host2 0 host3 33333 Does that make sense? I get HOSTx and hostx (the lookups are all uppercased), and on one or the other there are zero events counted - but they're the same host. ... View more

Ah, I see what you mean. Righto. So, then I end up getting the same results as explained, with ~10% of hosts showing up with different-case duplicates - one with appropriate event counts, and one with zero. Any thoughts on what's going on there? ... View more

Thanks. I've tried a very similar permutation today, but this brings back the problem I had at another point: I get about a third more results than I should, and they're duplicates (one uppercase, one lowercase). If I cast the host field to upper or lowercase before the stats max command, I get the correct number of hosts but around 10% then erroneously return 0 events. E.g.    | tstats count where [ | inputlookup file.csv ],index=* by host | append [ | inputlookup file.csv | eval count=0 ] | eval host=upper(host) | dedup host | stats max(count) as count by host     Expected result:    host count HOST1 12345 HOST2 67890 HOST3 24680     Actual result:   host count HOST1 0 HOST2 67890 HOST3 24680     But if I search for HOST1 or host1 manually, there are many thousands of events in the same time period. Since field values are supposed to be case-insensitive (IIRC), I'm stumped as to why case is relevant here. It's trivial to do the case-casting in the actual lookup file if appropriate, but I think there's one more piece missing somewhere. ... View more

This was close to what I want to do:   | tstats count where [ | inputlookup file.csv ],index=* by host   But it doesn't include hosts from the lookup that have no events, which I want to include. Adding a fillnull afterward doesn't do it.  ... View more

Thanks. I did start out using index=* as well, but I forgot about it. I still get null values for way too many hosts, but I can search for them directly using the same syntax (i.e. index=* and short hostname as found in the inputlookup) and get many thousands of events. It's making me nuts because it seems like it should be super straightforward! ... View more

Thank you for the detailed explanation. I'll try this in test and see how it works with my dataset.   I suppose it isn't the end of the world if only newly indexed events have the short name, but I know my security folks will hate that answer. It'll be irritating to go back and edit every dashboard panel deployment-wide to accommodate the two-name dichotomy for historical searches. ... View more

Nope, I don't have anything like that.  ... View more