On Fri, Nov 11, 2011 at 3:24 PM, Florian Haas <[email protected]> wrote: > Hi Russell, > > thanks again; more comments below. > > On 2011-11-11 20:55, Russell Bryant wrote: >>>> asterisk -rx will help verify that the process isn't totally hosed for >>>> some reason. The specific command issued to Asterisk, "core show >>>> uptime", is unlikely to help detect any additional type of error, >>>> though. One improvement would be "core show channels". If just about >>>> anything locks up inside of Asterisk, it's going to eventually >>>> escalate to here, and will cause this command to fail. The one major >>>> caveat here is that it's not a command that should be run at a very >>>> high frequency. >>> >>> Users would typically run this at an interval of 10-30 seconds. Is that >>> too high a frequency? >> >> No. I would be more concerned if it was once a second or less. > > OK. Now, please realize that Martin is our resident Asterisk expert and > I only reviewed the RA, and I'm jumping in for him as he is recovering > from a flu. Thus, please bear with me if this is a silly question: when > we do "core show channels", should we just check if the commmand > completes OK? Does it make sense to define a regex with the command > output should (or should not) match? Or is this so specific to > individual setups that the user had best define such a regex for themselves?
You could check the output. The output probably won't change, but it's certainly not guaranteed to. Here is example output from my "heavily loaded" personal system. pbx*CLI> core show channels count 0 active channels 0 active calls 15 calls processed >>>> There are additional things that would be interesting to consider, but >>>> they get into technology specific health checks. For example, if SIP >>>> is being used, I would want to send it a simple SIP request (like >>>> OPTIONS) to make sure it is responding. >>> >>> Which client binary would you suggest in using for that purpose? >> >> Another response said SIPp. That's my first instinct, as well. This >> type of functionality would have to be optional for the resource >> agent, though. > > Any other suggestions? We typically try to go with "standard" binaries > as much as we can for monitoring, so users don't have to install > relatively obscure packages just for being able to monitor resources > (and we really _want_ them to monitor resources, obviously). And I > notice that while SIPp is easily available on SourceForge, not too many > distros seem to ship its binaries. You're right that SIPp isn't packaged really, but it would have to be an optional feature of the resource agent regarless of what utilities it uses. A little 'nc' based hack might work. You wouldn't be able to do any validation of the message, but all you really care about is that a packet came back. Another utility to look at is 'sipsak'. I see that on both Ubuntu and Fedora (those are the only ones I checked). > Besides, what if the PBX happens to > be, say, an IAX only installation? Is there perhaps another test utility > that you could suggest, preferably one whose binaries typically ship > with Asterisk? Right. Or what if it's DAHDI only, or one of the other channel types only. SIP is just the most common. Channel technology specific checks would have to all be optional. If someone was going to start with one of them, SIP would be the most valuable. -- Russell bryant _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
