период хранения истории zabbix

Какие правильно почистить таблицы в базе Zabbix?

Есть база zabbix c секционными таблицами. Структуру базы со связями в документации не нашел. Проблема такая. Быстро растет таблица history и все ее секции.

В manage_partitions смотрю сколько хранятся данные.

Самый большие секции в history_uint, там за день выходит 5-6 Gb. History_text в день занимает по 500 Mb и если хранить его 120 дней, то места у меня не хватит точно.
Вопросы. Можно ли через UPDATE в базе поменять количество дней и не сломается ли тогда заббикс полностью? Если я правильно понял, то в эти секциях history_* хранятся только данные для графиков?

А вообще, по партицированию есть хорошая тема на zabbix forums.

Однозначно утверждать, что всё пройдет хорошо, Вам никто не будет. Я бы перед такой операцией сначала забэкапился.

И еще, у Вас действительно так много критичных данных для которых требуется хранить историю 120 дней? Вы их действительно анализируете? Может быть для этих целей логичнее использовать тренды (хранят усредненную информацию за каждый час), а период хранения истории ограничить, допустим, месяцем?

Источник

Заметки цифрового кочевника

Иногда в результате ошибки конфигурирования шаблона или ошибки конфигурирования оборудования, в данные системы мониторинга попадает масса ложной информации. Возможна ситуация, когда в период времени от А до Б информация верная, от Б до В – ложная, от В до Г верная. Эта статья ответит на вопрос, как удалить информацию на участке от Б до В, не затронув прочие данные.

Подготовка запросов MySQL.

Если ваш мониторинг осуществляется через zabbix proxy, а сервер выступает в роли коллектора данных, то вам несказанно повезло. Вы безболезненно можете остановить zabbix server, сделать резервную копию базы данных, провести удаление данных и после его запуска сервера получить всю информацию за время проведения работ. Таким образом, вы сможете работать в большей безопасности. Однако пока вы проводите свои работы, вам не будут приходить уведомления о событиях в наблюдаемых объектах, что может быть критично для некоторых компаний. В любом случае, вам стоит подумать над шагами к возворату системы в состояния до вносимых изменений. Я делаю резервное копирование базы данных Zabbix перед любыми подобными работами, работы провожу при выключенном сервере. Для резервного копирования используя следующий скрипт:

Подсвечены строки, требующие внесения ваших параметров!

Пока идёт резервное копирование — займёмся определением исходных данных. Нужно выяснить какие данные нужно удалить и где они находятся. Поможет нам в этом веб интерфейс системы. Веб интерфейс работает независимо от сервера заббикс, поэтому с доступом проблем быть не должно, однако возможно долгое выполнение запросов к интерфейсу в связи с загруженностью базы данных.

Чаще всего ошибки в данных обнаруживаются в двух случаях: неправильно срабатывают триггеры или графики показывают неактуальную информацию. В моём случае имела место вторая ситуация. Мои графики загрузки сетевых интерфейсов выглядели совсем неправдоподобно, и я знал, что 13 сентября были проведены изменения в шаблон:

Кроме информации по сетевым интерфейсам ошибочной была признана информация и по большинству других параметров данных устройств. Решено было удалить всю информацию по конкретным устройствам за последние две недели. Для этого нам нужно узнать id хостов, чтобы на их базе получить id параметров для удаления. Сделать это можно просто посмотрев на ссылку в веб интерфейсе zabbix. Например, при просмотре графиков:

В моём случае хосты имеют номера 10276, 10245, 10089. На базе данной информации я получаю список всех наблюдаемых параметров прямо из базы данных. Для этого используется следующий sql запрос:

Следующий необходимый кусок мозаики — временной промежуток, который нужно удалить. Даты и время в базе данных zabbix хранятся в unixtime формате. Поэтому нам нужно конвертировать начальное и конечное время в этот формат. Моя начальная дата — 14 сентября 2014 года 6 часов вечера, в unixtime формате это 1410703200. Конечная дата — 24 сентября 2014 года 12 часов дня вечера, в unixtime формате это 1411545600. При переводе времени между форматами не забывайте про часовые пояса, это самая частая ошибка. Перевод между часовыми часами вы должны делать до написания запроса, т.е. в уме. Unixtime – часовой пояс GMT. Перевод между форматами можно делать прямо в SQL запросе.

Определив промежуток времени, нам нужно выяснить тип удаляемых данных. От этого зависит внутренняя таблица базы данных zabbix, в которой нужно производить манипуляции. Либо можно пройтись запросами по всем таблицам без разбора. Я предпочитаю второй метод. Он не оставляет никаких следов за указанный период.

В заббикс за хранения исторических данных отвечают следующие таблицы:

