26-Telemetry Configuration Guide

HomeSupportConfigure & DeployConfiguration GuidesH3C MSR1000[2600][3600] Routers Configuration Guides(V9)-R9119-6W10026-Telemetry Configuration Guide
01-gRPC configuration
Title Size Download
01-gRPC configuration 194.85 KB

Configuring gRPC

About gRPC

gRPC is an open source remote procedure call (RPC) system initially developed at Google. It uses HTTP 2.0 and provides network device configuration and management methods that support multiple programming languages.

gRPC protocol stack layers

Table 1 describes the gRPC protocol stack layers.

Table 1 gRPC protocol stack layers

Layer

Description

Content layer

Defines the data of the service module.

Two peers must notify each other of the data models that they are using.

Protocol buffer encoding layer

Encodes data by using the protocol buffer code format.

gRPC layer

Defines the protocol interaction format for remote procedure calls.

HTTP 2.0 layer

Carries gRPC.

TCP layer

Provides connection-oriented reliable data links.

 

Network architecture

As shown in Figure 1, the gRPC network uses the client/server model. It uses HTTP 2.0 for packet transport.

Figure 1 gRPC network architecture

 

The gRPC network uses the following mechanism:

1.     The gRPC server listens to connection requests from clients at the gRPC service port.

2.     A user runs the gRPC client application to log in to the gRPC server, and uses methods provided in the .proto file to send requests.

3.     The gRPC server responds to requests from the gRPC client.

The device can act as the gRPC server or client.

Telemetry technology based on gRPC

Telemetry is a remote data collection technology for monitoring device performance and operating status. H3C telemetry technology uses gRPC to push data from the device to the collectors on the NMSs. As shown in Figure 2, after a gRPC connection is established between the device and NMSs, the NMSs can subscribe to data of modules on the device.

Figure 2 Telemetry technology based on gRPC

 

Telemetry modes

The device supports the following telemetry modes:

·     Dial-in mode—The device acts as a gRPC server and the collectors act as gRPC clients. A collector initiates a gRPC connection to the device to subscribe to device data.

·     Dial-out mode—The device acts as a gRPC client and the collectors act as gRPC servers. The device initiates a gRPC connection to the collectors and pushes subscribed device data to the collectors.

Protocols

RFC 7540, Hypertext Transfer Protocol version 2 (HTTP/2)

Restrictions: Hardware compatibility with gRPC

Hardware

gRPC compatibility

MSR 810, MSR 810-W, MSR 810-W-DB, MSR 810-LM, MSR 810-W-LM, MSR 810-10-PoE, MSR 810-LM-HK, MSR 810-W-LM-HK, MSR810-LM-CNDE-SJK, MSR810-CNDE-SJK

Yes

MSR 810-LMS, MSR 810-LUS

No

MSR810-LMS-EA, MSR810-LME

No

MSR1004S-5G

Yes

MSR 2600-6-X1, MSR 2600-10-X1, MSR2600-15-X1

Yes

MSR 2630

Yes

MSR 3600-28, MSR 3600-51

Yes

MSR 3600-28-SI, MSR 3600-51-SI

No

MSR 3600-28-X1, MSR 3600-28-X1-DP, MSR 3600-51-X1, MSR 3600-51-X1-DP

Yes

MSR 3610-I-DP, MSR 3610-IE-DP, MSR3610-IE-ES, MSR3610-IE-EAD, MSR-EAD-AK770, MSR3610-I-IG, MSR3610-IE-IG

Yes

MSR 3610-X1, MSR 3610-X1-DP, MSR 3610-X1-DC, MSR 3610-X1-DP-DC, MSR3620-X1, MSR3640-X1

Yes

MSR 3610, MSR 3620, MSR 3620-DP, MSR 3640, MSR 3660

Yes

MSR 3610-G, MSR 3620-G

Yes

Hardware

gRPC compatibility

MSR810-W-WiNet, MSR810-LM-WiNet

Yes

MSR830-4LM-WiNet

Yes

MSR830-5BEI-WiNet, MSR830-6EI-WiNet, MSR830-10BEI-WiNet

Yes

