Please find below update FS
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Monitoring+VR+services

Thanks,
Jayapal

On 05-Oct-2013, at 6:54 PM, Santhosh Edukulla <santhosh.eduku...@citrix.com> 
wrote:

> 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: <dev@cloudstack.apache.org>
> Cc: <us...@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: dev@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