[mrtg] Re[2]: errors monitoring

[nicolas.pigeau at paribas.com]

I just tried, the result is not bad at all, it works fine.
Thanks a lot for that.

just something strange: in my daily graph, the max is 20 errors/mn (yeah, I
know, bad link...), and for the same period, in the weekly graph it displays
data superior to 21 errors/mn (with the option "maxpeak") ???  (I deleted the
log/png files and restarted with "perminute")

not really disturbing, but strange...








Internet

From:     daniel.kilbourne at voyager.net on 27/04/2000 18:32


To:  Nicolas PIGEAU

cc:  mrtg

bcc:

Subject: Re: [mrtg] errors monitoring




try one of these - they go in the Options[target]:


perminute

     All the monitored variable values are multiplied by 60 (i.e. shown in units
per minute instead of units per second) in case of small values more accurate
     graphs are displayed. It also affects the 'factory default' labeling and
units for the given target.
perhour

     All the monitored variable values are multiplied by 3600 (i.e. shown in
units per hour instead of units per second) in case of small values more
accurate
     graphs are displayed. It also affects the 'factory default' labeling and
units for the given target.

On Thu, Apr 27, 2000 at 07:11:38PM +0100, nicolas.pigeau at paribas.com wrote:
>
>
>
>
> Hello,
>
> As many of you, We are using MRTG here to monitor traffic on leased lines and
it
> works perfectly.
> But we would like to use it to monitor errors on interfaces, and here, things
> are getting more difficult.
>
> To get the good data from the routers is not the problem, we are using the
good
> OID, and MRTG is getting them (I checked using the debug mode of MRTG).
>
> The problem is to display them.
> Apparently MRTG keeps on wanting to do the difference between the parameter he
> gets with the last one, which is good (the data are counters), but also divide
> that by the time between two collects, which is also good for traffic
monitoring
> (bit/s) but is quite bad for errors monitoring (the number of errors during 5
mn
> divided by 3600 seconds makes quite few errors/s, hopefuly less than one, and
> here is the problem.).
>
> I tried to use the "step" parameter, but it doesn't work fine.
>
> Anyone doing error monitoring could help me on that ?
>
> Thanks&best regards,
>
> Nicolas
>
>
>
> ps: sorry if this question was yet asked on newsgroup, but I don't have access
> to them.
>
>
>
>
>
>
>
----------------------------------------------------------------------------------------------

> This message is confidential; its contents do not constitute a
> commitment by BNP Paribas Group* except where provided
> for in a written agreement between you and BNP Paribas Group*.
> Any unauthorised disclosure, use or dissemination, either
> whole or partial, is prohibited. If you are not the intended
> recipient of the message, please notify the sender immediately.
> *BNP Paribas Group  is a trading name of BNP SA and Paribas SA
>
> Ce message est confidentiel; son contenu ne represente en
> aucun cas un engagement de la part du groupe BNP Paribas*
> sous reserve de tout accord conclu par ecrit entre vous et le
> groupe BNP Paribas*. Toute publication, utilisation ou diffusion,
> meme partielle, doit etre autorisee prealablement. Si vous n'etes
> pas destinataire de ce message, merci d'en avertir immediatement
> l'expediteur.
> *Le groupe BNP Paribas est le nom commercial utilise par BNP SA et Paribas SA
>
> --
> Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
> Archive     http://www.ee.ethz.ch/~slist/mrtg
> FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
>

--
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Daniel R. Kilbourne
daniel.kilbourne at voyager.net
Voyager.net Network Engineer

^^^^^^^^^^^^^^^^^^^^^^^^^^^^



--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org