Closed bernhardschmidt closed 8 months ago
what timezone you using in your os that you are browsing nfsen with? (utc?) the flows coming off your device are utc?
It would prob make sense to just configure the timezone on the box you run nfdump also to be UTC. that way when your running commands from nfdump manually it all just is aligned.
php defaults date.timezone to UTC - so nothing you need to do there unless you've change date.timezone
in your php ini
There was no change regarding TZ settings or handling. Maybe you updated some local OS or software components? Make sure the php settings are correct. See comment above from @thezoggy
I was about to open a "help me something is wrong and I can't find it" issue, but I found the correct configuration/fix/workaround now. But since I have not found anything about this in the documentation and I'm reasonably sure it did not happen before my upgrade to nfdump 1.7.x and current nfsen I thought I would raise it here.
Debian 12 (Bookworm), PHP 8.2 (FPM), nginx, nfdump 1.7.3, nfsen as of current git HEAD.
The server is running in the Europe/Berlin timezone, so right now UTC+1. It is now 23:15 . When I move the cursor to the rightmost available slot it says
The time in the x-axis of the graph also says 23:something.
In the bottom it says
Statistics timeslot Nov 25 2023 - 22:10 UTC
When I run a calculation for this timeslot we can see that it is indeed accessing the 22:10 data
nfdump -M /nfsen/profiles-data/live/sflow -T -r 2023/11/25/nfcapd.202311252210 -n 10 -s ip/flows
BUT the latest nfdump data is for 23:10.
So in the end nfcapd is naming the files in local time, while nfsen uses UTC for it's calculations. Setting date.timezone in php.ini to the same value was an easy fix. BUT
So maybe there is some change in current nfdump/nfsen that broke this calculation?