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 主题 进行寻址。通常，设备规则使用设备上的传感器。

跨多个设备的规则称为网络规则。网络规则：

• 必须配置规则频率

• 不得包含传感器

• 不能与剧本中的设备规则混合使用

若要部署任一类型的规则，请将规则包含在 playbook 中，然后将该 playbook 应用于设备组或网络组。

并非组成规则的所有块都是每个规则所必需的。规则定义中是否需要特定块取决于您尝试访问的信息类型。此外，某些规则组件对网络规则无效。 表 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 更详细地描述了四种字段引入类型。

向量

向量 有助于将多个元素收集到单个规则中。例如，使用向量可以收集所有接口错误字段。矢量的语法为：

$field-n 可以是类型引用的字段。

定义向量时使用的字段可以是对其他规则中定义的字段的直接引用：

此语法允许通过构造的 <field-name>=<field-value> 部分进行选择性筛选。向量还可以采用从提供的时间范围中选择值的时间范围选项。当在给定时间范围内返回多个值时，它们都被选为一个数组。

向量支持以下预定义公式：

• unique @vector1–返回来自 vector1 的唯一元素集

• @vector1 and @vector2–返回向量 1 和向量 2 中唯一元素的交集。

• @vector1 or @vector2–返回两个向量中唯一元素的总数。

• @vector1 unless @vector2–返回向量 1 中的唯一元素集，但不返回向量 2 中的唯一元素集

变量

变量是在规则创建期间在 “变量 ”页面上定义的。变量定义的这一部分创建默认值，如果在部署期间设备组中或设备上未设置特定值，则使用该默认值。例如，规则 check-interface-status 有一个名为 的变量 interface_name。 变量页面上 设置的值是正则表达式 （regex）， .*表示所有接口。

如果按原样应用，则该 check-interface-status 规则将提供有关设备组中所有设备上所有接口的接口状态信息。应用包含此规则的 playbook 时，可以在设备组或设备级别替代默认值。这使您可以灵活地应用规则。优先顺序是设备值覆盖设备组值，设备组值覆盖规则中设置的默认值。

功能

函数是在创建规则期间在“函数”选项卡上定义的。在此处定义函数允许在与字段关联的公式以及触发器的“时间”和“然后”部分中使用它。触发器的 when 子句中使用的函数称为用户定义函数。这些必须返回 true 或 false。触发器的 then 子句中使用的函数称为用户定义操作。

触发器

触发器在 Paragon Insights 规则定义中起着举足轻重的作用。它们是规则的一部分，用于确定是否以及何时根据可用传感器数据的变化采取任何操作。触发器是以何时-这个，然后-那个的方式构造的。如前所述，触发操作基于 条款。 术语 是使用 when 子句构建的，这些子句监视字段值的更新， 然后 是根据更改的内容启动某些操作的子句。可以在单个触发器中创建多个 项 。

对条款中 when 子句的评估从术语列表的顶部开始，一直到底部。如果评估了某个术语但未进行匹配，则评估下一个术语。默认情况下，评估以这种方式进行，直到进行匹配或到达列表底部而没有匹配。

可在 when 子句中使用的预定义运算符包括：

• 大于 – 用于检查一个值是否大于另一个值。

  • 返回：真或假

  • 语法：大于 <LHS> <RHS> [时间范围<范围>]

  • 例子： //Memory > 3000 MB in the last 5 minutes

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

• 大于或等于 – 与大于相同，但检查 大于 或等于 （>=）

• 小于

  • 返回：真或假

  • 语法：小于 <LHS> <RHS> [时间范围<范围>]

  • 例子： //Memory < 6000 MB in the last 5 minutes

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

• 小于或等于 – 与小于相同，但检查 小于 或等于 （<=）

• 等于 – 用于检查一个值是否等于另一个值。

  • 返回：真或假

  • 语法：等于 <LHS> <RHS> [时间范围<范围>]

  • 例子： //Queue’s buffer utilization % == 0 

    when equal-to $buffer-utilization 0;

• 不等于 – 与 等于 相同，但检查负条件 （！=）

• exists – 用于检查某个值是否存在，而不关心值本身。这意味着应该从设备发送一些值。

  • 返回：真或假

  • 语法：存在<$var> [时间范围<范围>]

  • 例子： //Has the device configuration changed? 

    when exists $netconf-data-change

• matches-with（用于字符串和正则表达式）–用于使用 Python 正则表达式操作检查字符串上的匹配项。有关详细信息 ，请参阅语法 。

  注意：

  LHS，或左侧，是我们正在搜索的字符串;RHS 或右侧是匹配表达式。正则表达式只能在 RHS 中使用。

  • 返回：真或假

  • 语法：匹配 <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（对于字符串和正则表达式）–与 matches-with 相同，但检查负面条件

• 范围 - 检查值 X 是否在给定范围内，例如最小值和最大值（最小值 <= X <= 最大值）

  • 返回：真或假

  • 语法：范围 <$var> 分钟<最小值><最大值最大值> [时间范围<范围>]

  • 例子： //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;

• 按最小值递增 – 用于检查与前一个值相比，值是否至少增加了可接受的最小速率。可以提供定义可接受的最小增长率的可选参数。如果未指定，则可接受的最小增长率默认为 1。

  • 返回：真或假

  • 语法：

    按最小值递增<$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。

  • 返回：真或假

  • 语法：

    按值递增<$var> [增量<连续点之间增加的最大值>]

    按值递增 <$var> [增量<连续点之间增加的最大值>] 时间范围<范围>

  • 例子： 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;

