Junos Telemetry 이해
Junos Telemetry는 주니퍼 네트웍스에서 개발한 프레임워크로, Junos 디바이스에서 외부 컬렉터로 운영 데이터를 내보낼 수 있습니다. 이 데이터는 실시간 장치 모니터링을 위해 분석됩니다. 이 주제에서는 Junos Telemetry에서 사용하는 모델 기반 텔레메트리, 텔레메트리 모드, 전송 프로토콜, 텔레메트리 센서, 센서 경로 및 데이터 모델의 개념에 대해 설명합니다.
네트워크 텔레메트리
네트워크 텔레메트리는 네트워크 디바이스에서 데이터를 수집, 전송, 분석하는 프로세스입니다. 이 데이터에는 트래픽 패턴, 디바이스 상태, 오류율 및 네트워크의 상태와 동작에 대한 인사이트를 제공하는 기타 메트릭에 대한 정보가 포함될 수 있습니다. 이 데이터를 사용하여 유용한 인사이트를 도출하고 이 정보를 적용하여 네트워크 성능 및 보안을 효과적으로 모니터링하고 관리할 수 있습니다. 네트워크 관리자는 텔레메트리 데이터를 사용하여 네트워크 문제를 해결하고, 이상을 탐지하고, 네트워크 전반에서 리소스 활용을 최적화할 수 있습니다. 네트워크 텔레메트리의 주요 이점 중 하나는 네트워크 운영에 대한 실시간 가시성을 제공할 수 있다는 것입니다.
네트워크 텔레메트리는 네트워크 보안을 강화하는 데도 중요한 역할을 합니다. 보안 팀은 텔레메트리 데이터를 분석하여 사이버 공격 또는 기타 보안 위협을 나타낼 수 있는 비정상적인 패턴을 식별할 수 있으므로 잠재적인 보안 사고를 더 빠르게 탐지하고 대응할 수 있으며 네트워크와 해당 데이터를 보호할 수 있습니다.
Junos Telemetry
Junos Telemetry는 텔레메트리 데이터를 스트리밍하기 위해 개발된 주니퍼의 텔레메트리 솔루션입니다. 확장성이 뛰어나며 네트워크에서 원격으로 여러 장치를 모니터링하는 것을 지원할 수 있습니다. 또한 문제 해결을 개선하고, 네트워크를 사전에 관리하고, 운영 비용을 절감하는 데 도움이 됩니다.
Junos Telemetry는 다음과 같은 다양한 네트워크 시나리오에 적용할 수 있습니다.
- 성능 모니터링: 인터페이스 활용도, 지연 시간, 패킷 손실과 같은 주요 지표를 모니터링하여 최적의 네트워크 성능을 보장합니다.
- 보안 모니터링: 보안 이벤트를 추적하고, 트래픽 패턴을 분석하고, 잠재적인 보안 위협을 식별합니다.
- 애플리케이션 성능 관리: 네트워크 데이터와 애플리케이션 데이터의 상관관계를 분석하여 애플리케이션 성능에 대한 인사이트를 확보합니다.
- 네트워크 용량 계획: 과거 데이터와 실시간 데이터를 분석하여 잠재적인 병목 현상을 파악하고 향후 용량 수요에 대비한 계획을 수립합니다.
다른 주니퍼 애플리케이션도 Junos Telemetry를 활용하여 실시간 데이터를 제공하고 네트워크 요소와 주니퍼의 Mist, 주니퍼의 Routing Director, Apstra와 같은 외부 컨트롤러 간의 운영 상태 동기화를 지원합니다.
모델 기반 텔레메트리
Junos Telemetry는 MDT(Model Driven Telemetry) 아키텍처를 채택했습니다. 모델 기반 네트워크 텔레메트리 시스템은 데이터 모델을 활용하여 네트워크 디바이스에서 텔레메트리 데이터를 정의하고 수집하는 네트워크 모니터링에 대한 고급 접근 방식입니다. 이 시스템에서 데이터 모델은 YANG(Yet Another Next Generation) 언어를 사용하여 정의되어 수집 또는 스트리밍할 데이터의 구조와 유형을 지정합니다.
주니퍼는 현재 두 가지 데이터 모델을 지원합니다.
-
주니퍼 네이티브 데이터 모델
-
OpenConfig 데이터 모델
두 모델 모두 YANG 을 사용하여 스트리밍할 데이터 구조 및 데이터 유형을 지정합니다. 자세한 내용은 데이터 모델을 참조하십시오.
올바른 데이터 모델을 선택하는 것은 특정 요구 사항에 따라 다릅니다. OpenConfig와 네이티브 센서를 동시에 구독할 수 있습니다.
아래 단계에 따라 모델 기반 텔레메트리 솔루션을 설정합니다.
- 데이터 수집기 설정: 데이터를 수집하고 인코딩하도록 네트워크 장치를 구성합니다. 자세한 내용은 원격 분석 데이터 수집기를 참조하세요.
- 전송 프로토콜 설정: 데이터 전송에 적합한 전송 프로토콜을 선택하고 구성합니다. 자세한 내용은 텔레메트리 프로토콜을 참조하십시오.
- 센서 구성: 센서 프로필은 모니터링하고 스트리밍할 시스템 리소스의 매개 변수를 정의합니다. 하나의 시스템 자원만 각 센서 프로파일을 모니터하거나 각 시스템 자원에 대해 다른 센서 프로파일을 구성할 수 있습니다. 그러나 동일한 시스템 리소스를 모니터링하도록 둘 이상의 센서를 구성할 수 있습니다. 자세한 내용은 센서 및 센서 경로를 참조하십시오.
- 구독 만들기: 모니터링해야 하는 데이터 스트림에 대한 구독을 설정합니다. 원격 분석 세션은 장치 또는 수신기가 구독을 시작하도록 구성되었는지 여부에 따라 전화 접속 모드 또는 전화 걸기 모드에서 설정할 수 있습니다. 자세한 내용은 원격 분석 모드를 참조하세요.
센서 및 센서 경로
원격 분석 센서는 원격 분석 솔루션의 중요한 구성 요소입니다. 다양한 물리적, 환경적, 성능 파라미터를 측정하고 이를 데이터로 변환합니다. 이 데이터는 원격 모니터링 및 분석을 위해 gNMI 또는 UDP 연결을 통해 컬렉터로 전송됩니다. 몇 가지 예로는 온도 센서, 인터페이스 센서, 유량 센서 등이 있습니다. 원격 측정 센서 경로는 YANG을 사용하여 정의된 데이터 모델 내의 특정 경로로, 네트워크 디바이스에서 수집 및 스트리밍할 정확한 데이터를 지정합니다. 주니퍼는 Openconfig와 네이티브 센서를 모두 지원합니다. Openconfig 센서는 카운터 기반 또는 상태 기반 메트릭을 추적하며, 네이티브 센서는 이러한 센서가 심층적인 디바이스 데이터에 액세스할 수 있으므로 이벤트 기반 메트릭을 효과적으로 추적합니다. Openconfig 기반 센서 경로를 구성하여 센서 정보를 벤더 중립적인 형식으로 검색하거나 네이티브 센서 경로를 구성하여 주니퍼 독점 정보를 네이티브 형식으로 검색할 수 있습니다. 자세한 내용은 센서 경로 탐색을 참조하십시오.
텔레메트리 데이터 수집기
텔레메트리 수집기는 텔레메트리 데이터의 데이터 수집, 처리, 전송 및 저장을 수행하는 특수 도구 또는 소프트웨어입니다. 텔레메트리 데이터를 생성하는 Junos 디바이스와 이를 저장, 분석 및 시각화하는 백엔드 시스템 사이의 중개자 역할을 합니다.
데이터 수집기의 기능:
- 데이터 수집: 수집기는 gRPC, gNMI 또는 UDP 연결을 통해 주니퍼 디바이스로부터 텔레메트리 데이터를 수신합니다.
- 데이터 처리: 수집기는 수집된 데이터를 집계 및 정규화하여 불필요한 정보를 필터링하고, 메트릭을 집계하고, 초기 분석을 수행합니다. 이렇게 처리하면 데이터 볼륨을 줄이고 가장 중요한 메트릭에 집중할 수 있습니다.
- 데이터 전송: 안정적인 데이터 전송과 짧은 대기 시간을 보장합니다.
- 데이터 저장: 처리된 데이터는 추가 분석, 시각화 및 저장을 위해 다양한 백엔드 시스템으로 내보내집니다. 장기 분석 및 기록 비교를 위해 데이터 레이크에 저장할 수 있습니다. 이 수집기는 여러 데이터 형식과 프로토콜을 지원하므로 다양한 모니터링 및 분석 도구와 호환됩니다. 분석된 데이터는 대화형 대시보드와 보고서를 통해 제공되므로 네트워크 관리자에게 실행 가능한 통찰력을 제공할 수 있습니다.
텔레메트리 모드
Junos Telemetry는 다음 두 가지 모드로 텔레메트리 세션을 지원합니다.
Juniper 디바이스는 다이얼 인 및 다이얼 아웃 모드에서 모두 작동할 수 있습니다. 네트워크 토폴로지에 따라 Juniper 디바이스를 두 모드 중 하나로 구성할 수 있습니다. 두 모드 모두 동일한 데이터 모델을 사용하고 네트워크를 통해 동일한 텔레메트리 데이터를 스트리밍합니다. 두 모드의 차이는 컬렉터 또는 주니퍼 디바이스가 연결을 시작하고 유지하는지 여부에 따라 달라집니다.
구독 유형
Junos Telemetry는 다양한 구독 모드를 지원하여 특정 요구와 조건에 따라 맞춤형 데이터 수집이 가능합니다. 구독 모드는 디바이스에서 구성되며 데이터 스트림의 동작을 지시합니다. 구독 모드의 구현은 전화 접속 연결을 사용하는지 또는 전화 접속 연결을 사용하는지에 따라 달라집니다. 스트리밍 간격은 디바이스와 수집기 간의 텔레메트리 데이터 전송 빈도를 결정합니다. 데이터 수집 및 스트리밍은 특정 조건이 충족되거나 원격 분석 데이터의 수집 및 스트리밍을 시작하는 이벤트가 발생할 때 트리거됩니다. 이러한 트리거는 특정 기준이 충족될 때 데이터가 수집되도록 합니다. 예를 들어, 패킷 손실이 감지되면 텔레메트리 데이터를 수집하고 스트리밍할 수 있습니다. 전화 접속 및 전화 접속 원격 분석은 모두 다음과 같은 구독 모드를 지원합니다.
- 한 번: 원격 분석 데이터에 대한 일회성 요청입니다. 구독한 데이터의 현재 상태에 대한 스냅샷이 필요할 때 이 모드를 구성할 수 있습니다. 전화 접속 연결과 전화 접속 연결 모두에서 지원되지만 주로 전화 접속 연결에 사용됩니다. 디바이스는 데이터를 수집기로 한 번 전송하고 다이얼 아웃 연결을 위해 중지합니다. 수집기는 ONCE 모드의 "구독" RPC를 통해 전화 접속 연결을 요청합니다. 전화 접속 연결에서는 센서 및 구독이 한 번만 트리거되도록 구성해야 하며, 이는 일반적인 시나리오가 아닙니다. 전화 접속 연결에서는 "Get" RPC와 비슷하지만 구독으로 프레이밍됩니다.
- 폴링: 원격 분석 데이터의 주기적인 주문형 검색입니다. 이 구성은 특정 간격으로 센서를 모니터링하는 데 적합합니다. POLL은 컬렉터가 디바이스의 gNMI 서버에 대한 연결을 시작하는 다이얼 인 시나리오에서 지원됩니다. Junos Telemetry 스트리밍은 디바이스 기반이므로 일반적인 다이얼 아웃 스트리밍 모드가 아닙니다. gNMI 서버를 실행하려면 디바이스가 필요합니다. 컬렉터는 POLL로 구독한 다음 필요에 따라 폴링합니다.
- 스트림: 이 지속적인 구독은 구성된 트리거가 발생할 때 지속적으로 데이터를 스트리밍합니다.
메모: 모든 센서(OpenConfig 또는 네이티브)가 모든 모드를 지원하는 것은 아닙니다.
이 형태의 서브스크립션에는 세 가지 하위 모드가 있습니다.
- ON_CHANGE: 디바이스는 모니터링되는 데이터가 변경되는 경우(예: 인터페이스 카운터가 증가하거나 상태가 뒤집히는 경우)에만 업데이트를 보냅니다. 이 모드는 시간 기반이 아닌 이벤트 기반 메트릭에 적합합니다. 네이티브 센서는 이벤트 기반 메트릭의 컨텍스트에서 Openconfig 센서보다 우위를 점합니다.
- 견본: 텔레메트리 업데이트는 구성된 간격에 따라 정기적으로 스트리밍됩니다. 이 모드는 시간이 지남에 따라 샘플링되는 패킷 수 또는 전송된 바이트 수와 같은 메트릭에 적합합니다.
- TARGET_DEFINED: 장치는 모니터링되는 센서 또는 리소스를 기반으로 최상의 모드(SAMPLE 또는 ON_CHANGE)를 결정합니다. ON_CHANGE 센서에 대해 명시적으로 지원되지 않는 한 주니퍼의 구현은 기본적으로 SAMPLE로 설정될 수 있습니다.
- 메모: 구성 경로에 대한 TARGET_DEFINED 구독 요청은 ON_CHANGE 요청으로만 처리됩니다.
네트워크에 적합한 텔레메트리 구성 결정
네트워크 토폴로지에 적합한 원격 분석 센서, 연결 방법(전화 접속 또는 전화 걸기) 및 구독 모드를 선택하기 전에 다음 지침을 고려하십시오.
- OpenConfig 센서와 구독 모드 SAMPLE의 조합은 표준화된 주기적 모니터링(예: 멀티벤더 대시보드)에 적합합니다.
- 네이티브 센서와 ON_CHANGE 구독 모드의 조합은 주니퍼 고유의 이벤트 기반 인사이트(예: 하드웨어 문제 해결)에 적합합니다.
네트워크에 적합한 원격 분석 세션을 결정하기 위해 다음 정보에는 전화 접속 원격 분석 모드와 전화 접속 원격 분석 모드 간의 비교가 요약되어 있습니다.
다이얼 인 vs. 다이얼 아웃
-
전화 접속(gNMI를 사용하는 gRPC)은 센서 유형(Openconfig 또는 네이티브)에서 스냅샷을 가져옵니다.
예: 수집기는 gRPC를 통해 gNMI를 사용하여 OpenConfig 통계(
/interfaces) 또는 기본 PFE 통계를(/junos/system/linecard가져옵니다. -
다이얼 아웃(gNMI 또는 UDP를 사용하는 gRPC)은 gNMI/gRPC 선호 구조와 네이티브 단순성에 적합한 UDP를 사용하여 업데이트를 스트리밍합니다.
예: 디바이스는 gRPC를 통해 gNMI를 통해 OpenConfig BGP 통계를 스트리밍하거나 UDP를 통해 네이티브 방화벽 카운터를 스트리밍합니다.
텔레메트리 프로토콜
Junos Telemetry는 gNMI 및 UDP 프로토콜을 지원하여 Juniper 디바이스에서 텔레메트리 데이터를 수집하고 데이터 수집기로 스트리밍합니다.
gRPC 네트워크 관리 인터페이스(gNMI)
gNMI는 네트워크 디바이스를 구성하고 모니터링하는 gRPC 기반 프로토콜입니다. 네트워크 운영자는 디바이스 구성 데이터를 검색 및 수정할 수 있으며 네트워크 디바이스에서 실시간 텔레메트리 데이터를 구독할 수 있습니다. gNMI는 텔레메트리 업데이트를 위해 ONCE, POLL 및 STREAM과 같은 구독 모드를 지원합니다. gNMI는 프로토콜 버퍼(protobuf)와 같은 데이터 인코딩 형식을 사용하며 TLS를 사용하여 보안 통신을 보장합니다. 자세한 내용은 gNMI 서비스 및 gNMI를 사용하여 텔레메트리 데이터 구독을 참조하십시오.
UDP(User Datagram Protocol)
UDP를 통한 스트리밍 원격 분석 데이터는 다이얼 아웃 메커니즘을 기반으로 합니다. 센서 경로는 CLI를 통해 구성되며, 디바이스는 UDP를 통해 구성된 센서 경로에 대한 데이터를 수집기의 대상 주소로 보냅니다. 대상 주소는 CLI를 통해 구성됩니다. 네이티브 센서에서 UDP를 통해 텔레메트리를 스트리밍하는 동안 데이터는 protobuf 형식으로 UDP를 통해 수집기로 전송됩니다. UDP는 상태 비저장 데이터를 내보내는 데 적합합니다. 자세한 내용은 UDP를 통한 스트리밍 텔레메트리 데이터를 참조하십시오.
데이터 모델
Junos Telemetry 데이터 모델은 YANG(Yet Another Next Generation)을 사용하여 네트워크 디바이스에서 수집된 텔레메트리 데이터의 구조를 정의합니다. YANG은 Junos Telemetry에서 네트워크 디바이스에 대한 구성, 운영 상태 데이터 및 원격 절차 호출(RPC)을 정의하는 데 사용되는 표준 기반의 확장 가능한 데이터 모델링 언어입니다. Junos Telemetry에서 YANG 모델은 네이티브 또는 OpenConfig 데이터 모델을 사용하여 인터페이스 통계와 같은 텔레메트리 데이터를 수집하고 내보낼 수 있는 센서 프로비저닝을 지원합니다. YANG 표준은 RFC 6020 및 RFC 7950에 정의되어 있습니다.
주니퍼 네트웍스는 Junos 디바이스용 YANG 모듈을 게시하며, 이러한 모듈은 Juniper GitHub 리포지토리 에서 다운로드하거나 디바이스에서 생성할 수 있습니다.
OpenConfig 작업 그룹은 OpenConfig 데이터 모델을 정의합니다. 네트워크를 구성하고 관리하는 것은 벤더 중립적인 데이터 모델입니다. OpenConfig 데이터 모델은 유니버설 키/값 형식의 Google 프로토콜 버퍼(GPB) 메시지로 데이터를 생성합니다. Junos Telemetry를 사용하면 OpenConfig 모델을 활용하여 벤더에 구애받지 않는 보다 광범위한 네트워크 뷰를 확보할 수 있습니다. Openconfig 센서 경로는 Openconfig 데이터 모델을 기반으로 센서에서 센서 정보를 검색하는 데 사용됩니다. 자세한 Openconfig 리소스 경로 탐색은 Junos YANG 데이터 모델 탐색기를 참조하십시오.
주니퍼 네이티브 데이터 모델은 주니퍼가 개발한 확장 가능한 개방형 프레임워크입니다. 이 모델은 주니퍼 디바이스에서 발견되는 고유한 기능에 대한 텔레메트리 데이터를 스트리밍하는 데 사용됩니다. 여기에는 인터페이스 통계, 라우팅 정보, 보안 메트릭 등이 포함됩니다. 또한 기본 모델을 사용하면 엔터프라이즈별 센서를 정의할 수 있습니다. 주니퍼 또는 엔터프라이즈별 센서의 정보에 액세스하려면 주니퍼 기본 센서를 구독하십시오. 기본 센서 경로는 기본 데이터 모델을 기반으로 센서에서 센서 정보를 검색하는 데 사용됩니다. 주니퍼의 네이티브 센서용 YANG 모듈은 주니퍼의 텔레메트리 GitHub 리포지토리에서 사용할 수 있습니다.
센서 경로 탐색
텔레메트리 센서 경로는 모니터링해야 하는 데이터 포인트 또는 메트릭에 대한 계층적 경로를 설명합니다. 필요한 센서 데이터를 스트리밍하고 센서를 활성화하며 관련 센서 경로를 식별합니다. Junos Telemetry는 Openconfig 센서 경로와 네이티브 센서 경로를 모두 지원합니다.
-
Openconfig 센서 경로
Openconfig 센서에서 데이터 수집을 구성하려면 구독 및 센서 경로(예:
/interfaces/interface/state/counters)를 정의하고, 데이터 수집기를 설정하고, 주니퍼 네트웍스 지원 페이지에서 Junos Telemetry 프로토콜 버퍼 파일을 다운로드합니다. 수집기에서 캡처된 데이터를 캡처하고 디코딩합니다. -
기본 센서 경로
기본 센서 경로는 Junos OS(예:
/junos/system/line card/interface/)에만 해당되며, 디바이스별 메트릭에 대해 주니퍼가 최적화한 세분화된 액세스를 제공합니다.네이티브 센서에서 데이터 수집을 구성하려면 Junos CLI를 사용하여 특정 데이터 수집을 위한 네이티브 센서를 프로비저닝합니다. gRPC 또는 UDP를 사용하여 데이터를 스트리밍하도록 Junos Telemetry를 구성합니다. 프로토콜 버퍼의 파일을 사용하여 수집기에서 스트리밍된 데이터를 디코딩합니다.
두 경로 유형 모두 JSON 또는 XML과 같은 형식으로 데이터를 구조화하여 출력할 수 있으므로 효율적인 모니터링 및 분석을 위해 외부 수집기와의 호환성이 보장됩니다.
센서 경로 탐색기
주니퍼 네트웍스 Junos YANG 데이터 모델 탐색기 는 지원되는 모든 리소스 경로, 해당 리프 및 이를 지원하는 디바이스 플랫폼을 볼 수 있는 온라인 도구입니다. 이를 통해 다양한 OpenConfig 및 네이티브 데이터 모델 속성을 탐색하거나 비교할 수 있습니다. 소프트웨어 릴리스 번호 또는 제품에 따라 필터 옵션을 사용하여 각 플랫폼의 자원 경로 및 센서 목록을 볼 수 있습니다.
텔레메트리 센서 경로 선택
모델 기반 텔레메트리 시스템에서, 센서 경로는 데이터 모델의 컨테이너 계층 구조 내의 모든 수준에서 종료되도록 구성될 수 있습니다. 필요한 텔레메트리 정보를 기반으로 센서 경로를 구성하여 광범위한 데이터 세트를 검색하거나 매우 구체적이고 특정 센서에 대한 대상 정보를 검색할 수 있습니다. 예를 들어, 센서 경로는 라우터의 모든 인터페이스 통계를 포함하는 컨테이너를 가리킬 수도 있고, 특정 인터페이스의 패킷 손실과 같은 단일 메트릭에 초점을 맞춰 더 세분화될 수도 있습니다.
예를 들어, 디바이스에서 생성된 알람에 대한 텔레메트리 데이터를 수신하려면(OpenConfig 데이터 모델 사용) 필요한 센서 데이터의 세분성에 따라 다음 리소스 경로 중 하나를 구성할 수 있습니다.
/system/alarms/alarm/id: 이 경로는 알람 ID만 검색합니다./system/alarms/alarm/config: 이 경로는 자세한 알람 정보를 검색합니다.
올바른 센서 경로를 구성하면 효율적인 원격 측정 시스템이 보장됩니다. 각 자원 경로는 시스템 자원에 대한 데이터 스트리밍을 전역적으로, 즉 시스템 전체에서 사용할 수 있도록 합니다. 각 리소스 경로를 수정하여 논리적 또는 물리적 인터페이스를 지정할 수 있습니다. 리소스 경로 ""/interfaces/interface/config은(는) 글로벌 물리적 인터페이스 수준에서 구성 가능한 항목 목록을 검색하는 반면, 경로 "/interfaces/interface/config/name"은(는) 인터페이스의 이름을 지정하며, 디바이스는 인터페이스 유형에 따라 이 리프에 허용되는 값을 제한할 수 있습니다.
센서 경로 선택을 위한 중요 지침
-
센서를 구성할 때 항상 완전하고 직접적인 리소스 경로를 제공해야 합니다. "
/components/component/"와 같은 부분 리소스 경로를 제공하면 구성이 불완전해지고 오류가 발생할 수 있습니다. 이러한 리소스 경로는 해당 계층 내에서 사용 가능한 모든 옵션을 검색하고 표시해야 하므로 디바이스에 상당한 부하를 줄 수 있습니다. 이를 방지하려면 항상 전체 리소스 경로를 확인하고 사용하여 정확하고 효율적인 센서 구성을 보장하십시오.메모: "/"(루트) 및 "/junos/"에서 구독 및 센서 구성을 만드는 것은 허용되지 않습니다.표 1: 센서 경로 Example 전체 센서 경로(권장) 부분 센서 경로(권장하지 않음) /interfaces/interface/subinterfaces/subinterface/state/counters/out-pkts/interfaces/interface -
논리적 및 물리적 패킷 포워딩 엔진 인터페이스 센서가 일부 리프를 일관되지 않게 수집기에 보고합니다. 예를 들어, 스트리밍된 경로를
/junos/system/linecard/interface/logical/ usage/생성하는 구독된 경로/interfaces/ 115 interface/는 키 이름 leavesparent_ae_name및init_time(리프 이름에 밑줄 포함)를 보고합니다. 스트리밍된 경로를/ junos/system/linecard/interface/queue/생성하는 구독 경로/interfaces/interface/state/는 키 이름 leavesparent-ae-name및init\u0002time(리프 이름에 하이픈 포함)를 보고합니다.
Junos Evolved 디바이스의 성능은 서비스 기반 아키텍처를 통해 최적화되며, 서비스 구성에 따라 일부 프로세스 또는 데몬이 활성화됩니다. 이러한 프로세스는 서비스가 구성될 때까지 비활성 상태로 유지됩니다. 원격 분석 구독이 비활성 서비스를 대상으로 하는 경우 원격 분석 출력이 생성되지 않습니다.
센서 데이터 캡슐화 형식Junos Telemetry는 프로토콜 버퍼(gpb) 형식으로 데이터를 내보내는 두 가지 방법을 지원합니다. 이 섹션에서는 UDP를 통해 텔레메트리 데이터를 내보낼 때 기본 센서에서 사용하는 데이터 형식에 대해 설명합니다. 데이터는 UDP 헤더로 캡슐화되며, 이는 IPv4 페이로드에서 추가로 캡슐화됩니다. 이 텔레메트리 모델은 구성된 센서에서 생성된 데이터가 데이터 플레인에서 직접 내보내지는 분산 아키텍처를 따릅니다. 이 접근 방식은 컨트롤 플레인을 우회함으로써 다른 중요한 기능을 위한 컨트롤 플레인 리소스를 절약하는 데 도움이 됩니다.
기본 센서는 UDP를 사용하여 소스에 가까운 데이터를 내보냅니다. 물리적 인터페이스 통계, 방화벽 필터 카운터 통계 또는 LSP(Label-Switched Path) 통계와 같은 다양한 유형의 텔레메트리 데이터를 내보낼 수 있습니다. 센서는 활성화되자마자 데이터를 내보내기 시작합니다.
센서 데이터는 라는 TelemetryStream단일 구조화된 프로토콜 버퍼 메시지로 표시됩니다. 아래에 표시된 메시지 또는 .proto 파일에는 라인 카드, 패킷 포워딩 엔진 또는 라우팅 엔진과 같이 데이터 소스를 식별하는 여러 속성이 포함되어 있습니다. 구성된 센서의 이름도 포함됩니다. 센서를 구성하는 방법에 대한 자세한 내용은 센서 경로 탐색을 참조하십시오. 지원되는 네이티브 센서 목록은 센서(Junos Telemetry Interface)를 참조하십시오.
또한 지원되는 모든 센서에 .proto 대한 파일을 스트리밍 서버 또는 수집기에 다운로드해야 합니다. 웹 브라우저에서 주니퍼 네트웍스 페이지의 All Junos Platforms software download URL( https://www.juniper.net/support/downloads/) 로 이동합니다. Junos OS 플랫폼 이름과 릴리스 번호를 선택한 후 도구 섹션으로 이동하여 Junos Telemetry Interface 데이터 모델 파일 패키지를 다운로드합니다. streaming-server 구성에 대한 자세한 내용은 streaming-server(Junos Telemetry Interface)를 참조하십시오.
네이티브 프로토콜 버퍼(protobuf) 메시지 구조
수집기로 스트리밍되는 정보는 (telemetry_top.proto 파일)의 TelemetryStream 최상위 메시지 구조를 사용하여 전송됩니다. 메시지에는 스트리밍되는 센서 데이터의 메타데이터(예: 센서 경로, 데이터가 전송되는 시스템, 데이터가 전송되는 노드 등)가 포함됩니다. 실제 센서 데이터는 최상위 메시지에 대한 확장으로 전송됩니다. 센서 데이터에 대해 별도의 proto 파일이 전송됩니다. telemetry_top.proto 파일 및 sensor proto 파일은 수집기에서 센서 데이터를 디코딩하는 데 사용됩니다.
telemetry_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 확인합니다.
표 2는 의미 체계 및 해당 스키마를 포함하여 센서 데이터에 의해 수집되는 각 요소에 대한 설명을 참조하십시오.
| 엘리먼트 타입 |
묘사 |
|---|---|
| 카운터 |
단조롭게 증가하는 부호 없는 정수입니다. 최대값에 도달하면 0에서 다시 시작합니다. |
| 계기 |
값을 늘리거나 줄일 수 있는 부호 없는 32비트 또는 64비트 정수입니다. 이 요소로 표시되는 데이터의 예는 큐 용량 또는 온도와 같은 특정 자원의 순간 값입니다. |
| 율 |
카운터 또는 계기와 같은 기본 메트릭이 변경되는 속도입니다. 이 요소 유형의 경우 측정 단위가 명시적으로 정의되고(예: 초당 비트 수) 속도가 수집되는 간격이 정의됩니다. |
| 평균의 |
기본 메트릭에 대한 여러 샘플의 평균입니다. 예를 들어, 평균 큐 용량 데이터 요소는 큐 크기의 여러 요소를 평균하여 계산됩니다. 이 요소 유형의 경우 평균을 계산하는 데 사용되는 측정 수와 측정 간의 시간 간격을 정의하는 것이 좋습니다. 그렇지 않으면 이 평균값을 계산하는 방법을 명시적으로 정의해야 합니다. |
| 봉우리 |
기본 메트릭의 여러 샘플 중 최대값입니다. 예를 들어, 피크 큐 깊이 요소는 큐 깊이의 여러 측정값을 비교하고 최대값을 선택하여 계산됩니다. 이 데이터 요소 유형의 경우 피크 값을 계산하는 데 사용되는 측정 수와 측정 간의 시간 간격을 정의하는 것이 좋습니다. 그렇지 않으면 이 피크 값을 정의하는 방법을 명시적으로 정의하십시오. 또한 이 값이 지워지지 않아 모든 시간 동안의 전체 최대값을 나타내는지 여부도 알아야 합니다. |
각 데이터 요소 유형에는 요소 하위 집합도 포함됩니다. 예를 들어, 데이터 요소 Counter 및 에는 , peak average및 측정값에 대한 rate하위 집합이 Gauge 포함됩니다.
지원되는 데이터 유형
GetRequest는 수집기 클라이언트가 원격 분석 데이터를 수신하기 위해 RPC 가져오기를 시작할 때 전송됩니다. GetRequest 내에는 데이터 형식을 포함하여 대상이 수집기에 데이터를 반환해야 하는 데이터 요소가 지정됩니다. 데이터 유형은 데이터가 전달되어야 하는 형식을 지정하는 변수입니다.
표 3 에는 Junos Telemetry에서 지원하는 데이터 유형이 나와 있습니다. 지정하지 않는 한, 데이터 유형은 원격 프로시저 호출(gRPC) 서비스, gRPC 네트워크 관리 인터페이스(gNMI) 서비스를 사용하거나 UDP를 통해 Junos Telemetry 데이터 내보내기에 지원됩니다.
| 형 |
값 |
묘사 |
|---|---|---|
| 문자열 |
|
문자열 값입니다. |
| 정수64 |
|
정수 값입니다. |
| uint64 (단위64) |
|
부호 없는 정수 값입니다. |
| 부울 |
|
Bool 값을 사용합니다. |
| 뜨다 |
|
부동 소수점 값입니다.
메모:
이 데이터 형식은 더 이상 사용되지 않습니다. 이 데이터 형식 대신 을 사용합니다 |
| 배 |
|
double 값은 64비트 부동 소수점 값입니다. |
| 10진수64 |
|
Decimal64로 인코딩된 값입니다. gNMI 서비스에서만 지원됩니다. decimal64를 사용하여 고정 정밀도 10진수를 인코딩합니다. 값은 자릿수가 자릿수 집합의 소수점 뒤에 오는 자릿수를 지정하는 자릿수와 함께 자릿수 집합으로 표현됩니다. 예를 들어: 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 데이터 유형은 "byte"입니다. gNMI 응답에서 디바이스에서 float_val 형식의 데이터가 잘못 수신되었으며 규정 미준수 오류가 표시되었습니다. bytes_val 형식으로 데이터를 반환하기 위해 변경 사항이 통합되었습니다. 부동 소수점 값을 나타내는 4바이트는 네트워크 바이트 순서로 전송됩니다. 값을 해석하기 전에 호스트 바이트 순서로 순서를 변경해야 합니다.
|
데이터 형식에 대한 자세한 내용은 github 및 http://www.openconfig.net/ 를 참조하세요.
Junos Telemetry를 사용한 성능 모니터링
Junos Telemetry의 주요 기능 중 하나는 성능 모니터링입니다. 성능 관리 시스템으로 데이터를 스트리밍하면 네트워크 관리자가 링크 및 노드 활용률의 추세를 측정하고 네트워크 혼잡과 같은 문제를 실시간으로 해결할 수 있습니다.
일반적인 배포에서 네트워크 요소 또는 장치는 성능 관리 시스템 수집기 역할을 하는 두 개의 대상 서버로 중복 데이터를 스트리밍합니다. 데이터를 두 개의 수집기로 스트리밍하면 중복성이 제공됩니다. 성능 관리 시스템 수집기가 데이터를 요청하는 방법과 디바이스가 데이터를 스트리밍하는 방법을 보여주는 그림은 그림 1 을 참조하십시오. 디바이스는 CLI(Command-Line Interface), NETCONF를 통한 구성 또는 gRPC 구독 호출을 사용하여 데이터를 수집하고 내보내기 위한 센서를 프로비저닝합니다. 수집기는 원격 분석 구독을 시작하여 데이터를 요청합니다. 데이터는 한 번만 요청되며 주기적으로 스트리밍됩니다.
위한 원격 분석 스트리밍
Junos OS 릴리스 18.1R1부터는 syslog 데이터를 네트워크 텔레메트리 수집기 시스템으로 스트리밍할 수 있는 새로운 센서를 사용할 수 있습니다. /junos/events/ 센서 및 0 reporting-rate 인 내보내기 프로파일을 사용하여 이제 통계 데이터와 함께 이벤트 데이터를 텔레메트리 수집 시스템으로 스트리밍할 수 있습니다.
Junos Telemetry의 다른 애플리케이션에는 네트워크 전반에서 트래픽 엔지니어링 경로 생성을 자동화하는 Northstar Controller와 같은 외부 컨트롤러와 네트워크 요소 간의 운영 상태 동기화를 지원하기 위해 실시간 데이터를 제공하는 것이 포함됩니다. NorthStar Controller는 LSP(Label-Switched Path) 통계와 같은 특정 네트워크 요소에 대한 텔레메트리 데이터를 구독할 수 있습니다.