mirror
/
client_golang
mirror of https://github.com/prometheus/client_golang.git
1
0
Fork 1
Code Issues Packages Projects Releases Wiki Activity
client_golang/text/create_test.go

348 lines
8.5 KiB
Go
Raw Normal View History

Change "Prometheus Team" to "The Prometheus Authors".
2015-02-02 17:14:36 +03:00
// Copyright 2014 The Prometheus Authors
Conversion back and forth between MetricFamily protobuf and text format. The idea here is to always go via the protobufs if dealing with the text format. That won't always be the most efficient way, but it avoids the multiplicity of conversion routines required for direct conversion (e.g. text format -> internal representation in the Prometheus server). The loss of efficiency is acceptable because the text format should not be used in high performance (high throughput, low latency) situations anyway. In that way, the text format stays perfectly isolated from other parts of the code. To receive text format, just plug the conversion in before the code path that normally reads protobufs. Correspondingly, for sending text format, simply replace the WriteDelimited call by a text.Create call. Nevertheless, the conversion code itself is optimized for efficiency and minimized memory churn (which was one of the reason for handcoding the parser and not using a lexer/parser code generation tool). Change-Id: Iee45ffe8aa421a844225d13a1f859becd8a3b066
2014-04-09 22:38:51 +04:00
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
package text
import (
"bytes"
"math"
"strings"
"testing"
Complete rewrite of the exposition library. This rewrite had may backs and forths. In my git repository, it consists of 35 commits which I cannot group or merge into reasonable review buckets. Gerrit breaks fundamental git semantics, so I have to squash the 35 commits into one for the review. I'll push this not with refs/for/master, but with refs/for/next so that we can transition after submission in a controlled fashion. For the review, I recommend to start with looking at godoc and in particular the many examples. After that, continue with a line-by-line detailed review. (The big picture is hopefully as expected after wrapping up the discussion earlier.) Change-Id: Ib38cc46493a5139ca29d84020650929d94cac850
2014-05-07 22:08:33 +04:00
"code.google.com/p/goprotobuf/proto"
Conversion back and forth between MetricFamily protobuf and text format. The idea here is to always go via the protobufs if dealing with the text format. That won't always be the most efficient way, but it avoids the multiplicity of conversion routines required for direct conversion (e.g. text format -> internal representation in the Prometheus server). The loss of efficiency is acceptable because the text format should not be used in high performance (high throughput, low latency) situations anyway. In that way, the text format stays perfectly isolated from other parts of the code. To receive text format, just plug the conversion in before the code path that normally reads protobufs. Correspondingly, for sending text format, simply replace the WriteDelimited call by a text.Create call. Nevertheless, the conversion code itself is optimized for efficiency and minimized memory churn (which was one of the reason for handcoding the parser and not using a lexer/parser code generation tool). Change-Id: Iee45ffe8aa421a844225d13a1f859becd8a3b066
2014-04-09 22:38:51 +04:00
dto "github.com/prometheus/client_model/go"
)
Complete rewrite of the exposition library. This rewrite had may backs and forths. In my git repository, it consists of 35 commits which I cannot group or merge into reasonable review buckets. Gerrit breaks fundamental git semantics, so I have to squash the 35 commits into one for the review. I'll push this not with refs/for/master, but with refs/for/next so that we can transition after submission in a controlled fashion. For the review, I recommend to start with looking at godoc and in particular the many examples. After that, continue with a line-by-line detailed review. (The big picture is hopefully as expected after wrapping up the discussion earlier.) Change-Id: Ib38cc46493a5139ca29d84020650929d94cac850
2014-05-07 22:08:33 +04:00
func testCreate(t testing.TB) {
Conversion back and forth between MetricFamily protobuf and text format. The idea here is to always go via the protobufs if dealing with the text format. That won't always be the most efficient way, but it avoids the multiplicity of conversion routines required for direct conversion (e.g. text format -> internal representation in the Prometheus server). The loss of efficiency is acceptable because the text format should not be used in high performance (high throughput, low latency) situations anyway. In that way, the text format stays perfectly isolated from other parts of the code. To receive text format, just plug the conversion in before the code path that normally reads protobufs. Correspondingly, for sending text format, simply replace the WriteDelimited call by a text.Create call. Nevertheless, the conversion code itself is optimized for efficiency and minimized memory churn (which was one of the reason for handcoding the parser and not using a lexer/parser code generation tool). Change-Id: Iee45ffe8aa421a844225d13a1f859becd8a3b066
2014-04-09 22:38:51 +04:00
var scenarios = []struct {
in *dto.MetricFamily
out string
}{
// 0: Counter, NaN as value, timestamp given.
{
in: &dto.MetricFamily{
Name: proto.String("name"),
Fix escaping even more. Change-Id: Ie958d557aae0dda68c451e9fafc615221cc07bb0
2014-05-14 21:28:53 +04:00
Help: proto.String("two-line\n doc str\\ing"),
Conversion back and forth between MetricFamily protobuf and text format. The idea here is to always go via the protobufs if dealing with the text format. That won't always be the most efficient way, but it avoids the multiplicity of conversion routines required for direct conversion (e.g. text format -> internal representation in the Prometheus server). The loss of efficiency is acceptable because the text format should not be used in high performance (high throughput, low latency) situations anyway. In that way, the text format stays perfectly isolated from other parts of the code. To receive text format, just plug the conversion in before the code path that normally reads protobufs. Correspondingly, for sending text format, simply replace the WriteDelimited call by a text.Create call. Nevertheless, the conversion code itself is optimized for efficiency and minimized memory churn (which was one of the reason for handcoding the parser and not using a lexer/parser code generation tool). Change-Id: Iee45ffe8aa421a844225d13a1f859becd8a3b066
2014-04-09 22:38:51 +04:00
Type: dto.MetricType_COUNTER.Enum(),
Metric: []*dto.Metric{
&dto.Metric{
Label: []*dto.LabelPair{
&dto.LabelPair{
Name: proto.String("labelname"),
Value: proto.String("val1"),
},
&dto.LabelPair{
Name: proto.String("basename"),
Value: proto.String("basevalue"),
},
},
Counter: &dto.Counter{
Value: proto.Float64(math.NaN()),
},
},
&dto.Metric{
Label: []*dto.LabelPair{
&dto.LabelPair{
Name: proto.String("labelname"),
Value: proto.String("val2"),
},
&dto.LabelPair{
Name: proto.String("basename"),
Value: proto.String("basevalue"),
},
},
Counter: &dto.Counter{
Value: proto.Float64(.23),
},
TimestampMs: proto.Int64(1234567890),
},
},
},
Fix escaping even more. Change-Id: Ie958d557aae0dda68c451e9fafc615221cc07bb0
2014-05-14 21:28:53 +04:00
out: `# HELP name two-line\n doc str\\ing
Conversion back and forth between MetricFamily protobuf and text format. The idea here is to always go via the protobufs if dealing with the text format. That won't always be the most efficient way, but it avoids the multiplicity of conversion routines required for direct conversion (e.g. text format -> internal representation in the Prometheus server). The loss of efficiency is acceptable because the text format should not be used in high performance (high throughput, low latency) situations anyway. In that way, the text format stays perfectly isolated from other parts of the code. To receive text format, just plug the conversion in before the code path that normally reads protobufs. Correspondingly, for sending text format, simply replace the WriteDelimited call by a text.Create call. Nevertheless, the conversion code itself is optimized for efficiency and minimized memory churn (which was one of the reason for handcoding the parser and not using a lexer/parser code generation tool). Change-Id: Iee45ffe8aa421a844225d13a1f859becd8a3b066
2014-04-09 22:38:51 +04:00
# TYPE name counter
name{labelname="val1",basename="basevalue"} NaN
name{labelname="val2",basename="basevalue"} 0.23 1234567890
`,
},
// 1: Gauge, some escaping required, +Inf as value, multi-byte characters in label values.
{
in: &dto.MetricFamily{
Name: proto.String("gauge_name"),
Fix escaping even more. Change-Id: Ie958d557aae0dda68c451e9fafc615221cc07bb0
2014-05-14 21:28:53 +04:00
Help: proto.String("gauge\ndoc\nstr\"ing"),
Conversion back and forth between MetricFamily protobuf and text format. The idea here is to always go via the protobufs if dealing with the text format. That won't always be the most efficient way, but it avoids the multiplicity of conversion routines required for direct conversion (e.g. text format -> internal representation in the Prometheus server). The loss of efficiency is acceptable because the text format should not be used in high performance (high throughput, low latency) situations anyway. In that way, the text format stays perfectly isolated from other parts of the code. To receive text format, just plug the conversion in before the code path that normally reads protobufs. Correspondingly, for sending text format, simply replace the WriteDelimited call by a text.Create call. Nevertheless, the conversion code itself is optimized for efficiency and minimized memory churn (which was one of the reason for handcoding the parser and not using a lexer/parser code generation tool). Change-Id: Iee45ffe8aa421a844225d13a1f859becd8a3b066
2014-04-09 22:38:51 +04:00
Type: dto.MetricType_GAUGE.Enum(),
Metric: []*dto.Metric{
&dto.Metric{
Label: []*dto.LabelPair{
&dto.LabelPair{
Name: proto.String("name_1"),
Value: proto.String("val with\nnew line"),
},
&dto.LabelPair{
Name: proto.String("name_2"),
Value: proto.String("val with \\backslash and \"quotes\""),
},
},
Gauge: &dto.Gauge{
Value: proto.Float64(math.Inf(+1)),
},
},
&dto.Metric{
Label: []*dto.LabelPair{
&dto.LabelPair{
Name: proto.String("name_1"),
Value: proto.String("Björn"),
},
&dto.LabelPair{
Name: proto.String("name_2"),
Value: proto.String("佖佥"),
},
},
Gauge: &dto.Gauge{
Value: proto.Float64(3.14E42),
},
},
},
},
Fix escaping even more. Change-Id: Ie958d557aae0dda68c451e9fafc615221cc07bb0
2014-05-14 21:28:53 +04:00
out: `# HELP gauge_name gauge\ndoc\nstr"ing
Conversion back and forth between MetricFamily protobuf and text format. The idea here is to always go via the protobufs if dealing with the text format. That won't always be the most efficient way, but it avoids the multiplicity of conversion routines required for direct conversion (e.g. text format -> internal representation in the Prometheus server). The loss of efficiency is acceptable because the text format should not be used in high performance (high throughput, low latency) situations anyway. In that way, the text format stays perfectly isolated from other parts of the code. To receive text format, just plug the conversion in before the code path that normally reads protobufs. Correspondingly, for sending text format, simply replace the WriteDelimited call by a text.Create call. Nevertheless, the conversion code itself is optimized for efficiency and minimized memory churn (which was one of the reason for handcoding the parser and not using a lexer/parser code generation tool). Change-Id: Iee45ffe8aa421a844225d13a1f859becd8a3b066
2014-04-09 22:38:51 +04:00
# TYPE gauge_name gauge
gauge_name{name_1="val with\nnew line",name_2="val with \\backslash and \"quotes\""} +Inf
gauge_name{name_1="Björn",name_2="佖佥"} 3.14e+42
`,
},
// 2: Untyped, no help, one sample with no labels and -Inf as value, another sample with one label.
{
in: &dto.MetricFamily{
Name: proto.String("untyped_name"),
Type: dto.MetricType_UNTYPED.Enum(),
Metric: []*dto.Metric{
&dto.Metric{
Untyped: &dto.Untyped{
Value: proto.Float64(math.Inf(-1)),
},
},
&dto.Metric{
Label: []*dto.LabelPair{
&dto.LabelPair{
Name: proto.String("name_1"),
Value: proto.String("value 1"),
},
},
Untyped: &dto.Untyped{
Value: proto.Float64(-1.23e-45),
},
},
},
},
out: `# TYPE untyped_name untyped
untyped_name -Inf
untyped_name{name_1="value 1"} -1.23e-45
`,
},
// 3: Summary.
{
in: &dto.MetricFamily{
Name: proto.String("summary_name"),
Help: proto.String("summary docstring"),
Type: dto.MetricType_SUMMARY.Enum(),
Metric: []*dto.Metric{
&dto.Metric{
Summary: &dto.Summary{
SampleCount: proto.Uint64(42),
SampleSum: proto.Float64(-3.4567),
Quantile: []*dto.Quantile{
&dto.Quantile{
Quantile: proto.Float64(0.5),
Value: proto.Float64(-1.23),
},
&dto.Quantile{
Quantile: proto.Float64(0.9),
Value: proto.Float64(.2342354),
},
&dto.Quantile{
Quantile: proto.Float64(0.99),
Value: proto.Float64(0),
},
},
},
},
&dto.Metric{
Label: []*dto.LabelPair{
&dto.LabelPair{
Name: proto.String("name_1"),
Value: proto.String("value 1"),
},
&dto.LabelPair{
Name: proto.String("name_2"),
Value: proto.String("value 2"),
},
},
Summary: &dto.Summary{
SampleCount: proto.Uint64(4711),
SampleSum: proto.Float64(2010.1971),
Quantile: []*dto.Quantile{
&dto.Quantile{
Quantile: proto.Float64(0.5),
Value: proto.Float64(1),
},
&dto.Quantile{
Quantile: proto.Float64(0.9),
Value: proto.Float64(2),
},
&dto.Quantile{
Quantile: proto.Float64(0.99),
Value: proto.Float64(3),
},
},
},
},
},
},
out: `# HELP summary_name summary docstring
# TYPE summary_name summary
summary_name{quantile="0.5"} -1.23
summary_name{quantile="0.9"} 0.2342354
summary_name{quantile="0.99"} 0
summary_name_sum -3.4567
summary_name_count 42
summary_name{name_1="value 1",name_2="value 2",quantile="0.5"} 1
summary_name{name_1="value 1",name_2="value 2",quantile="0.9"} 2
summary_name{name_1="value 1",name_2="value 2",quantile="0.99"} 3
summary_name_sum{name_1="value 1",name_2="value 2"} 2010.1971
summary_name_count{name_1="value 1",name_2="value 2"} 4711
`,
},
}
for i, scenario := range scenarios {
out := bytes.NewBuffer(make([]byte, 0, len(scenario.out)))
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
n, err := MetricFamilyToText(out, scenario.in)
Conversion back and forth between MetricFamily protobuf and text format. The idea here is to always go via the protobufs if dealing with the text format. That won't always be the most efficient way, but it avoids the multiplicity of conversion routines required for direct conversion (e.g. text format -> internal representation in the Prometheus server). The loss of efficiency is acceptable because the text format should not be used in high performance (high throughput, low latency) situations anyway. In that way, the text format stays perfectly isolated from other parts of the code. To receive text format, just plug the conversion in before the code path that normally reads protobufs. Correspondingly, for sending text format, simply replace the WriteDelimited call by a text.Create call. Nevertheless, the conversion code itself is optimized for efficiency and minimized memory churn (which was one of the reason for handcoding the parser and not using a lexer/parser code generation tool). Change-Id: Iee45ffe8aa421a844225d13a1f859becd8a3b066
2014-04-09 22:38:51 +04:00
if err != nil {
t.Errorf("%d. error: %s", i, err)
continue
}
if expected, got := len(scenario.out), n; expected != got {
t.Errorf(
"%d. expected %d bytes written, got %d",
i, expected, got,
)
}
if expected, got := scenario.out, out.String(); expected != got {
t.Errorf(
"%d. expected out=%q, got %q",
i, expected, got,
)
}
}
}
func TestCreate(t *testing.T) {
testCreate(t)
}
func BenchmarkCreate(b *testing.B) {
for i := 0; i < b.N; i++ {
testCreate(b)
}
}
Complete rewrite of the exposition library. This rewrite had may backs and forths. In my git repository, it consists of 35 commits which I cannot group or merge into reasonable review buckets. Gerrit breaks fundamental git semantics, so I have to squash the 35 commits into one for the review. I'll push this not with refs/for/master, but with refs/for/next so that we can transition after submission in a controlled fashion. For the review, I recommend to start with looking at godoc and in particular the many examples. After that, continue with a line-by-line detailed review. (The big picture is hopefully as expected after wrapping up the discussion earlier.) Change-Id: Ib38cc46493a5139ca29d84020650929d94cac850
2014-05-07 22:08:33 +04:00
func testCreateError(t testing.TB) {
Conversion back and forth between MetricFamily protobuf and text format. The idea here is to always go via the protobufs if dealing with the text format. That won't always be the most efficient way, but it avoids the multiplicity of conversion routines required for direct conversion (e.g. text format -> internal representation in the Prometheus server). The loss of efficiency is acceptable because the text format should not be used in high performance (high throughput, low latency) situations anyway. In that way, the text format stays perfectly isolated from other parts of the code. To receive text format, just plug the conversion in before the code path that normally reads protobufs. Correspondingly, for sending text format, simply replace the WriteDelimited call by a text.Create call. Nevertheless, the conversion code itself is optimized for efficiency and minimized memory churn (which was one of the reason for handcoding the parser and not using a lexer/parser code generation tool). Change-Id: Iee45ffe8aa421a844225d13a1f859becd8a3b066
2014-04-09 22:38:51 +04:00
var scenarios = []struct {
in *dto.MetricFamily
err string
}{
// 0: No metric.
{
in: &dto.MetricFamily{
Name: proto.String("name"),
Help: proto.String("doc string"),
Type: dto.MetricType_COUNTER.Enum(),
Metric: []*dto.Metric{},
},
err: "MetricFamily has no metrics",
},
// 1: No metric name.
{
in: &dto.MetricFamily{
Help: proto.String("doc string"),
Type: dto.MetricType_UNTYPED.Enum(),
Metric: []*dto.Metric{
&dto.Metric{
Untyped: &dto.Untyped{
Value: proto.Float64(math.Inf(-1)),
},
},
},
},
err: "MetricFamily has no name",
},
// 2: No metric type.
{
in: &dto.MetricFamily{
Name: proto.String("name"),
Help: proto.String("doc string"),
Metric: []*dto.Metric{
&dto.Metric{
Untyped: &dto.Untyped{
Value: proto.Float64(math.Inf(-1)),
},
},
},
},
err: "MetricFamily has no type",
},
// 3: Wrong type.
{
in: &dto.MetricFamily{
Name: proto.String("name"),
Help: proto.String("doc string"),
Type: dto.MetricType_COUNTER.Enum(),
Metric: []*dto.Metric{
&dto.Metric{
Untyped: &dto.Untyped{
Value: proto.Float64(math.Inf(-1)),
},
},
},
},
err: "expected counter in metric",
},
}
for i, scenario := range scenarios {
var out bytes.Buffer
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
_, err := MetricFamilyToText(&out, scenario.in)
Conversion back and forth between MetricFamily protobuf and text format. The idea here is to always go via the protobufs if dealing with the text format. That won't always be the most efficient way, but it avoids the multiplicity of conversion routines required for direct conversion (e.g. text format -> internal representation in the Prometheus server). The loss of efficiency is acceptable because the text format should not be used in high performance (high throughput, low latency) situations anyway. In that way, the text format stays perfectly isolated from other parts of the code. To receive text format, just plug the conversion in before the code path that normally reads protobufs. Correspondingly, for sending text format, simply replace the WriteDelimited call by a text.Create call. Nevertheless, the conversion code itself is optimized for efficiency and minimized memory churn (which was one of the reason for handcoding the parser and not using a lexer/parser code generation tool). Change-Id: Iee45ffe8aa421a844225d13a1f859becd8a3b066
2014-04-09 22:38:51 +04:00
if err == nil {
t.Errorf("%d. expected error, got nil", i)
continue
}
if expected, got := scenario.err, err.Error(); strings.Index(got, expected) != 0 {
t.Errorf(
"%d. expected error starting with %q, got %q",
i, expected, got,
)
}
}
}
func TestCreateError(t *testing.T) {
testCreateError(t)
}
func BenchmarkCreateError(b *testing.B) {
for i := 0; i < b.N; i++ {
testCreateError(b)
}
}