четверг, 31 декабря 2015 г.

Установка системы управления docker-контейнерами kubernetes


С развитием инфраструктуры docker-контейнеров появляется необходимость управления большим числом docker-контейнеров. Для этой цели служат системы: 
  • Kubernetes развиваемый компанией Google
  • Mesos развиваемый в сообществе Apache 
  • Docker Swarm от создателей Docker.
Компания Google утверждает, что уже более 9-ти лет использует в своей работе контейнеры. Поэтому разрабатываемая ими система Kubernetes является на сегодня стабильной и продвинутой.
С помощью этой статьи вы сможете легко развернуть кластер kubernetes из мастера и двух нод. И легко добавлять node-машины в дальнейшем. Мастер нода имеет API для управления кластером и дирежирует контейнерами. Ноды получают команды от мастера и запускают контейнеры.
Для начала нужно иметь 2 сервера и установить на них Docker.
Мы будем использовать 2 Docker-демона на каждом сервере:
  1. Docker начальной загрузки для запуска flanneld и etcd;
  2. Основной Docker для запуска инфраструктуры Kubernetes и запуска наших контейнеров.
Потребность в двух docker-демонах необходима по той причине, что для объединения всех контейнеров в единую сеть, будет использоваться демон flannel. Он должен запускаться не в основном Docker.

Настройка мастера
Мастер настраивается в 2 этапа:
  1. установка flanneld и etcd
  2. запуск компонент мастера
Для простоты, инициализируем переменную с IP адресом мастера:
export MASTER_IP=<IP адрес мастера, например 1.2.3.4>

Запускаем вспомогательный docker
sudo sh -c 'docker -d -H unix:///var/run/docker-bootstrap.sock \
  -p /var/run/docker-bootstrap.pid \
  --iptables=false \
  --ip-masq=false \
  --bridge=none \
  --graph=/var/lib/docker-bootstrap \
  2> /var/log/docker-bootstrap.log 1> /dev/null &'
Этот docker запускается с опцией --iptables=false, чтобы запускаемые им контейнеры работали только с опцией --net=host.

Запускаем etcd для flannel и API
sudo docker -H unix:///var/run/docker-bootstrap.sock run  \
  --restart=always \
  --net=host 
  -d gcr.io/google_containers/etcd:2.0.12 \
  /usr/local/bin/etcd --addr=127.0.0.1:4001 \
  --bind-addr=0.0.0.0:4001 \
  --data-dir=/var/etcd/data
Прописываем в etcd сеть для flannel 
Сеть не должна пересекаться с уже имеющимися сетями:
sudo docker -H unix:///var/run/docker-bootstrap.sock run \
  --net=host \
  gcr.io/google_containers/etcd:2.0.12 \
  etcdctl set /coreos.com/network/config '{ "Network": "10.1.0.0/16" }'
Устанавливаем flannel на мастер-ноде
Flannel перенастраивает bridge, который настроил Docker. Поэтому надо остановить основной Docker, запустить Flannel и снова запустить Docker.
Останавливаем Docker
sudo service docker stop

Запускаем flannel
sudo docker -H unix:///var/run/docker-bootstrap.sock run \
  -d \
  --restart=always \
  --net=host \
  --privileged \
  -v /dev/net:/dev/net \
  quay.io/coreos/flannel:0.5.0
Эта команда выведет длинный хеш, который будет использоваться в следующей команде. Скопируйте его.

Получаем настройки flannel-сети
sudo docker -H unix:///var/run/docker-bootstrap.sock \
  exec <длинный-хеш> cat /run/flannel/subnet.env
Пример вывода этой команды:
FLANNEL_SUBNET=10.1.10.1/24
FLANNEL_MTU=1472
FLANNEL_IPMASQ=false

Добавляем вспомогательный Docker в автозагрузку
Создаём файл /lib/systemd/system/docker-bootstrap.socket с таким содержимым:
[Unit]
Description=Docker Socket for the API
PartOf=docker-bootstrap.service

[Socket]
ListenStream=/var/run/docker-bootstrap.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker

[Install]
WantedBy=sockets.target
И файл /lib/systemd/system/docker-bootstrap.service с таким содержимым:
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target docker-bootstrap.socket
Requires=docker-bootstrap.socket

