Anybody noticed issues lately with mini-snmpd on AX88U? interface counters seem to be gone (there is no interface table at all when doing an snmpwalk) and it seems to be ignoring community string configuration etc.
mini-snmpd --version
v1.6
The problems may have started when I updated entware packages a couple of months ago, and I didn't notice. Actually mini-snmpd 1.6 is supposed to support 64 bit interface counters which would have been nice
I just checked, for me
mini-snmpd is still working regularly (and I'have the same version installed).
However, TBH, I've decided to
walk a different monitoring path. Unfortunately
mini_snmpd is way too much
mini for AX88u (e.g.: I need to monitor 11 interfaces and
mini_snmpd monitors at most 8 interfaces)
First I've been trying corgan's excellent monitoring script (which pumps data into an InfluxDB), but I've found that a deep stat collection is too resource hungry for my personal needs.
So at first, I've been trying to implement a quick of port corgan's script in Python, which improved performances a lot and reduced the load on cpu.
Finally I've decided to try to write a monitoring tool from scratch in
golang to pump data into InfluxDB.. and I've decided to stay there.
The golang tool has almost zero load on the CPU (which for me is very important, since when I'm working remotely I want as much band as possible on the VPN tunnels - I've 300Mbps unload), eats just about 8MB of RAM (which on a 1GB switch is almost nothing) and does not rely on cron (which fills the logs with unnecessary information).
Yet it is still incomplete; I should polish the code, integrate a better logging mechanism to pump logs directly in syslog (ready to be sent to the remote log server without additional configuration) and to figure out an efficient way to get traffic data by local client
About the last point, I don't like very much the idea of altering the firewall just to gather data (which BTW also misses data regarding newly connected devices until iptables are updated), moreover the biggest point is that there is already a feature of the router to monitor client traffic, thus creating a separate mean to collect the same data would only use resources to do the same job some other process is already doing. The best would be able to pick the client traffic data from the same source used by the standard feature, but I still have to figure out from where traffic details are collected.