В исторические таблицы записываются непосредственно снимаемые данные. Срок их хранения устанавливается в шаблонах отдельным параметром. Долгое хранение данных в этих таблицах не имеет смысла, так как графики с детализацией более 1 недели строятся по трендам и этот параметр жёстко записан в коде zabbix. По объёму данных исторические таблицы обычно одни из самых объёмных во всех установках систем мониторинга zabbix.

За хранения трендов отвечает всего две таблицы:

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

Проверка запросов MySQL и выполнение удаления.

Итак, осталось запустить запрос и проверить правильность его написания в вашем случае. Запрос на просмотр удаляемых данных будет выглядеть так:

Запрос должен вернуть список объектов, соответствующих заданным условиям. В конце строки запроса стоит фраза «LIMIT 0, 1000», которая лимитирует количество строк в ответе. Для понимания правильности достаточно 1000 строк. Если же сделать запрос безграничным, то это может вызвать значительную нагрузку на сервер баз данных. Здесь важно учитывать, остаётся он или нет рабочим в момент проведения манипуляций.

Если ответ на запрос получен, значит всё сделано верно. Осталось изменить тип запроса на запрос удаления. Удалять мы будем через команду DELETE.

Приведённые запросы тоже имеют лимит количества строк на выполнение. Это сделано, чтобы вы могли оценить загрузку вашего сервера баз данных и системы хранения в момент выполнения команды. Команда DELETE работает очень медленно и ресурсоёмко. В зависимости от участка удаляемых данных выполнение данной команды может занять несколько часов, в экстремальных, не лимитированных случаях – несколько дней.

Заключение.

Я думаю, что данную задачу можно оптимизировать на участке синтаксиса SQL запроса, однако алгоритм выполнения задачи будет соответствовать указанному в статье. Я с радостью отвечу на ваши вопросы или критику в комментариях к статье. Результат наших монипуляций виден в правильном графике:

На большом графике провал есть, но в целом график более информативен:

Источник

Zabbix 3.4: Макросы в интервалах времени

Привет. Продолжаем освещать нововведения Zabbix 3.4. Сегодня поговорим об использовании макросов в интервалах обновления и других временных периодах.

Пару слов о макросах

Пользовательские макросы – давно зарекомендовавший себя механизм, используемый в Zabbix повсеместно и дающий системе мониторинга необходимую ей гибкость. По сути это переменные, которые вы можете назначать с глобальным уровнем видимости, шаблона или узла сети. Использование макросов всячески приветствуется и рекомендуется, например в шаблонах, что делает их настраиваемыми в других окружениях и другими пользователями.
Выглядят пользовательские макросы следующим образом, вы их наверняка уже встречали:

Интервалы обновления и хранения истории

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

Обновления каждой метрики также могут быть «гибкими»(см. Пользовательские интервалы), а значит происходить по определенному расписанию («раз в сутки ночью» или «в 9:00 утра в будни»).

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

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

Варианты использования

Интервалы обновления и длительность хранения собранных данных

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

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

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

Это позволит не тратить каждый раз время на обдумывание «я хочу собирать эту метрику раз в 60 или раз в 61 секунду? или может раз в 5 минут будет достаточно?», а просто использовать принятые на вашем сервере и проекте правила по сбору и хранению элементов данных, зафиксированные в глобальных макросах. Хотя, возможно, такой вариант подойдет не всем 🙂

В низкоуровневом обнаружении

Поддерживается и контекст макросов, что может быть очень полезно, например, при LLD.
Представьте, что мы собираем трафик сетевых интерфейсов на множестве устройств. Чтобы не нагружать Zabbix, мы бы хотели сделать следующим образом:

Затем используем их в прототипе элемента данных интерфейса, но уже с контекстом (в данном случае это будет имя интерфейса ifName):

Уже на уровне узла сети укажем новое значение макроса с контекстом для ключевого интерфейса (для примера возьмем Gi0/0.114):

Теперь посмотрим частоту обновления и время хранения для различных интерфейсов в «Последних данных». Как видно, у нашего очень важного Gi0/0.114 теперь свои правила хранения и сбора:

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

Где еще?

А еще макросы теперь можно применять в других ситуациях, где нужно было указывать время или период. Например, в действиях:

или указать через макрос время доступности инженера для автоматических уведомлений:

С точным списком мест, в которых возможно применение макросов, можно ознакомиться здесь.

В итоге

Новые возможности макросов в 3.4 открывают парочку неплохих возможностей: с одной стороны — для более тонкой настройки (для LLD), а с другой стороны — для централизации и управления временем опроса и хранения. И кстати, в интервалах времени появилась поддержка суффиксов s,m,h,d,w — мелочь, а удобно 🙂

Источник

