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

Gals software

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 (презентация по запросу).
Подробнее..

Аудит событий Active Directory и других решений Microsoft в Quest Change Auditor анонс вебинара

22.02.2021 12:20:43 | Автор: admin
Change Auditor инструмент для автоматизации аудита изменений в AD, Azure AD, SQL Server, Exchange, Exchange Online, Sharepoint, Sharepoint Online, Windows File Server, OneDrive for Business, Skype for Business, VMware, NetApp, EMC, FluidFS. Есть предустановленные отчёты на различные виды угроз, а также на соответствие стандартам GDPR, SOX, PCI, HIPAA, FISMA, GLBA.

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

image

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


А кто это сделал? Автоматизируем аудит информационной безопасности

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

Управление доступом и формирование отчётов безопасности для окружения Microsoft в Quest Enterprise Reporter

Сравним инструменты для аудита изменений в Active Directory: Quest Change Auditor и Netwrix Auditor

Sysmon теперь может записывать содержимое буфера обмена

Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

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

А ещё у нас есть:

Группа в Facebook

Канал в Youtube.
Подробнее..

Централизованная аутентификация и управление файлами в решениях от One Identity анонс вебинара

16.03.2021 20:17:50 | Автор: admin


Приглашаем Вас принять участие в вебинаре посвящённому решению One Identity для интеграции UNIX, Linux и Mac OS X в Active Directory One Identity Safeguard Authentication Services и Safeguard for Sudo. Вебинар состоится 17 марта в 12 часов по московскому времени.

Регистрация

Вы узнаете, как с помощью One Identity Safeguard Authentication Services входить в системы, отличные от Windows, с использованием своих учетных данных AD. Благодаря централизованной аутентификации, межплатформенному контролю доступа и единому входу ваша организация может расширить возможности соответствия и безопасности Active Directory по всему предприятию и выйти на новый уровень операционной эффективности.

Используя One Identity Safeguard for Sudo вы сможете централизовать управление файлами политик sudo, расширить функционал, упростить управление, централизовать отчётность и многое другое.

Под катом решаемые продуктом задачи и ссылки на другие наши статьи о безопасности. Велкоме.

Как проблемы обеспечения безопасности Unix решает продукт:

  • Управление доступом отдельно по каждому серверу
  • Отсутствие согласованных политик в отношении паролей
  • Низкая безопасность NIS
  • Дублирующая инфраструктура LDAP
  • Отсутствие делегирования или контроля над корневыми учетными записями
  • Встроенные отчеты по доступу и привилегированным пользователям трудоемки и приводят к частым ошибкам
  • Отсутствие контроля и прозрачности при выполнении значимых команд привилегированными пользователями


Подробнее о решении вы можете узнать на сайте One Identity.

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

А ещё у нас есть на Хабре другие статьи о безопасности:

Как администратору Microsoft Teams обезопасить себя и того парня

А кто это сделал? Автоматизируем аудит информационной безопасности

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

Управление доступом и формирование отчётов безопасности для окружения Microsoft в Quest Enterprise Reporter

Сравним инструменты для аудита изменений в Active Directory: Quest Change Auditor и Netwrix Auditor

Sysmon теперь может записывать содержимое буфера обмена

Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Группа в Facebook

Канал в Youtube
Подробнее..

Восстановить контроллер домена Active Directory из пепла вебинар по Quest Recovery Manager

24.03.2021 00:15:52 | Автор: admin
Ошибки иногда случаются. Active Directory (AD) может понести утрату, если администратор в душевном порыве случайно что-то удалит или выполнит массовое обновление, которое приведёт к нежелательным результатам. Восстановление может растянуться на часы или даже дни и, как следствие, привести к вынужденному простою определённых бизнес-процессов. В таких ситуациях не помешает план аварийного восстановления и инструмент восстановления AD для ускорения возвращения в штатный режим работы.



Quest Recovery Manager для Active Directory похож на страховку для среды AD. Решение фиксирует изменения в AD на уровне объектов или атрибутов и позволяет в несколько кликов откатываться назад. В любой момент времени вы будете знать, что произошло, на кого повлияло и что нужно откатить. В интерфейсе можно быстро сравнить текущее состояние с резервной копией, чтобы мгновенно восстановить данные в локальной среде, Azure AD или гибридной среде.

Приглашаем вас зарегистрироваться на вебинар, который состоится 24 марта в 11 часов дня по московскому времени. Если вы не сможете его посетить или прочитаете этот пост после его начала, в любом случае, оставьте ваши контактные данные и мы пришлём вам запись. На вебинаре вы узнаете как восстановить любой объект в AD без необходимости перезапуска контроллеров домена и быстро выявить изменения в настройках AD (и не только AD). Под катом возможности Quest Recovery Manager для AD и несколько скриншотов интерфейса решения и ссылка на другие наши статьи по решениям Quest для работы со средой Microsoft.

Recovery Manager работает из оснастки операционной системы:



Позволяет делегировать восстановление другим пользователям:



Восстанавливает любой объект AD без нужды в перезагрузке контроллера домена:



Восстанавливает определённые атрибуты без необходимости восстановления учетной записи в AD целиком:



Отчётность по произошедшим изменениям (сравнение):



Поддерживает работу через PowerShell для автоматизации рутинных задач:



Если вы хотели бы протестировать Quest Recovery Manager в вашем окружении или вас интересует стоимость решения, оставьте ваши данные в форме обратной связи или свяжитесь другим удобным способом.



А ещё у нас есть:

А кто это сделал? Автоматизируем аудит информационной безопасности

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

Управление доступом и формирование отчётов безопасности для окружения Microsoft в Quest Enterprise Reporter

Сравним инструменты для аудита изменений в Active Directory: Quest Change Auditor и Netwrix Auditor

Sysmon теперь может записывать содержимое буфера обмена

Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Группа в Facebook

Канал в Youtube.
Подробнее..

Интеграция UNIX, Linux и Mac OS X в Active Directory с Safeguard Authentication Services анонс вебинара

11.05.2021 18:04:27 | Автор: admin
image

Приглашаем Вас принять участие в вебинаре посвящённому решению One Identity для интеграции UNIX, Linux и Mac OS X в Active Directory One Identity Safeguard Authentication Services и Safeguard for Sudo. Вебинар состоится 12 мая в 12 часов по московскому времени.

One Identity Safeguard Authentication Services предназначен для организации доступа в информационную среду компании с помощью записей в AD. С One Identity Safeguard for Sudo вы сможете централизовать управление файлами политик sudo, расширить функционал, упростить управление, централизовать отчётность и многое другое. Если вы хотите узнать о технических подробностях решений One Identity, оставьте заявку в форме обратной связи и мы вышлем вам ссылку на прошедший 17 марта вебинар.
Подробнее..

Google-like система поиска уязвимостей IT Security Search анонс вебинара

15.06.2021 16:19:06 | Автор: admin
image

IT Security Search это похожая на Google поисковая система для ИТ, которая позволяет ИТ-администраторам и командам безопасности быстро реагировать на инциденты безопасности и анализировать поступающие события. Веб-интерфейс инструмента объединяет разрозненные ИТ-данные из многих решений Quest по обеспечению безопасности и соответствия требованиям в единую консоль. Решения Quest, в свою очередь, могут являться надежным поставщиком отфильтрованных данных в различные SIEM-системы и даже помогут снизить стоимость владения ими.

Приглашаем вас зарегистрироваться на вебинар, который состоится 16 июня в 11 часов по московскому времени. Вы узнаете о функционале решения, решаемых задачах, интеграциях и лицензировании. Под катом кратко о возможностях IT Security Search. Даже если вы оставите данные после вебинара, мы вышлем вам ссылку.

