ADMINISTRATION PORTAL
Help Center User GuideGetting StartedFAQsRelease Notes
 
X
User Guide
Getting Started
FAQs
Release Notes

HealthBot Push-Model Ingest Methods

HealthBot currently supports the following push-model sensors:

Native GPB

Native sensors use a Juniper-proprietary data model using Google protocol buffers (GPB). The device pushes telemetry data (when configured) over UDP.

The device pushes data from the Packet Forwarding Engine, that is, directly from a line card. This means telemetry data is sent over the forwarding plane, so the collector must have in-band connectivity to the device.

To use native format, you configure the device with settings that include where to send the telemetry data. When you configure HealthBot to start collecting the data, the stream is already flowing towards the server.

For more information on native sensors, see Understanding the Junos Telemetry Interface Export Format of Collected Data.

NetFlow

Starting with Release 3.0.0, HealthBot supports NetFlow natively as another ingest method, using a data model that aligns with other HealthBot ingest mechanisms to provide all the same feature richness. With this release, HealthBot supports NetFlow v9 and NetFlow v10 (IPFIX).

How it Works

NetFlow is a network protocol for collecting IP traffic statistics, which can then be exported to a tool for analysis. NetFlow is available in different versions, the latest being NetFlow v9 and NetFlow v10. The NetFlow v9 data export format is described in RFC 3954; NetFlow v10 is officially known as IPFIX and standardized in RFC 7011.

Junos devices support flow monitoring and aggregation using these protocols; the Junos OS samples the traffic, builds a flow table, and sends the details of the flow table over a configured UDP port to a collector, in this case Healthbot. HealthBot receives the incoming Netflow data, auto-detects it as v9 or v10, and process it further.

As shown above, the network device pushes data from the Packet Forwarding Engine, that is, directly from a line card. This means flow data is sent over the forwarding plane, so the collector must have in-band connectivity to the device. To use the flow sensor option, you configure the device with settings that include where to send the flow data. When you configure HealthBot to start collecting the data, the flow data is already flowing towards the server.

NetFlow Templates

Where other ingest methods have established sensor formats and identification details - for example, native GPB references paths, SNMP references MIBs, etc. - flow has no equivalent mechanism. Instead, HealthBot uses templates. These flow templates provide a mechanism to identify and decode incoming flow data before sending it for further processing.

HealthBot provides predefined flow templates for NetFlow v9 and v10 (IPFIX), or you can define your own. The predefined templates match those which the Junos OS currently supports. For example, the Junos OS template, ipv4-template, aligns with the HealthBot template hb-ipfix-ipv4-template. To view the fields used in the Junos OS templates, see Understanding Inline Active Flow Monitoring.

Note In the current ingest implementation for NetFlow, the following field types are not supported:

  • Fields for enterprise specific elements

  • Variable length fields

NetFlow Ingest Processing

The raw flow data that HealthBot receives is in binary format and unreadable. In order to make this data usable, HealthBot processes the incoming flow data as follows:

Warning For NetFlow ingest, ensure that there is no source NAT in the network path(s) between the device and Healthbot. If the network path contains source NAT, then the device information received is not accurate.

NetFlow Configuration - Device Configuration

To use NetFlow as an ingest method in HealthBot, you must add configuration to the device you wish to monitor, to enable it to export flow data into HealthBot.

This example includes the Netflow v10 IPv4 template; adjust as needed for your environment. If not already done, complete device configuration to send NetFlow data to HealthBot as shown below.

## IPFIX template configuration

set services flow-monitoring version-ipfix template IPv4-TEMPLATE ipv4-template

## Apply IPFIX template to enable traffic sampling

set forwarding-options sampling instance IPFIX-IPv4-INSTANCE input rate 10
set forwarding-options sampling instance IPFIX-IPv4-INSTANCE family inet output flow-server 10.102.70.200 port 2055

## 10.102.70.200 = HealthBot server

