Русский
Русский
English
Статистика
Реклама

Мониторинг приложений

Zabbix под замком включаем опции безопасности компонентов Zabbix для доступа изнутри и снаружи

02.11.2020 10:17:21 | Автор: admin
А не пришло ли время разобраться и навести наконец-то порядок с безопасностью в мониторинге? Тем более, в одной из популярных систем мониторинга и встроенная возможность такая имеется.



На схеме видно, что зашифровать можно почти все потоки внутри Zabbix. В этой статье мы расскажем и покажем как это сделать, а еще расскажем о новой интеграции Zabbix с хранилищем секретов Hashicorp Vault. Там можно хранить любую чувствительную информацию от логина/пароля в БД до значений макросов. Это позволит централизованно управлять авторизационными данными, вести аудит и не хранить их на файловой системе или в БД Zabbix. Такой функционал появился в последней (на момент публикации статьи) версии Zabbix 5.2.

Интересный факт: включение шифрования на компонентах Zabbix не требует открытия дополнительных портов на фаерволлах, демоны Zabbiх поддерживают шифрованные и нешифрованные соединения одновременно.

Велкам ту подкат.

В Zabbix есть следующие основные информационные потоки:

  • Пользователь (web-браузер) <-> Zabbix web-сервер. Управление конфигурацией Zabbix, представление метрик. Шифрование настраивается средствами web-сервера.
  • Zabbix web-сервер <-> Zabbix-сервер. Web-сервер проверяет запущен ли Zabbix-сервер, запрашивает текущее состояние очереди, выполняет тест элементов данных и некоторые другие операции. Единственный поток, который в соответствии с архитектурой Zabbix нельзя зашифровать. Мы даже пытаться не будем.
  • Zabbix web-сервер <-> База данных Zabbix. Web-сервер обновляет конфигурацию в БД, извлекает данные для визуализации, удаляет исторические данные (по нажатию на Очистить историю) и запускает задания Выполнить сейчас (Execute now). Можно настроить при установке или позже в файле конфигурации zabbix.conf.php. Поддерживается TLS-шифрование при помощи ключей. Для хранения логина и пароля для БД можно использовать Vault. Важный факт: сертификаты, защищённые паролем не поддерживаются.
  • Zabbix-сервер <-> База данных Zabbix. Zabbix-сервер через configuration syncer загружает в свой кэш конфигурацию, через history syncer записывает собранные данные в БД, очищает историю (housekeeping) и выполняет некоторые другие операции. Настройки шифрования выполняются через присваивание значений специальным ключам в конфигурационном файле zabbix_server.conf.
  • Zabbix-сервер <-> Zabbix-агент. Поддерживаются общий ключ PSK и сертификаты. Взаимодействие этих компонентов делится на две части: к узлу сети (TLSAccept для пассивных проверок) и от узла сети (TLSConnect для активных проверок).
  • Zabbix-сервер <-> Zabbix-прокси. Поддерживаются общий ключ PSK и сертификаты. Настройки выполняются через присваивание значений специальным ключам в конфигурационном файле zabbix_proxy.conf.
  • Zabbix-прокси <-> Zabbix-агент. Поддерживаются общий ключ PSK и сертификаты. Взаимодействие этих компонентов делится на две части: к узлу сети (TLSAccept для пассивных проверок) и от узла сети (TLSConnect для активных проверок).
  • Zabbix-прокси <-> БД Zabbix-прокси. Настройки выполняются через присваивание значений специальным ключам в конфигурационном файле zabbix_proxy.conf.
  • Zabbix sender -> Zabbix-прокси. Поддерживаются общий ключ PSK и сертификаты в качестве параметров при вызове через командную строку.
  • Zabbix-агент -> Zabbix get. Поддерживаются общий ключ PSK и сертификаты в качестве параметров при вызове через командную строку.


Пользователь (web-браузер) <-> Zabbix web-сервер


