Як приготувати тости та заодно візуалізувати ІТ-системи

Вітаю, шановні читачі! У цьому матеріалі я хочу поділитися історією про приготування тостів та розповісти, яким чином ми розширили функціонал Zabbix за допомогою мотка дроту та інтегральної мікросхеми Open Source рішень. Про все по порядку, прошу під кат.

Давайте уявимо собі таке: ви працюєте в організації (вона може бути і вашою), в якій є бізнес-процес, підтримуваний однією або декількома ІТ-системами. Я достеменно знаю, що є система моніторингу. Далі бачення трохи розпливається, і незрозуміло: це промислова система або безкоштовна Open Source. Однак у вас трапляються ситуації, коли всі датчики на ній зелені, але сам бізнес-процес дає незрозумілі збої, демонструючи зниження ключових показників. Як спалах електрошокера представника правопорядку на несанкціонованому мітингу, у вашій голові проскакує думка, що ситуація вийшла з-під контролю і потрібно негайно діяти. Тільки ось незрозуміло як. Скажу вам, це досить поширений кейс, від проявів якого бажано якнайшвидше позбутися. Системний підхід до вирішення цієї проблеми забезпечить складання моделі сервісу.

Том Вуджек, який надає послуги з візуалізації процесів, що відбуваються в компаніях (не тільки ІТ-), провів цікаве дослідження. Він попросив різних людей намалювати процес приготування тостів. Нижче наведено деякі результати цієї роботи.

Що ж ми бачимо на багатьох картинках? Правильно! Об'єкти та зв'язки, присутні у будь-якій системі. Чим їх більше, тим системнішим буде підхід. Правильний ступінь гранулярності дозволить більш точно відстежувати здоров'я бізнес-системи. Для побудови схеми можна спробувати використовувати Visio, аленабагато цікавіше взяти маркер для малювання зв'язків, клейкі листочки для об'єктів та зобразити вашу систему на маркерній дошці. Чим більше жовтих листочків, тим більше зв'язків, тим вищий шанс визначити максимальну кількість точок моніторингу для точного визначення джерела проблеми.

А тепер настав час розповісти про наші напрацювання в галузі розширення стандартного функціоналу Zabbix та застосування системного підходу, описаного вище. Їх рівно дві.

Перша – складання карти систем та створення теплової карти сервісів. Враховуючи наш серйозний досвід щодо моніторингу банківських бізнес-процесів, приклад ми наведемо саме з цієї галузі. Розглянемо три типові банківські системи. Якщо у вашому банку є типовіші системи, прошу мене вибачити – їх ми розглядати тут не будемо.

Система дистанційного банківського обслуговування (ДПВ):

Корпоративна шина даних (ESB):

Система прийняття рішень (СПР):

У нашому додатку це буде виглядати так (так, структура дещо порушується, але при цьому наочність залишається):

У разі потреби можна перейти на рівень нижче. І, що не менш важливо, при наведенні на об'єкт спливає pop-up вікно з описом події та посиланням на графік у Zabbix:

Завдяки такому підходу та заданому ступеню деталізації, на виході ми отримуємо зручний дашборд, а заразом простий інструмент локалізації проблеми. Декілька слів про функціональні можливості нашої системи:

- Візуалізація залежностей між корпоративними системами; - налаштування ступеня впливу компонентів один на одного (вага зв'язку); - інтеграція з Zabbix (об'єкти на тепловій карті пов'язані з тригерами); —спливаючі вікна з текстом події під час наведення на об'єкт; - візуальний інтерфейс налаштування зв'язків об'єктів; - візуальний інтерфейс налаштування зв'язку об'єктів з тригерами Zabbix.

Як приклад наведу кілька вже розроблених інтерфейсів.

Додавання об'єктів на теплову картку:

Додавання інтеграцій із Zabbix:

Підключення тригерів Zabbix до об'єктів на тепловій карті:

Система працює на базі Google Charts та Bootstrap. Поки що це альфа-версія, ми плануємо її розвивати й надалі, додаючи корисні фішки з промислових систем, з якими успішно працюємо вже багато років. Постараюся тримати вас в курсі та публікувати пости у міру накопичення купи нових можливостей.

Друге напрацювання – це інтеграція з Zabbix та тепловою картою функціоналу синтетичних транзакцій. Фактично, це продовження теплової карти, але погляд з іншого боку. Однозначно, контролюючи систему тільки з боку самого додатка та інфраструктури, ви не матимете необхідної повноти інформації. Синтетичні транзакції дозволять подивитися на цю справу з боку користувача та локалізувати проблему ще до перших звернень користувачів до Help Desk.

Синтетичні транзакції побудовані на базі фреймворку phantom.js (але вам нічого не заважає перейти на casper.js, чистий selenium або щось інше на ваш смак). У нашій тестовій лабораторії виконання тестового сценарію налаштоване через cron і далі отримані дані передаються до Zabbix за допомогою zabbix_trapper. Як приклад тестового сценарію взято логін в особистий кабінет МТС та отримання залишку грошей на рахунку та трафіку в інтернет-пакеті. Нижче – листинг скрипту. У банківському середовищі найімовірнішим застосуванням цього інструменту може бутибути, наприклад, ДПВ. Ніхто вам не заважає виробляти логін в систему і перекидати 1 рубль з рахунку на рахунок.

Збираються items виглядають так:

Кожен відповідає свій графік.

У жодному разі не хочу сказати, що застосування в моніторингу Open Source рішень є таблеткою від усіх неприємностей. Відкрию секрет Полішинеля: як і у фізиці, тут діє закон збереження грошей та трудовитрат. Чим більше грошей ви увіллєте в готовий продукт, тим менше трудовитрат на доопрацювання, і навпаки. Завжди варто керуватися здоровим глуздом, наявним бюджетом та людським фактором: чи готова буде ваша команда кинутися на амбразуру бізнес-моніторингу за першим покликом?

Технологіями моніторингу, що особливо цікавляться, пропоную ознайомитися з нашою попередньою статтею з цієї теми «Принципи моніторингу бізнес-додатків».