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

avg(#3) > avg(#3,7d) * 0.3

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

может

хм

спасибо

может

как?

а вот так

снимаем метрику первый раз

метрика = 1

среднее =1

снимаем втрой раз

метрика =3

среднее = 2

дальше объяснять?

текущее среднее - это просто среднее (арифметическое к примеру)

да, но ты ведь среднее считаешь за какое-то количество метрик. Иначе твое среднее не имеет смысла

но оно текущее

от чего-то до сейчас

да, наверно я не так выразился. Текущее за какой-то период до сейчас

угу

А заббикс умеет сам менять важность триггера в зависимости от обстоятельств?

Они вроде что-то такое анонсировали в версии 3.4 ?

А заббикс умеет сам менять важность триггера в зависимости от обстоятельств?

https://www.zabbix.com/documentation/3.4/ru/manual/config/triggers/dependencies

Нет, это не то

Менять важность триггера в зависимости от обстоятельств – очень крутая была бы фича

Сейчас приходится заворачивать это в LLD и в зависимости от окружения зажигать разные лампочки

Менять важность триггера в зависимости от обстоятельств – очень крутая была бы фича

Была бы, но пока етсь зависимости

На девеле может быть warning, на проде disaster

avg(#3) > avg(#3,7d) * 0.3

а не подскажеш в чем ошибка может быть ? {Template OS Linux:net.if.in[{#IFNAME}.avg(1h)} > {Template OS Linux:net.if.in[{#IFNAME}.avg(1h,7d)} * 0.3

для прототипа

ошибку покажи

квадратную скобку не закрыл

и не используй 0.3 в триггере, используй макро

да макро потом

пока отладка

Некорректное выражение триггера. Проверьте часть выражения начиная с "{Template OS Linux:net.if.in[{#IFNAME}.avg(1h)} > ({Template OS Linux:net.if.in[{#IFNAME}.avg(1h,7d)} * 0.3)".

квадратную скобку не закрыл

Надеюс верно для прототипов

{Template OS Linux:net.if.in[{#IFNAME}].avg(1h)} > {Template OS Linux:net.if.in[{#IFNAME}].avg(1h,7d)} * 0.3

воспользуйся тестом выражения

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

{Template OS Linux:net.if.in[{#IFNAME}].avg(1h)} эта часть

я вот в прототипах не увидел такого )

Коллеги, а как такое реализовать? Есть 20 нод, есть веб сценарии с 10 шагами, нужно сделать график со 20 линиями, каждая из которых - длительность всей веб-проверки соответсвующего узла.

Если просто проверять длительность выполнения последнего шага - не тот торт

если все шаги рисовать - 200 линий выходит

Всех приветствую ? Друзья помогите пожалуйста. Постоянно на графике вылезают скачки( как с эти бороться?

Почини

Вероятно параметры собираются не совсем одновременно

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

Господа знатоки ... вопрос такой ... планируется хранить около 2мл метрик , хостов 10к ... из бест практис ... какие значения выставить в сроках хранения хаускипера

С такими нагрузками, я думаю, надо сразу смотреть в сторону партиционирования БД, хаускипер будет базу убивать на время очистки.

Господа знатоки ... вопрос такой ... планируется хранить около 2мл метрик , хостов 10к ... из бест практис ... какие значения выставить в сроках хранения хаускипера

Никакой. Паотицирование в бд и внешний скрипт очистки.

У нас хостов меньше, но очень много метрик. Только паотицирование и спасает

Господа знатоки ... вопрос такой ... планируется хранить около 2мл метрик , хостов 10к ... из бест практис ... какие значения выставить в сроках хранения хаускипера

Смотря для чего. Хаускипинг может чистить разные таблицы. Events, history, trends и т.д. Все зависит от nvps и от того как быстро база будет расти. Скорее всего тренды и историю нужно разбивать на партиции и хаускипинг для них не делать. Для всего остального можно. А сколько хранить - зависит от требований

ERROR: S client not available

Господа знатоки ... вопрос такой ... планируется хранить около 2мл метрик , хостов 10к ... из бест практис ... какие значения выставить в сроках хранения хаускипера

Готовь хороший сервер, сервер с партиционированием

у нас около 50к nvps

все на ssd лежит

у меня к сожалению не ssd

Хрена себе цензура. Все поудалял. =)

Хрена себе цензура. Все поудалял. =)

Тут вам не демократия

Что же, что же тут было? Неужели упоминание о каком-то продуктнейме? :)

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

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

Обычно хватает

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

При наличии хорошего канала связи с сервером без перебоев - достаточно sqlite

Понял, спасибо. Я допилил шаблон мониторинга hp msa 2312/2000/2040 без скриптов, только за счёт телнета и препроцессинга. Без ллд. Выкладывать?

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

ложка, конечно, хороша к обеду, но всё равно хотел бы поправить: отклонение каждого элемента в этом графике примерно одинаковое, только нижние элементы показывают реальное отклонение, а верхние - уже "усиленный" наложением графиков друг на друга скачок.. снизу к верху отклонение каждого элемента от прямой неуклонно увеличивается.. а это уже может влиять и неодновременность

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

Можно попробовать офисы в свои прокси отделить, только не забыв отследить связность с каждой проксёй.

Когда связи с прокси не будет все равно куча тригеров сработает, но данные конечно будут собираться

Не, вопрос именно в зависимостях. Если упал шлюз в инет в центральном офисе (квагга легла на заббиксе) - то не надо спамить о проблемах на всей остальной области.

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

Приветы. Скажите, как поудобнее сделать это? Есть данные вида cat /proc/net/sockstat* (можно сделать из них что-то типа такого - {"sockets":{"used":"7153"},"TCP":{"inuse":"2274","orphan":"4","tw":"694","alloc":"6088","mem":"5477"},"UDP":{"inuse":"12","mem":"5"},"UDPLITE":{"inuse":"0"},"RAW":{"inuse":"1"},"FRAG":{"inuse":"0","memory":"0"},"TCP6":{"inuse":"3631"},"UDP6":{"inuse":"7"},"UDPLITE6":{"inuse":"0"},"RAW6":{"inuse":"0"},"FRAG6":{"inuse":"0","memory":"0"}}), хочется пулять данные одной порцией из zabbix_sender.

Приветы. Скажите, как поудобнее сделать это? Есть данные вида cat /proc/net/sockstat* (можно сделать из них что-то типа такого - {"sockets":{"used":"7153"},"TCP":{"inuse":"2274","orphan":"4","tw":"694","alloc":"6088","mem":"5477"},"UDP":{"inuse":"12","mem":"5"},"UDPLITE":{"inuse":"0"},"RAW":{"inuse":"1"},"FRAG":{"inuse":"0","memory":"0"},"TCP6":{"inuse":"3631"},"UDP6":{"inuse":"7"},"UDPLITE6":{"inuse":"0"},"RAW6":{"inuse":"0"},"FRAG6":{"inuse":"0","memory":"0"}}), хочется пулять данные одной порцией из zabbix_sender.

разбирать джсон тем же питоном и слать метрики

либо делать проверки типа external_check, тем же скриптом

очень не нравится слать гору метрик поштучно

вот бы как-то за один раз

ты можешь опрашивать по одной тебе нужной

либо разово все, как твоей душе удобно

читаю про external_check, спасибо.

читаю про external_check, спасибо.

если версия 3.4 используй препроцессинг и не нужно JSON только regexp

ммм, щас почитаю, спасибо