Шифрование этой коммуникации не поддерживается со стороны Zabbix, нужно самостоятельно выполнить настройку на стороне Apache или Nginx. В этой статье мы рассмотрим настройку Nginx с самоподписанным SSL-сертификатом, т.к. преимущественно используем именно Nginx в своих проектах по мониторингу на базе Zabbix. Можно использовать сертификат доверенного центра сертификации, например, бесплатный от Let's Encrypt. Это позволит избежать страшных предупреждений в браузере. Обращаем внимание, что использование самоподписанного сертификата никак не умаляет надежности шифрованного соединения, оно будет таким же защищённым как и при использовании сертификата от доверенного CA.

Листинг настройки
# mkdir -p /etc/ssl/private/
# chmod 0750 /etc/ssl/private
# openssl req \
> -newkey rsa:2048 -nodes -keyout /etc/ssl/private/zabbix.key \
> -x509 -days 365 -out /etc/ssl/certs/zabbix.crt \
> -subj "/C=RU/ST=Russia/L=Moscow/O=Gals/OU=Gals_Dev/CN=gals.software/emailAddress=welcome@gals.software"
# chmod 0400 /etc/ssl/certs/zabbix.crt
# chmod 0400 /etc/ssl/private/zabbix.key
# mv /etc/nginx/conf.d/zabbix.conf /etc/nginx/conf.d/zabbix-ssl.conf
# vi /etc/nginx/conf.d/zbx-ssl.conf
listen 443 ssl default_server;
ssl on;
ssl_certificate /etc/ssl/certs/zabbix.crt;
ssl_certificate_key /etc/ssl/private/zabbix.key;
# vi /etc/nginx/conf.d/zabbix.conf
server {
listen 80;
return 301 https://$host$request_uri;
}
# systemctl restart nginx




В браузере появится замочек и можно посмотреть детали сертификата. Соединение зашифровано.


Zabbix web-сервер <-> База данных Zabbix


Перед началом настройки на стороне Zabbix, в БД должны быть созданы пользователи и роли с атрибутами, требующими шифрованное подключение.

Листинг создания пользователей для Zabbix web-сервера и Zabbix-сервера
mysql> CREATE USER    'zabbix_srv'@'%' IDENTIFIED WITH mysql_native_password BY '<strong_password>',    'zabbix_web'@'%' IDENTIFIED WITH mysql_native_password BY '<strong_password>' REQUIRE SSL    PASSWORD HISTORY 5; mysql> CREATE ROLE 'zabbix_srv_role', 'zabbix_web_role'; mysql> GRANT SELECT, UPDATE, DELETE, INSERT, CREATE, DROP, ALTER, INDEX, REFERENCES ON zabbix.* TO 'zabbix_srv_role'; mysql> GRANT SELECT, UPDATE, DELETE, INSERT ON zabbix.* TO 'zabbix_web_role'; mysql> GRANT 'zabbix_srv_role' TO 'zabbix_srv'@'%'; mysql> GRANT 'zabbix_web_role' TO 'zabbix_web'@'%'; mysql> SET DEFAULT ROLE 'zabbix_srv_role' TO 'zabbix_srv'@'%'; mysql> SET DEFAULT ROLE 'zabbix_web_role' TO 'zabbix_web'@'%';


Вызов статуса вернет, в том числе, данные по настройкам шифрования. Убедимся, что в строке SSL указаны алгоритмы шифрования.



Настройку шифрования между Zabbix и базой данных можно выполнить сразу при первичной настройке Zabbix через web-интерфейс. Обратите внимание на подпись напротив Database TLS encryption. Из-за того, что для подключения к локальной БД используется socket file, нет возможности настроить шифрованное подключение. Поэтому в поле Хост базы данных должны быть указаны IP-адрес или имя сервера с БД.



Меняем localhost на IP-адрес сервера и появляется чекбокс.



На двух скриншотах выше можно увидеть нововведение в Zabbix версии 5.2 поддержку интеграции с хранилищем Vault. Перед началом настройки Zabbix мы создали пару ключей и учетными данными для подключения к БД.



Берем клиентские ключи MySQL, заполняем необходимые поля и нажимаем Далее.



Другой способ настроить то же самое соответствующие ключи в конфигурационном файле zabbix.conf.php.

