Как Nagios меняет статус своих services? (вызов через SNMP)

Обсуждение настройки и работы сервисов, резервирования, сетевых настроек и вопросов безопасности ОС.

Модераторы: SLEDopit, Модераторы разделов

Аватара пользователя
Stauffenberg
Сообщения: 2041
Статус: ☮ PEACE ☮
ОС: открытая и свободная

Как Nagios меняет статус своих services?

Сообщение Stauffenberg »

Всем привет.

Хотелось бы получить совет/подсказку по поводу проверки режима подключения ФС: read-write или read-only. Есть старенькая ESX, на которой крутится пару VM. Так вот, не так давно стал замечать, что эти VM все чаще и чаще уходят в read-only режим. Написал маленький скриптик, который пишет тест-файл в каждый RW подмонтированный раздел. Подключил его к Centreon, вызываю через SNMP. Скриптик (а точнее SNMP демон, который этот скриптик вызвал) действительно сказал мне, когда машинка в очередной раз скатилась в RO, но при этом вернул 0 (return code), т.е. я получил сообщение об ошибке (print "CRITICAL: %s I/O error(%s): %s" % (path, errno, strerror)), но при этом статус OK, .т.е. 0 ...хотя из кода видно, что должен был вернуть 2.

Вот у меня вопрос: как именно Nagios/Centreon менят статус своих services? Пишет от сначала return code куда-то на раздел, а потом возврашает это знаение (и если до этого было 0, то после того, как машинка уехала в RO, он не смог перезаписать это значение, то и вернулось старое 0)? Может есть более интеллигентный способ проверки подмонтирования разделов (без запросов к самой ESX)?

Это для python 2.4

Код: Выделить всё

import datetime
import sys, os

def log():
  try:
    f = open("/var/log/firm_name/check_fs.log", 'w')
    f.write(str(datetime.datetime.now()) + "\n")
    f.close()
  except:
    print "WARNING: something goes wrong"
    sys.exit(1)

def writing(path):
  if path == "/":
    path = "/test_file"
  else:
    path = path + "/test_file"

  try:
    f = open(path, 'w')
    f.write('Read/Write Test\n')
    f.close()
    os.remove(path)

#-python 2.7
# except IOError as e:
#   print "I/O error({0}): {1}".format(e.errno, e.strerror), " : ", path


#-python 2.4
  except IOError, (errno, strerror):
    print "CRITICAL: %s I/O error(%s): %s" % (path, errno, strerror)
    sys.exit(2)


f = open("/etc/mtab", 'r').read()
line = f.split('\n')
for l in line:
  l = l.split(" ")
  if l[0][0:5] == "/dev/" and l[3].split(',')[0] == "rw":
    writing(l[1])

log()
print "OK: filesystem is mounted read-write"


Благодарю за ответы.

p.s. да, я знаю, это не лучший мой код (:
Labor omnia vincit

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
Спасибо сказали:
Аватара пользователя
Stauffenberg
Сообщения: 2041
Статус: ☮ PEACE ☮
ОС: открытая и свободная

Re: Как Nagios меняет статус своих services?

Сообщение Stauffenberg »

Не сталкивался никто или вопрос непонятен?
Labor omnia vincit

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
Спасибо сказали:
Аватара пользователя
SLEDopit
Модератор
Сообщения: 4824
Статус: фанат консоли (=
ОС: GNU/Debian, RHEL

Re: Как Nagios меняет статус своих services?

Сообщение SLEDopit »

А не пробовал смотреть в /proc/mounts?
У read only mounts есть пометка ro. Мне кажется, этого должно быть достаточно. Ну при условии, что есть включено errors=remount-ro.
UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity. © Dennis Ritchie
The more you believe you don't do mistakes, the more bugs are in your code.
Спасибо сказали:
Аватара пользователя
Stauffenberg
Сообщения: 2041
Статус: ☮ PEACE ☮
ОС: открытая и свободная

Re: Как Nagios меняет статус своих services?

Сообщение Stauffenberg »

Sorry for English, that's not my machine.

SLEDopit писал(а):
24.07.2015 16:43
А не пробовал смотреть в /proc/mounts?

I use /etc/mtab. I think, it should be the same. I hope :blush:

Код: Выделить всё

> ll /etc/mtab
lrwxrwxrwx 1 root root 17 Jun 14  2014 /etc/mtab -> /proc/self/mounts


SLEDopit писал(а):
24.07.2015 16:43
У read only mounts есть пометка ro. Мне кажется, этого должно быть достаточно. Ну при условии, что есть включено errors=remount-ro.

I'm not sure if this rw/ro will change in case of "broken FS". OS can just believe that FS is still RW. That's the reason why I try to create a new file (In this case I'm 100% sure).
Labor omnia vincit

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
Спасибо сказали:
Аватара пользователя
Stauffenberg
Сообщения: 2041
Статус: ☮ PEACE ☮
ОС: открытая и свободная

Re: Как Nagios меняет статус своих services?

Сообщение Stauffenberg »

Определение rw-разделов это конечно важно, но проблема в том, что когда надо было вернуть 2, скрипт вернул 0. Код в порядке. Где может быть проблема?

Я запускаю скрипт через SNMPd, в конфиге которого:

Код: Выделить всё

exec 1.3.6.1.4.1.2021.8.1.100 /path/to/script.py
Labor omnia vincit

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
Спасибо сказали:
Аватара пользователя
Stauffenberg
Сообщения: 2041
Статус: ☮ PEACE ☮
ОС: открытая и свободная

Re: Как Nagios меняет статус своих services?

Сообщение Stauffenberg »

Это баг в Centreon/Nagios.

Я написал вот такой скриптик

Код: Выделить всё

#!/usr/bin/env python
import sys
print "CRITICAL"
sys.exit(2)


Код: Выделить всё

> ./script.py
CRITICAL
> echo $?
2


И вызвал его через snmpd вот так:

Код: Выделить всё

> snmpwalk -v2c -c community IP_address 1.3.6.1.4.1.2021.8.1
UCD-SNMP-MIB::extIndex.1 = INTEGER: 1
UCD-SNMP-MIB::extNames.1 = STRING: 1.3.6.1.4.1.2021.8.1.100
UCD-SNMP-MIB::extCommand.1 = STRING: /path/to/script.py
UCD-SNMP-MIB::extResult.1 = INTEGER: 2                     <---- return code
UCD-SNMP-MIB::extOutput.1 = STRING: CRITICAL
UCD-SNMP-MIB::extErrFix.1 = INTEGER: noError(0)
UCD-SNMP-MIB::extErrFixCmd.1 = STRING:

как видите, демон, как и должен, возвращает все проавильно - правильная строка и правильный return code.

Но если этот скрипт добавить в Centreon, то он возвращает строку "CRITICAL" (как и должен), но return code 0, хотя должен 2.
Labor omnia vincit

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
Спасибо сказали: