Не обязательно. Если она просто пришла в негодное состояние. Забыл, как такое тестирование называют.

Я бы начал с проверки доступности сервера с узлов

{HOSTNAME:agent.ping.nodata(Nm)}=1

nodata не нужна, не используй

Хотя там активный

Ладно

заббикс сам проверяет доступность агента

по умолчанию

и проблеемы только примерн ос 75% узлов

заббикс сам проверяет доступность агента

Если шаблон с пассивной проверкой, активный - нет

у нас все хосты с активными агентами

Активный просто разбирает по уникальным хостнэймам

у нас все хосты с активными агентами

Так пинг и телнет ходят? Уже даже интересно

ага, ходят

update items set state=1. error cannot evaluate expression cannot evaluate function в статистике посгреса

Вы базу поломали

Заббикс писать не может

Данных (новых) нет

Срабатывают триггеры

Залип, отличное видео

Вот вводная: https://www.youtube.com/watch?v=NY-9HUnmR6c Там очень хорошо рассказывается как настроить по фэншую. Сделай reindex. Вот таблицам что в топе таком. select schemaname || '.' || relname, n_dead_tup from pg_catalog.pg_stat_user_tables order by n_dead_tup desc limit 20;

???

???

Всегда пожалуйста.

таки база инконсистентной окаалась

переехали на клон сделанный за пол часа до инцидента - все завелось

всем спасибо

ну ты кинь запрос-то. :) + есть https://t.me/pgsql

"SELECT h.name AS host, h.hostid AS hostid, t.triggerid," \ "t.description AS trigger, t.priority AS severity, t.lastchange " \ "FROM triggers t " \ "LEFT JOIN functions f ON t.triggerid = f.triggerid " \ "LEFT JOIN items i ON f.itemid = i.itemid " \ "LEFT JOIN hosts h ON i.hostid = h.hostid " \ "LEFT JOIN hosts_groups hg ON h.hostid = hg.hostid " \ "LEFT JOIN groups g ON hg.groupid = g.groupid " \ "LEFT JOIN interface ifa ON h.hostid = ifa.hostid AND ifa.main = 1 " \ "WHERE t.value = 1 " \ "AND h.status = 0 " \ "AND t.status = 0 " \ "AND i.status = 0 " \ "AND t.priority > 0 " \ "GROUP BY t.triggerid;"

Коллеги, а как вы добавляете хосты с одинаковой метрикой на один график?

Коллеги, а как вы добавляете хосты с одинаковой метрикой на один график?

Если нужен постоянный график, то наверное только через фиктивный хост. Если разово посмотреть, то по-моему через последние данные можно.

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

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

Будет ли? Будет привязан к одному точно.

Будет, у меня есть такие графики

причем в названии графика имени хоста не будет, зато имена хостов будут в легенде

Да. У меня такие есть.

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

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

Не зря запиннили. Ой не зря

а будет ли забикс агент 3.4 работать с сервером 4.0?

будет, но новые возможности будут недоступны.

"SELECT h.name AS host, h.hostid AS hostid, t.triggerid," \ "t.description AS trigger, t.priority AS severity, t.lastchange " \ "FROM triggers t " \ "LEFT JOIN functions f ON t.triggerid = f.triggerid " \ "LEFT JOIN items i ON f.itemid = i.itemid " \ "LEFT JOIN hosts h ON i.hostid = h.hostid " \ "LEFT JOIN hosts_groups hg ON h.hostid = hg.hostid " \ "LEFT JOIN groups g ON hg.groupid = g.groupid " \ "LEFT JOIN interface ifa ON h.hostid = ifa.hostid AND ifa.main = 1 " \ "WHERE t.value = 1 " \ "AND h.status = 0 " \ "AND t.status = 0 " \ "AND i.status = 0 " \ "AND t.priority > 0 " \ "GROUP BY t.triggerid;"

