Быстрый старт 1. О системе 1. О системе Установка системы представляет собой пакетную установку на серверах под управлением ОС Linux. Система поддерживает работу на Debian, Ubuntu, Astra Linux, RedOS, CentOS. Архитектура системы базируется на open source продуктах: Kafka / Redpanda выступают в качестве брокера сообщений. Все сырые метрики сначала поступают сюда, что обеспечивает буферизацию и устойчивость данных перед дальнейшей обработкой. NoSQL База данных HBase используется хранения сырых метрик. Реляционная БД PostgreSQL служит для хранения конфигурации, статусов объектов мониторинга, паспортов неисправностей и другой структурированной оперативной информации. Сервер приложений WildFly — это основной вычислительный узел, на котором работают бизнес-правила, логика обработки событий и веб-интерфейс. В качестве балансировки нагрузки и прокси (в случае если между сервером брокера и объектом нет прямой связанности, агент может слать на прокси-сервер агрегации данных, с который далее данные поступают на Kafka ) используются сервера с установленным агрегатором wiProbe . Управление компонентами системы осуществляется через программу установки. Для этого потребуется авторизоваться на сервере системы под УЗ по умолчанию wisla. sudo su - wisla И запустить run файл ./example.run Далее будут доступны пункты меню: Config update - позволяет внести изменения в конфигурации подсистем и настройки доступность портала Status - в данном меню можно посмотреть текущий статус компонентов системы Maintenance  - меню перезапуска служб Log viewer   - меню просмотра лог-журналов  Backup - меню резервного копирования Uninstall - удаление программы 1.1 Переключение в изолированный режим В меню « Config Update » перейти на вкладку « Resources Configuration » Параметр « Local geo services » перевести в true – для закрытого контура. И перезапустить сервер приложений. 1.2 Настройка уведомлений и авторизации по AD Для настройки e-mail уведомлений вам потребуется: Включить функцию в программе установке. В режиме «Config Update» перейти на вкладку «wiSLA Notification Configuration». И задать параметру wiSLA notification enabled значение "true" Включить уведомления на портале и настроить данные подключения к SMTP серверу (Настройка под профилем Admin ) 1.2 Задачи № Тип Выполнено Комментарий 1 Установить систему 2 Перевести систему в изолированный режим 3 Включить возможность нотификации в программе установки 2. Сбор данных 2. Сбор данных В качестве источников данных в системе используются программные агенты и аппаратные зонды WPE-108, WPE-110, WPE-114.  Агент — это легковесное программное обеспечение, которое устанавливается на узлы инфраструктуры и осуществляет сбор метрик с устройств. Зонды представляют из себя самостоятельное сетевое устройство – микрокомпьютер на базе  Linux с установленным агентом сбора данных. Однопортовый зонд 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 А протокол и соответствующй порт должен совпадать из настроек сервера приложений wiSLA. Актуальные порты можно проверить компандой: cat /opt/wisla5/wildfly/current/standalone/configuration/standalone.xml | grep jboss.htt Пример вывода: Настройка и обновление зонда выполняются через 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.log 1,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.jar 1 /usr/local/bin/ Расположение phantomjs 1 – Задания для планировщика cron /etc/cron.d/ Журнал FTP-обновления /var/log/socklog/main/current Метрики, частота сбора данных задаются агентом с сервера управления , через  web -интерфейс системы – портал оператора. Принято говорить, что зонд выполняет тесты – задания по сбору метрик. В системе присутствуют готовые «из коробки» шаблоны для мониторинга: U-test/ TWAMP (L3 –  каналы связи ) L2-test/ Y.1731 (L2 – каналы связи). ICMP  проверки доступности ресурсов L4 – TCP L7 – HTTP И другие, с полным списком можно ознакомиться в руководстве администратора. Помимо стандартных «коробочных» тестов зонд может выполнять пользовательские сценарии -    wiProbe Custom Scenario Test. В качестве входного параметра для теста задаётся скрипт на языке javascript. Скрипт может использовать один или несколько адаптеров. В скрипте доступна переменная manager класса AdapterManager, позволяющая получить экземпляр любого адаптера. По завершению скрипта   проверяется переменная result, значение true считается признаком успешного выполнения, и наоборот. Скрипт может в явном виде задавать значение этой переменной, либо использовать значение по умолчанию. По умолчанию, если выполнение скрипта происходит без выброса исключения, то result устанавливается в true, а при наличии исключения - в false. Вот основные из них:   HttpAdapter - позволяет отправлять http запросы и анализировать ответы. SmtpAdapter - позволяет отправлять письма по  SMTP. JdbcAdapter - позволяет подключаться к базе данных и выполнять запросы. LdapAdapter - позволяет подключаться к LDAP серверу и выполнять поиск записи. WebAdapter - позволяет имитировать действия пользователя в браузере. Тесты Тесты выполняют сбор показателей для мониторинга. Тип теста выбирают по задаче и возможностям зонда или программного агента. Создать тест можно на странице «Тесты» или при создании сервиса. Ниже тесты сгруппированы по назначению; некоторые используются в нескольких сценариях. Канальные Тесты для оценки качества каналов связи, потерь, задержек и джиттера, а также анализа загрузки и трафика. Cisco IP SLA — измерение качественных показателей сети с использованием двух зондов. Возможные комбинации: Cisco — Cisco, Cisco — wiProbe. TWAMP — измерение качества сети устройствами wiProbe по протоколу TWAMP (RFC 5357) посредством последовательности UDP-пакетов. Измеряет потери, одностороннюю и круговую задержку, односторонний и круговой джиттер, пакеты вне очереди и повторы пакетов. Требуется отправитель и ответная сторона с поддержкой TWAMP. wiProbe U-Test — отправка последовательности UDP-пакетов заданного размера с использованием двух зондов или программных агентов. Отправитель — wiProbe; возможные комбинации: wiProbe — wiProbe, wiProbe — Cisco, wiProbe — Network Device. Измеряет односторонние и круговые потери, задержки, джиттер, пакеты вне очереди, круговые повторы и пакеты с ошибками. Для получения односторонних показателей на wiProbe необходима точная NTP-синхронизация времени. wiProbe L2-Test — измерение качества передачи данных на канальном уровне между двумя wiProbe. Измеряет потери, одностороннюю и круговую задержку кадров, односторонний и круговой джиттер. Используется с сервисами «Канал связи». wiProbe Y.1731 — мониторинг производительности: потери и круговая задержка кадров. Использует программные агенты или аппаратные зонды wiProbe; ответной стороной может быть оборудование с поддержкой Y.1731. При использовании двух wiProbe и качественной NTP-синхронизации доступна односторонняя задержка кадров. wiProbe P-Test (ICMP) — отправка последовательности ICMP-пакетов. Измеряет круговые потери, задержку и джиттер. Используется с сервисами «Канал связи» и «Доступность услуги»; также описан в разделе «Доступность». Нагрузочный тест wiProbe — создаётся автоматически при запуске со страницы просмотра текущих показателей. SNMP Utilization test — получение данных о загрузке канала: текущая загрузка за 5 минут и коэффициент загрузки. Не использует созданные зонды: настройки подключения к оборудованию задаются непосредственно в тесте. wiProbe OnlineDPI — сбор статистики пользовательского трафика и управление трафиком, проходящим через зонд. Требует определённых моделей аппаратных зондов wiProbe с несколькими портами. Netflow — сбор статистики пользовательского трафика, в том числе с нескольких сенсоров. Требуется добавить в систему коллектор Netflow 127.0.0.1, настроить сенсоры и правило фильтрации трафика в тесте. Это сбор через коллектор и сенсоры, а не обычная активная проверка агентом. Доступность Проверки ресурсов и приложений. Для перечисленных тестов wiProbe достаточно одного зонда или программного агента. wiProbe P-Test (ICMP) — проверка ресурса последовательностью ICMP-пакетов. Измеряет круговые потери пакетов, круговую задержку и круговой джиттер. Работает с сервисами «Доступность услуги» и «Канал связи». wiProbe DNS — проверка разрешения имени узла через заданный DNS-сервер. Измеряет время разрешения имени, круговые потери пакетов, отклик и круговой джиттер. wiProbe L7-HTTP-Test — проверка доступности ресурса по HTTP или HTTPS и времени прохождения запроса. Измеряет потери, отклик и круговой джиттер. Используется с сервисами «Доступность услуги». wiProbe L7-TCP-Test — проверка доступности портов приложения по TCP. Измеряет потери, отклик и круговой джиттер. Название приведено как в исходной странице; в «Быстром старте» TCP-проверка обозначена как L4-TCP-Test. wiProbe Custom Scenario — выполнение пользовательского JavaScript-сценария на платформе RhinoJS. Возвращает результат, время выполнения и пользовательские показатели. Позволяет проверять базы данных, авторизацию на FTP, подключение и поиск в LDAP, отправку писем по SMTP, почтовые и Samba-серверы, Health- и SOAP-сценарии, WEB-страницы и другие действия. Подключается к сервисам «Доступность услуги». Также применим для задач DC. Outer — подключение стороннего теста с использованием идентификаторов внешней системы. Это интеграционный тип теста; он не означает выполнение проверки непосредственно агентом wiProbe. DC Сбор показателей узлов и инфраструктуры дата-центра. wiProbe Agent DC — сбор данных по шаблонам настроек, выбираемым при создании сервиса типа «Узел». Это внутренний тест wiSLA: он не отображается в разделе «Тесты», фильтрах и поиске и недоступен в форме создания нового теста. Используется только в сервисах «Узел». Запускается и останавливается автоматически со страницы настройки узла. SNMP Universal Test — универсальный сбор показателей по SNMP. Позволяет выбрать показатели типа «Пользовательский» или «Системный» и задать OID, по которому данные будут собираться с указанного IP-адреса. Применим к сетевому оборудованию и другим объектам с поддержкой SNMP. wiProbe Custom Scenario — пользовательские проверки баз данных, служб и приложений с возвратом собственных показателей. Возможности и требования приведены в разделе «Доступность». Статусы и управление тестами Активный — участвует в измерениях. Неактивный — не участвует в измерениях. Архивный — скрыт из общего списка. В списке доступны поиск, фильтры по статусу, типу и тегам, сортировка и управление тегами. Возможные действия: создание, запуск, остановка, редактирование, создание на основе выбранного теста, архивация, удаление и просмотр истории изменений. Запуск и остановка происходят автоматически при запуске и остановке связанного сервиса или контракта. При необходимости тест можно запустить или остановить вручную на странице его редактирования. Тесты, созданные «Оператором SLA», недоступны для редактирования и выполнения действий пользователю с ролью «Системный Администратор». Право редактирования можно ограничить владельцем. Архивировать можно только неактивный тест, не связанный с объектами инфраструктуры. Удаление необратимо и доступно только для архивного теста. Изменения настроек необходимо сохранять кнопкой «Сохранить». Создание теста Укажите название теста и выберите тип — это обязательные поля. При необходимости добавьте метки. После выбора типа появятся соответствующие параметры. Заполните настройки выбранного типа. Обычно это зонд или пара зондов, пропускная способность, интерфейс отправителя, адрес получателя, настройки пакетов и идентификатор теста. Зонды фильтруются по возможности использования с данным типом теста. В исходном руководстве все доступные поля настроек указаны как обязательные. Для отдельных тестов есть дополнительные окна настройки, например выбор шаблона Custom Scenario. Нажмите «Сохранить». Система предложит запустить тест. Предварительный запуск не всегда необходим: для полноценного мониторинга требуется настроить связанный сервис. Для тестов wiProbe предварительный запуск может ускорить получение результатов после активации сервиса или контракта. Следующий этап — настройка SLA и привязка теста к сервису. Он описан в главе «3. Работа с порталом» . Источник: «Тесты» в книге «Функции wiSLA» . 3. Работа с порталом 3. Работа с порталом 3.1 Создание контрагента и пользователя Первый шаг к настройке системы — создание Контрагента. Контрагент — это ваша корпоративная рабочая область, выступающая в роли Владельца. За этой сущностью закреплены конкретные аккаунты вашей команды и объекты мониторинга. Она фундаментально разграничивает доступ, обеспечивая, чтобы каждая группа работала в рамках своего персонального пространства в системе. Контрагенту можно задать роли, которые будут учитываться при формировании отчётов SLA. Для этого авторизуемся на портале под системной учетной записью "Admin" (пароль по умолчанию Admin@123). Далее создать пользователей в системе. У пользователя есть роли, которые обуславливают, возможности и доступы пользователя ко сущностям системы, а также администрированию. Завести контрагента. Общее меню →  Контрагенты →   . И присвойте роли "Провайдер SLA" и "Провайдер сервиса". Завести пользователя с ролью "оператор SLA".  Общее меню →  Пользователи →   . Привязать его к контрагенту. Работы по заведению инфраструктуры мы будем вести под пользователем с ролью "Оператор SLA". Не рекомендуются работы по настройке инфраструктуры под пользователем с привилегированными правами. 3.2 Создании точки доступа Точка доступа служит гео 3.2 Подготовка инфраструктуры к мониторингу 3.2.1 Подготовка зонда/агента к работе В системе мониторинга используется термин сервис. Сервис - это любой объект мониторинга, с которого можно получить данные о его состоянии. Это может быть физический сервер, виртуальная машина, база данных, канала связи и т.д. Для того что бы поставить объект на мониторинг потребуется: Настроить отправку данных с аппаратных зондов на сервер. Для этого необходимо командой задать и задать url сервера в формате "https://yarus.ru:8443" в терминале зонда. Зонд будет отображаться на странице "зонды" в  статусе "На складе". slamon-conf url 'https://yarus.ru:8443' Далее необходимо будет создать точку доступа "Владельца" агенту, для закрепления его за "Контрагентом" и привязать его к точке доступа (или создать новую) для отображения объекта на тепловой карте сервисов. Теперь зонд можно использовать в измерениях. 3.2.2 Настройка SLA К каждому сервису мониторинга прикрепляются SLA (Соглашения об уровне сервиса). В SLA четко прописываются пороговые значения для ключевых метрик.  Для создания SLA необходимо перейти: Общее меню →  SLA →   Для каналов связи выбрать шаблон "SLA премиум" → При необходимости можно поправить пороги и переименовать измерения. Для доступности услуг советуем за шаблон выбрать " SLA IT стандартный"  → При необходимости добавить измерение "ICMP" через кнопку выбрать в списке показатели: Круговая зад ержка Круговой джиттер Круговые потери пакетов Назовём измерение, укажем метрикам пороговые значения и сохраним SLA. 3.2.3 Создание контрактов Объекты мониторинга — сервисы — группируются в системе в логические группы (контракты). На основе контрактов формируются SLA-отчёты, которые рассчитывают доступность сервиса для пользователей, исходя из пороговых значений метрик, заданных в SLA. Для создания контракта необходимо перейти: Общее меню →  Контракты →   Указать название Прикрепить шаблоны SLA. Выберем "ежедневный" и "еженедельный" Созданный контракт можно использовать при заведении сервисов на мониторинг. 3.3 Постановка на мониторинг каналов связи Для заведения сервиса типа " канал связи " н еобходимо перейти: Общее меню → Сервисы → → " + Канал связи" Далее необходимо: Назвать сервис . Выбрать SLA , из созданного вами. Выбрать контракт , для автоматического формирования отчетов, по выбранным шаблонам. Указать зонд в точке мониторинга - инициатор измерений Указать зонд в удалённой точке - рефлектор трафика Далее добавить измерения из SLA →  и создать к измерению " тест ". В выпадающем списке выбрать " Создать тест " Далее предстоит настроить сам тест. Среди обязательных настроек: Название Тип теста - для мониторинга каналов используются wiProbe U-Test или TWAMP L3 тесты: wiProbe U-Test и TWAMP L2 тесты: wiProbe L2-Test и Y.1731 Далее настройки тестового трафика: Пропускная способность - номинальная пропускная спобоность направления, от заданного тут параметра будут отталкиваться нагрузочные тесты Исходящий интерфейс и интерфейс назначения  — это интерфейсы устройств, между которыми осуществляется взаимодействие. Порт - порт удалённого зонда, куда будет направляться трафик. По умолчанию 8787 Тестовая нагрузка - количество, интервал и размер отправляемых тестовых пакетов. Далее сохраняем настройки сервиса и ожидаем первых данных. Данные поступят в течении 10 минут. 3.4 Постановка на мониторинг доступности приложения/услуги Для заведения сервиса типа " Доступность услуги " н еобходимо перейти: Общее меню → Сервисы → → " + Доступность услуги" Далее необходимо: Назвать сервис . Выбрать SLA , из созданного вами. Выбрать контракт , для автоматического формирования отчетов, по выбранным шаблонам. Указать зонд в точке мониторинга - инициатор измерений Далее добавить измерения из SLA →  и создать к измерению " тест ". В выпадающем списке выбрать " Создать тест " Далее предстоит настроить сам тест. Среди обязательных настроек: Название Тип теста - для мониторинга доступности на разных уровнях используются используются следующие тесты L3 тесты: ICMP  - пинг ресурса, указываются: Пропускная способность направления Исходящий интерфейс Адрес назначения Тестовая нагрузка L4 тесты: L4-TCP-Test  - проверка доступности порта ресурса, указываются: Исходящий интерфейс Адрес назначения Интервал отправки L7 тесты: L7-HTTP-Test - проверка HTTP доступности ресурса wget запросами, указываются: исходящий интерфейс адрес назначения Количество тестовых пакетов в измерении Интервал формирования измерений Сохраняем тесты и сервис. Данные пойдут в течении 10 минут. 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.1 Общая постановка на мониторинг через системные шаблоны Для заведения сервиса типа " Узел " н еобходимо перейти: Общее меню → Сервисы → → " + Узел" Далее необходимо: Назвать сервис . Выбрать Тип узла , из готовых, либо создать свой. Выбрав пункт "Создать тип узла" вам будет открыто модальное окно создания собственного типа узла. Можно создать на основе системных шаблонов: Linux-сервер, Windows-сервер, PostgreSQL и т.д. В таком случае будут автоматически созданы шаблоны под ваш контрагент. Указать зонд - агент мониторинга Следующий шаг настройка измерений и метрик из шаблона, жмем кнопку и приступаем к настройке измерений. В системе есть возможность редактирования системных шаблонов, включая/выключая профили измерений/метрик.  Есть метрики, которые не требуют дополнительных настроек при постановке на мониторинг, к примеру: метрики по профилям "Процессор" и "Память". Однако есть метрики профилей таких как "Сеть", "Процессы", где потребуется выбрать из выпадающего списка сетевой интерфейс для сбора статистики или заполнить наименование процесса или пользователя. После настройки показателей жмем кнопку сохранить в модальном окне настроек показателей и жмем сохранить на странице создания/редактирования сервиса 4.2 Добавление пользовательских метрик с использованием CS-тестов wiProbe Custom Scenario Test в системе wiSLA  — это синтетические тесты, которые имитируют деятельность пользователя.  CS позволяет создавать и исполнять пользовательские скрипты, настраиваемые под конкретные задачи, что делает его незаменимым для мониторинга уникальных или нестандартных процессов в IT-инфраструктуре. Для заведения wiProbe Custom Scenario Test  необходимо: Создать тест, где прописан сам текст скрипта. Создать показатель в системе, который будет отображать метрику в системе. Добавить показатель к шаблону SLA, по которому оценивается узел. А так же указать пороговые значения, для настройки уведомлений по метрике. Добавить тест к профилю измерения, в который был включен новый показатель, в настройка "создания сервиса" для его сбора. 4.2.1 Создание теста Общее меню → → Далее: Называем тест В выпадающем списке выбираем тип " wiProbe Custom Scenario Test ". После выбора типа теста, потребуется выбрать агент, который будет выполнять этот скрипт. Выбрать интерфейс на хосте, через который сценарий будет выполняться Выбрать шаблон из системных или пользовательских. Или написать свой скрипт. Для выполнения скрипта вы должны объявить адаптер Основным является  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" это три разных показателя в системе. Для этого: Общее меню → →  В модальном окне потребуется: Ввести код показателя, соответствующие названию в скрипте Ввести название на русском и английском Выбрать или создать свою ЕИ 4.2.3 Добавление показателя в SLA После того как мы создали показатель, требуется добавить его в шаблон мониторинга: Для этого: Сервисы →   Редактировать шаблон (выбираем из списка, действующий шаблон SLA) Добавляем показатель к существующему измерению, либо создаём новое. Так же не забудьте указать пороговые значения отказа и деградации. Что добавить показатель к существующему измерению, требуется добавить его к шаблону и прописать пороговые значения в соответствующем столбце. Добавить отдельный профиль SLA, для отображения на отдельной вкладке, можно через кнопку " + " Жмем кнопку  4.2.4 Добавление теста в сервис Возвращаемся на страницу редактирования сервиса К измерению, к которому добавили показатель, добавляем тест, который собирает наш показатель. Жмем кнопку  Далее переходим на страницу текущих показателей качества сервиса. Переходим на измененный нами профиль. Примеры скриптов 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.1 Настройка SNMP-universal TEST Одним из инструментов сбора метрик по протоколу SNMP является SNMP-universal Test. Агентом сбора данных в данном случае является сам сервер системы. По-этому убедитесь, что на сервере установлена служба SNMP. Для его настройки перейдем на страницах: Общее меню → → Далее осуществляем настройку SNMP шаблона Настройка данных подключения к устройству: Далее настройка метрик Для упрощения настройки в системе есть возможность выполнить опрос устройства через snmpwalk или загрузить MIB-файл устройства. Теперь необходимо соотнести пару показатель в системе с OID устройства. ВАЖНО! Необходимо использовать OID, который возвращает целочисленное значение через snmpget запрос После добавления всех необходимых показателей жмем кнопку сохранить 5.2 Создание SLA через SNMP-universal TEST Следующим шагом будет создание SLA. Для этого Общее меню →   → Выбираем пункт  В выпадающем списке выбираем " SNMP-universal TEST " Выбираем созданный нами тест Выбираем показатели, которые мы хотим отображать в сервисе Далее: Требуется назначить пороговые значения показателям или указать "без порога" Показатели можно будет назначить различным профилям измерений, для отображения на различных вкладках.  Далее жмем . 5.3 Настройка агента network-device для сбору через метрик SNMP-universal TEST Для отображения устройства, которое мы будем опрашивать через SNMP-universal TEST, на тепловой геокарте. А так же отображения доступности по ICMP. Потребуется завести агент типа "NETWORK DEVICE" в системе. Для этого Общее меню → → Указать тип " Network device " Задать IP адрес устройства ( так же можно проверить доступность через утилиту ping через кнопку Привязать объект к точке доступа к заранее созданным в системе или создать новую. Нажать кнопку Устройство будет в статусе "Не используется", а доступность будет определена как "Неизвестно". Статусы изменятся после поступления данных.  Перейдем к созданию сервиса. 5.4 Настройка сервиса по отображению метрик через SNMP-universal TEST Для этого: Общее меню → Сервисы → → + "доступность услуги"  Требуется назвать сервис Выбрать созданный нами SLA Выбрать созданный нами агент  Далее настроить измерения из SLA Далее требуется добавить, созданный нами SNMP-universal Test, к измерениям. Жмем сохранить и запускаем мониторинг! 6. Постановка на мониторинг через wiProbe Custom Scenario Test 6. Постановка на мониторинг через wiProbe Custom Scenario Test 6.0 Подготовка к мониторингу Настроить тест  Создать не достающие показатели Создать SLA:  Общее меню →   → Потребуется назвать SLA Добавить показатель, через кнопку "+ Добавить показатель", для удобства можно указать код показателя в поисковом окне Назвать измерение, добавить дополнительные, если требуется. Прописать пороговые значения показателей в соответствующих измерениям столбцам. Жмем  6.1 Настройка сервиса по сбору показателей Custom Scenario Test Для этого: Общее меню → Сервисы → → + "доступность услуги"  Далее потребуется: Назвать сервис Выбрать созданный SLA Указать агент сбора данных, выбрать тот, на котором запущен скрипт Добавить измерения из SLA Добавить тест, через кнопку "+". Выбрать из выпадающего списка требуемый   Жмем  7. Настройка топологии 7. Настройка топологии Система wiSLA предоставляет инструмент для визуализации статуса сервисов мониторинга — топологию. Топология — это конструктор из сетевых элементов, который позволяет визуализировать объекты ИТ-инфраструктуры, выстраивать связи между ними и привязывать к ним результаты измерений (сервисов). Начало: Для создания своей топологии нужно: (Топология привязывается к контрагенту (владельцу) пользователя, под которым она заводится.)  перейти на страницу ТОПОЛОГИЯ СЕТИ   →  разблокировать → → ДОБАВИТЬ В системе присутствуют различные сущности для отображения объектов, групп и вложенности: Элемент Иконка Назначение Узел   Обеспечивает функционал вложенности топологии: каждому "узлу" соответствует свой «слой» топологии. На диаграмме отображается количество объектов мониторинга, закреплённых в узле, а также цветовая индикация их статуса. Сеть Обеспечивает функционал вложенности топологии: каждому "сети" соответствует свой «слой» топологии. На диаграмме отображается количество объектов мониторинга, закреплённых в узле, а также цветовая индикация их статуса. Маршрутизатор   Маршрутизатор - сетевой узел, отображающий связи и агрегирующий статус мониторинга привязанных сервисов. Коммутатор Коммутатор -  сетевой узел, отображающий связи и агрегирующий статус мониторинга привязанных сервисов. АРМ АРМ -  узел рабочего места, отображающий сетевые связи и агрегирующий статус мониторинга привязанных сервисов. Датчик       Датчик -  элемент топологии, используемый для привязки и отображения результатов измерений аппаратных зондов и пользовательских сценариев мониторинга. Кросс Кросс -  элемент топологии, отображающий точку кабельной коммутации и служащий для привязки статусов мониторинга. Группа объектов Группа объектов - элемент топологии, представляющий собой поле для логического группирования элементов. Добавление элементов и привязка результатов мониторинга ДОБАВИТЬ   →  выбрать элемент из списка → щелкнуть по элементу → в меню "Данные по объекту" → ИЗМЕНИТЬ ОБЪЕКТ В модальном окне есть возможность указать общую информацию об объекте IP -адрес МAC -адрес А также привязать результаты измерений (сервис) + ВЫБРАТЬ СЕРВИС В модальном окне выбираем через марке чек-бокс сервис. Можно несколько, тогда индикация элемента будет по наихудшему состоянию. Выбираем сервисы и жмем " ПРИМЕНИТЬ ". Далее в меню "Данные по объекту" жмем " СОХРАНИТЬ " В итоге  отображение элемента на топологии выглядит следующим образом: цветовая индикация узла соответствует  наихудшему статусу среди прикреплённых к нему сервисов. Топология содержит контекстные ссылки на сервисы - нажав на иконку статуса сервиса , можно перейти на страницу его текущих показателей. Отрисовка каналов связи Для настройки отображения линии каналов связи, требуется между протянуть между двумя элементами топологии линию: Выбрать элемент от которого вы планируете протянуть канал, зажать правую кнопку мыши и провести соедиенительную линю Для настройки цветовой индикации канала, а так же для гибкой настройки, требуется нажать стрелку и выбрать пункт ИЗМЕНИТЬ КАНАЛ в данном меню можно настроить количество точек изгибка, для удобной настройки линии канала. Указать тип канала: ВОЛС, DWDM, РРЛ, Медный кабель После установки параметров жмем СОХРАНИТЬ В итоге отображение канала связи на топологии выглядит следующим образом: цветовая индикация канала соответствует наихудшему статусу среди прикреплённых к нему сервисов. Тип линии соответствует выбранному типу канала. Для удобства пользователя предусмотрена возможность задавать количество точек изгиба линии. Линия канала содержит контекстные ссылки на сервисы — нажав на иконку статуса сервиса, можно перейти на страницу его текущих показателей. Настройка агента сканирования подсетей 1. Требования к хосту Операционная система: Linux. Доступ по SSH с сервера приложений wiSLA. Пользователь, от которого будет выполняться подключение, должен иметь право выполнения команд с  sudo   без ввода пароля  (настроен в  sudoers ). 2. Установка необходимых утилит На целевой хост требуется установить три утилиты: Утилита Назначение Примечание по установке zmap получение списка IP-адресов Требуется отдельная загрузка. На Red Hat-подобных ОС — через  epel-release . arp  (из пакета  net-tools ) сопоставление IP и MAC-адресов Обычно входит в состав дистрибутива. nmblookup  (из пакета  samba4-client ) получение NetBIOS-имён Обычно входит в состав дистрибутива. Установка выполняется штатными средствами ОС (например,  yum install ,  apt install ) в соответствии с руководством администратора. 3. Настройка zmap По умолчанию в  zmap  отключено сканирование локальных подсетей. Чтобы разрешить сканирование нужных подсетей: Найдите файл конфигурации  zmap . Обычно он расположен по пути: /etc/zmap/blacklist.conf Закомментируйте строки, соответствующие подсетям, которые вы планируете сканировать. Либо добавьте собственные правила разрешения. Сохраните изменения. Запуск сканирования Выбор агента сканирования, а также задача областей сканирования выполняются  в пункте « НАСТРОЙКИ ». Откроется модальное окно настройки: можно выбрать период сканирования: каждые 30 минут, час, 12 часов, сутки; указать подсети с заданием IP-адресов и масок. Также есть пункт « НАСТРОЙКИ АГЕНТА ». В нём указываются IP-адрес и порт службы SSH, а также  учётные данные  (логин/пароль) для подключения; выбирается сетевой интерфейс хоста,  с которого  будет инициироваться  сканирование ;  задаётся порт , который будет сканироваться на  доступность . Вручную запустить сканирование можно через пункт дополнительного меню  ⟶ ⟲ сканирование подсетей Результат сканирования выводится в выпадающем списке для каждой назначенной подсети. Чтобы добавить обнаруженный элемент на топологию, нажмите значок « ⊕ ». Затем выберите тип элемента — после этого объект будет размещён на топологии, и к нему можно будет прикрепить соответствующий сервис. Канал гиф.gif — демонстрация настройки канала Видео ролики по системе Заведение инфраструктуры Канал  RuTUBE Первые шаги в системе Контрагенты и пользователи Первый шаг к настройке системы — создание Контрагента. Контрагент — это ваша корпоративная рабочая область, выступающая в роли Владельца. За этой сущностью закреплены конкретные аккаунты вашей команды и объекты мониторинга. Первый сервис В этом ролике вы узнаете, завести на мониторинг свой первый объект. На примере Linux машины, мы расскажем, как использовать шаблоны мониторинга и настраивать сбор показателей. Мониторинг доступность сервера/сервис В этом ролике мы обсудим как поставить на контроль доступность элементов IT-инфраструктуры на L3, L4 и L7 уровнях. Мониторинг СУБД В этом ролике мы рассмотрим процесс постановки мониторинг систем управления базами данных на примере СУБД PostgreSQL. Мониторинг выполнения пользовательского сценария (скрипт-сценарий) Стандартных проверок на доступность порта и пинг недостаточно для контроля сложных бизнес-процессов. В этом обучающем ролике мы детально разберем создание и настройку синтетических проверок на основе скрипт-сценариев в системе мониторинга wiSLA. Сценарии мониторинга Узлы – windows & linux  В этом ролике мы разберем основные подходы к мониторингу ключевых узлов IT-инфраструктуры, включая серверы под управлением ОС Linux и Windows. Рассмотрим поэтапный процесс настройки мониторинга - от постановки систем на наблюдение до настройки контролируемых показателей и определения их пороговых значений. Мониторинг 1С:Предприятие Современная 1С -инфраструктура — это сложный организм, где сбои на любом уровне — от сервера до лицензии — парализуют работу компании и несут прямые финансовые потери. Сквозной мониторинг становится критическим инструментом, который обеспечивает прозрачность, предсказуемость и контроль над всей системой. ПАК wiSLA обеспечивает сквозной мониторинг 1С-систем, комплексно охватывая как аппаратную инфраструктуру, так и программные компоненты кластерных решений " 1С:Предприятие" . Автоматизация обработки аварийных инцидентов В данном ролике мы покажем, как функционал платформы wiSLA позволяет автоматизировать обработку аварийных инцидентов и сократить время простоя сервисов. Администрирование Канал  RuTUBE Администрирование системы wiSLA Установка Видео демонстрирует процесс установки wiSLA 5.2.12, включая предварительную настройку узла, запуск программы установки, первоначальная конфигурация компонентов системы. В ролике будет показана работа с установочным RUN-файлом Настройка бэкапирования В этом мы обсудим как пользоваться инструментами резервного копирования в системе wiSLA Селфмониторинг системы висла.  Интерпретация аппаратных метрик Видео объясняет, как сама система wiSLA отслеживает собственное "здоровье" — использования ресурсов сервера (CPU, память, диск, сеть и т.д.). Обсуждается, как интерпретировать эти метрики для анализа первопричин сбоев Первичная диагностика проблем Видео посвящено первым шагам при возникновении проблем в wiSLA: проверка работоспособности компонентов и определение директории для анализа основных лог-файлов системы. Это основа для самостоятельного устранения инцидентов Вопросы и ответы