Zabbix Documentation 3.4

Sidebar

Table of Contents

3 История и динамика изменений

Обзор

В то время как история хранит каждое собранное значение, динамика изменений хранит усредненную информацию за каждый час, что, следовательно, менее ресурсоемко.

Хранение истории

Вы можете указать как много дней история будет храниться:

Любые более старые данные будут удалены с помощью автоматической очистки базы данных (Housekeeper).

Вместо долговременного хранения истории, вы можете хранить больше данных динамики изменений. Например, вы можете хранить историю 14 дней и динамику изменений 5 лет.

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

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

Хранение динамики изменений

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

Вы можете указать как много дней динамика изменений будет храниться:

Обычно динамика изменений может храниться намного дольше чем история. Любые более старые данные будут удалены с помощью автоматической очистки базы данных (Housekeeper).

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

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

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

Таблицы истории никоим образом не участвуют в генерации динамики изменений.

Перезапуск сервера также может привести к потере точности вычисления усредненных значений у целочисленных типов данных за текущий час.

Источник

Zabbix 4.4.5 Почему размер базы не уменьшается?

Простой 23 комментария

neol,

всё закомментировано. Что там надо изменить?

и
SHOW VARIABLES LIKE ‘innodb_file_per_table’;

И заодно посмотрите что в логах пишут по поводу очистки:

Путь может отличаться.

neol, Требуемое быстродействие сервера 19.69

Вот сам ло часть лога(нельзя вставить сюда более 10000 символов):

