No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE40E V800R010C10SPC500 Feature Description - System Monitor 01

This is NE40E V800R010C10SPC500 Feature Description - System Monitor
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Key Telemetry Technologies

Key Telemetry Technologies

For the Telemetry device side, Telemetry indicates the original data, data model, encoding format, and transmission protocol. For the Telemetry NMS side, Telemetry indicates the data collection system, storage system, and application analysis system.

NOTE:

This document describes key technologies only on the Telemetry device side.

Original Data

Telemetry collects data from the forwarding, control, and management planes of network devices. Currently, the data that can be collected includes interface traffic statistics, CPU usage, and memory usage.

Data Model

Telemetry collects data based on the YANG model.

YANG is a data modeling language developed to define configuration data modules, status data models, RPC models, and notification mechanisms for transmission protocols.

NOTE:

For more information, see YANG Model Introduction.

Encoding Format

Support for the Google Protocol Buffers (GPB) Encoding Format

Google Protocol Buffers (GPB) encoding is a language-neutral, platform-neutral, and extensible mechanism for serializing structured data of communications protocols and data storage.

Telemetry uses the encoding format GPB (the file name extension of a file encoded in GPB format is .proto) and provides a mechanism for serializing structured data flexibly, efficiently, and automatically. The GPB format is binary encoding and has good performance and high efficiency.

GPB uses the .proto file to describe a dictionary for encoding, which is the data structure description. You can use a tool such as Protoc (for example, the protoc-3.0.2-windows-x86_64.exe file) to automatically generate code (for example, Java code) based on the .proto file. Then, perform secondary development based on the automatically generated code to encode and decode GPB, thereby implementing device interworking. Table 6-2 compares GPB encoding and decoding.

Table 6-2 Comparison between GPB encoding and decoding

GPB Encoding

GPB Decoding

{
 1:"HUAWEI"
 2:"s4"
 3:"huawei-ifm:ifm/interfaces/interface"
 4:46
 5:1515727243419
 6:1515727243514
 7{
  1[{
   1: 1515727243419
   2 {
    5{
     1[{
      5:1
      16:2
      25:"Eth-Trunk1"
     }]
    }
   }
  }]
 }
 8:1515727243419
 9:10000
 10:"OK"
 11:"NE40E"
 12:0
}
{
 "node_id_str":"HUAWEI",
 "subscription_id_str":"s4",
 "sensor_path":"huawei-ifm:ifm/interfaces/interface",
 "collection_id":46,
 "collection_start_time":"2018/1/12 11:20:43.419",
 "msg_timestamp":"2018/1/12 11:20:43.514",
 "data_gpb":{
  "row":[{
   "timestamp":"2018/1/12 11:20:43.419",
   "content":{
    "interfaces":{
     "interface":[{
      "ifAdminStatus":1,
      "ifIndex":2,
      "ifName":"Eth-Trunk1"
     }]
    }
   }
  }]
 },
 "collection_end_time":"2018/1/12 11:20:43.419",
 "current_period":10000,
 "except_desc":"OK",
 "product_name":"NE40E",
 "encoding":Encoding_GPB
}
NOTE:

For data transmitted between devices and collectors, the data encoded in the GPB format has a higher information load capability than that encoded in other formats (JSON or XML). GPB encoding ensures Telemetry data throughput capabilities and reduces the CPU usage and bandwidth.

Transport Protocol

Support for Google Remote Procedure Call Protocol (gRPC)

gRPC is a high-performance general RPC open-source software framework running over HTTP2 protocols. Both communication parties perform secondary development based on the framework, so that they focus on services and do not need to pay attention to bottom-layer communication implemented by the gRPC software framework.

Telemetry uses the gRPC protocol to report the data encoded in GPB format to the collector.

NOTE:

The gRPC protocol applies to Telemetry static subscription and dynamic subscription.

Figure 6-3 shows the gRPC protocol stack layers.

Figure 6-3 Description of gRPC protocol stack layers

Table 6-3 describes the layers.

Table 6-3 Layers

Layer

Description

TCP layer

This is a bottom-layer communication protocol, which is based on TCP connections.

TLS layer

This layer is optional. It is based on the TLS 1.2–encrypted channel and bidirectional certificate authentication.

HTTP2 layer

The HTTP2 protocol carries gRPC, using HTTP2 features such as bidirectional streams, flow control, header compression, and multiplexing request of a single connection.

gRPC layer

This layer defines the protocol interaction format for remote procedure calls.

Data model layer

NOTE:

The data model layer is divided into three layers, which are defined in different .proto files. To establish a gRPC connection between the collector and a network device, use the .proto files for interconnection. The .proto files on the two ends must be the same, which facilitates decoding.

RPC layer

  • Telemetry static subscription: defined in the huawei-grpc-dialout.proto file.

  • Telemetry dynamic subscription: defined in the huawei-grpc-dialin.proto file.

Telemetry layer

Defined in the huawei-telemetry.proto file.

Service data layer