MSR830-6BHI-WiNet, MSR830-10BHI-WiNet

Yes

MSR2600-6-WiNet , MSR2600-10-X1-WiNet

Yes

MSR2630-WiNet

Yes

MSR3600-28-WiNet

Yes

MSR3610-X1-WiNet

Yes

MSR3610-WiNet, MSR3620-10-WiNet, MSR3620-DP-WiNet, MSR3620-WiNet, MSR3660-WiNet

Yes

Hardware

gRPC compatibility

MSR2630-XS

Yes

MSR3600-28-XS

Yes

MSR3610-XS

Yes

MSR3620-XS

Yes

MSR3610-I-XS

Yes

MSR3610-IE-XS

Yes

MSR3620-X1-XS

Yes

MSR3640-XS

Yes

Hardware

gRPC compatibility

MSR810-LM-GL

Yes

MSR810-W-LM-GL

Yes

MSR830-6EI-GL

Yes

MSR830-10EI-GL

Yes

MSR830-6HI-GL

Yes

MSR830-10HI-GL

Yes

MSR1004S-5G-GL

Yes

MSR2600-6-X1-GL

Yes

MSR3600-28-SI-GL

No

FIPS compliance

The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features, commands, and parameters might differ in FIPS mode and non-FIPS mode. For more information about FIPS mode, see Security Configuration Guide.

gRPC is not supported in FIPS mode.

Restrictions and guidelines: gRPC configuration

Disabling the gRPC service deletes all gRPC settings.

Configuring the gRPC dial-in mode

gRPC dial-in mode configuration tasks at a glance

To configure the gRPC dial-in mode, perform the following tasks:

1.     (Optional.) Specifying the PKI domain for SSL communication with collectors

2.     Configuring the gRPC service

3.     Configuring a gRPC user

4.     (Optional.) Enabling gRPC logging in dial-in mode

Specifying the PKI domain for SSL communication with collectors

About this task

To implement SSL communication with collectors, you must specify a PKI domain. For more information about PKI domain configuration, see PKI configuration in Security Configuration Guide.

Procedure

1.     Enter system view.

system-view

2.     Specify the PKI domain for SSL communication with collectors.

grpc pki domain domain-name

By default, no PKI domain is specified for SSL communication with collectors.

Configuring the gRPC service

1.     Enter system view.

system-view

2.     Enable the gRPC service.

grpc enable

By default, the gRPC service is disabled.

3.     (Optional.) Set the gRPC service port number.

grpc port port-number

By default, the gRPC service port number is 50051.

Changing the gRPC service port number reboots the gRPC service and terminates all gRPC sessions to the gRPC server.

4.     (Optional.) Set the gRPC session idle timeout timer.

grpc idle-timeout minutes

By default, the gRPC session idle timeout timer is 5 minutes.

Configuring a gRPC user

About this task

For gRPC clients to establish gRPC sessions with the device, you must configure local users for the gRPC clients on the device.

Procedure

1.     Enter system view.

system-view

2.     Add a local user with the device management right.

local-user user-name [ class manage ]

3.     Configure a password for the user.

password [ { hash | simple } password ]

By default, no password is configured for a local user. A non-password-protected user can pass authentication after providing the correct username and passing attribute checks.

4.     Assign user role network-admin to the user.

authorization-attribute user-role user-role

By default, a local user is assigned the network-operator role.

5.     Authorize the user to use the HTTPS service.

service-type https

By default, no service types are authorized to a local user.

For more information about the local-user, password, authorization-attribute, and service-type commands, see AAA configuration in Security Command Reference.

Enabling gRPC logging in dial-in mode

About this task

To identify gRPC issues, enable gRPC operations logging in dial-in mode.

This feature generates gRPC operation logs in dial-in mode and sends them to the information center.

With the information center, you can configure log destinations and output rules. For more information about the information center, see Network Management and Monitoring Configuration Guide.

Restrictions and guidelines

gRPC operation logging might degrade device performance if gRPC operations are frequent. As a best practice, use gRPC operation logging only when necessary and log only gRPC operations of interest if gRPC operation logging is enabled.

Procedure

1.     Enter system view.

