Paragon Insights 개념

데이터 수집 - '푸시' 모델

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

'푸시' 모델은 데이터를 비동기 전송하여 이러한 한계를 극복하고 폴링을 제거합니다. 이 모델을 사용하면 Paragon Insights 서버가 네트워크 디바이스에 단일 요청을 수행하여 주기적인 업데이트를 스트리밍할 수 있습니다. 그 결과, '푸시' 모델은 확장성이 뛰어나며 네트워크에서 수천 가지 개체의 모니터링을 지원할 수 있습니다. Junos 디바이스는 Junos 텔레메트리 인터페이스 (JTI)의 형태로 이 모델을 지원합니다.

Paragon Insights 현재 다섯 가지 '푸시' 수집 유형을 지원합니다.

• 네이티브 GPB

• NetFlow

• sFlow

• OpenConfig

• Syslog

이러한 푸시 모델 데이터 수집(또는 수집)은 Paragon Insights 데이터 수집 가이드에 자세히 설명되어 있습니다.

데이터 수집 - '풀' 모델

'푸시' 모델은 효율성과 확장성을 위해 선호되는 접근 방식이지만, 여전히 '풀' 데이터 수집 모델이 적절한 경우가 있습니다. '풀' 모델에서 Paragon Insights 주기적인 간격으로 네트워크 디바이스의 데이터를 요청합니다.

Paragon Insights 현재 두 가지 '풀' 수집 유형을 지원합니다.

• iAgent(CLI/NETCONF)

• Snmp

이러한 풀 모델 데이터 수집(또는 수집)은 Paragon Insights 데이터 수집 가이드에 자세히 설명되어 있습니다.

규칙

규칙은 하드 코딩에서 자유로워지게 됩니다. 임계값을 생각해 보십시오. 임계값이 하드 코딩되면 요구 사항이 다른 다른 고객 또는 디바이스에 맞게 쉽게 사용자 지정할 수 있습니다. 따라서 기본 값을 설정하기 위해 매개 변수화를 사용하여 규칙이 정의됩니다. 이를 통해 매개 변수를 기본적으로 남겨 두거나 구축 시 운영자가 사용자 정의할 수 있습니다. 개별 규칙이 포함된 Paragon Insights 플레이북 을 적용하는 동안 디바이스 그룹 또는 개별 디바이스 수준에서 사용자 지정할 수 있습니다.

디바이스 중심 규칙을 디바이스 규칙이라고 합니다. 섀시, 시스템, 라인 카드 및 인터페이스와 같은 디바이스 구성 요소는 모두 규칙 정의에서 Paragon Insights 항목 으로 처리됩니다. 일반적으로 디바이스 규칙은 디바이스에서 센서를 사용합니다.

여러 디바이스에 걸친 규칙을 네트워크 규칙이라고 합니다. 네트워크 규칙:

• 반드시 규칙 주파수를 구성해야 합니다.

• 센서를 포함하지 않아야 합니다.

• 플레이북에서 디바이스 규칙을 혼합할 수 없음

규칙 유형 중 하나를 구축하려면 플레이북에 규칙을 포함시키고 해당 플레이북을 디바이스 그룹 또는 네트워크 그룹에 적용합니다.

규칙을 구성하는 모든 블록이 모든 규칙에 필요한 것은 아닙니다. 규칙 정의에서 특정 블록이 필요한지 여부는 어떤 정보를 얻으려는지에 달려 있습니다. 또한 일부 규칙 구성 요소는 네트워크 규칙에 대해 유효하지 않습니다. 표 1 은 규칙의 구성 요소를 나열하고 각 규칙에 대한 간략한 설명을 제공합니다.

센서

센서를 정의할 때는 센서 이름, 센서 유형, 데이터 수집 빈도와 같은 정보를 지정해야 합니다. 표 1에서 언급했듯이 센서는 다음 중 하나가 될 수 있습니다.

• OpenConfig

  OpenConfig JTI 센서에 대한 자세한 내용은 을(를) 참조하십시오 . /.. /.. /.. /.. /.. /.

• Native GPB

  네이티브 GPB JTI 센서에 대한 자세한 내용은 을(를) 참조하십시오 . /.. /.. /.. /.. /.. /.

• iAgent

  iAgent 센서는 NETCONF 및 YAML 기반 PyEZ 테이블과 뷰를 사용하여 필요한 데이터를 가져옵니다. 구조화된(XML) 및 비정형(VTY 명령 및 CLI 출력) 데이터가 모두 지원됩니다. Junos PyEZ에 대한 자세한 내용은 Junos PyEz 설명서를 참조하십시오.

