-
-
Не исключено, что всё уже украдено до вас: https://www.zabbix.com/forum/showpos...0&postcount=32Comment
-
Спасибо. Я видел вашу разработку. Если я правильно понял описание, то она больше заточена под контроль факта функционирования тех или иных объектов/компонентов. А меня больше интересуют нагрузочные параметры.
Опять же, вы сами отмечаете эту проблему, использование powershell для снятия счетчиков... Это, конечно, очень удобно и гибко. Но мой небогатый опыт показывает, что это просто беда с точки зрения паразитной нагрузки. В качестве простого примера - я там дал ссылку на шаблон, от которого я пляшу. Там для discovery выполняются простенькие скрипты. Так я вам скажу - дефолтного трехсекундного таймаута заббикс-агента не хватает! Причем нагрузка на сервера кластера у меня не сказать чтобы дикая. Я написал простенький шаблон, который контролирует репликацию DFS через павершелловский скрипт. Так он вообще не влез в 30-секундный предельный таймаут! Пришлось делать процесс асинхронным.
Поэтому хочется снять параметры с серверов кластера "дешевыми" вызовами к агенту, а получить интегрированные данные уже на заббикс-сервере.Comment
-
В целом - там можно посчитать всё, что содержится в свойстве объекта коллекции (а это могут быть и диски и шары). Просто я не всё включал в шаблон/обработки, так как что-то появилось в WinSrv2012, а у меня 2008R2. Какие-то вещи я в кластере не имею, а ставить экспериментальный специально для написания неизвестно кому нужной функциональности - глуповато. Если у вас есть какие-то идеи и вы готовы тестировать изменения в мой скрипт - может поработать совместно.
К сожалению вы можете получить не то, что ожидаете. Данные в заббикс не будут поступать синхронно по всем объектам, поэтому потенциально аггрегирующая функция (как и любая вычисляющая) может вам дать 300% чего-нибудь. Что вы будете делать с неправдивыми показаниями?Поэтому хочется снять параметры с серверов кластера "дешевыми" вызовами к агенту, а получить интегрированные данные уже на заббикс-сервере.
Использование предварительного запроса в WMI внутри скрипта, обработка коллекции и выдача в Zabbix готовой величины обеспечит и большее быстродействие и правдоподобность результата (будете работать с условным снимком состояния).
Что касается вопроса о том, откуда читать метрики. Я считаю, что метрики нужно считать с адреса кластера (вы его определили при создании кластера). В таком случае вы всегда будете иметь данные до тех пор, пока жива хотя бы одна нода. Вам же не нужен падающий мониторинг отказоустойчивого кластера? Однако, запуск кластеризованного агента в виде сервиса - нетривиальный трюк. Скрипты, теоретически, можно держать на CVS-разделе и ходить к ним через симлинк (C:\Cluster\...)Comment
-
Для тов.Sadman
Вы сейчас затрагиваете весьма спорную, на мой взгляд, тему. Мониторинг критического ресурса (кластера) "сбоку стоящими" средствами (заббиксом). Т.е. эти средства должны быть по надежности как минимум не меньшими, чем сам критический ресурс. Т.е., по логике, надо сначала на отдельном железе кластеризовать сам заббикс-сервер, а это недешево. Кластеризовать его на наблюдаемом кластере не имеет смысла - он сам может попасть под проблемы кластера и отрубиться.
Повторюсь, мне интересны нагрузочные метрики. А не критические характеристики типа "есть проблемы с ресурсами кластера" (это прекрасно мониторится собственными средствами винды). Т.е. я решаю сейчас совершенно некритичную задачу. Скорее - справочную. И чрезмерно усложнять ее решение не хочется. Как и съедать полезную производительность кластера.
Кластеризовать заббикс-агента "с налета с поворота" у меня не вышло. И такая кластеризация - это порождение новой сущности. Такой же, как вирт.машина, кластерный том и т.д. Выглядит излишним.
Агрегация данных на заббикс-сервере дает запаздывание и искажение, это да. Но съем счетчиков по сети с последующим суммированием в скрипте - тоже. А, насколько мне известно, интегрированных счетчиков производительности для кластера нет. Каждый сервер ведет свои. И чтобы оценить нагрузку (к примеру) на конкретный LUN, RAID или канал Data Storage (у нас в этом плане жутко убогая система, своих счетчиков не отдающая) мне по-любому надо где-то и как-то делать суммирование данных, снятых с отдельных серверов. Так что, думаю, вероятность получить 300% при разных методах интеграции данных не сильно различается.
Такие вот мысли. Возможно, я где-то ошибаюсь?Comment
-
И опять архитектурная ловушка Zabbix, в которую попадают практически все, кто видит параметр Update interval в элементе данных: данный параметр определяет не время между поступлениями данных, а время между помещениями в очередь запроса на получение данных для этого элемента. Очередь, как мы понимаем, общая для всех наблюдаемых узлов.
Таким образом два запроса, положим, на получение загрузки CPU1 и CPU2 (единого хоста), в элементы данных с таймаутом в 60 секунд будут помещены в очередь с "разбегом" в ~60сек. Если всё сложится удачно, то в элементы данных значения поступят с такой же разницей времени между съёмами "физических" метрик. Если же звёзды будут против и в очередь между этими двумя запросами вклинятся запросы к каким-нибудь слоупокам, а пулеров будет мало, то таймштампы реальных значений могут быть отличны и на 120 сек... Полагаю не нужно говорить о том, что нагрузка в 100% для CPU1, полученная на первом запросе, может быть 0% при другом и наоборот - загрузка CPU2 ко времени второго запроса подпрыгнет с 0% до 100%. Т.е. в реальности у нас 100% по всем CPU, а в Zabbix-е при агрегировании - 200%. А дальше у кого как фантазия в отношении Действий работает - кто-то ограничится SMS, а кто-то начнет автоматически ложить сервисы...
Пожалуй, что вместо такого мониторинга можно просто бросать кости и дёргать за рубильник
Last edited by sadman; 21-02-2017, 18:10.Comment
-
Более-менее - это все равно достаточно условно. Поэтому я и интересовался дальнейшей судьбой данных. Если просто в /dev/null сливать, то можно их скармливать вычисляющей функции. Только предварительно усреднение какое-нибудь провести что ли (только вопрос в периоде усреднения) ... Чтобы устоявшееся значение складывалось, а не моментальное. Ну или проводить агрегацию медленно меняющихся значений (а еще лучше - статических).Comment
-
Мониторинг критических ресурсов Zabbix-ом - это вообще тема для философского трактата.
Об этом речи не шло. Я писал о кластеризованном агенте, который продолжает выдавать данные вплоть до полного окукливания кластера, а не краснеет сразу же, как только его owner пошел в штатное обслуживание.Кластеризовать его на наблюдаемом кластере не имеет смысла - он сам может попасть под проблемы кластера и отрубиться.
Да ради бога... Как будто я вам административно запретил их получать через perfmon. Просто интересно, что вы будете делать с данными, которые истинными могут не являться, но крайне похожи на них. Вам же эти графики нужны для каких-то решений.Повторюсь, мне интересны нагрузочные метрики. А не критические характеристики типа "есть проблемы с ресурсами кластера" (это прекрасно мониторится собственными средствами винды).
Скажем так - на этом этапе уже нужно рассматривать конкретные объекты мониторинга. Это, в частности, обусловлено тем (как я понимаю устройство кластера от MS), что у каждого объекта есть свой владелец (owner). Вычислив этого owner-а можно сделать быстрые адресные запросы к нему и получить метрики, которые будут на порядки ближе друг к другу, чем те, что будут получены Zabbix-ом самостоятельно (даже возможно, что они будут находится в рамках одной коллекции). Далее - сложить их значения и вернуть в Zabbix. Сами данные кластера (не помню уже как это правильно называется в рамках концепции WMI) хранятся на каждой ноде и очень часто синхронизируются. Так что кластеризованный агент получает их без оверхеда с той ноды, на которой он физически висит на данный момент.А, насколько мне известно, интегрированных счетчиков производительности для кластера нет. Каждый сервер ведет свои. И чтобы оценить нагрузку (к примеру) на конкретный LUN, RAID или канал Data Storage (у нас в этом плане жутко убогая система, своих счетчиков не отдающая)
Несомненно. Я поделился своим видением ситуации и практикой. Но, возможно, что вы найдете свой путь - более быстрый и точный. И не исключено, что поделитесь им с комьюнити.мне по-любому надо где-то и как-то делать суммирование данных, снятых с отдельных серверов.Comment
-
Не совсем так. Давайте продолжим пример с Cluster Volume(s). Для него понятие owner заключается (я, естественно, упрощаю) только в том, что только owner может выполнять операции с оглавлением тома. Т.е. изменять состав и характеристики файлов, лежащих на нем. А метрики ввода-вывода с Volume, где лежат конкретные VHD, ведет каждый сервер в отдельности в зависимости от набора исполняемых им в данный момент ВМ. И счетчики на latency, read/write ops и bytes (в том числе и в секунду) у каждого сервера свои. Они не реплицируются между серверами. Owner не знает, насколько активно работают с "его" Volume прочие сервера. Вы это легко можете проверить на своем кластере - в 2012 и 2008 в этом плане разницы немного.
Другой пример - виртуальная машина. Она живет в каждый момент времени на конкретном сервере. Но имеет право "гулять" между серверами. Что мне мешает запросить метрики этой ВМ со всех серверов сразу, а потом суммировать их? Данные будут совершенно точными, т.к. все сервера кроме одного ответят, что item unsuppоrted, и сумма значений будет равна единственному имеющемуся. И не надо нагружать реальные сервера тяжелыми powershell-овскими скриптами со сложной логикой, запросами к кластерным командлетам и прочими вытребеньками.
Относительно неточности данных (и тут я вам не возражаю совершенно, она таки есть) - вы сами дали решение. Усреднение на каком-то заметном периоде (типа 5 минут при сборе счетчиков раз в минуту).
Короче, я собираюсь еще поиграть в свою идею
P.S. А скрипты у вас очень красивые! И не только в плане написания, но и в плане оформления. Хватает же терпения... У меня есть наработки, которые, возможно, могли бы быть еще кому-то интересны. Но очень уж они неопрятные. Показывать стыдно, а причесывать - лениво.Last edited by IgorB; 21-02-2017, 17:06.Comment
-
В данном случае действительно есть два пути. Если бы я завязывался на perfmon, то переключился в Zabbix agent(active) (конечно, учитывая его особенности), поставил бы очень короткий период опроса и хранил бы данные минимальное количество времени, позволяющее произвести усреднение и вычисление. Так можно избежать проблемы удержания очереди слоупоками.
Мне в этом отношении проще - я стряхиваю метрики нагрузки хранилища со StarWind и поэтому извращаться не приходится.
Что-то мне такое помнится, что если в вычисляемом значении один item unsuppоrted, то и результат тоже unsuppоrted.Что мне мешает запросить метрики этой ВМ со всех серверов сразу, а потом суммировать их? Данные будут совершенно точными, т.к. все сервера кроме одного ответят, что item unsuppоrted,
Пока не случится слишком быстрая миграцияи сумма значений будет равна единственному имеющемуся.
Мы и не такое видели... А уж писали то ещё хлеще. Если есть хороший алгоритм, то посмотреть на него никогда лишним не будет.У меня есть наработки, которые, возможно, могли бы быть еще кому-то интересны. Но очень уж они неопрятные. Показывать стыдно, а причесывать - лениво.Comment
-
Я провел простенькие эксперименты - суммировал на группе линуксовых серверов размер свободного пространства на /var. При этом не на всех серверах он выделен, т.е. часть значений - unsupported. За точность результата не ручаюсь, но он был.
И, да, я пока писал предыдущий пост, забыл к чему вел. А вел я к тому, что такой подход, если он, конечно заработает, позволяет не решать вопрос кластеризации заббикс-агента. Расставил его на реальные сервера - и "гуляй, рванина!"
А как приличные люди делятся наработками?Comment
Comment