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

From Splunk's perspective, manipulating peers within the cluster works the same regardless of whether they are on Debian, Centos or gentoo (I wonder if anyone runs Splunk on gentoo ;-)). You should have all nodes on the same distro and release (for example, all nodes on RHEL9) for maintainability purposes but technically - especially during transition period - you can just add Ubuntu peers to AWS Linux-based indexer cluster and they should run just fine. ... View more

You might have completely oposite requirements as well - short retention for performance data, long retention for content for auditing purposes. Depends on your organization. Still, as usual - if your data has different access requirements, different retention parameters or dramatically different volumetric characteristics, split it into separate indexes. Otherwise just leverage search parameters. Differentiate sourcetypes, create eventtypes... be creative. ... View more

Ok. So you're comparing things in different time spans. You should compare your license usage _before_ you had your drop in firewall events (before Jul 14th) with current one. You seem to have had two things happening which both affected your license usage and their combined result is that your license usage raised. But as I see from the graph, the license usage increased roughly by factor of two whereas the number of events per day increased way more 3-4 times. So this might actually mean that the reduction is working properly. As I said - you could disable this pipeline for a day or two and see if the license usage skyrockets again to be 100% sure. ... View more

OK. It's starting to make sense. At least partially. As you can see, while your events indeed got smaller due to the pipeline removing some fields, you're ingesting way more events now. Why is it? It's hard to say. Maybe it's a coincidence and your source simply suddenly started producing more data. Maybe enabling your pipeline triggered some other performance changes so you - for example - stopped losing some events. So generally - volumetrically it makes sense and it adds up - you have smaller events but you have so many of them now that they more than make up for the reduction in size. Therefore your license usage actually grew instead of dropping. But diagnosing why it actually happened could be tricky. You could disable your pipeline temporarily as a test and see whether your event count drops again If it does, that would mean that something in your ingestion path cannot keep up with the raw incoming data stream. ... View more

It's getting more and more interesting 😉 And the count of events? | tstats count where index=* sourcetype=pan:traffic:cloud by _time span=1d   ... View more

Interesting. The event contents indeed seem to have changed although you're getting some embedded json hash of _forwarder_channel_info (we don't see on the screenshot how big it is). You could do some stats how/whether single event size has changed by doing index=<your index> sourcetype=pan:traffic:cloud | timechart avg(eval(len(_raw))) Of course you can adjust span for timechart as needed and add sampling if you have (and you probably do) a lot of data. We're interested about sample stats, not about details for absolutely all events. ... View more

Typically you'd use tcpdump to check whether there are events coming in on your network interface from the source IP to your rsyslog box. ... View more

Well, this is more of a syslog-ng question than a Splunk one so you might get more info about syslog-ng specific tuning and tweaking on some syslog-ng related mailing list/forum. But. I can drop in my three cents (because why not ;-)) 1. I'm not (and I've never been) a big fan of the "separate port for everything" approach. Yes, I know that in the old times when we'd receive syslog directly on Splunk forwarder you'd have a separate port for each product so that you can assign different sourcetype to each port. With syslog-ng or rsyslog you can just use network-level metadata (source IP in this case) to assign target source/index/sourcetype to the event. I find this approach more tidy and the network teams like it because you only ever poke holes in firewalls for the typical 514 port instead of doing a wide range of ports. 2. Having said that - I'm not a big expert on syslog-ng and I'm not sure if you can in a reasonably manageable way attach different (post)processing pipelines to a single "source" depending on the event type (so that - for example - events from Palo Alto are processed differently than events from Fortigate while still being received on the same port). With rsyslog it's trivial, I'm not sure about syslog-ng. 3. There are two schools of thought regarding the "middle" between syslog receiver and Splunk. There is the old-school approach which you have in your config - receive events, write them to files, pick them up with monitor input, send to Splunk. There is also the modern-school approach - use http output/connector/whatever you call it to send it from your syslog receiver directly to HEC input. Both approaches have their pros and cons. The file-based approach requires disk space for the files, requires manual cleaning of the directories but gives you a natural "buffer" if your downstream is not available (your Splunk is down). The HEC output approach is simpler in terms of infrastructure, lets you easily assign additional metadata but is more sensitive to downstream availability (and buffering is more complicated). ... View more

First things first - have you compared the actual raw events before and after you applied this reduction pipeline? ... View more

1. What do you mean by "statistics" here? 2. If you use tstats with datamodel summaries, you don't deal with raw events. ... View more

Yes, but if CM cannot contact LM, it might not be aware of the fact that your license supports clustering. ... View more

Obviously you have some connectivity problems with your LM or simply your LM is down. I haven't had this kind of problems lately but I suppose if you restarted your CM _and_ it wasn't able to contact LM to confirm that your installation is actually licensed for cluster operations it _might_ refuse to work.  ... View more

Even if you had a common field join would probably be a bad idea - there are better solutions. Still, if you have two separate datasets, how would you want to join them? You can't just randomly add fields from another data set? Actually, you can (that's what appendcols is for) but it will not make any sense. So what would be the logic behind those two? Of course, you can simply append those two searches but as @gcusello already pointed out you'll gonna get a lot of empty space in your table since some of your result rows will have one set of fields, some wil have another. ... View more

If you can't find ready-made TA's (which even if exist may be of varying quality), you have several areas to cover. Sometimes there are some choices you have to make on your own, sometimes those are just imposed on you. 1. Ingestion method. Obviously anything that doesn't require writing own code, handling authentication and checkpoints like syslog is preferred over API-based methods provided you can get the same data both ways. 2. Basic parsing - event breaking, timestamp assignment. That should be pretty straightforward. Can get tricky if the same data stream (see p.1; can happen with multiple different "kinds" of data sent over a single syslog stream or written to the same file). 3. Basic field parsing - if you have multiple available formats providing the same set of data you have to decide on the format which will be easy to parse and possibly not overly verbose so you don't waste too much license on non-essential stuff. So you might - for example - prefer json over XML and a well-defined format over CEF (don't touch CEF with a six-foot pole! it's gonna end in tears) 4. CIM-compliance. This is often the most tricky and labor-intensive part. The problem here is that often if you've already dealt with such technology before, you've probably done that for some particular customer (or employer) and are not at liberty to release it freely. Sometimes, some solutions use well-known formats or at least use standard open-source components which produce relatively standard logs. For example, many web-related components produce one of typical access_log formats (like access combined), and many soultions have some standard SMTP daemon embedded in them (often postfix). EDIT: Oh, and make sure _what_ you actually want to onboard. For example - Trellix (formerly FireEye) components have two separate event "streams" one is operational logs which are often overly "chatty" and not used very much in reality, another is security alerts which is probably what you'll wanna go for. ... View more