LINUX.ORG.RU

Nagios, check_http - а что оно хочет-то?

 


0

1

Жил-был у меня блок управления вытяжкой на esp8266 с самописной прошивкой. В Nagios'e через check_http дергалась страничка на предмет наличия определенной строки (в стиле «Fan: OK» или «Fan: FAIL»), о чем мне и сигналило в случае чего на почту и в jabber.

В последнее время делаю унификацию всех подобных девайсов, поэтому прошивку сменил на ESP Home. К самой прошивке вопросов нет, но вот с проверкой состояния вышла загвоздка:

rain@walkbook:/tmp/1231231/usr/lib/nagios/plugins$ ./check_http -I 192.168.1.232 -v
GET / HTTP/1.0
User-Agent: check_http/v2.3.1 (monitoring-plugins 2.3.1)
Connection: close


CRITICAL - Socket timeout after 10 seconds


Если дернуть что-то другое - плагин работает:

rain@walkbook:/tmp/1231231/usr/lib/nagios/plugins$ ./check_http -I 192.168.1.200 -s Bitcoin
HTTP OK: HTTP/1.1 200 OK - 4267 bytes in 0,107 second response time |time=0,107245s;;;0,000000;10,000000 size=4267B;;;0
rain@walkbook:/tmp/1231231/usr/lib/nagios/plugins$ ./check_http -I 192.168.1.200 -s Bitc123oin
HTTP CRITICAL: HTTP/1.1 200 OK - string 'Bitc123oin' not found on 'http://192.168.1.200:80/' - 4273 bytes in 0,099 second response time |time=0,099289s;;;0,000000;10,000000 size=4273B;;;0


При этом контент вполне себе забирается curl'ом и wget'ом:

$ curl -v http://192.168.1.232/text_sensor/fan_state 
*   Trying 192.168.1.232:80...
* Connected to 192.168.1.232 (192.168.1.232) port 80 (#0)
> GET /text_sensor/fan_state HTTP/1.1
> Host: 192.168.1.232
> User-Agent: curl/7.74.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 56
< Content-Type: application/json
< Access-Control-Allow-Origin: *
< Connection: close
< Accept-Ranges: none
< 
* Closing connection 0
{"id":"text_sensor-fan_state","value":"OK","state":"OK"}


$ wget -qO- http://192.168.1.232/text_sensor/fan_state | awk -F',|:' '{gsub(/"/, ""); if ($3=="value") print $4}' 
OK



Глянул только что в процессе написания всего этого tcpdump - ответ приходит.

Собственно, а что ему надо-то? Пересмотрел параметры check_http, но вроде ничего, что могло бы дать ответ на вопрос или как-то поменять ситуацию. Простейший ведь запрос.

А, да. Поведение одинаковое как на nagios-plugins 1.4.16-1 из Debian 9, так и на monitoring-plugins 2.3.1 из Debian 11 (с 12-го хочет либу, не пробовал).

★★★★★

Последнее исправление: YAR (всего исправлений: 1)

Указать check_http ... -u /text_sensor/fan_state нельзя? Хочется именно '/' проверять?

ключик "--no-body" не подходит?

Есть подозрение, что http://192.168.1.232/ возвращает строку без перевода строки или длина ответа в в заголовке не соответствует длине данных.

Что показывает «wget -d -O x.dat http://192.168.1.232/" и каких размеров файл x.dat ?

vel ★★★★★
()
Ответ на: комментарий от vel

Есть подозрение, что http://192.168.1.232/ возвращает строку без перевода строки

Ну вот да, вероятнее всего, ибо

rain@walkbook:/tmp/1231231/usr/lib/nagios/plugins$ wget -qO- http://192.168.1.232/text_sensor/fan_state 
{"id":"text_sensor-fan_state","value":"OK","state":"OK"}rain@walkbook:/tmp/1231231/usr/lib/nagios/plugins$


С --no-body команда завершается, но контент, понятное дело, искать не будет.

Указать check_http ... -u /text_sensor/fan_state нельзя? Хочется именно '/' проверять?

Можно, это просто упрощенный вариант в командах - перебирал уже все, что только можно. Да, в финальном варианте там был бы -u /text_sensor/fan_state

YAR ★★★★★
() автор топика
Ответ на: комментарий от vel

Ок; с «почему» вроде как ясно. Вопрос в том, как это обойти :). Т.е., так-то я могу просто свой плагин сделать, который будет не через check_http, а через wget дергать страничку. Интересно просто, можно ли этого избежать.

YAR ★★★★★
() автор топика
Ответ на: комментарий от YAR

вряд ли это из-за переноса строки. Ну и это можно проверить, например, на nginx с модулем echo

location /ping_without_newline {
	default_type text/plain;
	echo -n "pong";
}
location /ping_with_newline {
	default_type text/plain;
	echo "pong";
}

В интернетах пишут, что таймаут возникает, если после ответа не закрывается соединение. По дампу есть tcp.fin?

