Page is loading ...
Paragon Insights User Guide
Published
2023-07-26
RELEASE
4.3.0
Juniper Networks, Inc.
1133 Innovaon Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. All other trademarks, service marks, registered marks, or registered service
marks are the property of their respecve owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right
to change, modify, transfer, or otherwise revise this publicaon without noce.
Paragon Insights User Guide
4.3.0
Copyright © 2023 Juniper Networks, Inc. All rights reserved.
The informaon in this document is current as of the date on the tle page.
YEAR 2000 NOTICE
Juniper Networks hardware and soware products are Year 2000 compliant. Junos OS has no known me-related
limitaons through the year 2038. However, the NTP applicaon is known to have some diculty in the year 2036.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentaon consists of (or is intended for use
with) Juniper Networks soware. Use of such soware is subject to the terms and condions of the End User License
Agreement ("EULA") posted at hps://support.juniper.net/support/eula/. By downloading, installing or using such
soware, you agree to the terms and condions of that EULA.
ii
Table of Contents
About This Guide | viii
1
Introducon to Paragon Insights
Paragon Insights Overview | 2
Paragon Insights Concepts | 6
Paragon Insights Data Collecon Methods | 7
Paragon Insights Topics | 9
Paragon Insights Rules - Basics | 10
Paragon Insights Rules - Deep Dive | 12
Paragon Insights Playbooks | 31
Paragon Insights Tagging | 33
Overview | 33
Types of Tagging | 40
Add a Tagging Prole | 48
Apply a Tagging Prole | 53
Delete a Tagging Prole | 55
Paragon Insights Time Series Database (TSDB) | 57
Paragon Insights Machine Learning (ML) | 65
Paragon Insights Machine Learning Overview | 65
Understanding Paragon Insights Anomaly Detecon | 66
Understanding Paragon Insights Outlier Detecon | 68
Understanding Paragon Insights Predict | 72
Paragon Insights Rule Examples | 73
Frequency Proles and Oset Time | 87
Frequency Proles | 87
iii
Oset Time Unit | 94
2
Paragon Insights Management and Monitoring
Manage Paragon Insights Users and Groups | 107
Manage Devices, Device Groups, and Network Groups | 121
Adding a Device | 122
Eding a Device | 129
Adding a Device Group | 129
Eding a Device Group | 136
Conguring a Retenon Policy for the Time Series Database | 136
Adding a Network Group | 137
Eding a Network Group | 140
Paragon Insights Rules and Playbooks | 141
Add a Pre-Dened Rule | 141
Create a New Rule Using the Paragon Insights GUI | 142
Edit a Rule | 159
Add a Pre-Dened Playbook | 159
Create a New Playbook Using the Paragon Insights GUI | 160
Edit a Playbook | 161
Clone a Playbook | 162
Manage Playbook Instances | 163
Monitor Device and Network Health | 172
Dashboard | 172
Health | 183
Network Health | 192
Graphs Page | 192
Understand Resources and Dependencies | 206
iv
About the Resources Page | 209
Add Resources for Root Cause Analysis | 212
Congure Dependency in Resources | 215
Example Conguraon: OSPF Resource and Dependency | 221
Edit Resources and Dependencies | 232
Edit a Resource | 232
Edit Resource Dependency | 233
Filter Resources | 234
Upload Resources | 235
Download Resources | 236
Clone Resources | 236
Delete Resources and Dependencies | 237
Delete a Resource | 238
Delete Resource Dependency | 239
Monitor Network Device Health Using Grafana | 239
Grafana Overview | 239
Access the Grafana UI | 240
Run a Query | 240
View Prepopulated Graphs | 242
Back Up and Restore Grafana Data | 243
Understanding Acon Engine Workows | 244
Manage Acon Engine Workows | 244
Alerts and Nocaons | 252
Generate Alert Nocaons | 252
Congure a Nocaon Prole | 253
Enable Alert Nocaons for a Device Group or Network Group | 259
v
Manage Alerts Using Alert Manager | 260
Viewing Alerts | 260
Manage Individual Alerts | 262
Congure Alert Blackouts | 263
Stream Sensor and Field Data from Paragon Insights | 264
Congure the Nocaon Type for Publishing | 264
Publish Data for a Device Group or Network Group | 267
Generate Reports | 268
Use Exim4 for E-Mails | 282
Congure the Exim4 Agent to Send E-mail | 283
Manage Audit Logs | 284
Filter Audit Logs | 284
Export Audit Logs | 285
Paragon Insights Commands and Audit Logs | 286
Congure a Secure Data Connecon for Paragon Insights Devices | 286
Congure Data Summarizaon | 290
Modify the UDA, UDF, and Workow Engines | 299
Commit or Roll Back Conguraon Changes in Paragon Insights | 307
Logs for Paragon Insights Services | 309
Troubleshoong | 312
Paragon Insights Conguraon – Backup and Restore | 321
Back Up the Conguraon | 322
Restore the Conguraon | 322
Backup or Restore the Time Series Database (TSDB) | 323
3
License Management
Paragon Insights Licensing Overview | 326
View, Add, or Delete Paragon Insights Licenses | 326
vi
About This Guide
Use this guide to understand the features you can congure and the tasks you can perform from the
Paragon Insights (formerly HealthBot) GUI.
viii
Paragon Insights Overview
IN THIS SECTION
Main Components of Paragon Insights | 2
Closed-Loop Automaon | 4
Benets of Paragon Insights | 6
Paragon Insights (formerly HealthBot) is a highly automated and programmable device-level diagnoscs
and network analycs tool that provides consistent and coherent operaonal intelligence across
network deployments. Paragon Insights integrates mulple data collecon methods (such as Junos
Telemetry Interface (JTI), NETCONF, syslog, and SNMP) to aggregate and correlate large volumes of
me-sensive telemetry data, thereby providing a muldimensional and predicve view of the network.
Addionally, Paragon Insights translates troubleshoong, maintenance, and real-me analycs into an
intuive user experience to give network operators aconable insights into the health of individual
devices and of the overall network.
Main Components of Paragon Insights
Paragon Insights consists of two main components:
• Health Monitoring, to view an abstracted, hierarchical representaon of device and network-level
health, and dene the health parameters of key network elements through customizable key
performance indicators (KPIs), rules, and playbooks. A playbook is a collecon of rules. You can
create a playbook and apply the playbook to a device group or a network group. For more
informaon on rules and playbooks, see "Paragon Insights Rules and Playbooks" on page 141.
• Root Cause Analysis, which helps you nd the root cause of a device or network-level issue when
Paragon Insights detects a problem with a network element.
Paragon Insights Health Monitoring
The Challenge
2
With increasing data trac generated by cloud-nave applicaons and emerging technologies, service
providers and enterprises need a network analycs soluon to analyze volumes of telemetry data, oer
insights into overall network health, and produce aconable intelligence. While although telemetry-
based techniques have existed for years, the growing number of protocols, data formats, and KPIs from
diverse networking devices has made data analysis complex and costly. Tradional CLI-based interfaces
require specialized skills to extract business value from telemetry data, creang a barrier to entry for
network analycs
How Paragon Insights Health Monitoring Helps
By aggregang and correlang raw telemetry data from mulple sources, the Paragon Insights Health
Monitoring component provides a muldimensional view of network health that reports current status,
as well as projected threats to the network infrastructure and its workloads.
Health status determinaon is ghtly integrated with the Paragon Insights RCA component, which can
make use of system log data received from the network and its devices. Paragon Insights Health
Monitoring provides status indicators that alert you when a network resource is currently operang
outside a user-dened performance policy. Paragon Insights Health Monitoring does a risk analysis using
historical trends and predicts whether a resource may be unhealthy in the future. Paragon Insights
Health Monitoring not only oers a fully customizable view of the current health of network elements,
but also automacally iniates remedial acons based on predened service level agreements (SLAs).
Dening the health of a network element, such as broadband network gateway (BNG), provider edge
(PE), core, and leaf-spine, is highly contextual. Each element plays a dierent role in a network, with
unique KPIs to monitor. Given that there is no single denion for network health across all use cases,
Paragon Insights provides a highly customizable framework to allow you to dene your own health
proles.
Paragon Insights Root Cause Analysis
The Challenge
For some network issues, it can be challenging for network operators to gure out what caused a
networking device to stop working properly. In such cases, an operator must call on a specialist (with
knowledge built from years of experience) to troubleshoot the problem and nd the root cause.
How Paragon Insights RCA Helps
The Paragon Insights RCA component simplies the process of nding the root cause of a network issue.
Paragon Insights’s RCA captures the troubleshoong knowledge of specialists and has a knowledge base
in the form of Paragon Insights rules. These rules are evaluated either on demand by a specic trigger or
periodically in the background to ascertain the health of a networking component, such as roung
protocol, system, interface, or chassis, on the device.
To illustrate the benets of Paragon Insights RCA, let us consider the problem of OSPF apping. Figure 1
on page 4 highlights the workow sequence involved in debugging OSPF apping. A network
3
operator troubleshoong this issue would need to perform manual debugging steps for each le (step)
of the workow sequence in order to nd the root cause of the OSPF apping. On the other hand,
theParagon Insights RCA applicaon troubleshoots the issue automacally by using an RCA bot. The
RCA bot tracks all of the telemetry data collected by the Paragon Insights and translates the informaon
into graphical status indicators (displayed in the Paragon Insights web GUI) that correlate to dierent
parts of the workow sequence shown in Figure 1 on page 4.
Figure 1: High-level workow to debug OSPF-apping
When you congure Paragon Insights, each le of the workow sequence (shown in Figure 1 on page 4)
can be dened by one or more rules. For example, the RPD-OSPF le could be dened as two rule
condions: one to check if "hello-transmied" counters are incremenng and the other to check if
"hello-received" counters are incremenng. Based on these user-dened rules, Paragon Insights provides
status indicators, alarm nocaons, and an alarm management tool to inform and alert you of specic
network condions that could lead to OSPF apping.
By isolang a problem area in the workow, Paragon Insights RCA proacvely guides you in determining
the appropriate correcve acon to take to x a pending issue or avoid a potenal one.
Closed-Loop Automaon
Paragon Insights oers closed-loop automaon. The automaon workow can be divided into seven
main steps (see Figure 2 on page 5):
1. Dene—The user denes the health parameters of key network elements through customizable key
performance indicators (KPIs), rules, and playbooks, by using the tools provided by Paragon Insights.
4
2. Collect—Paragon Insights collects rule-based telemetry data from mulple devices using the
collecon methods specied for the dierent network devices.
3. Store—Paragon Insights stores me-sensive telemetry data in a me-series database (TSDB). This
allows users to query, perform operaons on, and write new data back to the database, days, or even
weeks aer the inial storage.
4. Analyze—Paragon Insights analyzes telemetry data based on the specied KPIs, rules, and playbooks.
5. Visualize—Paragon Insights provides mulple ways for you to visualize the aggregated telemetry data
through its web-based GUI to gain aconable and predicve insights into the health of your devices
and the overall network.
6. Nofy—Paragon Insights noes you through the GUI and nocaon alarms when problems in
individual devices or in the network are detected.
7. Act Paragon Insights performs user-dened acons to help resolve and proacvely prevent
network problems.
Figure 2: Paragon Insights Closed-Loop Automaon Workow
5
Benets of Paragon Insights
•Customizaon—Provides a framework to dene and customize health proles, allowing truly
aconable insights for the specic device or network being monitored.
•Automaon—Automates root cause analysis and log le analysis, streamlines diagnosc workows,
and provides self-healing and remediaon capabilies.
• Greater network visibility—Provides advanced muldimensional analycs across network elements,
giving you a clearer understanding of network behavior to establish operaonal benchmarks, improve
resource planning, and minimize service downme.
•Intuive GUI—Oers an intuive web-based GUI for policy management and easy data consumpon.
• Open integraon—Lowers the barrier of entry for telemetry and analycs by providing open source
data pipelines, nocaon capabilies, and third-party device support.
•Mulple data collecon methods—Includes support for JTI, OpenCong, NETCONF, CLI, Syslog,
NetFlow, and SNMP.
RELATED DOCUMENTATION
Paragon Insights Geng Started Guide
Paragon Insights Concepts
IN THIS SECTION
Paragon Insights Data Collecon Methods | 7
Paragon Insights Topics | 9
Paragon Insights Rules - Basics | 10
Paragon Insights Rules - Deep Dive | 12
Paragon Insights Playbooks | 31
6
Paragon Insights (formerly HealthBot) is a highly programmable telemetry-based analycs applicaon.
With it, you can diagnose and root cause network issues, detect network anomalies, predict potenal
network issues, and create real-me remedies for any issues that come up.
To accomplish this, network devices and Paragon Insights have to be congured to send and receive
large amounts of data, respecvely. Device conguraon is covered throughout this and other secons
of the guide.
Conguring Paragon Insights, or any applicaon, to read and react to incoming telemetry data requires a
language that describes several elements that are specic to the systems and data under analysis. This
type of language is called a Domain Specic Language (DSL), i.e., a language that is specic to one
domain. Any DSL is built to help answer quesons. For Paragon Insights, these quesons are:
• Q: What components make up the systems that are sending data?
A: Network devices are made up of memory, cpu, interfaces, protocols and so on. In Paragon Insights,
these are called "Paragon Insights Topics" on page 9.
• Q: How do we gather, lter, process, and analyze all of this incoming telemetry data?
A: Paragon Insights uses "Paragon Insights Rules - Basics" on page 10 that consist of informaon
blocks called sensors, elds, variables, triggers, and more.
• Q: How do we determine what to look for?
A: It depends on the problem you want to solve or the queson you want to answer. Paragon
Insights uses "Paragon Insights Playbooks" on page 31 to create collecons of specic rules and
apply them to specic groups of devices in order accomplish specic goals. For example, part of the
system-kpis-playbook can alert a user when system memory usage crosses a user-dened threshold.
This secon covers these key concepts and more, which you need to understand before using Paragon
Insights.
Paragon Insights Data Collecon Methods
IN THIS SECTION
Data Collecon - ’Push’ Model | 8
Data Collecon - ’Pull’ Model | 8
7
In order to provide visibility into the state of your network devices, Paragon Insights rst needs to
collect their telemetry data and other status informaon. It does this using sensors.
Paragon Insights supports sensors that “push” data from the device to Paragon Insights and sensors that
require Paragon Insights to “pull” data from the device using periodic polling.
Data Collecon - ’Push’ Model
As the number of objects in the network, and the metrics they generate, have grown, gathering
operaonal stascs for monitoring the health of a network has become an ever-increasing challenge.
Tradional ’pull’ data-gathering models, like SNMP and the CLI, require addional processing to
periodically poll the network element, and can directly limit scaling.
The ’push’ model overcomes these limits by delivering data asynchronously, which eliminates polling.
With this model, the Paragon Insights server can make a single request to a network device to stream
periodic updates. As a result, the ’push’ model is highly scalable and can support the monitoring of
thousands of objects in a network. Junos devices support this model in the form of the Junos Telemetry
Interface (JTI).
Paragon Insights currently supports ve ‘push’ ingest types.
•Nave GPB
• NetFlow
• sFlow
•OpenCong
• Syslog
These push-model data collecon—or
ingest
—methods are explained in detail in the Paragon Insights
Data Ingest Guide.
Data Collecon - ’Pull’ Model
While the ’push’ model is the preferred approach for its eciency and scalability, there are sll cases
where the ’pull’ data collecon model is appropriate. With the ’pull’ model, Paragon Insights requests
data from network devices at periodic intervals.
Paragon Insights currently supports two ‘pull’ ingest types.
• iAgent (CLI/NETCONF)
• SNMP
8
These pull-model data collecon—or
ingest
—methods are explained in detail in the Paragon Insights
Data Ingest Guide.
Paragon Insights Topics
Network devices are made up of a number of components and systems from CPUs and memory to
interfaces and protocol stacks and more. In Paragon Insights, a topic is the construct used to address
those dierent device components. The Topic block is used to create name spaces that dene what
needs to be modeled. Each Topic block is made up of one or more Rule blocks which, in turn, consist of
the Field blocks, Funcon blocks, Trigger blocks, etc. See "Paragon Insights Rules - Deep Dive" on page
12 for details. Each rule created in Paragon Insights must be part of a topic. Juniper has curated a
number of these system components into a list of Topics such as:
• chassis
• class-of-service
• external
•rewall
• interfaces
• kernel
• linecard
• logical-systems
• protocol
•roung-opons
• security
• service
• system
You can create sub-topics underneath any of the Juniper topic names by appending
.<sub-topic>
to the
topic name. For example, kernel.tcpip or system.cpu.
Any pre-dened rules provided by Juniper t within one of the Juniper topics with the excepon of
external
, The
external
topic is reserved for user-created rules. In the Paragon Insights web GUI, when
you create a new rule, the Topics eld is automacally populated with the
external
topic name.
9
Paragon Insights Rules - Basics
Paragon Insights’ primary funcon is collecng and reacng to telemetry data from network devices.
Dening how to collect the data, and how to react to it, is the role of a
rule
.
Paragon Insights ships with a set of default rules, which can be seen on the Conguraon > Rules page
of the Paragon Insights GUI, as well as in GitHub in the healthbot-rules repository. You can also create
your own rules.
The structure of a Paragon Insights rule looks like this:
To keep rules organized, Paragon Insights organizes them into
topics
. Topics can be very general, like
system, or they can be more granular, like protocol.bgp. Each topic contains one or more rules.
As described above, a
rule
contains all the details and instrucons to dene how to collect and handle
the data. Each rule contains the following required elements:
• The
sensor
denes the parameters for collecng the data. This typically includes which data
collecon method to use (as discussed above in "Paragon Insights Data Collecon Methods" on page
7), some guidance on which data to ingest, and how oen to push or pull the data. In any given rule,
a sensor can be dened directly within the rule or it can be referenced from another rule.
• Example: Using the SNMP sensor, poll the network device every 60 seconds to collect all the
device data in the Juniper SNMP MIB table jnxOperangTable.
• The sensor typically ingests a large set of data, so
elds
provide a way to lter or manipulate that
data, allowing you to idenfy and isolate the specic pieces of informaon you care about. Fields can
also act as placeholder values, like a stac threshold value, to help the system perform data analysis.
10
• Example: Extract, isolate, and store the jnxOperang15MinLoadAvg (CPU 15-minute average
ulizaon) value from the SNMP table specied above in the sensor.
•
Triggers
periodically bring together the elds with other elements to compare data and determine
current device status. A trigger includes one or more ’when-then’ statements, which include the
parameters that dene how device status is visualized on the health pages.
• Example: Every 90 seconds, check the CPU 15min average ulizaon value, and if it goes above a
dened threshold, set the device’s status to red on the device health page and display a message
showing the current value.
The rule can also contain the following oponal elements:
•
Vectors
allow you to leverage exisng elements to avoid the need to repeatedly congure the same
elements across mulple rules.
• Examples: A rule with a congured sensor, plus a vector to a second sensor from another rule; a
rule with no sensors, and vectors to elds from other rules
•
Variables
can be used to provide addional supporng parameters needed by the required elements
above.
• Examples: The string “ge-0/0/0”, used within a eld collecng status for all interfaces, to lter the
data down to just the one interface; an integer, such as “80”, referenced in a eld to use as a stac
threshold value
•
Funcons
allow you to provide instrucons (in the form of a Python script) on how to further interact
with data, and how to react to certain events.
• Examples: A rule that monitors input and output packet counts, using a funcon to compare the
count values; a rule that monitors system storage, invoking a funcon to cleanup temp and log
les if storage ulizaon goes above a dened threshold
NOTE: Rules, on their own, don’t actually do anything. To make use of rules you need to add
them to "Paragon Insights Playbooks" on page 31.
11
Paragon Insights Rules - Deep Dive
IN THIS SECTION
Rules | 13
Sensors | 16
Fields | 16
Vectors | 18
Variables | 19
Funcons | 19
Triggers | 20
Tagging | 24
Rule Properes | 24
Pre/Post Acon | 24
Mulple Sensors per Device | 25
Sensor Precedence | 28
A rule is a package of components, or blocks, needed to extract specic informaon from the network
or from a Junos device. Rules conform to a specically tailored domain specic language (DSL) for
analycs applicaons. The DSL is designed to allow rules to capture:
• The minimum set of input data that the rule needs to be able to operate
• The minimum set of telemetry sensors that need to be congured on the device(s)
• The elds of interest from the congured sensors
• The reporng or polling frequency
• The set of triggers that operate on the collected data
• The condions or evaluaons needed for triggers to kick in
• The acons or nocaons that need to be performed when a trigger kicks in
The details around rules, topics and playbooks are presented in the following secons.
12
/