Пожалуй лучшая система мониторинга
Да, да это тот же самый стек
- Планирование на базе анализа временных рядов
- Планирование на базе статистического анализа
- Корректировка планов
- Экспорт планов для аналитики
Сбор и хранение логов
Планирование
- Мониторинг KPI
- Поиск аномалий и фрод мониторинг
- Мониторинг клиентского опыта
- Мониторинг SLA, нагрузки, населенности
Сбор и хранение бизнес метрик
Бизнес мониторинг и поиск аномалий
- Анализ работы сервисов на основе логов и events
- Мониторинг SLA и деградаций
- Выявление аномалий
- Поиск по логам, автоматические акты
Мониторинг сервисов и аномалий
- мониторинг инфраструктуры
- мониторинг сервисов (ресурсы, доступность )
- мониторинг на основе snmp
- Алертинг
Мониторинг инфраструктуры
Предлагаемый стек технологий и моудулей
Еще стек
Массштабирование
prodact deploy
prodact deploy
интерфейсы собственной разработки
REST API
OpenSource GUI
Рзработка CI/CD тестирование
ML NN Слой
пользовательские
модели и NN
пользовательские
модели и NN
ML штучки
Доп. хранилища
Аналитика
Авторизация
Аутентификация
Аутентификация
Типовой стек для обеспечения масштабирования обеспечения непрерывной разработки, тестирования и публикации в продуктивную среду, а так же вспомогательных функций хранения и авторизации и аутентификации
ETL ELT
Data Warehouse
GUI
ML
OpenSource GUI
Страшно? Дорогу осилит идущий.
Почему такой стек?
- Типовой стек легче найти специалистов (ну почти)
- opensource все лицензии позволяют использовать продукты для оказания коммерческих услуг
- для баз данных есть форки в реестре РФ в перспективе ФСТЭК
- Возможно разворачивание локально и простая миграция в облака (почти все элементы доступны как услуга ), возможна экономия на сопровождение
- Развитие проектов командами инженеров, клиентоориентированный подход, быстрая адаптация под нужды бизнес задач, экономия High-value HR
I just SELECT * FROM TERMINAL_STAT
Немного про применяемые технологии
- Уменьшение количества ошибок в моделях данных.
- Повышение согласованности данных (валидация).
- Повышение скорость работы команды разработчиков данных.
- Сокращение потери времени на дублирование работы?
- Четкое определения используемых метрик (автодокументирование)
- Облегчение работы новых сотрудников с кодовой базой.
- Барьер (90 % - это SQL, остальные 10 % требуют обучения)
- Избыточно сложен для простых вещей
- Для простого воспроизведения всех цепочек, локально требуется настройка CI/CD да и вобще для работы в команде требуется настройка, принятие парадигм итп
DBT
- легко установить и настроить, GUI из коробки.
- позволяет тестировать работу пайплайна без запуска всего рабочего процесса, встроенные тесты.
- Данные в Dagster имеют явно определенные типы, что обеспечивает большую надежность системы на этапе выполнения.
- предоставляет мощные средства для визуализации данных и пайплайнов, позволяет всей команде понимать, как связаны между собой разные данные, даже если они не участвовали в создании самого процесса, документация прямо из кода
- Множество встроенных интеграций в том числе с dbt
Dagster
- Opensearch это elasticsearch с нужной лицензией, встроенным GUI и кучей полезного функционала из коробки
- Opensearch лучше/легче полнотекстовый поиск, особенно с учтём, что не все логи мы сможем структурировать, и все это можно делать из интерфейса и есть API
- Opensearch легче реализовать потоковую вставку
- Clickhouse – лучший для агрегирующих запросов и OLAP
- Clickhouse – отличное сжатие данных, быстрая вставка батчами, крутой синтаксический сахар в SQL запросах
Opensearch и Clickhouse зачем нам обе?
- Сопровождать, изучать две системы баз данных
- Быстрый, эффективный, меньше потребляет CPU и RAM
- Работает как в режиме агента, так и агрегатора
- Вроде бы простая конфигурация (yml, toml, json) + динамическая перезагрузка конфигурации
- Быстрое преобразование и парсинг данных, много встроенных в том числе анонимайзеры
Vector
- Не нравится? давайте возьмем, что то другое.
- В стеке поддерживаются групповые политики доступа (RBAC) с принципами наименьших привилегий, возможен двухфакторный доступ
- Шифрование данных как при передачи данных TLS, так и при хранение, где-то прямо в базе где то необходимо будет настроить на уровне операционной системы
- Есть инструменты анонимизации, маскирования, чувствительной информации
Немного инфобеза
- Документирование всех сервисов, которые хотим мониторить, критерии стабильности работы и соблюдения SLA, выбор метрик для мониторинга, периодичность мониторинга, сценарии и каналы алертинга, паттерны поиска по логам для подготовки актов (см. примеры в конце)
- Для бизнес мониторинга и планирования – выбираем по одному показателю для тестирования технологии
Выход: статья xwiki, что мониторим, как и с какой периодичностью, как, кого и когда предупреждаем, куда смотрим, как часто и кто это делает
- Посмотреть, изучить, обсудить предлагаемый стек.
- Изучить текущие Log и данные, которые позволят организовать мониторинг необходимого поведения сервисов
- В идеале принять единый log style
Выход: Принять vs предложить свой vs ничего не делать
Аудит
Изучение стека
Предварительный этап (~3 недели)
1
Исполнитель помни! лучше меньше но лучше, лучшее-враг хорошего.
2
Первый этап. (~3 месяца)
Стандартизация для текущих систем, песочница для новых
Мониторинг инфраструктуры
- За Zabbix оставляем основные функции мониторинга инфраструктуры и алертинга, сервисы только в плане состояния вкл/выкл, потребление ресурсов (если нужно диагностировать раздельно от общего ресурса).
- Zabbix приводим к виду, описанному в xwiki на предварительном этапе, + документирование
Мониторинг сервисов и аномалий
- Настройка Vector для сбора логов, на всех видах перечисленных сервисов
- Настройка индексов для логово в OpenSearch
- Настройка Dashbord-ов для визуализации нужных процессов мониторинга
- Настройка алертинга средствами OpenSearch и трансляции в Zabbix
- Настроенная в песочнице под все виды сервисов система отслеживания, с настроенными потернами алертинга на основе статистических/статичных правил, без тиражирования
- Понимание требуемых объемов ресурсов для разворачивания, на всей продуктивной среде, попытка прогнозирования нужно ли разворачивание в кластерной среде kubernetes
Бизнес мониторинг и поиск аномалий
- Настройка первых моделей dbt для выбранного показателя/ей
- Первичная настройка dagster, подготовка запуск первых pipeline для собора данных из источников в DataWarehouse (Clickhause, OpenSearch)
- Настройка Dashbord-ов для визуализации нужных процессов мониторинга
- Тестирование статических порогов и на основе ML
- Настроенная песочница для разработки, тестирования.
- Знакомство с функционалом стека проверка гипотез.
- Понимание требуемых объемов ресурсов для следующего этапа.
Планирование
- Расширение моделий dbt, и пайплайнов для построения коневейра генерации данных для обучения моделей
- тестирование prophet
- Песочница для ML моделирования
- Первые результаты применения
Второй этап. (~2 месяца)
Мониторинг инфраструктуры
- корректируем то, что выявили в ходе первого этапа
- планируем и добавляем, мониторинг ресурсов самого мониторинга
- Настройка RBAC
- Работающая поддерживаемая система мониторинга ресурсов·
Мониторинг сервисов и аномалий
- тиражирование в продуктивную среду, работа под реаль нонагрузкой
- тестируем динамический анализ выявления аномалий (встроенный или если появились свои модели моделями)
- Настройка RBAC
- ·Работающая поддерживаемая система мониторинга сервисов·
Бизнес мониторинг и поиск аномалий
- Финализация стека и методов разработки CI/CD
- Передача проекта команде разработки подсистемы
- ·Передано команде разработке подсистемы со всеми необходимыми инструментами и вычислительными ресурсами или методами их бронирования
Планирование
- Финализация стека и методов разработки CI/CD
- Передача проекта команде разработки подсистемы
- Передано команде разработке подсистемы со всеми необходимыми инструментами и вычислительными ресурсами или методами их бронирования
- Бронирование необходимых вычеслительных ресурсов
Для всех подсистем
Запуск и теражирование системы мониторинга сервисов
Дальнейшие шаги выходят за рамки горизонта событий презентации