Category Archives: Itшное

Мониторинг графиков cacti и оповещение

Аналогично мониторингу графиков по соотношению текущего значения и вчерашнего, бывает нужно просто проверять не вышли ли значения за пределы заданных границ, с этой целью написал другой плагин, работающий аналогично.

Указывается имя rrd файла и задаются границы, если значения из rrd файла выходят за его пределы то отправляется уведомление.

balance_071813_122633_PM

 

Выше показан пример, когда задана только нижняя критическая граница.

balance_071813_123457_PM

 

А это пример когда заданы две нижние границы. При достижении значения ниже 10к создается ошибка уровня WARNING, когда значение доходит ниже порога в 5к, ошибка получает уровень CRITICAL.

Код команды в конфиге нагиоса:

define command{
    command_name    level_check
    command_line    /usr/bin/env bash /usr/local/etc/nagios/scripts/rrd_level_checker.sh $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$
}

Параметры такие же как и для скрипта по проверке соотношения.

Конфиг для сервиса в конфиге нагиоса:

define service{                
    use main-service   
    host_name levelCheck
    service_description your text
    check_command level_check!file_114.rrd!0.5!2.3
}

В этом случае заданы только по одной верхней и нижней границе (CRITICAL).

Вот пример когда заданы по две границы:

define service{                
    use main-service   
    host_name levelCheck
    service_description your text
    check_command level_check!file_114.rrd!0.5!0.8!2.3!2
}

Для примера который отображен на второй картинке параметры выглядят так:

check_command fall_check!file_114.rrd!5!10!0!0

Проблема с отключением гибернации в новых макбуках.

Обновился на днях на mountain lion и вылезла одна проблема. После отключения режима гибернации или safe sleep, как его называет эпл, после сна около полутора часов, макбук все же скинул всю память на диск и заснул покрепче.

Гонять туда-сюда 16Гб данных при каждом закрытии-открытии ноутбука не было никакого желания, хотелось вернуть как было раньше, только обычный sleep режим, без записи на диск.

В поисках наткнулся на вот это обсуждение. В рунете как то не видел что бы пободная проблема обсуждалась.

Краткая выдержка: не понятно это фишка или баг, заключается в том, что режим сна в любом случае будет с записью на диск. По сути режимы 3 и 0 сделали одинаковыми. При перезагрузке системы, ОС создает файл /private/var/vm/sleepimage равный объему оперативной памяти.

Некоторые решения этой проблемы:

sudo pmset -a hibernatemode 0
sudo rm /private/var/vm/sleepimage
sudo touch /private/var/vm/sleepimage
sudo chflags uchg /private/var/vm/sleepimage

Ставим режим сна в 0 (только сон), удаляем файл дампа памяти, создаем пустой файл и выставляем ему права которые делают его недоступным для записи. Данный способ проблему вроде как решает, но некоторые пишут что после этого появляются разные глюки в программах, так что подойдет не всем.

Еще вариант:

sudo pmset -a hibernatefile /dev/null

Эта команда устанавливает путь к файлу для дампа «в никуда». Не проверял лично как оно работает, но вроде есть такие кому такой метод тоже был нормальным.

И последний вариант, исходя из другого обсуждения. С новым апдейтом ввели новый параметр standbydelay, который задает время в секундах через которое сон переходит в гибернацию. По умолчанию он выставлен в 1.5 часа.

Для установки этого значения в 24 часа выполняем:

sudo pmset -a standbydelay 86400

Что бы проверить текущий параметры выполняем

pmset -g

Лично я остановился на последнем варианте, он самый цивилизованный. Единственный минус — файл sleepimage будет существовать, тем самым отнимая место на жестком диске на объем оперативной памяти. Но пока меня это не напрягает.

Настройка автоматического обновления баз GeoIP

В дополнение к предыдущей статье по теме GeoIP (определяем страну посетителя через nginx) настроим автоматическое обновление базы.

Для этого пишем простой скрипт на баше:

#!/usr/local/bin/bash

echo Start update at `/bin/date`
cd /usr/local/etc/nginx/data/geo/
/usr/local/bin/wget -q http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
echo Saved, unzip..
/usr/bin/gunzip -f GeoIP.dat.gz
echo Unziped, reload nginx
/usr/local/etc/rc.d/nginx reload
echo

Пути к файлам при необходимости нужно подправить естественно.

После этого сохраняем в файл и добавляем в крон, для примера так:

10 3 * * * /usr/local/bin/bash /usr/local/etc/geoip_update/update.sh >> /usr/log/script/geoip_update.log

В данном случае базы будут обновляться ежедневно в 03:10.

Домашний роутер — эволюция

После того как у меня появилась возможность подключить полноценный интернет, после диалапа, я почти сразу же купил роутер что бы можно было в будущем подключать другие устройства. Да и вообще говоря мне нравится когда жилище технически обустроено.

Так, после долгих исследований текущий вариантов на рынке мой выбор пал на ASUS WL-500GP

wl500gp

 

Данный экземпляр имел два USB порта для подключения внешнего винта и принтера, например. Позже кстати говоря выяснилось что у него имеются проблемы с подключением принтера, но не суть. К нему я подключил USB винт, запустил на роутере торрентокачалку и был доволен. Были правда проблемы с просмотром фильмов по сети с этого винта, скорости не хватало. Но я их смотрел не так часто, поэтому чаще всего просто копировал предварительно фильм на ноут и смотрел с него.

С тех пор он без нареканий проработал года 3, после чего случилась непредвиденная ситуация в результате которой роутер среди прочих вещей был похищен :)

Я купил такой же, так как никаких проблем с ним не возникало.

