+4Hello All,
I'm experiencing a 3 hours delay for my F5 ASM Logs as I can see the difference between the ingested_timestamp and event_timestamp are 3 hours apart. Is there any way I can solve this? Also I want to mention that I'm using a cfps forwarderer and I have set the collecter protocol as TCP when I check the collector logs it indicates that the logs is being uploaded successfully.
Best answer by chrisproudley
Hello, is it a consistent and exact 3 hour difference between ingested and event timestamps? We have seen instances where the relative timezone that the WAF is configured with (for example, UTC+3) introduces this kind of apparent delay, which is actually a disparity in the timezone Chronicle uses (UTC) compared to the F5 ASM.
The timestamps are ingested with no contextual information, so the relative timestamp (UTC+3, for example) is interpreted as UTC.These logs then get held back from the UI for the duration of the time difference, so it appears to be a delay in spite of the upload being successful.
There are a few options to resolve this. F5 ASM logs may not include a timezone by default, so one possibility could be to set the WAF to UTC, if I am correct and it is running with a steady 3 hour offset. The correct timestamp will then be parsed with no conversion necessary.
If resetting to UTC is not possible, this external blog from an F5 community page recommends using iRules to trigger the correct timezone in the response logs.
+4Hello, is it a consistent and exact 3 hour difference between ingested and event timestamps? We have seen instances where the relative timezone that the WAF is configured with (for example, UTC+3) introduces this kind of apparent delay, which is actually a disparity in the timezone Chronicle uses (UTC) compared to the F5 ASM.
The timestamps are ingested with no contextual information, so the relative timestamp (UTC+3, for example) is interpreted as UTC.These logs then get held back from the UI for the duration of the time difference, so it appears to be a delay in spite of the upload being successful.
There are a few options to resolve this. F5 ASM logs may not include a timezone by default, so one possibility could be to set the WAF to UTC, if I am correct and it is running with a steady 3 hour offset. The correct timestamp will then be parsed with no conversion necessary.
If resetting to UTC is not possible, this external blog from an F5 community page recommends using iRules to trigger the correct timezone in the response logs.
+4Hello, is it a consistent and exact 3 hour difference between ingested and event timestamps? We have seen instances where the relative timezone that the WAF is configured with (for example, UTC+3) introduces this kind of apparent delay, which is actually a disparity in the timezone Chronicle uses (UTC) compared to the F5 ASM.
The timestamps are ingested with no contextual information, so the relative timestamp (UTC+3, for example) is interpreted as UTC.These logs then get held back from the UI for the duration of the time difference, so it appears to be a delay in spite of the upload being successful.
There are a few options to resolve this. F5 ASM logs may not include a timezone by default, so one possibility could be to set the WAF to UTC, if I am correct and it is running with a steady 3 hour offset. The correct timestamp will then be parsed with no conversion necessary.
If resetting to UTC is not possible, this external blog from an F5 community page recommends using iRules to trigger the correct timezone in the response logs.
Yes I have discovered few moments after I posted this post that it turned out to be a timezone issue when I reset my F5 to UTC it worked and forgot to update this post but the article you mentioned regarding the iRule is helpful!
Also, iām wondering if there is a way that I can set the default timezone for chronicle ingestion(not SOAR)?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
