[Glass] Monit scripts for gemstone?

[Mariano Martinez Peck via Glass]

On Thu, Dec 19, 2013 at 11:09 AM, Johan Brichau <johan at yesplan.be> wrote:

> Hi Mariano,
>
> This is what I setup for each stone.
> Change the file paths, the user/group names, fill in the TEMPLATE and
> PORTxx stuff, adapt the timeouts to your need and you should be good to go.
>
> Johan
>
> #################################
> ## TEMPLATE
> #################################
> check process fastcgi_PORT1_TEMPLATE with pidfile
> /opt/gemstone/stones/TEMPLATE/data/FastCGI_server-PORT1.pid
>         start program = "/home/yesplan/yesplanscripts/startYesplanGems
> TEMPLATE PORT1" as uid yesplan and gid yesplan
>         stop program = "/home/yesplan/yesplanscripts/stopYesplanGems
> TEMPLATE PORT1" as uid yesplan and gid yesplan
>                 DEPENDS on stone_TEMPLATE
>                 GROUP TEMPLATE
>                 # Empty FastCGI request
>                 if failed port PORT1
>                   # Send FastCGI packet: version 1 (0x01), cmd
> FCGI_GET_VALUES (0x09)
>                   # padding 8 bytes (0x08), followed by 8xNULLs padding
>                   send
> "\0x01\0x09\0x00\0x00\0x00\0x00\0x08\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00"
>                   # Expect FastCGI packet: version 1 (0x01), resp
> FCGI_GET_VALUES_RESULT (0x0A)
>                   expect "\0x01\0x0A"
>                   timeout 40 seconds
>                 then restart
>


Hi Johan,

Sorry for reviving this very old thread. But I have a doubt. Why do you do
that special send / expect of the FastCGI protocol rather than a simple:

if failed port PORT1 then restart

Is this in case that the gem could be somehow "hanged" yet still having the
port still open? Any other reason?

I ask because I am experimenting something which I am not sure this is the
expected behavior. Basically, what happens to me is that if the gem is up
and alive, monit (when it checks the status of the process) will be waiting
for those 40 seconds before continue checking the next process. Is this
expect? It is happening the same to you?

which timeout you have in your webserver for the upstreams? 40 seconds too?

Thanks in advance,



Thanks in advance,




> check process fastcgi_PORT2_TEMPLATE with pidfile
> /opt/gemstone/stones/TEMPLATE/data/FastCGI_server-PORT2.pid
>         start program = "/home/yesplan/yesplanscripts/startYesplanGems
> TEMPLATE PORT2" as uid yesplan and gid yesplan
>         stop program = "/home/yesplan/yesplanscripts/stopYesplanGems
> TEMPLATE PORT2" as uid yesplan and gid yesplan
>         DEPENDS on stone_TEMPLATE
>         GROUP TEMPLATE
>                 # Empty FastCGI request
>                 if failed port PORT2
>                   # Send FastCGI packet: version 1 (0x01), cmd
> FCGI_GET_VALUES (0x09)
>                   # padding 8 bytes (0x08), followed by 8xNULLs padding
>                   send
> "\0x01\0x09\0x00\0x00\0x00\0x00\0x08\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00"
>                   # Expect FastCGI packet: version 1 (0x01), resp
> FCGI_GET_VALUES_RESULT (0x0A)
>                   expect "\0x01\0x0A"
>                   timeout 40 seconds
>                 then restart
> check process fastcgi_PORT3_TEMPLATE with pidfile
> /opt/gemstone/stones/TEMPLATE/data/FastCGI_server-PORT3.pid
>         start program = "/home/yesplan/yesplanscripts/startYesplanGems
> TEMPLATE PORT3" as uid yesplan and gid yesplan
>         stop program = "/home/yesplan/yesplanscripts/stopYesplanGems
> TEMPLATE PORT3" as uid yesplan and gid yesplan
>         DEPENDS on stone_TEMPLATE
>         GROUP TEMPLATE
>                 # Empty FastCGI request
>                 if failed port PORT3
>                   # Send FastCGI packet: version 1 (0x01), cmd
> FCGI_GET_VALUES (0x09)
>                   # padding 8 bytes (0x08), followed by 8xNULLs padding
>                   send
> "\0x01\0x09\0x00\0x00\0x00\0x00\0x08\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00"
>                   # Expect FastCGI packet: version 1 (0x01), resp
> FCGI_GET_VALUES_RESULT (0x0A)
>                   expect "\0x01\0x0A"
>                   timeout 40 seconds
>                 then restart
> check process servicevm_TEMPLATE with pidfile
> /opt/gemstone/stones/TEMPLATE/data/service.pid
>         start program =
> "/home/yesplan/yesplanscripts/startYesplanServiceVM TEMPLATE" as uid
> yesplan and gid yesplan
>         stop program = "/home/yesplan/yesplanscripts/stopYesplanServiceVM
> TEMPLATE" as uid yesplan and gid yesplan
>         DEPENDS on stone_TEMPLATE
>         GROUP TEMPLATE
> check file extent_TEMPLATE with path
> /opt/gemstone/stones/TEMPLATE/data/extent0.dbf
>                     if size > 4 GB then alert
>                     GROUP TEMPLATE
> check process stone_TEMPLATE with pidfile
> /opt/gemstone/stones/TEMPLATE/data/TEMPLATE.pid
>                 start program =
> "/home/yesplan/yesplanscripts/startYesplanStone TEMPLATE" as uid yesplan
> and gid yesplan
>                 stop program =
> "/home/yesplan/yesplanscripts/stopYesplanStone TEMPLATE" as uid yesplan and
> gid yesplan
>                 GROUP TEMPLATE
>
>
> On 19 Dec 2013, at 15:03, Mariano Martinez Peck <marianopeck at gmail.com>
> wrote:
>
> > Ok, I could start writing monit scripts for gemstone, but I guess many
> people already did that, right?
> >
> > The thing is that there are many processes to monit: the stone, netldi,
> each gem, etc.. From what I could see most of them, if not all, have a
> place for the pid, so it could be easy to write the monit scripts. For the
> seaside gems we could check the port.
> >
> > Thoughts?
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
> > _______________________________________________
> > Glass mailing list
> > Glass at lists.gemtalksystems.com
> > http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150218/4ebea182/attachment.html>