Comments 17
"это обычная практика, иметь по несколько PostgreSQL серверов на одном Linux сервере. В девелоперовском контуре их может быть несколько десятков на одном сервере, по одному на каждую команду. И почему профессионалы Zabbix это не учли, для меня большая загадка"
Как раз не загадка, ни разу. В современном мире с легкодоступными средствами виртуализации и контейнеризации я нигде не видел более одного экземпляра БД на машине. Даже на самых "совковых" проектах...
Типичная манипуляция общественным сознанием, использование слово "совковый", хотя оно тут совершенно неприемлемо. Современные средства виртуализации и конвейнеризации настолько глючные, что большинство поломок приходится именно на них. Сам по себе PostgreSQL очень стабилен и с самим PostgreSQL как с софтом никогда не бывает проблем, если только он не размещен на средствах виртуализации и конвейнеризации.
Более того. Отказоустойчивость веб сервисов основана на том, что в самих контейнерах не должно быть никакой информации относящейся к состоянию системы. Прочитайте, это в любом учебнике написано. Поэтому в случае выхода одного контейнера из строя или узла, легко можно поднять запасной. Это достигается как раз тем, что вся информация о состоянии системы находится в базах данных, например на базе PostgreSQL, а вот они находятся как раз не в контейнерах и их отказоустойчивость достигается другими методами.
Плюс потери производительности при виртуализации. Про потерю надежности уже говорил. Ну и, конечно, вопрос денег. Если молятся на модную микросервисную архитектуру это означает что баз данных очень много, но они небольшие и по сложности и по объему. У нас в компании несколько сотен баз данных. Арендовать под каждую виртуалку на точке обмена трафиком это еще и накладно, как по деньгам, так и по потерям производительности. Базы на железных машинах.
Ну не знаю. Возможно мне "везло" со средствами виртуализации. Ничего особо "глючного" никогда не замечал. С контейнерами аналогично. Каждый разработчик понимает себе мини сервак, и после работы просто "грохает", освобождая ресурся.
Даже когда я работал с Ораклом был один экземпляр и разные схемы для разрабов.
С постгресом, у которого нет лицензионных ограничений нет смысла пилить костыли в заббиксе.
И, как видите, мое мнение поддерживают, как минимум разработчики заббикса...
Еще могу сказать что разработка в контейнере != микросервисная архитектура. Но если каждому из десятков разработчиков нужна полноценная база на терабайты "для тестов" - это ясно просчет в организации разработки.
А так вы сейчас пишите про девелоперовский контур. Тут я вас поддерживаю, кстати. Я считаю что у каждого разработчика должна быть своя БД для отлаживания разработки. И я себе всегда такую делал. Впрочем и от общих баз данных для разработки тоже есть польза, в них объединяется труд разных разработчиков и окончательно проверяется перед выкаткой в продакшин. И с них я делал себе копию, если разрабатывал что-то своё.
А основная идея этой стати была в том, что бы такой мониторинг повесить именно что на продакшин с целью чтобы у разработчиков был доступ к информации о проблемах производительности и проблемных запросах на продакшине.
Типичная манипуляция общественным сознанием
Типичный бессознательный бред
Современные средства виртуализации и конвейнеризации настолько глючные, что большинство поломок приходится именно на них
Поверить, конечно, мы должны на слово? )
Сам по себе PostgreSQL очень стабилен и с самим PostgreSQL как с софтом никогда не бывает проблем
Буквально неделю назад 15.4 остановил все записи, нахапал коннекшнов до лимита, и его пришлось убивать ручками.
в самих контейнерах не должно быть никакой информации относящейся к состоянию системы
Docker головного мозга detected
вся информация о состоянии системы находится в базах данных, например на базе PostgreSQL, а вот они находятся как раз не в контейнерах
С чего бы им находиться не в контейнерах?
потери производительности при виртуализации
Показать, где там виртуализция в ядерном lxc — сможете?
Про потерю надежности уже говорил
Теперь ссылка на свое же, ранее ничем не подкрепленное, высказывание в качестве пруфа? )
На поржать сгодится, но ржать над таким — стыдно по испански…
Поставил дизлайк. Потому что все ваши аргументы построены на демагогии и оскорблении личности. Ничего, буквально ни одного аргумента вы не привели, который стоило бы обсудить. Все что вы написали характеризуется вашими же словами "Типичный бессознательный бред". Сплошные эмоции, без капли здравого смысла. Например фраза "Буквально неделю назад 15.4 остановил все записи, нахапал коннекшнов до лимита, и его пришлось убивать ручками." говорит о том, что вы в принципе не понимаете ни того как работает база данных, ни то как надо диагностировать или исправлять ошибки. Это не сервер PostgreSQL "хапает" коннешины, а наоборот, приложение. Вы даже не поняли что является источником проблемы, как следствие даже не пытались обнаружить её и исправить. И проблема с коннекшинами, точно такая же, ждёт вас еще не раз. И главный ваш талант это врать начальству, что это виноваты не вы, а PostgreSQL. Видимо, пока у вас это делать получается.
И раз вы не понимаете даже такие элементарные вещи, то эта статья не для вас. Обратите внимание, что уровень сложности выставлен как "сложный".
Обратите внимание на то, что ваш эпос применим не только к зеркалу, но и к оригиналу в той же мере.
UPD: кстати, к самому эпосу — тоже, что уже дает рекурсию )
Обратите внимание. Вот есть два мнения. У нас базы данных для общего пользования ставятся на железе. Конечно, если нужно было тестировать какую-то экзотику, я ставил их у себя в виртуалках. И я могу свидетельствовать о том, что базы работают стабильно если не годами, то точно месяцами, пока не будут перезагружены, например, для обновления или изменения конфига (добавить модули). Да, бывают проблемы с ошибками веб программистов, но сам postgresql работает стабильно, без нареканий. (За исключением ранних 9.6 версий).
А есть второе мнение, о том как это хорошо и правильно ставить их в виртуалках. И этот же самый сисадмин сетует, что якобы PostgreSQL "заблокировал все записи" и "захапал коннекты", хотя postgresql захапать коннекты никак не может. Если только речь не идет о связи между двумя БД, типа логической репликации, fdw, dblink и т.д. Такое совпадение, что PostgreSQL работает нестабильно именно у того сисадмина, который считает правильным ставить его в виртуалках, говорит о том что проблема вовсе не в PostgreSQL, а либо в виртуалке либо в сисадмине. Highly likely последнее, потому что по симптомам больше похоже на тривиальную жопорукость. У нас было что-то вроде дублирования сетевых пакетов в Кубернетис, но тут другое.
В шаблоне возможно ошибка.
Офф. документация говорит:
pgsql.custom.query[uri,<имя_пользователя>,<пароль>,имя_запроса,<аргументы...>]
5 параметров. У Вас в шаблоне почему-то 6.
Смотрите <аргументы...> подразумевает, что их может быть несколько. :) А может быть ни одного. В custom query такой же механизм как и в UserParameters. Может быть любое количество аргументов, которые потом подставляются в нужные места запроса.
Да, это уже увидел по ошибке в логе.
Хотелось бы отметить, что при разворачивании на простаивающую БД (в стороне от активных действий) некоторые пункты высвечивают состояние "не поддерживается"(и ошибка, что-то вроде: "NULL не есть хорошо для целого"). Некоторые элементы "закрыл" в COALESCE(..., 0).
А, это не баг, а фича. Я писал об этом в статье. Сейчас напишу еще раз, подробнее. Конечно, всегда есть запросы в любую базу, например от заббикс, но я же их отрезаю. Поэтому, если в базе нет нагрузки, то и запросов в pg_stat_statements нет. И данные при запросе не возвращаются в заббикс. Тут есть два варианта, как тут поступить. Один из них - как реализовали вы, вставлять в таком случае пустые значения вместо текстовых данных и 0 вместо цифровых. В этом случае база заббикса будет заполняться строчками содержащими нули и пустоту для простаивающих баз. Второй вариант, это оставлять такие данные null, которые заббикс не понимает и выдает ошибку. Но в таком случае строчки в заббикс попросту не появляются. Такое будет для тех "простаивающих баз" у которых в течении суток не было ни одного запроса. Например базы postgres. Идеальным было бы найти такое значение для этого случая, чтобы и сообщений об ошибке не было и ненужные строчки в базе заббикса не возникали.
Мне мой вариант показался предпочтительнее, чтобы сэкономить место в и так большой базе данных заббикса. Но если это вам портит ощущение прекрасного, можете исправлять. Нет нужды это править в SQL запросе, он всегда отрабатывает нормально и там вы можете выскочить за предел максимальной длины запроса. И нормально все это попадает в json поле. Можете временно включить его запись в историю, чтобы видеть, как он выглядит. Ошибки возникают в depended item, которые забирают данные из json и преобразуют в числа. Если бы такое делал я, то я бы это делал где-то в разделе preprocessing у соответствующих item.
И возможно вы не прочитали мой предыдущий ответ. 6 параметров это нормально и ошибки выдавать не должно. :)
Хочу поблагодарить вас за ваши комментарии. Это сподвигло меня еще раз поискать способ, как сделать так чтобы и ошибок не было и чтобы база нулями не забивалась для бездействующих баз данных. И, оказалось, в Zabbix есть этот функционал, сложность была только его найти. Шаблон в конце статьи переписал на новую версию.
Вопрос: А количество уязвимостей никого не смущает? https://vulmon.com/searchpage?q=zabbix&sortby=bydate&page=1
Смущает. Сложная система с рутовым доступом написанная веб программистами. :) Чего вы хотели? Я старался обращать на это внимание, например цитата из моей статьи:
Я думал о том, чтобы список таких пользователей оформить в виде параметра. Технически это возможно. Но есть опасность, потому что тогда пользователь, обладающий правами редактировать конфигурацию Zabbix, сможет настроить так, что начнёт видеть запросы от суперпользователя. Поэтому список нежелательных пользователей прописан в коде в конфигурационном файле в UserParameter, и изменить его может только сисадмин с правами редактирования этого файла (обычно root) на этом сервере.
Zabbix, PostgreSQL и pg_stat_statements