There is something wrong (or not obvious from the documentation) with how collect takes timezones. _time fields should be stored in unixtime, right? I have a report which does a long search and I use collect to take a _time and I use addtime=t to use that _time in the new field. The original timestamp is stored as: 2019-07-29 23:16:51.884 INFO ... in _raw (UTC). And its timestamp field is set to 2019-07-29 23:16:51.884 (UTC) and in my browser, the _time is set as 2019-07-29T16:16:51.884-07:00 . That's all correct. When I use collect and use that _time , it gets stored as 2019-07-29 23:16:51.884 in the _raw , 2019-07-29 23:16:51.884 in the timestamp field, but it incorrectly uses 2019-07-29T23:16:51.884-07:00 for _time . I don't know why it's using that timezone when it's passing the _time (which I thought was unixtime, which is always UTC). How can I correct for this bug in Splunk? ... View more

I'm trying to mvexpand multiple fields from a transaction, particularly a time and uri_path from an Apache-style access log. I'm trying this out but it does not work correctly, as it duplicates several fields: eventtype=web_logs_valid user=* uri_path != /server*/* | eval orig_time = _time | transaction user useragent | streamstats count as i | mvexpand uri | mvexpand orig_time | table i orig_time uri What is the proper way of expanding multiple fields from a transaction? ... View more

I have an input setup on a universal forwarder where I am monitoring a log file. The monitor on Splunk seems to read the file line-by-line and is truncating log entries way too early. Uploading the file into Splunk works just fine though. Here is an example of a log entry that I am trying to read: 2019-07-08 22:25:42.314 INFO [MessageHandler.java:91] Processing the following message from Queue ------------------------------------ <Metadata ready="false"> <ApplicableStartTime>2019-07-07T23:11:39.000</ApplicableStartTime> <ApplicableEndTime>2019-08-04T23:36:29.000</ApplicableEndTime> <ActualStartTime>2019-07-07T22:49:51.000</ActualStartTime> <ActualEndTime>2019-08-04T23:58:50.000</ActualEndTime> <FileName>test.bsp</FileName> <FileID>...</FileID> <Status>...</Status> <Grade>...</Grade> </Metadata> ------------------------------------ However, when I search for this data, I find an entry that looks like this: 2019-07-11 17:00:27.192 INFO [MessageHandler.java:91] Processing the following message from Queue ------------------------------------ <Metadata ready="true"> Then, when I search for the time within the <ApplicableStartTime> XML tag, I've found this as a standalone event: <ApplicableStartTime>2019-07-07T23:11:39.000</ApplicableStartTime> It seems that the monitor is reading the file line-by-line instead of respecting the line break rules defined in the props.conf, then the date parser takes the incorrect time as the log time. The logger might be flushing the file to disk after each line but that is something that is completely out of my control. Here is the sourcetype in my props.conf: [my-sourcetype] BREAK_ONLY_BEFORE_DATE = DATETIME_CONFIG = LINE_BREAKER = ([\r\n\s]*)\d{4}-\d{2}-\d{2}\s\d{2}:\d{2}:\d{2}\.\d{3}\s[\w+\s\[\w\.]+(\:\d+)?\] MAX_EVENTS = 2000 MAX_TIMESTAMP_LOOKAHEAD = 23 NO_BINARY_CHECK = true SHOULD_LINEMERGE = false TIME_FORMAT = %Y-%m-%d %H:%M:%S.%3N TIME_PREFIX = ^ TRUNCATE = 50000 category = Custom description = This is my source type yo pulldown_type = true When I test this out by uploading the file directly, this source type works just fine AND reads the entire log entry as a single one. How can I adjust this so it works for the monitor:// input type as well? Edit: here is the properties from the upload: Edit 2: where does the event breaking and fitting to a sourcetype actually occur? I did change the sourcetype on my universal forwarder instance. Do I need to rename the sourcetype on the UF, or will the indexer/searcher update the sourcetype? Or does it not matter? Edit 3: I've also tried using these parameters in the inputs.conf under the monitor:// stanza: multiline_event_extra_waittime = true time_before_close = 15 and it did not seem to affect it. Edit 4 (6/15): I had this extra capturing group (\:\d+)? which should've probably been (?:\:\d+)? in the LINE_BREAKER setting. Would that cause an issue like this? I've since removed the optional-ness, so it's just \:\d+ . And now: waiting until these messages occur again in our production environment. Edit 5: Nope, that was not the issue. 😞 Edit 6: Moved it to the indexer + HFs apparently, and it does not work still. ... View more

I'm running a search and I've noticed that there are a ton of additional sourcetypes (like f5_bigip:, pan:, WMI:*) being added into my search. I assume this has something to do with CIM compliance by our Splunk admins. Is there any way that I can prevent these additional sourcetypes from being added to my search? I do not have administrative permissions, so is there something that I can add into my search query? My search has nothing to do with those sourcetypes and my index does not contain data that's relevant to that. I am worried that it may degrade the performance of my query, which is sparse and already a bit slow. ... View more

I'm using the Splunk Addon for Java Management Extensions on OS X. So far, I've: Created an index for this and assigned it to the add-on Created a server entry in the add-on under Config > Server In my splunkd.log, I get a "Successfully established connection with JMX server" entry I've made a template for the content that I want: In Inputs: I created a new input configured with the stuff above I'm getting no data and I'm really unsure why. There aren't any logs in either splunkd or in the _internal index as well. The documentation seems pretty out of date or is just mismatched with the UI has: am I supposed to still use a config.xml and inputs.conf? Or is that deprecated? ... View more