I. Feature Description

Cloud Monitor data can be forwarded to a specified Kafka, supporting:

• Full data forwarding, such as forwarding all metric data of CVMs.
• Partial forwarding. For example, metric data of a CVM instance or metric data of all CVM instances under a specific AppID is forwarded, or specified metric data of specified instances is forwarded.
  The above features are configured through forwarding rules.

  Note:

  The tcloud-barad-dispense application must be deployed in the environment.

II. Forwarding Configuration

Currently, forwarding rules need to be configured via CLI-based operations, that is, by inserting forwarding rules into the database. The steps are as follows:

1. Connect to the forwarding database: Set the database name to dispense and the corresponding service_id to dbsql-barad-dispense, and run the following command on the master node:

dbsql_info barad-dispense         // This is barad-dispense, not dbsql-barad-dispense.

Note:

The connect cmd is the command to connect to the dispense database.

2. Configure forwarding rules.

-- Create a rule.
insert into t_rule (RuleName, Status) values ('forwarding rule name', 1);
// Note:
// RuleName: rule name.
// Status: whether the rule is enabled. 1: enabled, 0: disabled.

-- Configure the metrics that need to be forwarded.
insert into t_metric (RuleId, Metric, Namespace, Measurement, Periods) values (10, 'cpu_usage', 'qce/cvm', 'cvm_device', '60');
// Note:
// RuleId: ID of the new rule specified by t_rule.
// Metric: metric name.
// Namespace: Namespace to which the metric belongs.
// Measurement: view of Cloud Monitor. To obtain the view, refer to Appendix 1.
// Periods: time granularity of the metric. Multiple granularities can be specified, such as (60, 300), or the asterisk (*) can be used to indicate all supported granularities.
// If you need to know the namespace to which the metrics belong, the measurement, as well as the supported time granularities, refer to the appendix.

-- Configure filter conditions (Optional. Configure this if you only want to forward data of a specific instance. There are 10 tables in total. You can obtain the information about which table ${n} resides on by performing a ruleId % 10 calculation.)
insert into t_condition_${n} (RuleId, Filters) values (10, '[{"Key":"vm_uuid","Values":["c7fc0b4c-0059-4318-bb0c-dc4a31a071da"],"Expression":"="},{"Key":"__appid__","Values":["251005942", "1"],"Expression":"in"}]');
// Note:
// RuleId: ID of the new rule specified by t_rule.
// Filters: forwarding rule filter, which is of a JSON array with an and relationship between rules.

-- Configure the forwarding target Kafka.
insert into t_target (RuleId, Target, ProtoType) values (10, '{"brokers":"11.150.215.105:9092","topic":"Nowrite","user":"","password":""}', 1);
// Note:
// RuleId: ID of the new rule specified by t_rule.
// Target: target Kafka address.
// ProtoType: message types forwarded to Kafka. 1: JSON, 2: Protobuf.

III. Message Protocol

The message protocol forwarded to Kafka is as follows:

// json
{
    "Namespace": "qce/cvm",
    "MetricName": "cpu_usage",
    "Statistic": "MAX",
    "Period": 60,
    "Dimensions": [{
        "Name": "appid",
        "Value": "1"
    }, {
        "Name": "projectid",
        "Value": "0"
    }, {
        "Name": "vm_uuid",
        "Value": "4f7639f1-f156-41b4-9072-f7e27af97d3b"
    }],
    "Timestamp": 1737107700000,
    "Value": 22.916666666666668
}

IV. Forwarding Table Structure Description

5. Appendix: Viewing Metrics, Namespace, Measurement, and Period

1. Run kubectl get ingress -A | grep isd.barad on the master node.
   
2. Access the domain name through a browser.