The TRUNCATE setting is responsible for truncating overly long events. It has nothing to do (except of course for truncating the json prematurely) with any other problems with parsing json/extracting fields from it.   ... View more

As a rule of thumb (with some small exceptions) index-time settings "work" on the first "heavy" component your event goes through. So if you have an inermediate HF layer so that events from your UFs go to HFs and from them are forwarded to indexers, you need those settingns on the HFs. If you have a standalone HF ingesting jsons (from HEC input, pulling from remote with API and so on) you also need those settings on this HF. ... View more

You are aware that you're replying to an 11 years old post? ... View more

1. As I wrote before, transform will fire only once. Use a ruleset. 2. Use simple = instead of := in INGEST_EVAL. This will create multivalued fields. Yes. I tried doing it your way so that you have a single value with the whole chain but the := operator's performance is worse than straight assignment, it's easier to look for single values and the more intermediate steps you have, the more cardinality of your field raises. 3. I would be very cautious about using a transform (or ruleset) class called "default". It's a very popular word, it's easy to cause namespace clash. ... View more

You are right, by default Splunk doesn't capture this information. You can use a ruleset (not transform since it would only be fired once) to add an indexed field to your event on each step along the way. But it only works on a "heavy" component. ... View more

With timestamp assignment set to CURRENT the TZ setting doesn't matter since the timestamp is getting assigned based on the receving component's OS time. ... View more

It's not that easy. Firstly, we have no idea what your configuration is (mostly inputs and outputs are of interest here) Secondly, there is a very good question why didn't the forwarders stop and wait. Thirdly, generally there is no native way to manipulate forwarder's internal state from remote. There are some ugly hacks to do it but I will not promote them here since it's very easy to shoot yourself in the foot that way. Fourthly, with a normal desktop edition of windows 22 hours should not produce too many logs but on a busy server, depending on your configuration, that data could already have been overwritten if you hit the size limit. Fifthly, if you do have the data on the other hand, removing checkpoints would mean rereading all available events from scratch so that could cause an overload of your license and/or infrastructure. ... View more

How does "Splunk block one of your microservices"? What do you mean by that? ... View more

I would add a bit of info to @richgalloway 's response. Firstly - yes, 100% on that "don't modify CIM datamodels". There are some border cases when I've seen people do that but editing a Splunk-provided datamodel definition will only cause you pain. Next time a new revision of CIM app comes out you'll have to review the changes, manually merge them into your own edited datamodel... it's practically never worth the effort. So keep the DM definition as it is. And second - CIM datamodels are meant as standard to which your data should conform, not the other way around. So if you have a good CIM-compliant addon for parsing your data, it should be properly adjusting your fields so that they fit the datamodel. If not, it's up to you to not only extract raw fields from your data but also adjust them (sometimes calculate new values from existing ones, sometimes simply rename fields so they fit the datamodel...) to be CIM-compliant. And then you should configure your sourcetype (again - you modify Splunk's behaviour regarding your data, not the CIM definition!) so that it "marks" certain events with proper tags as per the datmodels' definitions. There is an app - add-on builder which can help you (but it also has some flaws and some people dislike it heavily) do that. So I understand that for now you're at the beginning of this journey. ... View more

Short answer is - no. Long answer is - there is no technical possibility to trace back statically that information. While you might be able to pinpoint "after a lot of time searching for the exact config" where the field came from, it is not possible without the results. Simply because some fields are not statically defined, but are dynamic. The easiest example of this would be fields extracted by automatic key-value parsing. More interesting case would be dynamic field creation with brackets syntax (eval {something}="here I am!"). So if you wanted to have this information you'd have to: 1) Have a complete audit trace of every single operation in the search pipeline 2) Drag this monstrosity along with the results from the indexers to the searchheads... (not to mention cases like federated search). So as usual - the question is simple, the answer isn't. ... View more

No. EventCode is _not_ an indexed field. That's just it. That's how Splunk search works. If Splunk sees a search condition like that "EventCode=4662" it selects only those events which contain value "4662" for further searching. And only those events are checked whether that value happens to be getting parsed out as the EventCode field. So if you have multiple search terms the intersection of the sets of events resulting from limiting the initial data set by those sought terms can be really small even though you're searching a broad time range (and that's also the reason why negative matching is not as effective performance-wise). If you do filtering with searchmatch Splunk cannot use this magic to limit the scanned events. It has to parse (at least to the point when it has all needed fields) each event. It can be a humongous number of events. Anyway, if you have _the same_ definition across different apps and eventtypes, that means something is way off in your knowledge management process. Don't try to solve policy problems with technical means and vice versa. @tscroggins 's solution with using a subsearch to generate the search dynamically is... well, while it's technically correct and should be working, it does make your life more complicated because you have more items to manage, auditing is more complicated (if possible at all) and debugging gets a lot more frustrating. If you need dynamic elements in your searches/eventtypes/dashboards and so on, you typically just use macros. Those macros can be made editable by a defined group of people and can contain variable elements of the search. Typical use cases here are - whitelisting some results or dynamic thresholding. Generally - that's the way of externalizing configuration of the search from its basic logic. But again - if you have the same search in various places across your environment that might need refactoring your configuration as a whole and redesigning your maintenance process - it can benefit everyone in the end and save a lot of time and effort instead of introducing more maintenance nightmares. ... View more