• SNMP	단순한 네트워크 관리 프로토콜.

• syslog

  시스템 로그

• BYOI	고유한 수집 기능 제공 – 수집 유형을 직접 정의할 수 있습니다.

• Flow	NetFlow 트래픽 플로우 분석 프로토콜

• sFlow

  sFlow 패킷 샘플링 프로토콜

규칙이 동일한 센서를 정의하면 센서당 하나의 구독만 이뤄집니다. OpenConfig 및 네이티브 GPB 센서를 위한 센서 경로 로 구성된 키와 iAgent 센서용 파일 및 테이블 튜플을 사용하여 관련 규칙을 식별합니다.

동일한 센서 경로 키를 가진 여러 센서가 서로 다른 주파수를 정의할 경우, 센서 구독 시 가장 낮은 주파수가 선택됩니다.

필드

표 1에 나열된 것처럼 네 가지 유형의 필드 소스가 있습니다. 표 2에서는 4가지 필드 수집 유형을 자세히 설명합니다.

벡터

벡터는 여러 요소를 단일 규칙으로 수집하는 데 유용합니다. 예를 들어, 벡터를 사용하여 모든 인터페이스 오류 필드를 수집할 수 있습니다. 벡터의 구문은 다음과 입니다.

$field-n은 유형 참조 필드일 수 있습니다.

벡터를 정의하는 데 사용되는 필드는 다른 규칙에 정의된 필드에 대한 직접 참조가 될 수 있습니다.

이 구문을 사용하면 구조의 <field-name>=<field-value> 부분을 통한 선택적 필터링이 가능합니다. 또한 벡터는 제공된 시간 범위에서 값을 선택하는 시간 범위 옵션을 사용할 수 있습니다. 주어진 시간 범위에 걸쳐 여러 값이 반환되면 모두 배열로 선택됩니다.

다음과 같은 사전 정의된 공식이 벡터에서 지원됩니다.

• unique @vector1–벡터의 고유한 요소 집합을 반환합니다1

• @vector1 and @vector2–벡터1과 벡터2에서 고유한 요소의 교집합을 반환합니다.

• @vector1 or @vector2–두 벡터에서 총 고유 요소 집합을 반환합니다.

• @vector1 unless @vector2–벡터-2에서는 아니지만 벡터-1의 고유한 요소 집합을 반환합니다.

변수

변수는 변수 페이지에서 규칙 생성 중에 정의 됩니다 . 변수 정의의 이 부분은 구축 중에 디바이스 그룹 또는 디바이스에서 특정 값이 설정되지 않은 경우 사용되는 기본값을 생성합니다. 예를 들어, 이 규칙에는 라는 check-interface-status 하나의 변수가 있습니다 interface_name. 변수 페이지에서 설정된 값은 정규 표현식(regex) .*이며, 이는 모든 인터페이스를 의미합니다.

있는 그대로 적용되면, check-interface-status 규칙은 디바이스 그룹의 모든 디바이스의 모든 인터페이스에 대한 인터페이스 상태 정보를 제공합니다. 이 규칙이 포함된 플레이북을 적용하는 동안 디바이스 그룹 또는 디바이스 수준에서 기본값을 재정의할 수 있습니다. 이를 통해 규칙을 적용할 때 유연성을 제공합니다. 우선 순위 순서는 디바이스 값이 디바이스 그룹 값을 재정의하고 디바이스 그룹 값이 규칙에서 설정된 기본 값을 재정의하는 것입니다.

함수

기능은 기능 탭에서 규칙을 생성하는 동안 정의됩니다. 여기에서 함수를 정의하면 필드와 관련된 공식과 트리거의 때 및 다음 섹션에서 함수를 사용할 수 있습니다. 트리거의 경우 절에서 사용되는 함수는 사용자 정의 기능으로 알려져 있습니다. 이들은 사실 또는 거짓을 반환해야합니다. 트리거의 다음 절에서 사용되는 기능을 사용자 정의 작업으로 알려져 있습니다.

트리거

트리거는 규칙 정의를 Paragon Insights 중요한 역할을 합니다. 사용 가능한 센서 데이터의 변경 사항에 따라 어떤 조치가 취해지는지 여부와 시기를 결정하는 규칙의 일부입니다. 트리거는 시기와 그 방식으로 구성됩니다. 앞서 언급했듯이 트리거 작업은 약관을 기반으로 합니다. 용어 는 필드 값의 업데이트를 감시 하는 절과 변경된 사항에 따라 일부 작업을 시작하는 절으로 구축됩니다. 하나의 트리거 내에서 여러 용어를 생성할 수 있습니다.

