I already told you in https://community.splunk.com/t5/Security/Cron-Expression-for-scheduled-Alert/m-p/575364 - there's no single cron schedule that will cover all the "uneven boundaries". ... View more

We might even spare ourselves the append and do a simple alternative. And I'm not sure if it shouldn't be aggregatted slightly differently. index=software OR index=downloads | stats count(timestamp) as downloads values(version) as version values(author) as author by sw But I'm not sure if your or mine aggregation is better because we simply don't see the full raw data. ... View more

How did you input those settings? Quotes are notorious for being "the wrong ones", especially when copy-pasted from an unknown source. ... View more

OK. So assuming that you didn't have too much delay on the ingestion queue, you have: IndexTime = 11/23/2021 02:06:29 (I assume that it's rendered in your local timezone) _time = 2021-11-23T07:06:28.000-05:00 Whereas in raw event you have 2021-11-23 07:06:28 From what you wrote earlier, the IndexTime is the right time for the event. That means that the raw event which is sent apparently in UTC was improperly intepreted as your local timezone based on local settings of the ingesting/parsing component (HF/Indexer). Maybe (but I have never tried it and anyway it's a very very ugly idea) you could eval the _time as a calculated field from the original _time value but it would be a horrible idea. Anyway, the timestamp is already stored with the event so regardless of the timezone you set in your user's settings, the event is already indexed at wrong time and you can't change it. The proper solution (but applying only to newly ingested events) is to set a proper timezone for this source/sourcetype/host on the ingesting component (first HF or Indexer that's receiving and parsing data). ... View more

What do you mean? In a clustered environment index is not stored on a single host. That's one. And if you "took the index out of a cluster" where would your forwarders write to? That's two. ... View more

Version:8.2.2.1 Build:ae6821b7c64b ... View more

_time is rendered by default in the timezone you have set in your user's configuration and is shown without the timezone information but if you expand a single event, you can see in the line with the _time field value a string representation including your timezone. So I don't quite understand. Can you please show a single event expanded? ... View more

This is not any rfc-compliant syslog format. That's  for start. And it's not advisable to receive syslog directly on splunk components. You should rather use some intermediate solution (sc4s, rsyslog) to receive syslog data and send it to splunk. ... View more

I still don't understand the concept of "timestamp plus timezone shift and have this as timestamp". You can of course add/substract any number of seconds to shift the timestamp into the future or past but it will make the timestamp point to another point in time. So if your other system stores the events with the wrong timestamp, there seems to be something wrong there. ... View more

OK. So for each server you want top 5 hours with highest error count? Is that it? ... View more

I still don't understand what you want. You parse the "product" field from the event yet don't use it. What is this error peak? Is it a count of error occcurrences per host? Or is it some value from the event? How does it correspond to the timestamp? ... View more

Look at the docs I pointed you to. I haven't done it myself but it involves creating some config files so that splunk understands how to interface with your script. ... View more

https://dev.splunk.com/enterprise/docs/devtools/customsearchcommands/ For scheduling you just create a report which runs - for example - once a day but don't care about the results 🙂 ... View more

If all your events in question had the ID field you could do something like (rough idea) index=* ID=* | stats values(_raw) by ID But that would mean doing stats  across all your indexes which is not very effective to say the least. But your join would be even worse 😉 ... View more

If you want to change the values of events stored in indexes - there is no way to do that other than to "delete" and re-ingest. You can however dynamically re-calculate it in search-time by <your search> | eval _time=_time+<your_offset_in_seconds It ain't pretty. Quite the opposite. And you have to remember to do this every time you use this data. And have to remember when to use it if you fix your ingestion. ... View more

https://docs.tenable.com/integrations/Splunk/Content/Splunk2/Tenable%20SecurityCenter%20Certificates_s2.htm ... View more

First noticeable thing is that _time is different from the timestamp included in the raw event. That means that the _time value is not parsed from the log but instead - as a last resort - it's created by the ingesting forwarder from local server's timestamp. You have to configure proper time parsing for your sourcetype. Second - the file(s?) is indeed read in batches - the same timestamp means (luckily for debugging purposes, the timestamps are local to forwarder) that events were read from the file or other input at the same time. I don't see any info what kind of input you are using for this so it's hard to say why it is so. EDIT: There is of course also the possibility that _time is explicitly created by other input component (for example source sending events with explicitly created timestamp via HEC, or modular input). ... View more

That's interesting, because indeed splunk does make something strange with _time export on CSV... when it's formated by default. If I did simply | makeresults I'd get my results as When I exported the job to csv, I'd get "_time" "2021-11-19T20:49:41.000+0200" But if I started fooling around with fieldformat I started getting weird results: | makeresults | eval t=_time | fieldformat t=strftime(t,"%Y-%m-%d %H:%M:%S.%l %z") As you can see, both fields, t and _time should have the same value. And in the WebUI it does indeed seem so: But the CSV export shows... "_time",t "2021-11-19T20:52:30.000+0200","2021-11-19 20:52:30.000 +0100" So if we render the _time without the timezone information, CSV export produces the default timezone on its own anyway. But if we render the _time with a proper timezone including format... | makeresults | eval t=_time | fieldformat t=strftime(t,"%Y-%m-%d %H:%M:%S.%l %z") | fieldformat _time=strftime(_time,"%Y-%m-%d %H:%M:%S.%l %z") Again - t and _time are equal but this time also string representations are explicitly created with the same format, including timezone information.   And now the CSV includes proper TZ information in both fields. "_time",t "2021-11-19 20:55:40.000 +0100","2021-11-19 20:55:40.000 +0100" So it seems it's not the webUI that is at fault but there's something "wrong" with CSV export. ... View more

As you can see, you're getting an SSL handshake error which means that either the negotiation of session parameters fails (have you upgraded either splunk, the app or the tenable server?) or the server's certificate is not accepted by the client (or vice-versa if you're using mutual authentication). Hasn't your tenable server's certificate just expired? Or haven't you reissued a cert for the server from another CA? ... View more

There are various things that are happening here. Firstly, the date_* fields - quoting from the docs (https://docs.splunk.com/Documentation/Splunk/latest/Data/Aboutdefaultfields😞 "Only events that have timestamp information in them as generated by their respective systems will have date_* fields. If an event has a date_* field, it represents the value of time/date directly from the event itself. If you have specified any timezone conversions or changed the value of the time/date at indexing or input time (for example, by setting the timestamp to be the time at index or input time), these fields will not represent that." So don't rely too much on the date_* fields because they don't have to match (as you can see) the final parsed _time value. Secondly, if you don't have your date format specified, splunk tries to find the date on its own but doesn't always do it properly (especially if the date is expressed somewhat exoticaly). Also, finding timestamp is one of the "heaviest" part of ingestion pipeline. So it's best to specify explicitly where the timestamp is within the event by means of TIME_PREFIX in props.conf and what is the timestamp format with TIME_FORMAT. If there is no timezone within the event itself you can also set TZ for a given sourcetype. ... View more

What do you mean by "unix format in the local time"? Unix timestamp has nothing to do with any timezone. It just represents a point in time - being the number of seconds that passed since Epoch. So if you have your unix timestamp you can render it to a human-readable form with any timezone specification but it's still the same point in time. ... View more