[Service]
ExecStart=/usr/bin/docker -d -H unix:///var/run/docker-bootstrap.sock -p /var/run/docker-bootstrap.pid --iptables=false --ip-masq=false --bridge=none --graph=/var/lib/docker-bootstrap
MountFlags=slave
LimitNOFILE=1048576
LimitNPROC=1048576
LimitCORE=infinity

[Install]
WantedBy=multi-user.target
В файл /lib/systemd/system/docker.service после After=network.target docker.socket
добавляем docker-bootstrap.service
После этого перечитываем конфиги systemctl
systemctl daemon-reload
systemctl enable docker-bootstrap

Настраиваем основной Docker
В конфиругационном файле или в скрипте запуска (для Ubuntu это /etc/default/docker или /etc/systemd/service/docker.service) нужно добавить:
--bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU}
Вместо FLANNEL_SUBNET и FLANNEL_MTU нужно прописать параметры из вывода предыдущей команды.
Команда запуска основного докера должа получится примерно такой:
/usr/bin/docker -d -H fd:// --bip="10.1.10.1/24" --mtu=1472

Удаляем существующий Docker bridge
По-умолчанию Docker создаёт bridge и именем docker0. Удалим его
sudo /sbin/ifconfig docker0 down
sudo brctl delbr docker0
Запускаем запускаем основной Docker
sudo service docker start

Запускаем kubernetes мастер
sudo docker run \
  --volume=/:/rootfs:ro \
  --volume=/sys:/sys:ro \
  --volume=/dev:/dev \
  --volume=/var/lib/docker/:/var/lib/docker:rw \
  --volume=/var/lib/kubelet/:/var/lib/kubelet:rw \
  --volume=/var/run:/var/run:rw \
  --net=host \
  --privileged=true \
  --pid=host \
  --restart=always \
  -d \
  gcr.io/google_containers/hyperkube:v1.1.3 /hyperkube kubelet --api-servers=http://localhost:8080 --v=2 --address=0.0.0.0 --enable-server --hostname-override=127.0.0.1 --config=/etc/kubernetes/manifests-multi --cluster-dns=10.0.0.10 --cluster-domain=cluster.local
Примечание: --cluster-dns и --cluster-domain нужны для запуска внутреннего DNS сервера. Можно исключить их из команды запуска мастера.

Примечание 2: если при запуске этого контейнера появляется ошибка "System error: The minimum allowed cpu-shares is 1024", то лечится она добавлением параметра --exec-opt native.cgroupdriver=cgroupfs в команду запуска основого Docker.


Запускаем service proxy для kubernetes
Service proxy обеспечивает балансировку нагрузку между группами контейнеров объединёных в Kubernetes services
sudo docker run -d --restart=always \
  --net=host \
  --privileged \
  gcr.io/google_containers/hyperkube:v1.1.3 /hyperkube proxy --master=http://127.0.0.1:8080 --v=2

Теперь у нас есть настроенный кластер из одной  ноды и мастера. Можем протестировать это.
Скачаем утилиту kubectl
wget -O /usr/bin/kubectl http://storage.googleapis.com/kubernetes-release/release/v1.1.3/bin/linux/amd64/kubectl
chmod +x /usr/bin/kubectl 
Запустим команду
kubectl get nodes
Пример вывода этой команды:
NAME        LABELS                             STATUS
127.0.0.1   kubernetes.io/hostname=127.0.0.1   Ready

Добавление ноды в кластер
Добавление ноды во многом повторяет настройку мастера. Процесс состоит из 3 шагов
  1. запуск flanneld
  2. запуск kubernetes
  3. добавление ноды в кластер
Инициализируем 2 переменные:
export MASTER_IP=<IP адрес мастера, например 1.2.3.4>
export NODE_IP=<IP адрес ноды, например 4.3.2.1>

Запуск flanneld
Запускаем Docker  для начальной загрузки
sudo sh -c 'docker -d -H unix:///var/run/docker-bootstrap.sock \
  -p /var/run/docker-bootstrap.pid \
  --iptables=false \
  --ip-masq=false \
  --bridge=none \
  --graph=/var/lib/docker-bootstrap \
  2> /var/log/docker-bootstrap.log 1> /dev/null &'

Останавливаем основной Docker
sudo service docker stop
Запускаем flannel
sudo docker -H unix:///var/run/docker-bootstrap.sock run \
  -d \
  --net=host \
  --privileged \
  -v /dev/net:/dev/net \
  quay.io/coreos/flannel:0.5.0 /opt/bin/flanneld --etcd-endpoints=http://${MASTER_IP}:4001