$DB['ENCRYPTION'] = true;
$DB['KEY_FILE'] = '/etc/ssl/mysql/client-key.pem';
$DB['CERT_FILE'] = '/etc/ssl/mysql/client-cert.pem';
$DB['CA_FILE'] = '/etc/ssl/mysql/ca.pem';
$DB['VERIFY_HOST'] = true;
$DB['CIPHER_LIST'] = '';


Zabbix-сервер <-> База данных Zabbix


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

DBTLSConnect=required
DBTLSCAFile=/etc/ssl/mysql/ca.pem
DBTLSCertFile=/etc/ssl/mysql/client-key.pem
DBTLSKeyFile=/etc/ssl/mysql/client-cert.pem
DBTLSCipher=''


После выполненных настроек, необходима перезагрузка службы Zabbix-сервера. Логин и пароль для подключения Zabbix-сервера к БД мы также храним в Vault.



Использование Vault требует добавления значений к следующим переменным в конфигурации Zabbix-сервера:

VaultDBPath=kv/secret/zabbix
VaultToken=s.Ev50RnGXNM3FmmcVBMRrR4Nz
VaultURL=http://192.168.56.101:8200


Переменная VaultDBPath отвечает за хранение учетных данных для подключения к БД. Подробнее о шифровании подключений к БД можно узнать в документации Zabbix.

Zabbix-сервер <-> Zabbix-прокси


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



Обратите внимание, что исходящие соединения (пассивные) могут выполняться каким-то одним способом на выбор, а для входящих доступны комбинации вариантов: без шифрования, PSK или сертификат.

На стороне прокси все настройки выполняются в конфигурационном файле. Для активных проверок:

TLSConnect=psk
TLSPSKIdentity=test_zabbix
TLSPSKFile=/var/zabbix/agentd.psk


Для пассивных проверок:

TLSAccept=psk
TLSPSKIdentity=test_zabbix
TLSPSKFile=/var/zabbix/agentd.psk


Второй способ шифрования подключения использование сертификатов. Заметим, что для pre-shared key (PSK) и сертификатов, закрытый ключ хранится на файловой системе в открытом виде.
Подробная информация доступна в документации Zabbix.

Zabbix-сервер <-> Zabbix-агент и Zabbix-прокси <-> Zabbix-агент


Мы не будем повторяться, настройка этих соединений аналогична настройке соединения сервера с прокси: для исходящих соединений доступен один вариант, для входящих один или несколько.



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

Zabbix-прокси <-> БД Zabbix-прокси


Подход к настройке аналогичен настройке шифрованного соединения между Zabbix-сервером и БД. Названия переменных такие же, указываются в конфигурационном файле Zabbix-прокси.

Zabbix sender -> Zabbix-прокси и Zabbix-агент -> Zabbix get


Шифрование соединения с утилитами Zabbix sender и Zabbix get выполняется при помощи специальных параметров при вызове соответствующих утилит.

zabbix_sender -z 127.0.0.1 -s zabbix02 -k Encrypt -o 18 --tls-connect psk --tls-psk-identity test_zabbix --tls-psk-file /etc/zabbix/keys/agent.psk

zabbix_get -s 127.0.0.1 -k agent.version \
--tls-connect psk --tls-psk-identity test_zabbix --tls-psk-file /etc/zabbix/keys/agent.psk


Авторегистрация с шифрованием


Шифрование также поддерживается и для процесса авторегистрации.



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

Хранение чувствительной информации в Vault


Приятное нововведение, которое появилось в версии Zabbix 5.2 поддержка хранилища Vault. Его можно использовать как для хранения учетных данных для доступа к БД так и для значений макросов. Так значения макросов выглядят в Vault:



А так на них можно сослаться в интерфейсе Zabbix:



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

Заключение


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

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

А ещё можно почитать:

Добавляем CMDB и географическую карту к Zabbix

Мониторинг принтеров дело благородное

Структурированная система мониторинга на бесплатных решениях

Elastic под замком: включаем опции безопасности кластера Elasticsearch для доступа изнутри и снаружи

Для обработки событий от Zabbix, Prometheus, Elastic и других систем рекомендуем использовать Amixr (презентация по запросу).
Подробнее..

