Стандартные визуализации заббикса мы используем, но в них не хватает гибкости для вывода на один экран несколько взаимосвязанных метрик. Поэтому остановились на специализированном, с точки зрения решения данной задачи, инструменте визуализации — Grafana. Данные для визуализации Grafana мы берем не только из заббикса, но и из ELK и Influxdb. Последнюю мы используем для сбора метрик по нагрузочному тестированию о которой писали недавно в статье
Prometheus рассматриваем как инструмент мониторинга при работе в облаке после полной контейнеризации сервисов системы.
Метрика объем файлов вложений\в год не учитывает общую потребность в подсистеме хранения. СХД для системы используется монопольно. Это позволяет решить вопросы тюнинга и конкуренции с прочими системами Банка. Помимо исторического набора данных с вложениями которых сейчас порядка 25 ТБ, мы имеем накладные расходы на поисковые индексы, на сервисы архивного хранения протоколов аудита и прочих, интеграционные сервисы и микросервисы системы. Т.е общая потребность в подсистеме хранения на текущий момент порядка 100 ТБ, а также заложены объемы на развитие.
Про стек технологий используемых для построения системы можно было бы написать отдельную статью если будет интересно. Сама система — это совокупность сервисов, объединённая общей шиной событий на основе Apache ActiveMQ Artemis. Ряд сервисов действительно микросервисы (сервис шрихкодирования, сервис конвертации в pdf, сервис проверки эп и тд). Но основной сервис бизнес логики это многослойный пирог объединяющий прикладную функциональность. С точки зрения сервиса бизнес логики мы выдерживаем компромисс между трудоемкостью сопровождения и развития. Слои сервиса бизнес логики состоит из слоя restapi, слоя доменной логики, слоя документоориентированных коннекторов к хранилищу и платформы AF5. Для большинства сервисов используем Spring Framework. Для различных клиентов: GWT, Angular, также есть нативные для iOS и Android. Поисковый движок Apache Solr. Субд соответсвенно PostgreSQL Все сервисы контейниризируются. Для автоматизации сборок Jenkins и maven, контроль качества автотесты на selenium, юнит тесты, интеграционные тесты и метрики через Sonar Cube.
Спасибо за вопрос. Я считаю так: если бизнес-пользователь не испытывает каких либо проблем (времена совпадают или опережают его ожидания ), то это очень неплохой результат. Исходя из этого, можно сказать что к данным цифрам стоит относиться позитивно.
С другой стороны, стоит задать вопрос: какой ценой дались эти времена? И здесь ответ однозначен: на оборудовании хуавей можем вот так. С технической точки зрения уверен, что есть ещё возможность улучшить данные цифры.
Если правильно понял вопрос, то речь о подготовке данных с точки зрения объемного тестирования.
Для того, чтобы организовать данные для тестовой среды нагрузочного тестирования мы:
1) Полностью мигрировали справочные данные из актуальной боевой инфраструктры
2) Выполнили миграцию данных за период двух месяцев и применили их мультиплексирование за счет созданных скриптов, которые фактически берут реальные данные и версионируют их.
Поэтому фактически статическая выборка, тем самым, была приближена к реальным условиям по составу, а инструменты п.2 позволили анализировать изменения, происходящие с системой в режиме накопления данных.
Профиль нагрузки, т.е фактические сценарии использования их количество и интенсивность,
распределения по ролям, мы получали за счет системы мониторинга реальной боевой среды.
Prometheus рассматриваем как инструмент мониторинга при работе в облаке после полной контейнеризации сервисов системы.
С другой стороны, стоит задать вопрос: какой ценой дались эти времена? И здесь ответ однозначен: на оборудовании хуавей можем вот так. С технической точки зрения уверен, что есть ещё возможность улучшить данные цифры.
Для того, чтобы организовать данные для тестовой среды нагрузочного тестирования мы:
1) Полностью мигрировали справочные данные из актуальной боевой инфраструктры
2) Выполнили миграцию данных за период двух месяцев и применили их мультиплексирование за счет созданных скриптов, которые фактически берут реальные данные и версионируют их.
Поэтому фактически статическая выборка, тем самым, была приближена к реальным условиям по составу, а инструменты п.2 позволили анализировать изменения, происходящие с системой в режиме накопления данных.
Профиль нагрузки, т.е фактические сценарии использования их количество и интенсивность,
распределения по ролям, мы получали за счет системы мониторинга реальной боевой среды.