Эта команда выведет длинный хеш, который будет использоваться в следующей команде. Скопируйте его.

Получаем настройки flannel-сети
sudo docker -H unix:///var/run/docker-bootstrap.sock \
  exec <длинный-хеш> cat /run/flannel/subnet.env
Пример вывода этой команды:
FLANNEL_SUBNET=10.1.90.1/24
FLANNEL_MTU=1472
FLANNEL_IPMASQ=false

Настраиваем основной Docker
В конфиругационном файле или в скрипте запуска (для Ubuntu это /etc/default/docker или /etc/systemd/service/docker.service) нужно добавить:
--bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU}
Вместо FLANNEL_SUBNET и FLANNEL_MTU нужно прописать параметры из вывода предыдущей команды.
Команда запуска основного докера должа получится примерно такой:
/usr/bin/docker -d -H fd:// --bip="10.1.90.1/24" --mtu=1472

Удаляем существующий Docker bridge
sudo /sbin/ifconfig docker0 down
sudo brctl delbr docker0
Запускаем запускаем основной Docker
sudo service docker start
Запуск kubernetes для ноды
Запускаем kubelet
sudo docker run \
    --volume=/:/rootfs:ro \
    --volume=/sys:/sys:ro \
    --volume=/dev:/dev \
    --volume=/var/lib/docker/:/var/lib/docker:rw \
    --volume=/var/lib/kubelet/:/var/lib/kubelet:rw \
    --volume=/var/run:/var/run:rw \
    --net=host \
    --privileged=true \
    --pid=host \
    -d \
    gcr.io/google_containers/hyperkube:v1.1.3 /hyperkube kubelet --api-servers=http://localhost:8080 --v=2 --address=0.0.0.0 --enable-server --hostname-override=127.0.0.1 --config=/etc/kubernetes/manifests-multi --cluster-dns=10.0.0.10 --cluster-domain=cluster.local
Примечание: --cluster-dns и --cluster-domain можно исключить из этой команды

Запуск service proxy

sudo docker run -d \
  --net=host \
  --privileged \
  gcr.io/google_containers/hyperkube:v1.1.3 /hyperkube proxy --master=http://${MASTER_IP}:8080 --v=2

Теперь, выполнив на мастере команду kubectl get nodes, мы увидим, что новая нода включена в кластер.
NAME              LABELS                                   STATUS
127.0.0.1         kubernetes.io/hostname=127.0.0.1         Ready
NODE_IP           kubernetes.io/hostname=NODE_IP           Ready

Сделано на основе документации:
https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/getting-started-guides/docker-multinode/master.md
https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/getting-started-guides/docker-multinode/worker.md

пятница, 2 августа 2013 г.

Мониторинг веб-сервера Nginx c помощью zabbix trapper



   Рассмотрим случай, когда требуется настроить мониторинг сервера по множеству однотипных или динамических метрик, которые отсутствуют в zabbix-агенте.
   В такой ситуации в zabbix-агенте можно создавать ключи для проверки с помощью параметра конфигурации - UserParameter. Для каждого параметра в zabbix_agentd.conf создаётся строка вида:

UserParameter=<key>,<shell command>


   Однако, если значений слишком много, такой способ может оказаться не удобным.
Второй способ заключается в использовании элемента данных zabbix типа trapper (zabbix-ловушки). Принцип очень простой: в zabbix-сервере создаются элементы данных этого типа с произвольным именем ключа. Затем, с помощью утилиты zabbix_sender формируется специальный запрос, в котором указывается ключ ловушки, значение параметра и имя хоста. Если параметров много, то можно сформировать файл в формате zabbix_sender и отправить все значения из файла за одно соединение с сервером.
Строки в файле должны быть оформлены в таком виде:
- <ключ> <значение> (дефис в начале строки обязателен)
или
<имя_хоста> <ключ> <значение>


   Рассмотрим, как использовать эту возможность на примере мониторинга популярного веб-сервера Nginx.  Для этого веб-сервера есть возможнось использовать модуль stub_status, который показывает в цифрах текущую нагрузку на Nginx примерно в таком виде:
Active connections: 26
server accepts    handled     requests
1344375             1344375    3208201
Reading: 0 Writing: 2 Waiting: 24


   Из этих данных мы можем получить, например, такие метрики для мониторинга:
  • nginx_status.active   -  количество всех открытых соединений
  • nginx_status.reading -  количество запросов, у которых nginx читает заголовки запроса
  • nginx_status.writing - количество запросов, у которых в данный момент сервер читает тело запроса, обрабатывает запрос или пишет ответ клиенту
  • nginx_status.waiting  -  количество неактивных(keep-alive) соединений
  • nginx_status.accepts - количество принятых запросов в секунду
  • nginx_status.handled - количество обрабатываемых запросов в секунду
  • nginx_status.requests  - количество запросов в секунду
   Благодаря этим параметрам можно оценить нагрузку на сервер (в течении дня, недели и т.д.) , а также оценить узкие места в его работе (медленный ли канал у сервера, медленные ли каналы у клиентов, медленно ли обрабабатываются запросы и т.д.).


   Скрипт, формирующий файл для zabbix_sender-а и запускающий zabbix_sender, может запускаться zabbix-агентом.
   Для этого в конфигурационном файле агента zabbix_agentd.conf создадим ключ nginx_status:
UserParameter=nginx_status,/home/zabbix/nginx.sh 127.0.0.1


   Содержимое /home/zabbix/nginx.sh примерно такое:
#!/bin/sh

# this script tries to collect nginx data

########################################
# Active connections: 768              #
# server accepts handled requests      #
#  133844 133844 601894                #
# Reading: 63 Writing: 21 Waiting: 684 #
########################################

WGET="/usr/local/bin/wget"
ZBX_STATS_FILE="/var/log/zabbix/ZabbixStats.txt"
ZBX_SENDER="/home/zabbix/bin/zabbix_sender"
ZBX_CONFIG="/home/zabbix/conf/zabbix_agentd.conf"
ZBX_HOSTNAME=`grep "^Hostname" ${ZBX_CONFIG} | cut -f2 -d"="`

NGX_STATS_FILE="/var/log/zabbix/NginxStats.txt"
if [ -z $1 ]; then
   NGX_HOSTNAME="localhost"
else
   NGX_HOSTNAME="${1}"
fi

$WGET -q -O ${NGX_STATS_FILE} -t3 -T5 http://${NGX_HOSTNAME}/nginx-status

if [ $? == 0 ]; then
       cat ${NGX_STATS_FILE} | awk -v myhost=$ZBX_HOSTNAME '/Active connections/ {active = int($NF)}
                      /\W*([0-9]+)\W*([0-9]+)\W*([0-9]+)/ {accepts = int($1); handled = int($2); requests = int($3)}
                      /Reading:/ {reading = int($2); writing = int($4); waiting = int($NF)}
                      END {
                      print myhost, "nginx_status.active", active;
                      print myhost, "nginx_status.reading", reading;
                      print myhost, "nginx_status.writing", writing;
                      print myhost, "nginx_status.waiting", waiting;

                      print myhost, "nginx_status.accepts", accepts;
                      print myhost, "nginx_status.handled", handled;
                      print myhost, "nginx_status.requests", requests;
                      }' > ${ZBX_STATS_FILE}

       ${ZBX_SENDER} -i ${ZBX_STATS_FILE} -c ${ZBX_CONFIG} >/dev/null
       echo 1;
       exit 0
else
       echo "0"
       exit 1
fi
При запросе сервером zabbix ключа nginx_status, скрипт вышлет данные серверу.


   Создаем в zabbix-сервере шаблон - Template App Nginx.
   Создаём в шаблоне элемент данных типа zabbix agent, запускающий скрипт /home/zabbix/nginx.sh (Рис. 1).
Рисунок. 1 Элемент данных, запускающий скрипт /home/zabbix/nginx.sh


   Скрипт в случае успешного получения страницы nginx-status возвращает 1 и 0 - в противном случае. Полезно создать триггер отслеживающий эту ситуацию (Рис. 2).
Рисунок 2. Тригер, отслеживаюший возможность получения статуса с Nginx.


   Далее для каждого параметра создаем элемент данных типа zabbix trapper. На Рис.2  пример для метритки nginx active connections.
Рисунок 3. Создание элемента данных для метрики nginx active connections.


   По аналогии делаем элементы для остальных метрик. Изменяется только название элемента данных (Name) и ключ (Key).


   После объединения графиков в группы получаются графики как на Рис. 4 и Рис. 5.
Рисунок 4. Статус соединений.


Рисунок 5. Нагрузка на сервер.


   Шаблон для мониторинга nginx можно скачать отсюда: http://forum.itrm.ru/t/94/

