Contact details are provided on the Splunkbase app page. You can try mailing the author if app's behaviour/configuration is not obvious beyond what is described in the Details and Installation tabs (I admit, the Splunk API key use is not obvious for me either) ... View more

Your SPL is quite straightforward so either: 1. The fields you're trying to use are not extracted and you're trying to use fields which aren't there. Or 2. The fields are ther but aren't numerical. The usual case is when they are multivalued ... View more

I'm not quite sure what you mean that your server has "NAT IP". I suppose you mean that it can be reached by means of connecting to IP A which is by some router NAT-ed to IP B which is your server's address. Generally speaking, in order for the TLS connection to be considered properly validated, the cert presented by the server must: - come from the certification chain originating at CA trusted by the client - the whole chain must not break any constraints and must not contain expired certs (I'm not 100% sure of validity of non-expired certs which had been issued by CAs which already expired) - the subject you're connecting to (either host name or IP, depending on what you are using to initiate the session) must match the data in the certificate presented by the server (either the subject field or one of the Subject Alternative Name (SAN) values) So if you have your server configured at 192.168.101.101 to which your internal DNS points from splunk.local hostname and your certificate is issued for splunk.local hostname only (or for both the hostname and 192.168.101.101 IP although it's a common practice to _not_ issue certs for IPs) it will _not_ be valid for any other name or IP. So if some part of your company would try to connect to your Splunk at 172.16.101.101, the cert will not match properly. If they use a name of splunk.external.local, it won't match either obviously. As far as I remember, while you can bind different certificates to specific inputs (although TLS settings on inputs have their share of problems), I don't recall binding separately (with different certificates) with webui instances. So you must either make sure that all your users connect using the same name(s) which are resolved by DNS to IPs apropriate for the client's environment (which can be tricky) or you must add all "endpoints" (names and IPs) as SANs to your certificate (which is very ugly and possibly leaking information especially if you're mixing private and public names and IPs; whatever private and public means in your case) ... View more

In this case you can just take down servers one by one generally in any order. Just remember to enable maintenance mode on the cluster so it doesn't start rebuilding searchable copies immediately. ... View more

There are some unknowns here. Do you actually have a 1+1 cluster? What is your RF/SF? What is your data flow? I'm assuming you want to have as little downtime as possible, right? Remember that forwarders can and will pause inputs if they cannot send to outputs (if those are the "stoppable" inputs; you can't "hang" syslog packets on a wire). Also you will undoubtedly have downtime during SH upgrade. Generally in a normal scenario you should not be needing to "point" anything anywhere becaue in a well-engineered setup you should be load-balancing outputs over your available indexers so any single-node downtime should not affect ingest flow. Also, be very careful about the in-place windows upgrades. They can go wrong. I would consider doing backup/restore over a clean server. As long as the names and IPs stay the same, the process should be trivial. Especially if you indeed have index storage on a separate storage which can be easily "plugged into" a new/restored instance. ... View more

If you want to anonymize your data, please use another character/string as placeholder. Asterisk has its usual meaning as a wildcard and thus is expected to be taken literally when encountered in such context. That's one. Two - The usual technique of avoiding join is appending two searches and doing stats over the combined result by common field. But. This requires planning since if you simply use the append command you can still hit the limits for subsearches and get incomplete/wrong results. You can use multisearch to fetch data from multiple searches but those searches must be streaming ones (i.e. cannot contain stats command). Three - it still doesn't solve the problem that you're trying to create the sat_host field based on value of a non-existent field. ... View more

OK. There are several things which catch my eye right off the bat. hostname!="*.corp" Two things "wrong" here (I mean, the search will run but it will be terribly inefficient). 1. Inclusion is better than exclusion. Splunk searches events by search terms and only those pre-selected events are verified against field extractions. In other words, if you do hostname=foo  Splunk will find all events where there is a "foo" anywhere and will check which of those has "foo" in place of the hostname field. If you do hostname!=foo Splunk has to check every single event to see if it contains "foo" and if it does, is it in the hostname spot or not. 2. Splunk indexes terms which come from splitting the input data on breakers (spaces, tabs and such). And keeps a lexicon of those terms with entries pointing to the events containing those terms. So if you're looking for "foo" or "foo*" Splunk can find in its lexicon all entries being "foo" or starting with "foo". If you do "*foo", there is no such magic. Splunk has to scan every single event to find this string. Another thing - eventstats is a relatively "heavy" command. I assume that since you're pulling data from some summary, you might have it already relatively well "compacted" but in a general case, be aware that it can be very memory-consuming since it needs to have whole result set to operate on. And probably the main culprit -  join type=inner sat_host [ search index="its-*-*tec-app" sourcetype="*:*:agent:reports" source="D:\\*eData\\*Agent_*.csv" earliest=-1d latest=-1m" | rename "Machine Name" as sat_host | eval sat_host = upper(sat_host) | stats latest(IP) as IP latest(Version) as Version_*, latest("Last Update Received") as last_update_recieved by sat_host] 1. You can't just write "as Version_*". Wasn't it supposed to be "latest(Version_*) as Version_*" (wildcard on right side of AS is allowed only as a match to left-side one). 2. More importantly - join with a raw event search usually ends in tears. Join command is usually best avoided altogether. Sometimes it's ok with a predictably fast search (like a small tstats or inputlookup). It practically never ends well with an index search. Join has a lot of limitations (result count, execution time) so it can get silently finalized and produce wrong/incomplete results without you ever knowing it. 3. You're joining on sat_host field which obviously (if your results before the join really look like what you're showing from the csv dump) does not exist in your data. You're doing  | stats latest(os) as os latest(Last_Status_time) As Last_Status_Time by sat_host Which leaves you with fields: - os - Last_Status_Time - sat_host so when you arrive at | eval sat_host=upper(replace(DeviceName, "\..*$", "")) there is no DeviceName field in your result set. ... View more

This is a "search app" it makes no sense to install it anywhere else. Also, quoting the Splunkbase description: "This add-on is available for Linux (64-bit), Windows (64-bit) and Mac. Make sure you install the appropriate one for your Splunk deployment." Notice the "appropriate for your Splunk deployment", not "for your endpoint". ... View more

There are some unknowns here regarding your detailed use case and data but I see you're already pretty proficient with debugging Splunk's internal workings. 😉 I do not have anything to support my suspicion but I have a feeling that since Splunk has changed over last few big versions around indexed fields autodiscovery I suppose it might be adding that lispy part for indexed field "just in case" and it could be difficult to get rid of.  Anyway, the lispy is sound. Splunk should not just "give up" on scanning the lexicon. What I'd try first (assuming that since your lispy shows just one VALUE) is verifying how many results you'd  get with  index=indexhere sourcetype="json_sourcetype" TERM(VALUE) (Choose a value which is unlikely to appear in other fields). You'll see if Splunk has this term correctly indexed and only has problems with parsing. If your event is big enough, you could be hitting some limits on auto-kv number of fields... ... View more

I don't recall this app having any web-configurable settings in this up. You're supposed to configure your ISE to send the logs to your Splunk via syslog and receive the syslog on your Syslog, possibly using SC4S or another syslog component. There are no modular inputs to configure in this add-on as far as I remember. ... View more

To be precise, the 50k rows limit applies to the join command. The general subsearch limit is just 10k restults. (and you have time limits for subsearch execution). And about the original question - if you have a search which returns inconsistent results, unless it contains an element of randomness, it means it hits some limits and is finalized in different moments and needs reworking. In this case, as @gcusello already pointed out, you're using the join operation which is generally strongly advised against. There are some specific use cases for it but it's best avoided in a typical case. The easiest approach to your search would be probably to reverse the order of operations - do a search and apply the lookup. The upside of this is that such search can be relatively well parallelized and the lookup will be matching on indexers. The downside is that if the lookup is huge it will not be very fast since for csv-based lookups (and if the lookup gets distributed to indexer, you're dealing with a csv export even if the original lookup was kvstore-based) the match done by linear matching from the top of the file. It should still be faster than join anyway. So you should simply do something like index="maj_p" OnboardingStatus=Onboarded OSPlatform=windows1* | stats latest(OnboardingStatus) as OnboardingStatus, latest(SensorHealthState) as SensorHealthState, latest(OSPlatform) as OSPlatform, latest(ClientVersion) as ClientVersion, latest(_time) as Def_Lastseen by DeviceName | eval Week_breakdown=case(Def_Lastseen>=relative_time(now(), "-7d@d"), "1-7 days", Def_Lastseen>=relative_time(now(), "-15d@d") AND Def_Lastseen<relative_time(now(), "-7d"), "8-15 days") | eval nt_host=upper(replace(DeviceName, "\..*$", "")) | lookup workstations (you had an error here; you can't have an asterisk in lookup name) nt_host <possible OUTPUT something AS something rules> | where hostname!="*.corp" (dv_install_status IN ("In use", "In stock") OR ds="dal" OR (seen_by_obt="n/a" AND ds!="dal")) AND (seen_by_cs="Yes" OR seen_by_q="Yes" OR seen_by_sccm_status="Yes") AND (os="Windows" OR os="WINDOWS") Now there comes a part which I don't understand. You're doing | eventstats count as scope_count Which gives you a field with the same value across all results. And then you're doing  | stats count as agent_count by scope_count I don't get it. You had an inner join so you can't have results which have a different scope_count value than the "main" one or don't have this value. Anyway, if you want to have the size of the lookup, you can do - for example | appendcols [ | inputlookup <...> | stats count as scope_count ] at the end to add this count. It's a fast operation so it should execute properly. ... View more

The add-on should not "do" much on the UF anyway. The "main" inputs (the .exe files) are built into the UF it, the scripted inputs generally rely on PowerShell and I don't think they change between versions that much anyway. ... View more

I don't think there are any public documents describing Splunk search process in that level of detail but I'd assume - from pieces here and there, and the available settings in limits.conf - that Splunk would try to keep stuff in RAM as long as it can (as long as it doesn't hit configured limits). If it exceeds the limits it dumps the data into intermediate files. Dig through spec file for limits.conf, the [stats] section for more info. ... View more

You have to do it manually. Format of the file is documented here - https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/10.4/configuration-file-reference/10.4.0-configuration-file-reference/default.meta.conf (for some reason it's incorrectly named in the docs but the description is OK).   ... View more

I'm not sure what you're asking us about. You need to build an inventory of your sources including ingestion methods. Both what you have and what is configured on your Splunk components. Then compare those two. ... View more

You can't change the email associated with the account. Since you don't have access to the old email requesting for deletion might prove tricky since you have no way to prove ownership of said axcount. ... View more

It depends on the actual files (and the upgrade process - RPM/deb should remove old files, simply unpacking tgz over old directory won't). ... View more

I suspected something along those lines 🙂 It's just that it's a bit counterintuitive since usually in configs you have some default units which can be omitted. This case is different so I pointed it out because the behaviour can be a bit unexpected. ... View more

What is important here and is easy to miss is that you need to set dropEventsOnQueueFull=0ms dropClonedEventsOnQueueFull=0ms Not just plain "0", it must be "0ms"!  ... View more

The docs for the add-on - https://community.sailpoint.com/t5/Identity-Security-Cloud-Wiki/SailPoint-Identity-Security-Cloud-AuditEvent-Add-on-for-Splunk/ta-p/77123#toc-hId--933693274 Say this: NOTE: As of version 2.0.0, if the Splunk add-on loses its connection to Identity Security Cloud (manually disabled, credentials are removed, etc) for longer than a 24 hour period, it will begin collecting events from the time of reactivation/reconnection. For administrators, this means that if the add-on collection is suspended longer than 24 hours, audit events for this time period will not be available in Splunk. These events will still be retrievable via the IdentityNow API's. I would read it as "the app reads at most 24 hours of backlog data". And it seems to be by design. You could fiddle with the add-on internals if it's in a readable form (I haven't checked if it's in python, as a binary or whatever). ... View more

I would back up my current config/state, do wipe & reinstall and then restore config/state. ... View more

One additional thing about your manual calculating event length (option B). It is (or at least doesn't have to be) _not_ accurate. Your license is consumed with _bytes_ you're writing to the index. And all Splunk's functions (including len()) operate on characters. If you have an US-ASCII text, both bytes and character counts will be the same but if you're getting into area of more complicated UTF-8 code points, your len() counts might be way off. ... View more

Moved. ... View more

08-12-2026 05:55:49.911 ERROR S2BucketCache [2772400 localCollectorThread] - waitFor probe, cache_id="bid|splunk_index~458~2366B991-21E7-46B8-A1A5-DA16C9370DBC|", did not localize all files before reaching download_status=idle files={"file_types":["tsidx","deletes"]} local_files={"file_types":["sourcetypes_data","sources_data","hosts_data","bucket_info","bfidx"]} failure_code=0 failure_reason=Cache was full and space could not be reserved AFAIR this error means that your local Splunk indexer didn't have enough space (and couldn't make enough space free) to pull the bucket filex to cache. Cache manager knows that there is a remote file in Smartstore but couldn't download it. Check your Smartstore activity in Monitoring Console. ... View more

You can just make an alert based on | rest /services/admin/summarization/?by_tstats=1 ... View more