Defined in a .proto file depending on the sensor_path field value in the huawei-telemetry.proto file. For example, if the sensor_path value is huawei-ifm:ifm/interfaces/interface, the data structure is defined in the huawei-ifm.proto file.

The .proto files are described as follows:
  • huawei-grpc-dialout.proto is the RPC header file. When a device functions as the client to push data, this file defines the RPC interface. The following table describes the file content and meaning.

    huawei-grpc-dialout.proto

    syntax = "proto3";                          //The .proto file version is defined as v3. 
    package huawei_dialout;                     //The package name is huawei_dialout. 
    service gRPCDataservice {                   //The service name is gRPCDataservice. 
        rpc dataPublish(stream serviceArgs) returns(stream serviceArgs) {};                 //The method name is dataPublish, providing the data push method. The working mode is bidirectional stream mode. The input parameter is the serviceArgs data flow. 
    }
    message serviceArgs {                       //Message format description. 
        int64 ReqId = 1;                        //Request ID, whose index is 1 during GPB coding. 
        bytes data = 2;                         //Data carried, whose index is 2 during GPB coding and explained in huawei-telemetry.proto.
        string errors = 3;                      //Error description, whose index is 3 during GPB coding. 
    }
  • huawei-grpc-dialin.proto is the RPC header file. When a device functions as the server to push data, this file defines the RPC interface. The following table describes the file content and meaning.

    huawei-grpc-dialin.proto

    syntax = "proto3";                           //The .proto file version is defined as v3.
    package huawei_dialin;                     //The package name is huawei_dialin.
    service gRPCConfigOper {                   //The service name is gRPCConfigOper.
        rpc Subscribe (SubsArgs) returns (stream SubsReply) {}; //The method is Subscribe, and the server stream mode is used, providing the dynamic subscription method. The input parameter SubsArgs contains subscribing parameters.
        rpc Cancel (CancelArgs) returns (CancelReply) {}; //The method is Cancel, and the query and response mode is used, providing the method of canceling dynamic subscription. The input parameter CancelArgs contains unsubscribing parameters.
    }
    message Path {                //Path message structure.
        string path = 1;          //Subscribed sensor-path.
    }
    message SubsArgs {            //Subscribing request parameter.
        uint64 request_id = 1;    //Request ID, which is transferred by the invoker.
        uint32 encoding = 2;      //Encoding type. Currently, the value can only be 0, indicating GPB encoding.
        repeated Path path = 5;   //Subscribed path structure.
        uint64 sample_interval = 6; //Sampling interval.
        uint64 heartbeat_interval = 7; //Redundancy suppression interval. This parameter is valid only when suppress_redundant is set to 1.
        bool suppress_redundant = 8; //Redundancy suppression. The sampled data is not reported if the data content remains unchanged. 0: disabled, 1: enabled.
    }
    message SubsReply {            //Subscribing response parameter.
        uint32 subscription_id = 1; //If the subscribing is successful, the subscription ID is returned. If the subscribing fails, 0 is returned.
        uint64 request_id = 2;        //ID of the subscribing request.
        string response_code = 3; //Return code. The value 200 indicates a success.
        bytes message = 4;            //Error description. When the operation succeeds, this field in the subsequent RPC returns the data to be sent.
    }
    message CancelArgs {            //Unsubscribing request parameter.
        uint64 request_id = 1;    //Request ID, which is transferred by the invoker.
        uint32 subscription_id = 2;   //ID of the subscription to be canceled.
    }
    message CancelReply {            //Unsubscribing response parameter.
        uint64 request_id = 1;    //Request ID, which is transferred by the invoker.
        string response_code = 2; //Return code. The value 200 indicates a success.
        string message = 3;            //Error description.
    
    }
  • huawei-telemetry.proto is the Telemetry header definition file. It defines the data header when Telemetry data sampled is sent, including key information, such as the sampling path and sampling timestamp. The following table describes the file content and meaning.

    huawei-telemetry.proto

    syntax = "proto3";                           //The .proto file version is defined as v3. 
    package telemetry;                          //The package name is telemetry. 
    message Telemetry {                         //Telemetry message structure definition. 
       string node_id_str = 1;                     //Device name.
       string subscription_id_str = 2;             //Subscription name during static subscription configuration, whose index is 2 during GPB encoding. 
       string sensor_path = 3;                     //Subscription path, whose index is 3 during GPB encoding. 
       string proto_path = 13;                    //Message path for the sampling path in the proto file.
       uint64 collection_id = 4;                   //Sampling round, whose index is 4 during GPB encoding. 
       uint64 collection_start_time = 5;           //Start time of a sampling round, whose index is 5 during GPB encoding. 
       uint64 msg_timestamp = 6;                   //Timestamp when the current message is generated, whose index is 6 during GPB encoding. 
       TelemetryGPBTable data_gpb = 7;             //Indicates that the data carried is defined in TelemetryGPBTable. The index is 7 during GPB encoding. 
       uint64 collection_end_time = 8;                   //End time of a sampling round, whose index is 8 during GPB encoding. 
       uint32 current_period = 9;                  //Sampling precision, in milliseconds, whose index is 9 during GPB encoding. 
       string except_desc = 10;        //Exception description, whose index is 10 during GPB encoding. It is used to report exception information when a sampling exception occurs. 
       string product_name = 11;       //Product name.
       enum Encoding {
        Encoding_GPB = 0;        //GPB encoding format.
        Encoding_JSON = 1;       //JSON encoding format.
      };
      Encoding encoding =12;    //Data encoding format. If the GPB encoding format is used, the data_gpb field is valid. Otherwise, the data_str field is valid.
      string data_str = 14;   //This field is valid only when a non-GPB encoding format is used.
    }
    message TelemetryGPBTable {                 //TelemetryGPBTable message structure definition. 
      repeated TelemetryRowGPB row = 1;           //Array definition, whose index is 1 during GPB encoding. Its member is TelemetryRowGPB structure. 
    } 
    message TelemetryRowGPB { 
    uint64 timestamp = 1;                       //Timestamp of the current sampling instance, whose index is 1 during GPB encoding. 
    bytes content = 11;                         //Sampling instance data carried, whose index is 11 during GPB encoding. The sensor_path field must be considered to determine which .proto file is used for encoding. 
    }
    message TelemetrySelfDefinedEvent {
      string path = 1;         //Sampling path that triggers the customized event, which describes the method of parsing the content.
      string proto_path = 13;  //Message path for the sampling path in the proto file.
      uint32 level = 2;        //Level of the user-defined event.
      string description = 3;  //Description of the user-defined event.
      string fieldName = 4; //Name of the field that triggers the customized event.
      uint32 fieldValue = 5;   //Value of the field that triggers the customized event.
      TelemetrySelfDefineThresTable data_threshold = 6; //Threshold filter criteria when the customized event is triggered.
      enum ThresholdRelation {
          ThresholdRelation_INVALID = 0; //The relationship between thresholds is not configured.
          ThresholdRelation_AND = 1; //The relationship between thresholds is And.
          ThresholdRelation_OR = 2; //The relationship between thresholds is Or.
      }
      ThresholdRelation thresholdRelation = 7; //Relationship between threshold filter criteria when the customized event is triggered.
      bytes content = 8; //Sampled data that triggers the customized event.
    }
    message TelemetrySelfDefineThresTable {
      repeated TelemetryThreshold row = 1; //Multiple thresholds are included.
    }
    message TelemetryThreshold {
      uint32 thresholdValue = 1; //Delivered threshold.
      enum ThresholdOpType {
          ThresholdOpType_EQ = 0; //The actual value in the data sent equals to the configured data threshold.
          ThresholdOpType_GT = 1; //The actual value in the data sent is greater than the configured data threshold.
          ThresholdOpType_GE = 2; //The actual value in the data sent is greater than or equals to the configured data threshold.
          ThresholdOpType_LT = 3; //The actual value in the data sent is less than the configured data threshold.
          ThresholdOpType_LE = 4; //The actual value in the data sent is less than or equals to the configured data threshold.
      }
      ThresholdOpType thresholdOpType = 2; //Threshold on the device.
    
    }
  • A service data file describes the detailed service data format. For details, see Sampling Paths That Telemetry Supports.