SELECT h.name AS host, h.hostid AS hostid, t.triggerid, t.description AS trigger, t.priority AS severity, t.lastchange FROM triggers t LEFT JOIN functions f ON t.triggerid = f.triggerid LEFT JOIN items i ON f.itemid = i.itemid LEFT JOIN hosts h ON i.hostid = h.hostid LEFT JOIN hosts_groups hg ON h.hostid = hg.hostid LEFT JOIN groups g ON hg.groupid = g.groupid LEFT JOIN interface ifa ON h.hostid = ifa.hostid AND ifa.main = 1 WHERE t.value = 1 AND h.status = 0 AND t.status = 0 AND i.status = 0 AND t.priority > 0 order by t.triggerid; -- т.к. нету тут ниодной агрегации, то и группировать не по чему. Это какая-то mysql-ная фича наверное. ну или так SELECT DISTINCT h.name AS host, h.hostid AS hostid, t.triggerid, t.description AS trigger, t.priority AS severity, t.lastchange FROM triggers t LEFT JOIN functions f ON t.triggerid = f.triggerid LEFT JOIN items i ON f.itemid = i.itemid LEFT JOIN hosts h ON i.hostid = h.hostid LEFT JOIN hosts_groups hg ON h.hostid = hg.hostid LEFT JOIN groups g ON hg.groupid = g.groupid LEFT JOIN interface ifa ON h.hostid = ifa.hostid AND ifa.main = 1 WHERE t.value = 1 AND h.status = 0 AND t.status = 0 AND i.status = 0 AND t.priority > 0;

SELECT h.name AS host, h.hostid AS hostid, t.triggerid, t.description AS trigger, t.priority AS severity, t.lastchange FROM triggers t LEFT JOIN functions f ON t.triggerid = f.triggerid LEFT JOIN items i ON f.itemid = i.itemid LEFT JOIN hosts h ON i.hostid = h.hostid LEFT JOIN hosts_groups hg ON h.hostid = hg.hostid LEFT JOIN groups g ON hg.groupid = g.groupid LEFT JOIN interface ifa ON h.hostid = ifa.hostid AND ifa.main = 1 WHERE t.value = 1 AND h.status = 0 AND t.status = 0 AND i.status = 0 AND t.priority > 0 order by t.triggerid; -- т.к. нету тут ниодной агрегации, то и группировать не по чему. Это какая-то mysql-ная фича наверное. ну или так SELECT DISTINCT h.name AS host, h.hostid AS hostid, t.triggerid, t.description AS trigger, t.priority AS severity, t.lastchange FROM triggers t LEFT JOIN functions f ON t.triggerid = f.triggerid LEFT JOIN items i ON f.itemid = i.itemid LEFT JOIN hosts h ON i.hostid = h.hostid LEFT JOIN hosts_groups hg ON h.hostid = hg.hostid LEFT JOIN groups g ON hg.groupid = g.groupid LEFT JOIN interface ifa ON h.hostid = ifa.hostid AND ifa.main = 1 WHERE t.value = 1 AND h.status = 0 AND t.status = 0 AND i.status = 0 AND t.priority > 0;

Ооо спасибо, я тут продвигался мелкими шажками)

SELECT h.name AS host, h.hostid AS hostid, t.triggerid, t.description AS trigger, t.priority AS severity, t.lastchange FROM triggers t LEFT JOIN functions f ON t.triggerid = f.triggerid LEFT JOIN items i ON f.itemid = i.itemid LEFT JOIN hosts h ON i.hostid = h.hostid LEFT JOIN hosts_groups hg ON h.hostid = hg.hostid LEFT JOIN groups g ON hg.groupid = g.groupid LEFT JOIN interface ifa ON h.hostid = ifa.hostid AND ifa.main = 1 WHERE t.value = 1 AND h.status = 0 AND t.status = 0 AND i.status = 0 AND t.priority > 0 order by t.triggerid; -- т.к. нету тут ниодной агрегации, то и группировать не по чему. Это какая-то mysql-ная фича наверное. ну или так SELECT DISTINCT h.name AS host, h.hostid AS hostid, t.triggerid, t.description AS trigger, t.priority AS severity, t.lastchange FROM triggers t LEFT JOIN functions f ON t.triggerid = f.triggerid LEFT JOIN items i ON f.itemid = i.itemid LEFT JOIN hosts h ON i.hostid = h.hostid LEFT JOIN hosts_groups hg ON h.hostid = hg.hostid LEFT JOIN groups g ON hg.groupid = g.groupid LEFT JOIN interface ifa ON h.hostid = ifa.hostid AND ifa.main = 1 WHERE t.value = 1 AND h.status = 0 AND t.status = 0 AND i.status = 0 AND t.priority > 0;

Я не понял, чем твой запрос отличается от моего

GROUP на ORDER BY поменял, вижу

Фишка в том, что несколько айтемов могут участвовать в одном триггере

