База данных Zabbix становится слишком большой (серверная часть PostgreSQL)
В настоящее время мы запускаем Zabbix 3.0 LTS с базой данных PostgreSQL версии 9.5.6, работающей на Ubuntu 16.04. Мы сталкиваемся с проблемой, из-за которой наша база данных Zabbix постоянно продолжает расти. Мы не совсем уверены, что вызывает проблему, но пока мы Мы выделили 400 ГБ для Zabbix, и эта цифра уже близка к прошлому. Мы включили уборку и настроили хранение данных в течение 30 дней. В нашей среде также 550 хостов, и у нас есть около 65 000 элементов в Zabbix с интервалом в 60 секунд. У нас очень много элементов, потому что наша среда в основном состоит из окон.
Вот несколько снимков экрана нашей среды Zabbix.
Это изображение наших параметров обслуживания
Я не уверен, что вызывает рост, но он увеличивается примерно на 40 ГБ каждую неделю, что просто безумно. Я не хочу увеличивать объем памяти, если это ничего не решит. Может ли кто-нибудь узнать, в чем проблема, или сталкивался ли кто-нибудь с подобными проблемами при запуске Zabbix на сервере PostgreSQL? Единственное, что я Я обнаружил, что решением может быть разбиение БД, но я хотел проверить здесь, прежде чем идти по этому пути.
Мы будем очень признательны за любые мысли или отзывы!
РЕДАКТИРОВАТЬ
Добавление графика нашего внутреннего процесса Zabbix, который показывает, что housekeeper работает на 100%. Housekeeper настроен на запуск каждый час и удаление не более 40 000 файлов. Похоже, что наши самые большие таблицы - это History, который занимает 175 ГБ, и History_uint, который занимает 100 ГБ. Если я выполняю поиск по запросу «housekeeper» или «housekeeping» в журналах zabbix сервера, я на самом деле ничего не вижу, что заставляет меня поверить в это ' s фактически ничего не удаляет
Не видя статистики больших таблиц (а именно, эффективно ли они вакуумируются авто-вакуумом), мое основное предложение - ограничить количество хранимой истории (а именно то, что идет в таблицах истории*, в отличие от таблиц трендов*).
Вообще говоря, Zabbix управляет объемом собранных данных, превращая историю (детальные наблюдения) в тренды (агрегированные наблюдения); идея заключается в том, что вы храните историю за короткий период, когда может быть целесообразно видеть точные данные поминутно, но для более долгосрочных исследований агрегированные данные являются адекватными. Более того, это означает, что таблицы истории (в которые активно добавляются данные) также меньше, и таблицы трендов могут быть больше, но с меньшей активностью записи.
Похоже, что вы делаете все наоборот, не сохраняя никаких данных о трендах, а всю историю? Есть ли причина или несчастный случай?
С другой стороны, которая через мгновение становится актуальной: Разбиение на разделы - это инструмент, он не решит вашу сиюминутную проблему, но работая над очень большими наборами данных вроде этого, он станет вашим другом. Тем не менее, разбиение на разделы (в основном) требует дисциплины в истории и сохранения тенденций, вы должны держать все элементы одинаково долгое время, так что вы можете просто бросить связанные с ними разделы по мере того, как они устаревают. Вернемся к основному ответу...
Что я делаю, так это смотрю на разные предметы и решаю, как я ими пользуюсь, и храню историю только столько, сколько мне действительно нужно, а также сохраняю тренд только столько, сколько мне нужно, если это вообще возможно. Например, у меня есть довольно много проверок на вменяемость, которые предупреждают, если что-то идет не так, но обычно это элементы, возвращающие 0, "OK" или что-то в этом роде. Довольно бессмысленно держать их больше нескольких дней. Однако, это специфическое сохранение элементов противоречит разметке, так что вы решаете.
Более уместно то, что вы опрашиваете и как часто. Я сократил наше количество элементов в 10 раз, агрессивно отфильтровывая вещи, на которые никто не смотрел. Один из самых больших - интерфейсы - некоторые устройства, которые имеют один физический интерфейс, могут иметь 6 или 10 виртуальных; конечно (кто-то скажет) у них есть смысл, но кто-нибудь на самом деле смотрит на данные, собранные с них? Подинтерфейсы, интерфейсы обратной связи, (некоторые) виртуальные интерфейсы и т.д. Сетевые администраторы часто думают: "Я все оставлю себе на всякий случай", но это редко бывает полезно - идите заклинайте данные элемента, и посмотреть, где у вас большое количество интерфейсов, о которых вам просто никогда не нужно будет знать. Или, в худшем случае, вам, возможно, придется начать мониторинг заново. Ударьте их из низкоуровневого обнаружения.
Пока вы там, посмотрите, что вы собираете для интерфейсов. Та же идея; люди часто собирают все, что показывает SNMP, потому что, ну, они могут. Притворитесь, что вы платите за каждый элемент данных, и спросите себя, стоит ли его сохранять, если вы платили за элемент. (В некотором смысле, хранение данных разумно). Если вы занимались мониторингом в течение нескольких лет, спросите себя, нужно ли вам РЕШЕНИЕ подсчитывать неудачи фрагментов (простой пример того, что звучит как реальный и полезный объект, может быть, для некоторых людей). Что бы вы сделали, если бы сказали 5? Если она не может быть использована, зачем ее сохранять? Если это та вещь, на которую вы смотрите реактивно, в реальном времени, зачем хранить ее в каждой системе исторически?
Пока вы там находитесь, спросите, почему вы так быстро опрашиваете некоторые вещи. Рассмотрим проблемы с подсчётом пакетов/байт - конечно, смотреть график истории в реальном времени каждые 60 секунд довольно аккуратно, но можно ли это сделать в действии? Научит ли Вас этому более чем один раз каждые 180 секунд? Каждые 300 секунд? Вы, наверное, собираете много таких данных, очень быстро - будете ли вы их использовать? У меня были сетевые администраторы, которые говорили: "Но мне нужно быстро реагировать на проблемы". Тогда вы обнаружите, что они вводят задержку и гистерезис, чтобы избежать ложных срабатываний и хлопания.
Откажитесь от того, что вы собираете и как часто, и ваша история сократится в 10 раз (+/-), не оказывая существенного влияния на ее полезность. Затем урежьте, как долго вы держите ее в деталях (против трендов), и она может упасть еще в 2 или 4 раза.
Длинный, блуждающий ответ, но в основном: если он не может быть использован, не держите его. Вы всегда можете вернуть его обратно, если угадаете неправильно.
Наконец: Убедитесь, что автоматический вакуум работает эффективно, подумайте о том, чтобы установить максимальное удаление домашнего хозяйства на 0 (удалить все сразу), но после этого внимательно следите за блокировкой (на системе хорошего размера с адекватной скоростью памяти/процесса/диска это может значительно ускорить работу домашнего хозяйства, но это также может привести к блокировке, если она попытается сделать TOO много за один раз).
Хорошо, наконец-то: Если Вы решили сделать то, что было предложено, и устранить множество пунктов, подумайте, можно ли просто начать все сначала. Очистка сотен гигабайт данных в домашнем хозяйстве будет огромной задачей.
.