Cheshire Cat Computing

This is asked for a lot, but has a number of very awkward problems.

1) Graph caching - we can't cache the graphs, since they are one-offs. However, the structure of routers2 means that graphs *have* to be cached. This could waste a lot of disk space.
2) Data availability - we've no control over what interval the user requests. Different intervals just may not have the data available in the requested granularity, or indeed at all. There would need to be a lot of sanity checking of the requested interval and .rrd file(s).
3) User interface - how should the user make the interval request? Where should the prompts be, and how would it affect the menus?

This is currently on the back-burner, awaiting a lot of free time, and will probably result in a major version change.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

A simple cron job based on GNU find with -mmin could remove the old files.


Sure, it would be some work to be done. Check SmokePing for inspiration, it does it well.


SmokePing allows the user to click on the graph and brings a simple pre-filled form. It might not be the best solution, but it works fine for me.

True - under UNIX. Most users have Windows based systems, though, and some have Applemacs. There is also the problem of how to automate the install in this situation, since even under UNIX you need to work our whose crontabs to put the entries into.



I believe that Smokeping has to deal with a lot less generality than routers2 has to - consider, for example, the userdefined combination graphs where we would have to identify the intersection of the sample time windows.



I can see you're quite a fan of SmokePing Actually, I really like the program as well, but it is much easier to provide this sort of facility when you have only one specific form of graph to produce. There are, indeed, several ways to produce a time-selection form, and all of them have their strengths and weaknesses - I need to work out which works the best for the general case.

The largest problem affecting all the options is that of performance, whether in calling multiple instances of the frontend, or in long analysis of the various .rrd files. Since no session information is preserved by the routers2 script, it means that options need either to be passed via the CGI, or re-calculated each invocation, and this would also be the case for checking time windows.

I expect that a future version of routers2 will initially assume that all times are OK, and will attempt to pick an archived .rrd appropriately. Following versions would hopefully be able to be more helpful. Also, I will eventually rewrite the do_graph routine to create the graph at image output time, thus removing the need for the working directory and the crontab entry mentioned in the first place. These are all major-version changes, though, and need to wait for the time to be available.

Another possibility is producing a plugin or companion script to do the time window ananlysis, in a similar way to the way the trend analysis works.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11