I would always advise people to keep their MRTG/RRD system on a physical box, due to the clock skew issues mentioned previously. Also, if you are monitoring a virtualised guest, then any rate-based statistics it returns are suspect - this includes network, disk and CPU stats. If you can obtain totals and calculate the rates on the MRTG box then you're better off. CPU, memory and network stats from a guest are always suspect because you don't know where the actual constraint is - it may show 80% but in fact have a 20% 'ready time' (guest waiting to execute but resources not available) so you're actually at 100%.
Clock skew under VMware affects you more when the ESX server is loaded and the guest cpu ready times start to creep up, or when the guest is underloaded and has large idle times. Using the vmutils agent to clock synch helps (don't ever use vmutils AND ntpd together!), particularly if you use the new (default disabled) more aggressive synchronisation. I've a special MRTG plugin, check_vmware, that is currently in beta which uses the VI API to retrieve correct statistics for guest CPU and memory from the virtualcentre server. This may be of use to you? You can download it from www.steveshipway.org/forum if interested. There's a section in my book about monitoring virtualised servers and virtualisation of the MRTG host. Plug, plug. ;) Steve _______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
