Показаны сообщения с ярлыком monitoring. Показать все сообщения
Показаны сообщения с ярлыком monitoring. Показать все сообщения

суббота, 22 апреля 2023 г.

Проверка подключения по IPv6 в Nagios

Несколько лет использовал www.google.com в Nagios чтобы проверять "связность" своих серверов с внешним миром по IPv6. На позапрошлой неделе сервера попали в "бан" и проверка перестала работать.

Поскольку www.google.com все же не предназначен для таких проверок, то переделал проверку на использование msftconnecttest.com. Для IPv6 вместо www.msftconnecttest.com нужно использовать ipv6.msftconnecttest.com.

Этот сервис использует Windows чтобы проверить подключение к Internet. Если при скачивании http://ipv6.msftconnecttest.com/connecttest.txt вы получаете строку "Microsoft Connect Test", то все IPv6 работает без ограничений.

$ /usr/lib/nagios/plugins/check_http -6 -H ipv6.msftconnecttest.com -u /connecttest.txt -s 'Microsoft Connect Test'
HTTP OK: HTTP/1.1 200 OK - 537 bytes in 0.012 second response time |time=0.012383s;;;0.000000;10.000000 size=537B;;;0

вторник, 30 мая 2017 г.

Спустя год заметил что отвалился IPv6 на сервере

В процессе прикручивания сертификата Let's Encrypt к своему сайту обнаружил что он более недоступен по IPv6 извне. Причем судя по статистике траффика в панели управления сервером это произошло еще в июне 2016. Сервер имеет IPv4/IPv6 стек и последний был настроен по принципу "пусть будет". А сейчас при валидации домена Let's Encrypt не может соединиться на IPv6 адрес сайта и проверка не проходит.

Доступность сервера по IPv4 проверяется в nagios из дома, а вот проверку доступности IPv6 пришлось добавить в виде костыля (нет у меня другого сервера с IPv6):

command['check_ipv6']=/usr/lib/nagios/plugins/check_http -6 -H google.com

Похоже что-то изменилось в маршрутизации у хостера, т.к. ipv6 адрес шлюза пингуется, а вот дальше него - тишина.

$ ip -6 a
1: lo: <loopback> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <broadcast> mtu 1500 qlen 1000
    inet6 2a01:4f8:d13:2742::2/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::21c:14ff:fe01:1dba/64 scope link 
       valid_lft forever preferred_lft forever

$ ip -6 r
2a01:4f8:d13:2742::/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via 2a01:4f8:d13:2742::1 dev eth0  metric 1024

$ ip -6 neigh
fe80::3285:a9ff:fea4:1ff7 dev eth0 lladdr 30:85:a9:a4:1f:f7 router STALE
2a01:4f8:d13:2742::1 dev eth0 lladdr 30:85:a9:a4:1f:f7 router STALE

$ ping6 -c 5 2a01:4f8:d13:2742::1
PING 2a01:4f8:d13:2742::1(2a01:4f8:d13:2742::1) 56 data bytes
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=1 ttl=64 time=0.281 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=2 ttl=64 time=0.284 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=3 ttl=64 time=0.250 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=4 ttl=64 time=0.223 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=5 ttl=64 time=0.148 ms

--- 2a01:4f8:d13:2742::1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.148/0.237/0.284/0.050 ms

$ ping6 -c5 ipv6.google.com
PING ipv6.google.com(waw02s06-in-x0e.1e100.net) 56 data bytes

--- ipv6.google.com ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4033ms

Посмотрю что завтра ответит тех. поддержка Hetzner.

UPDATE 31/05/2017

Ответ из техподдержки:
Thanks for trying a reboot first. We've now rechecked the routing of your IPv6-net and we were able to find an issue, which we fixed directly and your server is now back online using the mentioned IPv6.
IPv6 снова работает и мне удалось установить сертификат Let's Encrypt для моего сайта.

среда, 13 января 2016 г.

Munin-node на Arduino

Написал реализацию munin-node для Arduino. Для подключения к сети используется Ethernet shield. Сейчас мониторится относительная влажность и температура, но в планах добавить датчик CO2 и переписать на esp8266. В идеале хочется отказаться от Arduino вообще и использовать только ESP8266 с батарейным питанием.


Вначале было два датчика: DHT11 и DHT22, но их показания по части влажности отличались почти на 10%. Чтобы набрать кворум добавил еще 3 датчика DHT22. Теперь два старых датчика показывают похожие значения, а три новых почти не отличаются в показаниях между собой, но не совпадают с двумя старыми примерно на 10%.

Относительная влажность

Температура
Считается, что комфортный уровень влажности для человека это 40-60%. До включения отопления было 40-50%.

воскресенье, 5 апреля 2015 г.

Перестала работать проверка https в zabbix-proxy для некоторых хостов после апгрейда на Debian Wheezy

После обновления одного из серверов до debian wheezy (раньше там был squeeze-lts) появилась проблема в работе zabbix-proxy, который установлен на этом сервере. После обновления системы и перезагрузки zabbix отрапортовал о проблемах с https на двух хостах, которые мониторились с помощью zabbix-proxy.

Проверил браузером работу https на этих хостах - все в порядке. Zabbix-proxy проверяет больше десятка хостов, на которых есть https, но ложные срабатывания есть только на двух. Причем сами хосты не обновлялись и все было в порядке, пока zabbix-proxy работал на squeeze-lts.

Поискал в гугле и наткнулся на ветку в форуме, где описана аналогичная проблема. Включил DebugLevel=4 в zabbix-proxy и выловил описание проблемы в логе zabbix-proxy:

