Zabbix 7.0.3 стал зависать fronend (вход в админку)

[D.Frolov]

1. Установил Zabbix 7.0.3
2. Отмучился, все настроил и был счастлив, НО недолго
3. Раз в 2-3 суток НАГЛУХО зависает вход в админку, выглядит как на скрине (ZabbixError.png)
4. Помогает включение, выключение VPS, есть мысли про мало диска, см скрин (HostingDisk), на скрине кажет 16ГБ, а до перезагрузки было 18.8...
5. Дополнение, видимо кончается место, см скрин (ZabbixSpaceAvailable.png)
6. Прикрепил скрин как "пропало", место см.скрин (ZabbixSpaceAvailable5month.png)

З,Ы Куда он съело столько место? Ну там 2 десятка хостов, по паре шаблонов?? Что можно предпринять (кроме покупки доп. места на жестком диске). Прошу, пожалуйста, поделится мыслями по данному вопросу.

[Kos]

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

[PavelZ]

З,Ы Куда он съело столько место? Ну там 2 десятка хостов, по паре шаблонов??

Так надо посчитать.
Есть пара известных руководств по подсчету в виде SQL-запросов :
Что-то древнее: https://blog.hostname.sk/2014/02/cal...-by-sql-query/
Или вот знаменитый в узких кругах сисадмин-Владимир пишет https://serveradmin.ru/chto-zanimaet...dannyh-zabbix/
Эти запросы не очень точны, так как есть dependent items и строковые значения переменного размера.

Считать фактические показатели нет смысла - это очень медленно из-за особенностей БД. Но можно считать items как записи о намерениях.
В принципе, если вы можете выкачать БД себе на мощный ПК, реально посчитать с точностью до байта. Но таких руководств просто нет по вышеописанной причине.

[PavelZ]

Ах да, если бы вас было настроено секционирование (partitioning) в БД, можно написать такой запрос, чтобы он выбирал только одну секцию и результаты проэкстраполировать на весь набор данных.

[D.Frolov]

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

Кое-что нашлось - 1.9G /var/log/journal

[D.Frolov]

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

Есть такая штука - housekeeper, что скажите с точки зрения практики, какие данные на какую историческую глубину надо хранить? (Я просто как-то видел Ваши скриншоты и там вообще, кое-где в item видел "не хранить"), поэтому, хотелось бы услышать рассуждения по данному вопросу?

[Kos]

Есть такая штука - housekeeper, что скажите с точки зрения практики, какие данные на какую историческую глубину надо хранить? (Я просто как-то видел Ваши скриншоты и там вообще, кое-где в item видел "не хранить"), поэтому, хотелось бы услышать рассуждения по данному вопросу?

Ну, рассуждать-то можно долго, но мы у себя придерживаемся такой практики:

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

[D.Frolov]

Ну, рассуждать-то можно долго, но мы у себя придерживаемся такой практики:

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

Спасибо за ответ, а вот в очистке, как действуйте? (см. скриншот)

[Kos]

Спасибо за ответ, а вот в очистке, как действуйте? (см. скриншот)

Не помню, чтобы там что-то менял. Кажется, всё по умолчанию.

[D.Frolov]

Спасибо за ответ.

[D.Frolov]

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

Прочел "лучшие практики" - https://www.zabbix.com/documentation...best_practices тут ничего нет про это, не могли бы или пояснить или дать прочесть, как надо?

[Kos]

Прочел "лучшие практики" - https://www.zabbix.com/documentation...best_practices тут ничего нет про это, не могли бы или пояснить или дать прочесть, как надо?

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