## port 2055; use this value in HealthBot GUI (device group config)

set forwarding-options sampling instance IPFIX-IPv4-INSTANCE family inet output flow-server 10.102.70.200 version-ipfix template IPv4-TEMPLATE
set forwarding-options sampling instance IPFIX-IPv4-INSTANCE family inet output inline-jflow source-address 198.51.100.1

## inline-jflow = Enable inline flow monitoring for traffic from the designated address

## 198.51.100.1 = in-band interface doing the exporting; use this value in HealthBot GUI (device config)

## Associate sampling instance with the FPC

set chassis fpc 0 sampling-instance IPFIX-IPv4-INSTANCE

## Specify which interface traffic to sample

set interfaces ge-0/0/0 unit 0 family inet sampling input
set interfaces ge-0/0/0 unit 0 family inet sampling output

Add the Device In HealthBot

Procedure

Now add the device in HealthBot, specifying the IP address(es) that will send the flow data.

  1. In the HealthBot GUI, click Configuration > Device in the left-nav bar, and click the add device button (+ Device).
  2. Click the + (Add Device) button
  3. In the Add Device(s) window that appears, fill in the appropriate fields.

    Be sure to fill in the Flow IPs field with the IP address(es) from which NetFlow data will arrive.

  4. Click Save & Deploy.

For more information about adding a device, see Adding a Device in Manage Devices, Device Groups, and Network Groups.

Usage Notes:

Add Device Group

Procedure

With the device added, you now need to create a device group and define the flow ingest port for the device group.

  1. Click Configuration > Device Group
  2. Click the + (Add Device Group) button
  3. In the Add Device Group window that appears, fill in the fields as appropriate. In the Flow Ports field, enter the port(s) on which NetFlow data will arrive.

    Note If your HealthBot installation is a multi-node installation using Kubernetes, you must also specify which HealthBot nodes will receive the NetFlow traffic by filling in the Flow Deploy Nodes field in the Add/Edit Device Group window.

  4. Click Save & Deploy

    Usage Notes:

    • HealthBot will listen for NetFlow messages on this port for devices in this group.

    • The configured NetFlow ingest ports cannot be the same across device groups. You must configure a different port (or ports) for each group.

Define NetFlow Ingest Settings - Review Predefined Templates

Procedure

Flow templates provide a mechanism to identify and decode incoming flow data before sending it for further processing within HealthBot.

  1. Click Settings > Ingest Settings in the left-nav bar.
  2. Click the Netflow tab on the left side of the page.
  3. On the Netflow settings page, review the available templates for use in a rule.

Usage Notes:

Define NetFlow Ingest Settings - (Optional) Create Your Own NetFlow Template

Procedure

If the existing templates do not meet your needs, you can create your own template. You can also use custom templates to support other vendors’ devices.

  1. On the Netflow settings page, click the + Template button.
  2. In the Add Template window that appears, fill in the following fields (you can leave the other settings as is):
    • Template Name - give the template a name

    • NetFlow version - select v9 or v10

    • Priority - Available values are 1 through 10

    • Include Fields - add one or more fields that you want included in the template you wish to use

    • Exclude Fields - add one or more fields that you do not want included in the template you wish to use

    • Key Fields - specify which fields in the incoming messages should be treated as keys

  3. Click Save & Deploy

    You should now see the template added to the NetFlow settings page.

  4. (Optional) Repeat the steps above to create more templates.

Usage Notes:

Configure a Rule Using the Flow Sensor

Procedure

With the flow ingest settings complete, you can now create a rule using flow as the sensor.

This example rule includes three elements:

  • A flow sensor that uses the NetFlow v10 IPv4 template

  • Six fields capturing data of interest

  • A trigger that indicates when traffic flow is higher or lower than expected

