Быстрый старт


1. О системе

1. О системе

1. О системе

Установка системы представляет собой пакетную установку на серверах под управлением ОС Linux. Система поддерживает работу на Debian, Ubuntu, Astra Linux, RedOS, CentOS.

Архитектура системы базируется на open source продуктах:


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

Управление компонентами системы осуществляется через программу установки. Для этого потребуется авторизоваться на сервере системы под УЗ по умолчанию wisla.

sudo su - wisla

И запустить run файл

./example.run
{D403D810-20A9-483E-9E8B-138F344101DB}.png


Далее будут доступны пункты меню:

1.1 Переключение в изолированный режим

В меню «Config Update» перейти на вкладку «Resources Configuration» Параметр «Local geo services» перевести в true – для закрытого контура. И перезапустить сервер приложений.

{E6BDD26B-C021-44E5-8260-523C7DD9687D}.png

1.2 Настройка уведомлений и авторизации по AD

Для настройки e-mail уведомлений вам потребуется:

  1. Включить функцию в программе установке. В режиме «Config Update» перейти на вкладку «wiSLA Notification Configuration». И задать параметру wiSLA notification enabled значение "true"

    {ABC29BD9-B499-4E99-99D4-C54C2C3B11D6}.png


  2. Включить уведомления на портале и настроить данные подключения к SMTP серверу (Настройка под профилем Admin)

    image.png

1.2 Задачи

№ Тип Выполнено Комментарий
1 Установить систему

2 Перевести систему в изолированный режим

3 Включить возможность нотификации в программе установки

2. Сбор данных

2. Сбор данных

2. Сбор данных

В качестве источников данных в системе используются программные агенты и аппаратные зонды WPE-108, WPE-110, WPE-114. 

image.png image.png image.png

WPE-110-C-AC.png

WPE-110-C-AC1.png

Однопортовый зонд wiProbe WPE-108 Двухпортовый зонд wiProbe WPE-103 SFP зонд wiProbe WPE-114 Двухпортовый зонд wiProbe WPE-110-C-AC, стоечное исполнение

Для регистрации агента или зонда в системе требуется настроить параметр "slamon-conf url".

slamon-conf url 'https://yarus.ru:8443'

ip адрес передавемый в параметре slamon-conf url должен совпадать с  ip параметра wiProbe destination

image.png

А протокол и соответствующй порт должен совпадать из настроек сервера приложений wiSLA. Актуальные порты можно проверить компандой:

cat /opt/wisla5/wildfly/current/standalone/configuration/standalone.xml | grep jboss.htt

Пример вывода:

image.png


Настройка и обновление зонда выполняются через SSH-подключение.
Для этого необходимо подключиться к устройству по указанному IP-адресу через порт 22.

Учетные записи по умолчанию:

Параметр

Значение по умолчанию

IP-адрес порта «Management»

192.168.0.1

Пароль для учётной записи root

PleaseChangeTheRootPassword

Пароль для учётной записи admin

PleaseChangeTheAdminPassword

Пароль для учётной записи user

PleaseChangeTheUserPassword

Расположение основных файлов:

Файл Путь
slamon.conf
/var/lib/slamon/slamon.conf
slamon.log
/var/log/slamon/slamon.log
java.log1,2
/var/log/slamon/java.log
uuid
/var/lib/slamon/uuid
iptables_control /etc/init.d/iptables_control
Каталог csv
/var/log/slamon/csv/
Каталог http
/var/log/slamon/http/
Скрипт автозапуска
/etc/sv/slamond/run
Скрипт slamon-conf
/usr/local/bin/
Настройки каталогов
/etc/default/slamon
Настройка типа зонда
/etc/default/slamon
Java-машина1
В составе ОС или /opt/jre/
Расположение модуля Java custom-scenario-jar-with-dependencies.jar1
/usr/local/bin/
Расположение phantomjs1
–
Задания для планировщика cron
/etc/cron.d/
Журнал FTP-обновления
/var/log/socklog/main/current

Метрики, частота сбора данных задаются агентом с сервера управления , через web-интерфейс системы – портал оператора.

Принято говорить, что зонд выполняет тесты – задания по сбору метрик. В системе присутствуют готовые «из коробки» шаблоны для мониторинга:

Помимо стандартных «коробочных» тестов зонд может выполнять пользовательские сценарии -  wiProbe Custom Scenario Test. В качестве входного параметра для теста задаётся скрипт на языке javascript. Скрипт может использовать один или несколько адаптеров. В скрипте доступна переменная manager класса AdapterManager, позволяющая получить экземпляр любого адаптера. По завершению скрипта  проверяется переменная result, значение true считается признаком успешного выполнения, и наоборот. Скрипт может в явном виде задавать значение этой переменной, либо использовать значение по умолчанию. По умолчанию, если выполнение скрипта происходит без выброса исключения, то result устанавливается в true, а при наличии исключения - в false.

Вот основные из них:

2. Сбор данных

Тесты

Тесты выполняют сбор показателей для мониторинга. Тип теста выбирают по задаче и возможностям зонда или программного агента. Создать тест можно на странице «Тесты» или при создании сервиса. Ниже тесты сгруппированы по назначению; некоторые используются в нескольких сценариях.

Канальные

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

Доступность

Проверки ресурсов и приложений. Для перечисленных тестов wiProbe достаточно одного зонда или программного агента.

DC

Сбор показателей узлов и инфраструктуры дата-центра.

Статусы и управление тестами

Список тестов

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

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

Тесты, созданные «Оператором SLA», недоступны для редактирования и выполнения действий пользователю с ролью «Системный Администратор». Право редактирования можно ограничить владельцем.

Архивировать можно только неактивный тест, не связанный с объектами инфраструктуры. Удаление необратимо и доступно только для архивного теста. Изменения настроек необходимо сохранять кнопкой «Сохранить».

Создание теста

  1. Укажите название теста и выберите тип — это обязательные поля. При необходимости добавьте метки. После выбора типа появятся соответствующие параметры.

    Название и тип теста

  2. Заполните настройки выбранного типа. Обычно это зонд или пара зондов, пропускная способность, интерфейс отправителя, адрес получателя, настройки пакетов и идентификатор теста. Зонды фильтруются по возможности использования с данным типом теста. В исходном руководстве все доступные поля настроек указаны как обязательные. Для отдельных тестов есть дополнительные окна настройки, например выбор шаблона Custom Scenario.

    Настройки теста

  3. Нажмите «Сохранить». Система предложит запустить тест. Предварительный запуск не всегда необходим: для полноценного мониторинга требуется настроить связанный сервис. Для тестов wiProbe предварительный запуск может ускорить получение результатов после активации сервиса или контракта.

Следующий этап — настройка SLA и привязка теста к сервису. Он описан в главе «3. Работа с порталом».

Источник: «Тесты» в книге «Функции wiSLA».

3. Работа с порталом

3. Работа с порталом

3. Работа с порталом

3.1 Создание контрагента и пользователя

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

Для этого авторизуемся на портале под системной учетной записью "Admin" (пароль по умолчанию Admin@123).

{626940B2-2015-4DDC-A53D-51240F36640A}.png


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

{104FAEAF-0E29-4F2C-B990-C3122D636EBE}.png

{E4CE472A-2A09-42D9-8000-74AC9EC3CCB0}.png

Работы по заведению инфраструктуры мы будем вести под пользователем с ролью "Оператор SLA". Не рекомендуются работы по настройке инфраструктуры под пользователем с привилегированными правами.

3.2 Создании точки доступа

Точка доступа служит гео

3.2 Подготовка инфраструктуры к мониторингу

3.2.1 Подготовка зонда/агента к работе

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

Для того что бы поставить объект на мониторинг потребуется:

{10D53AB1-8061-46CF-9633-D35592C16E7D}.png


{5874BC08-E0D4-4E11-901E-30C8FFE5FC69}.png
{EB87E794-63B9-41B2-A28E-547E9FED0D53}.png

{153188D8-03C5-487A-B898-63C7F44FAEF7}.png

Теперь зонд можно использовать в измерениях.

3.2.2 Настройка SLA

К каждому сервису мониторинга прикрепляются SLA (Соглашения об уровне сервиса). В SLA четко прописываются пороговые значения для ключевых метрик.  Для создания SLA необходимо перейти: Общее меню → SLA → {0FC4D290-DA20-4191-AB18-5C3C6FDE565A}.png

{A405AC30-ED14-4C25-99E6-D50B97619831}.png

При необходимости можно поправить пороги и переименовать измерения.

При необходимости добавить измерение "ICMP" через кнопку {4F5D17A2-2118-4EF9-B7D6-9379B04E112C}.png выбрать в списке показатели:

Назовём измерение, укажем метрикам пороговые значения и сохраним SLA.

{893E9E19-5183-48DD-8C22-96FBF2038178}.png

3.2.3 Создание контрактов

Объекты мониторинга — сервисы — группируются в системе в логические группы (контракты). На основе контрактов формируются SLA-отчёты, которые рассчитывают доступность сервиса для пользователей, исходя из пороговых значений метрик, заданных в SLA.

Для создания контракта необходимо перейти: Общее меню → Контракты→ {0FC4D290-DA20-4191-AB18-5C3C6FDE565A}.png

{18FA48D5-EB2A-4A0E-A220-5E5A8E0F9B97}.png

{29EB221F-89C2-4DA0-AF98-2AC4E1FB60C4}.png

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

3.3 Постановка на мониторинг каналов связи

Для заведения сервиса типа "канал связи" необходимо перейти: Общее меню → Сервисы → {3A8414F7-BB15-4333-B47E-B0F490D4FF79}.png→ "+ Канал связи"

Далее необходимо:

image.png

Далее добавить измерения из SLA → {3FE1DC60-5AC5-4DCB-8AC4-7A5323F339A9}.pngи создать к измерению "тест". В выпадающем списке выбрать "Создать тест"

image.png

Далее предстоит настроить сам тест. Среди обязательных настроек:

{C52E27D0-8C39-466E-87EA-9D60F39081D6}.png

Далее настройки тестового трафика:

image.png

Далее сохраняем настройки сервиса и ожидаем первых данных. Данные поступят в течении 10 минут.

image.png

3.4 Постановка на мониторинг доступности приложения/услуги

Для заведения сервиса типа "Доступность услуги" необходимо перейти: Общее меню → Сервисы → {3A8414F7-BB15-4333-B47E-B0F490D4FF79}.png→ "+ Доступность услуги"

Далее необходимо:

image.png

Далее добавить измерения из SLA → {3FE1DC60-5AC5-4DCB-8AC4-7A5323F339A9}.pngи создать к измерению "тест". В выпадающем списке выбрать "Создать тест"

image.png

Далее предстоит настроить сам тест. Среди обязательных настроек:

{F19BB5E1-0FCB-43AB-9235-5770DEEF0FED}.png

{80AA2052-5594-4D2C-8C2F-64AC6E78A83C}.png

{2CE74A14-D607-4DC1-8C77-2D21D3A8B6FA}.png

{71A6114C-B196-4CED-A0EC-4A636F56BF06}.png

Сохраняем тесты и сервис. Данные пойдут в течении 10 минут.

image.png

3.4 Задачи

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

№ Тип Выполнено Комментарий
1 Создание контрагента

2 Создание пользователя

3 Задать url системы аппаратному зонду

4 Создание точки доступа

5 Прикрепить к точке доступа агент

6 Создать SLA для каналов связи

7 Создать SLA для проверки доступности ресурса

8 Создать контракт для каналов связи. Настроить формирование отчетов: ежедневно; еженедельно

9 Создать контракт для доступности услуги. Настроить формирование отчетов: ежедневно; еженедельно

10 Постановка на мониторинг канала связи, с привязкой к существующему контракту

11 Постановка на мониторинг доступности сервиса в разрезе L3, L4 и L7 тестов. Привязать к существующему контракту.

4. Постановка на мониторинг серверов под управлением ОС Linux/Windows

4. Постановка на мониторинг серверов под управлением ОС Linux/Windows

4. Постановка на мониторинг серверов под управлением ОС Linux/Windows

4.1 Общая постановка на мониторинг через системные шаблоны

Для заведения сервиса типа "Узел" необходимо перейти: Общее меню → Сервисы → {3A8414F7-BB15-4333-B47E-B0F490D4FF79}.png→ "+ Узел"

Далее необходимо:

{E821CDB8-6330-4F94-9971-7E092E33A268}.png

4.2 Добавление пользовательских метрик с использованием CS-тестов

wiProbe Custom Scenario Test в системе wiSLA — это синтетические тесты, которые имитируют деятельность пользователя. CS позволяет создавать и исполнять пользовательские скрипты, настраиваемые под конкретные задачи, что делает его незаменимым для мониторинга уникальных или нестандартных процессов в IT-инфраструктуре.
Для заведения wiProbe Custom Scenario Test необходимо:

  1. Создать тест, где прописан сам текст скрипта.
  2. Создать показатель в системе, который будет отображать метрику в системе.
  3. Добавить показатель к шаблону SLA, по которому оценивается узел. А так же указать пороговые значения, для настройки уведомлений по метрике.
  4. Добавить тест к профилю измерения, в который был включен новый показатель, в настройка "создания сервиса" для его сбора.

4.2.1 Создание теста

Далее:

image.png

image.png

image.png

image.png

{A948B61D-5C82-47D0-929E-DF9009CD4EE4}.png

Для выполнения скрипта вы должны объявить адаптер
Основным является CommandLineAdapter

Он отвечает за запуск javascript скриптов через командную строку системы. Получение экземпляра адаптера через CommandLineAdapter: getCommandLineAdapter().

Пример:
Получение информации о свободном месте на диске С Windows

var cmd = manager.getCommandLineAdapter(); 
var free_drive_c = cmd.execute('cmd /c wmic logicaldisk where "DeviceID=\'C:\'" get FreeSpace | find /V "FreeSpace"'); 
output.hdd = free_drive_c;

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

4.2.2 Создание показателя

 В предыдущем пункте был описан скрипт, которой собирает данные по свободному месту на диске с

output.hdd = free_drive_c;

Нам нужно создать показатель в системе соответствующий названию переменной после output. в данном примере потребуется создать показатель hdd

В системе учитывается регистр!
Пример: "Hdd",  "HDD", "hDD" это три разных показателя в системе.

Для этого:

{3C502A77-EE97-4D4B-A08F-DE668FA42226}.png

В модальном окне потребуется:

4.2.3 Добавление показателя в SLA

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

Для этого:

image.png

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

image.png

{D4A61963-9A20-484A-B5BE-8401604B9BF6}.png

image.png

Жмем кнопку  image.png

4.2.4 Добавление теста в сервис

image.png

image.png

Жмем кнопку  image.png

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

image.png

Примеры скриптов Custom Scenario.

Скрипт проверки статуса службы Linux:

var cmd = manager.getCommandLineAdapter();
var serviceName = "guacd.service";
var zodiacServiceStatus = cmd.execute("bash", "-c", "systemctl is-active " + serviceName + " >/dev/null 2>&1 && echo 1 || echo 0");
output.zodiacServiceStatus = zodiacServiceStatus;

Скрипт проверки размера директории Linux:

var cmd = manager.getCommandLineAdapter();
var catalogOpt = "/opt";
var catalogVar = "/var";
var valueOpt = cmd.execute("bash", "-c", "df -h " + catalogOpt + " | awk 'NR==2 {print $5}' | tr -d '%'");
var valueVar = cmd.execute("bash", "-c", "df -h " + catalogVar + " | awk 'NR==2 {print $5}' | tr -d '%'");
output.valueOptProcent = valueOpt;
output.valueVarProcent = valueVar;
logger.tryLog('Процент занятого места в каталоге OPT: ' + output.valueOptProcent);
logger.tryLog('Процент занятого места в каталоге VAR: ' + output.valueVarProcent)

Скрипт проверки работы веб-портала любого приложения, доступного по сети:

var cmd = manager.getCommandLineAdapter();
var url = "portal.example.com";
var http_port = "80";
var https_port= "443";

var portal_status = cmd.execute("bash", "-c", "curl -k -s -o /dev/null -w \"%{http_code}\" -L https://" + url + "/#/login | grep -qE \"^200\$\" && echo 1 || echo 0");
output.PORTAL_STAT = portal_status;

var portal_portcheck_http = cmd.execute("bash", "-c", "curl -s -o /dev/null -w \"%{http_code}\" http://" + url + ":" + http_port + " | grep -q \"200\\|301\" && echo 1 || echo 0");
output.PORTAL_CK_HTTP = portal_portcheck_http;

var portal_portcheck_https = cmd.execute("bash", "-c", "curl -k -s -o /dev/null -w \"%{http_code}\" -L https://" + url + ":" + https_port + " | grep -qE \"^(200|301)\$\" && echo 1 || echo 0");
output.PORTAL_CK_HTTPS = portal_portcheck_https;

var portal_downtime = cmd.execute("bash", "-c", "curl -k -o /dev/null -s -w \"%{time_total}\\n\" https://" + url + " | sed 's/,/./' | awk '{print \$1 * 1000}'");
output.PORTAL_DTIME = portal_downtime;

var portal_server_code = cmd.execute("bash", "-c", "echo \"\$(curl -s -k -w \"%{http_code}\" https://" + url + "/#/login | tail -n 1)\"");
output.PORTAL_SRV_CODE = portal_server_code;

var portal_certcheck = cmd.execute("bash", "-c", "echo \"\$(( ( \$(date -d \"\$(curl -vkI https://" + url + " 2>&1 | grep \"expire date\" | awk -F': ' '{print \$2}')\" +%s) - \$(date +%s) ) / 86400 ))\"");
output.PORTAL_CERT_CK = portal_certcheck;

4.3 Цели обучения

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

№ Тип Выполнено Комментарий
1 Создать собственный тип узала

2 Завести сервис типа "Узел"

3 Добавить пользовательскую метрику к системному шаблону и обеспечить её сбор

5. Постановка на мониторинг сетевого оборудования через SNMP-шаблон

5. Постановка на мониторинг сетевого оборудования через SNMP-шаблон

5. Постановка на мониторинг сетевого оборудования через SNMP-шаблон

5.1 Настройка SNMP-universal TEST

Одним из инструментов сбора метрик по протоколу SNMP является SNMP-universal Test.

Агентом сбора данных в данном случае является сам сервер системы. По-этому убедитесь, что на сервере установлена служба SNMP.

Для его настройки перейдем на страницах: Общее меню → {0E75C718-4244-4473-8A6E-14311A9DFEB7}.png → {0FC4D290-DA20-4191-AB18-5C3C6FDE565A}.png

Далее осуществляем настройку SNMP шаблона

image.png

Далее настройка метрик

{FBA82797-2064-40E7-96A4-B303F258FA80}.png

ВАЖНО! Необходимо использовать OID, который возвращает целочисленное значение через snmpget запрос

image.png

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

image.png

5.2 Создание SLA через SNMP-universal TEST

Следующим шагом будет создание SLA. Для этого

image.png

image.png

Далее:

image.png

image.png

 Далее жмем image.png .

5.3 Настройка агента network-device для сбору через метрик SNMP-universal TEST

Для отображения устройства, которое мы будем опрашивать через SNMP-universal TEST, на тепловой геокарте. А так же отображения доступности по ICMP. Потребуется завести агент типа "NETWORK DEVICE" в системе.

Для этого

image.png

image.png

Устройство будет в статусе "Не используется", а доступность будет определена как "Неизвестно". Статусы изменятся после поступления данных.

 Перейдем к созданию сервиса.

5.4 Настройка сервиса по отображению метрик через SNMP-universal TEST

Для этого: Общее меню → Сервисы → image.png → + "доступность услуги" 

image.png

image.png

image.png

image.png

Жмем сохранить и запускаем мониторинг!

image.png

6. Постановка на мониторинг через wiProbe Custom Scenario Test

6. Постановка на мониторинг через wiProbe Custom Scenario Test

6. Постановка на мониторинг через wiProbe Custom Scenario Test

6.0 Подготовка к мониторингу

image.png

image.png

Жмем  image.png

6.1 Настройка сервиса по сбору показателей Custom Scenario Test

Для этого: Общее меню → Сервисы → image.png → + "доступность услуги" 

Далее потребуется:

image.png

image.png

Жмем  image.png

7. Настройка топологии

7. Настройка топологии

7. Настройка топологии

Система wiSLA предоставляет инструмент для визуализации статуса сервисов мониторинга — топологию. Топология — это конструктор из сетевых элементов, который позволяет визуализировать объекты ИТ-инфраструктуры, выстраивать связи между ними и привязывать к ним результаты измерений (сервисов).

Начало:

Для создания своей топологии нужно: (Топология привязывается к контрагенту (владельцу) пользователя, под которым она заводится.)

image.png


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

Элемент Иконка
Назначение
Узел

 

{711C4F41-8495-4887-8E86-0B7A6DD81E61}.png

{41DC873F-D557-4630-AC93-D91F24F32EAE}.png Обеспечивает функционал вложенности топологии: каждому "узлу" соответствует свой «слой» топологии. На диаграмме отображается количество объектов мониторинга, закреплённых в узле, а также цветовая индикация их статуса.
Сеть

{23F51350-6A17-48AC-AC30-2DD6335F76F5}.png

image.png Обеспечивает функционал вложенности топологии: каждому "сети" соответствует свой «слой» топологии. На диаграмме отображается количество объектов мониторинга, закреплённых в узле, а также цветовая индикация их статуса.
Маршрутизатор

{7E1CE4AD-294E-4DAF-970F-3F0C9D3A9D9A}.png

 

image.png Маршрутизатор - сетевой узел, отображающий связи и агрегирующий статус мониторинга привязанных сервисов.
Коммутатор

{5DF96A97-FF8F-4F42-BDE6-A6A16A5147C2}.png

{6AB35FBF-42D3-40BF-8564-EE5BF1552F24}.png Коммутатор - сетевой узел, отображающий связи и агрегирующий статус мониторинга привязанных сервисов.
АРМ

{2046E62E-29C3-4B88-A6DE-D9657344E439}.png

{72D16179-C468-482D-95DB-ECCC0BE8F0B8}.png АРМ - узел рабочего места, отображающий сетевые связи и агрегирующий статус мониторинга привязанных сервисов.
Датчик

{1D06889E-EE27-4499-9725-71EFF68ABFA8}.png     

{F83F86B6-37C7-496B-8C04-A3D4197803EB}.png Датчик - элемент топологии, используемый для привязки и отображения результатов измерений аппаратных зондов и пользовательских сценариев мониторинга.
Кросс

{C91D6B66-C245-4032-8951-8197F0C7D598}.png

{DECC0205-DB94-4521-996C-0E7902C651E7}.png Кросс - элемент топологии, отображающий точку кабельной коммутации и служащий для привязки статусов мониторинга.
Группа объектов

{853FE9D6-C504-4273-A434-57A9A27E3C68}.png

{D92CCF96-15E9-47DB-84DE-C3AB1C191604}.png
Группа объектов - элемент топологии, представляющий собой поле для логического группирования элементов.

Добавление элементов и привязка результатов мониторинга

image.png

image.png

image.png

image.png

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

image.png

Отрисовка каналов связи

Для настройки отображения линии каналов связи, требуется между протянуть между двумя элементами топологии линию:

image.png

image.png

image.png

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

{FEAD976C-F259-4CF9-A8D7-0FE20E8ABCE3}.png

Настройка агента сканирования подсетей

1. Требования к хосту

2. Установка необходимых утилит

На целевой хост требуется установить три утилиты:

Утилита Назначение Примечание по установке
zmap получение списка IP-адресов Требуется отдельная загрузка. На Red Hat-подобных ОС — через epel-release.
arp (из пакета net-tools) сопоставление IP и MAC-адресов Обычно входит в состав дистрибутива.
nmblookup (из пакета samba4-client) получение NetBIOS-имён Обычно входит в состав дистрибутива.

Установка выполняется штатными средствами ОС (например, yum install, apt install) в соответствии с руководством администратора.

3. Настройка zmap

По умолчанию в zmap отключено сканирование локальных подсетей. Чтобы разрешить сканирование нужных подсетей:

Запуск сканирования

Выбор агента сканирования, а также задача областей сканирования выполняются в пункте «НАСТРОЙКИ». Откроется модальное окно настройки:

Также есть пункт «НАСТРОЙКИ АГЕНТА». В нём указываются IP-адрес и порт службы SSH, а также учётные данные (логин/пароль) для подключения; выбирается сетевой интерфейс хоста, с которого будет инициироваться сканирование; задаётся порт, который будет сканироваться на доступность.

image.png


image.png

Результат сканирования выводится в выпадающем списке для каждой назначенной подсети. Чтобы добавить обнаруженный элемент на топологию, нажмите значок «⊕». Затем выберите тип элемента — после этого объект будет размещён на топологии, и к нему можно будет прикрепить соответствующий сервис.

image.png


Канал гиф.gif — демонстрация настройки канала

Видео ролики по системе

Видео ролики по системе

Заведение инфраструктуры

Канал RuTUBE


Первые шаги в системе

  1. Контрагенты и пользователи
    Первый шаг к настройке системы — создание Контрагента.
    Контрагент — это ваша корпоративная рабочая область, выступающая в роли Владельца. За этой сущностью закреплены конкретные аккаунты вашей команды и объекты мониторинга.
  2. Первый сервис
    В этом ролике вы узнаете, завести на мониторинг свой первый объект. На примере Linux машины, мы расскажем, как использовать шаблоны мониторинга и настраивать сбор показателей.
  3. Мониторинг доступность сервера/сервис
    В этом ролике мы обсудим как поставить на контроль доступность элементов IT-инфраструктуры на L3, L4 и L7 уровнях.
  4. Мониторинг СУБД
    В этом ролике мы рассмотрим процесс постановки мониторинг систем управления базами данных на примере СУБД PostgreSQL.
  5. Мониторинг выполнения пользовательского сценария (скрипт-сценарий)

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


Сценарии мониторинга

  1. Узлы – windows & linux 
    В этом ролике мы разберем основные подходы к мониторингу ключевых узлов IT-инфраструктуры, включая серверы под управлением ОС Linux и Windows. Рассмотрим поэтапный процесс настройки мониторинга - от постановки систем на наблюдение до настройки контролируемых показателей и определения их пороговых значений.
  2. Мониторинг 1С:Предприятие
    Современная 1С-инфраструктура — это сложный организм, где сбои на любом уровне — от сервера до лицензии — парализуют работу компании и несут прямые финансовые потери. Сквозной мониторинг становится критическим инструментом, который обеспечивает прозрачность, предсказуемость и контроль над всей системой.
    ПАК wiSLA обеспечивает сквозной мониторинг 1С-систем, комплексно охватывая как аппаратную инфраструктуру, так и программные компоненты кластерных решений "1С:Предприятие".
  3. Автоматизация обработки аварийных инцидентов
    В данном ролике мы покажем, как функционал платформы wiSLA позволяет автоматизировать обработку аварийных инцидентов и сократить время простоя сервисов.


Видео ролики по системе

Администрирование

Канал RuTUBE

Администрирование системы wiSLA

  1. Установка
    Видео демонстрирует процесс установки wiSLA 5.2.12, включая предварительную настройку узла, запуск программы установки, первоначальная конфигурация компонентов системы. В ролике будет показана работа с установочным RUN-файлом
  2. Настройка бэкапирования
    В этом мы обсудим как пользоваться инструментами резервного копирования в системе wiSLA
  3. Селфмониторинг системы висла.  Интерпретация аппаратных метрик
    Видео объясняет, как сама система wiSLA отслеживает собственное "здоровье" — использования ресурсов сервера (CPU, память, диск, сеть и т.д.). Обсуждается, как интерпретировать эти метрики для анализа первопричин сбоев
  4. Первичная диагностика проблем
    Видео посвящено первым шагам при возникновении проблем в wiSLA: проверка работоспособности компонентов и определение директории для анализа основных лог-файлов системы. Это основа для самостоятельного устранения инцидентов

Вопросы и ответы