system-view

2.     Enable gRPC logging for RPC operations in dial-in mode.

grpc log dial-in rpc { all | { cli | get }* }

By default, gRPC logging is disabled for RPC operations in dial-in mode.

Configuring the gRPC dial-out mode

gRPC dial-out mode configuration tasks at a glance

To configure telemetry, perform the following tasks:

1.     (Optional.) Specifying the PKI domain for SSL communication with collectors

2.     Enabling the gRPC service

3.     Configuring sensors

4.     Configuring collectors

5.     Configuring a subscription

6.     (Optional.) Enabling gRPC logging in dial-out mode

Specifying the PKI domain for SSL communication with collectors

About this task

To implement SSL communication with collectors, you must specify a PKI domain. For more information about PKI domain configuration, see PKI configuration in Security Configuration Guide.

Procedure

1.     Enter system view.

system-view

2.     Specify the PKI domain for SSL communication with collectors.

grpc pki domain domain-name

By default, no PKI domain is specified for SSL communication with collectors.

Enabling the gRPC service

1.     Enter system view.

system-view

2.     Enable the gRPC service.

grpc enable

By default, the gRPC service is disabled.

Configuring sensors

About this task

The device uses sensors to sample data. A sensor path indicates a data source.

Supported data collection types include:

·     Event-triggered collection—Sensors in a sensor group sample data when certain events occur. For sensor paths of this data collection type, see NETCONF XML API Event Reference for the module.

·     Periodic collection—Sensors in a sensor group sample data at intervals. For sensor paths of this data collection type, see the NETCONF XML API references for the module except for NETCONF XML API Event Reference.

Procedure

1.     Enter system view.

system-view

2.     Enter telemetry view.

telemetry

3.     Create a sensor group and enter sensor group view.

sensor-group group-name

4.     Specify a sensor path.

sensor path path [ condition node node operator operator value value ]

To specify multiple sensor paths or data push conditions, execute this command multiple times. A sensor path can have a maximum of five data push conditions. The device pushes data of a sensor path to collectors only when all relevant conditions are met.

Configuring collectors

About this task

Collectors are used to receive sampled data from network devices. For the device to communicate with collectors, you must create a destination group and add collectors to the destination group.

Restrictions and guidelines

As a best practice, configure a maximum of five destination groups. If you configure too many destination groups, system performance might degrade.

Prerequisites

To configure a collector that resides in a VPN instance, configure the VPN instance first. For more information about VPN instance configuration, see MPLS L3VPN configuration in MPLS Configuration Guide.

Procedure

1.     Enter system view.

system-view

2.     Enter telemetry view.

telemetry

3.     Create a destination group and enter destination group view.

destination-group group-name

4.     Specify a collector.

IPv4:

ipv4-address ipv4-address [ port port-number ] [ vpn-instance vpn-instance-name ]

IPv6:

ipv6-address ipv6-address [ port port-number ] [ vpn-instance vpn-instance-name ]

The IPv6 address of a collector cannot be an IPv6 link-local address. For more information about IPv6 link-local addresses, see IPv6 basics configuration in Layer 3—IP Services Configuration Guide.

To specify multiple collectors, execute this command multiple times. One collector must have a different address, port, or VPN instance than the other collectors.

Configuring a subscription

About this task

A subscription binds sensor groups to destination groups. Then, the device pushes data from the specified sensors to the collectors.

Procedure

1.     Enter system view.

system-view

2.     Enter telemetry view.

telemetry

3.     Create a subscription and enter subscription view.

subscription subscription-name

4.     (Optional.) Specify the source IP address for packets sent to collectors.

source-address { ipv4-address | interface interface-type interface-number | ipv6 ipv6-address }

By default, the device uses the primary IPv4 address of the output interface for the route to the collectors as the source address.

Changing the source address causes the device to reconnect to the gRPC server.

5.     (Optional.) Set the DSCP value of packets sent to collectors.

dscp dscp-value

By default, the DSCP value for packets sent to collectors is 0.

A greater DSCP value represents a higher priority.

6.     Specify a sensor group.

sensor-group group-name [ sample-interval [ msec ] interval ]

