С чем больше опыта - самый лучший совет
Иначе потом будет тяжело траблшутить в случае ЧП

Тоесть в целом штатная работа на любом конфиге будет +- одинакова?
С субд отличия понятны. Например размер записи в таблице разный (сравнивая Oracle/Postgre)

Ну на сотню хостов оно вам точно не критично это

Принято, спасибо Андрей.

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

У нас есть http agent.

Через него за один вызов только одно значение можно положить?

Почему? Ты можешь получить и распарсить JSON

То есть например если джисон будет иметь скажем десять записей "таймстемп: value", то их все можно будет положить в один итем с соответствующим таймстемпом?

Как текст, можно. Будет в Zabbix'e лежать этот JSON одним куском. Я не понимаю чего ты хочешь получить в конце.

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

И что, нужно просто все, как есть, положить в заббикс?

нужно положить в заббикс с соответствующим таймстемпом из джисона каждое значение отдельно

Ну блин, то всё про скрипты и сендер тогда.

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

Почему?

Коллеги а напомните пожалуйста про требование к БД для использования сжатия а то установил на PostgreSQL 11 а в ответ   Compression is not available due to incompatible DB version

Столкнулся с причудой в LLD items.
Если создавать прототип вида systemd.unit.info[ssh.service]systemd.unit.info[ssh.service] без какого либо LLD макроса в ключе, то при дискавери выдаст: Cannot create item: item with the same key "systemd.unit.info[ssh.service]systemd.unit.info[ssh.service]" already exists.
Хотя его в действительности такого итема вообще пока не создано) Слегка неправильное сообщение однако

А какое сообщение ты бы ожидал?

Правило для каждого объекта в Json пытается создать айтемы с одним и тем же ключом.