LLD:как не потерять старые данные, если объект LLD стал идентифицироваться по-другому

[csr]

День добрый

Проще объяснить на примере:

Windows изменилась нумерация дисков, был диск 1, стал диск 2. Такое, увы, часто бывает, особенно при подключении iscsi дисков или чего-то подобного:

было:

perf_counter_en["\PhysicalDisk(1 Y:)\Disk Reads/sec",60]

стало

perf_counter_en["\PhysicalDisk(2 Y:)\Disk Reads/sec",60]

И так может быть по многим дискам, службам, интерфейсам и прочему, что находится через lld

Как не потерять старые данные? Переподключение дисков в правильном порядке не предлагать, это частность, тем более, что не всегда возможная.

Все же сталкивались с таким, кто как решает?

[Semiadmin]

LLD rule может возвращать множество LLD макросов, но на историю влияют только те, что содержатся в параметрах ключа прототипа айтема. Изменение значения любого из этих макросов ведет к созданию из прототипа нового айтема и объявление старого более не обнаруживаемым, и следовательно к прерыванию истории.
Поэтому желательно воздерживаться от использования в ключе меняющихся сущностей. Например, если дискаверится некий сервис, имеющий постоянный id и имя, которое потенциально может измениться, то в ключе стоит использовать id, а в имени прототипа айтема - то самое понятное, но непостоянное имя.
Хуже с приведенным примером, где номер физического диска необходим для получения метрик через перфкаунтер, и поэтому должен быть частью параметра ключа, дабы быть переданным агенту. Я бы попробовал в этом случае отказаться от перфкаунтеров, получать через wmi.getall большой json со статистикой по дискам (например, от класса Win32_PerfRawData_PerfDisk_PhysicalDisk), и сделать зависимые прототипы айтемов, имеющих в ключе только букву диска, а в JSONPath, в препроцессинге - и букву, и номер. Или только букву, и искать ее регуляркой не глядя на номер.

[csr]

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

Пример про диск это частности (но для виртуалок на винде частенько встречающиеся).

Как работает lld я понимаю. Неужели никто не задавался этим вопросом - как сохранить данные, полученные через ллд, если ключ lld изменился? Неужели нет никаких best practice совмещающий lld и долговременное хранение? Опять придумывать личный велосипед?

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

Предвижу совет создавать вручную, но это такое себе, из разряда - давайте перейдем на счеты

[Hamardaban]

Вы «объявили» своей основной задачей долговременное хранение, в то время как возможно основная масса пользователей заббикс имеет другие задачи?
Такие как мониторинг текущего состояния и реакция на выход метрик за установленные пределы?
А долгие данные назад да еще по удаленным метрикам - удел малой прослойки которая не гнушается вдумчиво подходить к сбору и хранению метрик и изобретать велосипеды?

Это так - в порядке «а поговорить».

Согласен - встречались ситуации когда нужны данные по удаленным из lld ЭД и это было неприятно. Но не смертельно.

[csr]

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

вот я и спрашиваю в порядке "а поговорить" и "кто как это решат". без негатива и наезда

[Semiadmin]

Насчет хранения более не обнаруживаемого - есть же Keep lost resources period, аж до 25 лет.
Что касается оповещения - да, кнопки включения такого режима нет, но никто не запрещает сделать прототип триггера.

[csr]

Насчет хранения более не обнаруживаемого - есть же Keep lost resources period, аж до 25 лет.

1. вопрос в том, чтобы хранить непрерывную историю, а не историю кусками: с января до марта смотри тут, с марта до августа здесь, а с августа...
2. не понял по поводу прототипа, объясните плз

[Semiadmin]

1. Все, что мог сказать про непрерывность, рассказал двумя постами выше
2. Если Keep lost resources period не установлен в 0, заббикс будет заданное в нем время пытаться работать с более необнаруживаемыми айтемами и триггерами. Соответственно, можно сделать протип тригера, который среагирует на новое поведение такого айтема. А уж условие триггера пишется исходя из того, что происходит с айтемом, переставшим обнаруживаться.