I have a question about the timezone showed on Graylog UI for timestamp fields that are not the original “timestamp” field of the event.
For example, I configured admin user to show the timestamp on GMT-3 timezone, with root_timezone = America/Argentina/Buenos_Aires on server.conf, because I live at Buenos Aires.
After that, I have te correct three timezones showed on System/Overview of Graylog UI:
Time configuration
User admin : 2019-11-11 16:54:52 -03:00
Your web browser: 2019-11-11 16:54:52 -03:00
Graylog server: 2019-11-11 16:54:52 -03:00
But:
The field timestamp show correctly, in GMT-3 timezone
The agentReceiptTime and deviceReceiptTime fields, obtained from a CEF Input, show the date in Zulu (GMT). Both fields are indexed as “date” type in ElasticSearch.
The agentTimeZone and the deviceTimeZone fields are America/Argentina/Buenos_Aires
I tried to “play” with timezone setting in CEF Input, for example using “Etc/UTC”, with no luck.
So:
Is there a way to show all the timestamp fields in Graylog UI in the selected timezone (for me America/Argentina/Buenos_Aires), or the only way is an Extractor at Input, or a Decorator at Search (or maybe a Pipeline)?
I guest no, only timestamp is rendered in selected timezone. If you want another date fields sended by device to have correct time in your timezone you have 2 options:
Configure your device to send field in your timezone
Or configure graylog to correct it based on timezone, for example use this pipeline rule:
rule “arcsight timezone fix”
when
has_field(“agentReceiptTime”) && has_field(“agentTimeZone”)
then
let new_date = parse_date(
value: to_string($message.agentReceiptTime),
pattern: “yyyy-MM-dd’T’HH:mm:ss.SSS’Z’”,
timezone: to_string($message.agentTimeZone)
);
set_field(“agentReceiptTime”, new_date);
end
The strange thing (an that is the reason I did the question here) is that the device is configured with the correct timezone (you can see that deviceTimeZone field is America/Argentina/Buenos_Aires, and I reviewed the date locally in the device too), GMT-3, and in ArcSight for example (we have a mixed environment with ArcSight ESM and Graylog) I can see the agentReceiptTime and the deviceReceiptTime in the correct timezone.
I suspect that the CEF Input make a mistake when convert the date from Epoch. agentReceiptTime and deviceReceiptTime fields in “real”, in the raw CEF event received from Syslog (from ArcSight SmartConnector), are Epoch. I supose in Arcsight ESM the UI “translate it visually”, but in Graylog, y supose the CEF Input convert that date to the format showed in Graylog UI before write the event to ElasticSearch, and that is the moment where the mistake happen.
Any developer of the Graylog CEF Input maybe can clarify this.
The Graylog UI show the time correctly for deviceReceiptTime and agentReceiptTime, but in Zulu Time (GMT), not in GMT-3 time, which is the configured time for the Graylog UI for admin user, and which is the time showed for timestamp field.
The final question is: is there a way to show all the date fields in Graylog UI in the same timezone (GMT-3 in this case), or the only way to do that is a Pipeline or a Decorator?
Hi team! I’m a coworker of Alejandro, we did some new tries, in a brief we have two issues.
The “timestamp” Graylog field is shown in localtime in the Graylog UI, meanwhile all other timestamps are shown in Zulu. Please keep in mind all timestamp are well persisted in the ElasticSearch in Zulu as expected, this is a “cosmetic” issue, where they are shown in Zulu on Graylog Search. It’ will be great if they could be shown in localtime as the “timestamp” Graylog field, is there any way to do it? If not, can we open an RFE?
As a workaround, we have configured a pipeline Decorator, using your suggested rule. Here the issue is that in the parse_date function the “timezone” parameter represents the timezone of the time passed in the “value” parameter, so it can be used to convert from localtime to Zulu. We need to convert from Zulu to localtime, is there any “elegant” way to do it? As a second workaround, as we are in UTC-3 we have set UTC+3 in the “timezone” parameter, and it worked…