Note See the usage notes at the end of this section for more detail on what has been configured.

  1. Click Configuration > Rules in the left-nav bar.
  2. On the Rules page, click the + Add Rule button.

    The Rules page refreshes to show a nearly empty rule on the right part of the page.

  3. In the top row of the rule window, leave the topic set as external and set the rule name that appears after the slash (/). In this example, it is periodic-aggregation-flow-rule.
  4. Add a description and synopsis if you wish.
  5. Click the + Add Sensor button and enter the following parameters in the Sensors tab:
  6. Now move to the Fields tab, click the + Add Field button and enter the following parameters to configure the first field, source-ipv4-address:
  7. Click the + Add Field button again and enter the following parameters to configure the second field, destination-ipv4-address:
  8. Click the + Add Field button again and enter the following parameters to configure the third field, sensor-traffic-count:
  9. Click the + Add Field button again and enter the following parameters to configure the fourth field, total-traffic-count:
  10. Click the + Add Field button again and enter the following parameters to configure the fifth field, traffic-count-maximum:
  11. Click the + Add Field button once more and enter the following parameters to configure the sixth field, traffic-count-minimum:
  12. As the last step for the fields configuration, set the field aggregation time-range value to 10s:
  13. Now move to the Variables tab, click the + ADD VARIABLE button and create the traffic-count-max and traffic-count-min variables that are the constants for the traffic-count-maximum and traffic-count-minimum fields, respectively.

    Note Only the definition for the traffic-count-max is shown graphically. Choose an appropriate Default Value when configuring both traffic-count-max and traffic-count-min variables. The value shown above is for testing purposes only and may not be appropriate for your network.

  14. Now move to the Triggers tab, click the + Add trigger button and enter the following parameters to configure a trigger called traffic-measurement-trigger:
  15. At the upper right of the window, click the Save & Deploy button.

Usage Notes:

Add the Rule to a Playbook

Procedure

With the rule created, you can now add it to a playbook. For this example, create a new playbook to hold the new rule.

  1. Click Configuration > Playbooks in the left-nav bar.
  2. On the Playbooks page, click the create + Create Playbook button.
  3. On the page that appears, enter the following parameters:
  4. Click Save & Deploy

Apply the Playbook to a Device Group

Procedure

  1. On the Playbooks page, click the Apply (Airplane) icon for the playbook you configured above.
  2. On the Run Playbook page that appears
    • Enter a name for the playbook instance.

    • Select the desired device group from the Apply Group pull-down menu.

    • Click Run Instance.

  3. On the Playbooks page, confirm that the playbook instance is running. Note that the playbook may take some time to activate.

Monitor the Devices

Procedure

With the playbook applied, you can begin to monitor the devices.

  1. Click Monitor > Device Group Health in the left-nav bar and select the device group to which you applied the playbook from the Device Group pull-down menu.
  2. Select one of more of the devices to monitor.
  3. In the Tile View, the external tile contains the parameters from the rule you configured earlier.

OpenConfig

This format utilizes the OpenConfig data model using gRPC. The network device acts as a gRPC server to terminate gRPC sessions from HealthBot, which runs as the client. RPC calls from HealthBot trigger the creation of sensors that either stream data periodically or report events, which are then funneled onto the appropriate gRPC channel as protobuf (GPB) messages.

In HealthBot releases prior to 3.1.0, OpenConfig could only be used on Junos OS and certain Cisco devices. This is because HealthBot has native support for the OpenConfig RPCs used by Juniper and Cisco, each of which uses its own proprietary encoding for OpenConfig data. Starting with release 3.1.0, HealthBot supports the gRPC Network Management Interface (gNMI) for OpenConfig communication. This protocol allows HealthBot to work with many third-party OpenConfig implementations in a vendor independent way.

With OpenConfig, the device receives sensor subscriptions from HealthBot and pushes telemetry data through any available interface, whether in-band or out-of-band.

Note that in the figure above, the out-of-band connection is shown as connecting to the fxp0 interface of a Junos device. If the device was from a third-party vendor, the out-of-band connection would be to the vendor-specific management port. Similarly, the in-band connection(s) would be to the vendor-specific interface designation.

