요약

  • RFC 3055는 PINT 서비스를 서버 측 관리 표면에서 측정 가능하게 만들었고, 총계를 서비스, 시간 창, 클라이언트, 사용자, 게이트웨이별로 구분했습니다.
  • 이 카운터들은 유용한 영수증이었지만, "성공"은 에이전트가 유지하는 분류에 불과했습니다. 사람이 응답했는지, 내용을 들었는지, 읽을 수 있는 팩스를 받았는지를 독립적으로 증명하지 않았습니다.

인터넷 쪽에서 본 전화 서비스

PINT — PSTN/Internet Interworking 아키텍처 — 는 유용한 비대칭에서 출발했습니다. 인터넷은 전화망이 되지 않고도 전화망에 행동을 요청할 수 있었습니다. 하나의 요청으로 두 당사자에게 전화를 걸고, 팩스를 보내고, 저장된 자료를 팩스로 회신받고, 콘텐츠를 전화로 음성 재생할 수 있었습니다. 요청은 행정적·기술적 경계를 넘었습니다. 실행의 중요한 세부 사항은 PSTN 내부에 남을 수 있었습니다.

그 경계 덕분에 모니터링은 유난히 중요해졌습니다. 웹 지향 서비스가 요청을 수락하는 동안 게이트웨이는 그 요청을 거부할 수 있었습니다. 게이트웨이가 요청을 받아들이는 동안 전화 측은 실패할 수 있었습니다. 사람이 아예 응답하지 않을 수도 있었습니다. 팩스 호출은 한 계층에서는 완료되었지만 다른 계층에서는 읽을 수 없는 페이지를 만들어낼 수 있었습니다. 운영자는 낙관적인 HTTP 응답이나 일반적인 서버 하트비트보다 나은 증거가 필요했습니다.

RFC 3055가 그 과제를 위한 관리 정보 베이스(MIB)를 제공했습니다. 2001년 2월에 Proposed Standard로 발표되었으며, IANA가 할당한mib-2번호 93 아래의 SMIv2 모듈을 정의했습니다. 이 MIB는 의도적으로 좁았습니다. PINT 고유의 서비스 성능만 모니터링했고, 네트워크 구성 요소를 관리하지 않으며, 관련 호스트·네트워크 성능은 명시적으로 범위 밖에 두었습니다.

그 좁힘은 결함이 아니라 증거의 정직함의 시작이었습니다.

네 가지 서비스, 네 개의 시간 창, 네 가지 집계 방식

MIB는 Request-to-Call, Request-to-Fax, Request-to-Fax-Back, Request-to-Hear-Content라는 네 가지 서비스 유형을 이름 지었습니다. 시간 창도 네 가지였습니다. 최근 30초, 최근 15분, 최근 24시간, 재부팅 이후.

그리고 같은 운영 세계를 네 개의 서로 다른 축으로 노출했습니다.

글로벌 테이블은 서버 전체 관점을 제공했습니다. 수신된 호출, 성공한 호출, 단절된 호출을 세고, 일부 실패를 클라이언트 또는 사용자 인증 실패, 서버 문제, 게이트웨이 문제로 나눴습니다.

클라이언트 테이블은 사람이 읽을 수 있는 문자열로 표현된 클라이언트 주소별로 활동을 묶었습니다. 수신, 성공, 단절, 클라이언트 인증 실패, 송출 설비 문제를 세었습니다.

사용자 테이블은UserIdName에 대해 비슷한 일을 했습니다. 게이트웨이 테이블은 등록된 게이트웨이 이름별로 수신, 성공, 단절된 호출을 묶었습니다.

이들은 네 개의 독립적 목격자가 아니었습니다. 에이전트는 게이트웨이 관련 행동을 보고할 때를 포함해 PINT 서버에서 작동하는 것으로 기대되었습니다. 네 테이블은 계측된 서비스 표면을 통과하는 네 개의 절단면이었습니다. 비교해 보면 질문을 좁힐 수는 있었습니다. 실패가 특정 클라이언트, 특정 사용자, 특정 게이트웨이에 집중되는가? — 하지만 일치한다고 해서 서버 측 계정 기록이 전화망 추적으로 변하지는 않았습니다.

위험한 단어는 "성공"이었다

pintServerGlobalSuccessfulCalls는 결정적으로 들립니다. 클라이언트, 사용자, 게이트웨이 카운터도 마찬가지입니다. 그러나 MIB는 수화기 옆마다 인간 관찰자를 배치하거나 팩스 기기마다 스캐너를 설치하지 않았습니다. 구현이 자신의 분류를 보고하는 경유 객체들을 명시했을 뿐입니다.

이 구분이 중요한 이유는 PINT가 의도적으로 서로 다른 시스템을 연결했기 때문입니다. 인터넷 측에서는 수락된 서비스 요청 자체가 의미 있는 진전일 수 있습니다. 게이트웨이에서는 성공적인 인계가 또 하나의 영수증일 수 있습니다. 전화망 내부에서는 응답, 재생, 팩스 협상, 콘텐츠 전송이 추가 조건을 도입했습니다. 끝단에서는 사람이 무음을 들을 수도, 음성을 오해할 수도, 읽을 수 없는 페이지를 버릴 수도 있었습니다.

RFC 3055는 그 연쇄를 닫겠다고 주장하지 않았습니다. 객체 설명에는 "successfully completed"라는 표현을 썼지만, 카운터 증가는 여전히 에이전트의 계측과 구현이 선택한 이벤트 경계에 속했습니다. 구현 규칙과 거래 증거, 하류 관찰이 없다면 "성공"이라는 단어는 그 단어를 만들어낸 계층 이상의 무게를 질 수 없었습니다.

이것은 카운터를 반대하는 논거가 아닙니다. 카운터의 영수증 경계를 보이게 유지하자는 논거입니다.

숫자에는 이전, 이후, 그리고 연속성 이야기가 필요하다

성능 테이블의 모든 서비스 카운트는Counter32를 사용했습니다. SMIv2는 그 유형을 2^32−1까지 증가하다가 0으로 되돌아가는 음수가 아닌 값으로 정의합니다. 그리고 모든 운영 콘솔 위에 걸어야 할 원칙도 명시합니다. 단일 카운터 값은 일반적으로 정보 내용이 없다는 것.

17,000이라는 값은 비율이 아닙니다. 시스템이 바빴는지, 유휴 상태였는지, 복구 중이었는지, 재설정되었는지를 말하지 않습니다. 유용한 주장에는 최소한 두 개의 경계가 있는 샘플과, 두 샘플 사이에 카운터가 연속적으로 유지되었다고 믿을 이유가 필요합니다.

RFC 3055는sinceReboot창에 대해 이 문제를 짚었습니다. 소비 애플리케이션이 카운터가 최대치에 도달해 0으로 돌아가는 것을 감안해야 했습니다. 재부팅은 또 하나의 경계를 만들었습니다. 롤링 창은 자체 질문을 더했습니다. 30초 창은 언제 잘렸는가, 두 에이전트가 그 기준을 맞추었는가, 놓친 폴링이 비교를 지워버렸는가?

이후의 Application MIB 작업은 불연속 표시기를 더 명시적으로 만들었습니다. 그 후대의 규율은 유용한 맥락이지, 모든 PINT 구현이 그것을 제공했다는 증명은 아닙니다. RFC 3055 증거에 대한 보수적 규칙은 그대로입니다. 샘플 시각, 관찰 지점, 시간 창, 이전 값, 재부팅 상태, 랩 해석을 함께 기록할 것.

없는 행은 깨끗한 0이 아니었다

사용자·클라이언트 뷰는 대가를 치르는 진단 정밀성을 약속했습니다. RFC 3055는 이 테이블들이 상당한 자원을 요구할 수 있음을 인정했습니다. 사용자 행의 노화(aging)는 로컬 구현에 맡기고, 고수준 디버깅을 위한 미래의 top-N 메커니즘을 언급했습니다.

그 선택은 부재에 대해 몇 가지 정당한 의미를 만들었습니다. 사용자 행이 없는 이유는 활동이 없어서일 수 있습니다. 노화로 사라졌을 수도 있습니다. 에이전트가 비용이 큰 세부 정보를 구현하지 않았을 수도 있습니다. 다른 서버에서 식별자가 다르게 구성되었을 수도 있습니다. 자원 한도가 일부만 보존했을 수도 있습니다.

사용자 식별자 자체에도 아키텍처적 가정이 담겨 있었습니다. 관련 PINT 서버와 게이트웨이 전반에서 고유하고 세션 식별자에 매핑되어야 했습니다. 클라이언트 식별자와 타임스탬프를 덧붙이는 것이 가능한 구성 중 하나로 제안되었습니다. 따라서 테이블 키는 관찰된 트래픽뿐 아니라 식별 정책도 반영했습니다.

없는 행을 0으로 다루면 두 사실이 모두 지워집니다.

MIB에는 자체 경종 벨이 없었다

RFC 3055는 알림(notification)을 정의하지 않았습니다. 대신 카운터에 임계값을 적용하는 표준 방법으로 Remote Monitoring MIB를 지목했습니다. 예컨대 한 클라이언트에서 반복되는 로그인·인증 실패, 한 사용자의 성가신 통화 같은 것.

그 위임은 PINT 모듈을 작게 유지했지만 경보 의미론을 다른 곳으로 옮겼습니다. RMON 알람은 선택된 변수, 샘플링 간격, 샘플 유형, 상승·하강 임계값, 연관된 이벤트에 의존합니다. 침묵은 아무것도 선을 넘지 않았다는 뜻일 수 있습니다. 알람이 구성되지 않았거나, 관련 테이블에 접근할 수 없거나, 샘플링 경계가 전환을 가리거나, 전달이 실패했다는 뜻일 수도 있습니다.

트랩이 없다고 해서 건강 영수증이 되는 것은 아닙니다.

읽기 전용이었다고 무해한 것은 아니었다

PINT MIB에서 읽기-쓰기 가능한 객체는 서비스 관리자 연락처 하나뿐이었고, read-create 객체는 없었습니다. 저위험 모듈처럼 보일 수 있습니다. RFC 3055는 그 지름길을 거부했습니다.

사용자 식별자는 고객 신원을 드러낼 수 있었습니다. 클라이언트·게이트웨이 슬라이스는 관계를 노출할 수 있었습니다. 서비스·실패 볼륨은 상업적으로 민감한 성능을 드러낼 수 있었습니다. 테이블을 GET만 할 수 있는 관리자도 누가 서비스를 사용했는지, 실패가 어디에 쌓였는지, 트래픽이 어떻게 변했는지를 알 수 있었습니다.

RFC는 SNMPv1만으로는 보안 환경이 만들어지지 않는다고 경고하고, 당시 최신인 SNMPv3 사용자 보안 모델과 뷰 기반 접근 제어 모델을 권했습니다. 암호화된 네트워크조차 주체 수준의 질문에 답하지 않습니다. 누가 어떤 객체를 읽거나 바꿀 자격이 있는가? 이후 RFC들이 그 SNMPv3 문서들을 대체했지만, 그 출판이 PINT 에이전트가 그것을 사용했다는 증명은 아닙니다.

따라서 모니터링 표면에는 두 가지 증거 의무가 있었습니다. 카운터의 의미를 보존하는 것, 그리고 그것에 대한 접근의 정당성을 보존하는 것.

RFC 3055가 실제로 표준화한 것

영속적인 성취는 PINT가 끝에서 끝까지 관찰 가능해졌다는 주장이 아니었습니다. 더 좁은 질문을 던지기 위한 공통 어휘이었습니다.

어떤 서비스였는가? 어떤 시간 창에서? 카운트가 글로벌이었는가, 클라이언트·사용자·게이트웨이에 키가 매겨졌는가? 에이전트가 그 작업을 수신, 성공, 단절 중 어느 것으로 분류했는가? 어느 넓은 실패 계열을 배정했는가? 카운터는 언제 초기화되거나 랩되었는가? 어떤 주체가 답을 읽을 자격이 있었는가?

이 질문들은 운영을 더 읽기 쉽게 만듭니다. 하지만 서버의 계정과 물리적 결과 사이의 유리를 없애지는 못합니다.

출처

Lu Heng은 RFC 3055를 저자하지 않았고 이를 보증하지도 않았습니다. 그의 에세이는 이 글에서 공개된 분석적 렌즈로만 사용되었습니다. RFC 2458에 크레딧된 H. Lu는 독립적인 신원 증거 없이는 동일 인물로 다루어지지 않습니다.