Monitor debugowania

Uważam, że monit debugowania jest głównym problemem. Środowisko powłoki Monita w zasadzie nie zawiera niczego (żadnych ścieżek ani innych zmiennych środowiskowych). Nie ma też żadnego pliku dziennika, który mogę znaleźć.

Problem polega na tym, że jeśli polecenie start lub stop w skrypcie monit zawiedzie, trudno jest stwierdzić, co jest z nim nie tak. Często nie jest to tak proste, jak samo wykonanie polecenia w powłoce, ponieważ środowisko powłoki różni się od środowiska powłoki monit.

Jakich technik używają ludzie do debugowania konfiguracji monitów?

Na przykład, byłbym szczęśliwy, mając powłokę monitującą, przetestować moje skrypty lub plik dziennika, aby zobaczyć, co poszło nie tak.

Miałem ten sam problem. Używanie opcji wiersza poleceń monit w pełnej wersji pomaga trochę, ale okazało się, że najlepszym sposobem jest utworzenie środowiska możliwie najbardziej podobnego do środowiska monit i uruchomienie z niego programu start / stop.

# 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
$

Zauważyłem, że najczęstsze problemy są związane ze zmiennymi środowiskowymi (szczególnie PATH) lub związane z uprawnieniami. Powinieneś pamiętać, że monit zwykle działa jako root.

Również jeśli używasz as uid myusernamew swojej konfiguracji monit, powinieneś zmienić użytkownika myusernameprzed przeprowadzeniem testu.

Mam nadzieję że to pomogło.

Pamiętaj, aby zawsze dokładnie sprawdzać konfigurację i ręcznie monitorować procesy, zanim pozwolisz monitowi zająć się wszystkim. systat (1), top (1) i ps (1) to Twoi znajomi, dzięki którym możesz obliczyć zużycie zasobów i limity. Znajomość monitorowanego procesu jest również niezbędna.

Jeśli chodzi o uruchamianie i zatrzymywanie skryptów, używam skryptu opakowującego do przekierowywania danych wyjściowych i sprawdzania środowiska i innych zmiennych. Coś takiego :

$ 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

Następnie w monitach:

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"

Nadal musisz dowiedzieć się, jakie informacje chcesz umieścić w opakowaniu, takie jak informacje o procesach, identyfikator, limity zasobów systemowych itp.

Możesz uruchomić Monit w trybie szczegółowym / debugowania, dodając MONIT_OPTS="-v"do /etc/default/monit(nie zapomnij o ponownym uruchomieniu; /etc/init.d/monit restart).

Następnie możesz przechwycić dane wyjściowe za pomocą 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 monit@example.io
[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]

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

Domyślnie monit rejestruje się w dzienniku komunikatów systemowych i możesz tam sprawdzić, co się dzieje.

Ponadto, w zależności od konfiguracji, możesz logować się w innym miejscu

tail -f /var/log/monit

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

Zakładając wartości domyślne (jak w każdej starej wersji monit, której używam), możesz dostosować dzienniki w następujący sposób:

CentOS:

tail -f /var/log/messages

Ubuntu:

tail -f /var/log/syslog

Mac OS X

tail -f /var/log/system.log

Windows

Oto smoki

Ale jest pewien projekt, który znalazłem, szukając, jak to zrobić z chorobliwej ciekawości: https://github.com/derFunk/monit-windows-agent

Tak, monit nie jest zbyt łatwy do debugowania.

Oto kilka sprawdzonych metod

• użyj skryptu opakowującego, który konfiguruje plik dziennika. Napisz tam argumenty poleceń, kiedy już to robisz:

muszla:

#!/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

To bardzo pomaga.

Inną rzeczą, która okazała się pomocna, jest uruchomienie monit z opcją „-v”, co daje szczegółowość. Więc przepływ pracy jest

• spraw, aby twój wrapper działał z powłoki "sudo my-wrapper"
• następnie spróbuj uruchomić program z monit, uruchom z wiersza poleceń z „-v”
• następnie spróbuj uruchomić go z monit, działającego w tle.

Możesz także spróbować uruchomić monit sprawdzający poprawność, gdy procesy są uruchomione, aby sprawdzić, czy któryś z nich ma problemy (a czasem uzyskać więcej informacji niż w plikach dziennika, jeśli wystąpią jakiekolwiek problemy). Poza tym niewiele więcej możesz zrobić.