Тоесть через —link? docker run --name zabbix-afent --link zabbix-server:zabbix-server -d zabbix/zabbix-agent:latest

Вообще я имел в виду - линковать приложение, которое нужно мониторить и агента. Чё-то вопрос мало понятен, на самом деле.

Имеется 8 докеров контейнеров. Как их мониторить с помощью zabbix? Zabbix так же располагается в докере. А вот так?)

Т.е. ребята пытались выкрутиться, получая из одного ЭД и обнаружение и метрики, но в итоге потеряли немного функционала. LLD лучше бы делать в какого-нить win32_diskdrive, а метрики - элементы данных на perf_counter. Но это такое вот имхо )

Это дискавери.. Там метрики не дергаются еще, там они формираются

там на основе этого дискавери еще одно поддискавери, в котором уже формируются элементы..

Еще как дёргаются. Там JSONPath'ом выдёргиватся препроцессингом они

ну если даже и дергаются, то не используются для получения данных

В смысле? У нас не может быть вложенных LLD.

Ну там зависимое дискавери, которое на базе того элемента wmi.get, которое я тебе скинул. Зависимое дискавери парсит явой вывод этого элемента и просто оттуда дергает названия для макросов.. и уже потом, на основе названий формирует метрики нормлаьные, типа:
vfs.dev.queue_size[CurrentDiskQueueLength.{#DEVNAME}]
vfs.dev.read.rate[DiskReadsPersec.{#DEVNAME}]

просто этот запрос wmi.getall исползуется потом для нескольких дискавери

Хм, а я глянул в win32_diskdrive еще, так с него нужного и не получить даже. Надо же.

ммм.. не совсем понял, чего не получить?

Я имел в виду инфы для LLD, чтобы создать айтем для perf_counter. Там отсутствуют данные о точке монтирования, вроде "0 C:"

Ну я так понял логику всей этой цепочки:
есть элемент, который делает запрос:
wmi.getall[root\cimv2,"select * from win32_perfformatteddata_perfdisk_physicaldisk"]
дальше на базе этого запроса есть discovery, которое парсит вывод (жсон, который я скидывал) и формирует как раз макросы с помощью препроцессинга:

output = JSON.parse(value).map(function(dev){
   return {
       "{#DEVNAME}": dev.Name,
       "{#DEVQUEUE}": dev.CurrentDiskQueueLength,
       "{#DEVREADS}": dev.DiskReadsPersec,
       "{#DEVTIME}": dev.PercentDiskTime,
       "{#DEVWRITES}": dev.DiskWritesPersec
   }})
return JSON.stringify({"data": output})

дальше уже на базе этих макросов говздятся элменты..
Причем используется только один макрос, по-сути - {#DEVNAME}, остальные просто не использутся вообще никак..

но я могу ошибаться..
и я наивно полагал, что модифицируя базовый запрос wmi.getall, можно еще получить в дискавери тип диска (ну типа fixed, removable...).. и фильтрануть по этому макросу как раз то, что мне надо..

для этого надо, чтобы эта инфа была в классе win32_perfformatteddata_perfdisk_physicaldisk, а ее там, как я понимаю, нет

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

Надо изучить WMI ) может быть есть более подходящий класс для дискавери.

TTL начинается с 1ч