All I agree with Simon that having one rrd per check means you need to do a lot of housekeeping, but on the other hand it gives you the possibility to add and delete checks per server very easily. What we've done is the following;
We've made a monitoring tool where each operator can create his/hers own checks using a webinterface. Each configured check goes into a MySQL database and a script runs every 5 minutes to add data to the rrdfiles if they excist or create them if they don't. When a check is deleted we keep the rrdfiles because they don't take up a lot of space and since no new data will be put in the database for them the won't eat any performance. In another table we have definitions on which parameters to use for each type of check/rrdfile. It was quite some work to create all this, but when it works it looks very sweet. :) We now have over 19000 configured checks on 1500 or so hosts. Our endusers, the operators, can also select which timeperiod they prefer to graph, giving them a lot of freedom to zoom in on a day to see exactly when something went wrong. Of course this means we have to keep quite detailed rrd's (15 minute steps over the last 35 days). Regards, Martin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Simon Hobson Sent: donderdag 6 december 2007 16:18 To: [email protected] Subject: Re: [rrd-users] Scaling rrd tables for best performance Eduardo M. Bragatto wrote: >I can have each server information store on a "server.rrd" file, like: > >server1.rrd, server2.rrd, etc... > >Or have it split among several rrd files for the same server, like: > >server1_cpu.rrd, server1_mem.rrd, server1_network.rrd, >server1_generic.rrd, server2_cpu.rrd, etc... From a simple practicality perspective, the latter would be quite hard to maintain. Each time you add or delete a server you will have to redefine your rrd and change the collection routines to suit. Also, you cannot update DSs independently in one rrd. So as a minimum, you would probably be best keeping one rrd per server. Also, since the number of data volumes/partitions/filesystems is likely to vary between servers, I'd personally be inclined to have a separate rrd for each so that the rrds are of a standard format. If you are graphing multiple systems on one graph then I suspect there isn't too much difference in memory requirements between opening one big rrd and multiple smaller rrds with the same information. However, if you want to graph an individual system, then I find it hard to imagine opening/processing a big rrd (and using only part of it's data) to be more efficient than opening/processing a smaller one. _______________________________________________ rrd-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e n i g e a a n s p r a k e l i j k h e i d v o o r d e m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n d i t b e r i c h t . O p a l o n z e r e c h t s v e r h o u d i n g e n , a a n b i e d i n g e n e n o v e r e e n k o m s t e n w a a r o n d e r A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e a n d e r e v o o r w a a r d e n d e L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n v a n t o e p a s s i n g . D e z e w o r d e n u o p a a n v r a a g d i r e c t k o s t e l o o s t o e g e z o n d e n . T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y f o r t h e a d d r e s s e e ; i t m a y a l s o b e p r i v i l e g e d . I f y o u r e c e i v e t h i s e - m a i l i n e r r o r , p l e a s e n o t i f y t h e s e n d e r i m m e d i a t e l y a n d d e s t r o y i t . A s i t s i n t e g r i t y c a n n o t b e s e c u r e d o n t h e I n t e r n e t , t h e A t o s O r i g i n g r o u p l i a b i l i t y c a n n o t b e t r i g g e r e d f o r t h e m e s s a g e c o n t e n t . A l t h o u g h t h e s e n d e r e n d e a v o u r s t o m a i n t a i n a c o m p u t e r v i r u s - f r e e n e t w o r k , t h e s e n d e r d o e s n o t w a r r a n t t h a t t h i s t r a n s m i s s i o n i s v i r u s - f r e e a n d w i l l n o t b e l i a b l e f o r a n y d a m a g e s r e s u l t i n g f r o m a n y v i r u s t r a n s m i t t e d . O n a l l o f f e r s a n d a g r e e m e n t s u n d e r w h i c h A t o s O r i g i n s u p p l i e s g o o d s a n d / o r s e r v i c e s o f w h a t e v e r n a t u r e , t h e T e r m s o f D e l i v e r y f r o m A t o s O r i g i n e x c l u s i v e l y a p p l y . T h e T e r m s o f D e l i v e r y s h a l l b e p r o m p t l y s u b m i t t e d t o y o u o n y o u r r e q u e s t . A t o s O r i g i n N e d e r l a n d B . V . / U t r e c h t K v K U t r e c h t 3 0 1 3 2 7 6 2
_______________________________________________ rrd-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