Specify the sample-interval interval option for periodic sensor paths and only for periodic sensor paths.

¡     If you specify the option for event-triggered sensor paths, the sensor paths do not take effect.

¡     If you do not specify the option for periodic sensor paths, the device does not sample or push data.

7.     Specify a destination group.

destination-group group-name

Enabling gRPC logging in dial-out mode

About this task

To identify gRPC issues, enable gRPC data collection logging in dial-out mode.

This feature generates gRPC data collection logs in dial-out mode and sends them to the information center.

With the information center, you can configure log destinations and output rules. For more information about the information center, see Network Management and Monitoring Configuration Guide.

Procedure

1.     Enter system view.

system-view

2.     Enable gRPC logging in dial-out mode.

grpc log dial-out { all | { event | sample }* }

By default, gRPC logging is disabled in dial-out mode.

Display and maintenance commands for gRPC

Execute display commands in any view.

 

Task

Command

Display gRPC information.

display grpc

 

gRPC configuration examples

These configuration examples describe only CLI configuration tasks on the device. The collectors need to run an extra application. For information about collector-side application development, see "Developing the collector-side application."

Example: Configuring the gRPC dial-in mode

Network configuration

As shown in Figure 3, configure the gRPC dial-in mode on the device so the device acts as the gRPC server and the gRPC client can subscribe to LLDP events on the device.

Figure 3 Network diagram

 

Procedure

1.     Assign IP addresses to interfaces on the gRPC server and client and configure routes. Make sure the server and client can reach each other.

2.     Configure the device as the gRPC server:

# Enable the gRPC service.

<Device> system-view

[Device] grpc enable

# Create a local user named test. Set the password of the user, and assign the network-admin user role and HTTPS service to the user.

[Device] local-user test

[Device-luser-manage-test] password simple 123456TESTplat&!

[Device-luser-manage-test] authorization-attribute user-role network-admin

[Device-luser-manage-test] service-type https

[Device-luser-manage-test] quit

3.     Configure the gRPC client.

a.     Prepare a PC and install the gRPC environment on the PC. For more information, see the user guide for the gRPC environment.

b.     Obtain the H3C proto definition file and uses the protocol buffer compiler to generate code of a specific language, for example, Java, Python, C/C++, or Go.

c.     Create a client application to call the generated code.

d.     Start the application to log in to the gRPC server.

Verifying the configuration

When an LLDP event occurs on the gRPC server, verify that the gRPC client receives the event.

Example: Configuring the gRPC dial-out mode

Network configuration

As shown in Figure 4, the device is connected to a collector. The collector uses port 50050.

Configure gRPC dial-out mode on the device so the device pushes the device capability information of its interface module to the collector at 10-second intervals.

Figure 4 Network diagram

 

Procedure

# Configure IP addresses as required so the device and the collector can reach each other. (Details not shown.)

# Enable the gRPC service.

<Device> system-view

[Device] grpc enable

# Create a sensor group named test, and add sensor path ifmgr/devicecapabilities/.

[Device] telemetry

[Device-telemetry] sensor-group test

[Device-telemetry-sensor-group-test] sensor path ifmgr/devicecapabilities/

[Device-telemetry-sensor-group-test] quit

# Create a destination group named collector1. Specify a collector that uses IPv4 address 192.168.2.1 and port number 50050.

[Device-telemetry] destination-group collector1

[Device-telemetry-destination-group-collector1] ipv4-address 192.168.2.1 port 50050

[Device-telemetry-destination-group-collector1] quit

# Configure a subscription named A to bind sensor group test with destination group collector1. Set the data collection interval to 10 seconds.

[Device-telemetry] subscription A

[Device-telemetry-subscription-A] sensor-group test sample-interval 10

[Device-telemetry-subscription-A] destination-group collector1

[Device-telemetry-subscription-A] quit

Verifying the configuration

# Verify that the collector receives the device capability information of the interface module from the device at 10-second intervals. (Details not shown.)

 


Protocol buffer code

Protocol buffer code format

Google Protocol Buffers provide a flexible mechanism for serializing structured data. Different from XML code and JSON code, the protocol buffer code is binary and provides higher performance.