Зонтичная система мониторинга и ресурсно-сервисные модели в обновленном DX Operations Intelligence от Broadcom (ex. CA)

19.10.2020 08:13:18 | Автор: admin
В этом сентябре Broadcom (бывшая CA) выпустила новую версию 20.2 своего решения DX Operations Intelligence (DX OI). На рынке этот продукт позиционируется как зонтичная система мониторинга. Система сособна получать и объединять данные от систем мониторинга различных доменов (сеть, инфраструктура, приложения, базы данных) как CA так и сторонних производителей, в том числе, open source решений (Zabbix, Prometheus и других).



Основная функция DX OI создание полноценной ресурсно-сервисной модели (РСМ) на базе конфигурационных единиц (КЕ), наполняющих инвентарную базу при интеграции со сторонними системами. В DX OI реализованы функции Machine Learning и Artificial Intelligence (ML и AI) над поступающими в платформу данными, что позволяет оценить/спрогнозировать вероятность отказа конкрентной КЕ и степень влияния отказа на бизнес-сервис, в основе которого лежит конкретная КЕ. Кроме того, DX OI является единой точкой сбора событий мониторинга и, соответственно, интеграции с системой Service Desk, что является неоспоримым преимуществом использования системы в единых центрах мониторинга дежурными сменами организаций. В этой статье мы расскажем подробнее о функционале системы и покажем интерфейсы пользователя и администратора.

Архитектура решения DX OI


Платформа DX имеет микросервисную архитектуру, устанавливается и работает под управлением Kubernetes или OpenShift. На следующем рисунке приведены компоненты решения, которые могут использоваться как самостоятельные инструменты мониторинга либо могут быть заменены на уже имеющиеся системы мониторинга со сходными функциями (на рисунке есть примеры таких систем) и далее подключаться к зонтику DX OI. На схеме ниже:

  • Мониторинг мобильных приложений в DX App Experience Analytics;
  • Мониторинг производительности приложений в DX APM;
  • Мониторинг инфраструктуры в DX Infrastructure Manager;
  • Мониторинг сетевых устройств в DX NetOps Manager.



Компоненты DX работают под управление кластера Kubernetes и масштабируются простым запуском новых POD. Ниже верхнеуровневая схема решения.



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

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



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



Ресурсно-сервисные модели и мониторинг бизнес-сервисов


DX OI имеет встроенные механизмы для создания сервисов и разработки классических РСМ с заданием логики влияния и весов между компонентами сервиса. Также имеются механизмы экспорта РСМ из внешней CMDB. На рисунке ниже встроенный редактор РСМ (обратите внимание на веса связей).



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



Рассмотрим подробности на примере сервиса Digital Banking. По клику по названию сервиса переходим в детальную РСМ сервиса. Видим, что статус сервиса Digital Banking зависит от состояния инфраструктурных и транзакционных подсервисов с различными весами. Работа с весами и их отображение занятное преимущество DX OI.



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

DX OI Topology Viewer это сервис, который использует в работе топологические данные, поступающие от доменных систем мониторинга, осуществляющих сбор данных непосредственно с объектов мониторинга. Инструмент предназначен для поиска в нескольких слоях хранилищ топологии и отображения карты отношений, зависящую от контекста. Для расследования проблем можно перейти в проблемный подсервис Backend Banking и увидеть топологию и проблемные компоненты. Также по каждому компоненту можно анализировать аварийные сообщения и метрики производительности.



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





Событийная аналитика (Alarm Analytics)


Алгоритмическое шумоподавление за счет кластеризации аварий


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



Таким образом, кластеризация позволяет пользователям объединять и группировать огромное количество событий и анализировать только те, которые имеют общий контекст. Например, набор событий, представляющих инцидент, влияющий на работу приложений или центра обработки данных. Ситуации создаются с использованием алгоритмов кластеризации на основе машинного обучения, использующих для анализа временную корреляцию, топологическую взаимосвязь и обработку естественного языка (native language). На рисунках ниже приведены примеры визуализации кластерных групп сообщений, так называемые Situations Alarms, и Evidence Timeline, отображающие основные параметры группировки и процесс уменьшения количества шумовых событий.