Инструмент интегрируется с другими решениями Quest: Change Auditor, InTrust, Recovery Manager и Enterprise Reporter. По поступающим оттуда данным и ведется полнотекстовый поиск.

В IT Security Search можно ввести имя пользователя, рабочей станции, тип события или всё что угодно и обнаружить связанные по этому признаку события или конфигурации. При формировании запросов можно использовать логические выражения. Из результатов запроса удобно строить отчёты и направлять их заинтересованным лицам по расписанию.

image

Из интерфейса IT Security Search можно также делать откат по изменениям в AD. То есть, например, можно восстановить удаленного по ошибке пользователя со всеми его атрибутами. Это реализуется при помощи интеграции с ещё одним продуктом Quest Recovery Manager for Active Directory.

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

Ссылки на наши предыдущие статьи

Групповые политики (GPO) Active Directory: разбираемся почему это важно и как ими управлять в GPOAdmin

Как администратору Microsoft Teams обезопасить себя и того парня

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

Управление доступом и формирование отчётов безопасности для окружения Microsoft в Quest Enterprise Reporter

Сравним инструменты для аудита изменений в Active Directory: Quest Change Auditor и Netwrix Auditor

Sysmon теперь может записывать содержимое буфера обмена

Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Подписывайтесь

Группа в Facebook

Канал в Youtube
Подробнее..

Дорожная карта миграции почты IBM NotesDomino в Exchange и Office 365

22.09.2020 08:08:59 | Автор: admin
image


Переход с IBM Notes на Microsoft Exchange или Office 365 дает весомое количество преимуществ для организации, но сам проект миграции выглядит пугающе и не совсем понятно с чего нужно начинать миграцию. Сам Exchange не включает собственные инструменты для полной миграции или установления сосуществования Notes и Exchange. Фактически, выполнение некоторых задач миграции и сосуществования невозможно без сторонних продуктов. В этой статье мы опишем семь ключевых шагов, которые необходимо выполнить в соответствии с лучшими практиками и нашим опытом проведения успешных миграций.

Успешная миграция включает следующие шаги:

  1. Предварительная оценки миграции.
  2. Установление сосуществования Notes и Exchange.
  3. Планирование оптимальной точности миграции.
  4. Обеспечение максимальной эффективности миграции.
  5. Запуск пробной миграции.
  6. Планирование времени миграции, для минимизации влияния на организацию.
  7. Запуск миграции и отслеживание ее прогресса.

В этой статье мы разберем как подготовиться к миграции и выполнить ее при помощи двух решений от Quest Coexistence Manager for Notes и Migrator for Notes to Exchange. Под катом некоторые подробности.

Шаг 1: Предварительная оценка миграции


Проведение инвентаризации текущей среды


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

  • Сколько существуют доменов Notes и серверов Domino?
  • Сколько у вас почтовых ящиков? Сколько из них не используются?
  • Сколько места на дисках занимают файлы основной почты? Сколько в архивах? Сколько в локальных репликах?
  • Где находятся архивы?
  • Сколько пользователей используют шифрование? Зашифрованный контент нужно перенести?
  • Сколько личных папок существует в окружении?
  • Какие пользователи используют ссылки на документы? Сколько пользователей получили ссылки от других пользователей и приложений?
  • Сколько данных вы собираетесь переносить? Например, вы хотите перенести данные только за последние полгода.
  • Будут ли перенесены нативные архивы в персональные архивы Exchange или в файлы *.pst Outlook?
  • Каковы ограничения полосы пропускания? Сколько данных можно перенести в
    определенный промежуток времени?
  • Какой объем хранилища потребуется после миграции?

Как миграция повлияет бизнес и операционную деятельность


Нужно тщательно спланировать проект, чтобы свести к минимуму простои и минимизировать потерю производительности.

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

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

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

Прежде чем начать миграцию, нужно определить критерии для измерения успеха. В частности, нужно понимать, что неразумно ожидать 100% переноса данных. Не у каждого типа элемента Notes есть эквивалент в Exchange (Active Mail самый вопиющий пример). Следовательно, реальность такова что не все элементы в Notes будут существовать в Exchange после миграции. Достижимая и измеримая цель 95% элементов перенесено для 95 процентов почтовых ящиков. Измерение и документирование результатов имеют решающее значение для обеспечения успеха миграции, а настоящие результаты возможны только если были определены критерии успешности в самом начале проекта миграции электронной почты.

Шаг 2: установление сосуществования Notes и Exchange


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

Разработка стратегии сосуществования


Чтобы повысить ценность от миграции, полный план сосуществования должен быть разработан и реализован на ранней стадии процесса миграции. Определение понятия сосуществования может быть разным для разных организаций. Некоторые организации активно используют данные Free/Busy, другие совсем не пользуются этим функционалом. Некоторые делают упор на миграцию данных календаря, в то время как другие сконцентрированы на тщательной проработке переноса полного каталога пользователей. Важно поработать с каждой из заинтересованных сторон, чтобы получить ясную картину того, что действительно важно и помочь всем понять важность эффективной стратегии сосуществования.

Переход с Notes на Exchange и Office 365 требует планирования миграции почтовых ящиков и приложений одновременно. Должна поддерживаться текущая функциональность приложений Notes для всех пользователей независимо от их текущей почтовой платформы. Как пользователи, перешедшие на Exchange и Office 365, они должны иметь доступ и использовать приложения Notes в рамках существующих рабочих процессов. Эта возможность должна сохраняться до тех пор, пока приложения Notes перенесутся на SharePoint или другую платформу.

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

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

Шаг 3: Планирование оптимальной точности миграции


Планирование перехода с Notes на Exchange или Office 365 требует понимания ряда конкретных различий между платформами.

Адреса электронной почты


Данные Notes обычно содержат проприетарные адреса, которые появляются в нескольких местах: в заголовках сообщений, встроены в архивы, личные контакты и распределенные списки. В рамках процесса миграции, эти проприетарные адреса должны быть обновлены до SMTP-адресов для обеспечения полной функциональности в среде Exchange. Многие организации также предпочитают обновить домен SMTP или стандарт адресации во время миграции. Если это касается вашей организации, важно понимать, что некоторые решения для миграции автоматически обновляют экземпляры исторического SMTP-адреса для каждого пользователя.

Структура папки


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

Локальные реплики и архивы


В целях контроля затрат на хранение и лучшего управления ростом объема данных, многие организации устанавливают квоты на почтовые ящики. Непреднамеренным следствием этой политики часто бывает увеличение количества и размера архивов. Эти дополнительные данные источники должны быть оценены и вопрос их миграции стоит рассмотреть во время планирования миграции. Можно предоставить пользователям компонент самообслуживания, который даст им перенести только важные данные. Для оптимизация хранилища Exchange мы рекомендуем использовать другой продукт Quest Archive Manager for Exchange, в нем есть, в частности, полезный функционал по дедупликации вложенных файлов, аналог DAOS в Notes.

ACL и делегирование


Разрешенные списки для контроля доступа (ACL) и делегирование ключевые элементы для операционной в среде Notes, они также имеют решающее значение для защиты целостности. В результате важно точно преобразовать связанные права и права доступа к эквивалентным правам в Exchange Server и Office 365. В идеале сделать это автоматически, что ускорит процесс и исключит человеческую ошибку. Чтобы поддержать эффективность защиты информационных активов организации, ACL и преобразование делегирования должно быть выполнено одновременно с почтовыми данными. Некоторые организации пытаются назначить эквивалентные права вручную или с помощью скриптов, после завершения переноса данных. Однако, такой подход может негативно повлиять на производительность и добавить пробелы в безопасность данных организации.

Собственное содержание Notes


Тот самый Active Mail. Еще одна распространенная проблема, когда миграция с IBM Notes встречается с большим количеством форматированного текста. Exchange и Office 365 не поддерживают интегрированные таблицы с вкладками, кнопки, сохраненные формы и другой проприетарный контент в Notes. В результате вам потребуется либо подготовиться к потере этой функциональности или инвестировать в решение для миграции, способное преобразовать эти элементы в формат, который может быть перенесен. Скажем сразу, что решения от Quest такое никак не конвертируют и могут разве что перенести такие письма в виде вложений, чтобы пользователь мог их потом открыть через клиент Notes.

Группы и личные адресные книги


Многие организации широко используют публичные списки рассылки для внутренней и
внешней связи. К тому же, пользователи Notes часто считают важным вести деловые контакты в личных адресных книгах. Эти источники данных важны для бизнес-операций и должны быть эффективно преобразованы во время перехода на платформу Microsoft. В результате важно автоматически подготовить группы к миграции в Active Directory и эффективно конвертировать все личные адреса, даже те, которые хранятся на рабочих местах пользователей.

Взаимодействие с приложениями Notes


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

Ресурсы и почтовые базы данных


Многие организации используют базы данных резервирования ресурсов, почтовые базы данных и другие общие базы данных в Notes. В результате, эти базы данных играют важную роль в работе организации. Для обеспечения непрерывности бизнеса и продуктивности сотрудников, очень важно учитывать подход и сроки реализации для:

  • Создания ресурсных почтовых ящиков в целевой среде;
  • Переноса данных из базы данных резервирования в Exchange;
  • Обеспечения того, чтобы пользователи обеих систем могли сотрудничать и использовать ресурсы в Notes и Exchange.

Шаг 4: обеспечение максимальной эффективности миграции


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

Архитектура миграционного решения


Один из важнейших факторов влияния на эффективность архитектура миграционного решения. Очень важно выбрать решение с многопоточной архитектурой, которая позволяет одному серверу миграции переносить несколько пользователей одновременно. Многопоточная архитектура снижает требования к оборудованию для миграции и увеличивает скорость миграции, резко снижая общую стоимость проекта. Не обманывайтесь решениями для миграции которые утверждают, что они многопоточны, но фактически выполняют миграцию только одного пользователя за раз и требуют добавления рабочих станции, чтобы переносить больше пользователей одновременно. В зависимости от конфигурации и окружения, настоящие многопоточные решения от 30 до 5000 процентов эффективнее при переносе данных на Exchange и Office 365.

Процесс миграции


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

Гибкость и самообслуживание


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

Шаг 5: запуск пробной миграции


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

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

Определение объема пилотной миграции


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

Выбор данных и систем


В процессе пилотной миграции важно использовать боевые данные и боевые системы. Это очень важно по некоторым причинам:

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

Установление ожиданий


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

Шаг 6: планирование времени миграции для минимизации влияния на организацию


Группировка пользователей


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

Сроки миграции


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

Шаг 7: запуск миграции и отслеживание ее прогресса


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

Заключение


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

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

Статья на Хабр: Миграция IBM Lotus Notes/Domino в Microsoft Exchange

Quest Migrator for Notes to Exchange на сайте Gals

Quest Coexistence Manager for Notes на сайте Gals

Quest Migrator for Notes to Exchange на сайте Quest

Quest Coexistence Manager for Notes на сайте Quest
Подробнее..

Зонтичная система мониторинга и ресурсно-сервисные модели в обновленном 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.

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

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

Как лицензируется и чем отличаются лицензии Elastic Stack (Elasticsearch)

05.11.2020 02:15:38 | Автор: admin
В этой статье расскажем как лицензируется Elastic Stack, какие бывают лицензии, что туда входит (ключевые возможности), немножечко сравним Elastic с OpenDistro от AWS и другими известными дистрибутивами.



Как видно на картинке выше, существует 5 типов, условно говоря, подписок, по которым можно пользоваться системой. Подробности по тому, что написано ниже, вы можете узнать на специальной странице Elastic. Всё написанное в этой статье применимо к Elastic Stack, размещаемому на собственной инфраструктуре (on-premise).

Open Source. Это версия Elastic Stack, которая находится в свободном доступе в репозитории Elastic на Github. В принципе, вы можете взять ее и сделать убийцу Arcsight, QRadar, Splunk и других прямых конкурентов Elastic. Платить за это ничего не нужно.

Basic. Этот тип лицензии включает в себя возможности предыдущей лицензии, но дополнен функционалом, который не имеет открытого кода, но, тем не менее, доступен на бесплатной основе. Это, например, SIEM, доступ к ролевой модели, некоторые виды визуализаций в Kibana, Index Lifecycle Management, некоторые встроенные интеграции и другие возможности.

На этом бесплатные лицензии закончились и пришло время разобраться с платными лицензиями. Elastic Stack лицензируется по количеству нод Elasticsearch. Рядом может стоять хоть миллион Kibana и Logstash (или Fluentd, если угодно), но лицензии будут считаться именно по хостам, на которых развернут Elasticsearch. В расчет лицензий также не входят ноды с ролями Ingest, Client/Coordinating. На попадающее в расчет количество нод напрямую влияет объем входящего трафика и требования к хранению данных. Напомним, что для обеспечения надежности работы кластера, в нем должно быть минимум 3 ноды. Мы проводим расчет сайзинга исходя из методики, которую описывали в одной из предыдущих статей. При покупке лицензий Elasticsearch доступен только формат подписки длительностью от 1 года с шагом в 1 год (2, 3 и так далее). Теперь вернемся к типам лицензий.

Gold. В лицензии Elasticsearch уровня Gold появляется поддержка авторизации через LDAP/AD, расширеное логирование для внутреннего аудита, расширяются возможности алертинга и техподдержка вендора в рабочие часы. Именно подписка уровня Gold очень похожа на AWS OpenDistro.

Platinum. Наиболее популярный тип подписки. кроме возможностей уровня Gold, тут появляется встроенное в Elastic машинное обучение, кросс-кластерная репликация, поддержка клиентов ODBC/JDBC, возможность гранулярного управления доступом до уровня документов, поддержка вендора 24/7/365 и некоторые другие возможности. Ещё в рамках этой подписки они могут выпускать Emergency patches.

Enterprise. Самый выскоий уровень подписки. Кроме всех возможностей уровня Platinum, сюда входят оркестратор Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, решение по безопасности для конечных устройств Endgame (со всеми его возможностями), поддержка вендором неограниченного количества проектов на базе Elastic и другие возможности. Обычно используется в крупных и очень крупных инсталляциях.

У Elastic появилось уже немало форков, самый известный из которых OpenDistro от AWS. Его ключевым преимуществом является поддержка некоторых возможностей оригинального Elastic, доступных на платных подписках. Основные это интеграция с LDAP/AD (а еще SAML, Kerberos и другими), встроенный алертинг (на бесплатном Elastic это реализуется через Elast Alert), логирование действий пользователей и поддержка JDBC-драйверов.

Упомянем также про HELK и Logz.io. Первый проект на Github, который обвешивает Elasticsearch дополнительным ПО для аналитики угроз (пишут, что пока это всё находится в альфе), а второй облачный сервис, основанный на Elastic и добавляющий некоторые приятные фичи. В комментариях можно поделиться другими форками, о которых вам известно.

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

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

Сайзинг Elasticsearch

Разбираемся с Machine Learning в Elastic Stack (он же Elasticsearch, он же ELK)

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

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows
Подробнее..

Низкоуровневое обнаружение (LLD) в Zabbix через SQL-запросы

16.11.2020 14:12:10 | Автор: admin


Привет, Хабр! В этой статье поделюсь полезным подходом мониторинга в Zabbix через обнаружение элементов данных в ответе на SQL-запрос. Этот тип мониторинга обычно используется в бизнес-мониторинге, когда собираются показатели производительности бизнес-процесса: количество пользователей, транзакций или выполняется контроль статуса операций. В целом, это универсальный подход, про который администраторы Zabbix иногда забывают. А он есть. Добро пожаловать под кат.

Что будем делать в этой статье:

  • Клонируем репозиторий pg_stat_monitor от Percona и соберём этот плагин из исходников;
  • Добавим плагин pg_stat_monitor в БД PostgreSQL, на которой работает Zabbix;
  • Создадим шаблон для выполнения SQL-запроса в pg_stat_monitor;
  • Создадим правило низкоуровневого обнаружения для разбора ответа от SQL-запрос;
  • Создадим зависимые прототипы элементов данных для мониторинга некоторых характеристик производительности БД.

На сервере предварительно уже установлен Zabbix 5.2, работающий на PostgreSQL 12.

Установка и настройка плагина pg_stat_monitor для PostgreSQL


Pg_stat_monitor плагин для сбора статистики от Percona, основанный на pg_stat_statements. Можно сказать, что pg_stat_monitor это pg_stat_statements на стероидах. Основной недостаток pg_stat_statements отсутствие агрегированной статистики (и гистограмм в т.ч.) по накопленным запросам и статистике по ним. Соответственно, pg_stat_monitor лишен такого недостатка. Объём статистики, которая может собираться, настраивается в конфигурации плагина. Работает плагин следующим образом:

  • собирается статистика и объединяется в корзину (агрегат);
  • корзина собирается и хранится заданный период времени;
  • когда время истекает, pg_stat_monitor сбрасывает всю накопленную статистику и начинает собирать её заново.

Т.к. все данные из корзины в итоге исчезнут, нужно успеть прочитать эти данные. Как раз их мы и будем читать при помощи Zabbix.

Исходный код плагина доступен в репозитории Percona на Github. Мы его оттуда клонируем, соберём на тестовом сервере и подключим к имеющемуся инстансу PostgreSQL.

Листинг установки плагина
# dnf -y install gcc git libpq-devel postgresql-server-devel # cd /tmp# git clone git://github.com/Percona/pg_stat_monitor.git# cd pg_stat_monitor# make USE_PGXS=1# make USE_PGXS=1 install# sudo -i -u postgres psql# postgres=# alter system set shared_preload_libraries=pg_stat_monitor;# postgres=# \q# systemctl restart postgresql# sudo -i -u postgres psql# postgres=# create extension pg_stat_monitor;# postgres=# \q


После установки можно убедиться, что всё работает и спросить у плагина его настройки:



Ещё можно спросить, что он вообще может показать:



Некоторые из данных со скриншота выше мы будет потом забирать в Zabbix.

Создание шаблона в Zabbix для работы с БД по ODBC


Теперь установим на сервер с БД драйвер ODBC:

# dnf -y install postgresql-odbc

И проверим как там называется драйвер:



Теперь можно перейти в Zabbix, добавить некоторые макросы:



И создать мастер-элемент данных, из которого потом будут разбирать всё необходимое зависимые элементы:



В результате получим вывод в формате JSON:



Создание LLD-правила и прототипов элементов данных


На следующем шаге добавим к шаблону правило дискаверинга:



Добавим LLD-макрос для создания новых объектов по полю queryid:



Создаём один из прототипов элементов данных:



И шаги препроцессинга:



В итоге мы настроили три прототипа данных для разбора полей с текстом запроса, максимальным временем выполнения и количеством вызовов:



В результате всех выполненных настроек получим следующую картину:



Некоторые из запросов окрашены в серый, потому что queryid с ними более не обнаруживаются. Можно настроить минимальное время хранения таких объектов и удалять их сразу после отправки оповещения о длительном SQL-запросе.

Заключение


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

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

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

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

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

Мониторинг принтеров в Zabbix

Как сократить объем дискового пространства, занимаемого БД Zabbix

Как снизить количество шумовых событий в Zabbix
Подробнее..

Анонс вебинара по зонтичной системе мониторинга 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.

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

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

Elasticsearch сайзинг шардов как завещал Elastic анонс вебинара предложения по митапу

15.03.2021 20:13:27 | Автор: admin

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

Сайзинг шардов Elasicsearch


Как Elasticsearch работает с шардами


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

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

Давайте теперь краем глаза взглянем на сегменты (см. картинку ниже). Каждый шард Elasticsearch является индексом Lucene. Максимальное количество документов, которое можно закинуть в индекс Lucene 2 147 483 519. Индекс Lucene разделен на блоки данных меньшего размера, называемые сегментами. Сегмент это небольшой индекс Lucene. Lucene выполняет поиск во всех сегментах последовательно. Большинство шардов содержат несколько сегментов, в которых хранятся данные индекса. Elasticsearch хранит метаданные сегментов в JVM Heap, чтобы их можно было быстро извлечь для поиска. По мере роста объёма шарда его сегменты объединяются в меньшее количество более крупных сегментов. Это уменьшает количество сегментов, что означает, что в динамической памяти хранится меньше метаданных (см. также forcemerge, к которому мы вернемся чуть дальше в статье).

Еще стоит сказать о ребалансировке кластера. Если добавляется новая нода или одна из нод выходит из строя, происходит ребалансировка кластера. Ребалансировка сама по себе недешёвая с точки зрения производительности операция. Кластер сбалансирован, если он имеет равное количество шардов на каждой ноде и отсутствует концентрация шардов любого индекса на любой ноде. Elasticsearch запускает автоматический процесс, называемый ребалансировкой, который перемещает шарды между узлами в кластере, чтобы его сбалансировать. При перебалансировке применяются заранее заданные правила выделения сегментов (об allocation awareness и других правилах мы подробнее расскажем в одной из следующих статей). Если вы используете data tiers, Elasticsearch автоматически разместит каждый шард на соответствующем уровне. Балансировщик работает независимо на каждом уровне.

Как заставить Elasticsearch ещё лучше работать с шардами


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

Создавать шарды размером от 10 до 50 ГБ. Elastic говорит, шарды размером более 50 ГБ потенциально могут снизить вероятность восстановления кластера после сбоя. Из-за той самой ребалансировки, о которой мы говорили в начале статьи. Ну, и большие шарды накладнее передавать по сети. Предел в 50 ГБ выглядит, конечно, как сферический конь в вакууме, поэтому мы сами больше склоняемся к 10 ГБ. Вот тут человек советует 10 ГБ и смотреть на размер документов в следующем плане:

  • От 0 до 4 миллионов документов на индекс: 1 шард.
  • От 4 до 5 миллионов документов на индекс: 2 шарда.
  • Более 5 миллионов документов считать по формуле: (количество документов / 5 миллионов) + 1 шард.

20 или менее шардов на 1 ГБ JVM Heap. Количество шардов, которыми может жонглировать нода, пропорциональны объему JVM Heap ноды. Например, нода с 30 ГБ JVM Heap должна иметь не более 600 шардов. Чем меньше, тем, скорее всего, лучше. Если это пропорция не выполняется можно добавить ноду. Посмотрим сколько там используется JVM Heap на каждой ноде:



А теперь посмотрим сколько шардов на каждой ноде и видим, что с нашим тестовым стендов всё в порядке. Жить будет.



Количество шардов на узле можно ограничить при помощи опции index.routing.allocation.total_shards_per_node, но если их уже много, присмотритесь к Shrink API.

Совсем необязательно создавать индексы размером в 1 день. Часто встречали у заказчиков подход, при котором каждый новый день создавался новый индекс. Иногда это оправдано, иногда можно и месяц подождать. Ролловер ведь можно запускать не только с max_age, но и с max_size или max_docs. На Хабре была статья, в которой Адель Сачков, в ту пору из Яндекс Денег (сейчас уже нет), делился полезным лайфхаком: создавал индексы не в момент наступления новых суток, а заранее, чтобы этот процесс не аффектил на производительность кластера, но у него там были микросервисы.
каждые сутки создаются новые индексы по числу микросервисов поэтому раньше каждую ночь эластик впадал в клинч примерно на 8 минут, пока создавалась сотня новых индексов, несколько сотен новых шардов, график нагрузки на диски уходил в полку, вырастали очереди на отправку логов в эластик на хостах, и Zabbix расцветал алертами как новогодняя ёлка. Чтобы этого избежать, по здравому размышлению был написан скрипт на Python для предварительного создания индексов.

С новогодней ёлкой неплохой каламбурчик получился.

Не пренебрегайте ILM и forcemerge. Индексы должны плавно перетекать между соответствующими нодами согласно ILM. В OpenDistro есть аналогичный механизм.



С индексами, в которые уже не ведется запись можно выполнить forcemerge слияние меньших по размеру сегментов в более крупные. Это в итоге снизит накладные расходы на эксплуатацию шардов и повысит скорость поиска. Forcemerge требует значительных ресурсов, поэтому лучше это делать к какие-то в непиковые часы. Добавим, что forcemerge это фактические создание нового сегмента из двух старых, поэтому свободное место на диске лишним точно не будет.

Приходите в комментарии и расскажите о своём опыте с раскладыванием шардов по нодам. Было бы интересно узнать о том, что работает в вашем случае.

Анонс вебинара. Elastic приглашает посетить 17 марта в 12 часов по московскому времени вебинар Elastic Telco Day: Applications and operational highlights from telco environments. Эксперты расскажут о применении в решений Elastic в телекоме. Регистрация.

Предложения по митапу. Планируем проведение онлайн-митап по Elastic в апреле. Напишите в комментариях или в личку какие темы вам было бы интересно разобрать, каких спикеров услышать. Если бы вы хотели сами выступить и у вас есть что рассказать, тоже напишите. Вступайте в группу Elastic Moscow User Group, чтобы не пропустить анонс митапа.

Канал в телеге. Подписывайтесь на наш канал Elastic Stack Recipes, там интересные материалы и анонсы мероприятий.

Читайте наши другие статьи:




Если вас интересуют услуги внедрения, администрирования и поддержки Elastic Stack, вы можете оставить заявку в форме обратной связи на специальной странице.
Подробнее..

Зонтичная Grafana скрещиваем Zabbix и Microsoft SCOM

18.03.2021 18:13:59 | Автор: admin
Если у вас есть Grafana и несколько систем мониторинга, то почему бы не визуализировать все имеющиеся данные и статусы в едином интерфейсе?

image

Покажем на примере нашего тестового стенда как скрестить Zabbix и SCOM в единой Grafana и сделать сервисный мониторинг (с точки зрения здоровья сервисов). Подробности и скриншоты под катом.

На скриншоте ниже информационные системы компании. Здесь электронная почта, DNS, Active Directory, Sharepoint и другие. Каждый квадрат это агрегированный статус информационной системы. Ниже мы покажем за счет чего так получается. Обращаем внимание, что различные системы могут быт охвачены различными системами мониторинга. В нашем случае это Zabbix и SCOM.

image

Начнём c Zabbix. Там есть возможность создавать группы узлов. Каждому узлу соответствует набор триггеров. Что мы делаем дальше? Ищем наихудший статус триггера на узле и отдаём его значение в специальный элемент данных. Следом проводим аналогичное действие по агрегированию наихудшего статуса триггера для группы узлов и получаем агрегированный статус здоровья группы.

image

Уже после этого можно привязывать статусные элементы данных к плиткам в Grafana. На скриншоте ниже компоненты информационной системы Электронная почта. Каждая плитка это агрегированный статус здоровья сервисов системы. Каждая плитка это ссылка, можно провалиться и увидеть на каком узле проблема. Обратите внимание, что такая агрегация позволяет выводить вложенные события на каждом уровне (они под плитками).

image

Если проваливаться дальше, то можно дойти до уровня узла, где будут его метрики производительности. При желании, там можно сделать плитку с агрегированным статусов виртуализации, а дальше и сетевых устройств. Подход зависит от задач. С Zabbix разобрались, переходим к SCOM.

Интеграция Grafana со SCOM реализована при помощи SQL-запросов в базы OperationsManager и OperationsManagerDW. Первая для кратковременного хранения, вторая для долговременного. При помощи SQL-запроса получим список узлов, которые находятся на мониторинге в SCOM.

image

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

image

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

image

Ну, а дальше посмотреть на значения отдельных метрик узла.

image

Ещё можно использовать вот такое представление с событиями одновременно для Zabbix и Microsoft SCOM.

image

Спасибо за внимание! Надеюсь, было интересно.

А ещё у нас есть:

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

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

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


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

Application performance management (APM) от Broadcom для мониторинга производительности приложений (включая мобильные)

24.02.2021 08:04:01 | Автор: admin
Всем привет! В этой статье расскажем о возможностях мониторинга производительности приложений одного из лидеров квадранта Gartner c APM-решениями Broadcom.

image

Appdynamics, Dynatrace и New Relic достаточно известны на российском рынке. Broadcom чуть менее знаком, этакая серая лошадка, однако, имеет не уступающий всем троим функционал мониторинга приложений. А использование APM-решения от Broadcom в комплексе с другим их продуктом, зонтичной AIOps-системой DX Operations Intelligence, позволит создать единое окно мониторинга для разнокалиберного ПО и инфраструктуры. Под катом текст и скриншоты.

Для мониторинга производительности приложений Broadcom поставляет два решения: DX APM и DX AXA. Первое работает с бэкэндом, второе с фронтэндом и мобильными приложениями.

DX APM


Архитектура DX APM


DX Applications Performance Management (APM) предназначен для мониторинга производительности приложений, написанных на Java, .NET, C++, PHP, Node.js, Python, Go и использующих другие технологии. Полный список поддерживаемых технологий можно посмотреть в Compatibility Guide. На ниже приведена область задач мониторинга, которые закрывает DX APM.



Основные особенности DX APM:

  • Распределенная (микросервисная) архитектура решения;
  • Простота в установке, использовании и обновлении;
  • Простота развертывания агентов, в том числе для микросервисных приложений, развернутых в кластере Kubernetes или Openshift;
  • Способность преждевременно выявлять нештатные ситуации до того, как это отразится на опыте конечных пользователей;
  • Автоматический поиск первопричины отказа или возникновения нештатных ситуаций как на программном так и на инфраструктурном уровнях;
  • Является поставщиком необходимой и достаточной информации для разработчиков, операционных подразделений заказчика и бизнес-ориентированных групп.

В спектр задач, решаемых DX APM входят:

  • Мониторинг производительности приложений;
  • Мониторинг опыта пользователей и бизнес-контекста;
  • Мониторинг отклика БД, инфраструктурных компонентов приложения и внешних сервисов;
  • Аналитика и root cause analysis.



DX APM предоставляет различные варианты для визуализации данных:

Experience View. Представление данных с точки зрения оценки опыта конечных пользователей. Данные представлены в виде Experience Cards. Experience card предоставляет верхнеуровневый обзор здоровья для транзакций. Транзакции объединены в Experience Card по заданным атрибутам.

Так выглядит набор Experience Cards:


А так отдельная Experience Card:


Map View транзакционная карта приложения. Слева направо отображает прохождение транзакций от конечного пользователя до сервера приложений, базы данных и т.д, в зависимости от архитектуры приложения. Карта строится автоматически после установки агентов на серверы приложений.



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



Если приложение микросервисное, DX APM распознает используемые технологии в рамках поддерживаемых и создаст соответствующую визуализацию.



Ещё одно важное преимущество решения от Broadcom наличие универсального агента Universal Monitoring Agent (UMA) для различных технологий. UMA устанавливается единожды на кластер, где развернуто микросервисное приложение, далее агент сам отслеживает динамические изменения и ведет мониторинг как инфраструктурных компонент кластера (nodes, pods, containers) так и осуществляет технологический мониторинг приложений в части исполнения кода. С точки зрения автоматизации мониторинга самое оно.



Расследование проблем DX APM


DX APM для ускорения поиска первопричины проблемы в снижении производительности использует в работе запатентованные технологии: Differential Analysis, Timeline View и Assisted Triage, Topology View/Layers. Во многих случаях упреждающие оповещения (на основе аномального поведения), генерируемые DX APM, позволяют избежать реальных проблем в будущем.

Assisted Triage сигнализирует о наличии проблем и аномалий в работе приложений и в автоматическом режиме предоставляет заключение о первоисточнике проблемы, тем самым обеспечивая root-cause analysis. Аномалии указывают на нестрандартное поведение в работе приложении, но при этом воздействия на опыт конечных пользователей еще нет. Так выглядит работа Assisted Triage



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



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



Функция Timeline позволяет быстро увидеть изменения в архитектуре приложения во времени в контексте проблем с производительностью, не покидая Map View. Особенно это эффективно при обновлении релиза приложения позволит увидеть все проблемы разом.



При возникновения проблем в работе приложения, разработчикам будет интересно и полезно проанализировать транзакционные трейсы. DX APM предусматривает как функционал автоматической записи трейсов Smart Instrumentation, так и возможности запуска ручной трассировки. DX APM автоматически записывает трассировки транзакций при возникновении следующих событий:

  • В случае ошибок;
  • В случае нестабильного поведения в работе приложения (на основе изменяющегося времени отклика между компонентами приложения или так называемого Differential Analysis).



Использование коммерческими решения открытых решений заметный тренд последнего времени. DX APM поддерживает технологию OpenTracing. При этом решение получает данные о показателях и трассировках транзакций из приложений, оснащенных трассировщиками, совместимыми с OpenTracing. Как результат, можно видеть в UI DX APM целостную транзакционную цепочку (MAP) и сквозной транзакционный трейс. Это особенно актуально для распределённых микросервисных приложений.



Ещё одной важной функцией при расследовании проблем снижения производительности в работе приложения является анализ SQL-запросов к базам данных и мониторинг производительности баз данных. DX APM предоставляет такие возможности для наиболее популярных баз данных, таких как Oracle, MS SQL и некоторых других.



Business Payload Analyzer


Business Payload Analyzer (BPA) это запатентованная функция сбора и анализа данных (Payload транзакций), которая помогает использовать бизнес-контекст для именования транзакций. На рисунке 23 представлено позиционирования BPA по отношению к AXA и APM. По сути, как и AXA (через Browser agent и мобильный SDK) BPA является поставщиком метаданных для APM и помогает в определении бизнес-транзакций.



Физически, BPA является плагином, который устанавливается на web-сервер приложения. Плагин собирает сырые http-данные (после дешифрования серверов https-трафика) каждого запроса и ответа и заливает их в DX APM для дальнейшей обработки и формирования бизнес-транзакций. В текущей версии DX APM 20.2 плагин BPA доступен для:

  • Apache Web Server Plugin for Linux and Windows;
  • IIS Plugin;
  • Nginx Web Server Plugin.

DX AXA


DX AXA (Application Experience Analytics) ориентирован на мониторинг взаимодействия пользователeй с фронтэндом через браузер или мобильное приложение на своём гаджете. Данные, собираемые AXA, могут быть использованы как разработчиками для оптимизации работы приложений, так и бизнес-аналитиками для формирования отчетности о доступности сервисов и планирования бизнес-KPI. Фокус AXA в задаче мониторинга опыта конечных пользователей представлен на рисунке ниже.



DX AXA получает данные по транзакциям пользователей мобильных приложений с помощью интеграции SDK в приложение. В список поддерживаемых платформ включены: Android, iOS, WatchOS. Стоит отметить, что процедура встраивания инструментария SDK в приложения Android очень проста, осуществляется в web-интерфейсе AXA в несколько кликов мыши и не требует привлечения разработчиков.

Также AXA покрывает мониторинг и web-транзакций пользователей с помощью Browser Agent. Browser agent это snippet (скрипт), который встраивается в домашнюю страницу приложения, и при взимодейсвии пользователя с приложением собирает и отправляет метрики взаимодействия на сервер AXA для анализа. Таким образом, это не требует установки агента на рабочих станциях конечных пользователей. Browser agent имеет широкий спектр возможностей по кастомизации и сбору данных. При этом поддерживаются web-транзакции во всех популярных браузерах.



Основной спектр задач, который решает AXA для команд эксплуатации являются:
  • Сегментация данных по версии приложения, провайдеру / wifi, местоположению, платформе, ОС;
  • Оповещения в режиме реального времени о снижении в производительности в работе приложений, пользовательскго опыта и нарушнении SLA, и потенциальных рисков для доходов компании;
  • Ускорение выявления первопричины проблемы.



В список функций, предназначенных для разработчиков приложений входят:

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



2. Сегментация сбоев по платформе, устройству. Индикация и детальные данные по App Crashes, HTTP и JavaScript Errors.



3. Просмотр параметров производительности для каждой сессии пользователя.



4. Функция Resource Waterfall обеспечивает более глубокое понимание производительности веб-приложений, отображая подробную информацию о времени загрузки всех компонентов веб-сайта.



Фунционал по разработке отчетности и визуализации данных способен удовлетворить требования бизнеса по планированию доходов и оценке затрат на модернизацию приложений:

  • Приоритезация проблем путем оценки влияния на доходы компании;
  • Возможность задания KPI для оценки ROI;
  • Дополнительные данные для формирования OPEX и CAPEX.





DX AXA имеет глубокую интеграцию с продуктом DX Application Performance Management (APM) для расследования проблем, не связанных с фунционированием фронтэнда. DX AXA при этом является дополнительным поставщиком данных для DX APM по транзакциям, совершаемым пользователями с помощью мобильных приложений.



Интеграция DX APM и DX AXA с DX Operational Intelligence


DX Operations Intelligence это зонтичная система мониторинга, в которой реализованы функции Machine Learning и Artificial Intelligence (ML и AI) над поступающими в платформу данными. Одними из поставщиков таких данных (наравне с Zabbix, Prometheus и прочими) являются DX APM и DX AXA.

DX AXA и DX APM работают в составе платформы DX. Платформа DX устанавливается и работает под управлением кластеров Kubernetes или OpenShift. Установщик платформы DX это консольное приложение, которое запускается пв докер-контейнере и поэтому имеет минимальные зависимости от операционной системы. Программа установки взаимодействует с кластером и выполняет все необходимые действия для создания готового к использованию экземпляра платформы DX. Установщик платформы DX также поддерживает развертывание с хоста, который не является частью кластера.
Используя установщик платформы DX, вы можете установить следующие компоненты:

  • Мониторинг производительности приложений DX APM
  • Мониторинг мобильных приложений DX AXA
  • Зонтичное решение DX OI



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

  • Создание и управление тенантами;
  • Мониторинг и управление ресурсами кластера и сервисами;
  • Создание учетных записей администраторов и пользователей и управление ими;
  • Управление учетными записями пользователей на основе LDAP;
  • Создание и управление учетными записями пользователей, не использующих LDAP;
  • Настройка параметров почтового сервера.





Broadcom безвозмездно предоставит в пользование продукт DX Operational Intelligence Foundation (DX OI) при приобретении лицензий DX APM. DX OI Foundation позволит реализовать фукнции Machine Learning над поступающими в платформу данными (логи, метрики, аварийные сообщения, топология) и оценить/спрогнозировать доступность сервисов на базе анализа поступающих данных. Кроме того, DX OI Foundation может стать единой точкой концентрации аварийных сообщений и интеграции с системой Service Desk.

К сведению: по сравнению с полной версией DX OI, версия Foundation имеет ограничения по времени хранения данных, также есть ограничения по функциям Predictive Insights, Capacity Analytics и интеграции со сторонними системами через Open RESTful APIs. Для снятия этих ограничений необходимо отдельно приобрести лицензии на решение DX OI.

Ну, и напоследок, важное замечание: все перечисленные в этой статье решения Broadcom можно использовать как on-premise так и в SaaS-формате.

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

В ближайшее время мы проведём вебинар по DX APM и DX AXA. Если вы хотели бы узнать подробнее об этих решениях, оставьте заявку и вам вышлем приглашение как только анонсируем вебинар.

А ещё у нас есть:

Запись нашего вебинара по DX OI

Статья на Хабре о зонтичной AIOps-системе мониторинга DX OI

Группа в Facebook

Канал в Youtube
Подробнее..

Мониторинг производительности приложений в Broadcom DX APM анонс вебинара

02.03.2021 10:09:04 | Автор: admin
image

Единый агент для всех популярных технологий, динамическое отслеживание изменений инфраструктуры, низкий оверхед, искусственный интеллект, оценка эффективности релизов, контекстный мониторинг, мониторинг реальных транзакций обо всём этом и многом другом вы узнаете на вебинаре, посвящённому инструменту для мониторинга производительности приложений и инфраструктуры под ними Broadcom DX APM. Вебинар состоится 5 марта в 11 часов утра по московскому времени.

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

Под катом вы найдёте квадрант Gartner за 2020 год по APM-решениям и дополнительные материалы по DX APM и другим решениям Broadcom.


DX APM несколько лет подряд сохраняет лидерство. Решение регулярно обновляется, появляется новый функционал. Особенность продукта использование под капотом открытых технологий, например, OpenTelemetry. Этот тренд, кстати, распространяется и на некоторых других лидеров квадранта.

image

А ещё у нас есть:

Как устроен и работает DX APM

Запись нашего вебинара по зонтичной AIOps-системе мониторинг DX OI

Статья на Хабре о зонтичной AIOps-системе мониторинга DX OI

Группа в Facebook

Канал в Youtube
Подробнее..

Мониторинг популярных баз данных из единого интерфейса Quest Foglight анонс вебинара

05.04.2021 10:08:01 | Автор: admin
Foglight for Databases удобный инструмент для DBA, который поддерживает мониторинг SQL Server, Oracle, MySQL, PostgreSQL, DB2, SAP ASE, MongoDB и Cassandra. И всё это в одном интерфейсе.

Кроме этого, инструмент позволяет сравнивать производительности БД в разные периоды времени (например, до релиза и после него), а также выполнять сравнение производительности различных экземпляров.

image

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

Ключевая особенность мониторинга SQL Server в Foglight for Databases наличие инструмента Performance Investigator, который выполняет многомерный анализ производительности БД в разрезах по базам данных, долгим запросам, сессиям, пользователям, исполнимым скриптам, рабочим станциям и приложениям. На скриншоте ниже ниже в древовидном меню можно рассматривать производительность БД в нескольких разрезах. Кроме этого, Foglight фиксирует изменения к конфигурации БД, Execution Plan и других компонентах.

image

В одной из предыдущих статей мы рассказывали о примере выполнения диагностики в Foglight следующих проблем:

  • Поиск источника блокировки;
  • Сравнение настроек БД было-стало с привязкой к метрикам производительности;
  • Поиск изменений в структуре БД, из-за которых снизилась производительность.

Аналогичных кейсов с диагностикой в решении есть с избытком.

Чтобы узнать больше о Foglight for Databases вы также можете прочитать другие наши статьи:

Как не превратиться в стрекозу, если у вас много разных баз данных

Интерфейсы для мониторинга производительности популярных БД в Foglight for Databases

Подписывайтесь на нашу группу в Facebook и канал в Youtube.
Подробнее..

Управление и оптимизация баз данных в ApexSQL анонс вебинара

18.05.2021 22:22:31 | Автор: admin
ApexSQL это комплексный набор инструментов, который оптимизирует и автоматизирует процессы управления базами данных SQL Server и разработки, а также обеспечивает безопасность и соответствие требованиям. В одной из прошлых статей мы описывали бесплатные и платные инструменты ApexSQL (там и правда есть из чего выбрать).

image

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

Под катом список решений ApexSQL с кратким описанием и ссылками на соответствующие страницы на сайте вендора.


  1. ApexSQL Compare инструмент для сравнения SQL-кода, файлов и папок. Работает также в качестве расширения для SSMS или Visual Studio.
  2. ApexSQL Decrypt потоковая дешифрация объектов в SQL Server: процедур, функций, триггеров и представление (view). Работает также в качестве расширения для SSMS или Visual Studio.
  3. ApexSQL Discover обнаружение экземпляров SQL Server и сопутствующих сервисов SSRS, SSAS и SSIS.
  4. ApexSQL Refactor инструмент для рефакторинга и форматирования SQL-кода. Работает в качестве расширения для SSMS или Visual Studio.
  5. ApexSQL Model создание диаграмм объектов SQL Server. Работает также в качестве расширения для SSMS или Visual Studio.
  6. ApexSQL Plan инструмент для оптимизации Execution plans. Работает также в качестве расширения для SSMS.
  7. ApexSQL Complete инструмент автоматически завершает операторы SQL и позволяет добавлять собственные сниппеты (сочетания клавиш для автозаполнения). Работает также в качестве расширения для SSMS или Visual Studio.
  8. ApexSQL Propagate инструмент для исполнения SQL-кода на нескольких БД за один раз.
  9. ApexSQL Search утилита для поиска данных и объектов в недрах SQL Server. Работает в качестве расширения для SSMS или Visual Studio.
  10. ApexSQL DevOps Toolkit инструмент для создания CI/CD пайплайнов. Единственный из всех перечисленных тут продуктов имеет веб-консоль.
  11. ApexSQL Audit инструмент для аудита БД на соответствие требованиям безопасности, в т.ч. поддерживаются HIPAA, GDPR, PCI. Поддерживаются отчёты и просмотр истории изменений.
  12. ApexSQL Backup автоматизация создания инкрементального бэкапа, лога транзакций и полного бэкапа. Поддерживается восстановление на определённый момент во времени, можно создавать шаблоны для создания бэкапа и гибко настраивать планы бэкапов.
  13. ApexSQL Defrag утилита для мониторинга и управления дефрагментацией.
  14. ApexSQL Job инструмент для управления заданиями, включая историю, расписание и уведомления.
  15. ApexSQL Log инструмент для чтения лога транзакция для аудита, репликации или отката изменений.
  16. ApexSQL Recover восстановление повреждённых, удалённых или потерянных данных.
  17. ApexSQL Analyze инструмент для анализа связей в БД.
  18. ApexSQL Build инструмент для автоматизации создания БД. Может подключаться к системам контроля версий.
  19. ApexSQL Enforce улучшатель SQL-кода.
  20. ApexSQL Generate инструмент для генерации миллионов строк данных за один клик. Поддерживается экспорт тестовых данных в SQL, XML, CSV, JSON и Excel.
  21. ApexSQL Mask инструмент для поиска, классификации и маскирования чувствительных данных в БД. Имеет 220+ предопределённых масок и 55+ встроенных фильтров для классификации.
  22. ApexSQL Script инструмент для создания DDL и DML скриптов и исполняемых инсталляционных пакетов.
  23. ApexSQL Source Control инструмент для интеграции систем контроля версий с SSMS.
  24. ApexSQL Trigger аудит данных в БД и трансляция в DML.
  25. ApexSQL Unit Test инструмент для выполнения юнит-тестов напрямую из консоли SSMS.


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



А ещё у нас есть:

Интерфейсы для мониторинга производительности популярных БД в Foglight for Databases

Быстрая локализация проблем производительности Microsoft SQL Server в Quest Foglight

10 бесплатных утилит ApexSQL для управления базами данных Microsoft SQL Server

Как не превратиться в стрекозу, если у вас много разных баз данных

Подписывайтесь на нашу группу в Facebook и канал в Youtube.
Подробнее..

Управление и оптимизация баз данных SQL Server в ApexSQL анонс вебинара

19.05.2021 00:17:20 | Автор: admin
ApexSQL это комплексный набор инструментов, который оптимизирует и автоматизирует процессы управления базами данных SQL Server и разработки, а также обеспечивает безопасность и соответствие требованиям. В одной из прошлых статей мы описывали бесплатные и платные инструменты ApexSQL (там и правда есть из чего выбрать).

image

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

Под катом список решений ApexSQL с кратким описанием и ссылками на соответствующие страницы на сайте вендора.


  1. ApexSQL Compare инструмент для сравнения SQL-кода, файлов и папок. Работает также в качестве расширения для SSMS или Visual Studio.
  2. ApexSQL Decrypt потоковая дешифрация объектов в SQL Server: процедур, функций, триггеров и представление (view). Работает также в качестве расширения для SSMS или Visual Studio.
  3. ApexSQL Discover обнаружение экземпляров SQL Server и сопутствующих сервисов SSRS, SSAS и SSIS.
  4. ApexSQL Refactor инструмент для рефакторинга и форматирования SQL-кода. Работает в качестве расширения для SSMS или Visual Studio.
  5. ApexSQL Model создание диаграмм объектов SQL Server. Работает также в качестве расширения для SSMS или Visual Studio.
  6. ApexSQL Plan инструмент для оптимизации Execution plans. Работает также в качестве расширения для SSMS.
  7. ApexSQL Complete инструмент автоматически завершает операторы SQL и позволяет добавлять собственные сниппеты (сочетания клавиш для автозаполнения). Работает также в качестве расширения для SSMS или Visual Studio.
  8. ApexSQL Propagate инструмент для исполнения SQL-кода на нескольких БД за один раз.
  9. ApexSQL Search утилита для поиска данных и объектов в недрах SQL Server. Работает в качестве расширения для SSMS или Visual Studio.
  10. ApexSQL DevOps Toolkit инструмент для создания CI/CD пайплайнов. Единственный из всех перечисленных тут продуктов имеет веб-консоль.
  11. ApexSQL Audit инструмент для аудита БД на соответствие требованиям безопасности, в т.ч. поддерживаются HIPAA, GDPR, PCI. Поддерживаются отчёты и просмотр истории изменений.
  12. ApexSQL Backup автоматизация создания инкрементального бэкапа, лога транзакций и полного бэкапа. Поддерживается восстановление на определённый момент во времени, можно создавать шаблоны для создания бэкапа и гибко настраивать планы бэкапов.
  13. ApexSQL Defrag утилита для мониторинга и управления дефрагментацией.
  14. ApexSQL Job инструмент для управления заданиями, включая историю, расписание и уведомления.
  15. ApexSQL Log инструмент для чтения лога транзакция для аудита, репликации или отката изменений.
  16. ApexSQL Recover восстановление повреждённых, удалённых или потерянных данных.
  17. ApexSQL Analyze инструмент для анализа связей в БД.
  18. ApexSQL Build инструмент для автоматизации создания БД. Может подключаться к системам контроля версий.
  19. ApexSQL Enforce улучшатель SQL-кода.
  20. ApexSQL Generate инструмент для генерации миллионов строк данных за один клик. Поддерживается экспорт тестовых данных в SQL, XML, CSV, JSON и Excel.
  21. ApexSQL Mask инструмент для поиска, классификации и маскирования чувствительных данных в БД. Имеет 220+ предопределённых масок и 55+ встроенных фильтров для классификации.
  22. ApexSQL Script инструмент для создания DDL и DML скриптов и исполняемых инсталляционных пакетов.
  23. ApexSQL Source Control инструмент для интеграции систем контроля версий с SSMS.
  24. ApexSQL Trigger аудит данных в БД и трансляция в DML.
  25. ApexSQL Unit Test инструмент для выполнения юнит-тестов напрямую из консоли SSMS.


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



А ещё у нас есть:

Интерфейсы для мониторинга производительности популярных БД в Foglight for Databases

Быстрая локализация проблем производительности Microsoft SQL Server в Quest Foglight

10 бесплатных утилит ApexSQL для управления базами данных Microsoft SQL Server

Как не превратиться в стрекозу, если у вас много разных баз данных

Подписывайтесь на нашу группу в Facebook и канал в Youtube.
Подробнее..

Мониторинг SQL Server в Quest Spotlight анонс вебинара

10.03.2021 00:12:29 | Автор: admin
Spotlight простой, но при этом функциональный инструмент для мониторинга Microsoft SQL Server. На одном экране вы сможете наблюдать за статусами всех экземпляров баз данных с возможностью провалиться на уровень экзепляра и увидеть подробности.



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

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

В Spotlight есть представление в виде Timeline для просмотра событий по проблемам производительности в интервале времени. Вы увидите полную картину выявленных проблем и сможете принять адекватное решение по их устранению.



На скриншоте ниже вы видите детальное описание проблемы и рекомендацию по её устранению.



На этом скриншоте представление с Топ-8 файлов базы данных, которые наиболее интенсивно используются. Это ли не повод задумать о тюнинге производительности?



На следующем скриншоте представлен execution plan запроса. Вы сможете быстро оценить его оптимальность.



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



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



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



А ещё у нас есть:

Интерфейсы для мониторинга производительности популярных БД в Foglight for Databases

Быстрая локализация проблем производительности Microsoft SQL Server в Quest Foglight

10 бесплатных утилит ApexSQL для управления базами данных Microsoft SQL Server

Как не превратиться в стрекозу, если у вас много разных баз данных

Подписывайтесь на нашу группу в Facebook и канал в Youtube.
Подробнее..

Категории

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

  • Имя: Макс
    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