[mrtg] TrafGrapher - interactive multiple MRTG data in one graph

[Ján ONDREJ]

Hello,

  thank you for you point of view, but TrafGrapher has not been created as
replacement for RRDTool. RRDTools utilities can be used to make similar
behaviour, asi is done by TrafGrapher.

  If there is any volunteer, it can write RRDTool processor for TrafGrapher,
even if it will not be simple, because processing binary data in javascript
is a bit complicated (at least for me).

  TrafGrapher's SNMP client (get.py) has better disk IO, like native MRTG.
On first run if MRTG log file is detected, then it's converted to
TrafGrapher log file by increasing first line's numbers to longer ones, for
example:
  1430293217 00000009387329063987 00000034934007987400
These counters can be overridden with new values without changind the rest
of file. New data is written to the end of file, so there is no need to read
or write whole file, just 2 blocks(sectors) (first and last).
Once per day files is completelly rewritten, data are cumulated and sorted
and old values are removed. I think this behaviour can signifivantly improve
disk usage. Is there any volunteer, who can compare this to RRDTool?

  I like simple text log files, but I don't oppose adding RRDTool data
support to TrafGrapher, just need an volunteer, who knows how data is stored
in rrd files.

							SAL

On Tue, Apr 28, 2015 at 09:37:35PM +0000, Steve Shipway wrote:
> First of all, it's good to see a new frontend that has more interactivity - 
> the Routers2 interface is still a bit stuck in the last decade, and the 
> Native-mode interface is very basic.  Also, this is (as far as I know) the 
> first improved and interactive interface for Native-mode MRTG that has ever 
> been produced.  Routers2 originally avoided Javascript in order to be as 
> compatible as possible with mobile devices (many of which were monochrome or 
> had no javascript support); but nowadays, this is not an issue and the next 
> generation of frontends for MRTG should be making the most of DHTML, CSS and 
> so on.
> 
> However, I need to also join the chorus saying - what about RRDTool?  Although 
> the majority of small MRTG installations likely use native mode (.log files), 
> the medium to large installations have long since moved to RRDTool as their 
> backend.  The main reason for this is the Disk IO efficiency - you simply 
> cannot monitor thousands of metrics using native-mode as the IO is way too 
> large.  As you head to the tens of thousands, you need RRDCached+RRDTool to be 
> workable. Native mode has no chance.
> 
> I really think that you need to consider making your system also support the 
> RRDTool backend (which may in fact be simpler as RRDTool already has export 
> capability).  Then you'll have a winner.
> 
> Steve
> 
> (Full disclosure -- yes, I wrote Routers2, so I could be seen as owning a 
> competing project to this, but I've tried to be impartial)
> 
> Steve Shipway
> UNIX Design Team Lead
> University of Auckland, New Zealand
> s.shipway at auckland.ac.nz
>