Розробка веб-інструменту для моніторингу роботи внутрішніх процесів

Думаю что стоит взять какое-то готовое решение, типа https://medium.com/southbridge/prometheus-monitoring-ba8fbda6e83

Илья Капустин 5 травня 2019

Да, у нас есть мониторинг Zabbix. Он покрывает только нужны мониторинга железа, сервисов, портов и тд.

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

Какой у вас стек технологий?
Prometheus позволяет мониторить различные метрики, думаю хорошо подходит для решения этой задачи.

Илья Капустин 5 травня 2019

Вы серьёзно? С помощью него можно "замерить" сколько выполняются различные методы в коде? Если это действительно так, то это отлично, благодарю за совет.

Если нет, то внимательно прочитайте суть написанного в проекте. Тогда не будет вопросов "Какой стек технологий?"

Это действительно так, он позволяет это сделать. А стек нужен для того чтобы люди понимали с чем им придется работать.

Илья Капустин 5 травня 2019

Работать со стеком не придется. Работать придется ТОЛЬКО с данными в базе. Больше ни с чем. 

Погуглил, почитал про Prometheus. Возможно действительно его и можно адаптировать под наши нужны. Но нужны очень тонкая его настройка, не сразу понятно как это сделать, нужно разбираться, углубляться и тд. Возможно проще написать своё узкое решение.

Если у вас есть опыт его тонкой настройки, давайте обсудим.

Илья Капустин 5 травня 2019

Вопрос "про стек" лишь говорит о том, что вы начали обсуждение не особо вчитываясь в то, что написано в проекте.

решение под ключ, в моем понимании, это выполнить задачу полностью, т.е. и залезть в приложение,  и настроить мониторинг и визуализацию

Илья Капустин 5 травня 2019

Согласен с вами. Только при чем тут "стек"?

Давайте ближе к делу. Вам по силам настроить Prometheus в качестве мониторинга на временем выполнения отдельных методов? В свой код мы самостоятельно пропишем нужные вызовы, разумеется. Предпложительно, это будет "складываться" сначала в MySQL, а оттуда уже перегружаться, в тот же Prometheus например.

В таком случае необходимость в использовании Prometheus отпадает, нужно просто визуализировать данные с помощью той же https://grafana.com/ например

а если БД с метриками уже есть, нужно только данные визуализировать, то это же совсем другой разговор

Илья Капустин 5 травня 2019

Поэтому я вам и написал - читайте внимательнее. Всё описано ведь в деталях.

Илья Капустин 5 травня 2019

Артём, спрашу в 3 раз. У вас есть опыт работы со всем этим? Готовы за это взяться?

Да, готов, конечно, я пытаюсь понять фронт работ и как будет проходить сотрудничество.
Как я понял, что нужно сделать:
- развернуть и настроить grafana, которая выведет все метрики и отправит алерты когда нужно
Верно?

Илья Капустин 5 травня 2019

Да, как вариант сделать это нужно сначала для MySQL таблицы. 

Посмотреть как всё это будет выглядеть вообще. Потом поднять ClickHouse (тут мы сами осилим, если у вас нет представления как это делать) и мигроровать на эту БД. Плагин для кликхаус у графаны есть, я уже посмотрел это

на каком языке это написано шо за СУБД?если на языке программирования написано это одно если на php или питоне то другое

При раскладе 1000 записей о событиях в секунду или более - настраиваемый или подстраеваемый Алерт не сработает быстро технически по причине того что ожидание самой записи в БД  может дойти до минут на таких объемах. А их ещё считать потом.. 

Собственное решение не может идти в привязке к SQL в таком случае. Или другой универсальной среде. Лучше определить буфферы в памяти/диапазоны адресов в файле для записи о событиях и каждый микропроцесс пишет свои логи паралельно с другими микропроцессами но во избежание накладок только строго в свой участок. Тут в помощь ещё одна техника - циклические буфферы. Кто сталкивался например со звуком знает - доходит запись до конца выделенного блока и начинает писать в этот же блок сначала. 

Мое субъективное мнение - SQL со своими десятками милисекунд последовательной записи (а она последовательна, вся параллельность ставится в очередь во избежания перезаписи поверх), 1000 запросов в секунду.. 

может ошибаюсь но думаю что используя промежуточные звенья вроде стандартизованных СУБД не прыгнете вы сильно высоко по скорости мониторинга. Минуты задержки при таких нагрузках - может быть. И это за счастье. Секунды - нет.

Ну и в свою очередь, если речь идёт о мониторинге с отставанием в минуты, привязываясь к SQL, то подойдёт любое решение. Вряд ли расстроит отставание (актуальность)  данных о событии 5 минут, при этом те же 5 минут записи всех удовлетворят как за положеное. Дискриминация по функциональному признаку получается ))

может имеет смысл нагрузочное тестирование? пара тестировщиков в такой сложной системе найдут слабые места

А вот этот 100%. Согласен, Андрей.

Без предварительного убойного теста на отказ выполнение задачи будет грозить просто тратой времени двух сторон. 

А именно когда исполнитель потратит время, а заказчик скажет - извини, но у нас сидит штат и курит мониторя  300 серверов потому что твое решение тормозит так что выспаться можно. Исполнитель же в свою очередь скажет - ребята, моя задача была отобразить данные - я отобразил в пределах способности  их предоставить..