Monitor Windows via WMI from Cacti on Linux
Moderators: Developers, Moderators
Just a quick update. Haven't made any changes as things have been working quite happily.
So far we have tested against and are using it on servers/workstations running the following.
* Windows XP
* Windows 2000 32bit
* Windows 2003 32bit
* Windows 2008 32bit and 64bit
* Exchange 2003 32bit
* SQL Server 2008 64bit and 32bit
* SQL Server 2005 32bit
* SQL Server 2000 32bit
* IIS 6
So far we have tested against and are using it on servers/workstations running the following.
* Windows XP
* Windows 2000 32bit
* Windows 2003 32bit
* Windows 2008 32bit and 64bit
* Exchange 2003 32bit
* SQL Server 2008 64bit and 32bit
* SQL Server 2005 32bit
* SQL Server 2000 32bit
* IIS 6
-
- Cacti Guru User
- Posts: 1884
- Joined: Mon Oct 16, 2006 5:57 am
- Location: United Kingdom
- Contact:
Does anyone have a working copy of WMIC for CentOS (CactiEZCD 6) that they can post here ? The one I am using complains:
/var/www/html/scripts/wmic: error while loading shared libraries: requires glibc 2.5 or later dynamic linker
Thanks
/var/www/html/scripts/wmic: error while loading shared libraries: requires glibc 2.5 or later dynamic linker
Thanks
Cacti Version 0.8.8b
Cacti OS Ubuntu LTS
RRDTool Version RRDTool 1.4.7
Poller Information
Type SPINE 0.8.8b
Client RPC Latency for Exchange 2003.
Quite a good measure to see how things are coping. The data source also has a few other options which I haven't got graphs for but may be useful like number of RPC operations per second etc.
Quite a good measure to see how things are coping. The data source also has a few other options which I haven't got graphs for but may be useful like number of RPC operations per second etc.
- Attachments
-
- cacti_graph_template_exchange_-_client_rpc_latency_wmi.xml
- (14.51 KiB) Downloaded 446 times
Questions and FAQ
I posted questions couple weeks back that I answered myself. Memory tempate wasn't working for me. It was -- as you wrote to someone else -- cdef issue.
I had to change cdef to something like d,h -
Other question I had related to values in Legends showing up with M, m or whatever.
That was simple. RTFM for rrd and I got it.
The wmi queries for a bunch of the exchange performance items are COUNTERS. This makes sense to me but how is it graphed? Is a cdef applied to it? Legend doesn't show anything if I change to Exact Number and the values are odd if I don't.
An faq would be great. I'm a good clueless consumer that could test such a document and would love to help.
I had to change cdef to something like d,h -
Other question I had related to values in Legends showing up with M, m or whatever.
That was simple. RTFM for rrd and I got it.
The wmi queries for a bunch of the exchange performance items are COUNTERS. This makes sense to me but how is it graphed? Is a cdef applied to it? Legend doesn't show anything if I change to Exact Number and the values are odd if I don't.
An faq would be great. I'm a good clueless consumer that could test such a document and would love to help.
You will have to bear with me as I am still learning a lot about cacti/rrd as well
Basically from my understanding the way it works out the graph is your rrd has a big table of values which it knows are over x amount of time. With a counter it stores the difference between each row/time. So your counter might be 1000 1001 1002 so going up by one every x amount of time it will store this as 1000, 1, 1 storing only the change. This is for a counter gauge stores the whole value and I cant remember derivative.
So basically each row or x time period in the table is 5 mins, so it knows that you did y number of messages in 5 minutes it will graph the difference between those two time periods on the graph. BUT the other issue is that the graph will be ideally showing per second but your data is only polled every 5 mins, so there is a bit of leveling. For example you might have done 300 messages in that 5 minute period but the graph will show 1 message per sec which is correct and will be flat. E.g. for that 5 mins all it can tell you is that you did at least 1 message a sec over 5 minutes. It may have actually been 100 messages in 10 seconds in 3 intervals over that 5 mins but as it only has recorded 300 over the 5 mins thats all it can show you.
Hopefully that makes some sense. You can increase the accuracy of cacti and poll time but it is at the cost of performance. And in the end most of us are using cacti for getting a reasonable idea of whats going on, we don't need to know exactly what most hosts are doing at every second, if we do there are other tools to do this. Like you'd use perfmon when investigating a problem period for accuracy to find out exactly whats going on but you'd have a rough idea looking at cacti which doesnt impose a possible performance hit.
Basically from my understanding the way it works out the graph is your rrd has a big table of values which it knows are over x amount of time. With a counter it stores the difference between each row/time. So your counter might be 1000 1001 1002 so going up by one every x amount of time it will store this as 1000, 1, 1 storing only the change. This is for a counter gauge stores the whole value and I cant remember derivative.
So basically each row or x time period in the table is 5 mins, so it knows that you did y number of messages in 5 minutes it will graph the difference between those two time periods on the graph. BUT the other issue is that the graph will be ideally showing per second but your data is only polled every 5 mins, so there is a bit of leveling. For example you might have done 300 messages in that 5 minute period but the graph will show 1 message per sec which is correct and will be flat. E.g. for that 5 mins all it can tell you is that you did at least 1 message a sec over 5 minutes. It may have actually been 100 messages in 10 seconds in 3 intervals over that 5 mins but as it only has recorded 300 over the 5 mins thats all it can show you.
Hopefully that makes some sense. You can increase the accuracy of cacti and poll time but it is at the cost of performance. And in the end most of us are using cacti for getting a reasonable idea of whats going on, we don't need to know exactly what most hosts are doing at every second, if we do there are other tools to do this. Like you'd use perfmon when investigating a problem period for accuracy to find out exactly whats going on but you'd have a rough idea looking at cacti which doesnt impose a possible performance hit.
-
- Cacti Guru User
- Posts: 1884
- Joined: Mon Oct 16, 2006 5:57 am
- Location: United Kingdom
- Contact:
I've setup a test box running Ubuntu Server 8.10. The wmi-client works fine, and was as simple as using
sudo apt-get install wmi-client
All I had to do was change the location of the WMIC binary, and setup the credentials in wmi-login.php, and everything seems fine.
Still ironing out some kinks in Ubuntu, but I plan to move away from Windows soon to a new Ubuntu server.
sudo apt-get install wmi-client
All I had to do was change the location of the WMIC binary, and setup the credentials in wmi-login.php, and everything seems fine.
Still ironing out some kinks in Ubuntu, but I plan to move away from Windows soon to a new Ubuntu server.
Last edited by mcutting on Tue Feb 10, 2009 3:09 am, edited 1 time in total.
Cacti Version 0.8.8b
Cacti OS Ubuntu LTS
RRDTool Version RRDTool 1.4.7
Poller Information
Type SPINE 0.8.8b
Glad to here it worked well. Ubuntu and Debian are the easiest to get it running on as they have packages for the WMI client readily available.mcutting wrote:I've setup a test box running Ubuntu Server 8.10. The wmi-client works fine, and was as simple as using
apt-get install wmi-client
All I had to do was change the location of the WMIC binary, and setup the credentials in wmi-login.php, and everything seems fine.
Still ironing out some kinks in Ubuntu, but I plan to move away from Windows soon to a new Ubuntu server.
I've got a couple new templates I've been testing today, mainly for monitoring the stats of a single process. Allows you to track the privileged, user and processor time of a process, its threads and handles and its memory usage. We have an app which tends to slowly leak, this way we can better predict is memory usage over time rather than the whole system.
New templates available.
* System Calls per Sec
* Context Switches per Sec
* Exchange RPC Client Latency (pic below)
* Processor Queue Length
* Per Process Stats (handles/threads + memory usage)
* Processes total
As always latest templates are in SVN and via the WebSVN interface below
http://svn.parkingdenied.com/CactiWMI/trunk/templates/
* System Calls per Sec
* Context Switches per Sec
* Exchange RPC Client Latency (pic below)
* Processor Queue Length
* Per Process Stats (handles/threads + memory usage)
* Processes total
As always latest templates are in SVN and via the WebSVN interface below
http://svn.parkingdenied.com/CactiWMI/trunk/templates/
- Attachments
-
- process-store-general.png (19.97 KiB) Viewed 10951 times
-
- process-store-memory.png (15.74 KiB) Viewed 10951 times
-
- system-calls.png (16.71 KiB) Viewed 10951 times
-
- exchange-rpc-latency.png (27.29 KiB) Viewed 10951 times
-
- system-context-switches.png (16.79 KiB) Viewed 10951 times
Who is online
Users browsing this forum: No registered users and 2 guests