Support for User Datagram Protocol (UDP)

UDP is a datagram-oriented simple transport-layer protocol. It does not provide reliability, flow control, or error recovery functions for IP. UDP is applicable to networks with low reliability requirements and economical transmission.

Telemetry uses the UDP protocol to report the data collected to the collector.

NOTE:

The UDP protocol applies to Telemetry static subscription.

Figure 6-4 shows the UDP protocol stack layers.

Figure 6-4 UDP protocol stack layers

Table 6-4 describes the layers.

Table 6-4 Layers

Layer

Description

UDP layer

UDP-based communications protocol.

Data model layer

NOTE:

The data model layer is divided into three layers, which are defined in different .proto files except the Message header. To establish a UDP connection between the collector and a network device, use the .proto files for interconnection. The .proto files on the two ends must be the same, which facilitates decoding. For description of the .proto files, see the relevent content of gRPC.

Message header

For the definition of Message header architecture, see UDP based Publication Channel for Streaming Telemetry.

Telemetry layer

Defined in the huawei-telemetry.proto file.

Service data layer

Defined in a .proto file depending on the sensor_path field value in the huawei-telemetry.proto file. For example, if the sensor_path value is huawei-ifm:ifm/interfaces/interface, the data structure is defined in the huawei-ifm.proto file.

Customized Event Reporting Based on Telemetry Static Subscription

You can configure a Telemetry customized event. If a performance indicator of a resource object that Telemetry monitors exceeds the user-defined threshold, the customized event is reported to the collector in time for service policy determination.

Push Mode

The Telemetry push mode enables network devices to periodically push data to the NMS, avoiding repeated query and improving monitoring performance. Figure 6-5 shows the push process.

Figure 6-5 Sampling process in Telemetry push mode

Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055050

Views: 5096

Downloads: 26

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next