약관의 절이 용어 목록의 맨 위에서 시작하여 맨 아래로 진행되는 경우 평가. 용어가 평가되고 일치가 이루어지지 않으면 다음 용어가 평가됩니다. 기본적으로 평가는 일치가 이루어지거나 목록 맨 아래에 일치하지 않고 도달할 때까지 이 방식으로 진행됩니다.

때 절에서 사용할 수 있는 사전 정의된 연산자는 다음을 포함합니다.

• 중대형–한 값이 다른 값보다 큰지 확인하는 데 사용됩니다.

  • 반환: True 또는 False

  • 구문: <LHS> <RHS>보다 큰 [시간 범위 <레인지>]

  • 예제: //Memory > 3000 MB in the last 5 minutes

    when greater-than $memory 3000 time-range 5m;

• 초과 또는 equal-to-to-equal-to-greater-than-but >=보다 크거나 동일한지 확인합니다.

• 보다 적은 수

  • 반환: True 또는 False

  • 구문: [time-range <range>] <LHS> <RHS> 미만

  • 예제: //Memory < 6000 MB in the last 5 minutes

    when less-than $memory 6000 time-range 5m;

• 에 비해 같거나 같지만(<=) 보다 낮거나 동일한지 확인합니다.

• equal-to-한 값이 다른 값과 동일한지 확인하는 데 사용됩니다.

  • 반환: True 또는 False

  • 구문: <LHS> <RHS>[time-range <range>]

  • 예제: //Queue’s buffer utilization % == 0 

    when equal-to $buffer-utilization 0;

• 동일하지는 않지만 부정적인 상태를 확인합니다(!=)

• 기존- 값 자체를 신경 쓰지 않고 일부 값이 존재하는지 확인하는 데 사용됩니다. 즉, 디바이스에서 일부 값이 전송되어야 합니다.

  • 반환: True 또는 False

  • 구문: [시간 범위 <레인지>]<$var> 존재합니다.

  • 예제: //Has the device configuration changed? 

    when exists $netconf-data-change

• matches-with(문자열 및 regex용) - Python regex 작업을 사용하여 문자열에서 일치 항목을 확인하는 데 사용됩니다. 자세한 내용은 구문을 참조하십시오.

  참고:

  LHS(왼쪽)는 우리가 검색하는 문자열입니다. RHS 또는 오른손은 일치 표현식입니다. 정규 표현식은 RHS에서만 사용할 수 있습니다.

  • 반환: True 또는 False

  • 구문: <LHS> <RHS>[시간 범위 <레인지>]와 일치합니다.

  • 예제: //Checks that ospf-neighbor-state has been UP for the past 10 minutes

    when matches-with $ospf-neighbor-state “^UP$” time-range 10m;

  예 1: 한 번 더 백슬래시 '\'로 이스케이프 백슬래시 '\'

  escape \ with one more \

  예 2: escape \ with one more \

• does-not-match-with(문자열 및 regex용)– match-with와 동일하지만 부정적인 상태 확인

• 범위–값 X가 최소 및 최대(최소 <= X <= 최대)와 같은 주어진 범위 내에 있는지 확인합니다.

  • 반환: True 또는 False

  • 구문: 범위 <$var> 최소 <미미움 값> 최대 <maximum 값> [시간 범위 <레인지>]

  • 예제: //Checks whether memory usage has been between 3000 MB and 6000 MB in the last 5 minutes

    when range $mem min 3000 max 6000 time-range 5m;

• value-by-value 증가 – 값이 이전 값에 비해 최소한 최소 허용 속도로 증가하는지 확인하는 데 사용됩니다. 허용되는 최소 증가 속도를 정의하는 선택적 매개 변수를 제공할 수 있습니다. 을(를) 지정하지 않을 경우 최소 허용 가능한 증가 속도는 기본값을 1로 증가합니다.

  • 반환: True 또는 False

  • 구문:

    증가-최소-값 <$var> [연속 포인트 간 증가의 증분 <최대 가치>]

    증가-최소-값별 <$var> [연속 포인트 사이 증가의 증분 <마미움 값>] 시간 범위 <레인지>

  • 예제: Checks that the ospf-tx-hello has been increasing steadily over the past 5 minutes.

    when increasing-at-least-by-value $ospf-tx-hello increment 10 time-range 5m;