• 按最小速率递增 – 用于检查连续值之间的增长率是否至少为给定速率。必需参数包括值和时间单位，它们共同表示可接受的最小增长率。

  • 返回：真或假

  • 语法：

    此语法将当前值与以前的值进行比较，确保它至少按值率增加。

    最小递增速率<$var>值<连续点之间增加的最小值>每<秒|分钟|小时|天|周|月|年> [时间范围<范围>]

    此语法将当前值与以前的值进行比较，确保它至少按百分比增加

    按最小速率递增 <$var> 百分比 <百分比> <秒|分钟|小时|天|周|月|年> [时间范围<范围>]

  • 例子： 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 子句中指定的操作。默认情况下，术语的处理此时停止。您可以通过启用 Then 子句底部的“评估下一个术语”按钮来更改此流程。这会导致 Paragon Insights 继续术语处理，以创建更复杂的决策功能，例如何时进行这个和这个，然后那个。

以下是可在 “然后” 部分使用的预定义操作的列表：

• 下

• 地位

标记

从版本 3.1.0 开始，HealthBot 支持标记。通过标记，您可以在满足特定条件时将字段、值和键插入 Paragon Insights 规则中。有关详细信息，请参阅 Paragon Insights 标记 。

规则属性

规则属性块允许您指定 Paragon Insights 规则的元数据，例如硬件依赖关系、软件依赖关系和版本历史记录。这些数据可用于提供信息或验证设备是否与 Paragon Insights 规则兼容。

行动前/行动后

（可选）从 Paragon Insights 4.3.0 版开始，您可以使用规则中的操作前和操作后选项卡来自动执行操作引擎工作流程中预先配置的任务。操作引擎工作流用于执行可作为命令行命令、NETCONF 命令或可执行文件中的命令执行的任务。有关更多信息 ，请参阅了解操作引擎工作流 。

在设备组上运行 playbook 实例时，Paragon Insights 会在 playbook 实例化开始时执行操作前任务。操作前任务可用于执行设备组中的设备配置或向其他应用程序发出有关设备状态的通知。多个操作前任务之间以及操作前任务和规则的执行之间不存在依赖关系。如果您在一个规则中配置多个操作前任务，Paragon Insights 会同时执行所有操作前任务。

Paragon Insights 会在您停止 playbook 实例时执行操作后任务。即使为可选配置，操作后任务也可用于删除通过操作前任务添加到设备的任何其他配置。

操作前和操作后任务都具有执行一次选项。默认情况下，执行一次处于禁用状态。如果启用执行一次，则 Paragon Insights 只会在设备组中的设备上执行一次任务。执行一次适用于以下情况：

• 在同一设备组上运行剧本的多个实例时。

• 在不同的 playbook 中包含包含一组操作前或操作后任务的规则，并在同一设备组上运行 playbook 实例时。

Paragon Insights 会先检查并解决操作前和操作后任务的重复问题，然后再在设备组中的设备上执行这些任务。当您在剧本中包含的许多规则中配置特定的操作前或操作后任务时，会发生重复。

要在规则中配置操作前任务和操作后任务，请参阅 Paragon Insights 规则和操作指南。

每个设备多个传感器

Paragon Insights 4.0.0 版允许您为每个规则添加多个传感器，这些传感器可应用于设备组中的所有设备。在早期版本中，每个规则只能添加一个传感器。每个规则的每个传感器都会在字段表中生成数据。如果在多个规则中添加了不同的传感器，则生成的字段表数与规则数一样多。在 Paragon Insights 的单个规则中添加多种类型的传感器（例如 OpenConfig 或本机 GPB）时，来自传感器的数据将合并到一个字段表中，该表更易于导出或可视化。对多个传感器配置的 GUI 支持将在后续版本中实现。

• 指引
• 在 Paragon Insights GUI 中配置多个传感器
• 用例

传感器优先级

若要使从传感器收集数据有效，设备组中的设备必须支持将特定传感器作为引入方法。选择运行旧版本操作系统的设备组中的设备、设备组中不同供应商的设备或同一供应商的不同产品（如瞻博网络的 EX、MX 和 PTX 路由器）都是可能导致将传感器应用于设备组的挑战的方案。在这种情况下，您需要设置与设备组中特定设备兼容的其他传感器。

Paragon Insights 4.0.0 版允许您设置传感器优先级，以便在规则属性的每个层次结构中配置不同的传感器，例如供应商名称、操作系统、产品名称、平台和发布版本。这样就可以在异构设备组中的多供应商设备上应用合适的传感器。在 4.0.0 版中，只能通过 Paragon Insights CLI 配置传感器优先级。从 Paragon Insights 4.2.0 版开始，您可以为一个规则配置多个传感器。有关更多信息，请参阅 Paragon Insights 规则和剧本。

图 1 说明了两个规则，每个规则具有多个传感器。假定规则属性配置为传感器优先级。

图 1：规则 中传感器优先级的表示形式

假设规则 1 中的传感器 1 是 OpenConfig，规则 2 中的传感器 4 是 iAgent，设备 1 运行 Junos 操作系统 （OS）。如果在规则属性中将 OpenConfig 和 iAgent 设置为Junos OS 层次结构的默认传感器，则在为设备组部署 Playbook 时，设备 1 将从传感器 1 和传感器 4 接收数据。

• 开始之前
• 传感器优先级配置