так заббикс прокси есть, но как заставить через нее опрашивать комманды на хосте?*

Эээ, в настройках хоста указать, что мониторим с этой прокси.
Или я чего-то не понимаю

да, стоит, извини, там скорее всего в хосте проблема

Добрый день! Прошу помощи.
Для логической репликации БД нужно чтобы все таблицы имели первичный ключ.

А поскольку в БД zabbix наличие таких таблиц имеет место быть я со своей стороны вижу два решения этой проблемы.

1. Добавить для каждой таблицы свой первичный ключ.
ALTER TABLE my_table ADD COLUMN id SERIAL PRIMARY KEY;
2. Использовать целиком таблицу как ключ
ALTER TABLE my_table REPLICA IDENTITY FULL;

Какое решение более оптимальное и какие могут быть подводные камни в связи с этими возможными решениями?

Ну вот не помогает в данном случае гугл к сожалению.

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

Текущая                    Целевая
Denian-9                     Debian-10
zabbix-server 4.0     zabbix-server5.0
postgresql-9.6          postgresql-12

Пишет not supported, когда добавляю на item ssh агента за проксей

попробую через externalcheck и трапперы

Всё я не понимаю логику работы LLD видимо. Вот у меня есть  LLD Discovery rule. Она выплёвывает JSON со списком грубо говоря параметров, к каждому из которых применяется Item prototype и соответственно создаётся Item. Но в Item prototype жёстко задан тип. Если в прототипе строка - то все Item будут типа строка. В Overrides собственно Discovery rule можно поменять разное, но не тип Item. Я предполагаю, что мне придётся делать несколько Item prototype c фильтрами, которые будут последовательно применяться к полученному по discovery JSON-списку. Так или не так?

так то оно так
только как будто вы что-то не то делаете
у вас дискавери должен же однотипные данные дискаверить - и одинаковые. соответтвенно

если из вашего JSON вываливается куча всего - имхо, правильнее сделать на каждый тип свой дискавери

хм. но почему? вот например смарт-параметры. их удобно отдавать один раз одной пачкой, а тип разный

это можно решить если отдавать в raw ийтем, а на основе него делать нужное количество dependet discovery

т.е. если у меня данные 4 типов, мне нужно делать одну и ту же по сути операцию 4-жды. это неоптимально. с учётом того, что discovery запускается периодически, вызовов будет в 4 раза больше.

dependent discovery требует похода на хост за новой порцией данных?

а 4 типа прототипа Items не получается разве сделать?

а вот тут и вопрос - это работает так как я предполагаю?

а мы тут не мысли ваши не читаем )

а я в первосм сообщении написал 😊 дублирую

нет. данные приходят один раз и из общей простыни фильтрами разбираются во все зависимые элементы за один раз

Я предполагаю, что мне придётся делать несколько Item prototype c фильтрами, которые будут последовательно применяться к полученному по discovery JSON-списку. Так или не так?

а в чём тогда различие с несколькими прототипами?