• 최대값으로 증가- 이전 값에 비해 허용되는 최대 속도보다 값이 증가하는지 확인하는 데 사용됩니다. 허용되는 최대 증가 속도를 정의하는 선택적 매개변수가 제공될 수 있습니다. 을(를) 지정하지 않을 경우 최대 허용 가능한 증가 속도는 기본값을 1로 입니다.

  • 반환: True 또는 False

  • 구문:

    최대가 증가 <$var> [연속> 포인트 간 최대치 증가<최대치 값]

    증가-at-most-value <$var> [연속 지점 간 증가 <maximum 값>] 시간 범위 <레인지>

  • 예제: Checks that the error rate has not increased by more than 5 in the past 5 minutes.

    when increasing-at-most-by-value $error-count increment 5 time-range 5m;

• 증가-최소 속도–연속 값 간의 증가 속도는 최소한 주어진 속도 확인에 사용 됩니다. 필수 매개 변수에는 값과 시간 단위가 포함되며, 이는 함께 허용되는 최소 증가 속도를 의미합니다.

  • 반환: True 또는 False

  • 구문:

    이 구문은 현재 값을 이전 값과 비교하여 적어도 가치 비율로 증가하도록 보장합니다.

    연속 포인트 간 증가-최소 속도 <$var> 값 <><초|분|시간|day|week|year>[time-range <range>]

    이 구문은 현재 값을 이전 값과 비교하여 적어도 백분율 비율로 증가하도록 보장합니다.

    <초당 최소 속도 <$var><percentage>><초|분|시간|day|week|year|year>[time-range <range>]

  • 예제: Checks that the ospf-tx-hello has been increasing strictly over the past five minutes.

    when increasing-at-least-by-rate $ospf-tx-hello value 1 per second time-range 5m;

• 최다 속도의 증가–이 비율이 감소하는지 확인하는 것을 제외하고는 최소한 속도씩 증가하는 것과 유사합니다.

이 연산자를 when 절에서 사용하면 사용자 정의 조건으로 알려진 함수를 생성합니다. 이러한 기능은 항상 true 또는 false로 돌아가야 합니다.

용어를 평가하면 일치가 발생하면 Then 절에 지정된 작업이 수행됩니다. 기본적으로 용어 처리는 이 시점에서 중단됩니다. 다음 절 하단에 있는 다음 용어 평가 단추를 활성화하여 이 플로우를 변경할 수 있습니다. 이로 인해 Paragon Insights 용어 처리를 계속하여 시기와 이와 같은 보다 복잡한 의사 결정 기능을 생성하게 됩니다.

다음은 다음 섹션에서 사용할 수 있는 사전 정의된 작업 목록입니다.

• 다음

• 상태

태그

릴리스 3.1.0부터 HealthBot 태깅을 지원합니다. 태깅을 사용하면 특정 조건이 충족될 때 필드, 값 및 키를 Paragon Insights 규칙에 삽입할 수 있습니다. 자세한 내용은 Paragon Insights 태깅을 참조하십시오.

규칙 속성

규칙 속성 차단을 사용하면 하드웨어 종속성, 소프트웨어 종속성, 버전 기록과 같은 Paragon Insights 규칙에 대한 메타데이터를 지정할 수 있습니다. 이 데이터는 정보 목적으로 사용하거나 디바이스가 Paragon Insights 규칙과 호환되는지 여부를 확인하는 데 사용할 수 있습니다.

사전/사후 조치

(선택 사항) Paragon Insights 릴리스 4.3.0부터는 규칙의 사전 작업 및 사후 작업 탭을 사용하여 작업 엔진 워크플로우에서 미리 구성된 작업을 자동화할 수 있습니다. 작업 엔진 워크플로우는 명령줄 명령, NETCONF 명령 또는 실행 파일에서 명령으로 실행할 수 있는 작업을 수행하는 데 사용됩니다. 자세한 내용은 작업 엔진 워크플로우 이해를 참조하십시오.

디바이스 그룹에서 플레이북 인스턴스를 실행하면 Paragon Insights 플레이북 인스턴스화 시작 시 사전 작업 작업을 실행합니다. 사전 작업 작업은 디바이스 그룹에서 디바이스 구성을 실행하거나 다른 애플리케이션에 디바이스 상태에 대한 알림을 발행하는 데 유용합니다. 여러 사전 작업 작업과 사전 작업 작업 및 규칙 실행 사이에는 종속성이 없습니다. 규칙에 두 개 이상의 사전 작업 작업을 구성하는 경우, Paragon Insights 모든 사전 작업 작업을 동시에 실행합니다.

