Windows performance counters & VBS/WMI via SNMP
Moderators: Developers, Moderators
erwan.l
Now I have used the version of 2.0.0.14.
I want to find the exact reason for the server snmp service downed.
I find that I didn't use the trackerstatus.exe to get the defined data. only use the sample counter.ini like that:
;this file is optional
;you can define here the hardcoded oid for specific ms counters
[1.3.6.1.4.1.15.5.1]
counter=memory\Available Bytes
[1.3.6.1.4.1.15.5.2]
counter=virtual memory\Available Bytes
But the graph by cacti also like that 1.jpg displayed。
Can you help me?
PS:The CPU is a little high,is that the reason???
I have sent you a mail .please received it ..thanks a lot : )
Now I have used the version of 2.0.0.14.
I want to find the exact reason for the server snmp service downed.
I find that I didn't use the trackerstatus.exe to get the defined data. only use the sample counter.ini like that:
;this file is optional
;you can define here the hardcoded oid for specific ms counters
[1.3.6.1.4.1.15.5.1]
counter=memory\Available Bytes
[1.3.6.1.4.1.15.5.2]
counter=virtual memory\Available Bytes
But the graph by cacti also like that 1.jpg displayed。
Can you help me?
PS:The CPU is a little high,is that the reason???
I have sent you a mail .please received it ..thanks a lot : )
- Attachments
-
- 1.jpg (45.19 KiB) Viewed 7821 times
-
- cpu.jpg (91.79 KiB) Viewed 7821 times
Hi Stone_II,
I am afraid I cant help much more.
I dont know this executable you call.
My feeling is that the issue lays there.
First goal of snmptools is to interface MS perf counters.
Eventually you can call VBS thru wscript or cscript engine and I am pretty confident there as at worse you will face vbs script errors.
Now, when when you call external executables, I cannot guarantee what will happen there since I cant control what is ran outthere.
Regards,
Erwan.
I am afraid I cant help much more.
I dont know this executable you call.
My feeling is that the issue lays there.
First goal of snmptools is to interface MS perf counters.
Eventually you can call VBS thru wscript or cscript engine and I am pretty confident there as at worse you will face vbs script errors.
Now, when when you call external executables, I cannot guarantee what will happen there since I cant control what is ran outthere.
Regards,
Erwan.
Stone_ll wrote:erwan.l
Now I have used the version of 2.0.0.14.
I want to find the exact reason for the server snmp service downed.
I find that I didn't use the trackerstatus.exe to get the defined data. only use the sample counter.ini like that:
;this file is optional
;you can define here the hardcoded oid for specific ms counters
[1.3.6.1.4.1.15.5.1]
counter=memory\Available Bytes
[1.3.6.1.4.1.15.5.2]
counter=virtual memory\Available Bytes
But the graph by cacti also like that 1.jpg displayed。
Can you help me?
PS:The CPU is a little high,is that the reason???
I have sent you a mail .please received it ..thanks a lot : )
erwan.l wrote:Hi Stone_II,
I am afraid I cant help much more.
I dont know this executable you call.
My feeling is that the issue lays there.
First goal of snmptools is to interface MS perf counters.
Eventually you can call VBS thru wscript or cscript engine and I am pretty confident there as at worse you will face vbs script errors.
Now, when when you call external executables, I cannot guarantee what will happen there since I cant control what is ran outthere.
Regards,
Erwan.
Sorry ,erwan.l
I am afraid that you havent understand my meaning. ^_^
Now the counter.ini's content I used is like this :
[1.3.6.1.4.1.15.5.1]
counter=memory\Available Bytes
[1.3.6.1.4.1.15.5.2]
counter=virtual memory\Available Bytes
in other word I havent used my user-defined executable ,totally use your example counter.ini.
But the graph created by cacti is incoherently.
- Attachments
-
- 1_587.jpg (45.19 KiB) Viewed 7765 times
version 2.0.0.15 uploaded here : http://erwan.l.free.fr/snmptools/snmptools2.zip .
Change log :
2.0.0.15
added : new reg key "collect_delay"(dword) to control the time between 2 perf snapshot (default=1000ms)
modified : PDH_FMT_NOSCALE added to PdhGetFormattedCounterValue / PdhCalculateCounterFromRawValue
fixed : raw counters (flag="raw") fully supported thru PdhCalculateCounterFromRawValue
added : new flag "round" to round a float number to integer (not sure all snmp clients like float in strings)
modified : asn_counter64 does not work for now, back to ASN_OCTETSTRING for 64bits values
not much news except for the raw counters which mimic the way snmp informant works.
might give more accurate performance counters values.
/Erwan
Change log :
2.0.0.15
added : new reg key "collect_delay"(dword) to control the time between 2 perf snapshot (default=1000ms)
modified : PDH_FMT_NOSCALE added to PdhGetFormattedCounterValue / PdhCalculateCounterFromRawValue
fixed : raw counters (flag="raw") fully supported thru PdhCalculateCounterFromRawValue
added : new flag "round" to round a float number to integer (not sure all snmp clients like float in strings)
modified : asn_counter64 does not work for now, back to ASN_OCTETSTRING for 64bits values
not much news except for the raw counters which mimic the way snmp informant works.
might give more accurate performance counters values.
/Erwan
Last edited by erwan.l on Tue Apr 14, 2009 3:26 pm, edited 1 time in total.
yes,my meaning is what your said.Now I use the newest version 15.erwan.l wrote:Hi Stone_II,
I understand now.
By incoherent, do you mean the values or the white space (aka cacti not retrieving values from the snmp server from time to time) ?
Regards,
Erwan
this server's cpu is little high,just like that the graph I uploaded.
Is this the reason.and my server's os run the Chinese language.
erwan.l wrote:Hi Stone_II,
The chinese langage could be the issue (something with unicode and memory allocation).
The cpu is busy indeed and you may have snmp timeouts from time to time, hence the white space.
You can try this without harming your graphs : raise the snmp timeout to 5000 (ms).
Regards,
Erwan.
your meaning is that? I raise the server's snmp timeout to 5000 ms .the windows os ?
Hi, erwan.l
I encountered a strange question:
I used the sample counter.ini file, when i try to draw graph for OID 1.3.6.1.4.1.15.10.3.1, cacti report errors:
04/16/2009 04:55:05 PM - CMDPHP: Poller[0] Host[6] DS[66] WARNING: Result from SNMP not valid. Partial Result: U
But the agent log file seems no error:
17:17:34:447 , GetRequest: OID=1.3.6.1.4.1.15.10.3.1 (10)
17:17:34:447 , GetPerf: path=memory\Available Bytes
17:17:34:463 , GetPerf: pdh_counter_path=\memory\Available Bytes
17:17:35:463 , GetPerf: vartype=Double
17:17:35:463 , GetRequest: value=1630306304 asn_type=2
17:17:35:463 , GetRequest: OK
17:17:35:479 , SnmpExtensionQueryEx
17:17:35:479 , nRequestType=SNMP_EXTENSION_GET
17:17:35:494 , GetRequest: OID=1.3.6.1.4.1.15.10.3.1 (10)
17:17:35:494 , GetPerf: path=memory\Available Bytes
17:17:35:510 , GetPerf: pdh_counter_path=\memory\Available Bytes
17:17:36:510 , GetPerf: vartype=Double
17:17:36:510 , GetRequest: value=1630306304 asn_type=2
17:17:36:525 , GetRequest: OK
17:17:46:869 , SnmpExtensionQueryEx
And the OID 1.3.6.1.4.1.15.1 is ok.
Could you tell me how to do?
Thanks
xdg
I encountered a strange question:
I used the sample counter.ini file, when i try to draw graph for OID 1.3.6.1.4.1.15.10.3.1, cacti report errors:
04/16/2009 04:55:05 PM - CMDPHP: Poller[0] Host[6] DS[66] WARNING: Result from SNMP not valid. Partial Result: U
But the agent log file seems no error:
17:17:34:447 , GetRequest: OID=1.3.6.1.4.1.15.10.3.1 (10)
17:17:34:447 , GetPerf: path=memory\Available Bytes
17:17:34:463 , GetPerf: pdh_counter_path=\memory\Available Bytes
17:17:35:463 , GetPerf: vartype=Double
17:17:35:463 , GetRequest: value=1630306304 asn_type=2
17:17:35:463 , GetRequest: OK
17:17:35:479 , SnmpExtensionQueryEx
17:17:35:479 , nRequestType=SNMP_EXTENSION_GET
17:17:35:494 , GetRequest: OID=1.3.6.1.4.1.15.10.3.1 (10)
17:17:35:494 , GetPerf: path=memory\Available Bytes
17:17:35:510 , GetPerf: pdh_counter_path=\memory\Available Bytes
17:17:36:510 , GetPerf: vartype=Double
17:17:36:510 , GetRequest: value=1630306304 asn_type=2
17:17:36:525 , GetRequest: OK
17:17:46:869 , SnmpExtensionQueryEx
And the OID 1.3.6.1.4.1.15.1 is ok.
Could you tell me how to do?
Thanks
xdg
snmpget is ok:
[root@nfs_server resource]# snmpget -v 2c -c public huzsbk01 1.3.6.1.4.1.15.10.3.1
SNMPv2-SMI::enterprises.15.10.3.1 = INTEGER: 1573924864
[root@nfs_server resource]# snmpget -v 2c -c public huzsbk01 1.3.6.1.4.1.15.10.3.1
SNMPv2-SMI::enterprises.15.10.3.1 = INTEGER: 1571737600
And datasource maximum value is 100, type is "gauge".
Thanks
[root@nfs_server resource]# snmpget -v 2c -c public huzsbk01 1.3.6.1.4.1.15.10.3.1
SNMPv2-SMI::enterprises.15.10.3.1 = INTEGER: 1573924864
[root@nfs_server resource]# snmpget -v 2c -c public huzsbk01 1.3.6.1.4.1.15.10.3.1
SNMPv2-SMI::enterprises.15.10.3.1 = INTEGER: 1571737600
And datasource maximum value is 100, type is "gauge".
Thanks
Catchtime,
Lets exclude a snmp timeout issue on a cacti side.
In your counters.ini, just above the "counters=" line, add flag=norefresh.
Indeed, the "memory\Available Bytes" is a simple counter and does not need interval calculation.
By default, snmptools will take 1000ms to send the data back.
Note that you could also shorten that 1000ms to 500ms or 100ms, for all counters, by using the collect_delay reg key under snmptools reg key.
Note that you would also achieve the same by increasing the timeout on your device to 2000ms for instance.
Let me know if this solves your issue.
Regards,
Erwan.
Lets exclude a snmp timeout issue on a cacti side.
In your counters.ini, just above the "counters=" line, add flag=norefresh.
Indeed, the "memory\Available Bytes" is a simple counter and does not need interval calculation.
By default, snmptools will take 1000ms to send the data back.
Note that you could also shorten that 1000ms to 500ms or 100ms, for all counters, by using the collect_delay reg key under snmptools reg key.
Note that you would also achieve the same by increasing the timeout on your device to 2000ms for instance.
Let me know if this solves your issue.
Regards,
Erwan.
Who is online
Users browsing this forum: No registered users and 0 guests