[Fwd: [PEAR] Net_Monitor]

-------- Original Message -------- Subject: [PEAR] Net_Monitor Date: Tue, 28 Feb 2006 23:58:22 -0500 From: Philippe Jausions <Philippe.Jausions@11abacus.com> Organization: 11abacus To: bertrand@toggg.com, cyberscribe@php.net Bertrand, Robert, I'm planning on using the Net_Monitor package. However, I'm not planning on using it for standard protocols (at least at first), but rather to do remote monitoring of the behavior of the servers. My plan is to write a driver for Net_Monitor_Service that would call an URL on a remote site (I may piggyback on the HTTP/HTTPS service monitor for that) to check a database connection status. I plan to use XML to report the details of the information. I came across "Common Base Event": http://dev.eclipse.org/viewcvs/indextools.cgi/~checkout~/hyades-home/docs/components/common_base_event/cbe101spec/CommonBaseEvent_SituationData_V1.0.1.pdf http://www-128.ibm.com/developerworks/autonomic/library/ac-cbe1/ That would fit perfectly into Net_Monitor, I'm not sure about license terms though. I'm trying to figure that out. What do you think of it? Otherwise, do you have a plan on plugging PEAR::Log as an Alert? Thanks, -Philippe Then Robert P Peake wrote:

Hi Philippe, I have not honestly thought much about extending Net_Monitor up the evolutionary scale, beyond protocols to their behaviors and outputs. However, the idea behind Net_Monitor is to create a framework for many different types of monitoring, and many different mechanisms for sending alerts. So, I certainly support and appreciate your efforts toward that end. Common Base Event looks like a specification, not an authored software implementation, so if you were to write a Net_Monitor_Service component to this specification I'm sure there would not be any problem with licensing if you wanted to contribute your code to the project under the same license as the core project itself. It looks like a very interesting idea, and possibly something that would merit a PEAR package in its own right. Much of the inspiration for Net_Monitor came from the existence of many different PEAR packages for handling protocol interactions. Certainly, plugging together class components in this more loosely-coupled fashion promotes better code reuse than simply relying on polymorphism. So, practically speaking, if you wanted to evolve a PEAR package out of a unique service component or vice versa I think this would be a useful contribution. Obviously, if you are developing service components for Net_Monitor that will be released with the core package, we would want review your code before rolling it into an official release, and then once released we would want to list you as a either a developer or at least helper on the project so you could respond to any bug reports about the specific components you authored. Let me know how you would like to proceed, and thanks again for helping extend our thinking about this project. I look forward to your input and participation. Best,

Robert

Then I wrote:

Bonjour Philippe, Net_Monitor interface is wide open, so naturally any sort of driver can be added. I don't really see how this Common Base Event is related to our driver side. Basically, Net_Monitor watchs over states of the monitored services (e.g. HTTP status). It will send alerts if this state changes. You could say we are state based and *produce* the events. If I get it right, the Common Base Event would interesting more on the Alerter side. However, we could imagine to develop some extension of Net_Monitor to process *also* events. Could be extract states from them, but almost filter and hand on the events to the alerters. That could be useful for other protocols as SNMP. For your database connection status, we could make a service more, using DB or MDB2, where each service would be specified through a DSN, and trying to connect, state could be simply boolean or more elaborate, for example using DB or MDB2 error codes. But if you plan to do it over some HTTP request, the thing could be even simpler. The requested application (PHP or other) could simply use the HTTP response code to return the state of the connection. If connection succeeds then return a 200 with a simple "OK for database xxx" content (just for human readers). If connection fails, then return a 404. Then you can directly use the HTTP service to monitor your databases states. PEAR::Log alerter: for sure it would be a nice Alerter to have ! It's an evidence that a monitoring application should furnish some log facility. Why is this discussion not forwarded to pear-dev ? I know some other people are interested in using/extending Net_Monitor. Regards -- toggg

Then Philippe replied

Salut Bertrand, Yes, a HTTP status return code could work, but that's really making it very basic solution. That also makes it difficult to differentiate between connection errors to the server over HTTP/S and errors from the service being checked. i.e. the service could be running fine, but the script calling the stub on that remote server could have some unrelated HTTP connection issues. Of course, both case should be checked on, but not for the same reasons. What I was looking for in the Common Base Event (CBE) is the XML format for reporting information on the status of a service. CBE is more than that, but (if possible license-wise) it would be better to use an existing XML format that fits the bill, even if we would be using just a subset of the tags. As for the DB service, I guess some people could use a direct connection, but that wouldn't work for everyone. There are credential problems (who's connecting from what computer), and it doesn't check if a particular server has problem connecting to the database server. So the script that actually checks for the DB connection should run on the same server that would really connect. Net_Monitor is one side of the solution. Net_Monitor queries a server about its status, server responds, the Net_Monitor takes appropriate actions based on that. And there is the other way around: The server knows something is wrong, the event could be logged with PEAR::Log for notifications as well, or some kind of other object could be linked through PEAR::Event_Dispatcher. That is for web site running PHP scripts. This is all related to the same problem: making sure servers and services are running properly, and take some actions/send notifications if necessary. The reason I'm looking into using Net_Monitor, is that the site I want to check has sporadic DB connection issues. Furthermore, the site was not written very clean (not my fault ;-) and there are hundreds of places in the code where a DB connection could be _created_, making it difficult to actually implement the PEAR::Log (and some scripts are written in Perl) solution. So a script doing the DB connection test seems the sensible approach. Now, somehow that script must be regularly called to check on the status. Since Net_Monitor already has status-change notification built-in it is an obvious choice for me. Anyway, I'm waiting on getting some license information about the XML schema, which I guess would be ok to use since I think they submitted it for standardization by OASIS. If you have other input, let me know. Hopefully I'll be able to move forward with this, and eventually submit that code for inclusing to Net_Monitor. Ciao, -Philippe

and

Bertrand, Robert, Ok, apparently that Common Event Base is now known as Web Event Format (WEF) and is officially part of the Web Service Distributed Management (WSDM) standard approved by OASIS (http://www.oasis-open.org/committees/wsdm/) While WSDM probably will deserve its own package in PEAR, will dig into the specifications and see how WEF can be used to respond to Net_Monitor for status of services. Cheers, Ciao & a+, -Philippe

Finally, after we talked on irc, Marcelo Araujo wrote:

Hi Bertrand, I am really interested about providing a new class to Net_Monitor, services' section. Is there a way to check if a database service is available (using MDB2)? Very similar to Net_FTP and the other related services. The only main difference is that I could use MDB2 in order to check the database services.. Just let me know if it is possible.. Thanks again, Marcelo Araujo Long story again...

Cheers -- toggg