Paragon Insights 플레이북 인스턴스를 중지할 때 작업 후 작업을 실행합니다. 선택적 구성이지만, 작업 후 작업은 사전 작업 작업을 통해 디바이스에 추가된 추가 구성을 제거하는 데 유용합니다.

실행 전 및 사후 작업 모두 실행-한 번 옵션이 있습니다. 기본적으로, execute-once는 비활성화됩니다. 일단 실행을 활성화하면 Paragon Insights 디바이스 그룹의 디바이스에서 한 번만 작업을 실행합니다. 실행 1회는 다음과 같은 경우에 적용됩니다.

• 동일한 디바이스 그룹에서 플레이북의 여러 인스턴스를 실행할 때.

• 다른 플레이북에 사전 작업 또는 사후 작업 세트가 있는 규칙을 포함하고 동일한 디바이스 그룹에서 플레이북 인스턴스를 실행합니다.

Paragon Insights 디바이스 그룹에서 디바이스에서 실행하기 전에 사전 작업 및 사후 작업 중복을 확인하고 해결합니다. 중복은 플레이북에 포함된 여러 규칙에서 특정 사전 작업 또는 사후 작업 작업을 구성할 때 발생합니다.

규칙에서 사전 작업 작업과 사후 작업 구성은 Paragon Insights 규칙 및 플레이북을 참조하십시오.

디바이스당 여러 센서

Paragon Insights 릴리스 4.0.0을 사용하면 규칙당 여러 센서를 추가하여 디바이스 그룹의 모든 디바이스에 적용할 수 있습니다. 이전 릴리스에서는 규칙당 하나의 센서만 추가할 수 있습니다. 규칙당 각 센서는 필드 테이블에서 데이터를 생성합니다. 여러 규칙에 다른 센서를 추가하면 규칙 수만큼 많은 필드 테이블이 발생합니다. Paragon Insights 단일 규칙에서 여러 유형의 센서(예: OpenConfig 또는 Native GPB)를 추가할 때, 센서의 데이터는 내보내기 또는 시각화가 더 간단한 단일 필드 테이블에 통합됩니다. 여러 센서 구성에 대한 GUI 지원은 후속 릴리스에서 구현됩니다.

• 가이드
• Paragon Insights GUI에서 여러 센서 구성
• 사용 사례

센서 우선 순위

센서에서 효과적으로 데이터를 수집하려면 디바이스 그룹의 디바이스가 특정 센서를 수집 방법으로 지원해야 합니다. 이전 버전의 운영 체제를 실행하는 디바이스, 디바이스 그룹의 다른 벤더의 디바이스 또는 동일한 벤더의 다른 제품(예: Juniper EX, MX 및 PTX 라우터)을 실행하는 디바이스 그룹에서 선택하는 모든 시나리오는 디바이스 그룹에 센서를 적용하는 데 문제를 일으킬 수 있습니다. 이러한 경우 디바이스 그룹의 특정 디바이스와 호환되는 다른 센서를 설정해야 합니다.

Paragon Insights 릴리스 4.0.0을 사용하면 센서 우선순위를 설정하여 벤더 이름, 운영 체제, 제품 이름, 플랫폼 및 릴리스 버전과 같은 규칙 속성의 각 계층에서 서로 다른 센서를 구성할 수 있습니다. 이를 통해 이기종 디바이스 그룹의 멀티벤더 디바이스에 적합한 센서를 적용할 수 있습니다. 릴리스 4.0.0에서는 Paragon Insights CLI를 통해서만 센서 우선 순위를 구성할 수 있습니다. 릴리스 4.2.0 Paragon Insights 룰에 대해 두 개 이상의 센서를 구성할 수 있습니다. 자세한 내용은 Paragon Insights 규칙 및 플레이북을 참조하십시오.

그림 1 은 각각 여러 센서가 있는 두 가지 규칙을 보여줍니다. 센서 우선 순위에 대해 규칙 속성이 구성된 것으로 가정합니다.

그림 1: 규칙 에서 센서 우선순위 표시

규칙 1의 Sensor1이 규칙 2의 OpenConfig 및 Sensor4가 iAgent이고 Device1이 Junos 운영체제(OS)를 실행한다고 가정해 보겠습니다. OpenConfig 및 iAgent가 규칙 속성의 Junos OS 계층 구조의 기본 센서로 설정된 경우, 디바이스1은 디바이스 그룹에 대한 플레이북이 구축될 때 Sensor1 및 Sensor4로부터 데이터를 받게 됩니다.

• 시작하기 전에
• 센서 우선 순위 구성