хранится как текст, конечно же. но у него числовой тип там.

У текста числовой тип?

то, что он в начале написал про отправку строки, в общем-то, было просто неверной формулировкой.

нет, он числовое значение выплёвывает один хрен

Вот ещё один прикольный пример https://m.habrahabr.ru/company/zabbix/blog/252915/

так что вы рано парня загнобили (:

костыль - да, логи в бд - нет

вот тут дичь, да

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

говорю ж, формулирует он неверно. в батнике у него значение в виде строки, но содержит число.

а, нет, всё же есть правда... кидает "ок". но один фиг это не "логи в бд" (:

whatever

нет-нет, подобный кейс имеет место быть. разумного применения требует лишь. разница большая.

даже простое "ок", которое валится в бд каждые 30 секунд конкретно забивает бд

На самом деле тут надо смотреть

1. Сколько времени это все хранится. 2. Объем, т.е. сколько таких ок с девайсом полетит.

Как по мне Graylog с Elastic'oм, где то даже плагин видел чтоб грейлог трапил в заббикс

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

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

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

Так а что мешает трапить не текст, а как ты написал например некий код (0, 1,2 и тд) в заббиксе есть сопоставление