요약

  • RFC 1224는maxAlertsPerTime,windowTime,alertsEnabled상태를 통해 에이전트의 알림 총량을 제한했습니다.
  • 한도를 초과하면 에이전트는alertsDisabled를 한 번 보낸 뒤 멈추는데, 이 정지 통지 자체가 전달되지 않을 수도 있습니다.
  • 에이전트는 폴링 가능한 기록에alertId와alertData를 보관하지만, 읽기나 삭제는 고장 처리를 증명하지 않습니다.

침묵은 안심의 신호가 아니라 잠재적 실패였다

RFC 1224는 1991년 5월에 발행되었습니다.RFC Editor 레지스트리는 이를 실험적 문서로 분류하며,IETF Datatracker는 Alert-Man 작업 안에서 그 정체성을 보관하고 있습니다. 문서는 알림의 생성 조건이나 내용을 정하지 않고, 생성 이후의 정보 이동을 다뤘습니다.

위험은 이중적이었습니다. 고장 난 장치나 네트워크는 고장을 보고하지 못할 수도 있고, 불안정한 링크는 관리자의 처리 능력과 관리 경로를 소모하는 알림 홍수를 만들어낼 수도 있습니다. 따라서 시스템은 과잉을 억제하는 동시에, 손실을 감지하거나 잃어버린 정보를 재구성해야 했습니다.

RFC 1157은 SNMP 메시지를 신뢰할 수 없는 데이터그램 서비스 위에 두고, Trap-PDU의 대상 선택을 구현에 맡깁니다.RFC 1215는 trap 정의를 표준화하면서 그 남발에 대해 강력히 경고합니다. 구조의 정합성이 도착의 증거를 만들지는 않습니다.

측정 창이 의도된 침묵을 만들었다

‘핀(pintle)’ 메커니즘은 두 가지 한계를 사용했습니다: 개수 한도maxAlertsPerTime과 시간 창windowTime입니다. 계산은 에이전트에서 모든 종류의 알림을 합산했습니다.

alertsEnabled는 참 상태로 시작합니다. 로컬 알림이 발생할 때마다 에이전트는 이 상태를 검사하고, 거짓이면 보내지 않고, 참이면 보낸 뒤 시각을 기록합니다. 창 안에서 정해진 개수에 도달하면alertsDisabled를 한 번 보내고 상태를 거짓으로 바꿉니다.

이 조치는 프로세서, 대역폭, 관리자를 보호했지만 새로운 빈틈을 열었습니다. 메시지 정지를 알리는 그 메시지 자체가 전달되지 않을 수 있습니다. 그래서 RFC 1224는 관리자가 상태를 주기적으로 폴링하고, 재활성화하며, 침묵 기간 동안 trap이 유실될 가능성을 기록하도록 권고했습니다. 이제 트래픽 부재는 문제 부재의 증거가 아니었습니다.

기록은 임시 보관이었다

두 번째 경로에서는 각 알림이 증가하는alertId와alertData의 OPAQUE 값을 담은 행을 만듭니다. 관리자는 다음 행이나 특정 번호를 요청할 수 있고, 구현이 지원한다면 쓰기나 삭제 작업으로 그 행을 지울 수 있습니다.RFC 1189는 RFC 1224가 비교에 사용한 CMOT/CMIP 작업의 맥락을 제공합니다.

이 기록은 자동 전송의 성공에 의존하지 않지만, 한정적입니다. 테이블이 가득 차면 새 행이 가장 오래된 행을 대체합니다. 가장 오래된 것부터 제공하면 유실 위험을 줄일 뿐 막지는 못합니다.

번호는 에이전트가 기록을 생성하고 어느 시점에 보관했음을 증명합니다. 값의 전송, 도착, 대체 전의 회수, 또는 그 값이 현실을 정확히 기술했는지는 증명하지 않습니다. 행의 삭제는 저장 상태를 바꿀 뿐; 어떤 사람의 승인, 수리, 서비스 복귀를 증명하지 않습니다.

여러 관리자는 community에 따라 서로 다른 한도, 상태, 값을 볼 수 있습니다. 한쪽의 조치가 다른 쪽에 대해 자동으로 권위를 갖지 않습니다. 또한 RFC 1224는 보안을 다루지 않는다고 명시했으므로, SET이나 DELETE만으로는 문서화된 신원이나 권한을 증명할 수 없습니다.

출처