OpenConfig RPC

To use OpenConfig format, you configure the device as a gRPC server. With HealthBot acting as the client, you define which sensors you want it to subscribe to, and it makes subscription requests towards the device.

Data streamed through gRPC is formatted in OpenConfig key/value pairs in protocol buffer (GPB) encoded messages. Keys are strings that correspond to the path of the system resources in the OpenConfig schema for the device being monitored; values correspond to integers or strings that identify the operational state of the system resource, such as interface counters. OpenConfig RPC messages can be transferred in bulk, such as providing multiple interface counters in one message, thereby increasing efficiency of the message transfer.

For more information on OpenConfig sensors, see Understanding OpenConfig and gRPC on Junos Telemetry Interface.

gNMI-Encoded OpenConfig RPC

gNMI-encoded OpenConfig works much like OpenConfig RPC in that you must set the network device up as an OpenConfig server to which HealthBot makes subscription requests. However, gNMI supports more subscription types than HealthBot currently supports. Currently, HealthBot only supports gNMI STREAM subscriptions in the SAMPLE mode. STREAM subscriptions are long-lived subscriptions that continue, indefinitely, to transmit updates relating to the set of paths configured within the subscription. SAMPLE mode STREAM subscriptions must include a sample_interval.

The messages returned to the client thorugh gNMI are encoded by the device in protobuf, JSON, or JSON-IETF format and cannot be sent in bulk. This, in part, makes gNMI-encoded messaging less efficient than gRPC-encoded messaging.

Warning 

  • For JSON or JSON-IETF, it is assumed that the device returns gNMI updates as only leaf values encoded in JSON, rather than returning an entire hierarchy or sub-hierarchy as a JSON object.

  • Numbers encoded in JSON or JSON-IETF are decoded by HealthBot as either float64, int64, or string, according to RFC 7159 and RFC 7951. If your OpenConfig rules contain fields that are of a different type, we recommend that you change the field types accordingly.

Junos OS and Cisco devices can be managed by HealthBot using gNMI-encoded OpenConfig. If a device does not support gNMI in general, or the STREAM subcription in SAMPLE mode, or does not support an OpenConfig request, it returns one of the following errors:

In the case of a Junos OS or Cisco device, the error causes the connection to fall back to OpenConfig RPC. In the case of a third-party device, the connection simply fails due to the error.

gNMI-encoded OpenConfig can be enabled at the device or device-group level. If enabled at the device-group level, then all devices added to the group use gNMI by default. If enabled (or not enabled) at the device level, then the device level setting takes precedence over the device-group level setting.

Note During the initial connection gNMI devices attempt to perform an initial sync with the client. The device sends a continuous stream of data until the device and the collector (HealthBot) are in sync. After initial sync, the device begins normal streaming operations based on the configured reporting rate. Because of the processing load this creates, HealthBot has this feature disabled by default. It can be enabled at the device-group or device level if needed.

For more information about gNMI, see: gRPC Network Management Interface (gNMI).

Syslog

In addition to the JTI-related options above, starting with Release 2.1.0, HealthBot also supports syslog natively as another data collection method, using a data model that aligns with other HealthBot ingest mechanisms to provide all the same feature richness.

A device can push syslog messages (when configured) over UDP to the HealthBot server either out-of-band through the Routing Engine (RE) using the router’s management interface, or in-band through the Packet Forwarding Engine, that is, directly from a line card.

To use syslog format, you configure the device with settings that include where to send the syslog messages. When you configure HealthBot to start collecting the data, messages are already flowing towards the server.

For more information on syslog as used by Juniper devices, see Junos OS System Log Overview.

Overview

Syslog ingest requires some setup before you can use it as a sensor in a rule:

To see how patterns and pattern sets are used, see Example: Creating a Rule Using Syslog Ingest.

System-Generated Fields

Some fields are common in syslog messages. HealthBot extracts these fields and includes them automatically in the raw table, enabling you to make use of them directly when creating a rule, and avoiding the need to configure patterns.

To illustrate use of these values, consider the following example syslog messages:

Structured - <30>1 2019-11-22T03:17:53.605-08:00 R1 mib2d 28633 SNMP_TRAP_LINK_DOWN [junos@2636.1.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

Equivalent unstructured - <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

System-generated fields:

Note Be sure not to define any new fields using a name already defined above.

Usage Notes

Optional Configuration Elements

Configure syslog ports

By default, HealthBot listens for syslog messages from all device groups on UDP port 514. You can change the system-level syslog port, and also configure one or more ports per device group. The more specific device group setting takes precedence over the system level setting.

Procedure

To change the system-level syslog port:

  1. Click Settings > Ingest Settings in the left-nav bar.
  2. Select the Syslog tab on the left side of the page.
  3. On the Syslog Settings page, edit the port number.
  4. Click Save & Deploy.

Procedure

To configure a syslog port for a device group:

  1. Go to the Configuration > Device Group page and click on the name of a device group.
  2. Click the Edit (Pencil) icon.
  3. In the pop-up window, enter the port(s) in the Syslog Ports field.
  4. Click Save & Deploy.

Configure time zone for a device

When a device exports structured syslog messages, time zone information is included within the message. However, unstructured syslog messages do not include time zone information. By default, HealthBot uses GMT as the time zone for a device. In these cases you can assign a time zone to a device or device group within HealthBot.

Procedure

To configure a device’s time zone at the device group level:

  1. Go to the Configuration > Device Group page and click on the name of a device group.
  2. Click the Edit (Pencil) icon.
  3. In the pop-up window, enter a value in the Timezone field, for example -05:00.

Procedure

To configure a device’s time zone at the device level:

  1. Go to the Configuration > Device page and click on the name of a device.
  2. Click the Edit (Pencil) icon.
  3. In the pop-up window, enter a value in the Timezone field, for example -05:00.

Note The more specific device setting takes precedence over the device group setting.

Configure multiple source IP addresses for a device

In cases where syslog messages arrive from a device using a different source IP address than the one originally configured in the HealthBot GUI, you can add additional source IP addresses.

Procedure

To support additional source IP addresses:

  1. Go to the Configuration > Device page and click on the name of a device.
  2. Click the Edit (Pencil) icon.
  3. In the pop-up window, enter the IP address(es) in the Syslog Source IPs field.

Configure host name aliases for a device

When a device has more than one host name, such as a device with dual REs, syslog messages can arrive at the HealthBot server with a host name that is not the device’s main host name. In these cases, you can add host name aliases for that device.

Note If you add a device in HealthBot using its IP address, you must also add the host name that will appear in the syslog messages.

Procedure

To configure additional hostname aliases:

  1. Go to the Configuration > Device page and click on the name of a device.
  2. Click the Edit (Pencil) icon.
  3. In the pop-up window, enter the host name(s) in the Syslog Host Names field.

Example: Creating a Rule Using Syslog Ingest

To illustrate how to configure and use a syslog sensor, consider a scenario where you want to:

To implement this scenario, you will need to complete the following activities:

The workflow is as follows:

CONFIGURE NETWORK DEVICES

Note This example assumes you have already added your devices into HealthBot and assigned them to a device group.

Add syslog configuration to the network device

If not already done, configure your network device(s) to send syslog data to Healthbot. For more details on configuring your Junos device, see the Network Device Requirements section of the HealthBot Installation Guide.

SET UP SYSLOG INGEST

Configure patterns

A pattern is a configuration to monitor some syslog event; you create a pattern for each event you want to monitor. This example uses patterns to monitor four syslog events (two structured and two unstructured).

Note See the usage notes at the end of this section for more detail on what has been configured.

Procedure

  1. In the HealthBot GUI, click Settings > Ingest in the left-nav bar.
  2. Select the Syslog tab on the left of the page.
  3. On the Syslog Settings page, click the + Add Pattern button.
  4. In the pop-up window that appears, enter the following parameters for the first pattern, named snmp-if-link-down:
  5. Click OK.
  6. Click the add pattern button (+ Add Pattern) once more and enter the following parameters for the second pattern, named fpc-offline:

    Note The full value entered in the Filter field is fpc%{NUMBER:fpc} Marking ports %{WORD:port-status}

  7. Click OK. On the Syslog Settings page you should see the two patterns you just created.
  8. At the upper right of the Syslog Settings window, click the save and deploy button (+ Save & Deploy).

Usage notes for the patterns

For structured syslog:

For unstructured syslog:

Regarding filters:

Add patterns to a pattern set

With the patterns configured, group them into a pattern set.

Procedure

  1. On the Syslog Settings page, scroll down and click the add pattern set button (+ Add Pattern Set).
  2. In the pop-up window that appears, enter the following parameters:
  3. Click OK. On the Syslog Settings page you should see the pattern set you just created.
  4. At the upper right of the window, click the save and deploy button (+ Save & Deploy).

CREATE RULE, APPLY PLAYBOOK

Configure a rule using the syslog sensor

With the syslog ingest settings complete, you can now create a rule using syslog as the sensor.

This rule includes three elements:

Note See the usage notes at the end of this section for more detail on what has been configured.

Procedure

  1. Click Configuration > Rules in the left-nav bar.
  2. On the Rules page, click the + Add Rule button.
  3. On the page that appears, in the top row of the rule window, set the rule name. In this example, it is check-interface-status.
  4. Add a description and synopsis if you wish.
  5. Click the + Add sensor button and enter the following parameters in the Sensors tab:
  6. Now move to the Fields tab, click the + Add field button, and enter the following parameters to configure the first field, named event-id:
  7. Click the + Add field button again and enter the following parameters to configure the second field, named fpc-slot:
  8. Click the + Add fieldbutton again and enter the following parameters to configure the third field, named if-name:
  9. Click the + Add field button once more and enter the following parameters to configure the fourth field, named snmp-index:
  10. Now move to the Triggers tab, click the + Add trigger button, and enter the following parameters to configure a trigger named link-down:
  11. At the upper right of the window, click the + Save & Deploybutton.

Usage Notes for the rule

Add the rule to a playbook

With the rule created, you can now add it to a playbook. For this example, create a new playbook to hold the new rule.

Procedure

  1. Click Configuration > Playbooks in the left-nav bar.
  2. On the Playbooks page, click the + Create Playbook button.
  3. On the page that appears, enter the following parameters:
  4. Click Save & Deploy.

Apply the playbook to a device group

To make use of the playbook, apply it to a device group.

Procedure

  1. On the Playbooks page, click the Apply (Airplane) icon for the check-interface-status playbook.
  2. On the page that appears:
    • Enter a name

    • Select the desired device group

    • Click Run Instance

  3. On the Playbooks page, confirm that the playbook instance is running. Note that the playbook may take some time to activate.

MONITOR

Monitor the devices

With the playbook applied, you can begin to monitor the devices.

Procedure

  1. Click Monitor > Device Group Health in the left-nav bar, and select the device group to which you applied the playbook from the Device Group pull-down menu.
  2. Select one of more of the devices to monitor.
  3. In the Tile View, the tile labeled external contains the parameters from the rule you configured earlier.

Note For this example, since the rule trigger does not include a ‘green’ term, the status will show red when there is an issue and otherwise will show gray (no data).

Help us to improve. Rate this article.
Feedback Received. Thank You!

Ask questions in TechWiki

Check documentation in TechLibrary

Rating by you:      
X

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:
Email:

Need product assistance? Contact Juniper Support

Submit