Hi,
Got an issue. I want to search my imported logs in Graylog by the timestamp of the logs themselves, not when Graylog received the log via syslog. How would I be able to do this?
Thanks in advance
Hi,
Got an issue. I want to search my imported logs in Graylog by the timestamp of the logs themselves, not when Graylog received the log via syslog. How would I be able to do this?
Thanks in advance
You would probably have to parse the time/date fields within the data as it comes in to change the date. If you can see the date/time in the message you should be able to do some basic text searching without having to parse/reimport.
@rmdashrf is correct. If the timestamp is not parsed from the syslog message itself (it should be though), you have to parse the timestamp manually, using our Processing Pipelines.
Some example based on @lennartās comment.
I struggled 4 hours just to figure that out. Hope this will save some time for others.
E.g.
event_ts
, from apache combined log. I extracted with Grok.timestamp
value.Following is example rules for the example.
rule "parse event timestamp"
when
true
then
let new_date = parse_date(to_string($message.event_ts), "dd/MMM/yyyy:hh:mm:ss Z");
set_field("timestamp", new_date);
end
I would like to know my approach is proper? or if there is better way to achieve it.
Cheers,
ye
Ye,
Thanks for posting this. We currently do all of this in logstash/nxlog before the logs go into Graylog, and hadnāt really considering doing it the way you described.
I donāt know if itās proper or not, but it could reduce our need to use more complicated logstash configurations.
Dustin Tennill
EKU
@dustintennill You are right! We definitely recommend going with the way described by @yett.
@yett, thanks for the example! Looks great.
@lennart, Thanks for the pointer. I was bit unsure if I am on the right direction. Cheers.
Just to understand the thinking here:
Does this mean that the extractors and converters are not the preferred method of handling raw input data (such as lines from log files)? Are they on the way out?
My timestamp still isnāt being set.
Iāve tried the above parser as well as:
rule "parse ACCESS log timestamp" when true then let new_date = flex_parse_date(to_string($message.event_ts)); set_field("timestamp", new_date); end
The timestamp is still set to the time the message arrived in graylog, not the timestamp in the log. My graylog instance was recently offline, when it caught back up, all of the messages were the time the system processed the messages.
I have a Input Extractor that creates āevent_tsā in the form ādd/MMM/yyyy:HH:mm:ssā
I think it should be
set_field("timestamp",$new_date);
I am also interested in how this works - I have had quite a lot timestamp problems, and still get occasionally failed indexing, due to wrong timestamp format.
Well Iām not sure what changed. I didnāt change the code, but it magically started working. Now my Access Logs have the timestamp from the log rather than when they arrived. Now to figure out how to fix the rest of my logs !!
This is something Splunk does automatically, I wish Graylog did this out of the box!
Trying to catch up here - Same goal: Apache logs provide message timestamp, but Log Time is Graylog-ingested timestamp.
Out of the box COMMONAPACHELOG grok pattern parses the date field just fine into its own fields by out of the box %{HTTPDATE:timestamp} but timestamp is not set. I thought maybe I require the ^ pipeline rule, but testing pipeline looks like itās not running thru the assigned grok pattern: Should it? Thereās no explicit selector for it nor any indication that it tried or didnātā¦
My method of testing is:
I suppose a better question is: With Graylog 2.3.1+9f2c6ef and standard Apache log files, whatās the expected Log Time timestamp? Ingested or message-provided? And is the above recipe required to get Log Time to be message-provided timestamp? How best to test/confirm?
Thanks
[update]
I have narrowed it down to that I canāt access $message.time (the json extractor shows me thereās a field ātimeā). I get the error message Invalid format: ""
.
[update]
In my case, the $message object was indeed not getting populated, because the order of message processors in Graylog config had Pipeline rules fire first and -then- JSON extraction second:
[/update]
A post was split to a new topic: Make the Timestamp / timestamp get the correct time