Table 2 compares a protocol buffer code format example and the corresponding JSON code format example.

Table 2 Protocol buffer and JSON code format examples

Protocol buffer code format example

Corresponding JSON code format example

{

1:“H3C”

2:“H3C”

3:“H3C device_test”

4:“Syslog/LogBuffer”

5:"notification": {

"Syslog": {

"LogBuffer": {

"BufferSize": 512,

"BufferSizeLimit": 1024,

"DroppedLogsCount": 0,

"LogsCount": 100,

"LogsCountPerSeverity": {

"Alert": 0,

"Critical": 1,

"Debug": 0,

"Emergency": 0,

"Error": 3,

"Informational": 80,

"Notice": 15,

"Warning": 1

},

"OverwrittenLogsCount": 0,

"State": "enable"

}

},

"Timestamp": "1527206160022"

}

}

{

"producerName": "H3C",

"deviceName": "H3C",

"deviceModel": "H3C device_test",

"sensorPath": "Syslog/LogBuffer",

"jsonData": {

"notification": {

"Syslog": {

"LogBuffer": {

"BufferSize": 512,

"BufferSizeLimit": 1024,

"DroppedLogsCount": 0,

"LogsCount": 100,

"LogsCountPerSeverity": {

"Alert": 0,

"Critical": 1,

"Debug": 0,

"Emergency": 0,

"Error": 3,

"Informational": 80,

"Notice": 15,

"Warning": 1

},

"OverwrittenLogsCount": 0,

"State": "enable"

}

},

"Timestamp": "1527206160022"

}

}

}

 

Proto definition files

You can define data structures in a proto definition file. Then, you can compile the file with utility protoc to generate code in a programing language such as Java and C++. Using the generated code, you can develop an application for a collector to communicate with the device.

H3C provides proto definition files for both dial-in mode and dial-out mode.

Proto definition files in dial-in mode

Public proto definition files

The grpc_service.proto file defines the public RPC methods in dial-in mode, for example, login method and logout method.

The following are the contents of the grpc_service.proto file:

syntax = "proto2";

package grpc_service;

message GetJsonReply { // Reply to the Get method

    required string result = 1;

}

message SubscribeReply { // Subscription result

    required string result = 1;

}

message ConfigReply {   // Configuration result

    required string result = 1;

}

message ReportEvent {   // Subscribed event

    required string token_id = 1;   // Login token_id

    required string stream_name = 2; // Event stream name

    required string event_name = 3;     // Event name

    required string json_text = 4;  // Subscription result, a JSON string

}

message GetReportRequest{ // Obtains the event subscription result

    required string token_id = 1; // Returns the token_id upon a successful login

}

message LoginRequest {  // Login request parameters

    required string user_name = 1; // Username

    required string password = 2; // Password

}

message LoginReply {  // Reply to a login request

    required string token_id = 1; // Returns the token_id upon a successful login

}

message LogoutRequest { // Logout parameter

    required string token_id = 1; // token_id

}

message LogoutReply { // Reply to a logout request

    required string result = 1; // Logout result

}

message SubscribeRequest { // Event stream name

    required string stream_name = 1;

}

service GrpcService {   // gRPC methods

    rpc Login (LoginRequest) returns (LoginReply) {}    // Login method

    rpc Logout (LogoutRequest) returns (LogoutReply) {}     // Logout method

    rpc SubscribeByStreamName (SubscribeRequest) returns (SubscribeReply) {} // Event subscription method

    rpc GetEventReport (GetReportRequest) returns (stream ReportEvent) {} // Method for obtaining the subscribed event

}

Proto definition files for service modules

The dial-in mode supports proto definition files for the following service modules: Device, Ifmgr, IPFW, LLDP, and Syslog.

The following are the contents of the Device.proto file, which defines the RPC methods for the Device module:

syntax = "proto2";

import "grpc_service.proto";

package  device;

message DeviceBase { // Structure for obtaining basic device information

    optional string HostName = 1;   // Device name

    optional string HostOid = 2;    // sysoid

    optional uint32 MaxChassisNum = 3; //Maximum number of chassis

    optional uint32 MaxSlotNum = 4;     // Maximum number of slots

    optional string HostDescription = 5; // Device description

}

