GUI на Grafana для mgstat — утилиты мониторинга системы на InterSystems Caché, Ensemble или HealthShare

[osigida]

Я конечно извиняюсь, но уникального материала здесь ровно 4 строки.

К чему это нужно? Показать что в докер можно завернуть почти все, а графана в связке с прометеусом умеет отображать графики?

[myardyas]

Цель была показать, как конкретно вывод ^mgstat можно показать наглядно. Про Docker тут сказано коротко, самое нужное для понимания. Остальной материал полностью мой, но если покажете, где что слизал касательно ^mgstat, буду благодарен.

[osigida]

Отчего-ж, именно по ^mgstat материал уникален, спору нет.
А вот пошаговая инструкция, по запуску докера и настройки борды в графане, уже несколько не в тренде.

[myardyas]

Соглашусь, что, возможно, некоторые шаги можно было просто упомянуть, не описывая. Однако еще одной своей задачей ставил изложение достаточно понятное даже для тех, кто докером и графаной до сих пор не пользовался. Ну ок, попробую учесть на будущее. Про SYS.Stats материал будет интересен?

[osigida]

не знаю что это, значит должно быть интересно узнать :-)

[myardyas]

Это набор классов внутри Caché, которые позволяют собрать тонны статистики о работе систем на платформе InterSystems. Еще насчет связки Prometheus-Grafana. AlertManager, Consul, PushGateway, Prometheus remote systems — считаем известными или же стоит уделить внимание? )

[doublefint]

Большое спасибо за обе статьи!

«отсутствие данных в Singlestat-панелях (которые, естественно, предполагают единственное значение). У нас сервера два, вот и значения два.» — делаем отдельную строку, определяем дополнительную переменную с именами серверов, в панели используем опцию «повторить для переменной». Вот тут пример

Замечание к реализации странице выдачи метрик — программа ( программа, Карл! ) и класс. Имхо класса более чем достаточно. Перед взятием метрик по коду размазана проверка версии сервера — если что, в каше есть режимы генерации кода

[myardyas]

Спасибо за комментарий!
По поводу решения для Singlestat-панелей. На community Murray Oldfield задавал вопрос о шаблонах. Поэтому сделал через шаблоны в качестве ответа. Надеюсь, статья будет переведена на английский и выложена там.
Как по мне, слова «рутина» и «программа» взаимозаменяемы.
Насчет размазанности проверки версий — это к ISC -). Взял код ^mgstat и оставил/заменил в нем нужное мне.
В следующий раз планирую вообще не использовать ^mgstat и брать метрики напрямую из SYS.Stats. Надо только внимательно сравнить выдачу SYS.Stats и всяких там $zu(190,2,1) и т.п. Жаль, далеко не все $zu описаны. Придется либо искать по коду, либо спрашивать у саппорта.

[doublefint]

Поэтому сделал через шаблоны в качестве ответа

Так я же предлагаю улучшить их использование — переменные шаблона можно использовать для генерации панелей SingleStat.

слова «рутина» и «программа» взаимозаменяемы.

Замечание было не про термины рутина — программа, а про способ организации кода. Зачем вы используете дополнительный модуль ( рутина, программа ) с кодом, когда у вас есть класс, в который это все можно было сложить, задокументировать, покрыть тестами ( ыы :). Зачем в 2017 году использовать рутины-программы, когда у вас есть более удобная высокоуровневая абстракция — класс.

Насчет размазанности проверки версий — это к ISC -).

Нет, к вам. Это вы так организовали код, что одни и те же проверки многоратно повторяются. Принцип «Однажды и только однажды»?.. В Каше есть всё, чтобы переписать ваш код более лаконично и наглядно.

и брать метрики напрямую из SYS.Stats

Я попался с такой попыткой на версии 2014.1.4 — там баг для класса SYS.Stats.Dashboard. Имхо, более старые низкоуровневые функции работают надежней. Ну или тесты ;)

[myardyas]

Так я же предлагаю улучшить их использование — переменные шаблона можно использовать для генерации панелей SingleStat.

Принимается как вариант улучшения.

Зачем вы используете дополнительный модуль

Тоже принимается. Это статья о возможности. К следующему разу будет реализация напрямую в классе. Тестов не обещаю -)

проверки многоратно повторяются.

Принимается в том смысле, что код альтернативной рутины выложен мной, стало быть, и «пахнет» по моей вине.

старые низкоуровневые функции работают надежней

Тоже попался на, кажется, 15-й версии. Но ISC рекомендует избавляться от использования $zu — раз. Лучше задокументировано — два. Ошибка исправлена — три.

В принципе, с glostats и diskstats полями в $zu уже разобрался, как и со статистикой по WD. С чем пока затык — это со статистикой по ECP. Назначение многих метрик буду выпытывать к саппорта.

Будет интересно продолжение (AlertManager, автообнаружение + больше метрик (взятых, возможно, действительно из $zu))?

Ну или какие темы, по-вашему, еще стоит осветить, если стоит?

[doublefint]

Думаю будет интересно, если поделитесь прикладным опытом исходя из типового сценария — вот «у одного моего знакомого» был grafana-дашборд для cache-сервера, в нем объединены метрики из ( node_exporter || wmi_exporter ) && cache_exporter… Какие именно метрики наиболее полезны и почему, куда смотреть в первую очередь, куда потом, куда копать глубже, как настроили для себя alert ы и примеры как справлялись с проблемными ситуациями

[myardyas]

Вас понял. Спасибо за ответ! Попробую что-то подобное подготовить. Есть как раз «одни мои знакомые» на винде. Посмотрю на них wmi_exporter. Знакомых, работающих на контейнерах, пока нет. Хотелось бы в деле посмотреть еще cadvisor_exporter. Тут есть мысль перевести сборку на Jenkins докер. Появится «знакомый». Недавно была хорошая статья по контейнеризации Cache. Также есть ваша статья по сборке на Jenkins. Сборкой на Jenkins уже давно пользуемся. Теперь еще один шаг вперед.

[doublefint]

Попробуйте также сборку на Gitlab, мне очень нравится

[myardyas]

Спасибо, попробуем. Также один очень хороший специалист, работающий ныне в TeamCity, хвалил TeamCity. Хотя последний, вроде как, проигрывает gitlab'у -)

[SergeyMi]

Спасибо, обе статьи прекрасные. Экономят время и все актуально.