If you look at the example message you mention, what are the contents of the time related fields and the application_name field in that message, after Graylog has run all extractors and pipeline functions you have defined?
Thanks for reply.
I paste you a full trace. Hour 7:04
2017-06-13 07:00:21.392 mail PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.X.X user=root 70eba514-4ff6-11e7-b3fe-000000000000 Received by Syslog on 76899de3 / mydomain.com Stored in index graylog_0 Routed into streams All messages SSH application_name sshd facility security/authorization level 5 message PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.X.X user=root process_id 5643 source mail timestamp 2017-06-13T05:00:21.392Z
Well, if I search last 5 minutes I don’t get it but alert was 7.00 (and now its 7.04) but if I search last 1 hour I get it. Its rare, don’t?
look at the timestamp value and compare with the message content. Seems you have defined timezones so that there is a two timezone difference. You could recheck your timezone settings and if necessary, add a date converter for the message.
I am logging in Graylog with timezone -> "Madrid"
In server I re-did dpkg-reconfigure tzdata and again setup “Europe/Madrid” (it was right)
Hour server is # date
Tue Jun 13 12:56:26 CEST 2017
I think that in both sites I have same timezone. However, more weird, I setup a “Alert” to send me an email when Stream SSH receives any entry. If I search in Stream SSH (all messages) I get results, why haven’t I email? Alert is setup and working because I can do a “test email” and I receive it.
I use timezone=UTC for graylog internally, but for Graylog users the local timezone. All logs are converted to UTC when received, so the user will see the correct time.
You can check from System/Overview, what Graylog thinks the time zones are.
So, time server UTC? With dpkg-reconfigure tzdata which choose?
In System/Overview (my user) I use “Madrid”.
And what do u think about alerts?
Don’t worry about tzdata. The point is that if you look at the timestamp field, it shows Z as time zone, i.e. UTC. If that time is wrong, after converting back to your local timezone, you need to add a date converter for that input.
It is better to make the timestamp work OK before worrying about the stream, I think. One problem at a time.
Well, really time in server in same than graylog. Mi own laptop if have 10 minutes less but don’t worry.
However if I try to login to my server and I fail, Graylog take that log, its ok (with some minutes less but don’t worry).
I can go Stream, search “sshd” and I will see my fail login, but if there are entries in Stream SSH and I have an alert configured to sent an email when its ocurrs, why don’t I receive emails?
Therefore, how could I solve timestamp? Any plugin? Changing timezone in any site?
I’m sorry for large post but I am stuck.
That page covers date converters that can be used to fix timezone issues.
… and for the email issue: you can try to send test alert emails from Alerts/Manage notification
That way you can first check that your email configuration is OK, so that the problem is not there. If the test email work, then the problem could be in stream settings.
I attach two pictures, I created a extractor to change timestamp, I think that I create it good but after I try to login (with bad password) and I see log in Graylog but its keeping bad timestamp. I’m really stuck
Regarding email, tests is working fine and If I search in Stream SSH I see logs and in Alert is configured correctly. I attach pictures too to be more easy help me.
date converters are picky. I recommend you first extract the time/date to a field with a different name (such as timestamp_test to see if the extraction works OK (if the converter does not work, you will not get the new field).
Seems extractor is working fine, dont?
Metrics 150 total invocations since boot, averages: 1.6, 0.45, 0.16. 0 hits, 150 misses Total time 95th percentile: 6μs 98th percentile: 6μs 99th percentile: 14μs Standard deviation: 2μs Mean: 3μs Minimum: 1μs Maximum: 18μs Condition time 95th percentile: 1μs 98th percentile: 1μs 99th percentile: 1μs Standard deviation: 0μs Mean: 0μs Minimum: 0μs Maximum: 1μs Execution time 95th percentile: 0μs 98th percentile: 0μs 99th percentile: 0μs Standard deviation: 0μs Mean: 0μs Minimum: 0μs Maximum: 0μs Converter time 95th percentile: 0μs 98th percentile: 0μs 99th percentile: 0μs Standard deviation: 0μs Mean: 0μs Minimum: 0μs Maximum: 0μs
Now, what next step?
I saved it in new stored field -> store as field: timestamp_test.
it works fine, if it produces a timestamp_test field and the content of that field is the correct event time in UTC. Once you get it working, you can change the extractor so that it saves the result in the timestamp field, and see if it still produces the right time. In my experience, for some reason this second step can be also problematic.
The explanation is:
Hi, thanks both. I did it but new logs are same than others, it isn’t converting
Extractor type: Copy input
Source field: timestamp
The entire input will be copied verbatim.
Condition: Always try to extract
Store as field: timestamp
Extraction strategy: Copy
Extractor title: Timestamp
Add converter: Convert Date and format string:
Format String: yyyy-MM-dd HH:mm:ss
Time Zone: Madrid
I save it, after I went to Stream (or dashboard main) and timestamp from new logs are same (like that 2017-06-15T06:38:35.155Z)
I don’t understand how works Alerts.
SSH Graylog (Email Alert Callback)
Executed once per triggered alert condition in stream SSH
Stream SSH has entries.
Test Alert works fine. Why never I receive alerts?
As described in Flexibly Parse Date and the documentation at http://docs.graylog.org/en/2.2/pages/extractors.html, Extractors only work on text (string) fields, but “timestamp” is not a string.
thanks Jochen, so I no worries about that, really I could work with that, there are some difference with minutes/hour but ok.
If you see it well I will open a new post about alerts to not mix both doubts.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.