Hi!, I noticed just today that observium doesn't graph i/o wait time from CPU usage. Only user/nice/system/idle, i/o wait is not provided by SNMP or it's just missing in Observium?
Regards,
On Fri, 2012-03-23 at 17:28 +0000, Adam Armstrong wrote:
On 2012-03-23 12:07, Ciro Iriarte wrote:
Hi!, I noticed just today that observium doesn't graph i/o wait time from CPU usage. Only user/nice/system/idle, i/o wait is not provided by SNMP or it's just missing in Observium?
Regards,
I'm not sure :)
I'm pretty sure we checked this out and it's not in the mib. Which is a pity as it's the most important number for disk stuff ;-/
Tom
On 2012-03-23 17:57, Tom Laermans wrote:
On Fri, 2012-03-23 at 17:28 +0000, Adam Armstrong wrote:
On 2012-03-23 12:07, Ciro Iriarte wrote:
Hi!, I noticed just today that observium doesn't graph i/o wait time from CPU usage. Only user/nice/system/idle, i/o wait is not provided by SNMP or it's just missing in Observium?
Regards,
I'm not sure :)
I'm pretty sure we checked this out and it's not in the mib. Which is a pity as it's the most important number for disk stuff ;-/
I can do this with the new unix agent. :)
adam.
2012/3/23 Tom Laermans tom.laermans@powersource.cx:
On Fri, 2012-03-23 at 17:28 +0000, Adam Armstrong wrote:
On 2012-03-23 12:07, Ciro Iriarte wrote:
Hi!, I noticed just today that observium doesn't graph i/o wait time from CPU usage. Only user/nice/system/idle, i/o wait is not provided by SNMP or it's just missing in Observium?
Regards,
I'm not sure :)
I'm pretty sure we checked this out and it's not in the mib. Which is a pity as it's the most important number for disk stuff ;-/
Tom
I was worried about missing CPU time and fake idle info...
Regards,
On 2012-03-23 19:23, Ciro Iriarte wrote:
2012/3/23 Tom Laermanstom.laermans@powersource.cx:
On Fri, 2012-03-23 at 17:28 +0000, Adam Armstrong wrote:
On 2012-03-23 12:07, Ciro Iriarte wrote:
Hi!, I noticed just today that observium doesn't graph i/o wait time from CPU usage. Only user/nice/system/idle, i/o wait is not provided by SNMP or it's just missing in Observium?
Regards,
I'm not sure :)
I'm pretty sure we checked this out and it's not in the mib. Which is a pity as it's the most important number for disk stuff ;-/
Tom
I was worried about missing CPU time and fake idle info...
Pretty soon we might replace a lot of things we currently get from Net-SNMP with things from a shell-script based agent.
It should let us get a lot of very nice stats from Linux boxes in particular. :)
adam.
2012/3/23 Adam Armstrong adama@memetic.org:
On 2012-03-23 19:23, Ciro Iriarte wrote:
2012/3/23 Tom Laermanstom.laermans@powersource.cx:
On Fri, 2012-03-23 at 17:28 +0000, Adam Armstrong wrote:
On 2012-03-23 12:07, Ciro Iriarte wrote:
Hi!, I noticed just today that observium doesn't graph i/o wait time from CPU usage. Only user/nice/system/idle, i/o wait is not provided by SNMP or it's just missing in Observium?
Regards,
I'm not sure :)
I'm pretty sure we checked this out and it's not in the mib. Which is a pity as it's the most important number for disk stuff ;-/
Tom
I was worried about missing CPU time and fake idle info...
Pretty soon we might replace a lot of things we currently get from Net-SNMP with things from a shell-script based agent.
It should let us get a lot of very nice stats from Linux boxes in particular. :)
adam.
Great!.
Regards,
On 24/03/12 05:34, Adam Armstrong wrote:
... I was worried about missing CPU time and fake idle info... Pretty soon we might replace a lot of things we currently get from Net-SNMP with things from a shell-script based agent.
It should let us get a lot of very nice stats from Linux boxes in particular. :)
Is that going to be optional, or will it become the only supported mechanism? I'd certainly prefer the former.
Paul
On Sat, 24 Mar 2012 09:00:29 +1000, Paul Gear observium@gear.dyndns.org wrote:
On 24/03/12 05:34, Adam Armstrong wrote:
... I was worried about missing CPU time and fake idle info... Pretty soon we might replace a lot of things we currently get from Net-SNMP with things from a shell-script based agent.
It should let us get a lot of very nice stats from Linux boxes in particular. :)
Is that going to be optional, or will it become the only supported mechanism? I'd certainly prefer the former.
Not using it will probably result in reduced functionality.
We don't have the resources to maintain two separate methods of extracting the same information.
Net-SNMP has proved to be too limiting.
adam.
On 24.03.2012 2:54, Adam Armstrong wrote:
Not using it will probably result in reduced functionality.
We don't have the resources to maintain two separate methods of extracting the same information.
Net-SNMP has proved to be too limiting.
So this mean we get functionality like currently net-snmp does if we don't use new bash script. We'd prefer to stay with net-snmp also.
On 24.03.2012 2:54, Adam Armstrong wrote:
Not using it will probably result in reduced functionality.
We don't have the resources to maintain two separate methods of extracting the same information.
Net-SNMP has proved to be too limiting.
So this mean we get functionality like currently net-snmp does if we don't use new bash script. We'd prefer to stay with net-snmp also.
Moving to a bash script from SNMP would be a bit of a pain, but I'm definitely interested in this new script.
SNMP has some drawbacks. There are the already discussed limitations of the MIB. But also as a protocol it's not very efficient at polling. Hitting one shell script and pulling down all the metrics you need in one TCP connection would be far more efficient than SNMP. Our polling machine is hammered 24x7 because of this.
Adam: How will the networking part be handled in the agent, does the script run daemonised? Or will it be called via xinetd, over ssh, etc?
In any case, I'm interested in testing this out when it's ready.
Cheers,
Tim.
________________________________
This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.
On 2012-03-26 01:56, GOLLSCHEWSKY, Tim wrote:
On 24.03.2012 2:54, Adam Armstrong wrote:
Not using it will probably result in reduced functionality.
We don't have the resources to maintain two separate methods of extracting the same information.
Net-SNMP has proved to be too limiting.
So this mean we get functionality like currently net-snmp does if we don't use new bash script. We'd prefer to stay with net-snmp also.
Moving to a bash script from SNMP would be a bit of a pain, but I'm definitely interested in this new script.
SNMP has some drawbacks. There are the already discussed limitations of the MIB. But also as a protocol it's not very efficient at polling. Hitting one shell script and pulling down all the metrics you need in one TCP connection would be far more efficient than SNMP. Our polling machine is hammered 24x7 because of this.
The majority of that load is likely to be RRD-related, rather than SNMP-related, try faster disks or more spindles :)
But yes, one of the reasons we're doing this is performance. (The others are accuracy and amount of data)
Adam: How will the networking part be handled in the agent, does the script run daemonised? Or will it be called via xinetd, over ssh, etc?
In any case, I'm interested in testing this out when it's ready.
The basics are in SVN now, but disabled as default.
$config['poller_modules']['unix-agent'] = 0;
The agent itself isn't in SVN yet. It needs xinetd to run, and includes no security at all (all security is provided by xinetd and/or firewalling).
adam.
On 2012-03-26 10:59, Adam Armstrong wrote:
The basics are in SVN now, but disabled as default.
$config['poller_modules']['unix-agent'] = 0;
The agent itself isn't in SVN yet. It needs xinetd to run, and includes no security at all (all security is provided by xinetd and/or firewalling).
I'm also considering writing a Munin-esque plugin system to allow graphing of arbitrary values from hosts running the agent.
http://munin-monitoring.org/wiki/HowToWritePlugins
Comments?
Something similar might also be done for SNMP hosts at a later date.
adam.
The agent itself isn't in SVN yet. It needs xinetd to run, and includes no security at all (all security is provided by xinetd and/or firewalling).
I'm also considering writing a Munin-esque plugin system to allow graphing of arbitrary values from hosts running the agent.
http://munin-monitoring.org/wiki/HowToWritePlugins
Comments?
Something like this would be pretty handy!
Tim.
________________________________
This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.
An update on the agent:
I've converted the apache application on my development system to automatically be created when the unix agent is configured to send apache statistics.
At some point in the near future, the entire current "apps" infrastructure will be replaced with this method. It involves putting a script onto the monitored device which injects statistics into the agent. This is parsed by the unix-agent module which populates the applications table. The applications module then reads data directly from the array created by the unix-agent module rather than polling directly from the host.
We hope it should be faster, but we're mostly doing this to make it easier. Injecting things into SNMP is a pain. We also gain the ability to "detect" applications at poller time with no additional work, as we now do with ports and some other things.
adam.
On 2012-03-27 01:12, GOLLSCHEWSKY, Tim wrote:
The agent itself isn't in SVN yet. It needs xinetd to run, and includes no security at all (all security is provided by xinetd and/or firewalling).
I'm also considering writing a Munin-esque plugin system to allow graphing of arbitrary values from hosts running the agent.
http://munin-monitoring.org/wiki/HowToWritePlugins
Comments?
Something like this would be pretty handy!
Tim.
This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hi Adam,
We hope it should be faster, but we're mostly doing this to make it easier. Injecting things into SNMP is a pain. We also gain the ability to "detect" applications at poller time with no additional work, as we now do with ports and some other things.
This sounds great.
Is the intention also that the unix agent will one day capture all the metrics we currently capture with SNMP? So one day "snmpd" can be turned off?
Or will the agent work in tandem with the SNMP poller?
Cheers,
Tim.
________________________________
This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.
On 2012-04-19 05:08, GOLLSCHEWSKY, Tim wrote:
Hi Adam,
We hope it should be faster, but we're mostly doing this to make it easier. Injecting things into SNMP is a pain. We also gain the ability to "detect" applications at poller time with no additional work, as we now do with ports and some other things.
This sounds great.
Is the intention also that the unix agent will one day capture all the metrics we currently capture with SNMP? So one day "snmpd" can be turned off?
Or will the agent work in tandem with the SNMP poller?
I don't think we will replace any of the 'standard' things which are already very well supported with SNMP. Certainly we would never replace network statistics, as that would require duplicating far too much code.
The intention is to use the Agent to obtain information that we would otherwise have to hack into Net-SNMP via extend scripts, and to perhaps provide extra information for modules which also poll via SNMP.
I don't think the experience of using the existing 'applications' system with SNMP injection scripts was terribly good. It is a pain to set up, a pain to test and a pain to autodetect.
Currently we can do the following from the Agent:
RPM Packages (new) Apache statistics (replacing the old SNMP injection) MySQL statistics (replacing the old SNMP injection) NGINX statistics (replacing the old SNMP injection)
Basically: Anyone who is currently using Observium but who hasn't use the "applications" framework will see no difference if they don't install the agent. Anyone who is currently using the "applications" framework will have to migrate all of their applications to the agent.
Anyone who doesn't install the agent in the future will miss out on future improvements to the Linux support in particular, as there are a lot of things we can fetch via the agent that we can't get easily via SNMP.
adam.
2012/3/24 Nikolay Shopik shopik@inblock.ru:
On 24.03.2012 2:54, Adam Armstrong wrote:
Not using it will probably result in reduced functionality.
We don't have the resources to maintain two separate methods of extracting the same information.
Net-SNMP has proved to be too limiting.
So this mean we get functionality like currently net-snmp does if we don't use new bash script. We'd prefer to stay with net-snmp also.
Well, in fact in some scenarios is almost impossible to touch the host (layer 8 issues), enabling SNMP is less invasive, adding some kind of agent will make it harder...
For self controlled hosts, it's not an issue...
Regards,
participants (6)
-
Adam Armstrong -
Ciro Iriarte -
GOLLSCHEWSKY, Tim -
Nikolay Shopik -
Paul Gear -
Tom Laermans