Кратко

  • RFC 1224 суммарно ограничивал все оповещения агента через maxAlertsPerTime, windowTime и alertsEnabled.
  • После превышения порога агент один раз отправлял alertsDisabled и прекращал передачу, но это последнее сообщение тоже могло потеряться.
  • Опросный журнал хранил alertId и alertData; чтение или удаление строки не доказывало устранение причины.

Не сообщить и сообщить слишком много

RFC 1224 вышел в мае 1991 года. RFC Editor относит его к Experimental, а IETF Datatracker хранит историю Alert-Man. Документ не задавал условия генерации. Он управлял потоком после появления оповещения.

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

RFC 1157 использовал для SNMP ненадёжные датаграммы, а выбор адресов Trap-PDU оставлял реализации. RFC 1215 предлагал форму определения trap, одновременно настойчиво не рекомендуя плодить новые. Синтаксис не был квитанцией о доставке.

Скользящий предел намеренно создавал тишину

Механизм pin сочетал число maxAlertsPerTime с периодом windowTime. Считалась общая сумма всех типов у одного агента.

После запуска alertsEnabled имел значение true. При каждом локальном событии агент проверял флаг: false запрещал отправку, true позволял её и сохранял время. Когда заданное количество помещалось в окно, агент отправлял единственный alertsDisabled и переводил флаг в false.

Так сохранялись процессор, полоса и способность менеджера принимать решения. Однако уведомление о прекращении уведомлений могло пропасть. Поэтому менеджеру предлагалось регулярно опрашивать флаг, включать его снова и отмечать возможную потерю traps за тихий интервал. Отсутствие трафика стало результатом управления, а не доказательством здоровья.

Таблица давала ограниченное хранение

Для каждого локального оповещения журнал создавал возрастающий alertId и OPAQUE-копию alertData. Менеджер мог запросить следующую или конкретную строку и при поддержке удалить её через SET либо DELETE. RFC 1189 даёт контекст операций CMOT/CMIP, на которые опиралось сравнение.

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

Идентификатор подтверждал создание локальной записи. Он не доказывал отправку, доставку, чтение до перезаписи, правильность содержания или действия оператора. Удаление меняло таблицу, но не состояние услуги. У нескольких менеджеров могли быть разные пороги и представления; действие одного не определяло другого. Вопросы безопасности RFC 1224 не рассматривал, поэтому SET или DELETE не удостоверяли личность и полномочия.

Источники