SNMP나 API를 고르기 전에 VPN 객체를 정의하라

전송 방식보다 앞서 경보가 어떤 객체를 설명하는지, 어느 방향과 범위를 다루는지, 읽기가 얼마나 최신이어야 하는지라는 세 가지 결정이 있다. SNMP, HTTPS API, 애플리케이션 프로브는 모두 VPN에 관해 무언가를 보고할 수 있지만 같은 것을 보고하지는 않는다. 이 세 가지를 정하지 않고 프로토콜을 바꾸면 혼란이 모이는 위치만 달라진다. 객체와 경보의 의미가 설계이고, 프로토콜은 전달일 뿐이다.

네 가지 서로 다른 관측을 하나의 초록 아이콘으로 바꾸는 대시보드는 이미 그 결정을 잘못 내렸다.

경보는 실제로 무엇을 뜻해야 하는가?

피어가 인증할 수 없다는 뜻일 수도, 보호된 데이터 상태가 없다는 뜻일 수도, 경로가 잘못된 곳을 가리킨다는 뜻일 수도, 애플리케이션이 작업을 끝내지 못한다는 뜻일 수도 있다. 각각은 고유한 소유자와 고유한 첫 점검, 고유한 거짓 양성 비율을 가진다. 인증할 수 없는 피어는 신원 문제이고, 빠진 보안 연관은 프로토콜 상태 문제이며, 경로는 구성 문제이고, 애플리케이션 실패는 그중 어느 것도 아닐 수 있다. 수집기를 고르기 전에 경보가 무엇을 위한 것인지 정하라.

당직 엔지니어가 행동할 수 있는 문장으로 써라. 문장에 객체가 둘 필요하다면 그것은 경보 두 개이지, 반쯤 맞는 하나가 아니다.

TCP 표는 TCP를 설명한다

RFC 4022는 tcpConnectionTable를 규정하며, 그 행은 설정된 TCP 연결을 양 끝의 주소 유형, 주소, 포트를 키로 설명한다. 연결이 닫히면 행은 사라지고, 수신 대기 소켓은 다른 표에 나타난다. 같은 장비에서 VPN을 돌린다고 TCP 표가 IPsec 보안 연관 목록이 되지는 않는다. 관리 세션, 애플리케이션 흐름, TCP로 전달되는 터널을 설명할 수 있지만 행 자체가 어느 것인지 알려 주지는 않는다.

인터페이스 카운터는 더 거친 수준에서, 인터페이스의 바이트가 그것을 쓰는 모든 피어와 모든 흐름을 합산한다는 같은 모호성을 지닌다.

작은 관측 계약을 세워라

각 지표마다 지원되는 객체나 API 필드, 소유 장치와 소프트웨어 버전, 피어나 서비스 식별자, 방향, 수집 시각, 예상 갱신 동작을 기록하라. 그다음 프로토콜 상태에는 게이트웨이의 문서화된 연관 또는 세션 보기를, 경로 상태에는 라우팅 표를, 애플리케이션 상태에는 좁게 허용된 요청을 사용하라. 동작하는 관리 엔드포인트는 관리 엔드포인트가 동작함을 증명할 뿐, 그 뒤의 애플리케이션에 관해서는 아무것도 말하지 않는다.

설치된 에이전트에 필요한 객체가 없다면 명시적으로 지원되는 다른 읽기 전용 인터페이스를 골라라. OID를 지어내거나, 일반 TCP 수를 터널 수로 읽거나, 오래된 벤더 API가 자매 제품에서 그대로 유지되리라 기대하는 것은 모두 막다른 길이다.

오래된 데이터는 터널 장애가 아니다

수집 시간 초과, 만료된 자격 증명, 변경된 API 경로는 누락된 텔레메트리를 만든다. 그것은 모니터링 실패이며 끊긴 터널과는 다른 사건이다. 어느 관측이 언제 오래되었는지 기록해, 운영자가 터널 재설정 대신 의미 있는 첫 점검을 받게 하라. 모든 시간 초과를 VPN 중단으로 다루면 사람들은 둘 다 무시하게 된다.

수집 권한도 좁게 유지하라. 구성을 바꾸거나 세션을 지울 수 있는 인터페이스는 모니터링 작업이 물려받아서는 안 되는 권한 경계를 지니며, 읽기 전용 계정이면 보통 충분하다.

쓸모 있는 설계는 객체와 의미, 최신성 요구를 명시한다. 프로토콜 선택은 그로부터 나오며, 그 반대가 아니다.