The typical reason for this if you're doing it in corporate environment is TLS inspection sollution. It does a MITM on the connection and uses its own CA to dynamically create a cert for your connection. This CA's cert is typically pushed to endpoints with GPO, Ansible or whatever your company is using. ... View more

Normally I'd say that the searches are run in different contexts (app, maybe user) so they might have access to different sets of KOs. But I don't understand the part about "adding fields to the search" which makes it work. ... View more

It is a very bad idea. For at least two reasons. One is the maintenance and accountability - change in the lookup contents will not be audited. Another, probably more important for you at this point - performance. If you have a set of search terms in the initial search, Splunk tries very hard to limit the number of events it actually has to read from the index, parse out the fields from and process down the pipeline.  With a search like this Splunk has to read each single event from the index, parse it and try to match to a given search condition. An example from my home lab. If I do index=windows EventCode=4662 over last 24 hours, the search ends almost immediately (after 0.5s it takes to spawn the search) and returns nothing because I don't have any event with such event and since Splunk hadn't indexed anything with a term "4662" it just checks the tsidx file, sees there is no such term and doesn't have to read a single raw event from the index file. But if I do it "your way" index=winevents | eval match=if(searchmatch("EventCode=4662"),1,0) | where match=1 I still get no results because the events haven't suddenly magically spawned but to come up with this it took Splunk about 2.5 seconds (on my mostly empty lab) and it had to read all 23851 events from the search time range. ... View more

It really depends on the use case and data. Unfortunately eventstats can be a memory-hungry command, especially on a high-volume data set so if there is another way, it would be better do find it.  ... View more

OK. If list inputstatus shows no wineventlog inputs at all that means that you didn't enable the input correctly. Check splunk btool inputs list --debug on the forwarder ... View more

Nope. You're still doing a lot of hand waving. A pie chart is just a visualization so it's not adding anything to the question. Again - what data you have and what is the relationship between events if there is any. Your example two events (if the are not typed in by hand but copy-pasted that would mean you have horribly inconsistent logging format). receive: 2025-11-04 Operation name [accountId=12345, errorCode=400] receive: 2025-11-04 Operation name {accountId=12345, country='spain'} Would suggest that you could (assuming your fields are properly extracted aggregate your data for example with index=whatever | stats values(errorCode) as errorCode values(country) as country by accountID That's a typical approach to this kind of problems ... View more

Ouch. Don't use subsearches unless you are absolutely sure you're aware of their limitations. Same goes for dedup. Also searching for something from an index in the subsearch and then searching for those items from the same search can surely be done much more efficiently without the subsearch. Unfortunately your original question was a bit vague. Show us a sample of your data (anonymized/sanitized if needed) and tell us what you want to achieve. ... View more

You effectively broke the event recognition completely. DATETIME_CONFIG = CURRENT means that you're not recognizing the timestamp from the event but assuming the current timestamp of the receiving component. That is wrong. If you have any delays in the ingestion process, your data will not be properly timestamped. This is _not_ the solution of the original problem. This is a way of a short-term avoidance of the problem but not the solution. ... View more

OK. Now we're getting somewhere 😉 Poet 9997 is for data forwarding. Forwarders register in Deployment Server on 8089. Also you need to configure the client to use a DS - with Windows UF, if you installed it interactively, you had a dialog during installation letting you specify the DS address. If you pointed it to your Splunk Server, enabled the DS functionality on your Splunk server and opened the 8089 port, the forwarder should register itself with the DS. So that's the reason why you're not seeing your UF as deployment client. If you provided target indexer address during UF installation, you should be (if everything works OK) seeing forwarders internal log in the _internal index. ... View more

Are you sure it's not something on your end? With the time(zone) configuration on your SH? What do you get if you run | makeresults | eval _time=strptime("2025-10-29T14:55:17-04:00","%Y-%m-%dT%H:%M:%S%z") | eval time=strftime(_time,"%s")   ... View more

What do you mean by "4 hours into the future". The timestamp you posted in the example event references 18:55:17 UTC (1761764117 as epoch-based unix timestamp). ... View more

No. It actually does match the format. It's a bit unfortunate that the offset is "glued" to the time part but it seems to match. And since the timestamp references timezone definition, the TZ setting for the sourcetype should be ignored. So there's something else here. Are the settings defined in the right place on the right component? (and aren't they overwritten by settings from another app?) ... View more

Ideally, in a supported environment, all "main" components should be in the same version. You can get away with HFs running older versions (which is sometimes required if you have legacy systems for which you are using some legacy apps). The order of upgrade can be deduced from the Installation Manual (and is charted in the post referenced somewhere else in this thread) but it can get tricky if your components have multiple roles. Don't get me wrong but if you don't know nothing about upgrading Splunk and don't even know how to make a backup copy, maybe it's time to engage your local friendly Splunk Partner for this one and in the meanwhile set up a lab environment and train there before going all-in into the prod. ... View more