понедельник, 3 июня 2013 г.

Мониторинг и управление ИТ


Общий взгляд на ИТ-мониторинг

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

Если у нас есть статистическая информация по ИТ-системе, что за квартал объем данных возрастает на 10 Тб, и данные надо собирать и хранить год, а в течение этого времени у нас не будет возможности контролировать дисковое пространство, мы можем заранее купить и установить диски на 40 Тб, чтобы система работала стабильно в требуемом временном интервале. Это пример управления ИТ при помощи разомкнутого контура на основе заранее собранной и проанализированной информации.

Другой пример, если у нас есть возможность контролировать определенные параметры ИТ-системы в реальном режиме времени и сразу реагировать на них. Например, свободное место на том же диске. Как только будет превышен определенный порог, это станет нам сразу же известно, и мы сможем удалить ненужные данные или перенести часть из них в резервное хранилище, чтобы система продолжала работать стабильно. Это пример управления с замкнутым контуром.

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

ИТ-Мониторинг с точки зрения ITIL

В ITIL (библиотека, описывающая лучшие практики управления IT) ИТ-Мониторинг играет одну из ключевых ролей в управлении ИТ-услугами.

Из глоссария ITIL:
Мониторинг -  это постоянное наблюдение за Конфигурационной единицей, ИТ-услугой или Процессом с целью обнаружения Событий и обеспечения информированности о текущем состоянии.
 
А вот управление Событиями, о которых информирует ИТ-мониторинг уже является основным процессом в управлении ИТ-услугами. ITIL классифицирует События в зависимости от значимости на Инциденты, Проблемы и Изменения и далее по каждому из видов Событий рекомендует использовать соответственно процессы управления Инцидентами, управления Проблемами и управления Изменениями, что в конечном итоге позволяет значительно повысить качество ИТ-услуг.


ИТ-Мониторинг с точки зрения COBIT

В COBIT Мониторинг выведен в отдельный домен "Мониторинг и оценка". Всего доменов в последней 5-ой версии пять, они схематически изображены на рисунке ниже.  

Рисунок 1. Домены процессов в COBIT 5

Домен "Мониторинг и оценка"состоит из 4-х процессов:

- Мониторинг и оценка эффективности ИТ;

- Мониторинг и оценка системы внутреннего контроля

- Обеспечение соответствия внешним требованиям

- Обеспечение корпоративного управления ИТ

 
По COBIT Мониторинг необходим для уверенности в том, что все делается правильно, в соответствии с принятыми направлениями и политиками.
 
Так как COBIT специализируется на контроле и аудите ИТ, то в отличии от ITIL, специализирующегося в основном на управлении ИТ,  для COBIT более важное значение имеют не События, а статистическая информация. Этот вид информации, который Мониторинг собирает и хранит в базе, позволяет руководству компании делать текущие выводы на основе исторических данных, принимать стратегические управленческие решения, прогнозировать затраты и эффективность информационных технологий для организации.  


Какую систему мониторинга выбрать
 
Когда ставится вопрос о системе мониторинга, то выбор стоит между системами с открытым программным обеспечением (Open Source Software) и  платным (требующим оплату за лицензии). В большинстве случаев выбор сводится к четырем вариантам.
 
Две системы c открытым исходным кодом:
Nagios
Zabbix
 
И две, требующие оплаты за использование ПО:
IBM Tivoli
HP Software (в прошлом HP OpenView)

Платные системы мониторинга имеет смысл использовать, если есть наличие промышленных приложений уровня SAP, Oracle, возможность интеграции с системами поддержки и управления ИТ-услугами (ServiceDesk), системами управления бизнес-услугами (Business Service Management, BSM), требование гарантированной технической поддержки от разработчиков данного программного обеспечения, а также возможность платить за лицензии.
 
Open Source системы мониторинга можно использовать в тех случаях, когда вы готовы своими силами дописывать скрипты для мониторинга каких-либо специфических метрик, нет необходимости в короткие сроки настроить мониторинг редких промышленных приложений, так как под них вы скорее всего не найдете готовых шаблонов, и придется их разрабатывать самостоятельно. А также у вас нет необходимости интеграции с ServisDesk, BSM, и в случае возникновения проблем с системой мониторинга вы готовы решать их самостоятельно.
 
Большой плюс систем мониторинга с открытым программным обеспечением в том, что, в принципе, вы можете самостоятельно настроить мониторинг практически любых метрик при возможности их получения каким-либо способом.