Анализ корневых проблем и корреляция аварий


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

Разберем пример, когда в систему поступают многочисленные аварийные сообщения по разным объектам (КЕ), лежащим в основе одного сервиса. В случае воздействия на доступность и работоспособность сервиса система сгенерирует сервисную аварию (Service Alarm), укажет и обозначит вероятную корневую причину (проблемный КЕ и аварийное сообщение по КЕ), которое способствовало снижению производительности или отказу сервиса. На рисунке ниже приведена визуализация аварийной ситуации для сервиса Webex.



DX OI позволяет работать с событиями посредством интуитивно понятных действий в web-интерфейсе системы. Пользователи могут вручную назначать события на ответственного сотрудника для устранения неполадок, сбрасывать/подтверждать оповещения, создавать заявки или отправлять уведомления по электронной почте, запускать автоматизированные сценарии для устранения аварийной ситуации (Remediation Workflow, об этом чуть позже). Таким образом, DX OI позволяет операторам дежурных смен сосредоточиться на корневом аварийном сообщении, а также помочь упростить процесс сортировки сообщений на кластерные массивы.

Машинные алгоритмы обработки метрик и анализ данных по производительности


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

  • Обнаружение узких мест и аномалий производительности;
  • Сравнение несколько показателей для одних и тех же устройств, интерфейсов или сетей;
  • Сравнение одинаковых показателей на нескольких объектах;
  • Сравнение различных показателей по одному и нескольким объектам;
  • Сравнение многомерных метрик по нескольким объектам.

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



Результатом применения математических алгоритмов является построение так называемых вероятностных распределений значения метрики (Rare, Probable, Center, Mean, Actual). На рисунках выше и ниже представлены вероятностные распределения.



На двух графиках выше отображены следующие данные:

  • Фактические данные (Actual). Фактические данные отображаются на графике в виде сплошной черной линии (нет сигналов тревоги) или цветной сплошной линии (состояние тревоги). Линия рассчитывается на основе фактических данных для метрики. Сравнивая фактические данные и медианное значение, вы можете быстро увидеть вариации метрики. Когда возникает событие, черная линия меняется на цветную сплошную линию, которая соответствует критичности события и отображает значки с соответствующей критичностью над графиком. Например, красный цвет для критической аномалии, оранжевый для значительной аномалии и желтый для незначительной аномалии.
  • Среднее значение показателя (Mean value). Среднее значение или среднее значение для показателя показано на диаграмме серой линией. Среднее значение отображается, когда не хватает исторических данных.
  • Медианное значение показателя (Center value). Медианная линия является серединой диапазона и показана зеленой пунктирной линией. Зоны, ближайшие этой линии, наиболее близки к типичным значениям показателя.
  • Общие данные (Common Value). Данные общей зоны отслеживают ближайшую к центральной линии или норму для вашего показателя и отображаются в виде темно-зеленой полосы. Аналитические расчеты помещают общую зону на один процентиль выше или ниже нормы.
  • Вероятностные данные. Данные вероятностной зоны показаны на графике зеленой полосой. Система помещает вероятностную зону на два процентиля выше или ниже нормы.
  • Редкие данные. Данные о редких зонах показаны на графике в виде светло-зеленой полосы. Система помещает зону с редкими значениями метрики на три процентиля выше или ниже нормы и сигнализирует о поведении показателя за пределами нормального диапазона при этом система генерирует так называемый Anomaly Alert.

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

Функция обнаружения аномалий DX OI предоставляет следующие преимущества:

  • Не нужно устанавливать пороговые значения. DX OI самостоятельно сопоставит данные и выявит аномалии.
  • DX OI включает более десяти алгоритмов искусственного интеллекта и машинного обучения, в том числе EWMA (Exponentially-WeightedMoving-Average) и KDE (Kernel Density Estimation). Эти алгоритмы позволяют выполнять быстрый анализ первопричин и прогнозировать будущие значения метрик.

Предиктивная аналитика и оповещение о возможных отказах


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



А это визуализация предиктивных предупреждений для конкретной метрики.