27111:20150405:124028.523 check_https: curl_easy_perform failed for [example.com:443]: SSL connect error
27109:20150405:124127.938 check_https: curl_easy_perform failed for [example.net:443]: SSL connect error
27111:20150405:124128.978 check_https: curl_easy_perform failed for [example.com:443]: SSL connect error
27108:20150405:124227.737 check_https: curl_easy_perform failed for [example.net:443]: SSL connect error

Пробую натравить wget на один из проблемных хостов:

$ wget --no-check-certificate -O /dev/null  https://example.com/
--2015-04-05 14:59:49--  https://example.com/
Resolving example.com (example.com)... 192.168.1.14
Connecting to example.com (example.com)|192.168.1.14|:443... connected.
GnuTLS: A TLS warning alert has been received.
Unable to establish SSL connection.

Поиск по фразе "GnuTLS: A TLS warning alert has been received." привел меня к двум багрепортам в debian: #738625 и #686837.

Как оказалось на обоих хостах отсутствовала конфигурация ServerName или ServerAlias для example.com и example.net. Поскольку используются *.*.example.com и *.example.net, то проблема оставалась незамеченной, а после обновления сервера - выплыла наружу. После добавления конфигурации для example.com и example.net все пришло в норму.

среда, 14 августа 2013 г.

Расчет критических значений Load Average для системы мониторинга сервера

Сегодня подкручивал настройки Nagios и решил добавить статью по расчету значений лимитов load average для различных конфигураций серверов. Чтобы понимать суть load average я советую прочесть эту статью.

Поскольку лимиты load average зависят от количества доступных ядер процессора, то у различных серверов будут значения будут различаться. Наиболее распространенные варианты конфигурации процессоров:
  • 1 физическое ядро
  • 2 физических ядра
  • 2 физических ядра + hyperthreading (4 виртуальных ядра)
  • 4 физических ядра
  • 4 физических ядра + hyperthreading (8 виртуальных ядер)
Я не буду рассматривать варианты дальше, поскольку там все аналогично. Для себя я определил следующие лимиты, которые по моему мнению не приводят к заметному снижению производительности сервера относительно процессора.

State/Load Average1 min5 min15 min
WarningCPU cores * 2CPU cores * 1.5CPU cores * 1.25
CriticalCPU cores * 4CPU cores * 2CPU cores * 1.5

Поскольку ядро процессора, которое эмулируется hyperthreading, не является полноценным, то такие ядра я исключаю из расчета. Чтобы узнать свое количество физических ядер вы можете выполнить этот скрипт

#!/bin/bash
if [ `grep -c processor /proc/cpuinfo` != 1 ]; then
    grep 'core id' /proc/cpuinfo | sort | uniq | wc -l
else
    echo 1
fi

Готовые значения лимитов для плагина check_load из состава Nagios.

  • Single core: check_load -w 2,1.5,1.25 -c 4,2,1.5
  • Dual core: check_load -w 4,3,2.5 -c 8,4,3
  • Quad core: check_load -w 8,6,5 -c 16,8,6

среда, 11 января 2012 г.

TinyCA: Проверка срока действия сертификатов

Для управления сертификатами использую TinyCA. Недостаток этого решения в том, что об окончании срока действия сертификата узнаешь только тогда, когда он уже окончился.

Чтобы узнавать об этом заранее, я решил набросать небольшой скрипт, который проходится по хранилищу сертификатов и проверяет их "годность" (TinyCA хранит сертификаты в каталоге ~/.TinyCA/CAName/certs).

Выходит, что для проверки достаточно пройтись по всем ~/.TinyCA/CAName/certs/*.pem файлам. Нагуглил скрипт на perl, который проверяет срок действия сертификата. Скрипт завершается с кодом 2, если сертификат просрочен, с кодом 1, если истечет в течении двух недель и с нулевым, если с сертификатом все в порядке.

Далее дописал обвязку для крона, который проверяет сертификаты из ~/.TinyCA/CAName/certs

check-certificate-expire - проверка единичного сертификата
#!/bin/sh

openssl_get_CN_from_file() {
  if [ ! -f "$1" ]; then
    echo "Unable to find file: $1"
    return 1
  fi

  X509_CN=`openssl x509 -in "$1" -noout -subject | perl -pi -e 's/^.*\/?CN=([^\/]*).*$/\1/'`
  echo $X509_CN
}

if [ ! -f "$1" ]; then
  echo "Unable to find file: $1"
  exit 1
fi

check-expire -f /usr/local/etc/check-expire.cfg openssl_x509 -in "$1"

case $? in
  1)
    X509_CN=`openssl_get_CN_from_file "$1"`
    if [ ! -z "$X509_CN" ]; then
      echo "$X509_CN: certificate expires soon"
    else
      echo "$1: certificate expires soon"
    fi
    ;;
  2)
  X509_CN=`openssl_get_CN_from_file "$1"`
  if [ ! -z "$X509_CN" ]; then
    echo "$X509_CN: certificate expired!"
  else
    echo "$1: certificate expired!"
  fi
  ;;
esac

check_tinyca_certs - проверка сертификатов из директории
#!/bin/sh

if [ ! -d "$1" ]; then
  echo "Unable to find directory: $1"
  exit 1
fi

for sslcert in "$1"/*.pem
do
  if [ -f "$sslcert" ]; then
    check-certificate-expire "$sslcert"
  else
    echo "File $sslcert not found"
  fi
done

Конфиг для скрипта check-expire
<class default>
        <expired>
                exit_value 2
        </expired>

        <window>
                inside 2w
                exit_value 1
        </window>
</class>