И так было еще несколько лет.

Но вот несколько месяцев назад среди домашней техники появился NAS и захотелось кофортной работы с ним. Скорость через текущий роутер не устраивала (NAS был подключен к роутеру по кабелю). Средняя скорость передачи в любую сторону была порядка 3Мб/с. Это конечно было крайне мало, просмотр fullHD видео уже был невозможен без предварительной загрузки.

Я решил что дело в отсутствии поддержки стандарта n wifi сети. В то время когда делали роутер этого стандарта еще не существовало.

На этот раз я не долго выбирал и решил взять один из дешевых роутеров лишь бы поддерживался n стандарт. Простого роутера должно было быть достаточно потому что отпала необходимость в подключении каких либо внешних устройств в нему. Торренты качались на НАСе, а принтера нету и не планируется.

На этот раз я приобрел ZyXel Keenetic Lite

zyxel_keenetic_lite

 

Уже после покупки я понял, что стандарт n здесь поддерживается не полноценно, и, возможно, если бы я взял не lite версию а полноценную то не пришлось бы его так быстро менять.

В общем говоря скорость передачи на нем осталась практически на том же уровне. На этот раз я сделал несколько замеров что бы при очередной смене сердца сетевой инфраструктуры дома было как оценить результат.

Копирование большого файла с ноута на НАС выполнялась на средней скорости 3.7Мб/с.

Копирование этого же файла с НАСа на ноут 5.5Мб/с.

Ноут показывал скорость подключения 73Мбит/с.

И вот графики копирования с НАСа/на НАС

keenetci_lt-nas1keenetic_nas-lt1

 

Итак, порывшись очередной раз в интернетах я решил уже не размениваться на дешевые девайсы и прикупить то, что должно справляться со всеми нагрузками влегкую с запасом.

Это был Linksys EA4500.

cisco-ea4500

 

Шесть встроенных антенн, работа на двух диапазонах — 2.4 + 5ГГц, полноценная поддержка сети wifi n — все это звучало обещающе.

Выбор был сделан и в скором времени я его купил. Настройка не заняла много времени, с этим в общем то не возникало проблем ни с одним из роутеров.

Каких то впечатлений пока еще не сформировалось, могу лишь сказать что на данный момент он меня радует. Выглядит намного стильнее своих предыдущих товарищей, что немаловажно :-)

Сразу же сделал повторные замеры и вот результаты.

Копирование большого файла с ноута на НАС выполнялась на средней скорости 14.9Мб/с.

Копирование этого же файла с НАСа на ноут 16.7Мб/с.

Ноут показывал скорость подключения 300-324Мбит/с (я подключился по сети 5ГГц).

И вот графики копирования с НАСа/на НАС

linksys_lt-nas2linksys_nas-lt2

Еще к слову сказать начиная с этой линейки роутеров, циска вводит фичу типа магазина приложений, а-ля app store только для роутеров. Посмотрим что там появится, пока не вникал.

 

Оповещение о падении графиков Cacti через плагин для Nagios

Написал простой плагин для nagios который работает по простому принципу: берутся значения с rrd файла за последний час и значения за этот же промежуток день назад.

После чего вычисляються соотношения текущих ко вчерашним точкам и если какое то значение выходит за заданные пределы (минимальный и максивальный уровень) — плагин сигнализирует об ошибке.

(на рисунку прозрачным цветом нарисован график за предыдущий день)

Для nagios нужно прописать в objects/commands.cfg следующие строки

define command{
    command_name    fall_check
    command_line    /usr/bin/env bash /usr/local/etc/nagios/scripts/rrd_fall_checker.sh $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$
}

ARG1 — имя rrd файла (без абсолютного пути, он настраивается в самом файле плагина)

А дальше возможны варианты:

Если указаны только аргументы 2 и 3:

  • ARG2 — минимальный критический порог
  • ARG3 — максивальный критический порог (0 или пусто -верхней границы не задано)

Если указаны все аргументы то задаются отдельно значения для уровня критического уровня и предупреждения (нагиос будет показывать статус CRITICAL, WARNING соответственно):

  • ARG2 — минимальный критический порог
  • ARG3 — минимальный порог предупреждения
  • ARG4 — максивальный критический порог (0 или пусто -верхней границы не задано)
  • ARG5 — максимальный порог предупреждения

Конфиг для сервиса на проверку выглядит примерно так:

define service{                
    use main-service   
    host_name fallCheck
    service_description your text
    check_command fall_check!file_114.rrd!0.5!2.3
}

В данном случае задан порог с 0.5 до 2.3 и при выходе за заданные границы будет критическое уведомление.

Либо так:

define service{                
    use main-service   
    host_name fallCheck
    service_description your text
    check_command fall_check!file_114.rrd!0.5!0.8!2.3!2
}

В этом случае, если ратио опустится ниже 0.8 — будет ошибка уровня WARNING. Если ниже 0.5 то уже CRITICAL. Аналогично и для верхней границы.

Если нужно указать только нижние границы то можно использовать такую запись:

check_command fall_check!file_114.rrd!0.5!0.8!0!0

Сам плагин доступен на гитхабе: https://github.com/unkn0wn404/Nagios.FallChecker

Требует наличия bash и php. Можно было бы обойтись и без пхп конечно, но было лень маяться с логикой проверки ратио в баше.

Update: изначально логика была такова, что при выходе за границы получалась критическая ошибка, а если для последние значения находятся в норме, то показывался ворнинг, пока предыдущие значения за полчаса тоже вернуться в нормальные границы. Как показала практика такой подход неправильный и теперь границы для разных ошибок задаются по разному, а если не заданы то используется только критическое уведомление.