C уважением,
Андрей
Компания ITRM

понедельник, 20 мая 2013 г.

Автоматизация мониторинга доступности динамического списка серверов и сетевых устройств в системе мониторинга Zabbix


В вычислительных сетях с большим количеством устройств (например, сеть банкоматов или сетевых устройств) часто требуется мониторинг доступности узлов с возможностью сбора и графического отображения статистической информации по задержкам и потерям пакетов в канале до данных узлов. Иногда список устройств для которого требуется мониторинг доступности бывает динамическим, то есть может периодически меняться как сам список устройств, так и их ИП-адреса или названия.


В данной статье мы решили описать решение этой задачи при помощи системы мониторинга Zabbix.


В Zabbix-е начиная с версии 2.0 доступна новая функция: низкоуровневое обнаружение.
Низкоуровневое обнаружение предоставляет возможность автоматического создания элементов данных, триггеров и графиков для разных ресурсов на компьютере. Так, в дистрибутив включена возможность автоматического обнаружения сетевых интерфейсов и дисков на сервере. Рассмотрим, как ещё можно применять данную возможность.


Есть задача осуществлять мониторинг доступности серверов - порядка 200-300 единиц. Допустим, что требуется раз в 2 минуты с серверов клиента проверять их доступность по сети, время отклика и потери пакетов. По всем параметрам должна собираться и графически отображаться статистика. При этом список серверов обновляется динамически в текстовом файле выглядящем следующим образом::
имя_сервера1 192.168.1.11
имя_сервера2 192.168.2.22
и т.д.


Для решения этой задачи удобно использовать низкоуровневое обнаружение.
Создаем скрипт, который будет запрашиваться с сервера, где работает система мониторинга Zabbix. Его результатом будет текст в формате json, который требуется для низкоуровневого обнаружения:


#!/usr/bin/perl

$latest_file=`ip.servers.lst`;  # Текстовый файл с динамическим списком узлов

print "{\n";
print "\t\"data\":[\n\n";