Прогнозирование загрузки вычислительных мощностей с функцией задания сценариев нагрузки


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

Функция Capacity Analytics в DX OI дает следующие преимущества:

  • Прогнозирование мощностей в пиковые сезоны;
  • Определение момента, когда потребуются дополнительные ресурсы для обеспечения качественного функционирования сервиса;
  • Закупка дополнительных ресурсов только при необходимости;
  • Эффективное управление инфраструктурой и сетями;
  • Устранение излишних затрат на электроэнергию за счет выявления недоиспользуемых ресурсов;
  • Выполнение оценки нагрузки на ресурсы в случае запланированного увеличения потребностей в сервисе или ресурсе.

На странице Capacity Analytics DX OI (рисунок ниже) есть следующие виджеты:

  • Состояние емкости ресурса (Resource Capacity Status);
  • Контролируемые группы/службы (Monitored Groups/Services);
  • Крупные потребители ресурсов (Top Capacity Consumers).



Основная страница Capacity Analytics показывает компоненты ресурсов, которые избыточно загружены и у которых заканчивается емкость. Эта страница помогает администраторам платформы находить чрезмерно используемые ресурсы и помогает им изменять размер и оптимизировать ресурсы. Состояние ресурсов можно проанализировать на основе цветовых кодов и их соответствующих значений. Ресурсы классифицируются в зависимости от степени их перегруженности на странице состояния емкости ресурсов. Можно щелкнуть на каждый из цветов, чтобы просмотреть список компонентов, входящих в выбранную категорию. Далее отобразится тепловая карта со всеми объектами и прогнозами на 12 месяцев, что позволяет выявить ресурсы, которые вот-вот будут исчерпаны.



Для каждой из метрик в Capacity Analytics можно указать фильтры, которые DX Operational Intelligence использует для составления прогнозов (рисунок ниже).



Доступны следующие фильтры:

  • Metric. Метрика, которая будет использоваться для прогноза.
  • Base on. Выбор объема исторических данных, которые будут использованы для построения прогнозов на будущее. Это поле используется для сравнения и анализа тенденций за последний месяц, тенденций за последние 3 месяца, тенденций за год и т. д.
  • Growth. Ожидаемая скорость роста рабочей нагрузки, которую хотите использовать для моделирования прогноза мощности. Эти данные можно использовать для прогнозирования роста сверх прогнозов. Например, ожидается, что использование ресурса вырастет еще на 40 процентов из-за открытия нового офиса.

Анализ логов


Функция анализа логов DX OI обеспечивает:

  • Сбор, агрегацию логов из разных источников (в том числе полученных агентским и безагентским способами);
  • Парсинг и нормализацию данных;
  • Анализ на соответствие поставленным условиям и генерацию событий;
  • Корреляцию событий на основе логов, в том числе с событиями, полученными в результате мониторинга ИТ-инфраструктуры;
  • Визуализацию данных на основе анализа в DX Dashboards;
  • Выводы о доступности сервисов на основе анализа данных из логов.



Сбор логов безагентным методом выполняется системой для Windows Event logs и Syslog. Агентным способом собираются текстовые логи.

Функция автоматизированного разрешения аварийных ситуаций (Remediation)


Автоматизированные действия по исправлению аварийной ситуации (Remediation Workflow) позволяют решить проблемы, вызвавшие генерацию события в DX OI. Например, проблема загрузки ЦП генерирует аварийное сообщение, процесс исправления (Remediation Workflow) решает проблему путем перезапуска сервера, на котором возникла проблема. Интеграция между DX OI и системой автоматизации позволяет запускать процессы исправления из консоли событий в DX Operational Intelligence и отслеживать их в консоли системы автоматизации.

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





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



Пример обратной связи от пользователя: пользователь выбирает понравившееся или не понравившееся предложенное действие, а система учитывает этот выбор при дальнейших рекомендациях. Лайк/дизлайк:



Рекомендуемые корректирующие действия для конкретной тревоги основаны на комбинации обратной связи, которая определяет, является ли действие приемлемым. DX OI поставляется с готовой интеграцией с системой автоматизации Automic Automation.

Интеграция DX OI со сторонними системами


