Hi Team,
we are getting log from Router/switch on graylog , there is huge time difference
on graylog, how we can resolve this issue,
What version of Graylog are you on? Show some (nicely formatted with the above tools) examples of what your issue is. Are the two devices in different time zones? Is the system clock time on both devices the same? Graylog’s timestamp is in UTC, is that what you are comparing? Is the difference between the times random or a specific offset? Did this just change or has it always been this way?
When you are asking for help - particularly in a public forum - you should include as much detail as you can. It’s nearly impossible to answer your question without specific detail on what you see happening and perhaps what you have done to try and resolve it.
Or you can go the paid route - they will patiently ask you all the questions.
2 Likes
To echo what @tmacgbay said, @Shyambihari, please read the forum guidelines before posting. These guidelines should help you better scope your question. Additionally (echoing again) show us what you’ve tried, what you see, and what you expect to see.
As shown in your graphic, the processing buffer is full and you have over 2 million messages waiting in the disk journal. The differences in timestamp is likely the time between the event happening and when it was able to be processed by the overloaded Graylog system.
1 Like
yes there is the 2 million messages waiting in the disk journal so how we can resolve this?
and if i am generating the log from router so i am able to see on graylag cli and it is also showing in GUI with in 10 minute but the timestamp difference is 5 hrs/ 10hrs , same i have checked in router log time which is also same when i received on graylag cli.
please help us…
Doing a quick look around here is a post on a quite older version of Graylog but the idea still stands. If your router/switch is not reporting it’s time zone Graylog will assume it’s UTC, then display in your local timezone. Looks like that and perhaps the overloaded resource delay added on. You can correct timestamp information in the pipeline… also… look for inefficiencies in your pipeline that might help with the overload. One thing that has helped in the past is adding a ^ to the start of any GROK if it is expected to start finding things at the start of a message so it doesn’t try and iterate through the whole message…
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.