debugging - movil - install ddms in android studio

Depuración monit

Question

Me parece que eliminar el monit es un gran dolor. El entorno de shell de Monit básicamente no tiene nada (no hay rutas u otras variables de entorno). Además, no hay ningún archivo de registro que pueda encontrar.

El problema es que si falla el comando de inicio o detención en el script monit, es difícil discernir qué está mal con él. Muchas veces no es tan simple como simplemente ejecutar el comando en el shell porque el entorno del shell es diferente del entorno monit shell.

¿Cuáles son algunas de las técnicas que usa la gente para depurar configuraciones monit?

Por ejemplo, me gustaría tener un monit shell para probar mis scripts o un archivo de registro para ver qué salió mal.

Answer 1

Asegúrate de verificar siempre tu conf y controlar tus procesos a mano antes de dejar que monit maneje todo. systat (1), top (1) y ps (1) son tus amigos para descubrir el uso y los límites de los recursos. Conocer el proceso que monitoreas es esencial también.

En cuanto a los scripts de inicio y finalización, utilizo un script de contenedor para redirigir el resultado e inspeccionar el entorno y otras variables. Algo como esto :

$ cat monit-wrapper.sh

#!/bin/sh
{
  echo "MONIT-WRAPPER date"
  date
  echo "MONIT-WRAPPER env"
  env
  echo "MONIT-WRAPPER $@"
  $@
  R=$?
  echo "MONIT-WRAPPER exit code $R"
} >/tmp/monit.log 2>&1

Luego en Monit:

start program = "/home/billitch/bin/monit-wrapper.sh my-real-start-script and args"
stop program = "/home/billitch/bin/monit-wrapper.sh my-real-stop-script and args"

Aún debe averiguar qué información desea en el contenedor, como información del proceso, id, límites de recursos del sistema, etc.

Answer 2

De forma predeterminada, monit registra en el registro de mensajes de su sistema y puede verificar allí para ver qué está sucediendo.

Además, dependiendo de su configuración, es posible que esté iniciando sesión en un lugar diferente

tail -f /var/log/monit

http://mmonit.com/monit/documentation/monit.html#LOGGING

Asumiendo los valores predeterminados (a partir de la versión anterior de Monit que estoy usando), puede alinear los registros como sigue:

CentOS:

tail -f /var/log/messages

Ubuntu:

tail -f /var/log/syslog

Mac OS X

tail -f /var/log/system.log

Windows

Aquí hay dragones

Pero hay un proyecto neato que encontré mientras buscaba cómo hacerlo por curiosidad morbosa: https://github.com/derFunk/monit-windows-agent

Answer 3

He tenido el mismo problema. Usar la opción de línea de comandos detallada de monit ayuda un poco, pero encontré que la mejor manera era crear un entorno lo más similar posible al entorno de monit y ejecutar el programa de inicio / detención desde allí.

# monit runs as superuser
$ sudo su

# the -i option ignores the inherited environment
# this PATH is what monit supplies by default
$ env -i PATH=/bin:/usr/bin:/sbin:/usr/sbin /bin/sh

# try running start/stop program here
$

He encontrado que los problemas más comunes están relacionados con variables de entorno (especialmente PATH ) o relacionados con permisos. Debes recordar que Monit generalmente se ejecuta como root.

Además, si utiliza as uid myusername en su monit config, debe cambiar al usuario myusername antes de realizar la prueba.

Espero que eso ayude.

Answer 4

Puede iniciar Monit en modo verbose / debug agregando MONIT_OPTS="-v" a /etc/default/monit (no olvide reiniciar; /etc/init.d/monit restart ).

Luego puede capturar la salida usando tail -f /var/log/monit.log

[CEST Jun  4 21:10:42] info     : Starting Monit 5.17.1 daemon with http interface at [*]:2812
[CEST Jun  4 21:10:42] info     : Starting Monit HTTP server at [*]:2812
[CEST Jun  4 21:10:42] info     : Monit HTTP server started
[CEST Jun  4 21:10:42] info     : ''ocean'' Monit 5.17.1 started
[CEST Jun  4 21:10:42] debug    : Sending Monit instance changed notification to [email protected]
[CEST Jun  4 21:10:42] debug    : Trying to send mail via smtp.sendgrid.net:587
[CEST Jun  4 21:10:43] debug    : Processing postponed events queue
[CEST Jun  4 21:10:43] debug    : ''rootfs'' succeeded getting filesystem statistics for ''/''
[CEST Jun  4 21:10:43] debug    : ''rootfs'' filesytem flags has not changed
[CEST Jun  4 21:10:43] debug    : ''rootfs'' inode usage test succeeded [current inode usage=8.5%]
[CEST Jun  4 21:10:43] debug    : ''rootfs'' space usage test succeeded [current space usage=59.6%]
[CEST Jun  4 21:10:43] debug    : ''ws.example.com'' succeeded testing protocol [WEBSOCKET] at [ws.example.com]:80/faye [TCP/IP] [response time 114.070 ms]
[CEST Jun  4 21:10:43] debug    : ''ws.example.com'' connection succeeded to [ws.example.com]:80/faye [TCP/IP]

Answer 5

Sí Monit no es tan fácil de depurar.

Aquí algunas mejores prácticas

• use una secuencia de comandos envoltorio que configura su archivo de registro. Escriba sus argumentos de comando allí mientras lo hace:

cáscara:

#!/usr/bin/env bash

logfile=/var/log/myjob.log
touch ${logfile} 
echo $$ ": ################# Starting " $(date) "########### pid " $$ >> ${logfile}

echo "Command: the-command $@" >> ${logfile} # log your command arguments
{
  exec the-command $@
} >> ${logfile} 2>&1

Eso ayuda mucho.

La otra cosa que encuentro que ayuda es a ejecutar monit con ''-v'', lo que te da verbosidad. Entonces, el flujo de trabajo es

• saca tu envoltorio del caparazón "sudo my-wrapper"
• luego intenta ponerlo en marcha desde monit, ejecuta desde la línea de comando con "-v"
• luego intenta ponerlo en funcionamiento desde monit, ejecutándose en segundo plano.

Answer 6

También puede intentar ejecutar monit validate una vez que los procesos se estén ejecutando, para tratar de averiguar si alguno de ellos está teniendo problemas (y, a veces, obtener más información de la que obtendría en los archivos de registro si hay algún problema). Más allá de eso, no hay mucho más que puedas hacer.

Answer 7

monit -c /path/to/your/config -v