Juniper Paragon Active Assurance (formerly Netrounds) Developer Guide

Type
Developer Guide

This manual is also suitable for

REST API Orchestraon Guide
Published
2023-11-28
RELEASE
4.3
Table of Contents
Introducon
Orchestraon with Paragon Acve Assurance
Supported Paragon Acve Assurance Features
Geng Started with the REST API
Test and Monitor Templates
Examples of Controlling Paragon Acve Assurance via REST API
Examples: Test Agents
Examples: Inventory Items
Examples: Alarms
Examples: SSH Keys
Examples: Monitors
Examples: Tests
Tags
Troubleshoong
ii
Introducon
IN THIS SECTION
Convenons | 1
In recent years, REST (REpresentaonal State Transfer) has emerged as the standard architectural design
for web services and web APIs.
This documentaon describes how to integrate Paragon Acve Assurance with a network service
orchestrator via the Paragon Acve Assurance REST API. This is a RESTful API that adheres to the
standardized OpenAPI/Swagger 2.0 denion format, thereby enabling easy and ecient orchestraon
of Paragon Acve Assurance tasks.
(As explained here: "OpenAPI Specicaon (formerly Swagger Specicaon) is an API descripon format
for REST APIs. An OpenAPI le allows you to describe your enre API, including: available endpoints (/
users) and operaons on each endpoint (GET /users, POST /users); operaon parameters Input and
output for each operaon; authencaon methods; and contact informaon, license, terms of use and
other informaon.")
Hands-on examples are given of the principal tasks involved, including:
creang and deploying Virtual Test Agents
running tests and monitors
retrieving results from these acvies.
Orchestraon through the REST API (that is, using the "write" funcons of the API) is available only with
on-premise installaons of Paragon Acve Assurance where the REST API has been installed.
Orchestraon is not available to users of the Paragon Acve Assurance SaaS soluon. However, SaaS
users do have access to the data retrieval (that is, "read") funcons of the REST API.
Convenons
The following abbreviaons are used in this document:
1
Abbreviaon Meaning
ES Errored Second
MEP MEG (Maintenance Enty Group) End Point
(ITU-T Y.1731 denion)
or Maintenance End Point
(Cisco denion)
NFV Network Funcon Virtualizaon
NFVO Network Funcon Virtualizaon Orchestrator
REST REpresentaonal State Transfer
SLA Service Level Agreement
VNF Virtual Network Funcon
vTA Virtual Test Agent
Orchestraon with Paragon Acve Assurance
IN THIS SECTION
Overview | 2
Denions of Paragon Acve Assurance Concepts | 4
Work Flow for Automaon | 4
Overview
A third-party NFVO or service orchestrator is typically the component which iniates test and
monitoring sessions using the Control Center API. This orchestrator also retrieves the aggregated
measurement results from the Test Agent acvies. Performance KPIs may be retrieved by third-party
2
Performance Management Systems, while events – once triggered by threshold violaons set in the
Control Center – can be sent to third-party Fault Management systems.
To summarize, the gure below shows how Paragon Acve Assurance interacts with other third-party
systems in the OSS landscape.
NFVO/Service Orchestrator: Instructs the VNF Manager to deploy the vTAs and congure Paragon
Acve Assurance into the service chain. Once the service has been acvated, the orchestrator uses
the API towards Control Center to trigger service acvaon tests and retrieve pass/fail results. If the
tests pass, the orchestrator will use the API towards Control Center to start acve monitoring of the
service. KPIs from the monitoring are retrieved connuously either by the orchestrator or by a
separate Performance Management plaorm.
Control Center (G-VNF Manager): Deploys, scales, and terminates the vTA as instructed by the NFVO
or service orchestrator.
Performance Management system or Service Quality Management system: Reads KPIs from acve
monitoring via the Control Center API.
Fault Management system: Receives NETCONF, SNMP, or email nocaons from Control Center if
SLAs are violated.
3
Denions of Paragon Acve Assurance Concepts
Test Agents: The components that perform measurements (for tests as well as monitors) in a Paragon
Acve Assurance system. Test Agents consist of soware with the ability to generate, receive, and
analyze real network trac.
The kind of Test Agent discussed in this document is the
Virtual Test Agent (vTA)
, a virtual
network funcon (VNF) deployed on a hypervisor. Other types of Test Agent also exist.
Measurement types:
There are two basic types of measurement in Paragon Acve Assurance,
tests
and
monitors
.
Test: A test consists of one or several
steps
, each of which has a
specied
,
nite duraon
. Steps
are executed sequenally. Each step may entail running mulple
tasks
concurrently.
Monitor: A monitor does not have a specied duraon but executes
indenitely
. Like a step in a
test, a monitor may execute mulple concurrent tasks.
Template: When Paragon Acve Assurance is controlled by an orchestrator, tests and monitors are
always executed by means of templates in which the test or monitor is dened. Parameter sengs
can be passed as inputs to the template at runme.
Work Flow for Automaon
Design Time
At design me, you prepare measurements by creang templates for tests and monitors in Paragon
Acve Assurance. How to do that is covered in the chapter "Test and Monitor Templates" on page 28.
Runme
At runme, you set up your devices and perform the actual measurements.
An overview of all examples given is found in the chapter "Examples of Controlling Paragon Acve
Assurance via REST API" on page 29.
How to deploy and congure Test Agents is gone through in the chapter "Examples: Test Agents" on
page 30.
How to congure inventory items is gone through in the chapter "Examples: Inventory Items" on
page 48:
TWAMP reectors
4
Y.1731 MEPs
IPTV channels
SIP accounts
How to congure alarms is covered in the chapter "Examples: Alarms" on page 54.
How to run tests and monitors by execung Paragon Acve Assurance templates through the REST
API is described in the chapters "Examples: Tests" on page 75 and "Examples: Monitors" on page
62.
There is also the possibility of pushing SSH keys to Test Agents to enable logging in to the Test Agents
via SSH. The details are covered in the chapter "Examples: SSH Keys" on page 60.
Supported Paragon Acve Assurance Features
IN THIS SECTION
Product Features Available in the REST API | 5
All test and monitor types in Paragon Acve Assurance can be created and executed from the REST API
through the use of templates. How to set up test and monitor templates is explained in the in-app help
under "Tests and monitors" > "Creang templates".
Creaon of Paragon Acve Assurance accounts is currently not supported; however, one or several
predened accounts will have been set up for the user.
The tables that follow detail what product features are available in this release.
For full details on syntax, refer to https://<Control Center host IP>/rest.
Product Features Available in the REST API
Each REST API operaon consists of an HTTP method (for example, GET, PUT, PATCH, POST, or
DELETE) applied to a URL with a specied syntax. Each operaon is therefore represented below as
follows:
5
HTTP method Path
where the omied inial part of the URL is {protocol}://{Control Center host IP}/rest.
All operaons are performed on the Paragon Acve Assurance account given in the URL.
Paginaon
Many of the API resources in the REST API are used to list mulple items. These resources all share the
same mechanism for paginang the returned results by specifying the query parameters:
limit: Seng this to
n
means that at most
n
elements will be returned. By default, this limit is set to
10 elements.
offset: Seng this to
n
means that elements will be returned starng at posion
n
in the list. By
default, there is no oset.
The result is returned in the following format:
{
"items":
{
...
},
"offset": 0,
"limit": 10,
"count": 123
}
Here, items contains the returned result items, while count denotes the total number of items available in
the list.
The resources are listed in the subsecons that follow.
Resource: Alarms
Acon Path
GET /accounts/{account}/alarms/
6
Retrieve a list of all alarms with their full denions. For each alarm, an acve cong is returned; this is
what is used to actually trigger an alarm. It consists of parameters from an alarm template overridden by
values from an alarm cong.
Acon Path
PUT /accounts/{account}/alarms/{alarm_id}/
Suppress an alarm with a given ID so that it will never trigger.
Acon Path
GET /accounts/{account}/alarms/{alarm_id}/
Retrieve the full denion of an alarm with a given ID. An acve cong is returned for the alarm; this is
what is used to actually trigger it. The cong consists of parameters from an alarm template overridden
by values from an alarm cong.
Acon Path
DELETE /accounts/{account}/alarms/{alarm_id}/
Delete an alarm with a given ID.
Resource: Alarm Email Lists
Acon Path
PUT /accounts/{account}/alarm_emails/{alarm_emails_id}/
Modify the conguraon of an alarm email list with a given ID.
Acon Path
GET /accounts/{account}/alarm_emails/{alarm_emails_id}/
Retrieve an alarm email list with a given ID.
7
Acon Path
DELETE /accounts/{account}/alarm_emails/{alarm_emails_id}/
Delete an alarm email list with a given ID.
Acon Path
POST /accounts/{account}/alarm_emails/
Create a new alarm email list.
Acon Path
GET /accounts/{account}/alarm_emails/
Retrieve a list of all alarm email lists.
Resource: Alarm Templates
Acon Path
PUT /accounts/{account}/alarm_templates/{alarm_template_id}/
Modify the conguraon of an alarm template with a given ID.
Acon Path
GET /accounts/{account}/alarm_templates/{alarm_template_id}/
Retrieve the full denion of an alarm template with a given ID.
Acon Path
DELETE /accounts/{account}/alarm_templates/{alarm_template_id}/
8
Delete an alarm template with a given ID.
Acon Path
POST /accounts/{account}/alarm_templates/
Create a new alarm template.
Acon Path
GET /accounts/{account}/alarm_templates/
Retrieve a list of all alarm templates.
Resource: External URL Share
External URL shares consist of test or monitor results shared externally by means of a URL.
Acon Path
PUT /accounts/{account}/external_url_shares/{share_id}/
Modify the conguraon of an external URL share with a given ID.
Acon Path
GET /accounts/{account}/external_url_shares/{share_id}/
Retrieve the conguraon of an external URL share with a given ID.
Acon Path
DELETE /accounts/{account}/external_url_shares/{share_id}/
Delete an external URL share with a given ID.
9
Acon Path
POST /accounts/{account}/external_url_shares/
Create a new external URL share.
Acon Path
GET /accounts/{account}/external_url_shares/
Retrieve a list of all external URL shares.
Resource: IPTV Channels
Acon Path
PUT /accounts/{account}/iptv_channels/{iptv_id}/
Modify the conguraon of an IPTV channel with a given ID.
Acon Path
GET /accounts/{account}/iptv_channels/{iptv_id}/
Retrieve the conguraon of an IPTV channel with a given ID.
Acon Path
DELETE /accounts/{account}/iptv_channels/{iptv_id}/
Delete an IPTV channel with a given ID.
Acon Path
POST /accounts/{account}/iptv_channels/
10
Create a new IPTV channel.
Acon Path
GET /accounts/{account}/iptv_channels/
Retrieve a list of all IPTV channels.
Resource: Monitors
Acon Path
GET /accounts/{account}/monitors/{monitor_id}/pdf_report
Generate a PDF report on a monitor with a given ID.
Acon Path
POST /accounts/{account}/monitors/
Create a new monitor based on a monitor template.
Acon Path
GET /accounts/{account}/monitors/
Retrieve a list of all dened monitors as well as data on SLA fulllment during their execuon. SLA
fulllment is by default indicated for the last 15 minutes; a dierent me period can be specied with
the query string parameters start and end.
Acon Path
PUT /accounts/{account}/monitors/{monitor_id}/
Start or stop a monitor with a given ID. This is done by seng the started parameter to True or False.
This operaon can also be used to change the monitor name or descripon, or to modify any parameter
in its cong.
11
Acon Path
PATCH /accounts/{account}/monitors/{monitor_id}/
Start or stop a monitor with a given ID. This is done by seng the started parameter to True or False.
PATCH can also be used to change the monitor name or descripon.
NOTE: PATCH cannot be used to edit other monitor parameters; PUT needs to be used instead.
Acon Path
GET /accounts/{account}/monitors/{monitor_id}/
Retrieve the full denion of a monitor with a given ID, as well as data on SLA fulllment during its
execuon and comprehensive data metrics for successive me intervals (the length of these intervals is
governed by the resolution parameter). SLA fulllment is by default indicated for the last 15 minutes; a
dierent me period can be specied with the query string parameters start and end. – Periodic tests are
run as part of a monitor. If a task has a task_type value of periodic, the results list will always be empty.
Instead, an executions list is provided containing a list of test IDs for each run of the tests. Here the actual
results are found.
Acon Path
DELETE /accounts/{account}/monitors/{monitor_id}/
Delete a monitor with a given ID.
Resource: Monitor Templates
Acon Path
GET /accounts/{account}/monitor_templates/
Retrieve a list of all monitor templates.
12
Acon Path
POST /accounts/{account}/monitor_templates/import/
Import previously exported monitor templates.
Acon Path
GET /accounts/{account}/monitor_templates/{template_id}/
Retrieve the full denion of a monitor template with a given ID.
Acon Path
GET /accounts/{account}/monitor_templates/export/
Export all monitor templates.
Creaon of monitor templates must be done through the Control Center web GUI; for details of this
procedure, see the in-app help under "Tests and monitors" > "Creang templates".
Resource: SIP Accounts
Acon Path
POST /accounts/{account}/sip_accounts/
Create a new SIP account.
Acon Path
GET /accounts/{account}/sip_accounts/
Retrieve a list of all SIP accounts.
13
Acon Path
PUT /accounts/{account}/sip_accounts/{sip_id}/
Modify the conguraon of a SIP account with a given ID.
Acon Path
GET /accounts/{account}/sip_accounts/{sip_id}/
Retrieve the conguraon of a SIP account with a given ID.
Acon Path
DELETE /accounts/{account}/sip_accounts/{sip_id}/
Delete a SIP account with a given ID.
Resource: SNMP Managers
Acon Path
PUT /accounts/{account}/snmp_managers/{snmp_manager_id}/
Modify the conguraon of an SNMP manager with a given ID.
Acon Path
GET /accounts/{account}/snmp_managers/{snmp_manager_id}/
Retrieve an SNMP manager with a given ID.
Acon Path
DELETE /accounts/{account}/snmp_managers/{snmp_manager_id}/
14
Delete an SNMP manager with a given ID.
Acon Path
POST /accounts/{account}/snmp_managers/
Create a new SNMP manager.
Acon Path
PUT /accounts/{account}/snmp_managers/
Retrieve a list of all SNMP managers.
Resource: Speedtest
Acon Path
GET /accounts/{account}/speedtest/results/
Retrieve a list of all Speedtest results.
Acon Path
GET /accounts/{account}/speedtest/results/{speedtest_id}
Returns a Speedtest result for a given instance ID.
NOTE: The Speedtest commands are not intended to be used directly, but rather by a custom
web page set up for Speedtest. See the document
Creang a Custom Speedtest Web Page
.
15
Resource: SSH Keys
Acon Path
PUT /accounts/{account}/ssh_keys/{ssh_key_id}/
Modify the conguraon of an SSH key with a given ID.
Acon Path
GET /accounts/{account}/ssh_keys/{ssh_key_id}/
Retrieve an SSH key with a given ID.
Acon Path
DELETE /accounts/{account}/ssh_keys/{ssh_key_id}/
Delete an SSH key with a given ID.
Acon Path
POST /accounts/{account}/ssh_keys/
Add a new SSH key.
Acon Path
GET /accounts/{account}/ssh_keys/
Retrieve a list of all SSH keys.
16
Resource: Tags
Acon Path
POST /accounts/{account}/tags/
Create a new tag.
Acon Path
GET /accounts/{account}/tags/
Retrieve a list of all tags.
Acon Path
PUT /accounts/{account}/tags/{tag_id}/
Modify a tag with a given ID.
Acon Path
GET /accounts/{account}/tags/{tag_id}/
Retrieve the tag and all items (monitors, templates, Test Agents, TWAMP reectors) it has been applied
to.
Acon Path
DELETE /accounts/{account}/tags/{tag_id}/
Delete a tag with a given ID.
Acon Path
POST /accounts/{account}/tags/assign/
17
Assign a tag to specied resources.
Acon Path
POST /accounts/{account}/tags/unassign/
Unassign a tag from specied resources.
Resource: Test Agents
Acon Path
POST /accounts/{account}/test_agents/reboot/
Trigger a reboot on target Test Agents. The target Test Agents can be provided by either specifying their
IDs in a list or using the “?all” query parameter.
Acon Path
POST /accounts/{account}/test_agents/
Create a new virtual Test Agent.
Acon Path
GET /accounts/{account}/test_agents/
Retrieve a list of all Test Agents.
Acon Path
POST /accounts/{account}/test_agents/update/
Reboot and update Test Agents. This acon can be run in two ways: for all Test Agents, by appending
the ?all query string in the URL; or for specied Test Agents, listed by ID in the body as described in the
schema.
18
  • Page 1 1
  • Page 2 2
  • Page 3 3
  • Page 4 4
  • Page 5 5
  • Page 6 6
  • Page 7 7
  • Page 8 8
  • Page 9 9
  • Page 10 10
  • Page 11 11
  • Page 12 12
  • Page 13 13
  • Page 14 14
  • Page 15 15
  • Page 16 16
  • Page 17 17
  • Page 18 18
  • Page 19 19
  • Page 20 20
  • Page 21 21
  • Page 22 22
  • Page 23 23
  • Page 24 24
  • Page 25 25
  • Page 26 26
  • Page 27 27
  • Page 28 28
  • Page 29 29
  • Page 30 30
  • Page 31 31
  • Page 32 32
  • Page 33 33
  • Page 34 34
  • Page 35 35
  • Page 36 36
  • Page 37 37
  • Page 38 38
  • Page 39 39
  • Page 40 40
  • Page 41 41
  • Page 42 42
  • Page 43 43
  • Page 44 44
  • Page 45 45
  • Page 46 46
  • Page 47 47
  • Page 48 48
  • Page 49 49
  • Page 50 50
  • Page 51 51
  • Page 52 52
  • Page 53 53
  • Page 54 54
  • Page 55 55
  • Page 56 56
  • Page 57 57
  • Page 58 58
  • Page 59 59
  • Page 60 60
  • Page 61 61
  • Page 62 62
  • Page 63 63
  • Page 64 64
  • Page 65 65
  • Page 66 66
  • Page 67 67
  • Page 68 68
  • Page 69 69
  • Page 70 70
  • Page 71 71
  • Page 72 72
  • Page 73 73
  • Page 74 74
  • Page 75 75
  • Page 76 76
  • Page 77 77
  • Page 78 78
  • Page 79 79
  • Page 80 80
  • Page 81 81
  • Page 82 82
  • Page 83 83
  • Page 84 84
  • Page 85 85
  • Page 86 86
  • Page 87 87
  • Page 88 88
  • Page 89 89
  • Page 90 90
  • Page 91 91
  • Page 92 92
  • Page 93 93
  • Page 94 94
  • Page 95 95
  • Page 96 96
  • Page 97 97

Juniper Paragon Active Assurance (formerly Netrounds) Developer Guide

Type
Developer Guide
This manual is also suitable for

Ask a question and I''ll find the answer in the document

Finding information in a document is now easier with AI