Останавливаться подробно на интеграции данных из нативных продуктов мониторинга Broadcom (DX NetOps, DX Infrastructure Management, DX Application Performance Management) мы не будем. Вместо этого рассмотрим как интегрируются данные из сторонних 3rd-party систем и разберем пример интеграции с одной из наиболее популярных систем Zabbix.

Для интеграции со сторонними системами используется компонент DX Gateway. DX Gateway состоит из 3 компонентов On-Prem Gateway, RESTmon и Log Collector (Logstash). Вы можете установить все 3 компонента или только тот, который нужен, изменив общий файл конфигурации при установке DX Gateway. На рисунке ниже архитектура DX Gateway.



Рассмотрим назначение компонентов DX Gateway отдельно.

On-Prem Gateway. Это интерфейс, который собирает аварийные сигналы от платформы DX и отправляет события об авариях в сторонние системы. On-Prem Gateway действует как поллер, который периодически собирает данные о событиях из DX OI, используя API запросов по протоколу HTTPS, затем отправляет предупреждения на сторонний сервер, который интегрирован с платформой DX, используя вебхуки.



DX Log Collector принимает syslog от сетевых устройств или серверов и загружает их в OI. DX Log Collector позволяет разделить программное обеспечение, которое генерирует сообщения, систему, которая их хранит, и программное обеспечение, которое сообщает и анализирует их. Каждое сообщение помечается кодом объекта, указывающим тип программного обеспечения, генерирующего сообщение, и ему назначается уровень критичности. В DX Dashboards это всё потом можно посмотреть.

DX RESTmon интегрируется со сторонними продуктами/услугами через REST API и передает данные в OI. На рисунке ниже представлена схема функционирования DX RESTmon на примере интеграции с системами мониторинга Solarwinds и SCOM.



Ключевые функции DX RESTmon:

  • Подключение к любому стороннему источнику данных для приема данных:
    • PULL: подключение и извлечение данных из общедоступных REST API;
    • PUSH: поток данных в RESTmon через REST.
  • Поддержка форматов JSON и XML;
  • Прием метрик, предупреждений, групп, топологии, инвентаризации и журналов;
  • Готовые коннекторы для различных инструментов/технологий, также возможно разработать коннектор к любому источнику с открытым API (список коробочных коннекторов на рисунке ниже);
  • Поддержка базовой аутентификации (по умолчанию) при доступе к интерфейсу Swagger и API;
  • Поддержка HTTPS (по умолчанию) для всех входящих и исходящих сообщений;
  • Поддержка входящих и исходящих прокси;
  • Мощные возможности синтаксического анализа текста для журналов, полученных через REST;
  • Настраиваемый синтаксический анализ с помощью RESTmon, обеспечивающий эффективный анализ и визуализацию журналов;
  • Поддержка извлечения информации о группах устройств из приложений мониторинга и загрузки в OI для анализа и визуализации;
  • Поддержка возможности сопоставления с регулярными выражениями. Это может использоваться для синтаксического анализа и сопоставления сообщений логов, полученных через REST, а также для генерации или закрытия событий на основе определенных условий регулярного выражения.



Теперь рассмотрим процесс настройки интеграции DX OI с Zabbix через DX RESTmon. Коробочная интеграция забирает из Zabbix следующие данные:

  • Инвентарные данные;
  • Топология;
  • Проблемы;
  • Метрики.

Поскольку коннектор для Zabbix доступен из коробки, всё, что нужно сделать для настройки интеграции это обновить профайл, указав IP адрес API сервера Zabbix и учетную запись, а затем загрузить профайл через web-интерфейс Swagger. Пример на двух следующих рисунках.





После настройки интеграции, для поступающих из Zabbix данных будут доступны аналитические функции DX OI, описанные выше, а именно: Alarm Analytics, Performance Analytics, Predictive Insights, Service Analytics и Remediation. На рисунке ниже приведен пример анализа метрик производительности по объектам, интегрированным из Zabbix.



Заключение


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

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

Добавляем CMDB и географическую карту к Zabbix