Телега сьедает некоторые апострофы и знаки кстати, в лоб запрос в psql не проходил и мелкой сменой синтаксиса тоже. Проверю чуть позже, начал просто делать выборки с простых и джоинить в итоге, но не доделал.

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

есть шаблон, к он прявязан к 5,6к хостов, при попытке поменять время опроса на одном или нескольких айтемах веб морда прорисовывает шапку и белый экран, и время опроса не меняет, кто виноват куда копать?

есть шаблон, к он прявязан к 5,6к хостов, при попытке поменять время опроса на одном или нескольких айтемах веб морда прорисовывает шапку и белый экран, и время опроса не меняет, кто виноват куда копать?

Смотри пхп логи

в заббикс логе еще сыпется вот такая ерунда slow query: 7.116211 sec,

ввсякие настройки мускула и конфига забикса как советуют в различных статьях инета не сильно помогают

в заббикс логе еще сыпется вот такая ерунда slow query: 7.116211 sec,

Он ещё и запрос должен писать

ввсякие настройки мускула и конфига забикса как советуют в различных статьях инета не сильно помогают

Ты читаешь вообще, что я тебе написал?

да

Говорю, смотри логи пхп. Ты мне про какие-то настройки мускуля.

Ну то что внутри

На андроиде просто не отрисовывает

Смотри пхп логи

ок

ок

Чо пишут?

пока хз

в заббикс логе еще сыпется вот такая ерунда slow query: 7.116211 sec,

Тут же запрос видно будет

И смотреть в slowquery логе MySQL

пока хз

Ну найдёшь – либо крутить время выполнения, либо лимит по памяти. Там точно скажут. Если по памяти – смотри, сколько на сервере свободно, чтобы не прибить остальные процессы.

спс

??

Какие опции за это отвечают – надо гуглить, я не помню на память

ERROR: S client not available

этим и занят

Господа, кто знает подскажите Zabbix housekeeper processes more than 75% busy чего это значит?

Господа, кто знает подскажите Zabbix housekeeper processes more than 75% busy чего это значит?

Процесс очистки дб жрет ресурсы

База у тебя подросла

Процесс очистки дб жрет ресурсы

ясно

Или на медленном диске

База у тебя подросла

Откуда такие выводы? ?

да база там почти 150 Гиг

База у тебя подросла

Нет

Потому что обычно люди начинают это чувствовать когда база подрастает)

да и сервер не новый.... не ссд

history Обзор Обзор Структура Структура Поиск Поиск Вставить Вставить Очистить Очистить Удалить Удалить ~853,952,924 InnoDB utf8_general_ci 92.3 ГиБ - history_uint Обзор Обзор Структура Структура Поиск Поиск Вставить Вставить Очистить Очистить Удалить Удалить ~603,826,710 InnoDB utf8_general_ci 68.2 ГиБ

Рекомендую отказаться от хаускипинга в сторону партицирования

Потому что обычно люди начинают это чувствовать когда база подрастает)

75% не из-за того, что просто база подросла

Рекомендую отказаться от хаускипинга в сторону партицирования

Кем?

Зачем?

Кем что?

Да уже прочитал, что ты рекомендуешь

Я не рекомендую

Вообще хаускипер жрёт либо 0% (не работает), либо 100% (работает).

Я не рекомендую

+

Ilya Ableev (3) увеличил репутацию Alexander (2)

так ладно .... кипер сам почистит или надо руками базу обрезать или почистить .. станцевать с ней? подскажите

так ладно .... кипер сам почистит или надо руками базу обрезать или почистить .. станцевать с ней? подскажите

Если ты можешь дропать таблицы – то ты будешь быстрее хаускипера. Почистить базу быстрее хаускипера – нужно сильно извратиться.

Я не рекомендую

В двух словах - почему?

Если ты можешь дропать таблицы – то ты будешь быстрее хаускипера. Почистить базу быстрее хаускипера – нужно сильно извратиться.

он просто ее лопатит уже неделю....

В двух словах - почему?

Из-за того, что это решение из коробки. Партиционирование - лишние телодвижения. Лучше учиться обходиться инструментарием приложения. Хотя и надо немного почитать и посчитать.

Здраво, да. Хотя и не всем подходит.

Здраво, да. Хотя и не всем подходит.

По идее должно всем подходить. Просто в случае очень большой нагрузки надо пересматривать срок хранения в меньшую сторону и/или задуматься об экспорте исторических данных куда-то для последующей аналитики

Прдскажите куда копать