message DevicePhysicalEntities {    // Structure for obtaining physical entity information of the device

    message Entity {

        optional uint32 PhysicalIndex = 1; // Entity index

        optional string VendorType = 2;         // Vendor type

        optional uint32 EntityClass = 3;        // Entity class

        optional string SoftwareRev = 4;        // Software version

        optional string SerialNumber = 5;   // Serial number

        optional string Model = 6;          // Model

    }

    repeated Entity entity = 1;

}

service DeviceService { // RPC methods

    rpc GetJsonDeviceBase(DeviceBase) returns (grpc_service.GetJsonReply) {} // Method for obtaining basic device information

    rpc GetJsonDevicePhysicalEntities(DevicePhysicalEntities) returns (grpc_service.GetJsonReply) {}    // Method for obtaining physical entity information of the device

}

Proto definition file in dial-out mode

The grpc_dialout.proto file defines the public RPC methods in dial-out mode. The following are the contents of the file:

syntax = "proto2";

package grpc_dialout;

message DeviceInfo{     // Pushed device information

    required string producerName = 1; // Vendor name

    required string deviceName = 2;      // Device name

    required string deviceModel = 3;  // Device model

}

message DialoutMsg{   // Format of the pushed data

    required DeviceInfo deviceMsg = 1; // Device information described by DeviceInfo

    required string sensorPath = 2; // Sensor path, which corresponds to xpath in NETCONF

    required string jsonData = 3;  // Sampled data, a JSON string

}

message DialoutResponse{  // Response from the collector. Reserved. The value is not processed.

    required string response = 1;

}

service GRPCDialout {  // Data push method

    rpc Dialout(stream DialoutMsg) returns (DialoutResponse);

}

Obtaining proto definition files

Contact the technical support.

Example: Developing a gRPC collector-side application

Use a language (for example, C++) to develop a gRPC collector-side application on Linux to enable a collector to collect device data.

Prerequisites

1.     Obtain H3C proto definition files.

¡     For dial-in mode, obtain the grpc_service.proto file and proto definition files for service modules.

¡     For dial-out mode, obtain the grpc_dialout.proto file.

2.     Obtain utility protoc from https://github.com/google/protobuf/releases.

3.     Obtain the protobuf plug-in for C++ (protobuf-cpp) from https://github.com/google/protobuf/releases.

Generating the C++ code for the proto definition files

Dial-in mode

# Copy the required proto definition files to the current directory, for example, grpc_service.proto and BufferMonitor.proto.

$protoc --plugin=./grpc_cpp_plugin  --grpc_out=. --cpp_out=. *.proto

Dial-out mode

# Copy proto definition file grpc_dialout.proto to the current directory.

$ protoc --plugin=./grpc_cpp_plugin  --grpc_out=.  --cpp_out=. *.proto

Developing the collector-side application

Dial-in mode

In dial-in mode, the application needs to provide the code to be run on the gRPC client.

The C++ code generated from the proto definition files already encapsulates the service classes, which are GrpcService and BufferMonitorService in this example. For the gRPC client to initiate RPC requests, you only need to call the RPC method in the application.

The application performs the following operations:

·     Log in to obtain the token_id.

·     Prepare parameters for the RPC method, use the service classes generated from the proto definition files to call the RPC method, and resolve the returned result.

·     Log out.

To develop the collector-side application in dial-in mode:

1.     Create a GrpcServiceTest class.

# In the class, use the GrpcService::Stub class generated from grpc_service.proto. Implement login and logout with the Login and Logout methods generated from grpc_service.proto.

class GrpcServiceTest

{

public:

    /* Constructor functions */

   GrpcServiceTest(std::shared_ptr<Channel> channel): GrpcServiceStub(GrpcService::NewStub(channel))  {}

 

    /* Member functions */

    int Login(const std::string& username, const std::string& password);

   void Logout();

   void listen();

 

    /* Member variable */

   std::string token;

  

private:  