16886:20201027:002733.354 executing housekeeper
16886:20201027:002740.707 housekeeper [deleted 42390 hist/trends, 0 items/triggers, 6 events, 2 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 7.351415 sec, idle for 1 hour(s)]
16886:20201027:012751.440 executing housekeeper
16886:20201027:012757.885 housekeeper [deleted 42323 hist/trends, 0 items/triggers, 0 events, 2 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 6.442195 sec, idle for 1 hour(s)]
16886:20201027:022808.798 executing housekeeper
16886:20201027:022815.691 housekeeper [deleted 42321 hist/trends, 0 items/triggers, 2 events, 0 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 6.891708 sec, idle for 1 hour(s)]
16886:20201027:032826.899 executing housekeeper
16886:20201027:032834.343 housekeeper [deleted 42438 hist/trends, 0 items/triggers, 0 events, 1 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 7.442116 sec, idle for 1 hour(s)]
16886:20201027:042845.407 executing housekeeper
16886:20201027:042852.527 housekeeper [deleted 42384 hist/trends, 0 items/triggers, 0 events, 0 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 7.117147 sec, idle for 1 hour(s)]
16886:20201027:052903.821 executing housekeeper
16886:20201027:052911.138 housekeeper [deleted 42326 hist/trends, 0 items/triggers, 9 events, 1 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 7.313612 sec, idle for 1 hour(s)]
16886:20201027:062922.603 executing housekeeper
16886:20201027:062930.401 housekeeper [deleted 42391 hist/trends, 0 items/triggers, 6 events, 0 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 7.797529 sec, idle for 1 hour(s)]
16886:20201027:072941.115 executing housekeeper
16886:20201027:072946.660 housekeeper [deleted 41768 hist/trends, 0 items/triggers, 6 events, 1 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.543927 sec, idle for 1 hour(s)]
1462:20201027:075517.093 server #2 started [housekeeper #1]
2723:20201027:080119.972 server #2 started [housekeeper #1]
2723:20201027:083125.112 executing housekeeper
2723:20201027:083131.185 housekeeper [deleted 42774 hist/trends, 0 items/triggers, 17 events, 19 problems, 1 sessions, 0 alarms, 1 audit, 0 records in 6.072061 sec, idle for 1 hour(s)]
2723:20201027:093140.547 executing housekeeper
2723:20201027:093146.468 housekeeper [deleted 41840 hist/trends, 0 items/triggers, 12 events, 13 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.918032 sec, idle for 1 hour(s)]
2723:20201027:103156.081 executing housekeeper
2723:20201027:103202.258 housekeeper [deleted 41724 hist/trends, 0 items/triggers, 0 events, 4 problems, 0 sessions, 0 alarms, 4 audit, 0 records in 6.174529 sec, idle for 1 hour(s)]
2723:20201027:113212.564 executing housekeeper
2723:20201027:113218.392 housekeeper [deleted 41775 hist/trends, 0 items/triggers, 6 events, 18 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.827587 sec, idle for 1 hour(s)]
2723:20201027:120047.133 forced execution of the housekeeper
2723:20201027:120047.133 executing housekeeper
2723:20201027:120051.988 housekeeper [deleted 19772 hist/trends, 0 items/triggers, 0 events, 2 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 4.854205 sec, idle for 1 hour(s)]
2723:20201027:130101.183 executing housekeeper
2723:20201027:130107.014 housekeeper [deleted 41750 hist/trends, 0 items/triggers, 0 events, 2 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.824747 sec, idle for 1 hour(s)]
2723:20201027:140116.463 executing housekeeper
2723:20201027:140122.555 housekeeper [deleted 41761 hist/trends, 0 items/triggers, 0 events, 2 problems, 0 sessions, 0 alarms, 10 audit, 0 records in 6.084993 sec, idle for 1 hour(s)]
2723:20201027:150132.094 executing housekeeper
2723:20201027:150137.956 housekeeper [deleted 41934 hist/trends, 0 items/triggers, 40 events, 5 problems, 0 sessions, 0 alarms, 6 audit, 0 records in 5.861040 sec, idle for 1 hour(s)]
2723:20201027:160147.398 executing housekeeper
2723:20201027:160153.193 housekeeper [deleted 41944 hist/trends, 0 items/triggers, 14 events, 4 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.793303 sec, idle for 1 hour(s)]
2723:20201027:170202.418 executing housekeeper
2723:20201027:170208.310 housekeeper [deleted 41849 hist/trends, 0 items/triggers, 5 events, 14 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.890620 sec, idle for 1 hour(s)]
2723:20201027:180218.080 executing housekeeper
2723:20201027:180223.715 housekeeper [deleted 41910 hist/trends, 0 items/triggers, 1 events, 18 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.634568 sec, idle for 1 hour(s)]
2723:20201027:190234.257 executing housekeeper
2723:20201027:190240.972 housekeeper [deleted 41939 hist/trends, 0 items/triggers, 7 events, 5 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 6.714017 sec, idle for 1 hour(s)]
2723:20201027:200251.726 executing housekeeper
2723:20201027:200256.681 housekeeper [deleted 41887 hist/trends, 0 items/triggers, 16 events, 1 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 4.953033 sec, idle for 1 hour(s)]
2723:20201027:210307.227 executing housekeeper
2723:20201027:210313.404 housekeeper [deleted 41870 hist/trends, 0 items/triggers, 7 events, 15 problems, 1 sessions, 0 alarms, 0 audit, 0 records in 6.174263 sec, idle for 1 hour(s)]
2723:20201027:220323.361 executing housekeeper
2723:20201027:220328.395 housekeeper [deleted 41941 hist/trends, 0 items/triggers, 0 events, 0 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.031466 sec, idle for 1 hour(s)]
2723:20201027:230338.956 executing housekeeper
2723:20201027:230344.637 housekeeper [deleted 41884 hist/trends, 0 items/triggers, 0 events, 1 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.678305 sec, idle for 1 hour(s)]
2723:20201028:000354.338 executing housekeeper
2723:20201028:000359.410 housekeeper [deleted 40688 hist/trends, 0 items/triggers, 34 events, 1 problems, 0 sessions, 0 alarms, 1 audit, 0 records in 5.071194 sec, idle for 1 hour(s)]
2723:20201028:010410.006 executing housekeeper
2723:20201028:010415.673 housekeeper [deleted 40876 hist/trends, 0 items/triggers, 43 events, 0 problems, 0 sessions, 0 alarms, 1 audit, 0 records in 5.664823 sec, idle for 1 hour(s)]
2723:20201028:020426.314 executing housekeeper
2723:20201028:020432.699 housekeeper [deleted 41908 hist/trends, 0 items/triggers, 33 events, 0 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 6.384172 sec, idle for 1 hour(s)]
2723:20201028:030443.246 executing housekeeper
2723:20201028:030449.558 housekeeper [deleted 41970 hist/trends, 0 items/triggers, 2 events, 4 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 6.311710 sec, idle for 1 hour(s)]
2723:20201028:040500.109 executing housekeeper
2723:20201028:040505.866 housekeeper [deleted 41873 hist/trends, 0 items/triggers, 2 events, 3 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.752221 sec, idle for 1 hour(s)]
2723:20201028:050516.109 executing housekeeper
2723:20201028:050521.840 housekeeper [deleted 41875 hist/trends, 0 items/triggers, 8 events, 1 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.730616 sec, idle for 1 hour(s)]
2723:20201028:060532.428 executing housekeeper
2723:20201028:060538.016 housekeeper [deleted 41989 hist/trends, 0 items/triggers, 51 events, 2 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.585915 sec, idle for 1 hour(s)]
2723:20201028:070547.903 executing housekeeper
2723:20201028:070553.529 housekeeper [deleted 41853 hist/trends, 0 items/triggers, 51 events, 3 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 5.623519 sec, idle for 1 hour(s)]

Источник