I. Naming scheme
The OPENTSDB naming format is somewhat similar to the RRD style, with the introduction of tags (tags) that make the metrics (metric) More representative and versatile, and can share many unique time series. By the combination of key value pairs to determine the uniqueness of the indicator, you can be very flexible to aggregate the function of the query.
RRD If you want to record the amount of user space used by the WEB1 server's first CPU, the named format is Web1.sys.cpu.0.user, and if you have thousands of servers, each multi-core CPU, you need to name a lot to differentiate, such as Webn.sys.cpu.m.user. For Opentsdb, you can name Sys.cpu.user host=web1,cpu=0. If you want to summarize the values of all kernels, simply sum:sys.cpu.user{host=web1}. If you want to summarize the CPU value of thousands of servers, just sum:sys.cpu.user. More versatile than the RRD naming format.
Therefore, for the object to be monitored naming, to define a common, easy to summarize, at the same time, to be able to express a good monitoring of the project. two. Specification for indicator naming
Indicator names are case-sensitive and are uniformly named in lowercase letters.
Indicator names cannot contain spaces.
The indicator name can only contain the following characters: A-z,a-z,0-9,-, _,.,/or Unicode letters.
The index name is as short as possible. Three. Specification of indicator value
The metric value can be either an integer or a floating-point number. four. Time Stamp
The Unix timestamp can be a second or millisecond, must be an integer, and cannot exceed 13 digits. The time stamp format for the millisecond level must be 1234567890123, and the last three digits represent the number of milliseconds. For an application-generated timestamp of more than 13 digits, it must be rounded up to a maximum of 13 digits, otherwise the error is not correct.
Because the opentsdb underlying storage system HBase currently supports only second-level storage, the millisecond-level data is converted to seconds. Five. Tag Naming conventions
tags are used to supplement the indicator, the attribute of the indicator, to define the difference of the indicator.
The tag is a pair of key-value pairs.
Each metric has at least one tag. Usually Host=ip or host=hostname.
OPENTSDB supports up to 8 tags.
Tags are case-sensitive and are named uniformly in lowercase letters.
tags cannot contain spaces.
Tags can only contain the following characters: A-z,a-z,0-9,-, _,.,/or Unicode letters. six. HTTP API Interface
To conserve bandwidth, the interface allows multiple data point data to be submitted in a single request. Each data point is handled separately, and if one of the data points has a problem it does not affect the storage of the other number of positions. Address:/api/put/api/put?summary debugging, returns the summary information/api/put?details debugging, returns the detailed information method: POST format:
{
Metric: "Lvs.connection.active",//required, string, indicator name
timestamp:1234567890,//required, integral type, time stamp
value:11.11,//required, Integer, floating-point, string, metric value
Returns the result:
By default, if all data stores succeed, respond to a 204 status code. Returns a 400 status code and error message content if one or more data points are faulted. When the request address is/api/put?summary, return:
{
"Failed": 1,//integral type, number of data points that failed to store
"Success": 0//integer, storage number of successful data points
When the request address is/api/put?details, return:
{
"Errors": [...],//array, List of failed data points, and reasons for failure
"Failed": 1,
"Success": 0
} seven. HTTP API Interface Instance
1./api/put
# curl-i-X post-d ' {"metric": "proc.loadavg.15m", "timestamp": 1413015492, "value": 8, "tags": {"host": "10.0.101.145"}} ' Http://10.0.101.145:4242/api/put http/1.1204nocontent content-type:application/json;charset=utf-8 content-length:0
2./api/put?summary