   std::unique_ptr<GrpcService::Stub> GrpcServiceStub;  // Use the GrpcService::Stub class generated from grpc_service.proto.

};

2.     Customize the Login method.

# Call the Login method of the GrpcService::Stub class to allow a user who provides the correct the username and password to log in.

int GrpcServiceTest::Login(const std::string& username, const std::string& password)

{

    LoginRequest request;   // Username and password.

    request.set_user_name(username);

    request.set_password(password);

 

LoginReply reply;      

ClientContext context;

 

   // Call the Login method.

   Status status = GrpcServiceStub->Login(&context, request, &reply);

   if (status.ok())

    {

       std::cout << "login ok!" << std::endl;

        std::cout <<"token id is :" << reply.token_id() << std::endl;

       token = reply.token_id();  // The login succeeds. The token is obtained.

        return 0;

    }

    else{                                       

       std::cout << status.error_code() << ": " << status.error_message()

                   << ". Login failed!" << std::endl;

        return -1;

    }

}

3.     Initiate an RPC request to the device. In this example, the application subscribes to interface packet drop events.

rpc SubscribePortQueDropEvent(PortQueDropEvent) returns (grpc_service.SubscribeReply) {}

4.     Create the BufMon_GrpcClient class to encapsulate the RPC method.

# Use the BufferMonitorService::Stub class generated from BufferMonitor.proto to call the RPC method.

class BufMon_GrpcClient

{

public:

    BufMon_GrpcClient(std::shared_ptr<Channel> channel): mStub(BufferMonitorService::NewStub(channel))

    {

    }

   

    std::string BufMon_Sub_AllEvent(std::string token);

    std::string BufMon_Sub_BoardEvent(std::string token);

    std::string BufMon_Sub_PortOverrunEvent(std::string token);

    std::string BufMon_Sub_PortDropEvent(std::string token);

 

    /* Get entries */

    std::string BufMon_Sub_GetStatistics(std::string token);

    std::string BufMon_Sub_GetGlobalCfg(std::string token);

    std::string BufMon_Sub_GetBoardCfg(std::string token);

    std::string BufMon_Sub_GetNodeQueCfg(std::string token);

    std::string BufMon_Sub_GetPortQueCfg(std::string token);

 

private:

   std::unique_ptr<BufferMonitorService::Stub> mStub; // Use the class generated from BufferMonitor.proto.

};

5.     Use std::string BufMon_Sub_PortDropEvent(std::string token) to implement interface packet drop event subscription.

std::string BufMon_GrpcClient::BufMon_Sub_PortDropEvent(std::string token)

{

    std::cout << "-------BufMon_Sub_PortDropEvent-------- " << std::endl;

 

   PortQueDropEvent stNodeEvent;

   PortQueDropEvent_PortQueDrop* pstParam = stNodeEvent.add_portquedrop();

 

    UINT uiIfIndex = 0;

    UINT uiQueIdx = 0;

    UINT uiAlarmType = 0;

 

    std::cout<<"Please input interface queue info : ifIndex queIdx alarmtype " << std::endl;

    cout<<"alarmtype : 1 for ingress; 2 for egress; 3 for port headroom"<<endl;

 

    std::cin>>uiIfIndex>>uiQueIdx>>uiAlarmType; // Set the subscription parameters and interface index.

   pstParam->set_ifindex(uiIfIndex);

    pstParam->set_queindex(uiQueIdx);

    pstParam->set_alarmtype(uiAlarmType);

 

    ClientContext context;

 

   /* Token needs to be added to context */ // Set the token_id to be returned after a successful login

   std::string key = "token_id";

   std::string value = token;

   context.AddMetadata(key, value);

  

   SubscribeReply reply;

   Status status = mStub->SubscribePortQueDropEvent(&context,stNodeEvent,&reply); // Call the RPC method.

 

   return reply.result();

}

6.     Use a loop to listen to event reports.

# Implement this method in the GrpcServiceTest class.

void GrpcServiceTest::listen()