for (`cat $latest_file`)
{
    ($clname, $clip) = m/\S_(\S+) (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/; # $clname - имя сервера, $clip - его IP-адрес

   print "\t{\n";
   print "\t\t\"{#CLNAME}\":\"$clname\",\n";
   print "\t\t\"{#CLIP}\":\"$clip\"\n";
   print "\t},\n";
}

print "\t]\n";
print "}\n";


Вывод этого скрипта будет примерно таким:
{
       "data":[
       {
               "{#CLNAME}":"server_name1",
               "{#CLIP}":"192.168.1.11"
       },
       {
               "{#CLNAME}":"server_name2",
               "{#CLIP}":"192.168.2.22"
       },



       ]
}


Добавляем скрипт в конфигурацию агента Zabbix zabbix_agentd.conf  в разделе UserParameter:
UserParameter=cl.discovery,/home/zabbix/cl.discovery.pl


В web-интерфейсе Zabbix-сервера создаем правило “create discovery rule” (Рис. 1) для хоста, с которого осуществляется мониторинг серверов и сети:
  • Name discovery clients
  • Type zabbix agent
  • Key такой же, что указан в UserParameter (cl.discovery)
  • Keep lost resources period (in days) 0 (если не хотим хранить информацию о серверах, которые не требуется мониторить)

     
Рисунок 1. Правило “create discovery rule”


В разделе Item prototypes (Рис. 2) создаем прототипы требуемых элементов данных (create item prototype):
Для времени отклика:
  • Name ICMP ping response time to {#CLNAME} {#CLIP}
  • Type Zabbix trapper
  • Key cl.icmppingsec[{#CLIP}]
  • Type of information Numeric(float)
  • Units ms

Рисунок 2. Раздел Item prototypes.


Для потерь пакетов:
  • ICMP ping percentage of loss packets {#CLNAME} {#CLIP}
  • Type Zabbix trapper
  • Key cl.icmppingloss[{#CLIP}]
  • Type of information Numeric(float)
  • Units %


В разделе Graph prototypes (Рис. 3) создаем (create graph prototype) прототип графиков привязанные к созданным прототипаv элементов данных.


Рисунок 3. Разделе Graph prototypes.


В разделе Trigger prototypes создаём прототипы тригеров к созданным прототипам элементов данных.


Теперь при изменении списка с серверами в zabbix-сервере автоматически будут создаваться и удаляться соответствующие элементы данных и графики (Рис. 4).


Рисунок 4. Графики по задержкам и потерям пакетов в канале до определенного узла.

C уважением,
Компания ITRM

пятница, 22 июня 2012 г.

Облачные вычисления

Облачные вычисления

Сейчас очень много говорят о вычислениях в “облаках”. Попробую высказать свою точку зрения на это. Если где-то ошибусь - буду рад, если меня поправят.

Во-первых, облачные вычисления - это не какая-то новая идея, и даже не новая технология. Пользуюсь облачными сервисами уже больше 10 лет - это и электронная почта, онлайн-переводчик, сервисы создания и редактирования документов, онлайн-мониторинга и многое другое. Даже блог нашей компании создан и размещается в облаке.Что касается технологий, то и тут нет ничего нового. Провайдеры предоставляющие облачные услуги используют известные уже давно технологии виртуализации: XEN, KVM, VirtualBox, VmWare.

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

Попробуем разобраться.

Немного истории.
В самом начале развития информационных технологий доминировали майнфреймы (высокопроизводительные сервера). Еще до эпохи Интернета, чтобы воспользоваться вычислительными ресурсами майнфрейма, надо было заранее договориться о времени и физически присутствовать там, где находилось оборудование. Заранее - так как хоть это и мощный компьютер, но и он ограничен в вычислительных ресурсах. Но в тоже время с высокопроизводительным сервером могли работать одновременно несколько человек.


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

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

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

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

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

Этой возможности послужили три фактора. Перечислю их по мере значимости.

Первый и, по моему, основной - пропускная способность каналов связи за последние годы значительно возросла, стала стабильнее и дешевле. Это позволило выносить из частных сетей в публичные большие объемы информации с небольшими затратами, но еще важнее - иметь стабильный и скоростной доступ в любое время для работы с этой информацией.
Второй фактор - появились технологии виртуализации позволяющие просто и эффективно ограничивать ресурсы потребляемые пользователями, расширять и уменьшать их при необходимости. Причем этот фактор также повысил безопасность и SLA.
И в третий - сами вычислительные ресурсы бысто растут при уменьшении стоимости на них и, например, сегодня обычный персональный компьютер по мощности можно сравнить с сервером 2-3 летней давности. Это позволило снизить стоимость владения и, соответственно, использования ресурсов супер-компьютеров для пользователей.

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


C уважением,
Андрей

понедельник, 4 июля 2011 г.

SRV-записи для Jabber-сервера

Настройки ДНС для Jabber-сервера:

_xmpp-server._tcp.your_domain.ru. 3600 SRV 20 0 5269 jabber.your_domain.ru.
_xmpp-client._tcp.your_domain.ru. 3600 SRV 20 0 5222 jabber.your_domain.ru.
_jabber._tcp.your_domain.ru. 3600 SRV 20 1 5269 jabber.your_domain.ru.

Данные SRV записи нужны для связи вашего jabber-сервера с другими, например gtalk.

среда, 16 июня 2010 г.

HP ANM - Automated Network Management

HP ANM

Новый программный продукт от компании HP - Automated Network Management (HP ANM) представляет из себя интеграцию новой версии NNM - NNMi 9 с Network Automation (NA), а также с нескольких SPI:

- iSPI Performance for Quality Assurance 9
- iSPI Performance for Metrics 9
- iSPI Performance for Traffic 9
- iSPI NET

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

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

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

Перечисленные iSPI собирают статистическую информацию с сетевых устройств и сохраняют ее в базе данных, интегрируются с NNMi9. Это предоставляет единый интерфейс для просмотра и анализа статистики.

среда, 16 декабря 2009 г.

Jabber

Сети мгновенной передачи сообщений как средство связи в бизнесе.

Помимо традиционных средств связи, таких как телефон, факс, электронная почта рассмотрим еще одно - посредством сетей мгновенной передачи сообщений.

В последнее время набирает популярность открытый протокол XMPP (также известный как Jabber), в настоящее время используемый в таких сервисах как Я.Онлайн, Google Talk, LiveJournal.

Помимо открытости протокола, Jabber имеет еще одно преимущество - при помощи шлюзов клиенты Jabber могут работать также с такими популярными сетями, как ICQ, MSN и др.

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

Взято отсюда:
http://forum.itrm.ru/index.php?t=msg&th=178&start=0&rid=21