Monitor debugowania


79

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.


Zauważyłem, że monit ma funkcje logowania. mmonit.com/monit/documentation/monit.html Niestety nie jest to tak szczegółowe, jak bym chciał.
Brian Takita

Odpowiedzi:


94

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.


Dzięki, to jest pomocne. Ale jak zmienić na myusername bez pobierania ich środowiska?
Nils

@Chocohound $ sudo myusername; $ env -i PATH = / bin: / usr / bin: / sbin: / usr / sbin / bin / sh
s01ipsist

2
@ s01ipsist to powinno byćsu myusername
Michał Szajbe

1
to jest ogólnie świetna wskazówka
Robert Riedl

36

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.


2
Bardzo dziękuję za tę sugestię dotyczącą debugowania!
Dr Nic,

1
Wspaniałą rzeczą w @billitch monit-wrapper jest to, że wynikowy plik dziennika faktycznie zawiera komunikat o błędzie, który powoduje problem (np. Nie można znaleźć pliku wykonywalnego), który monit połyka. Bardzo dobra sugestia i uratowała mi całą kupę bólu.
ChrisW,

musiałem użyćstart program=/bin/bash -c "..."
Mirko

13

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]


5

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


Nie widzę tego pliku podczas instalacji monitu.
weisjohn

Pracujesz na komputerze z systemem UNIX? / var / log / messages to standardowe miejsce do logowania systemowego na wielu komputerach z systemem UNIX.
WattsInABox

Jestem na Ubuntu 12.04 LTS. Poprawiłem jednak moje pytania monit ... Tak czy inaczej dziwne, że go nie mam ...
weisjohn

4
Nie do końca. Każda dystrybucja systemu UNIX może rejestrować standardowe komunikaty w dowolnym miejscu przez programistów. Najwyraźniej Ubuntu loguje się do /var/log/syslog gdzie jest var / log / messages?
WattsInABox

RHL i centos is tail-f / var / log /
monit

2

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.

0

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ć.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.