CaHbl4
()
Ответ на: комментарий от CaHbl4

Похоже, что нет - [F] (это ж оно?) только когда check_http отваливается по таймауту:

rain@walkbook:/tmp/1231231/usr/lib/nagios/plugins$ ./check_http -I 192.168.1.232 -u /text_sensor/fan_state -v
GET /text_sensor/fan_state HTTP/1.0
User-Agent: check_http/v2.3.1 (monitoring-plugins 2.3.1)
Connection: close


CRITICAL - Socket timeout after 10 seconds


root@walkbook:/home/rain# tcpdump -nvv -i eth0 host 192.168.1.232
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:19:58.746303 IP (tos 0x0, ttl 64, id 18646, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.166.37224 > 192.168.1.232.80: Flags [S], cksum 0x850d (incorrect -> 0x6205), seq 3210983445, win 64240, options [mss 1460,sackOK,TS val 3484978496 ecr 0,nop,wscale 7], length 0
13:19:58.748422 IP (tos 0x0, ttl 255, id 27780, offset 0, flags [none], proto TCP (6), length 44)
    192.168.1.232.80 > 192.168.1.166.37224: Flags [S.], cksum 0xbcde (correct), seq 30553220, ack 3210983446, win 5840, options [mss 1460], length 0
13:19:58.748516 IP (tos 0x0, ttl 64, id 18647, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.166.37224 > 192.168.1.232.80: Flags [.], cksum 0x84f9 (incorrect -> 0xf07a), seq 1, ack 1, win 64240, length 0
13:19:58.748732 IP (tos 0x0, ttl 64, id 18648, offset 0, flags [DF], proto TCP (6), length 156)
    192.168.1.166.37224 > 192.168.1.232.80: Flags [P.], cksum 0x856d (incorrect -> 0x48f4), seq 1:117, ack 1, win 64240, length 116: HTTP, length: 116
        GET /text_sensor/fan_state HTTP/1.0
        User-Agent: check_http/v2.3.1 (monitoring-plugins 2.3.1)
        Connection: close

13:19:58.757863 IP (tos 0x0, ttl 255, id 27781, offset 0, flags [none], proto TCP (6), length 218)
    192.168.1.232.80 > 192.168.1.166.37224: Flags [P.], cksum 0xa29b (correct), seq 1:179, ack 117, win 5724, length 178: HTTP, length: 178
        HTTP/1.0 200 OK
        Content-Length: 56
        Content-Type: application/json
        Access-Control-Allow-Origin: *
        Connection: close

        {"id":"text_sensor-fan_state","value":"OK","state":"OK"} [|http]
13:19:58.757940 IP (tos 0x0, ttl 64, id 18649, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.166.37224 > 192.168.1.232.80: Flags [.], cksum 0x84f9 (incorrect -> 0xf006), seq 117, ack 179, win 64062, length 0

*** тут висим ***

13:20:08.747178 IP (tos 0x0, ttl 64, id 18650, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.166.37224 > 192.168.1.232.80: Flags [F.], cksum 0x84f9 (incorrect -> 0xf005), seq 117, ack 179, win 64062, length 0
13:20:08.750219 IP (tos 0x0, ttl 255, id 27786, offset 0, flags [none], proto TCP (6), length 40)
    192.168.1.232.80 > 192.168.1.166.37224: Flags [F.], cksum 0xd3e8 (correct), seq 179, ack 118, win 5723, length 0
13:20:08.750302 IP (tos 0x0, ttl 64, id 18651, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.166.37224 > 192.168.1.232.80: Flags [.], cksum 0x84f9 (incorrect -> 0xf004), seq 118, ack 180, win 64062, length 0
^C

YAR ★★★★★
() автор топика
Последнее исправление: YAR (всего исправлений: 1)
Ответ на: комментарий от YAR

Ну, с другой стороны, вот при wget'е:

root@walkbook:/home/rain# tcpdump -nvv -i eth0 host 192.168.1.232
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:27:57.713473 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.232 tell 192.168.1.166, length 28
13:27:57.721264 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.232 is-at a4:e5:7c:01:7c:9f, length 46
13:27:58.281429 IP (tos 0x0, ttl 64, id 34195, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.166.56340 > 192.168.1.232.80: Flags [S], cksum 0x850d (incorrect -> 0x1cb6), seq 2264111601, win 64240, options [mss 1460,sackOK,TS val 3485458032 ecr 0,nop,wscale 7], length 0
13:27:58.284046 IP (tos 0x0, ttl 255, id 27931, offset 0, flags [none], proto TCP (6), length 44)
    192.168.1.232.80 > 192.168.1.166.56340: Flags [S.], cksum 0xc28f (correct), seq 31275696, ack 2264111602, win 5840, options [mss 1460], length 0
13:27:58.284079 IP (tos 0x0, ttl 64, id 34196, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.166.56340 > 192.168.1.232.80: Flags [.], cksum 0x84f9 (incorrect -> 0xf62b), seq 1, ack 1, win 64240, length 0
13:27:58.284127 IP (tos 0x0, ttl 64, id 34197, offset 0, flags [DF], proto TCP (6), length 187)
    192.168.1.166.56340 > 192.168.1.232.80: Flags [P.], cksum 0x858c (incorrect -> 0x8d77), seq 1:148, ack 1, win 64240, length 147: HTTP, length: 147
        GET /text_sensor/fan_state HTTP/1.1
        User-Agent: Wget/1.21
        Accept: */*
        Accept-Encoding: identity
        Host: 192.168.1.232
        Connection: Keep-Alive

13:27:58.297802 IP (tos 0x0, ttl 255, id 27932, offset 0, flags [none], proto TCP (6), length 239)
    192.168.1.232.80 > 192.168.1.166.56340: Flags [P.], cksum 0x7762 (correct), seq 1:200, ack 148, win 5693, length 199: HTTP, length: 199
        HTTP/1.1 200 OK
        Content-Length: 56
        Content-Type: application/json
        Access-Control-Allow-Origin: *
        Connection: close
        Accept-Ranges: none

        {"id":"text_sensor-fan_state","value":"OK","state":"OK"} [|http]
13:27:58.297833 IP (tos 0x0, ttl 64, id 34198, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.166.56340 > 192.168.1.232.80: Flags [.], cksum 0x84f9 (incorrect -> 0xf598), seq 148, ack 200, win 64041, length 0
13:27:58.297963 IP (tos 0x0, ttl 64, id 34199, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.166.56340 > 192.168.1.232.80: Flags [F.], cksum 0x84f9 (incorrect -> 0xf597), seq 148, ack 200, win 64041, length 0
13:27:58.338868 IP (tos 0x0, ttl 255, id 27933, offset 0, flags [none], proto TCP (6), length 40)
    192.168.1.232.80 > 192.168.1.166.56340: Flags [F.], cksum 0xd984 (correct), seq 200, ack 149, win 5692, length 0
13:27:58.338933 IP (tos 0x0, ttl 64, id 34200, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.166.56340 > 192.168.1.232.80: Flags [.], cksum 0x84f9 (incorrect -> 0xf596), seq 149, ack 201, win 64041, length 0
^C

YAR ★★★★★
() автор топика

Тест со сторонним web-сервером:

С переводом строки:

rain@walkbook:/tmp/1231231/usr/lib/nagios/plugins$ ./check_http -I 192.168.1.200 -u /nl.file -s OK
HTTP OK: HTTP/1.1 200 OK - 278 bytes in 0,001 second response time |time=0,001325s;;;0,000000;10,000000 size=278B;;;0
rain@walkbook:/tmp/1231231/usr/lib/nagios/plugins$ wget -qO- http://192.168.1.200/nl.file
{"id":"text_sensor-fan_state","value":"OK","state":"OK"}


Без:
rain@walkbook:/tmp/1231231/usr/lib/nagios/plugins$ ./check_http -I 192.168.1.200 -u /nnl.file -s OK
HTTP OK: HTTP/1.1 200 OK - 277 bytes in 0,001 second response time |time=0,001353s;;;0,000000;10,000000 size=277B;;;0
rain@walkbook:/tmp/1231231/usr/lib/nagios/plugins$ wget -qO- http://192.168.1.200/nnl.file
{"id":"text_sensor-fan_state","value":"OK","state":"OK"}rain@walkbook:/tmp/1231231/usr/lib/nagios/plugins$

YAR ★★★★★
() автор топика
Последнее исправление: YAR (всего исправлений: 1)
Ответ на: комментарий от CaHbl4

Интересно, спасибо.

Похоже, начиная c nagios-plugins:release-2.3.2 должно работать

Похоже, нет:

rain@meganas:/tmp$ ./check_http -I 192.168.1.232 -u /text_sensor/fan_state -v
GET /text_sensor/fan_state HTTP/1.0
User-Agent: check_http/v2.3.3 (monitoring-plugins 2.3.3)
Connection: close


CRITICAL - Socket timeout after 10 seconds
rain@meganas:/tmp$ wget -qO- http://192.168.1.232/text_sensor/fan_state
{"id":"text_sensor-fan_state","value":"OK","state":"OK"}rain@meganas:/tmp$

YAR ★★★★★
() автор топика
Ответ на: комментарий от aol
rain@meganas:/tmp$ ./check_http -I 192.168.1.232 -u /text_sensor/fan_state -v -H 192.168.1.232
GET /text_sensor/fan_state HTTP/1.1
User-Agent: check_http/v2.3.3 (monitoring-plugins 2.3.3)
Connection: close
Host: 192.168.1.232


CRITICAL - Socket timeout after 10 seconds

YAR ★★★★★
() автор топика