Do mikrotik routers/switches have enough storage to store long time graph data for interfaces?
I see there is endpoint to view graphs but am wondering for how long data can one store since mikrotik devices lack enough storage

How long can one store for and what other options or solutions do you gusy use? for your monitoring/logging?

Graphing doesn't allow any adjustments to the time intervals, these are hard-coded:

• 5-minute average for daily graph (288 values)
• 30-minute average for weekly graph (336 values)
• 2-hour average for monthly graph (372 values)
• 1-day average for yearly graph (365 values)

All in all that's 1361 values (give or take) per graphed parameter. As time passes, old values get purged so data set size remains constant.
If these values are stored as single precission floats (which is already excessive as graphs don't provide that much of detail), that means around 5.3kiB of data per parameter. Small devices have up to 10 parameters (in default config) and up to some 25 parameters is IMO sensible config on ARM devices with 16MB storage, so less than 150kiB for graphing data.
The only way that storage consumption goes high is if one wants to graph data for many interfaces and/or queues ... and I expect that routers running many of either will have more than 16MB of flash storage anyway ...

For any better graphing/logging, use some 3rd party tools. Such as cacti with SNMP data collection.

For any better graphing/logging, use some 3rd party tools. Such as cacti with SNMP data collection.

Mind pointing to what cacti templates you using or you have custom templates?
Between by know i would have thought there will be a newer and more modern monitoring software than cacti and the others
Aren't there more modern and better ones? Cacti has been around for decades

I'm not doing any monitoring of my (few) devices other than built-in graphing, so I can't give you more details about that.

Just because cacti is around a while doesn't mean it's not one of most used and usable softwares in this arena. It would be pitty to dismiss it solely on this grounds. And it's still light years ahead of MT's own built-in graphing for that matter. But that's my own opinion, you're free to look in any direction you want.

We're using icinga2 (FOSS fork of nagios) with grafana as icingaweb plugin ... the combination provides some nice graphing in addition to monitoring. But does need appropriate plugins to do the monitoring and preparing data appropriate for it. Not a huge undertake, one can prepare a bash script that polls data via SNMP and presents it to icinga. The monitoring logic (what values to monitor and thresholds to raise alarms) is more or less on the polling scripts. There are some included plugins that directly monitor SNMP values on configured hosts but those provide little control over which values are actually relevant and of interest.

We are not using the mentioned combination for monitoring MT routers, but we use it to monitor a wide variety of support infrastructure (UPSes, diesel gensets, inrow coolers, chillers, ...). They all provide data via SNMP and it would be fairly easy to adapt the monitoring also for switches/routers if needed.

There are many commercial products that do similar things ... if you can spare some dimes.