Шаблон для собора информации о статусе процессов

[Toad_Rash]

Сделал шаблон для собора информации о "disk sleep" процессах.
- В Discovery rule указываю ключ "proc.get". Проверяю, он возвращает JSON:

[
   {
      "pid":1,
      "ppid":0,
      "name":"systemd",
      "cmdline":"/lib/systemd/systemd --system --deserialize 38",
      "user":"root",
      "group":"root",
      "uid":0,
      "gid":0,
      "vsize":171397120,
      "pmem":0.29578540560244176,
      "rss":12197888,
      "data":21733376,
      "exe":835584,
      "hwm":12197888,
      "lck":0,
      "lib":8294400,
      "peak":235130880,
      "pin":0,
      "pte":86016,
      "size":23625728,
      "stk":1056768,
      "swap":0,
      "cputime_user":2091.29,
      "cputime_system":4083.09,
      "state":"sleeping",
      "ctx_switches":3451819,
      "threads":1,
      "page_faults":157
   },​
...
]

- Хорошо, создаю два LLD макроса: "{#PROC.NAME} = $..name" и "{#PROC.STATE} = $..state", которые собирают имя процесса и статус
- Отфильтровываю процессы в состоянии disk sleep: "{#PROC.STATE} matches disk sleep"
- Делаю интервал сбора 5 сек
- Период хранения потерянных ресурсов (Keep lost resources period) 1 час

- Создаю прототип айтема с именем "Process - {#PROC.NAME}" и с ключом "proc.get[{#PROC.NAME}]"
- Интервал 5 сек
- Хранение истории 3 дня
- В препроцессинге "JSONPath = $..state.fitst()"
- Айтем выдает значение в виде текста со статусом пойманного LLD процесса (disk sleep/sleeping/running/idle/... и т.п.)

- Выражение в прототипе триггера ищет 6 диск слипов подряд из истории и говорит, что "{#PROC.NAME} - Disk Sleep for more than 30 sec". Само выражение: count(/Discovering of Proccesses with State - Disk Sleep/proc.get[{#PROC.NAME}],#6,"like","disk sleep")=6


С точки зрения опытных ребят, это нормальная схема для информирования о статусе процессов или можно было бы сделать проще/надежнее?

[Hamardaban]

Позвольте мелкие поправки:
1) наверное всё же так...

 "{#PROC.NAME} = $.name" и "{#PROC.STATE} = $.state"

2) стОит сделать один мастер итем proc.get и от него делать LLD и прототипы как зависимые элементы..
3) если в качестве "уникальности" ключа итема использовать имя процесса то могут быть ошибки дублирования при обнаружении (несколько процессов с одинаковым наименованием)

[Toad_Rash]

Позвольте мелкие поправки:
1) наверное всё же так...

 "{#PROC.NAME} = $.name" и "{#PROC.STATE} = $.state"

2) стОит сделать один мастер итем proc.get и от него делать LLD и прототипы как зависимые элементы..
3) если в качестве "уникальности" ключа итема использовать имя процесса то могут быть ошибки дублирования при обнаружении (несколько процессов с одинаковым наименованием)

1) Нет, все-таки две точки.
2) Спасибо, учту.
3) Да, действительно. Прикрутил PID.

[Hamardaban]

по 1) - как хотите , но разница есть. Вы же ищете вполне определенный элемент? Так почему не использовать явное определение?
Можете привести пример для чего ".." а не "."?

[Toad_Rash]

Для отладки парсинга использовал JSONPath Online Evaluator - jsonpath.com. Так вот, там $..pid находит pid, а $.pid - нет. В Заббиксе то же самое, с двумя точками работает, с одной - нет (возвращает "[]")

[Hamardaban]

В LLD всё срабатывает. Проверено неоднократно.
У вас ключ возвращает массив объектов. Если попытаться разобрать эту конструкцию в JSONPath в элементе данных - то конечно там не найдется $.pid т.к. этому соответствует множество (и какой брать?). Но (насколько я понимаю) LLD работает иначе с таким массивом - он берет один элемент и в нем делает поиск.
По крайней мере в примерах в документации везде используют "definite"

Ради "освежения памяти" сделал такое же обнаружение как у вас и всё работает с "одной точкой"!

Замечал, что JSONPath Online Evaluator штука хорошая, но несколько отличается от реализации JSONPath в забикс

Может коллеги поправят мои измышления боле аккуратно. :-)

Вот как написано в доках

To find a matching segment ignoring its ancestry (detached segment) it must be prefixed with '..' , for example $..name or $..['name'] return values of all 'name' properties.

Matched element names can be extracted by adding a ~ suffix to the JSONPath. It returns the name of the matched object or an index in string format of the matched array item. The output format follows the same rules as other JSONPath queries - definite path results are returned 'as is' and indefinite path results are returned in array. However there is not much point of extracting the name of an element matching a definite path - it's already known.

[Toad_Rash]

Позвольте мелкие поправки:
1) наверное всё же так...

 "{#PROC.NAME} = $.name" и "{#PROC.STATE} = $.state"

2) стОит сделать один мастер итем proc.get и от него делать LLD и прототипы как зависимые элементы..
3) если в качестве "уникальности" ключа итема использовать имя процесса то могут быть ошибки дублирования при обнаружении (несколько процессов с одинаковым наименованием)

Еще дополнительный вопрос появился по пункту 2.
Подскажите, пожалуйста, в каком случае на сервер нагрузки меньше: в моем варианте с фильтрацией состояния процесса уже на уровне правила обнаружения или в предложенном с зависимыми айтемами? У меня ощущение, что когда в Latest data показываются все обнаруженные процессы, то это менее выгодно, чем когда там только один-два процесса с disk sleep состоянием.

[Hamardaban]

Можно вообще не хранить информацию по мастер ЭД.
И фильтровать в LLD тоже можно до создания итемов.
И в зависимых тоже преобразовывать \ фильтровать как угодно для минимизации шума

Основной недостаток выбранного пути через LLD - уникальность ключей. PID - тоже не самое правильное (перезагрузка ОС?)
Наверное нужно иметь что-то составное типа ИМЯ+PID..
Но всё равно этот механизм будет порождать массу неподдерживаемых итемов ожидающих удаления.