Junos 텔레메트리 이해하기
Junos Telemetry는 주니퍼 네트웍스에서 개발한 프레임워크로, Junos 디바이스에서 외부 수집기로 운영 데이터를 내보낼 수 있습니다. 이 데이터는 실시간 디바이스 모니터링을 위해 분석됩니다. 이 주제에서는 모델 기반 텔레메트리, 텔레메트리 모드, 전송 프로토콜, 텔레메트리 센서, 센서 경로 및 Junos Telemetry에서 사용되는 데이터 모델의 개념에 대해 설명합니다.
네트워크 텔레메트리
네트워크 텔레메트리는 네트워크 디바이스에서 데이터를 수집, 전송 및 분석하는 프로세스입니다. 이러한 데이터에는 트래픽 패턴, 디바이스 상태, 오류율 및 네트워크의 상태 및 동작에 대한 인사이트를 제공하는 기타 메트릭에 대한 정보가 포함될 수 있습니다. 이 데이터를 사용하여 유용한 통찰력을 도출하고 이 정보를 적용하여 네트워크 성능과 보안을 효과적으로 모니터링하고 관리할 수 있습니다. 네트워크 관리자는 텔레메트리 데이터를 사용하여 네트워크 문제를 해결하고, 이상 징후를 탐지하고, 네트워크 전반에서 리소스 활용을 최적화할 수 있습니다. 네트워크 텔레메트리의 주요 이점 중 하나는 네트워크 운영에 대한 실시간 가시성을 제공할 수 있다는 것입니다.
네트워크 텔레메트리는 또한 네트워크 보안을 강화하는 데 중요한 역할을 합니다. 보안 팀은 텔레메트리 데이터를 분석하여 사이버 공격 또는 기타 보안 위협을 나타낼 수 있는 비정상적인 패턴을 식별할 수 있으므로 잠재적인 보안 사고를 더 빠르게 탐지 및 대응하고 네트워크와 해당 데이터를 보호하는 데 도움이 됩니다.
Junos 텔레메트리
Junos Telemetry는 텔레메트리 데이터를 스트리밍하기 위해 개발된 주니퍼의 텔레메트리 솔루션입니다. 확장성이 뛰어나며 네트워크에서 원격으로 디바이스 모니터링을 지원할 수 있습니다. 또한 문제 해결을 개선하고 네트워크를 선제적으로 관리하며 운영 비용을 절감하는 데 도움이 됩니다.
Junos Telemetry는 다음과 같은 다양한 네트워크 시나리오에 적용할 수 있습니다.
- 성능 모니터링: 인터페이스 활용률, 지연 시간, 패킷 손실과 같은 주요 지표를 모니터링하여 최적의 네트워크 성능을 보장합니다.
- 보안 모니터링: 보안 이벤트를 추적하고, 트래픽 패턴을 분석하고, 잠재적인 보안 위협을 식별합니다.
- 애플리케이션 성능 관리: 네트워크 데이터와 애플리케이션 데이터의 상호 연관성을 통해 애플리케이션 성능에 대한 인사이트를 얻을 수 있습니다.
- 네트워크 용량 계획: 과거 및 실시간 데이터를 분석하여 잠재적인 병목 현상을 식별하고 향후 용량 요구 사항에 대비한 계획을 세웁니다.
다른 주니퍼 애플리케이션도 Junos Telemetry를 활용하여 실시간 데이터를 제공하여 네트워크 요소와 외부 컨트롤러(예: 주니퍼의 Mist, 주니퍼의 Routing Director, Apstra) 간의 운영 상태 동기화를 지원합니다.
모델 기반 텔레메트리
Junos Telemetry는 MDT(Model Driven Telemetry) 아키텍처를 채택했습니다. 모델 기반 네트워크 텔레메트리 시스템은 데이터 모델을 활용하여 네트워크 디바이스에서 텔레메트리 데이터를 정의하고 수집하는 네트워크 모니터링에 대한 고급 접근 방식입니다. 이 시스템에서 데이터 모델은 수집 또는 스트리밍할 데이터의 구조와 유형을 지정하기 위해 YANG(Yet Another Next Generation) 언어를 사용하여 정의됩니다.
주니퍼는 현재 다음과 같은 다양한 데이터 모델을 지원합니다.
-
주니퍼 네이티브 데이터 모델
-
OpenConfig 데이터 모델
-
Genstate 모델
모든 모델은 YANG을 사용하여 스트리밍할 데이터 구조와 데이터 유형을 지정하며, 자세한 내용은 데이터 모델을 참조하십시오.
올바른 데이터 모델을 선택하는 것은 특정 요구 사항에 따라 달라집니다. 모든 모델의 센서를 동시에 구독할 수 있습니다. 네이티브 센서는 다양한 사용 사례를 지원하는 데 있어 우위를 점합니다.
아래 단계에 따라 모델 기반 텔레메트리 솔루션을 설정합니다.
텔레메트리 데이터를 스트리밍하도록 주니퍼 디바이스를 설정합니다 . 주니퍼 디바이스가 Junos 텔레메트리를 지원하는 호환 Junos OS 버전을 실행하고 주니퍼 디바이스와 수집기 간의 네트워크 연결이 있는지 확인합니다.
- 데이터 수집기 설정: 데이터를 수집하고 디코딩하도록 수집기를 구성합니다. 자세한 내용은 텔레메트리 데이터 수집기를 참조하세요.
- 전송 프로토콜 설정: 데이터 전송에 적합한 전송 프로토콜을 선택하고 구성합니다. 자세한 내용은 전송 프로토콜을 참조하십시오.
- 센서 구성: 센서 프로필은 모니터링 및 스트리밍할 시스템 리소스의 매개 변수를 정의합니다. 하나의 시스템 리소스만 활성화하여 각 센서 프로필을 모니터링하거나 각 시스템 리소스에 대해 다른 센서 프로필을 구성할 수 있습니다. 그러나 동일한 시스템 리소스를 모니터링하기 위해 둘 이상의 센서를 구성할 수 있습니다. 자세한 내용은 센서 및 센서 경로를 참조하십시오.
- 구독 만들기: 모니터링해야 하는 데이터 스트림에 대한 구독을 설정합니다. 텔레메트리 세션은 디바이스 또는 수신자가 구독을 시작하도록 구성되었는지 여부에 따라 전화 접속 모드 또는 전화 접속 모드에서 설정할 수 있습니다. 자세한 내용은 텔레메트리 모드를 참조하세요.
센서 및 센서 경로
텔레메트리 센서는 텔레메트리 솔루션의 중요한 구성 요소입니다. 다양한 물리적, 환경적, 성능 매개변수를 측정하고 원격 모니터링 및 분석을 위해 TCP 또는 UDP 연결을 통해 수집기로 전송되는 데이터로 변환합니다. 몇 가지 예로는 온도 센서, 인터페이스 센서, 유량 센서 등이 있습니다. 텔레메트리 센서 경로는 YANG을 사용하여 정의된 데이터 모델 내의 특정 경로로, 네트워크 디바이스에서 수집 및 스트리밍할 정확한 데이터를 지정합니다. 주니퍼는 Openconfig, 네이티브 및 genstate 모델의 센서를 모두 지원합니다. Openconfig 센서는 카운터 기반 또는 상태 기반 메트릭을 추적하고, 네이티브 센서는 심층적인 디바이스 데이터에 액세스할 수 있으므로 이벤트 기반 메트릭을 효과적으로 추적합니다. 벤더 중립적인 형식으로 센서 정보를 검색하도록 Openconfig 기반 센서 경로를 구성하거나 네이티브 형식으로 주니퍼 독점 정보를 검색하도록 네이티브 센서 경로를 구성할 수 있습니다. 자세한 내용은 센서 경로 탐색을 참조하십시오.
텔레메트리 데이터 수집기
텔레메트리 수집기는 텔레메트리 데이터의 데이터 수집, 처리, 전송 및 저장을 수행하는 특수 도구 또는 소프트웨어입니다. 텔레메트리 데이터를 생성하는 Junos 디바이스와 데이터를 저장, 분석 및 시각화하는 백엔드 시스템 사이의 중개자입니다.
데이터 수집기의 기능:
- 데이터 수집: 수집기는 gRPC 또는 UDP 연결을 통해 주니퍼 디바이스로부터 텔레메트리 데이터를 수신합니다.
- 데이터 처리: 수집기는 수집된 데이터를 집계 및 정규화하여 처리하여 불필요한 정보를 필터링하고 메트릭을 집계하며 초기 분석을 수행합니다. 이러한 처리는 데이터 볼륨을 줄이고 가장 중요한 메트릭에 집중하는 데 도움이 됩니다.
- 데이터 전송: 안정적인 데이터 전송과 짧은 대기 시간을 보장합니다.
- 데이터 저장: 처리된 데이터는 추가 분석, 시각화 및 저장을 위해 다양한 백엔드 시스템으로 내보내집니다. 장기 분석 및 과거 비교를 위해 데이터 레이크에 저장할 수 있습니다. 수집기는 여러 데이터 형식과 프로토콜을 지원하므로 다양한 모니터링 및 분석 도구와 호환됩니다. 분석된 데이터는 대화형 대시보드와 보고서를 통해 표시되어 네트워크 관리자에게 실행 가능한 통찰력을 제공할 수 있습니다.
텔레메트리 모드
Junos Telemetry는 다음 두 가지 모드로 텔레메트리 세션을 지원합니다.
주니퍼 장치는 전화 접속 및 전화 접속 모드 모두에서 작동할 수 있습니다. 네트워크의 토폴로지에 따라 어느 모드에서든 주니퍼 디바이스를 구성할 수 있습니다. 두 모드 모두 동일한 데이터 모델을 사용하고 네트워크를 통해 동일한 텔레메트리 데이터를 스트리밍합니다. 두 모드의 차이는 수집기 또는 주니퍼 디바이스가 연결을 시작하고 유지하는지에 따라 달라집니다.
구독 유형
Junos Telemetry는 다양한 구독 모드를 지원하므로 특정 요구 사항과 조건에 따라 맞춤형 데이터 수집이 가능합니다. 구독 모드는 CLI 명령을 사용하여 디바이스에서 구성되거나 텔레메트리 유형에 따라 구독 요청의 일부입니다. 이러한 모드는 데이터 스트림의 동작을 결정합니다. 스트리밍 간격은 디바이스와 수집기 간의 텔레메트리 데이터 전송 빈도를 결정합니다. 데이터 수집 및 스트리밍은 특정 조건이 충족되거나 텔레메트리 데이터의 수집 및 스트리밍을 시작하는 이벤트가 발생할 때 트리거됩니다. 이러한 트리거를 통해 특정 기준이 충족될 때 데이터가 수집됩니다. 예를 들어, 패킷 손실이 감지되면 텔레메트리 데이터를 수집하고 스트리밍할 수 있습니다. 지원되는 구독 모드는 다음과 같습니다.
- 한 번: 텔레메트리 데이터에 대한 일회성 요청입니다. 구독된 데이터의 현재 상태에 대한 스냅샷이 필요한 경우 이 구독 유형을 구성할 수 있습니다. 디바이스는 텔레메트리 데이터를 수집기로 한 번 전송하고 중지합니다.
- 설문 조사: 텔레메트리 데이터를 주기적으로 온디맨드로 검색합니다. 이 구성은 특정 간격으로 센서를 모니터링하는 데 적합합니다. 전화 접속 시나리오에서 수집기는 이러한 유형의 구독을 통해 텔레메트리 데이터를 구독한 다음 필요에 따라 정보를 폴링합니다.
- 스트림: 이 지속적인 구독은 구성된 트리거가 발생할 때 데이터를 지속적으로 스트리밍합니다.
참고: 모든 센서(OpenConfig 또는 네이티브)가 모든 유형의 구독을 지원하는 것은 아닙니다.
구독 모드
Junos 텔레메트리는 다음과 같은 구독 모드를 지원합니다.
- ON_CHANGE: 디바이스는 모니터링되는 데이터가 변경될 때만 업데이트를 보냅니다(예: 인터페이스 카운터 증가 또는 상태 반전 등). 이 모드는 시간 기반이 아닌 이벤트 기반 메트릭에 적합합니다.
- 샘플: 텔레메트리 업데이트는 구성된 간격에 따라 정기적으로 스트리밍됩니다. 이 모드는 시간이 지남에 따라 샘플링되는 패킷 수 또는 전송된 바이트와 같은 메트릭에 적합합니다.
- TARGET_DEFINED: 디바이스는 모니터링되는 센서 또는 리소스를 기반으로 최상의 모드(SAMPLE 또는 ON_CHANGE)를 결정합니다. 센서에 대해 명시적으로 지원되지 않는 한 주니퍼의 구현은 기본적으로 SAMPLE ON_CHANGE 될 수 있습니다.
-
참고: 구성 경로에 대한 TARGET_DEFINED 구독 요청은 ON_CHANGE 요청으로만 처리됩니다.
-
네트워크에 적합한 텔레메트리 구성 결정
네트워크 토폴로지 및 데이터 요구 사항에 따라 적절한 센서, 구독 유형 및 구독 모드가 결정됩니다. 예를 들어, OpenConfig 센서를 SAMPLE 구독 모드와 함께 사용하면 표준화된 주기적 모니터링(예: 멀티벤더 대시보드 지원)을 받을 수 있습니다. 하드웨어 문제 해결과 같은 주니퍼별 또는 이벤트 기반 인사이트의 경우 ON_CHANGE 구독 모드에서 네이티브 센서를 사용합니다.
전송 프로토콜
전송 프로토콜은 Junos 디바이스와 텔레메트리 수집기 간에 텔레메트리 데이터가 전송되는 방식을 정의합니다.
지원되는 프로토콜은 다음과 같습니다.
-
TCP(전송 제어 프로토콜)
-
UDP(User Datagram Protocol)
TCP
TCP는 Junos Telemetry에서 지원하는 기본 프로토콜입니다. TCP는 연결 지향적이고 스테이트풀이며 안전한(TLS 지원) 기능이므로 데이터를 안정적으로 전송할 수 있습니다. TCP는 전화 접속 및 전화 접속 텔레메트리 모드에서 지원됩니다. 이는 사전 gNMI(주니퍼 독점) 및 gNMI와 같은 텔레메트리 메커니즘의 기반 레이어를 형성합니다.
| 전화 접속 | 다이얼 아웃 | |
|---|---|---|
| 운송 | TCP | TCP |
| 세션 | HTTP/2 | HTTP/2 |
| RPC 프레임워크 | gRPC | gRPC |
| 텔레메트리 API | gNMI | gNMI |
| 데이터 모델 |
|
|
텔레메트리를 구성하고 텔레메트리 메시지를 디코딩하려면 gNMI 구독, gRPC 서비스 구성, 지원되는 데이터 유형, 주니퍼 GitHub 리포지토리 및 Protobuf 압축 메시지 형식(주니퍼 독점)을 참조하십시오.
UDP
UDP는 Junos Telemetry에서 지원하는 경량 비연결 전송 프로토콜입니다. UDP는 전화 접속 텔레메트리 모드에서 지원됩니다.
| 전화 접속 | 다이얼 아웃 | |
|---|---|---|
| 운송 | - | UDP |
| 세션 | - | - |
| RPC 프레임워크 | - | gRPC |
| 텔레메트리 API | - | - |
| 데이터 모델 | - |
|
UDP 텔레메트리에서 프로토 파일은 텔레메트리 메시지 구조를 디코딩하는 데 필요합니다. 텔레메트리 메시지를 구성하고 디코딩하려면 UDP를 통한 텔레메트리 데이터 스트리밍, 센서 데이터 캡슐화 형식, 지원되는 데이터 유형, 주니퍼 GitHub 리포지토리 및 Protobuf 컴팩트 메시지 형식(주니퍼 독점)을 참조하십시오.
데이터 모델
Junos Telemetry 데이터 모델은 YANG(Yet Another Next Generation)을 사용하여 네트워크 디바이스에서 수집된 텔레메트리 데이터의 구조를 정의합니다. YANG은 Junos Telemetry에서 네트워크 디바이스의 구성, 운영 상태 데이터 및 원격 절차 호출(RPC)을 정의하는 데 사용되는 표준 기반의 확장 가능한 데이터 모델링 언어입니다. Junos Telemetry에서 YANG 모델은 인터페이스 통계와 같은 센서를 포함하는 데이터 모델의 구조와 세부 정보를 표현합니다. YANG 표준은 RFC 6020 및 RFC 7950에 정의되어 있습니다.
주니퍼 네트웍스는 주니퍼 GitHub 리포지토리에서 다운로드할 수 있는 Junos 디바이스용 YANG 모듈을 게시합니다. 릴리스 23.4부터는 구성 및 텔레메트리 YANG 모델이 병합되어 주니퍼 GitHub 리포지토리에 게시됩니다. 여기에는 구성, RPC 및 텔레메트리 모델에 대한 YANG 정의가 포함됩니다.
OpenConfig 작업 그룹은 OpenConfig 데이터 모델을 정의합니다. 네트워크를 구성하고 관리하기 위한 벤더 중립적인 데이터 모델입니다. OpenConfig 데이터 모델은 데이터를 유니버설 키/값 형식의 GPB(Google Protocol Buffers) 메시지로 생성합니다. Junos Telemetry를 사용하면 OpenConfig 모델을 활용하여 네트워크에 대한 보다 광범위하고 벤더에 구애받지 않는 뷰를 확보할 수 있습니다. Openconfig 센서 경로는 Openconfig 데이터 모델을 기반으로 센서에서 센서 정보를 검색하는 데 사용됩니다. 자세한 Openconfig 리소스 경로 탐색은 Junos YANG 데이터 모델 탐색기를 참조하십시오.
주니퍼 네이티브 데이터 모델은 주니퍼가 개발한 확장 가능한 개방형 프레임워크입니다. 이 모델은 주니퍼 디바이스에서 발견되는 고유한 기능에 대한 텔레메트리 데이터를 스트리밍하는 데 사용됩니다. 여기에는 인터페이스 통계, 라우팅 정보, 보안 메트릭 등이 포함됩니다. 또한 네이티브 모델을 사용하면 엔터프라이즈별 센서를 정의할 수 있습니다. 주니퍼 또는 엔터프라이즈별 센서의 정보에 액세스하려면 주니퍼 네이티브 센서를 구독하십시오. 네이티브 센서 경로는 네이티브 데이터 모델을 기반으로 센서에서 센서 정보를 검색하는 데 사용됩니다. 네이티브 센서용 주니퍼의 YANG 모듈은 GitHub의 주니퍼 YANG 리포지토리에서 구입할 수 있습니다.
Genstate 모델은 운영 상태 데이터에서 파생된 자동 생성된 YANG 모델입니다. genstate YANG 모델은 gNMI 구독 RPC를 통해 show 명령 데이터의 하위 집합을 노출합니다. gNMI 텔레메트리 수집기는 게시된 모델에 정의된 리소스 경로를 구독하여 특정 상태 데이터를 얻을 수 있습니다. gNMI 구독을 구성하려면 gNMI 구독을 참조하십시오. 수집기는 genstate 모델을 사용하여 리소스 경로 쿼리를 실행하여 특정 운영 상태 데이터를 검색합니다. 각 루트 태그는 단일 genstate 모델(즉, 루트 태그당 하나의 YANG 파일)에 해당합니다.
센서 경로 살펴보기
텔레메트리 센서 경로는 모니터링해야 하는 데이터 포인트 또는 메트릭에 대한 계층 경로를 설명합니다. 관련 데이터를 식별, 활성화 및 스트리밍하는 데 사용됩니다. Junos Telemetry는 Openconfig, Genstate 및 네이티브 센서 경로를 지원합니다.
-
Openconfig 센서 경로
Openconfig 센서에서 데이터 수집을 구성하려면 구독 및 센서 경로(예: )
/interfaces/interface/state/counters를 정의하고 데이터 수집기를 설정하고 주니퍼 네트웍스 지원 페이지에서 Junos Telemetry 프로토콜 버퍼 파일을 다운로드합니다. 수집기에서 캡처한 데이터를 캡처하고 디코딩합니다. -
네이티브 센서 경로
네이티브 센서 경로는 Junos OS(예
/junos/system/line card/interface/: )에 따라 다르며, 디바이스별 메트릭에 대한 세분화된 주니퍼 최적화 액세스를 제공합니다.구독 모드는 CLI 명령을 사용하여 디바이스에서 구성되거나 텔레메트리 유형에 따라 구독 요청의 일부입니다. 프로토콜 버퍼의 파일을 사용하여 수집기에서 센서 데이터를 디코딩합니다.
-
젠스테이트 센서 경로
Genstate 리소스 경로는 네트워크 디바이스에서 Genstate YANG 데이터 모델을 통해 노출된 상태 데이터를 검색하는 데 사용됩니다. genstate YANG 모델은 gNMI 구독 RPC를 통해 show 명령 데이터의 하위 집합을 노출합니다. genstate 모델 리소스 경로에는
/genstate/. 예를 들어, 수집기는 mpls lsp 이름을 검색하기 위해 다음 쿼리를 보냅니다.genstate:/genstate/mpls-lsp-information/rsvp-session-data/rsvp-session/mpls-lsp/name참고:genstate YANG 모듈에 대한 자세한 내용과 주어진 show 명령에 대한 해당 모듈 및 사용 가능한 리소스 경로를 검색하는 방법은 Junos Genstate YANG 데이터 모델을 참조하십시오.
지원되는 show 명령 및 루트 경로를 보려면 Genstate YANG 데이터 모델을 참조하십시오.
모든 경로 유형을 통해 JSON 또는 XML과 같은 형식으로 데이터를 구조화하여 출력할 수 있으므로 효율적인 모니터링 및 분석을 위해 외부 수집기와의 호환성이 보장됩니다.
센서 경로 탐색기
주니퍼 네트웍스 Junos YANG 데이터 모델 탐색기는 지원되는 모든 리소스 경로, 해당 리프 및 이를 지원하는 디바이스 플랫폼을 확인할 수 있는 온라인 도구입니다. 이를 통해 다양한 데이터 모델 속성을 탐색하거나 비교할 수 있습니다. 소프트웨어 릴리스 번호 또는 제품에 기반한 필터 옵션을 사용하여 각 플랫폼의 리소스 경로 및 센서 목록을 확인합니다.
텔레메트리 센서 경로 선택
모델 기반 텔레메트리 시스템에서 센서 경로는 데이터 모델의 컨테이너 계층 내의 모든 수준에서 끝나도록 구성할 수 있습니다. 필요한 텔레메트리 정보를 기반으로 광범위한 데이터 세트를 검색하거나 매우 구체적이고 특정 센서에 대한 대상 정보를 검색하도록 센서 경로를 구성할 수 있습니다. 예를 들어, 센서 경로는 라우터의 모든 인터페이스 통계를 포함하는 컨테이너를 가리킬 수도 있고, 특정 인터페이스의 패킷 손실과 같은 단일 메트릭에 초점을 맞춰 보다 세분화될 수도 있습니다.
예를 들어, 디바이스에서 생성된 알람에 대한 텔레메트리 데이터를 수신하려면(OpenConfig 데이터 모델 사용) 필요한 센서 데이터의 세분성에 따라 다음 리소스 경로 중 하나를 구성할 수 있습니다.
/system/alarms/alarm/id: 이 경로는 알람 ID만 검색합니다./system/alarms/alarm/config: 이 경로는 자세한 알람 정보를 검색합니다.
올바른 센서 경로를 구성하면 효율적인 텔레메트리 시스템을 보장할 수 있습니다. 각 리소스 경로는 전역, 즉 시스템 전체에서 시스템 리소스에 대한 데이터 스트리밍을 활성화합니다. 각 리소스 경로를 수정하여 논리적 또는 물리적 인터페이스를 지정할 수 있습니다. 리소스 경로 "/interfaces/interface/config"는 전역, 물리적 인터페이스 수준에서 구성 가능한 항목 목록을 검색하는 반면, 경로 "/interfaces/interface/config/name"는 인터페이스 이름을 지정하며, 디바이스는 인터페이스 유형에 따라 이 리프에 허용되는 값을 제한할 수 있습니다.
센서 경로에 대한 중요 지침 및 명명 규칙
대부분의 경우 센서를 구성할 때 완전하고 직접적인 리소스 경로를 제공해야 합니다. ""/components/component/와 같은 부분적인 리소스 경로를 제공하면 구성이 불완전해지고 오류가 발생할 수 있습니다. 이러한 리소스 경로는 해당 계층 내에서 사용 가능한 모든 옵션을 검색하고 표시해야 하므로 디바이스에 상당한 부하를 가할 수 있습니다. 이를 방지하려면 항상 전체 리소스 경로를 확인하고 사용하여 정확하고 효율적인 센서 구성을 보장하십시오.
시스템 구성 요소에 계층 구성 요소 명명 규칙을 사용합니다. 이 규칙은 라우팅 엔진 및 CHASSIS0:FPCx:PICy:NPUz 네트워크 처리 장치(NPU)와 CHASSIS0:REx 같은 루트 노드에서 시작하는 전체 경로를 사용하여 정확한 구성 요소 식별을 허용합니다.
다음 표에는 구성 요소 이름이 변경된 방식의 예가 포함되어 있습니다.
| 구성 요소 범주 |
이전 이름 |
새 이름 |
|---|---|---|
| 섀시 |
|
|
| 컨트롤 보드(CB) |
|
|
| 팬 트레이 |
팬 트레이, 팬 트레이 0 |
|
| 팬 |
팬 트레이 0 팬 0 |
|
| FPC |
|
|
| RE CPU |
|
|
| FPC CPU(논리적) |
|
|
| FPC CPU(코어) |
|
|
| PIC |
|
|
| 참조 |
|
|
| NPU |
|
|
| DP |
|
|
| 포트 |
|
|
| XCVR |
|
|
| 오크 |
|
|
| 차선 |
|
|
| FPM |
|
|
| 미드플레인 |
|
|
| PSM |
|
|
| 라우팅 엔진(RE) |
|
|
| FTC |
|
|
| SIB |
|
|
| RE 부트로더 |
|
|
| RE BIOS |
|
|
| 2월 |
|
|
예를 들어 전체 경로의 예 fpc 는 /components/component[name="CHASSIS0:FPC0"]/state/parent : CHASSIS0입니다.
구성 요소 명명 규칙에 대한 자세한 내용은 인터페이스 명명을 참조하십시오
센서 경로 예
| 전체 센서 경로 | 부분 센서 경로 |
|---|---|
/interfaces/interface/subinterfaces/subinterface/state/counters/out-pkts |
/interfaces/interface |
/junos/system/linecard/interface/logical/ usage/ 생성하는 구독 경로
/interfaces/interface/ 는 키 이름 리프
parent_ae_name 및
init_time (리프 이름에 밑줄 포함)를 보고합니다. 스트리밍 경로를
/ junos/system/linecard/interface/queue/ 생성하는 구독 경로
/interfaces/interface/state/ 는 키 이름 리프
parent-ae-name
init-time 와 (리프 이름에 하이픈 포함)를 보고합니다.
Junos Evolved 디바이스의 성능은 서비스 구성에 따라 일부 프로세스 또는 데몬이 활성화되는 서비스 기반 아키텍처를 통해 최적화됩니다. 이러한 프로세스는 서비스가 구성될 때까지 비활성 상태로 유지됩니다. 텔레메트리 구독이 비활성 서비스를 대상으로 하는 경우 텔레메트리 출력이 생성되지 않습니다.
센서 데이터 캡슐화 형식
Junos 텔레메트리는 프로토콜 버퍼(gpb) 형식으로 데이터를 내보내는 두 가지 방법을 지원합니다. 이 섹션에서는 UDP를 통해 텔레메트리 데이터를 내보낼 때 네이티브 센서에서 사용하는 데이터 형식에 대해 설명합니다. 데이터는 UDP 헤더에 캡슐화되며, 이 헤더는 IPv4 페이로드에 추가로 캡슐화됩니다. 이 텔레메트리 모델은 구성된 센서에서 생성된 데이터를 데이터 플레인에서 직접 내보내는 분산 아키텍처를 따릅니다. 컨트롤 플레인을 우회함으로써 이 접근 방식은 다른 중요한 기능을 위한 컨트롤 플레인 리소스를 보존하는 데 도움이 됩니다.
네이티브 센서는 UDP를 사용하여 소스에 가까운 데이터를 내보냅니다. 물리적 인터페이스 통계, 방화벽 필터 카운터 통계 또는 레이블 스위치 경로(LSP)에 대한 통계와 같은 다양한 유형의 텔레메트리 데이터를 내보낼 수 있습니다. 센서는 활성화되는 즉시 데이터를 내보내기 시작합니다.
센서 데이터는 라는 단일 구조화된 프로토콜 버퍼 메시지 TelemetryStream로 표시됩니다. 아래에 표시된 메시지 또는 .proto 파일에는 라인 카드, 패킷 포워딩 엔진 또는 라우팅 엔진과 같이 데이터 소스를 식별하는 여러 속성이 포함되어 있습니다. 구성된 센서의 이름도 포함됩니다. 센서를 구성하는 방법에 대한 자세한 내용은 센서 경로 탐색을 참조하세요. 지원되는 네이티브 센서 목록은 센서(Junos Telemetry Interface)를 참조하십시오.
또한 스트리밍 서버 또는 수집기에 지원되는 모든 센서에 대한 파일을 다운로드 .proto 해야 합니다. OpenConfig 및 YANG 모델 파일을 다운로드하려면 웹 브라우저를 열고 https://www.hpe.com/us/en/networking/hpe-juniper-networking.html 로 이동한 다음 지원을 클릭하여 https://support.juniper.net/support/ 에서 주니퍼 지원 포털을 엽니다. 다운로드 탭을 선택하고 제품 이름 입력 필드에 제품 이름을 입력한 다음 제품 찾기를 클릭하고 필요한 제품을 검색하여 선택한 다음 드롭다운 목록에서 적절한 Junos OS및 소프트웨어 버전을 선택합니다. 같은 페이지에서 아래로 스크롤하여 + 도구 섹션을 확장한 다음 필요한 파일(OpenConfig 모델용 JUNOS Telemetry Interface 데이터 모델 파일 및 YANG 파일용 YANG 모듈 )을 다운로드합니다. 스트리밍 서버 구성에 대한 자세한 내용은 스트리밍 서버(Junos 텔레메트리 인터페이스)를 참조하십시오.
Protobuf 컴팩트 메시지 형식(주니퍼 독점)
수집기로 스트리밍되는 정보는 (텔레메트리_top.proto 파일)의 TelemetryStream 최상위 메시지 구조를 사용하여 전송됩니다. 메시지에는 스트리밍되는 센서 데이터의 메타데이터(예: 센서 경로, 데이터가 전송되는 시스템, 데이터가 전송되는 노드 등)가 포함됩니다. 실제 센서 데이터는 최상위 메시지의 확장으로 전송됩니다. 센서 데이터에 대해 별도의 프로토 파일이 전송됩니다. 텔레메트리_top.proto 파일과 센서 프로토 파일은 수집기에서 센서 데이터를 디코딩하는 데 사용됩니다.
텔레메트리_top.proto 파일의 구조
message TelemetryStream {
required string system_id = 1
[(telemetry_options).is_key = true];
optional uint32 component_id = 2
[(telemetry_options).is_key = true];
optional string sensor_name = 4
[(telemetry_options).is_key = true];
….
optional EnterpriseSensors enterprise = 101;
}
message EnterpriseSensors {
extensions 1 to max;
}
extend EnterpriseSensors {
// re-use IANA assigned numbers
optional JuniperNetworksSensors juniperNetworks = 2636;
}
message JuniperNetworksSensors {
extensions 1 to max; → ends with the extension message
}
이 파일은 메시지로 끝납니다.extension
센서 프로토 파일의 구조
이 파일은 메시지로 시작합니다.extension
extend JuniperNetworksSensors { → begins with the extension message
optional Port jnpr_interface_ext = 3;
}
message Port {
repeated InterfaceInfos interface_stats = 1;
}
message InterfaceInfos {
required string if_name = 1
[(telemetry_options).is_key = true];
optional uint64 init_time = 2;
…..
}
이 메시지에는 TelemetryStream 다양한 유형의 데이터를 전달하는 선택적 중첩 구조도 포함되어 있습니다. 중첩된 구조는 다음과 같이 EnterpriseSensors. 개인적으로 정의된 센서 데이터를 전달할 수도 있습니다. 아래 예 참조:
//
// This file defines the top level message used for all Juniper
// Telemetry packets encoded to the protocol buffer format.
// The top level message is TelemetryStream.
//
import "google/protobuf/descriptor.proto";
extend google.protobuf.FieldOptions {
optional TelemetryFieldOptions telemetry_options = 1024;
}
message TelemetryFieldOptions {
optional bool is_key = 1;
optional bool is_timestamp = 2;
optional bool is_counter = 3;
optional bool is_gauge = 4;
}
message TelemetryStream {
// router name or export IP address
required string system_id = 1 [(telemetry_options).is_key = true];
// line card / RE (slot number)
optional uint32 component_id = 2 [(telemetry_options).is_key = true];
// PFE (if applicable)
optional uint32 sub_component_id = 3 [(telemetry_options).is_key = true];
// configured sensor name
optional string sensor_name = 4 [(telemetry_options).is_key = true];
// sequence number, monotonically increasesing for each
// system_id, component_id, sub_component_id + sensor_name.
optional uint32 sequence_number = 5;
// timestamp (milliseconds since 00:00:00 UTC 1/1/1970)
optional uint64 timestamp = 6 [(telemetry_options).is_timestamp = true];
// major version
optional uint32 version_major = 7;
// minor version
optional uint32 version_minor = 8;
optional IETFSensors ietf = 100;
optional EnterpriseSensors enterprise = 101;
}
message IETFSensors {
extensions 1 to max;
}
message EnterpriseSensors {
extensions 1 to max;
}
extend EnterpriseSensors {
// re-use IANA assigned numbers
optional JuniperNetworksSensors juniperNetworks = 2636;
}
message JuniperNetworksSensors {
extensions 1 to max;
}
주니퍼 네트웍스와 같은 개별 회사는 엔터프라이즈 센서가 생성하는 속성을 정의하고 유지합니다. 각 회사에는 고유한 속성 식별자가 할당됩니다. 현재 규칙은 각 속성에 대해 IANA 할당 엔터프라이즈 MIB 식별자를 사용하는 것입니다. 주니퍼 네트웍스의 경우 할당된 식별자는 2636입니다.
권장: 특정 메시지 유형을 내보내고 수신했는지 확인하려면 gpb 메시지에서 해당 TelemetryStream.enterprise.juniperNetworks 속성을 확인합니다.
의미 체계 및 해당 스키마를 포함하여 센서 데이터에서 수집한 각 요소에 대한 설명은 표 5 를 참조하십시오.
| 요소 유형 |
설명 |
|---|---|
| 카운터 |
단조롭게 증가하는 부호 없는 정수입니다. 최대값에 도달하면 다시 0에서 시작합니다. |
| 게이지 |
값을 늘리거나 줄일 수 있는 부호 없는 32비트 또는 64비트 정수입니다. 이 요소가 나타내는 데이터의 예로는 대기열 깊이 또는 온도와 같은 특정 리소스의 즉각적인 값이 있습니다. |
| 요금 |
카운터 또는 게이지와 같은 기본 메트릭이 변경되는 속도입니다. 이 요소 유형의 경우, 측정 단위가 명시적으로(예: 초당 비트 수) 그리고 속도가 수집되는 간격이 정의됩니다. |
| 평균 |
기본 메트릭의 여러 샘플의 평균입니다. 예를 들어, 평균 큐 깊이 데이터 요소는 큐 깊이의 여러 요소를 평균화하여 계산됩니다. 이 요소 유형의 경우 평균을 계산하는 데 사용되는 측정 수와 측정 간의 시간 간격을 정의하는 것이 좋습니다. 그렇지 않으면 이 평균값을 계산하는 수단을 명시적으로 정의해야 합니다. |
| 피크 |
기본 메트릭의 여러 샘플 중 최대값입니다. 예를 들어, 최대 대기열 깊이 요소는 대기열 깊이의 여러 측정값을 비교하고 최대값을 선택하여 계산됩니다. 이 데이터 요소 유형의 경우 피크 값을 계산하는 데 사용되는 측정 횟수와 측정 간 시간 간격을 정의하는 것이 좋습니다. 그렇지 않으면 이 피크 값이 어떻게 정의되는지 명시적으로 정의합니다. 또한 이 값이 지워지지 않는지, 따라서 모든 시간의 전체 최대값을 나타내는지 여부도 알아야 합니다. |
각 데이터 요소 유형에는 요소 하위 집합도 포함됩니다. 예를 들어, 데이터 요소 Counter 및 Gauge 에는 , average, peak 및 측정에 대한 rate하위 집합이 포함됩니다.
지원되는 데이터 유형
GetRequest는 수집기 클라이언트가 텔레메트리 데이터를 수신하기 위해 Get RPC를 시작할 때 전송됩니다. GetRequest 내에 지정된 것은 데이터 형식을 포함하여 대상이 수집기에 데이터를 반환해야 하는 데이터 요소입니다. 데이터 유형은 데이터를 전달해야 하는 형식을 지정하는 변수입니다.
표 6 에는 Junos 텔레메트리에서 지원하는 데이터 유형이 나와 있습니다. 지정하지 않는 한, 데이터 유형은 원격 프로시저 호출(gRPC) 서비스, gRPC 네트워크 관리 인터페이스(gNMI) 서비스 또는 UDP를 통해 Junos Telemetry 데이터 내보내기에 지원됩니다.
| 유형 |
값 |
설명 |
|---|---|---|
| 문자열 |
|
문자열 값입니다. |
| 정수64 |
|
정수 값입니다. |
| 유인트64 |
|
부호 없는 정수 값입니다. |
| 부울 |
|
부울 값입니다. |
| 플로트 |
|
부동 소수점 값입니다.
참고:
이 데이터 유형은 더 이상 사용되지 않습니다. 이 데이터 유형 대신 사용합니다 |
| 더블 |
|
double 값은 64비트 부동 소수점 값입니다. |
| 십진수64 |
|
Decimal64로 인코딩된 값입니다. gNMI 서비스에서만 지원됩니다. decimal64를 사용하여 고정 정밀도 십진수를 인코딩합니다. 이 값은 숫자 집합에서 소수점 다음의 자릿수를 지정하는 정밀도를 가진 숫자 집합으로 표시됩니다. 예를 들면 다음과 같습니다. message Decimal64 {
int64 digits = 1; // Set of digits.
uint32 precision = 2; // Number of digits following the decimal point.
참고:
이 데이터 유형은 더 이상 사용되지 않습니다. 이 데이터 유형 대신 사용합니다 |
| 스칼라 배열 |
|
혼합 유형 스칼라 배열 값입니다. 혼합 데이터 유형(string, int64, uint64, bool float 또는 decimal64) 값의 동종 배열입니다. gNMI 서비스에서만 지원됩니다. |
| 유형 | 값 | 설명 |
|---|---|---|
| ieeefloat32 | 이진수, 길이 = 4 | IEEE 32비트 부동 소수점 숫자입니다. Open Config 모델 데이터 유형입니다. 이 숫자의 형식은 다음과 같습니다. 1-bit sign
8-bit exponent
23-bit fraction
The floating point value is calculated using:
(-1)**S * 2**(Exponent-127) * (1+Fraction)";
참고: 이진 형식에 해당하는 gNMI 데이터 유형은 "바이트"입니다. gNMI 응답에서 float_val 형식의 디바이스에서 데이터가 잘못 수신되어 비준수 오류가 표시되었습니다. bytes_val 형식으로 데이터를 반환하도록 변경 사항이 통합되었습니다. 4바이트(부동 소수점 값을 나타냄)는 네트워크 바이트 순서로 전송됩니다. 값을 해석하기 전에 호스트 바이트 순서로 재정렬해야 합니다.
|
데이터 유형에 대한 자세한 내용은 github 및 http://www.openconfig.net/ 를 참조하십시오.
Junos Telemetry를 사용한 성능 모니터링
Junos Telemetry의 주요 기능 중 하나는 성능 모니터링입니다. 성능 관리 시스템으로 데이터를 스트리밍하면 네트워크 관리자는 링크 및 노드 사용률의 추세를 측정하고 네트워크 혼잡과 같은 문제를 실시간으로 해결할 수 있습니다.
일반적인 구축에서 네트워크 요소 또는 디바이스는 성능 관리 시스템 수집기 역할을 하는 두 개의 대상 서버로 중복 데이터를 스트리밍합니다. 두 개의 수집기로 데이터를 스트리밍하면 중복이 제공됩니다. 성능 관리 시스템 수집기가 데이터를 요청하는 방법과 디바이스가 데이터를 스트리밍하는 방법에 대한 일러스트레이션은 그림 1 을 참조하십시오. 디바이스는 센서를 프로비저닝하여 명령줄 인터페이스(CLI), NETCONF를 통한 구성 또는 gRPC 구독 호출을 사용하여 데이터를 수집하고 내보냅니다. 수집기는 텔레메트리 구독을 시작하여 데이터를 요청합니다. 데이터는 한 번만 요청되며 주기적으로 스트리밍됩니다.
위한 텔레메트리 스트리밍
Junos Telemetry의 다른 응용 분야에는 네트워크 요소와 네트워크 전반에서 트래픽 엔지니어링 경로 생성을 자동화하는 Northstar Controller와 같은 외부 컨트롤러 간의 운영 상태 동기화를 지원하기 위한 실시간 데이터 제공이 포함됩니다. NorthStar Controller는 레이블 스위칭 경로(LSP) 통계와 같은 특정 네트워크 요소에 대한 텔레메트리 데이터를 구독할 수 있습니다.