You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: metric/doc.go
+35-1Lines changed: 35 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,41 @@ Package metric is a generic metric package for the standard metric types gauges/
4
4
This implementation is aimed at being as fast as possible to not discourage metrics on values in hotpaths just because of locking overhead. This requires some client side buffering (and flusher go-routines) and, especially for the timer/histogram event type, a relatively large data structure to create a ring-buffer with mostly lock-free writes. (it uses condition variables for flushing).
5
5
This design is for the use case where you have a lot of timer/histogram metric events going to a few buckets.
6
6
7
-
The API is accessed via Client objects. (There's a default global client). The low latency and speed is achieved by creating permanent buffering metrics objects for each metric. Alternatively you can manually send ad-hoc metrics directly to the Clients configured sink. This allows for use cases where you don't have a small set of known metrics receiving many events, but rather many metrics receiving few evetns each.
7
+
The API consists of 3 main types of objects:
8
+
9
+
* Meter - the object doing the actual measuring. (possibly buffering measurements)
10
+
* Sink - an object to which Meter readings can be sent. Sinks can have internal buffering which can be flushed
11
+
* Client - an object responsible for sending Meter readings to an assigned Sink, possibly at configured flushing intervals.
12
+
13
+
The API supports 3 approaches to maintaining your metrics:
14
+
15
+
Ad-hoc
16
+
17
+
Ad-hoc generation of metric events without a Meter object (explicitly flushing the Client sink):
18
+
This is a relative slow, but simple way to generate metric data.
19
+
This allows for use cases where you don't have a small set of known metrics receiving many events, but rather many metrics receiving few events each:
20
+
21
+
metric.SetDefaultSink(sink)
22
+
metric.AdhocGauge("gauge", 17, true)
23
+
24
+
Manually
25
+
26
+
Manually making readings of a meter directly to a Sink. (use this only if strictly needed)
27
+
28
+
gauge := metric.NewGauge("gauge")
29
+
gauge.Set(17)
30
+
gauge.FlushReading(sink)
31
+
sink.Flush()
32
+
33
+
Managed
34
+
35
+
Registring a buffered Meter object with a client. This is the fastest method.
36
+
The low latency API is accessed via Client objects. (There's a default global client). The speed is achieved by creating permanent buffering metrics objects for each metric.
The statsd sink also does client side buffering before sending UDP packages and is flushed when asked, or when running full. You can set the max size of the UDP datagrams created.
0 commit comments