A shell script can be used. Few thoughts below:

1. Collect the process id of all daemons you wanted to monitor using "pidof" of 
command and then use "kill" command to check if the pid you got is valid. Using 
kill we can send a signal 0, then check the status using echo $? . For sending 
a notification use linux syslog call ( man 3 syslogd) or "logger" command to 
send to syslog. If wanted to send email then you may also have to look for 
firewall not allowing outbound smtp port communiation. Even for snmp this holds 
same( i mean if any blocking through firewall rules ).  Using syslog may be 
good as it by default exposes various debug log levels through its api call.

Now, to keep the monitor script up always up and runninig. Keep the monitor 
script run continuosly through cron or at at regular\scheduled intervals. This 
way even if monitor script goes down, the next xth interval, it is up again. 

With this there is a catch though, we may got multiple pids for a given daemon 
provided if there are multiple daemons spawned by same\multiple applications, 
if this scenario is not common then its ok, otherwise we may have to track it 
differently maintaining state of each spawned daemon and see if it exists. If 
multiple applications launch the same daemon, you may also wanted to say its 
application which got killed. EX: A launched httpd, and during its exit logic, 
it is killing all daemons it launched, then you may wanted to add  A is not 
available, rather than just http is not available. 


2.  Using  netstat command : Check for available, listening and active ports on 
local host, provided all the daemons you wanted to monitor are running on 
"standard" ports or if we know the listening ports of those deamons to be 
monitored. Again, this script can be added through cron\at to be scheduled to 
run x units, if it gets killed the next x units after the monitor script is up 
again. 

Also, there could be many other approaches as well.


Thanks!
Santhosh 
________________________________________
From: Jayapal Reddy Uradi [jayapalreddy.ur...@citrix.com]
Sent: Saturday, October 05, 2013 5:17 AM
To: <d...@cloudstack.apache.org>
Cc: <users@cloudstack.apache.org>
Subject: Re: [PROPOSAL] Service monitoring tool in virtual router

Hi,

+users list
If any one is already using any tools for monitoring then please share your 
ideas.
Also share the cases where you experienced service crashes.

Thanks,
Jayapal

On 05-Oct-2013, at 4:12 AM, Chiradeep Vittal <chiradeep.vit...@citrix.com> 
wrote:

> Well just make sure that your script is resilient to its own crashes as
> well.
>
> On 10/4/13 1:59 AM, "Jayapal Reddy Uradi" <jayapalreddy.ur...@citrix.com>
> wrote:
>
>> Hi,
>>
>> I am planning to write script utility to monitor processes and restart on
>> the event of failure. It will also logs the events.
>>
>> Thanks,
>> Jayapal
>>
>> On 02-Oct-2013, at 3:25 AM, Simon Weller <swel...@ena.com> wrote:
>>
>>> supervisord maybe?
>>>
>>> ----- Original Message -----
>>>
>>> From: "Chiradeep Vittal" <chiradeep.vit...@citrix.com>
>>> To: d...@cloudstack.apache.org
>>> Sent: Tuesday, October 1, 2013 4:45:56 PM
>>> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
>>>
>>> Got it. Any other OSS tool out there similar to monit?
>>>
>>> On 10/1/13 8:24 AM, "David Nalley" <da...@gnsa.us> wrote:
>>>
>>>> On Thu, Sep 26, 2013 at 1:27 AM, Chiradeep Vittal
>>>> <chiradeep.vit...@citrix.com> wrote:
>>>>> SNMP wouldn't restart a failed process nor would it generate alerts.
>>>>> It
>>>>> is
>>>>> simply too generic for the requirements outlined here. The proposal
>>>>> does
>>>>> not talk about modifying monit, just using it. That wouldn't trigger
>>>>> the
>>>>> AGPL.
>>>>
>>>> Let me restate my objection to anything AGPL.
>>>> People are largely comfortable with GPLv2 software - Linux is
>>>> ubiquitous. Many legal departments routinely prohibit GPLv3 software
>>>> (we actually saw this when CS was GPLv3 licensed.) But the Affero GPL
>>>> license is anathema in many corporate environments, and by forcing it
>>>> on folks in the default System VM I fear it will hurt adoption of
>>>> CloudStack.
>>>>
>>>> --David
>>>
>>>
>>
>

Reply via email to