Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지의 내용
 

센서 개요

Paragon Insights는 주니퍼, 타사 디바이스, 시스템 로그 및 SNMP와 같은 기존 네트워크 관리 프로토콜을 포함한 다양한 유형의 텔레메트리 센서에서 데이터를 수신합니다. Paragon Insights는 데이터 수집의 푸시 및 풀 모델을 지원합니다. 예를 들어 푸시 모델에서 디바이스는 트랩 알림을 통해 텔레메트리 데이터를 Paragon Insights에 푸시합니다. 풀 모드에서 Paragon Insights는 주기적으로 디바이스에서 데이터를 폴링합니다. 이 가이드에서는 지원되는 각 수집 방법을 푸시 또는 풀 모델에 속하는지 여부에 따라 정렬된 예제와 함께 설명합니다. 각 설명과 함께 특정 수집 유형을 활성화하는 데 필요한 Junos OS 버전 및 디바이스 구성이 제공됩니다.

네트워크의 개체 수와 객체가 생성하는 메트릭이 증가함에 따라 네트워크 상태를 모니터링하기 위한 운영 통계를 수집하는 것이 점점 더 어려워지고 있습니다. SNMP 및 CLI와 같은 기존의 '풀' 데이터 수집 모델은 네트워크 요소를 주기적으로 폴링하기 위해 추가 처리가 필요하며 확장을 직접적으로 제한할 수 있습니다.

'푸시' 모델은 데이터를 비동기식으로 제공하여 폴링을 제거함으로써 이러한 한계를 극복합니다. 이 모델을 통해 Paragon Insights 서버는 네트워크 디바이스에 단일 요청을 하여 주기적인 업데이트를 스트리밍할 수 있습니다. 결과적으로 '푸시' 모델은 확장성이 뛰어나며 네트워크에서 수천 개의 개체 모니터링을 지원할 수 있습니다. Junos 디바이스는 JTI( Junos Telemetry Interface ) 형태로 이 모델을 지원합니다.

Paragon Insights는 현재 5개의 푸시 모델 센서를 지원합니다.

효율성과 확장성 측면에서 '푸시' 모델이 선호되는 접근 방식이지만 '풀' 데이터 수집 모델이 적절한 경우도 여전히 있습니다. 두 가지 예로는 디바이스가 JTI(Junos Telemetry Interface)를 지원하지 않거나 타사 디바이스를 관리할 때가 들 수 있습니다. 풀 모델을 통해 Paragon Insights는 사용자가 정의한 주기적인 간격으로 네트워크 디바이스에 데이터를 요청합니다.

Paragon Insights는 현재 다음과 같은 풀 모델 센서를 지원합니다.

네이티브 GPB

네이티브 센서는 Google 프로토콜 버퍼(GPB)를 사용하는 주니퍼 독점 데이터 모델을 사용합니다. 디바이스는 UDP를 통해 텔레메트리 데이터(구성된 경우)를 푸시합니다.

디바이스는 패킷 포워딩 엔진, 즉 라인 카드에서 직접 데이터를 푸시합니다. 즉, 텔레메트리 데이터가 포워딩 플레인을 통해 전송되므로 수집기는 디바이스에 대역 내 연결이 있어야 합니다.

네이티브 형식을 사용하려면 텔레메트리 데이터를 보낼 위치를 포함하는 설정으로 디바이스를 구성합니다. 데이터 수집을 시작하도록 Paragon Insights를 구성할 때 스트림은 이미 서버를 향해 흐르고 있습니다.

네이티브 센서에 대한 자세한 내용은 수집된 데이터의 Junos Telemetry Interface 내보내기 형식 이해를 참조하십시오.

넷플로우

Paragon Insights는 다른 Paragon Insights 수집 메커니즘과 일치하는 데이터 모델을 사용하여 NetFlow 수집 방법으로 NetFlow v9 및 NetFlow v10(IPFIX)을 기본적으로 지원합니다. NetFlow는 IP 트래픽 통계를 수집하기 위한 네트워크 프로토콜이며, 분석을 위해 도구로 내보낼 수 있습니다. NetFlow v9 데이터 내보내기 형식은 RFC 3954에 설명되어 있습니다. NetFlow v10은 공식적으로 IPFIX로 알려져 있으며 RFC 7011에서 표준화됩니다.

Junos 디바이스는 이러한 프로토콜을 사용하여 플로우 모니터링 및 어그리게이션을 지원합니다. Junos OS는 트래픽을 샘플링하고, 플로우 테이블을 구축하며, 구성된 UDP 포트를 통해 플로우 테이블의 세부 정보를 수집기(이 경우 Paragon Insights)로 보냅니다. Paragon Insights는 수신되는 Netflow 데이터를 수신하고 이를 v9 또는 v10으로 자동 감지한 후 추가로 처리합니다.

위에서 볼 수 있듯이 네트워크 디바이스는 패킷 포워딩 엔진, 즉 라인 카드에서 직접 데이터를 푸시합니다. 즉, 플로우 데이터가 포워딩 플레인을 통해 전송되므로 수집기는 디바이스에 대역 내 연결이 있어야 합니다. 유량 센서 옵션을 사용하려면 유량 데이터를 보낼 위치를 포함하는 설정으로 디바이스를 구성합니다. 데이터 수집을 시작하도록 Paragon Insights를 구성할 때 플로우 데이터가 이미 서버로 흐르고 있습니다.

Paragon Insights는 추가 처리를 위해 전송하기 전에 들어오는 플로우 데이터를 식별하고 디코딩하는 메커니즘으로 플로우 템플릿을 사용합니다. Paragon Insights는 NetFlow v9 및 v10(IPFIX)에 대해 사전 정의된 플로우 템플릿을 제공하거나 사용자가 직접 정의할 수 있습니다. 사전 정의된 템플릿은 Junos OS가 현재 지원하는 템플릿과 일치합니다. 예를 들어, Junos OS 템플릿 은 ipv4-templateParagon Insights 템플릿 hb-ipfix-ipv4-template과 일치합니다. Junos OS 템플릿에 사용되는 필드를 보려면 인라인 액티브 플로우 모니터링 이해를 참조하십시오.

참고:

NetFlow의 현재 수집 구현에서는 다음 필드 유형이 지원되지 않습니다.

  • 엔터프라이즈별 요소에 대한 필드

  • 가변 길이 필드
경고:

NetFlow 수집의 경우, 디바이스와 Paragon Insights 간의 네트워크 경로에 소스 NAT가 없는지 확인합니다. 네트워크 경로에 소스 NAT가 포함된 경우 수신된 디바이스 정보가 정확하지 않습니다.

일반적인 워크플로우에는 Paragon Insights에 NetFlow 구성 디바이스 추가, NetFlow 템플릿 구성, 플로우 센서로 규칙 구성, 규칙이 포함된 플레이북을 디바이스 그룹에 구축하는 작업이 포함됩니다.

플레이북이 적용되면 디바이스 모니터링을 시작할 수 있습니다.

  1. 왼쪽 탐색 모음에서 Monitoring > Network Health(네트워크 상태 모니터링 )를 클릭하고 Device Group(디바이스 그룹 ) 탭을 클릭합니다.

  2. 디바이스 그룹 풀다운 메뉴에서 플레이북을 적용한 디바이스 그룹을 선택합니다.

  3. 모니터링할 장치 중 하나를 선택합니다.

  4. 타일 보기에서 외부 타일에는 이전에 구성한 규칙의 매개 변수가 포함됩니다.

s플로우

Paragon Insights는 또 다른 플로우 기반 수집 방법으로 sFlow(v5)를 기본적으로 지원합니다.

sFlow는 고속 스위치 또는 라우팅 네트워크를 위한 통계 샘플링 기반 기술입니다. 원하는 경우 모든 인터페이스에서 동시에 유선 속도로 트래픽을 지속적으로 모니터링하도록 sFlow를 구성할 수 있습니다.

sFlow는 다음을 제공하거나 지원합니다.

  • 기가비트 속도에서 상세하고 정량적인 트래픽 측정

  • 포워딩 결정에 대한 인사이트

  • 네트워크 문제 해결

  • 혼잡 제어

  • 보안 및 감사 추적 분석

  • 경로 프로파일링

sFlow가 위에서 수행하는 모든 작업은 포워딩 또는 네트워크 성능에 영향을 주지 않습니다. sFlow에 대한 자세한 내용은 RFC 3176, InMon Corporation의 sFlow: 스위치 및 라우팅된 네트워크에서 트래픽을 모니터링하는 방법을 참조하십시오.

통계 샘플링 프로토콜로서 주니퍼의 sFlow 에이전트는 네트워크 인터페이스의 트래픽과 카운터를 샘플링하고 sFlow 데이터그램을 생성하여 외부 sFlow 수집기로 전달합니다. Paragon Insights는 그러한 수집기 중 하나입니다.

Paragon Insights에서 sFlow 패킷을 구성하는 방법을 알아보려면 sFlow 설정 구성으로 이동하십시오.

OpenConfig

OpenConfig 형식을 사용하려면 디바이스를 gRPC 서버로 구성합니다. Paragon Insights가 클라이언트 역할을 하면서 구독할 센서를 정의하고 디바이스에 구독 요청을 합니다.

gRPC를 통해 스트리밍되는 데이터는 프로토콜 버퍼(GPB) 인코딩 메시지의 OpenConfig 키/값 쌍으로 형식이 지정됩니다. 키는 모니터링 중인 디바이스에 대한 OpenConfig 스키마의 시스템 리소스 경로에 해당하는 문자열입니다. 값은 인터페이스 카운터와 같이 시스템 리소스의 작동 상태를 식별하는 정수 또는 문자열에 해당합니다. OpenConfig RPC 메시지는 하나의 메시지에 여러 인터페이스 카운터를 제공하는 등 대량으로 전송할 수 있으므로 메시지 전송의 효율성이 높아집니다.

OpenConfig 센서에 대한 자세한 내용은 Junos Telemetry Interface의 OpenConfig 및 gRPC 이해를 참조하십시오.

gNMI로 인코딩된 OpenConfig RPC

gNMI로 인코딩된 OpenConfig는 네트워크 디바이스를 Paragon Insights가 구독 요청을 하는 OpenConfig 서버로 설정해야 한다는 점에서 OpenConfig RPC와 매우 유사하게 작동합니다. 그러나 gNMI는 Paragon Insights가 현재 지원하는 것보다 더 많은 구독 유형을 지원합니다. 현재 Paragon Insights는 샘플 모드에서 gNMI STREAM 구독만 지원합니다. STREAM 구독은 구독 내에서 구성된 경로 집합과 관련된 업데이트를 무기한으로 계속 전송하는 수명이 긴 구독입니다. 샘플 모드 스트림 구독에는 sample_interval.

gNMI를 통해 클라이언트에 반환되는 메시지는 디바이스에서 protobuf, JSON 또는 JSON-IETF 형식으로 인코딩되며 대량으로 전송할 수 없습니다. 이로 인해 부분적으로 gNMI로 인코딩된 메시징이 gRPC로 인코딩된 메시징보다 효율성이 떨어집니다.

경고:

  • JSON 또는 JSON-IETF의 경우, 디바이스가 전체 계층 또는 하위 계층을 JSON 개체로 반환하는 대신 JSON으로 인코딩된 리프 값으로만 gNMI 업데이트를 반환한다고 가정합니다.

  • JSON 또는 JSON-IETF로 인코딩된 숫자는 RFC 7159 및 RFC 7951에 따라 Paragon Insights에 의해 float64, int64 또는 문자열로 디코딩됩니다. OpenConfig 규칙에 다른 유형의 필드가 포함된 경우 그에 따라 필드 유형을 변경하는 것이 좋습니다.

Junos OS 및 Cisco 디바이스는 gNMI로 인코딩된 OpenConfig를 사용하여 Paragon Automation에서 관리할 수 있습니다. 디바이스가 일반적으로 gNMI를 지원하지 않거나 SAMPLE 모드에서 STREAM 구독을 지원하지 않거나 OpenConfig 요청을 지원하지 않는 경우 다음 오류 중 하나를 반환합니다.

  • 구현되지 않음

  • 사용할 수 없음

  • Invalid인수

Junos OS 또는 Cisco 디바이스의 경우, 오류로 인해 연결이 OpenConfig RPC로 폴백됩니다. 타사 장치의 경우 오류로 인해 연결이 실패합니다.

gNMI로 인코딩된 OpenConfig는 디바이스 또는 디바이스 그룹 수준에서 활성화할 수 있습니다. 디바이스 그룹 수준에서 활성화된 경우, 그룹에 추가된 모든 디바이스는 기본적으로 gNMI를 사용합니다. 디바이스 수준에서 활성화(또는 활성화되지 않은 경우) 디바이스 수준 설정이 디바이스 그룹 수준 설정보다 우선합니다.

참고:

초기 연결 중에 gNMI 디바이스는 클라이언트와의 초기 동기화 수행을 시도합니다. 디바이스는 디바이스와 수집기(Paragon Insights)가 동기화될 때까지 연속적인 데이터 스트림을 보냅니다. 초기 동기화 후 디바이스는 구성된 보고 속도에 따라 정상적인 스트리밍 작업을 시작합니다. 이로 인해 발생하는 처리 부하 때문에 Paragon Insights는 기본적으로 이 기능을 비활성화합니다. 필요한 경우 디바이스 그룹 또는 디바이스 수준에서 활성화할 수 있습니다.

gNMI에 대한 자세한 내용은 gRPC 네트워크 관리 인터페이스(gNMI)를 참조하십시오.

OpenConfig에 대한 디바이스 구성

OpenConfig에는 다음이 필요합니다.

  • Junos OS 버전: 16.1 이상

    • OpenConfig 센서를 사용하려면 Junos 디바이스에 OpenConfig 및 네트워크 에이전트 패키지가 설치되어 있어야 합니다. 이러한 패키지는 Junos OS 릴리스 18.2X75, 18.3 이상에 내장되어 있습니다. 16.1과 18.2X75 또는 18.2 사이의 릴리스의 경우 OpenConfig 및 네트워크 에이전트 패키지를 설치해야 합니다.

      네트워크 에이전트 패키지를 설치하기 전에:

      • Junos OS 릴리스 16.1R3 이상을 설치합니다.

      • OpenConfig for Junos OS 모듈을 설치합니다. 웹 브라우저를 사용하여 주니퍼 네트웍스 웹 페이지의 모든 Junos 플랫폼 소프트웨어 다운로드 URL( https://www.juniper.net/support/downloads/) 으로 이동합니다. 네트워크 관리 탭에서 아래로 스크롤하여 OpenConfig를 선택합니다. 소프트웨어 탭을 선택합니다. OpenConfig 패키지(업그레이드된 FreeBSD가 포함된 Junos)를 선택합니다. 자세한 내용은 OpenConfig 패키지 설치를 참조하십시오.

      • 주니퍼 네트웍스 디바이스에 SSL(Secure Sockets Layer) 인증 인증서를 설치합니다.

        참고:

        서버 기반 SSL 인증만 지원됩니다. 클라이언트 기반 인증은 지원되지 않습니다.

      유효한 네트워크 에이전트 패키지 이름의 예는 다음과 같습니다.

      network-agent-x86-32-16.1R4.12-C1.1.tgz

      참고:

      네트워크 에이전트 패키지의 각 버전은 Junos OS의 단일 릴리스에서만 지원됩니다. 지원되는 Junos OS 버전은 네트워크 에이전트 패키지 이름에 포함된 Junos OS 릴리스 번호로 식별됩니다.

      32비트 및 64비트 버전의 Junos OS 또는 Junos OS Evolved 모두에 32비트 네트워크 에이전트 패키지를 사용합니다.

      네트워크 에이전트 패키지를 다운로드하고 설치하려면 다음을 수행합니다.

      1. 주니퍼 네트웍스 웹 페이지에서 모든 Junos 플랫폼 소프트웨어 다운로드 URL로 이동합니다 : https://www.juniper.net/support/downloads/.

      2. 다운로드할 소프트웨어의 Junos OS 플랫폼 이름을 선택합니다.

      3. Download Software(소프트웨어) 다운로드 페이지의 오른쪽에 있는 Release(릴리스 ) 드롭다운 목록에서 릴리스 번호(다운로드할 소프트웨어 버전 번호)를 선택합니다.

      4. 소프트웨어 탭을 선택합니다.

      5. 소프트웨어 탭의 도구 섹션으로 이동하여 릴리스에 대한 Junos 네트워크 에이전트 패키지를 선택합니다.

      6. 주니퍼 네트웍스 담당자가 제공한 사용자 이름(일반적으로 이메일 주소)과 비밀번호를 사용하여 주니퍼 네트웍스 인증 시스템에 로그인합니다.

      7. 소프트웨어를 로컬 호스트에 다운로드합니다.

      8. 소프트웨어를 주니퍼 네트웍스 디바이스 또는 내부 소프트웨어 배포 사이트에 복사합니다.

      9. 운영 모드에서 을(를request system software add package-name) 실행하여 디바이스에 새 network-agent 패키지를 설치합니다.

        예를 들어:

        참고:

        명령은 기본적으로 이 validate 옵션을 사용합니다. 이 옵션은 디바이스가 성공적으로 재부팅되도록 소프트웨어 패키지를 추가하기 위한 전제 조건으로 현재 구성에 대해 소프트웨어 패키지의 유효성을 검사합니다. 이는 추가되는 소프트웨어 패키지가 다른 릴리스일 때의 기본 동작입니다.

      OpenConfig 및 네트워크 에이전트 패키지가 설치되어 있는지 확인하려면 다음 명령을 입력합니다.

      자세한 정보는 Junos Telemetry Interface의 OpenConfig 및 gRPC 이해 를 참조하십시오.

    • 네트워크 에이전트는 PPC 플랫폼(MX104, MX80 등)에서 지원되지 않습니다.

Device Configuration

다음 명령을 입력하여 디바이스를 구성합니다.

Paragon Automation GUI의 디바이스 구성에서 OpenConfig 포트를 구성하려면 디바이스 편집의 디바이스 편집 페이지 테이블에서 편집 가능한 필드를 참조하십시오.

시스템 로그

위의 JTI 관련 옵션 외에도 Paragon Insights는 다른 수집 메커니즘과 일치하는 데이터 모델을 사용하여 데이터 수집 방법으로 시스템 로그를 지원합니다.

디바이스는 UDP를 통해 syslog 메시지(구성된 경우)를 Paragon Insights 서버로 푸시할 수 있습니다. 라우터의 관리 인터페이스를 사용하는 라우팅 엔진(RE)을 통해 대역 외로 또는 패킷 포워딩 엔진을 통해 즉 라인 카드에서 직접 대역으로 푸시할 수 있습니다.

syslog 형식을 사용하려면 syslog 메시지를 보낼 위치를 포함하는 설정으로 디바이스를 구성합니다. 데이터 수집을 시작하도록 Paragon Insights를 구성할 때 메시지가 이미 서버로 전달되고 있습니다.

주니퍼 디바이스에서 사용되는 syslog에 대한 자세한 내용은 Junos OS 시스템 로그 개요를 참조하십시오.

syslog 메시지는 헤더, 대괄호 안에 키-값 형식의 구조화된 데이터 및 로그 메시지로 구성됩니다. 헤더는 다음 정보로 구성됩니다.

  • 로그 우선 순위

  • 헤더 형식의 Syslog 프로토콜 사양 버전 번호입니다.

    현재 이 숫자는 1입니다.

  • "Mmm dd hh:mm:ss" 형식으로 메시지가 생성된 시점의 타임스탬프입니다.

  • 호스트 이름은 syslog 메시지를 보낸 디바이스를 식별합니다.

  • 애플리케이션 이름

  • 애플리케이션 프로세스 ID

  • 메시지 ID

Paragon Insights에서 Syslog를 구성하기 위한 요구 사항

Syslog 수집은 규칙에서 센서로 사용하기 전에 몇 가지 설정이 필요합니다.

  • 패턴 - 패턴이 일부 syslog 이벤트를 식별합니다. 모니터링할 각 이벤트에 대한 패턴을 만듭니다. 구조화 및 비구조화 이벤트 모두에 대한 패턴을 구성할 수 있습니다.

  • 패턴 세트 - 패턴이 구성되면 패턴 세트로 그룹화한 다음 규칙 내에서 syslog 센서 설정을 정의할 때 참조합니다.

Syslog 수집을 위한 패턴 및 패턴 세트를 구성하기 전에 다음 필드가 syslog 메시지에서 공통적이라는 점에 유의하십시오. Paragon Insights는 이러한 필드를 추출하여 원시 테이블에 자동으로 포함시키므로 규칙을 생성할 때 직접 사용할 수 있고 패턴을 구성할 필요가 없습니다.

이러한 값의 사용을 설명하기 위해 다음 예제의 syslog 메시지를 고려하십시오.

구조화 - <30>1 2019-11-22T03:17:53.605-08:00 R1 mib2d 28633 SNMP_TRAP_LINK_DOWN [junos@2636.10.1.1.2.29 snmp-interface-index="545" admin-status="up(1)" operational-status="down(2)" interface-name="ge-1/0/0.16"] ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16

동등한 비구조화 - <30>Nov 22 03:17:53 R1 mib2d[28633]: SNMP_TRAP_LINK_DOWN: ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16

시스템 생성 필드:

  • "__log_priority__" - syslog 메시지의 우선 순위

    • 이 예에서 는 <30> 우선 순위를 나타냅니다

  • "__log_timestamp__" - syslog 메시지에서 epcoh의 타임스탬프

    • 구조화된 예 2019-11-22T03:17:53.605-08:00 에서는 시간대를 나타내는 -08:00 을 사용하여 epoch로 변환됩니다.

    • 구조화되지 않은 예에서는 구성의 표준 시간대가 epoch를 계산하는 데 사용됩니다

  • "__log_host__" - syslog 메시지의 호스트 이름

    • 예제에서 는 R1 호스트 이름을 나타냅니다.

  • "__log_application_name__" - syslog 메시지의 애플리케이션 이름

    • 예제에서 mib2d 애플리케이션 이름은

  • "__log_application_process_id__" - syslog 메시지의 애플리케이션 프로세스 ID

    • 이 예 28633 에서 ID는

  • "__log_message_payload__" - 메시지에서 페이로드

    • 구조화된 예제 - “SNMP_TRAP_LINK_DOWN [junos@2636.10.1.1.2.29 snmp-interface-index="545" admin-status="up(1)" operational-status="down(2)" interface-name="ge-1/0/0.16"] ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16”

    • 구조화되지 않은 예 - “SNMP_TRAP_LINK_DOWN: ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16”

  • "Event-id" - 패턴에 구성된 이벤트 ID를 나타냅니다

    • 예제에서 SNMP_TRAP_LINK_DOWN 이벤트 ID는

참고:

위에 이미 정의된 이름을 사용하여 새 필드를 정의하지 마십시오.

Syslog 수집을 구성하는 방법에 대한 자세한 내용은 시스템 로그 수집 구성을 참조하십시오.

서버 모니터링 센서

Paragon Automation에서 서버 모니터링 센서는 Paragon 애플리케이션을 호스팅하는 서버 및 가상 머신에서 데이터를 수집합니다. 센서는 타사 플러그인인 Node Exporter를 사용합니다. Node Exporter 플러그인은 Paragon Automation의 모든 서버 클러스터에 사전 설치되어 있습니다. GUI에서 Paragon Automation 클러스터에 배포된 기본 서버 및 가상 머신은 Paragon-Cluster 디바이스 그룹에 자동으로 추가되는 디바이스로 표시됩니다. 센서는 서버와 가상 머신에서 데이터를 수집하여 CPU, 메모리, 네트워크, 트래픽, 디스크 및 파일 시스템 메트릭을 추적합니다. 출력을 시계열 데이터베이스에 씁니다.

참고:

사용자는 기본 Paragon-Cluster 디바이스 그룹을 삭제해서는 안 됩니다.

Paragon Automation에는 서버 데이터를 모니터링하기 위해 다음과 같이 사전 구성된 플레이북이 있습니다.

  • CPU 사용률
  • 디스크 읽기 및 쓰기
  • 오류, 사용 가능한 바이트 및 파일 시스템에서 사용된 바이트
  • 사용된 바이트 및 메모리의 사용 가능한 바이트
  • 수신 및 전송된 총 패킷 크기, 수신 및 전송된 패킷의 오류, 네트워크에서 수신 및 전송된 총 멀티캐스트 패킷

서버 모니터링 수집을 사용하여 규칙을 구성할 때 표 1에 나열된 일부 센서 경로를 사용할 수 있습니다.

표 1: 서버 메트릭
센서 경로 설명
/node/boot/time/seconds 각 서버 노드의 부팅 시간입니다.
/노드/CPU/초/합계 CPU가 유휴 모드, 시스템, 사용자 및 nice 모드에 유지되는 총 시간(초)입니다.
/노드/디스크/읽기/바이트/합계 성공적으로 읽은 총 바이트 수입니다.
/node/disk/read/errors/total 노드에서 총 읽기 오류 수입니다.
/노드/디스크/읽기/재시도/합계 오류가 발생할 경우 수집이 디스크에서 읽기를 시도하는 횟수입니다.
/node/disk/read/sectors/total 성공적으로 읽은 총 섹터 수입니다.
/노드/디스크/읽기/시간/초/합계 노드당 읽기를 성공적으로 완료하는 데 걸리는 총 시간입니다.
/노드/디스크/읽기/완료/합계 성공적으로 완료된 총 읽기 수입니다.
/node/disk/write/errors/total 쓰기의 총 오류 수
/node/disk/write/retries/total 오류가 발생할 경우 수집이 디스크에 쓰기를 시도하는 횟수입니다.
/node/disk/write/time/seconds/total 모든 쓰기를 완료하는 데 걸리는 총 시간입니다.
/노드/디스크/쓰기/완료/합계 노드당 완료된 총 쓰기 수입니다.
/노드/디스크/쓰기/바이트/합계 성공적으로 기록된 총 바이트 수입니다.
/node/disk/written/sectors/total 성공적으로 작성된 총 섹터 수입니다.
/노드/내보내기/빌드/정보 값이 '1'이고 노드 내보내기가 빌드되는 버전, 개정, go 버전 및 브랜치가 있는 메트릭입니다.
/노드/파일 시스템/avail/바이트 루트가 아닌 사용자가 사용할 수 있는 파일 시스템 크기입니다.
/node/filesystem/device/오류 파일 시스템에서 데이터를 수집할 때 발생하는 I/O 오류 수입니다.
/노드/파일 시스템 / 파일 노드에서 허용되는 총 인덱스 노드 수입니다.
/노드/파일 시스템/파일/무료 노드에서 자유롭게 사용할 수 있는 인덱스 노드 수입니다.
/노드/파일 시스템/무료/바이트 예약된 블록을 제외하고 사용자가 사용할 수 있는 여유 공간(바이트)입니다.
/node/filesystem/readonly 노드의 파일 시스템이 읽기 전용으로 마운트되었는지 보여주는 데이터입니다.
/노드/파일 시스템/크기/바이트 모든 파일의 크기(바이트)입니다.
/노드/로드1 1분마다 캡처되는 각 서버/호스트 노드의 부하입니다.
/노드/로드15 15분마다 캡처되는 각 서버/호스트 노드의 부하입니다.
/노드/로드5 5분마다 캡처되는 각 서버/호스트 노드의 부하입니다.
/노드/메모리/액티브/바이트 프로세스에서 적극적으로 사용되는 메모리 바이트입니다.
/노드/메모리/압축/바이트 압축된 메모리의 총 크기입니다.
/노드/메모리/여유 시간/바이트 노드에서 사용할 수 있는 총 메모리(바이트)입니다.
/노드/메모리/비활성/바이트 프로세스에서 적극적으로 사용되지 않는 메모리 바이트입니다.
/노드/메모리/스왑/합계/바이트 노드에서 스왑된 총 메모리입니다.
/노드/메모리/스왑/사용/바이트 노드에서 사용되는 스왑된 메모리의 양입니다.
/node/memory/swapped/in/bytes/total 노드의 메모리에서 스왑된 총 숫자입니다.
/node/memory/swapped/out/bytes/total 노드에서 스왑된 총 메모리입니다.
/노드/메모리/합계/바이트 노드의 총 메모리 바이트입니다.
/노드/메모리/유선/바이트 스왑 아웃할 수 없는 메모리입니다.
/노드/네트워크/수신/바이트/합계 디바이스가 수신한 패킷의 총 크기입니다.
/노드/네트워크/수신/오류/합계 패킷을 수신할 때 디바이스에서 발생한 총 오류 수.
/노드/네트워크/수신/멀티캐스트/합계 디바이스가 수신한 총 멀티캐스트 패킷 수입니다.
/노드/네트워크/수신/패킷/합계 디바이스가 수신한 총 패킷 수입니다.
/노드/네트워크/전송/바이트/합계 디바이스에서 전송된 패킷의 총 크기.
/노드/네트워크/전송/오류/합계 패킷을 전송할 때 디바이스에서 발생한 총 오류 수.
/노드/네트워크/전송/멀티캐스트/합계 디바이스에서 전송한 총 멀티캐스트 패킷 수입니다.
/노드/네트워크/전송/패킷/합계 디바이스에서 전송한 총 패킷 수입니다.
/node/scrape/collector/duration/seconds 각 수집기가 메트릭을 스크랩하는 데 걸리는 시간입니다.
/node/scrape/collector/success 노드 내보내기 수집기가 대상을 스크랩한 횟수입니다.
/node/textfile/scrape/error 텍스트 파일 스크립트를 사용하여 대상을 스크래핑할 때 Node Exporter에서 발생하는 오류입니다.
/노드/시간/초 epoch(1970) 이후 노드의 시스템 시간을 초 단위로 표시합니다.
/노드/uname/info Node Exporter가 메트릭을 수집하는 노드의 이름입니다.

모드, 디바이스 등과 같은 다음 태그는 주요 메트릭(/node/cpu 또는 /node/network) 아래에 나열된 모든 메트릭에 적용할 수 있는 키 필드로 사용할 수 있습니다.

규칙에 키 필드를 구성할 때 경로 필드에는 키 필드 이름만 언급할 수 있습니다.

  • /노드/cpu/
    • cpu: CPU에서 사용 가능한 코어 수입니다.
    • mode: 유휴, 시스템, 사용자, nice 등 노드의 CPU 사용량 유형입니다.
  • /노드/디스크/
    • device: disk0, disk1, sda, sdb 또는 sdc와 같은 디스크의 이름입니다.
  • /노드/파일 시스템/
    • device: /dev/sda1, /dev/sda2, /dev/sdb1과 같은 디스크 경로
    • fstype: ext4, NTFS(New Technology File System), APFS(Apple File System)와 같은 파티션 포맷 유형입니다.
    • mountpoint: 디바이스의 마운트 경로입니다.
  • /노드/네트워크/
    • device: 디바이스의 인터페이스 이름(예: wlan0, en0 또는 docker0)입니다.

Server Monitoring 수집을 사용하여 예제 규칙을 구성하려면 Server Monitoring Sensor를 사용하여 규칙 구성을 참조하십시오.

iAgent(CLI/NETCONF)

'푸시' 데이터 수집 방법의 모든 이점을 위해 일부 운영 및 상태 정보는 CLI/VTY 명령을 통해서만 사용할 수 있습니다. iAgent는 NETCONF/SSH 기능을 활용하여 Paragon Automation에 디바이스에 연결하고, 명령을 실행하고, 출력을 캡처할 수 있는 기능을 제공함으로써 이러한 격차를 메웁니다.

iAgent 센서는 NETCONF/SSH 및 YAML 기반 PyEZ 테이블과 뷰를 사용하여 필요한 데이터를 가져옵니다. 구조화된(XML) 및 구조화되지 않은(VTY 명령 및 CLI 출력) 데이터가 모두 지원됩니다.

iAgent를 사용하면 Paragon Automation 서버는 대역 내 또는 대역 외에 관계없이 사용 가능한 모든 네트워크 인터페이스를 통해 인바운드 SSH 요청을 시작합니다. 디바이스가 요청된 데이터로 응답합니다(올바르게 구성된 경우).

Paragon Automation Platform에서 iAgent 수집은 Arista Networks, Palo Alto Networks 및 Cisco의 다른 벤더 장치로 확장됩니다.

iAgent 센서 또는 NETCONF 연결을 사용하여 텔레메트리 데이터를 전송하도록 Junos 디바이스를 구성해야 합니다.

최소한 iAgent(NETCONF)에는 다음이 필요합니다.

  • Junos OS 버전: 11.4 이상

  • 최소 필수 디바이스 구성:

Paragon Automation GUI에서 인바운드 연결을 위해 iAgent 또는 NETCONF 포트를 구성하려면 표 1을 참조하십시오.

Paragon Automation은 Netmiko를 사용하여 선택한 포트를 통해 타사 디바이스에 인바운드 SSH 연결을 만듭니다. 디바이스 정보를 수집하기 위해 Paragon Automation은 SSH를 통해 CLI 명령을 전송하고 문자열 Blob을 출력으로 다시 수신합니다. 그런 다음 문자열 Blob은 NTC 템플릿을 사용하여 JSON 형식으로 TextFSM을 통해 구문 분석된 다음 데이터베이스에 저장됩니다. 기본 템플릿은 /srv/salt/_textfsm에 있습니다. 네트워크 디바이스용 NTC 템플릿 의 GitHub 리포지토리를 방문할 수 있습니다.

존재하지 않는 템플릿이 필요한 고급 사용자의 경우, 구성 > 규칙 페이지의 규칙 파일 업로드 버튼을 사용하여 자체 템플릿을 만들어 Paragon Insights에 업로드할 수 있습니다. 사용자 정의 템플릿은 /jfit/_textfsm에 저장됩니다. 파일은 .textfsm 접미사로 끝나야 합니다. Paragon Automation Platform에서 사전 정의된 규칙을 업로드하는 방법에 대한 자세한 내용은 사전 정의된 규칙 추가를 참조하십시오.

TextFSM은 iAgent의 필수적인 부분인 PyEZ의 테이블/뷰 기능에 통합되어 있습니다.

Example: PaloAlto Panos– Show Running Security Policy

Panos 디바이스에서 실행 중인 보안 정책을 보려면 다음을 수행해야 합니다.

PyEZ 테이블/뷰 정의

Panos 디바이스에 할당된 iAgent 규칙에서 사용하는 PyEZ 테이블을 정의해야 합니다. 다음 테이블 정의에는 뷰 정의가 없습니다. 이 때문에 처리된 후 데이터베이스에 저장되는 전체 출력 show running security-policy 이 끝납니다.

(선택 사항) 수신된 데이터의 일부만 Paragon Automation에 저장하려면 동일한 파일에 보기를 정의할 수 있습니다. 이 보기는 Paragon Automation이 어떤 분야에 주의해야 하는지 알려줍니다.

디바이스에서 출력 수집

Paragon Automation은 위에서 정의한 PyEZ 테이블(또는 테이블/뷰)을 참조하는 iAgent 규칙을 사용하여 다음 출력을 생성하는 디바이스에 명령을 show running security-policy 보냅니다.

Paragon Automation 데이터베이스에서 사용할 JSON 생성

디바이스 구성에서 Palo Alto Networks를 공급업체로 지정하고 Panos OS를 운영 체제로 지정하므로 이 예제에 사용된 TextFSM 템플릿은 다음과 같습니다.

Paragon Automation에서 위의 템플릿을 사용하여 이전에 표시된 출력을 구문 분석하면 결과 JSON은 다음과 같습니다.

아웃바운드 SSH(디바이스 시작)

Paragon Automation은 또한 아웃바운드 SSH를 사용하여 디바이스에서 시작되는 iAgent(NETCONF) 연결을 지원합니다. 이 구성을 통해 Paragon Automation은 연결하는 디바이스에 클라이언트 역할을 합니다. 이러한 유형의 연결은 원격 디바이스가 들어오는 연결을 수락할 수 없는 환경에서 유용합니다. 아웃바운드 SSH가 Junos 디바이스에 구성될 때 기존의 모든 iAgent 규칙을 사용할 수 있습니다.

참고:

SSH 연결을 통한 NETCONF는 Junos 디바이스에서만 지원됩니다.

아웃바운드 SSH는 기본적으로 비활성화되어 있습니다. 아웃바운드 SSH 연결을 구성할 수 있습니다.

  • 단일 포트를 구성하여 수집할 때 이 포트는 모든 디바이스 그룹에서 사용됩니다.

  • device-groups에서 포트를 구성합니다. 이 구성은 수집 구성보다 우선합니다.

디바이스 그룹에서 아웃바운드 SSH를 구성할 때, 모든 멤버 디바이스가 Paragon Automation에 대한 NETCONF 연결을 시작하는 TCP 포트 번호를 입력해야 합니다. 관리 CLI를 통해 디바이스에서 아웃바운드 SSH를 비활성화할 수 있습니다. 디바이스 그룹에서 아웃바운드 SSH 포트를 구성하려면 디바이스 그룹 추가에서 디바이스 그룹 구성의 포트 섹션을 참조하십시오.

Paragon Automation은 모든 디바이스 그룹에서 단일 TCP 포트 for iAgent(NETCONF) 아웃바운드 SSH 연결을 지원합니다. 이 포트는 수집 수준에서 구성할 수 있습니다. 서로 다른 디바이스 그룹에서 여러 TCP 포트를 열 필요가 없으며 단일 포트로 네트워크 관리를 단순화할 수 있습니다. 수집 시 iAgent 포트를 구성하려면 iAgent에 대한 아웃바운드 SSH 포트 구성을 참조하십시오.

각 클라이언트가 동일한 포트를 갖는 여러 클라이언트를 구성하여 아웃바운드 SSH를 통해 서로 다른 디바이스 그룹에서 관리되는 디바이스를 연결할 수 있습니다. 이 경우 디바이스 그룹의 수만큼 디바이스의 복사본을 생성해야 합니다. 각 디바이스는 동일한 포트 번호를 가져야 합니다.

예를 들어, 디바이스 그룹 dg1 및 dg2에 대해 구성된 디바이스 r0(10.1.1.1)을 생각해 보십시오. 동일한 아웃바운드 SSH 포트를 통해 두 디바이스 그룹에 10.1.1.1을 연결하려면 동일한 IP를 가진 디바이스 r1(10.1.1.1)을 하나 더 생성하여 dg2에 구축할 수 있습니다.

또한 각 디바이스 그룹에서 이러한 포트에 대해 Paragon Automation을 구성해야 합니다. 그림 1 은 디바이스 그룹 구성의 예입니다.

그림 1: 디바이스 그룹 구성 Edit Device Group Configuration 편집

다음 샘플 클라이언트 구성을 사용하여 디바이스 10.1.1.1은 동일한 포트를 가진 두 개의 아웃바운드 SSH 클라이언트를 사용하여 두 개의 디바이스 그룹에 연결할 수 있습니다.

참고:

예시의 10.1.1.1은 Paragon Automation(호스트) IP 주소를 나타냅니다.

SNMP

SNMP는 널리 알려져 있고 널리 인정되는 네트워크 관리 프로토콜로, 주니퍼 네트웍스를 비롯한 많은 네트워크 디바이스 제조업체가 해당 디바이스와 함께 사용하도록 제공합니다. SNMP를 사용하도록 구성된 네트워크 디바이스가 수집기에서 구성, 진단 및 이벤트 정보를 사용할 수 있도록 하는 폴링 유형 프로토콜이며, 이러한 정보도 올바르게 구성 및 인증되어야 합니다. 수집기는 데이터를 검색하기 위해 get 요청이라는 구체적으로 구조화된 요청을 전송하여 디바이스를 폴링합니다.

Paragon Automation은 표준 GET 요청을 사용하여 디바이스에서 통계를 수집하는 센서 유형으로 SNMP를 지원합니다. Paragon Automation은 대역 내 또는 대역 외 사용 가능한 모든 인터페이스를 통해 요청하고 디바이스는 요청된 데이터로 응답합니다(구성된 경우).

Junos OS 디바이스에서 사용되는 SNMP에 대한 자세한 내용은 Junos OS의 SNMP 구현 이해를 참조하십시오.

또한 Paragon Insights는 SNMP에서 테이블 형식 객체와 함께 스칼라 객체 인스턴스를 지원합니다.

  • SNMP 개체는 규칙에서 스칼라, 테이블 형식 또는 이 둘의 조합일 수 있습니다. SNMP 수집을 사용하여 규칙을 생성할 때 다음을 추가할 수 있습니다.

    • 스칼라 필드만 해당됩니다.

    • 테이블 형식 및 스칼라 필드의 조합.

    • 스칼라 객체로 쿼리된 인덱스와 함께 테이블 형식 열입니다.

      스칼라로 쿼리되는 테이블 형식 열에는 규칙에서 테이블 형식 필드를 구성할 때 인덱스 번호가 모든 디바이스에서 동일한 개체를 참조하지 않는다는 제한이 있습니다. 예를 들면 . IF-MIB::ifAdminStatus.16 ifAdminStatus는 IF MIB 테이블의 열입니다. 인덱스 IF-MIB::ifAdminStatus.16 가 16인 테이블 열을 참조합니다.

    • 테이블 형식 필드만 표시됩니다.

  • 스칼라 객체는 MIB 이름(예: JUNIPER-MIB::scalarObjectName) 또는 OID로 식별됩니다.

  • Paragon Insights는 MIB 정의의 속성을 확인 MAX-ACCESS 하여 주어진 스칼라를 검증합니다.

    MIB 정의에서 읽기 전용, 읽기-생성 또는 읽기-쓰기로 설정된 경우 MAX-ACCESS , 해당 개체를 스칼라로 쿼리할 수 있습니다.

스칼라 객체를 쿼리하는 전체 경로는 MIB-Name::table column name:index number입니다.

예를 들면 . IF-MIB::ifInOctets:16

다음은 뭘까요