19.10.2020 10:13:52 | Автор: admin
Хабр, конечно, не очень-то подходящая для романтики площадка, но мы не можем не признаться в любви к Zabbix. В очень многих наших проектах по мониторингу мы использовали Zabbix и очень ценим стройность и логичность этой системы. Да, здесь нет модной кластеризации событий и машинного обучения (и некоторых других фичей, доступных из коробки в коммерческих системах), но уже того что есть, определенно достаточно для внутреннего спокойствия за продуктивные системы.



В этой статье расскажем о паре инструментов для расширения функционала Zabbix: CMDB на базе бесплатного решения iTop и карте объектов на базе OpenStreetMap (OSM). А в конце статьи ваш ждет ссылка на репозиторий с кодом фронтовой части для OSM.

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



Каждая аптека это набор следующего оборудования: рабочая станция (или несколько рабочих станций), роутер, IP-камеры, принтер и другая периферия. На рабочих станциях установлены агенты Zabbix. С рабочей станции выполняется проверка через ping периферийного оборудования. Аналогичным образом, на карте объектов, с принтера можно перейти на его карточку в CMDB и посмотреть инвентаризационные данные: модель, дату поставки, ответственного и т.д. Так выглядит вложенная карта.



Здесь нужно сделать небольшое отступление. Вы можете спросить, а почему бы не использовать внутренний инвентарь Zabbix? В некоторых случаях его бывает достаточно, но мы рекомендуем клиентам всё-таки использовать внешнюю CMDB (iTop не единственный вариант, но эта система достаточно функциональна при своей бесплатности). Это удобное централизованное хранилище, где можно формировать отчеты и следить за актуальностью данных (на самом деле не только это).



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



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



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



На этой странице наш общий подход к интеграции Zabbix с iTop.

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



При нажатии на аварийную метку появляется всплывающая подсказка. С нее можно перейти на карточку объекта в CMDB либо в Zabbix. При приближении и отдалении метки объединяются в кластеры с цветом наихудшего статуса.

Географическая карта реализована с использованием js-библиотеки leaflet и плагина для кластеризации объектов. На каждую метку добавляются события из системы мониторинга и ссылка на соответствующий объект в CMDB. Статус кластеров определяется по наихудшему событию для вложенных меток. При необходимости, можно интегрировать карту с любой системой мониторинга с открытым API.

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

Если вам интересен наш подход, на этой странице можно оставить заявку на демонстрацию. Расскажем подробнее и покажем.
Подробнее..

Анонс вебинара по зонтичной системе мониторинга Broadcom DX Operations Intelligence

25.11.2020 22:06:19 | Автор: admin
image

Приглашаем вас в эту пятницу (27 ноября) принять участие в вебинаре, на котором представители Broadcom в России презентуют новую зонтичную систему мониторинга Digital Operational Intelligence (DX OI). Во время сессии мы поговорим об основных функциях системы и рассмотрим основные разделы пользовательского интерфейса. Мы покажем как, опираясь на функциональные возможности DX OI, вы сможете обеспечить значительную операционную эффективность IT-подразделений, что позволит им принимать более быстрые и правильные решения для повышения качества ИТ-услуг и бизнес-сервисов за счет междоменного контекстного анализа.

Основа DX OI это современная распределенная облачная архитектура. В решении реализованы механизмы Machine Learning над всеми поступающими данными как из доменных решений Broadcom, так и от сторонних систем через REST API, таких как Zabbix, SCOM и других популярных систем. Основная функция DX OI создание полноценной ресурсно-сервисной модели (РСМ) на базе конфигурационных единиц (КЕ), наполняющих инвентарную базу при интеграции со сторонними системами. Важная особенность DX OI возможность спрогнозировать отказ КЕ в будущем и оценить степень его вляиние на доступность сервиса.

Для владельцев приложений и бизнес-подразделений DX OI раскрывает показатель доступности и качества сервисов в контексте не только технологических IT-показателей, но и бизнес KPI, извлекаемых из транзакционной статистики конечных пользователей.

Вебинар состоится 27 ноября в 11 часов утра по московскому времени на платформе Zoom.

Регистрация на вебинар

Узнать подробнее о системе (статья на Хабре)
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru