Практический старт — wiSLA 5

Самостоятельное практическое руководство, размещённое рядом с исходной книгой «Быстрый старт». Пошаговый маршрут: узел → тест → сервис и SLA → показатели → аналитика → уведомления. 8 страниц с примерами и снимками интерфейса. Учтено переименование «Зонды» в «Узлы» в 5.2.18; формы и иллюстрации проверены на стенде 5.2.17 (сборка 2608181235). Начните со страницы 01; если тесты уже созданы — со страницы 04. Исходная книга сохранена в прежнем виде.

01. Маршрут быстрого старта и основные понятия

Результат: один работающий сервис, его показатели и состояние, виджет в «Аналитике» и настроенная подписка на события. Если ICMP, DNS или TCP-тесты уже созданы, начинайте со страницы 04. Сервис, SLA и запуск мониторинга.

Версии. В wiSLA 5.2.18 раздел «Зонды» переименован в «Узлы». В этой главе используется название «Узлы». Иллюстрации сняты на стенде wiSLA 5.2.17, сборка 2608181235: на них сохраняются прежние названия. Остальные различия между сборками следует сверять с интерфейсом своей системы. Дата подготовки: 24.09.2026.

1.1. Как связаны объекты

Узел с агентом → тест → измерение сервиса по SLA → показатели и события → аналитика и уведомления.

Объект За что отвечает Пример
Узел Точка выполнения измерений. В рассматриваемом сценарии это машина с агентом wiProbe. Агент в офисе, откуда проверяется приложение.
Тест Как и куда отправлять запросы, какие результаты собирать. ICMP к серверу, TCP к порту, DNS-запрос.
SLA Набор измерений, показателей, порогов и правил оценки качества. Допустимые потери и задержка, условия отказа.
Сервис Контролируемая услуга; связывает SLA, узел и конкретные тесты. Доступность корпоративного портала.
Контракт Объединение сервисов для учёта, фильтрации и отчётности. Доступность приложений организации.
Аналитика Представление накопленной статистики выбранных сервисов. Виджет готовности первого сервиса.

«Узел» как объект инфраструктуры и сервис типа «Узел» - разные понятия. Для проверки доступности адреса или порта в этой главе используется сервис типа «Доступность услуги».

1.2. Что подготовить

  1. Учётную запись с правами на создание сервиса, доступом к своему владельцу, узлу, тестам и SLA. Базовый сценарий рассчитан на оператора SLA; первичную установку выполняет администратор.
  2. Один доступный программный агент wiProbe и адрес портала, с которым он должен работать.
  3. Свой целевой адрес, TCP-порт или DNS-имя. Проверьте доступность цели именно с узла измерения.
  4. Подходящий SLA либо согласованный набор показателей и порогов для нового SLA.

В примерах используется 192.0.2.10 как условный адрес. Замените его адресом своей цели. Скриншоты показывают заполнение форм; тест на этот условный адрес не запускался.

1.3. Порядок работы

  1. 02 - подключить агент и проверить узел.
  2. 03 - выбрать и создать тест, либо использовать уже созданный.
  3. 04 - собрать сервис, выбрать SLA и запустить мониторинг.
  4. 05 - проверить показатели и вывести сервис в аналитику.
  5. 06 - настроить уведомления и проверить результат.
  6. 07 - разобрать частые вопросы, включая UDP, NetFlow и OnlineDPI.
  7. 08 - выбрать следующий сценарий и найти дополнительные материалы.

Эта глава дополняет существующие страницы книги. Видеоролики, «Администрирование» и «[Обучение] Администрирование wiSLA» остаются самостоятельными материалами.

02. Подключение агента и проверка узла

Результат: агент зарегистрирован на нужном портале, узел доступен и виден вашему владельцу. Если такой узел уже есть, переходите к странице 03.

2.1. Установить и подключить агент

  1. Получите пакет агента для вашей ОС у администратора. В развёртываниях, где включена загрузка с портала, используйте «Справка» → «Загрузить агент» либо соответствующий пункт раздела «Узлы» (до 5.2.18 - «Зонды»). Список пакетов зависит от настроек сервера.
  2. На Windows запустите предоставленный установщик, задайте имя агента и параметры подключения к порталу по инструкции вашей поставки.
  3. На Linux установите пакет подходящего формата. Для DEB: sudo dpkg -i <имя_файла.deb>. Для RPM: sudo rpm -ivh <имя_файла.rpm>. Имя файла замените фактическим именем полученного пакета.
  4. Проверьте адрес сервера в конфигурации агента. Для Linux в учебных материалах приведена команда slamon-conf url 'https://wisla.example:8443'. Это пример: используйте реальный адрес и порт своего развёртывания, предоставленные администратором.
  5. Откройте «Инфраструктура» → «Узлы» и найдите агент по имени или адресу. Если агент зарегистрировался без владельца, попросите администратора назначить вашего владельца.

Не устанавливайте второй экземпляр агента только потому, что не видите первый в своей учётной записи: сначала проверьте портал, владельца и права доступа.

2.2. Проверить карточку узла

  1. Проверьте имя, адрес, состояние доступности и версию агента.
  2. Убедитесь, что узел принадлежит нужному владельцу и доступен оператору, который создаёт сервис.
  3. При необходимости назначьте точку доступа для размещения на карте и привязки к площадке.
  4. Проверьте исходящий сетевой интерфейс: в тесте понадобится интерфейс, из которого доступна цель. Loopback 127.0.0.1 подходит только для специально предусмотренного локального сценария.

2.3. Если узел не появился или недоступен

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

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

В руководстве: приложение 1 «Работа с программным агентом»; раздел 3 «Узлы. Страница раздела» и «Узлы. Страница создания узла (редактирования, просмотра)».

03. Выбор и создание тестов: ICMP, TCP, DNS, HTTP и UDP

Результат: для выбранной задачи есть тест с правильным узлом и адресом назначения. Создать тест можно в разделе «Тесты» или прямо при настройке измерения сервиса.

3.1. Какой тест выбрать

Что проверить Тест Что требуется на другой стороне
Сетевая доступность по ICMP wiProbe P-Test Хост, отвечающий на ICMP. Второй агент не нужен.
Установление TCP-соединения с портом wiProbe L4-TCP-Test TCP-служба на целевом порту. Второй агент не нужен.
Разрешение DNS-имени wiProbe DNS DNS-сервер, доступный узлу измерения.
Ответ веб-приложения wiProbe L7-HTTP-Test Целевой HTTP(S)-ресурс.
Потери, задержка, джиттер по UDP между участниками TWAMP / wiProbe U-Test Совместимый отвечающий участник. Произвольный хост без поддержки протокола не подходит.
Прикладной сценарий wiProbe Custom Scenario Test Поддерживаемая служба и сценарий с проверкой ожидаемого ответа.

В старой странице «Тесты» TCP-проверка может называться «L7-TCP-Test». На проверенном стенде имя в списке типов - wiProbe L4-TCP-Test. Доступные типы зависят от выбранного узла, вида сервиса и конфигурации системы.

3.2. Пример ICMP

  1. Откройте «Инфраструктура» → «Тесты» и создание теста. Другой путь: в сервисе выберите измерение SLA, нажмите «+» в столбце «Тесты» → «Создать тест».
  2. Задайте понятное имя, например «Старт - ICMP»; выберите тип wiProbe P-Test.
  3. Укажите исполняющий узел, если он не унаследован из сервиса. Выберите его исходящий интерфейс и задайте реальный адрес назначения.
  4. Заполните обязательные поля со звёздочкой, включая пропускную способность, если её требует форма. Значение должно соответствовать вашему каналу. Проверьте число, интервал и размер тестовых пакетов; для первого примера сохраняйте штатные значения, если они подходят задаче.
  5. Сохраните тест. Для законченного мониторинга выполните привязку к сервису и запуск на странице 04. Отдельная активация теста не заменяет настройку сервиса.

Форма создания wiProbe P-Test

Рисунок 1. Форма wiProbe P-Test на wiSLA 5.2.17. Адрес 192.0.2.10 условный; пропускную способность требуется заполнить перед сохранением.

3.3. TCP, DNS и HTTP

TCP: выберите L4-TCP-Test, задайте целевой адрес и порт (например, 443 для своей HTTPS-службы), затем доступные параметры попыток и тайм-аута. Успешное TCP-соединение подтверждает доступность порта; работоспособность самой страницы проверяйте HTTP-тестом.

DNS: выберите wiProbe DNS, укажите проверяемое имя, DNS-сервер и остальные обязательные параметры формы. Успешное разрешение имени и доступность приложения - отдельные проверки.

HTTP: выберите L7-HTTP-Test, укажите URL, а при необходимости параметры доступа и проверки ответа. Критерий успеха должен соответствовать приложению, включая ожидаемые перенаправления.

3.4. Почему нельзя просто переключить TCP на UDP

В проверенных материалах не подтверждён универсальный тест вида «любой хост + любой порт + TCP/UDP», в котором UDP даёт однозначный ответ о доступности без участия удалённой стороны. У UDP нет установления соединения: отсутствие ответа само по себе не доказывает ни доступность, ни недоступность службы.

Для качества канала используйте TWAMP или U-Test с совместимым ответчиком. Это два участника измерения, но не обязательно два одинаковых аппаратных устройства wiProbe. Для доступности конкретной UDP-службы нужен её прикладной запрос и проверка ответа; например, задача проверки DNS решается DNS-тестом. Поддержку произвольного UDP-сценария в Custom Scenario следует отдельно подтвердить для своей версии агента и доступных адаптеров.

Проверка результата: в карточке теста верны тип, узел, интерфейс и цель; ошибок обязательных полей нет.

В руководстве: раздел 3 «Тесты. Страница создания теста (редактирования, просмотра)»; приложения 2 «Соответствие показателей (метрик) и тестов» и 4 «Сервисы и тесты wiSLA». Каталог типов дополнен по странице «Тесты» книги «Функции wiSLA».

04. Сервис, SLA и запуск мониторинга

Результат: существующие или новые тесты включены в сервис, измерения оценены по SLA, мониторинг запущен. Контракт можно добавить для группировки и отчётности; в форме «Доступность услуги» он не является обязательным условием первого запуска.

4.1. Выбрать SLA

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

Названия SLA и измерений не гарантируют совместимость: тест должен выдавать показатели, используемые в измерении. Например, для TCP-проверки нужен соответствующий набор показателей TCP, а не произвольная строка с названием «TCP».

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

4.2. Если подходящего SLA нет

  1. Откройте «Инфраструктура» → «SLA» → создание SLA; введите название.
  2. На вкладке «Мониторинг» добавьте измерения, например ICMP, DNS и TCP. При наличии подходящего образца используйте копирование измерений из другого SLA.
  3. Для каждого измерения добавьте показатели, которые выдаёт выбранный тест; проверьте единицы. Настройте условия деградации и отказа либо явно выберите режим без порога, если нужна только статистика по этому показателю.
  4. На вкладке «Неисправности» проверьте задержки открытия, закрытия и изменения критичности. Они влияют на момент появления события.
  5. Проверьте исключения и период мониторинга. Сохраните SLA.

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

4.3. Создать сервис из уже готовых тестов

  1. Откройте «Инфраструктура» → «Сервисы» → «Создать сервис» → «Доступность услуги».
  2. Задайте название, например «Старт - доступность портала». Проверьте владельца.
  3. Выберите подходящий SLA.
  4. В блоке «Узлы» выберите точку мониторинга - узел, на котором выполняются ваши тесты. В 5.2.17 этот блок называется «Зонды».
  5. Нажмите «Добавить измерение из SLA». Выберите, например, ICMP.
  6. В строке измерения, в столбце «Тесты», нажмите «+» → «Выбрать тест». Найдите свой готовый ICMP-тест. Если его ещё нет, используйте «Создать тест».
  7. Повторите привязку для DNS и TCP, если эти измерения предусмотрены в вашем SLA. Набор строк определяется выбранным SLA.
  8. При необходимости выберите контракт. Для первого отдельного сервиса этот шаг можно отложить.
  9. Сохраните сервис. Если форма остаётся черновиком, прочитайте список недостающих полей и завершите привязки.
  10. В списке сервисов откройте меню действий своего сервиса и выполните «Запустить», если мониторинг ещё не запущен. Проверьте состояние сервиса и входящих тестов.

Привязка ICMP-теста к измерению SLA в сервисе

Рисунок 2. Измерение ICMP и выбранный существующий тест в форме сервиса, wiSLA 5.2.17. Пример заполнения, без сохранения учебного сервиса на стенде.

4.4. Если нужного теста нет в списке

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

4.5. Проверка результата

Откройте показатели качества сервиса и дождитесь данных. Руководство для сценария веб-приложения рекомендует проверять статус не ранее чем через 5 минут; фактическое время зависит от периода измерений и обработки. Сразу после запуска «Не определено» ещё не означает отказ цели.

В руководстве: раздел 2 «Мониторинг доступности веб-приложения» и «Создание нового SLA»; раздел 3 «Сервисы. Страница создания сервиса (редактирование) типа “Доступность услуги”».

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

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

5.1. Сначала проверить источник данных

  1. В «Сервисах» откройте страницу текущих показателей качества своего сервиса.
  2. Выберите период, включающий время после запуска мониторинга. Для первого просмотра используйте небольшой интервал, чтобы свежие данные были заметны.
  3. Проверьте, что отображаются нужные измерения, у показателей есть значения и новые точки на графике.
  4. Сравните значения с порогами SLA. Если состояние отличается от ожидаемого, проверьте единицы измерения, условия отказа/деградации и задержки регистрации.

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

5.2. Быстрый просмотр в «Аналитике»

  1. Откройте «Мониторинг» → «Аналитика».
  2. Выберите период: день, неделя, месяц или произвольный интервал.
  3. В параметрах поиска выберите поиск по сервисам, введите имя и выберите конкретный сервис из списка. Проверьте дополнительные фильтры по контрактам и тегам.
  4. Просмотрите стандартные виджеты: готовность, аварии, время в отказе и деградации. Учитывайте, что они показывают накопленную статистику, а не только текущее мгновенное состояние.

5.3. Свой виджет для первого сервиса

  1. При необходимости создайте отдельную вкладку кнопкой «+» в строке вкладок. Двойным щелчком по названию задайте понятное имя.
  2. Нажмите «Добавить виджет».
  3. На шаге «Основные настройки» выберите тип «Готовность», задайте название «Старт - готовность» и период обновления. На стенде начальное значение - 5 минут.
  4. Нажмите «Далее». Для этого типа на проверенном стенде следующий шаг - «Выбор сервисов». У других типов может быть дополнительный шаг с правилом.
  5. Выберите режим «По списку», найдите и отметьте свой сервис. Нажмите «Добавить».
  6. Проверьте период панели и фильтры. Дождитесь обновления виджета и сравните его с данными сервиса за тот же интервал.

Основные настройки виджета готовности

Рисунок 3. Мастер добавления виджета «Готовность», wiSLA 5.2.17. После «Далее» выбираются сервисы.

5.4. Что означает пустой виджет

Проверьте четыре условия: данные уже поступают в сервис; сервис включён в выборку виджета; выбранный период содержит эти данные; фильтры панели не исключают сервис. Для отчёта по контракту дополнительно нужна корректная связь сервиса с контрактом.

В руководстве: раздел 2 «Анализ статистики, настройка панелей аналитики, добавление виджетов»; раздел 3 «Аналитика. Страница создания виджета» и «Сервисы. Страница просмотра текущих показателей качества».

06. Уведомления и проверка результата

Результат: создана активная подписка на события выбранного сервиса; понятны условия появления события и канал доставки.

6.1. Подготовить канал

Для почты должны быть настроены системная отправка и адрес пользователя. Для Telegram используется подключённый к вашей системе бот и wiSLA ID из профиля. Push - уведомления портала. Доступность каналов зависит от настроек вашей системы.

6.2. Настроить именованную подписку

  1. Откройте профиль пользователя → вкладку «Уведомления». При наличии прав это также доступно через «Администрирование» → «Пользователи» → нужная учётная запись.
  2. В блоке «Подписки на уведомления» нажмите «Добавить подписку».
  3. На шаге «Критерии подписки» выберите тип «Сервис» и отметьте свой первый сервис.
  4. На шаге «Типы уведомлений» в блоке паспортов неисправностей выберите нужные уровни (например, отказ и деградация) и события жизненного цикла (например, открытие и закрытие).
  5. На шаге «Способы получения» выберите канал, задайте название и проверьте флажок «Подписка активна».
  6. Просмотрите список сервисов в подписке, затем сохраните. Убедитесь, что подписка отображается активной и содержит нужный сервис.

Критерии объединяются по правилу «ИЛИ». Если дополнительно выбрать контракт или владельца, подписка может охватить больше сервисов, чем один учебный. Для первого примера достаточно одного явно выбранного сервиса.

Уведомления об отчётах SLA и доступности узлов задаются отдельно в блоке «Системные уведомления». Они не входят в мастер подписки на сервисные события. Набор типов событий зависит от канала; например, ППР, действия по событиям и провалы нагрузочных тестов в описанном руководством сценарии доступны Email и Push, но не Telegram.

6.3. Проверить цепочку «измерение → событие → уведомление»

  1. Убедитесь, что сервис получает показатели и его SLA содержит условия регистрации неисправности.
  2. На отдельной учебной цели согласованно вызовите короткую недоступность проверяемой службы. Не отключайте рабочий сервис ради проверки инструкции.
  3. Дождитесь интервала измерения и задержки открытия, заданной в SLA. Откройте «Мониторинг» → «События» и найдите паспорт неисправности своего сервиса.
  4. Проверьте уведомление на выбранном канале, затем восстановите учебную службу.
  5. Дождитесь закрытия события с учётом задержки SLA и проверьте уведомление о восстановлении, если оно включено в подписке.

Эта проверка описывает действия пользователя после настройки. При подготовке главы авария на стенде не создавалась, уведомления не рассылались.

6.4. Критерии завершения быстрого старта

В руководстве: раздел 2 «Настройка уведомлений» и «Анализ событий мониторинга»; раздел 3 «Пользователи. Страница создания пользователя (редактирования, просмотра)». Автоматические сценарии реагирования описаны отдельно в пункте «Действия по событиям».

07. Частые вопросы: два узла, UDP, NetFlow и OnlineDPI

7.1. Можно ли всё проверить одним узлом?

Одного узла с программным агентом достаточно для ICMP, TCP, DNS и HTTP-проверок удалённой службы. Агент на целевой машине при этом не нужен: цель отвечает своим сетевым стеком или приложением.

Если выбранный тест требует второго участника, пропускать его нельзя. Для TWAMP нужен совместимый ответчик, для U-Test - поддерживаемая удалённая сторона. Выбор зависит от режима и совместимости оборудования. Для односторонних временных характеристик отдельно проверяются требования к синхронизации часов.

7.2. Нужна проверка «хост + порт + TCP или UDP»

TCP-порт проверяется L4-TCP-Test. Для UDP сначала сформулируйте задачу: качество канала между двумя участниками или ответ определённой службы. В первом случае рассматривайте TWAMP/U-Test; во втором - прикладной тест с ожидаемым ответом. Одного выбора UDP и номера порта недостаточно для достоверного заключения о работоспособности произвольной службы.

7.3. Что делает NetFlow и какой узел нужен?

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

Схема: маршрутизатор или программный сенсор → экспорт потоков → коллектор → тест NetFlow → статистика сервиса.

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

  1. Определите, какое оборудование или сенсор видит нужный трафик и может его экспортировать.
  2. Согласуйте с администратором версию NetFlow, адрес и порт коллектора и проверьте поступление потоков.
  3. Откройте редактирование нужного сервиса, вкладку «Статистика», выберите или создайте тест NetFlow в соответствии с настройкой коллектора.
  4. Сохраните связь и проверьте статистику потребления трафика за период, когда потоковые записи уже поступали.

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

7.4. Что делает OnlineDPI и какой узел нужен?

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

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

Для начала зафиксируйте задачу: какие приложения или классы трафика нужно видеть, где проходит трафик, каков объём и какое оборудование уже есть. Затем подбирайте поддерживаемую схему подключения и профиль анализа. Не обещайте расшифровку HTTPS, чтение любого содержимого или универсальную блокировку приложений только на основании названия DPI.

7.5. Тест создан. Почему мониторинга ещё нет?

Проверьте привязку теста к измерению сервиса и запуск сервиса. Сам факт сохранения или активации теста не означает, что настроены оценка по SLA, аналитика и уведомления. Пошаговая привязка - страница 04.

7.6. Таблица быстрой диагностики

Симптом Что проверить первым
Узел не виден Портал подключения агента, владелец, права и фильтры.
Теста нет в выборе сервиса Узел, владелец, архив, тип и совместимость с измерением SLA.
Сервис остаётся черновиком Подсказку формы: название, SLA, узел, измерения и назначенные тесты.
После запуска нет значений Доступность агента, статус теста, интерфейс, цель, период и время поступления первых данных.
Неожиданный отказ/деградация Фактические значения, единицы и пороги SLA, условия и задержки регистрации.
Сервис есть, виджет пуст Выборку виджета, период, поиск и фильтры панели.
Есть событие, нет уведомления Активность подписки, критерии, тип/уровень события, канал и адрес доставки.
NetFlow не показывает трафик Видимость трафика сенсором, экспорт, коллектор, связь теста с сервисом и период.

В руководстве: раздел 2 «Постановка на мониторинг пользовательского трафика (Netflow)»; раздел 3 «Сервисы. Страница просмотра статистики потребления трафика»; книга «Функции wiSLA», страница «Тесты», пункты wiProbe OnlineDPI, Netflow, TWAMP и U-Test. Подготовка сенсора - в руководстве администратора, пункт 1.2 «Подготовка сенсора NetFlow».

08. Следующие сценарии и существующие материалы книги

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

8.1. Куда идти дальше

Задача Следующий сценарий
ОС, сервер или виртуальная машина Сервис типа «Узел» и подходящий шаблон; пункт руководства «Постановка на мониторинг сервера, виртуальной машины, СУБД».
Сетевое оборудование SNMP и соответствующий шаблон/тест; пункт «Постановка на мониторинг сетевого оборудования по SNMP».
Качество канала Сервис «Канал связи», поддерживаемые участники и набор измерений; пункт «Заведение сервиса типа “Канал связи”».
Прикладная операция Custom Scenario и поддерживаемые адаптеры; пункты о пользовательских метриках и шаблонах Custom Scenario.
Телефония Пункт «Постановка на мониторинг SIP-сервера».
Реальный трафик Страница 07 этой главы, затем специализированные материалы NetFlow/OnlineDPI.
Массовая настройка «Групповое заведение сервисов», шаблоны и клонирование.

8.2. Что уже есть в книге «Быстрый старт»

«Заведение инфраструктуры». Ролики о контрагентах и пользователях, первом сервисе, доступности сервера, PostgreSQL, мониторинге Windows/Linux, 1С и автоматизации инцидентов. Это демонстрации, к которым удобно обращаться после соответствующего шага практического маршрута.

«Администрирование». Ролики об установке, резервном копировании, самомониторинге и диагностике. Видео установки относится к 5.2.12; применимость команд и требований к текущей версии нужно проверять отдельно.

«[Обучение] Администрирование wiSLA». Архитектура, развёртывание, агенты, владельцы и роли, учебные задания по серверам, СУБД, SNMP, каналам и приложениям. Материал используется как расширенный курс после первого результата.

8.3. Как интегрирована страница «Тесты»

Из каталога книги «Функции wiSLA» в страницы 03 и 07 включены выбор типа теста, требования к участникам и ограничения применения. Для пошаговых действий использованы текущие разделы руководства пользователя и доступные формы стенда. Старый каталог сохранён; его названия не подменяют актуальные подписи интерфейса.

Особые сценарии требуют своих условий: Cisco IP SLA, L2 и Y.1731 - совместимых участников; SNMP - доступности и параметров опроса; Outer - внешнего источника результатов. Agent DC создаётся в соответствующих сценариях мониторинга узлов и не рассматривается как обычный ручной тест для произвольного адреса.

8.4. Что осталось дополнить в исходных материалах

8.5. Основа и границы проверки

Глава подготовлена по книге «Быстрый старт», странице «Тесты» книги «Функции wiSLA», руководству пользователя wiSLA 5 и интерфейсу стенда 5.2.17. Переименование «Зонды» → «Узлы» учтено для 5.2.18. Проверены формы создания сервиса, привязка существующего теста, форма P-Test и мастер виджета. Учебный сервис и виджет на рабочем стенде не сохранялись; сквозная проверка с созданием аварии и доставкой уведомлений не выполнялась.

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