База данных Zabbix становится слишком большой (серверная часть PostgreSQL)

Не просматривая статистику больших таблиц (в частности, они эффективно очищаются с помощью автоматического вакуумирования), я предлагаю ограничить объем хранимой вами истории (в частности, то, что входит в таблицы истории *, а не таблицы трендов *).

Вообще говоря, Zabbix управляет объемом собранных данных, превращая историю (подробные наблюдения) в тренды (агрегированные наблюдения); Идея состоит в том, что вы храните историю в течение короткого периода, когда было бы целесообразно просматривать точные данные поминутно, но для более долгосрочных исследований достаточно агрегированных данных. Более того, это означает, что таблицы истории (в которые постоянно добавляются данные) также меньше, а таблицы трендов могут быть больше, но с меньшей активностью записи.

Похоже, вы делаете наоборот, храня не данные о тенденциях, а всю историю? Есть причина или случайность?

Кроме того, это становится актуальным через мгновение: разбиение на разделы - это инструмент, он не решит вашу непосредственную проблему, но, работая с такими очень большими наборами данных, он станет вашим другом. Тем не менее, разделение (в основном) требует дисциплины в истории и сохранении тенденций, вы должны хранить все элементы одинакового периода времени, чтобы вы могли просто удалить связанный с ними раздел по мере его устаревания. Вернемся к основному ответу ...

Что я делаю, так это смотрю на разные предметы и решаю, как я их использую, и храню историю только до тех пор, пока мне действительно нужно, и сохраняю тенденцию только так долго, если вообще. Например, у меня есть довольно много проверок работоспособности, которые предупреждают, если что-то идет не так, но обычно это элементы, возвращающие 0, «ОК» или что-то подобное. Довольно бессмысленно хранить их дольше нескольких дней. Однако такое удержание для конкретного элемента противоречит разделению, поэтому решать вам.

Более важно то, что вы опрашиваете и как часто. Я уменьшил количество пунктов, может быть, в 10 раз, агрессивно отфильтровав вещи, на которые никто не смотрел. Один из самых больших - это интерфейсы - некоторые устройства с одним физическим интерфейсом могут иметь 6 или 10 виртуальных; конечно (кто-то скажет), что они имеют значение, но действительно ли кто-нибудь просматривает данные, полученные от них? Субинтерфейсы, интерфейсы обратной петли, (некоторые) виртуальные интерфейсы и т. Д. Сетевые администраторы часто думают: «Я сохраню все на всякий случай», но это редко бывает полезно - изучите данные элемента и посмотрите, где у вас большое количество интерфейсов вам просто никогда не нужно будет знать об этом. Или, в худшем случае, вам, возможно, придется снова начать мониторинг. Убейте их с помощью низкоуровневых открытий.

Пока вы там, посмотрите, ЧТО вы собираете для интерфейсов. Та же идея; люди часто собирают все, что показывает SNMP, потому что они могут. На мгновение представьте, что вы платите за каждый элемент данных, и спросите себя, стоит ли его хранить, если вы платили по элементу. (В некотором смысле, с точки зрения хранения данных, вы подходите). Если вы занимались мониторингом в течение нескольких лет, спросите себя, нужно ли вам КОГДА-ЛИБО подсчет отказов фрагментов (простой пример того, что звучит как реальный и полезный элемент, возможно, для некоторых людей). Что бы вы сделали, если бы вы сказали, что появится 5? Если это не требует действий, зачем его хранить? Если на такие вещи вы смотрите реактивно, в реальном времени, зачем скрывать их от каждой системы исторически?

Пока вы там, спросите, почему вы так быстро опрашиваете некоторые элементы. Обратите внимание на проблемы с подсчетом пакетов / байтов - конечно, неплохо наблюдать за графиком истории в реальном времени каждые 60 секунд, но можно ли это сделать? Обучает ли он вас чаще, чем одному каждые 180 секунд? Каждые 300 секунд? Вы, вероятно, очень быстро собираете МНОГО таких данных - вы будете их использовать? У меня были сетевые администраторы, которые говорили «но мне нужно быстро реагировать на проблемы». Затем вы обнаруживаете, что они вводят задержку и гистерезис, чтобы избежать ложных срабатываний и колебаний.

Вернитесь к тому, что вы собираете и как часто, и ваша история сократится в 10 раз (+/-) без значительного влияния на его полезность. Затем сократите время хранения информации в деталях (по сравнению с тенденциями), и она может упасть еще в 2 или 4 раза.

Длинный, бессвязный ответ, но в основном: если он не имеет смысла, не оставляйте его. Вы всегда можете вернуть его, если угадаете неправильно.

Наконец: убедитесь, что автоматический вакуум работает эффективно, подумайте о том, чтобы установить максимальное значение для служебного удаления на 0 (удалить все сразу), но затем внимательно следите за блокировкой (в системе хорошего размера с адекватной памятью / процессом / скоростью диска это может значительно ускорить работу дома. сохраняется, но он также рискует заблокироваться, если попытается сделать слишком много сразу).

Хорошо, наконец-то: если вы ДЕЙСТВИТЕЛЬНО решите поступить так, как было предложено, и исключить множество элементов, подумайте, можете ли вы просто начать с данных. Очистка сотен гигабайт данных в домашнем хозяйстве будет огромной проблемой.