Hi,
Hoping someone can help.
Since upgrading to the latest version using the SVN the device_ucd_load graphs have stopped generating and are no longer displayed within Observium. We use an external website and link to these graphs so our clients can view the server load and it'd be handy to get them working again.
Were they disabled/removed in the latest version? Is there any way to get them back?
Thanks
On 2014-02-27 08:15, Daniel Knights wrote:
Hi,
Hoping someone can help.
Since upgrading to the latest version using the SVN the device_ucd_load graphs have stopped generating and are no longer displayed within Observium. We use an external website and link to these graphs so our clients can view the server load and it'd be handy to get them working again.
Were they disabled/removed in the latest version?
No.
And as you didn't supply any screenshots or any debugging output, no one can even begin to guess what's not working.
adam.
I doubt a screenshot is going to help, the graph we used to pull from Observium is now just blank - https://www.dropbox.com/s/4sn7pt5b3ledc3z/Screenshot%202014-02-27%2017.48.02...
It's the same for all servers.
There's no screenshot to provide within Observium as they've completely disappeared. All other graphs are present except server load.
How do I find the debugging output?
On 27 February 2014 17:02, Adam Armstrong adama@memetic.org wrote:
On 2014-02-27 08:15, Daniel Knights wrote:
Hi,
Hoping someone can help.
Since upgrading to the latest version using the SVN the device_ucd_load graphs have stopped generating and are no longer displayed within Observium. We use an external website and link to these graphs so our clients can view the server load and it'd be handy to get them working again.
Were they disabled/removed in the latest version?
No.
And as you didn't supply any screenshots or any debugging output, no one can even begin to guess what's not working.
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
You mean this graph?
http://demo.observium.org/graphs/type=device_ucd_load/device=6/to=1393532605...
You can see the debugging output in the UI by putting either /debug=1/ or &debug=1 on the end of a page or graph URL.
You can see poller/discovery debugging output by running the poller with -d, for example:
./poller.php -h <device> -d -m ucd-mib
Will run only the UCD-MIB module (and the compulsory modules), and show debugging output, like :
------------------------------------------- including: includes/polling/ucd-mib.inc.php ... DEBUG: SNMP Auth options = -v2c -c /usr/bin/snmpbulkwalk -Cr100 -v2c -c -OQUs -m UCD-SNMP-MIB -M /home/observium/dev/mibs/rfc:/home/observium/dev/mibs/net-snmp 'udp':'alpha.memetic.org':'161' laLoadInt laLoadInt.1 = 352 laLoadInt.2 = 325 laLoadInt.3 = 196
RRD[cmd[update /mnt/ramdisk/observium_dev/alpha.memetic.org/ucd_load.rrd N:352:325:196] stdout[OK u:0.00 s:0.00 r:0.97] stderr[]] Module time: 0.073s --------------------------------------------
adam.
On 2014-02-27 11:49, Daniel Knights wrote:
I doubt a screenshot is going to help, the graph we used to pull from Observium is now just blank - https://www.dropbox.com/s/4sn7pt5b3ledc3z/Screenshot%202014-02-27%2017.48.02... [2]
It's the same for all servers.
There's no screenshot to provide within Observium as they've completely disappeared. All other graphs are present except server load.
How do I find the debugging output?
On 27 February 2014 17:02, Adam Armstrong adama@memetic.org wrote:
On 2014-02-27 08:15, Daniel Knights wrote:
Hi,
Hoping someone can help.
Since upgrading to the latest version using the SVN the device_ucd_load graphs have stopped generating and are no longer displayed within Observium. We use an external website and link to these graphs so our clients can view the server load and it'd be handy to get them working again.
Were they disabled/removed in the latest version?
No.
And as you didn't supply any screenshots or any debugging output, no one can even begin to guess what's not working.
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [2] https://www.dropbox.com/s/4sn7pt5b3ledc3z/Screenshot%202014-02-27%2017.48.02...
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hi,
i found out that it took a while to poll my linux boxes and the culprit is laLoadInt - tested from the command line:
[root@observium ~]# /usr/bin/snmpbulkwalk -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt Timeout: No Response from udp:burk1.example.com:161
snmpwalk does the trick:
[root@observium ~]# /usr/bin/snmpwalk -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 16 laLoadInt.2 = 7 laLoadInt.3 = 6
(timeout is set high for the impi stuff to work (supermicro via snmp))
Testing with 100 retries:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr100 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt Timeout: No Response from udp:burk1.example.com:161
But 1-2 works nicely:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr2 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 0 laLoadInt.2 = 3 laLoadInt.3 = 5
With 3:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr3 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 42 laLoadInt.2 = 14 laLoadInt.3 = 8 ^[Timeout: No Response from udp:burk1.example.com:161
So what value should be used for Retries?
/niklas
On 2014-02-27 21:29, Adam Armstrong wrote:
You mean this graph?
http://demo.observium.org/graphs/type=device_ucd_load/device=6/to=1393532605...
You can see the debugging output in the UI by putting either /debug=1/ or &debug=1 on the end of a page or graph URL.
You can see poller/discovery debugging output by running the poller with -d, for example:
./poller.php -h <device> -d -m ucd-mib
Will run only the UCD-MIB module (and the compulsory modules), and show debugging output, like :
including: includes/polling/ucd-mib.inc.php ... DEBUG: SNMP Auth options = -v2c -c /usr/bin/snmpbulkwalk -Cr100 -v2c -c -OQUs -m UCD-SNMP-MIB -M /home/observium/dev/mibs/rfc:/home/observium/dev/mibs/net-snmp 'udp':'alpha.memetic.org':'161' laLoadInt laLoadInt.1 = 352 laLoadInt.2 = 325 laLoadInt.3 = 196
RRD[cmd[update /mnt/ramdisk/observium_dev/alpha.memetic.org/ucd_load.rrd N:352:325:196] stdout[OK u:0.00 s:0.00 r:0.97] stderr[]] Module time: 0.073s
adam.
On 2014-02-27 11:49, Daniel Knights wrote:
I doubt a screenshot is going to help, the graph we used to pull from Observium is now just blank
[2]
It's the same for all servers.
There's no screenshot to provide within Observium as they've completely disappeared. All other graphs are present except server load.
How do I find the debugging output?
On 27 February 2014 17:02, Adam Armstrong adama@memetic.org wrote:
On 2014-02-27 08:15, Daniel Knights wrote:
Hi,
Hoping someone can help.
Since upgrading to the latest version using the SVN the device_ucd_load graphs have stopped generating and are no longer displayed within Observium. We use an external website and link to these graphs so our clients can view the server load and it'd be handy to get them working again.
Were they disabled/removed in the latest version?
No.
And as you didn't supply any screenshots or any debugging output, no one can even begin to guess what's not working.
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [2] https://www.dropbox.com/s/4sn7pt5b3ledc3z/Screenshot%202014-02-27%2017.48.02...
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
And a quick update,
setting Retries in the gui added the -r flag which was no good, setting the $config['snmp']['max-rep'] = true - added the -Cr100 which failed on mem and laLoadInt.
So I did a ugly fix and made snmp_command use snmp_walk if oids was laLoadInt - and now I can get the value and the polling time has gone from 60 to 7 seconds...
/niklas
On 2014-03-13 13:36, Niklas Larsson wrote:
Hi,
i found out that it took a while to poll my linux boxes and the culprit is laLoadInt - tested from the command line:
[root@observium ~]# /usr/bin/snmpbulkwalk -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt Timeout: No Response from udp:burk1.example.com:161
snmpwalk does the trick:
[root@observium ~]# /usr/bin/snmpwalk -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 16 laLoadInt.2 = 7 laLoadInt.3 = 6
(timeout is set high for the impi stuff to work (supermicro via snmp))
Testing with 100 retries:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr100 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt Timeout: No Response from udp:burk1.example.com:161
But 1-2 works nicely:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr2 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 0 laLoadInt.2 = 3 laLoadInt.3 = 5
With 3:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr3 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 42 laLoadInt.2 = 14 laLoadInt.3 = 8 ^[Timeout: No Response from udp:burk1.example.com:161
So what value should be used for Retries?
/niklas
On 2014-02-27 21:29, Adam Armstrong wrote:
You mean this graph?
http://demo.observium.org/graphs/type=device_ucd_load/device=6/to=1393532605...
You can see the debugging output in the UI by putting either /debug=1/ or &debug=1 on the end of a page or graph URL.
You can see poller/discovery debugging output by running the poller with -d, for example:
./poller.php -h <device> -d -m ucd-mib
Will run only the UCD-MIB module (and the compulsory modules), and show debugging output, like :
including: includes/polling/ucd-mib.inc.php ... DEBUG: SNMP Auth options = -v2c -c /usr/bin/snmpbulkwalk -Cr100 -v2c -c -OQUs -m UCD-SNMP-MIB -M /home/observium/dev/mibs/rfc:/home/observium/dev/mibs/net-snmp 'udp':'alpha.memetic.org':'161' laLoadInt laLoadInt.1 = 352 laLoadInt.2 = 325 laLoadInt.3 = 196
RRD[cmd[update /mnt/ramdisk/observium_dev/alpha.memetic.org/ucd_load.rrd N:352:325:196] stdout[OK u:0.00 s:0.00 r:0.97] stderr[]] Module time: 0.073s
adam.
On 2014-02-27 11:49, Daniel Knights wrote:
I doubt a screenshot is going to help, the graph we used to pull from Observium is now just blank
https://www.dropbox.com/s/4sn7pt5b3ledc3z/Screenshot%202014-02-27%2017.48.02...
[2]
It's the same for all servers.
There's no screenshot to provide within Observium as they've completely disappeared. All other graphs are present except server load.
How do I find the debugging output?
On 27 February 2014 17:02, Adam Armstrong adama@memetic.org wrote:
On 2014-02-27 08:15, Daniel Knights wrote:
Hi,
Hoping someone can help.
Since upgrading to the latest version using the SVN the device_ucd_load graphs have stopped generating and are no longer displayed within Observium. We use an external website and link to these graphs so our clients can view the server load and it'd be handy to get them working again.
Were they disabled/removed in the latest version?
No.
And as you didn't supply any screenshots or any debugging output, no one can even begin to guess what's not working.
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [2] https://www.dropbox.com/s/4sn7pt5b3ledc3z/Screenshot%202014-02-27%2017.48.02...
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hi,
What version of net-snmpd?
adam.
On 2014-03-13 06:36, Niklas Larsson wrote:
Hi,
i found out that it took a while to poll my linux boxes and the culprit is laLoadInt - tested from the command line:
[root@observium ~]# /usr/bin/snmpbulkwalk -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt Timeout: No Response from udp:burk1.example.com:161
snmpwalk does the trick:
[root@observium ~]# /usr/bin/snmpwalk -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 16 laLoadInt.2 = 7 laLoadInt.3 = 6
(timeout is set high for the impi stuff to work (supermicro via snmp))
Testing with 100 retries:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr100 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt Timeout: No Response from udp:burk1.example.com:161
But 1-2 works nicely:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr2 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 0 laLoadInt.2 = 3 laLoadInt.3 = 5
With 3:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr3 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 42 laLoadInt.2 = 14 laLoadInt.3 = 8 ^[Timeout: No Response from udp:burk1.example.com:161
So what value should be used for Retries?
/niklas
On 2014-02-27 21:29, Adam Armstrong wrote: You mean this graph?
http://demo.observium.org/graphs/type=device_ucd_load/device=6/to=1393532605... You can see the debugging output in the UI by putting either /debug=1/ or &debug=1 on the end of a page or graph URL.
You can see poller/discovery debugging output by running the poller with -d, for example:
./poller.php -h <device> -d -m ucd-mib
Will run only the UCD-MIB module (and the compulsory modules), and show debugging output, like :
including: includes/polling/ucd-mib.inc.php ... DEBUG: SNMP Auth options = -v2c -c /usr/bin/snmpbulkwalk -Cr100 -v2c -c -OQUs -m UCD-SNMP-MIB -M /home/observium/dev/mibs/rfc:/home/observium/dev/mibs/net-snmp 'udp':'alpha.memetic.org':'161' laLoadInt laLoadInt.1 = 352 laLoadInt.2 = 325 laLoadInt.3 = 196
RRD[cmd[update /mnt/ramdisk/observium_dev/alpha.memetic.org/ucd_load.rrd N:352:325:196] stdout[OK u:0.00 s:0.00 r:0.97] stderr[]] Module time: 0.073s
adam.
On 2014-02-27 11:49, Daniel Knights wrote: I doubt a screenshot is going to help, the graph we used to pull from Observium is now just blank
https://www.dropbox.com/s/4sn7pt5b3ledc3z/Screenshot%202014-02-27%2017.48.02... [2]
It's the same for all servers.
There's no screenshot to provide within Observium as they've completely disappeared. All other graphs are present except server load.
How do I find the debugging output?
On 27 February 2014 17:02, Adam Armstrong adama@memetic.org wrote:
On 2014-02-27 08:15, Daniel Knights wrote:
Hi,
Hoping someone can help.
Since upgrading to the latest version using the SVN the device_ucd_load graphs have stopped generating and are no longer displayed within Observium. We use an external website and link to these graphs so our clients can view the server load and it'd be handy to get them working again.
Were they disabled/removed in the latest version?
No.
And as you didn't supply any screenshots or any debugging output, no one can even begin to guess what's not working.
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [2] https://www.dropbox.com/s/4sn7pt5b3ledc3z/Screenshot%202014-02-27%2017.48.02... _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On 2014-03-14 04:36, Adam Armstrong wrote:
Hi,
What version of net-snmpd?
did a yum upgrade on the observium box and now I can't reproduce the issue -
Package updated: net-snmp (x86_64) from 5.5-44.el6_4.4 to 5.5
Version : 5.5 Release : 49.el6
Sorry for the noice...
/niklas
adam.
On 2014-03-13 06:36, Niklas Larsson wrote:
Hi,
i found out that it took a while to poll my linux boxes and the culprit is laLoadInt - tested from the command line:
[root@observium ~]# /usr/bin/snmpbulkwalk -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt Timeout: No Response from udp:burk1.example.com:161
snmpwalk does the trick:
[root@observium ~]# /usr/bin/snmpwalk -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 16 laLoadInt.2 = 7 laLoadInt.3 = 6
(timeout is set high for the impi stuff to work (supermicro via snmp))
Testing with 100 retries:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr100 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt Timeout: No Response from udp:burk1.example.com:161
But 1-2 works nicely:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr2 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 0 laLoadInt.2 = 3 laLoadInt.3 = 5
With 3:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr3 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 42 laLoadInt.2 = 14 laLoadInt.3 = 8 ^[Timeout: No Response from udp:burk1.example.com:161
So what value should be used for Retries?
/niklas
On 2014-02-27 21:29, Adam Armstrong wrote: You mean this graph?
http://demo.observium.org/graphs/type=device_ucd_load/device=6/to=1393532605... You can see the debugging output in the UI by putting either /debug=1/ or &debug=1 on the end of a page or graph URL.
You can see poller/discovery debugging output by running the poller with -d, for example:
./poller.php -h <device> -d -m ucd-mib
Will run only the UCD-MIB module (and the compulsory modules), and show debugging output, like :
including: includes/polling/ucd-mib.inc.php ... DEBUG: SNMP Auth options = -v2c -c /usr/bin/snmpbulkwalk -Cr100 -v2c -c -OQUs -m UCD-SNMP-MIB -M /home/observium/dev/mibs/rfc:/home/observium/dev/mibs/net-snmp 'udp':'alpha.memetic.org':'161' laLoadInt laLoadInt.1 = 352 laLoadInt.2 = 325 laLoadInt.3 = 196
RRD[cmd[update /mnt/ramdisk/observium_dev/alpha.memetic.org/ucd_load.rrd N:352:325:196] stdout[OK u:0.00 s:0.00 r:0.97] stderr[]] Module time: 0.073s
adam.
On 2014-02-27 11:49, Daniel Knights wrote: I doubt a screenshot is going to help, the graph we used to pull from Observium is now just blank
https://www.dropbox.com/s/4sn7pt5b3ledc3z/Screenshot%202014-02-27%2017.48.02... [2]
It's the same for all servers.
There's no screenshot to provide within Observium as they've completely disappeared. All other graphs are present except server load.
How do I find the debugging output?
On 27 February 2014 17:02, Adam Armstrong adama@memetic.org wrote:
On 2014-02-27 08:15, Daniel Knights wrote:
Hi,
Hoping someone can help.
Since upgrading to the latest version using the SVN the device_ucd_load graphs have stopped generating and are no longer displayed within Observium. We use an external website and link to these graphs so our clients can view the server load and it'd be handy to get them working again.
Were they disabled/removed in the latest version?
No.
And as you didn't supply any screenshots or any debugging output, no one can even begin to guess what's not working.
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [2] https://www.dropbox.com/s/4sn7pt5b3ledc3z/Screenshot%202014-02-27%2017.48.02... _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hi Niklas,
Seems you had an oldish version of net-snmpd which didn't handle large max-rep values correctly.
First Linux system I've seen which didn't!
adam.
On 2014-03-14 02:07, Niklas Larsson wrote:
On 2014-03-14 04:36, Adam Armstrong wrote: Hi,
What version of net-snmpd?
did a yum upgrade on the observium box and now I can't reproduce the issue -
Package updated: net-snmp (x86_64) from 5.5-44.el6_4.4 to 5.5
Version : 5.5 Release : 49.el6
Sorry for the noice...
/niklas
adam.
On 2014-03-13 06:36, Niklas Larsson wrote: Hi,
i found out that it took a while to poll my linux boxes and the culprit is laLoadInt - tested from the command line:
[root@observium ~]# /usr/bin/snmpbulkwalk -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt Timeout: No Response from udp:burk1.example.com:161
snmpwalk does the trick:
[root@observium ~]# /usr/bin/snmpwalk -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 16 laLoadInt.2 = 7 laLoadInt.3 = 6
(timeout is set high for the impi stuff to work (supermicro via snmp))
Testing with 100 retries:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr100 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt Timeout: No Response from udp:burk1.example.com:161
But 1-2 works nicely:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr2 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 0 laLoadInt.2 = 3 laLoadInt.3 = 5
With 3:
[root@observium ~]# /usr/bin/snmpbulkwalk -Cr3 -t '2' -v2c -c 'secret' -OQUs -m UCD-SNMP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'burk1.example.com':'161' laLoadInt laLoadInt.1 = 42 laLoadInt.2 = 14 laLoadInt.3 = 8 ^[Timeout: No Response from udp:burk1.example.com:161
So what value should be used for Retries?
/niklas
On 2014-02-27 21:29, Adam Armstrong wrote: You mean this graph?
http://demo.observium.org/graphs/type=device_ucd_load/device=6/to=1393532605... You can see the debugging output in the UI by putting either /debug=1/ or &debug=1 on the end of a page or graph URL.
You can see poller/discovery debugging output by running the poller with -d, for example:
./poller.php -h <device> -d -m ucd-mib
Will run only the UCD-MIB module (and the compulsory modules), and show debugging output, like :
including: includes/polling/ucd-mib.inc.php ... DEBUG: SNMP Auth options = -v2c -c /usr/bin/snmpbulkwalk -Cr100 -v2c -c -OQUs -m UCD-SNMP-MIB -M /home/observium/dev/mibs/rfc:/home/observium/dev/mibs/net-snmp 'udp':'alpha.memetic.org':'161' laLoadInt laLoadInt.1 = 352 laLoadInt.2 = 325 laLoadInt.3 = 196
RRD[cmd[update /mnt/ramdisk/observium_dev/alpha.memetic.org/ucd_load.rrd N:352:325:196] stdout[OK u:0.00 s:0.00 r:0.97] stderr[]] Module time: 0.073s
adam.
On 2014-02-27 11:49, Daniel Knights wrote: I doubt a screenshot is going to help, the graph we used to pull from Observium is now just blank
https://www.dropbox.com/s/4sn7pt5b3ledc3z/Screenshot%202014-02-27%2017.48.02... [2]
It's the same for all servers.
There's no screenshot to provide within Observium as they've completely disappeared. All other graphs are present except server load.
How do I find the debugging output?
On 27 February 2014 17:02, Adam Armstrong adama@memetic.org wrote:
On 2014-02-27 08:15, Daniel Knights wrote:
Hi,
Hoping someone can help.
Since upgrading to the latest version using the SVN the device_ucd_load graphs have stopped generating and are no longer displayed within Observium. We use an external website and link to these graphs so our clients can view the server load and it'd be handy to get them working again.
Were they disabled/removed in the latest version?
No.
And as you didn't supply any screenshots or any debugging output, no one can even begin to guess what's not working.
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [2] https://www.dropbox.com/s/4sn7pt5b3ledc3z/Screenshot%202014-02-27%2017.48.02... _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
participants (3)
-
Adam Armstrong -
Daniel Knights -
Niklas Larsson