Дорый вечер.
1) ZBXNEXT-245
В рамках фича-реквеста, которому к слову уже 2.5 года, прилагается патч для версии 1.8.х реализующий независимые настройки для граничных значений ординат. Так как второй набор параметров надо где то хранить, то в патче добавляются дополнительные столбцы в таблицу graphs.
Я решил что внесение изменений в БД мне не очень нравится и можно пожертвовать "полноценностью" функционала, посему я реализовал свой вариант workaround. Все изменения для реализации задуманного касаются только frontend-а (php).
а) я добавляю 4 новых "типа" для фиксирования ординаты, 95% патча это внесение изменений в раличные "валидации", эти изменения даже теоритически не могут иметь "побочных эфектов"
б) так как отрисовка графиков в забиксе по умолчанию поддерживает "расчет" двух ординат без фиксирования, то код для независимого расчета минимальных и максимальных значений ординат уже готов, там ничего менять не надо, требуется лишь дать алгоритму правильные данные, это оставшиеся 5% пача
в) в моем варианте нельзя задать минимальное значение одновменно для правой и левой ординаты, так же как и максимальное значение, но можно ограничить, например, левую ординату или ограничить левую по минимальному значению, а правую по максимальному, ну и т.д.
2) ZBXNEXT-123 Смешно сказать, но через месяц этому фича-реквесту будет 4 года. В коментариях к нему есть ссылка на пост на форуме где публикуется патч для версии 1.8.x. Если чесно я его не смотрел внимательно. Написал свой вариант, опять же все правки только интерфейсные.
а) внес изменения в две функции в class.cchart.php которые отрисовывают левую и правую ординаты, эти две функции по сути одинаковы, я проверяю определен ли valuemapid для отображаемого на данной ординате итема, если у нас несколько итемов с мапингом или если один из итемов определяет units, то я не буду мапить значения (проверки независимы для каждой ординаты, как я уже сказал, так что мы можем мапить с одной стороны, а с другой отображать итем с единицами измерения)
б) переписал функцию applyValueMap, во первых добавил опциональный параметр при установке которого в TRUE на выходе будет пустая строка если подстановка не найдена, во вторых сделал кэширование "ненайденных" значений, что бы не дергать БД лишний раз, в целом код там более чем тривиальный
Вообщем, что имеем прикладываю в посту.
На моем графике соотношение сигнал/шум в "прямом" спутниковом канале отображается на левой ординате и измеряется оно в dB, на правой же ординате мы отображаем модуляцию и FEC (modcod) используемый для передачи данных данному vsat. Сигнал/шум хочется отобразить с привязкой ординаты к нулю, так лучше воспринимается визуально, а модкоды хочется видеть по их названиям, а не какие то числа. Модкодов в районе 30 штук.
P.S. На закуску прикладываю еще патч добавляющий вычисление квадратного корня (например, last("mykeyone[]") * 2~(last("mykeytwo[]") + last("mykeythree[]")) собственно "2~" это операция квадратного корня по модулю) и вычисление степени - "^". Мне как и другим понадобилось вычислять среднеквадратичное отклонение джитера по данным cisco sla udp-jitter, если кому будет интересно, то и шаблон приложу.
P.P.S. все патчи для версии stable 2.0.3rc1, у меня ревизия 29519. Так же проверил что патчи прикладываются на последнюю доступную ревизию - 29985.
1) ZBXNEXT-245
В рамках фича-реквеста, которому к слову уже 2.5 года, прилагается патч для версии 1.8.х реализующий независимые настройки для граничных значений ординат. Так как второй набор параметров надо где то хранить, то в патче добавляются дополнительные столбцы в таблицу graphs.
Я решил что внесение изменений в БД мне не очень нравится и можно пожертвовать "полноценностью" функционала, посему я реализовал свой вариант workaround. Все изменения для реализации задуманного касаются только frontend-а (php).
а) я добавляю 4 новых "типа" для фиксирования ординаты, 95% патча это внесение изменений в раличные "валидации", эти изменения даже теоритически не могут иметь "побочных эфектов"
б) так как отрисовка графиков в забиксе по умолчанию поддерживает "расчет" двух ординат без фиксирования, то код для независимого расчета минимальных и максимальных значений ординат уже готов, там ничего менять не надо, требуется лишь дать алгоритму правильные данные, это оставшиеся 5% пача
в) в моем варианте нельзя задать минимальное значение одновменно для правой и левой ординаты, так же как и максимальное значение, но можно ограничить, например, левую ординату или ограничить левую по минимальному значению, а правую по максимальному, ну и т.д.
2) ZBXNEXT-123 Смешно сказать, но через месяц этому фича-реквесту будет 4 года. В коментариях к нему есть ссылка на пост на форуме где публикуется патч для версии 1.8.x. Если чесно я его не смотрел внимательно. Написал свой вариант, опять же все правки только интерфейсные.
а) внес изменения в две функции в class.cchart.php которые отрисовывают левую и правую ординаты, эти две функции по сути одинаковы, я проверяю определен ли valuemapid для отображаемого на данной ординате итема, если у нас несколько итемов с мапингом или если один из итемов определяет units, то я не буду мапить значения (проверки независимы для каждой ординаты, как я уже сказал, так что мы можем мапить с одной стороны, а с другой отображать итем с единицами измерения)
б) переписал функцию applyValueMap, во первых добавил опциональный параметр при установке которого в TRUE на выходе будет пустая строка если подстановка не найдена, во вторых сделал кэширование "ненайденных" значений, что бы не дергать БД лишний раз, в целом код там более чем тривиальный
Вообщем, что имеем прикладываю в посту.
На моем графике соотношение сигнал/шум в "прямом" спутниковом канале отображается на левой ординате и измеряется оно в dB, на правой же ординате мы отображаем модуляцию и FEC (modcod) используемый для передачи данных данному vsat. Сигнал/шум хочется отобразить с привязкой ординаты к нулю, так лучше воспринимается визуально, а модкоды хочется видеть по их названиям, а не какие то числа. Модкодов в районе 30 штук.
P.S. На закуску прикладываю еще патч добавляющий вычисление квадратного корня (например, last("mykeyone[]") * 2~(last("mykeytwo[]") + last("mykeythree[]")) собственно "2~" это операция квадратного корня по модулю) и вычисление степени - "^". Мне как и другим понадобилось вычислять среднеквадратичное отклонение джитера по данным cisco sla udp-jitter, если кому будет интересно, то и шаблон приложу.
P.P.S. все патчи для версии stable 2.0.3rc1, у меня ревизия 29519. Так же проверил что патчи прикладываются на последнюю доступную ревизию - 29985.
Attached Files
Comment