{

    GetReportRequest reportRequest;

    ClientContext context;

    ReportEvent reportedEvent;

  

   /* Add the token to the request */

   reportRequest.set_token_id(token);

 

    std::unique_ptr< ClientReader< ReportEvent>> reader(GrpcServiceStub->GetEventReport(&context, reportRequest)); // Use GetEventReport (which is generated from grpc_service.proto) to obtain event information.

 

    std::string streamName;   

    std::string eventName;

    std::string jsonText;

   std::string token;

 

    JsonFormatTool jsonTool;

 

   std::cout << "Listen to server for Event" << std::endl;

 

    while(reader->Read(&reportedEvent) ) // Read the received event report.

    {

        streamName = reportedEvent.stream_name();

        eventName = reportedEvent.event_name();

       jsonText = reportedEvent.json_text();

       token = reportedEvent.token_id();

 

       std::cout << "/**********************EVENT COME************************/" << std::endl;

       std::cout << "TOKEN: " << token << std::endl;

       std::cout << "StreamName: "<< streamName << std::endl;

       std::cout << "EventName: " << eventName << std::endl;

       std::cout << "JsonText without format: " << std::endl << jsonText << std::endl;

        std::cout << std::endl;

       std::cout << "JsonText Formated: " << jsonTool.formatJson(jsonText) << std::endl;

        std::cout << std::endl;

    }

 

    Status status = reader->Finish();

    std::cout << "Status Message:" << status.error_message() << "ERROR code :" << status.error_code();

}  // Login and RPC request finished.

7.     To log out, call the Logout method. (Details not shown.)

Dial-out mode

In dial-out mode, the application needs to provide the gRPC server code so the collector can receive and resolve data obtained from the device.

The application performs the following operations:

·     Inherit the automatically generated GRPCDialout::Service class, overload the automatically generated RPC Dialout service, and resolve the fields.

·     Register the RPC service with the specified listening port.

To develop the collector-side application in dial-out mode:

1.     Inherit and overload RPC service Dialout.

# Create class DialoutTest and inherit GRPCDialout::Service.

class DialoutTest final : public GRPCDialout::Service { // Overload the automatically generated abstract class.

    Status Dialout(ServerContext* context, ServerReader< DialoutMsg>* reader, DialoutResponse* response) override; // Implement RPC method Dialout.

};

2.     Register the DialoutTest service as a gRPC service and specify the listening port.

using grpc::Server;

using grpc::ServerBuilder;

std::string server_address("0.0.0.0:60057"); // Specify the address and port to listen to.

DialoutTest dialout_test; // Define the object declared in step 1.

ServerBuilder builder;

builder.AddListeningPort(server_address, grpc::InsecureServerCredentials());// Add the listening port.

builder.RegisterService(&dialout_test); // Register the service.

std::unique_ptr<Server> server(builder.BuildAndStart()); // Start the service.

server->Wait();

3.     Implement the Dialout method and data resolution.

Status DialoutTest::Dialout(ServerContext* context, ServerReader< DialoutMsg>* reader, DialoutResponse* response)

{

        DialoutMsg msg;

 

        while( reader->Read(&msg))

        {

            const DeviceInfo &device_msg = msg.devicemsg();

            std::cout<< "Producer-Name: " << device_msg.producername() << std::endl;

            std::cout<< "Device-Name: " << device_msg.devicename() << std::endl;

            std::cout<< "Device-Model: " << device_msg.devicemodel() << std::endl;

            std::cout<<"Sensor-Path: " << msg.sensorpath()<<std::endl;

            std::cout<<"Json-Data: " << msg.jsondata()<<std::endl;

            std::cout<<std::endl;

        }

        response->set_response("test");

 

        return Status::OK;

}

4.     After obtaining the DialoutMsg object (generated from the proto definition file) through the Read method, you can call the method to obtain the field values.

 

  • Cloud & AI
  • InterConnect
  • Intelligent Computing
  • Security
  • SMB Products
  • Intelligent Terminal Products
  • Product Support Services
  • Technical Service Solutions
All Services
  • Resource Center
  • Policy
  • Online Help
All Support
  • Become a Partner
  • Partner Resources
  • Partner Business Management
All Partners
  • Profile
  • News & Events
  • Online Exhibition Center
  • Contact Us
All About Us
新华三官网