quipo/statsd

Golang StatsD client

statsd's Issues

PrecisionTiming avg,cnt,min,max treated as 'ms', should be 'g'?

We use Collectd to collect the timing stats, and it automatically calculates averages++ based on the timing events from statsd. But because statsd already calculates avg,cnt, max and min before sending the data, we end up with events like x.x.avg.avg, x.x.avg.cnt etc. instead of simply x.x.avg. I am no expert on the StatsD protocol or anything, but are averages, counts etc. really 'timing' measurements?

As it is, we have had to change our version of quipo/statsd so that the PrecisionTiming.Statsd function prints 'c' for count and 'g' instead of 'ms' to get correct measurements.

I wonder if this should be incorporated into the base code somehow?

Enforce create udp4 socket

Right now when I create udp socket there is no option to specify which ip version to use, I've got an issue on one of my servers statd clients sends udp packets over udp6

#
U ::1:13896 -> ::1:8125
environment.p007.p007_1.p007_1.redis.connection.active:1596|g

But statsd just drops these packets, only when I send them over ipv4

echo "sample.gauge:14|g" | nc -u -w0 127.0.0.1 8125

it is ok. Is there any way to specify ip version of client or it needs pull request?

Statsd complains constantly when emitting to Sysdig's StatsD teleport

This is essentially the opposite of #25, but the way Sysdig handles StatsD is to listen for outgoing packets in the kernel, rather than capture them. This is a relatively common use case for containerized applications (i.e. Docker & Kubernetes). By doing it this way, there's no need to instrument a StatsD listener in the container or deal with networking.
More info here:
https://sysdig.com/blog/how-to-collect-statsd-metrics-in-containers/

From looking into it, quipo/statsd use net.Conn, which will log a failure when emitting to no one in particular:
https://github.com/quipo/statsd/blob/master/client.go#L190
[BufferedStatsdClient] 2017/03/28 21:44:41 write udp 127.0.0.1:57858->127.0.0.1:8125: write: connection refused

Using a net.PacketConn and WriteTo() does not produce an error in the same conditions. I was considering a pull request for a sysdig client, but the scope is pretty large for an essentially parallel code path. I was wondering about just replacing the existing net.conn with a net.PacketConn?

checkCount fails if value is zero

The checkCount function evaluates if a count is less than or equal to zero, but raises an ErrInvalidCount error that states ""count is less than 0".

https://github.com/quipo/statsd/blob/3d6a5565f3141ac42f8353d97b2c016da2752006/client.go#L348C1-L354C2

func checkCount(c int64) error {
    if c <= 0 {
        return ErrInvalidCount
    }
    return nil
}

checkCount should be evaluating for c < 0. (Zero is OK).

Buffered client GaugeDelta does not append "+" to positive values.

The non-buffered client does this, but the buffered client does not.

The effect is that statsd interprets it as setting the value of the gauge instead of applying a delta.

Add functionality to handle socket creation errors with "delayed" retries

When running in distributed container environments (Kubernetes) resolving connection to statsd service may not always be successful, due to various reasons (outdated or lagging iptables is one of many). The current implementation does not provide good handling for such edge-case. While consumer of the client library can "re-dial" the socket connection, it has no control over metrics functionality (bar overloading send methods)
It would be very helpful if client library could "handle" this edge-case periodically retry socket connection while dropping current metrics.

Use-case:

1. Client attempts to open socket and receives dial TCP/UDP error
2. Client has the option to log error and continue
3. On every send invocation, client will attempt to reconnect if connection is nil

Expected outcomes:

A. socket creation is successful upon initial socket creation (current model)
B. socket creation failed upon initial attempt, however, subsequently succeeds. Impact: loss of metrics until the socket is re-dialled.
C. socket creation failed upon initial and on all successive attempts. Impact: loss of all metrics.

Seems like the flush call has a race condition

We would need to block the call to flush otherwise we could lose some events between when the events collection gets send to statds and when the collection is reset. Is this intentional?

No support for sub millisecond metrics

It it not possible to send sub millisecond timings, or timings with more than 1millisecond precision.
I suggest: #3

unable to use Incr and PrecisionTiming with the same key

I want to use the same key in both Incr and PrecisionTiming. I assumed that the internal logic would take care of using prefixes like "timers" and other things like ".count", ".avg", etc.
https://github.com/quipo/statsd/blob/master/bufferedclient.go#L147 is calling update because it thinks they are the same type since they are hashed only based on key and not based on type as well.

However, according to https://github.com/quipo/statsd/blob/master/event/precisiontiming.go#L23
they have to be of the same type - which makes sense here.

sending more than one stat (delimitted by \n) for bufferedclient over udp

Currently, buffered client optimizes only at the level of each "key" being updated if many of them come before a flush happens.
However, SendEvent is called for each key, and then an fmt.Fprintf(c.conn...) for every stat in that event. This leads to quite a lot of udp traffic.
The statsd protocol supports sending more than one stat by separating by \n. By doing so, we will reduce the number of fmt.Fprintf(c.conn...) calls, thereby reducing udp traffic.

StatsdClient fails silently when there's no statsd listening on the given address

Neither CreateSocket() nor any of the metrics-generating methods (i.e. Timing(), Incr(), etc) return an error when there's no statsd listening on the address given when creating the client, as can be seen at the following gist: https://gist.github.com/gsalgado/07b8bec3e326582c7174

I'd expect them all to return an error in this case.

Gauge value is being incremented instead of override

Create annotated tags for releases

Hi

It would be great if you tagged the current HEAD with v1.0.0, and in the future, occasionally bump the version and make new tags with new releases. I suggest using the semver.org versioning scheme, where you have major.minor.patch, and you bump the major for incompatible changes and the minor for compatible changes to the API.

add sample rate support?

add sample rate support?

Concurrency usage of client returned by NewStatsdBuffer

@quipo Can StatsdBuffer be used concurrently. Like in a production scenario if we create one instance of StatsdBuffer and use it across the code till the program exists, is it fine?

Gauge increments the metric value

Gauge should set the metric to an absolute value but rather increments the previous value by the set value.

Logger polution

When statsdbuffer.Close() is called, it dumps [BufferedStatsdClient] 2015/03/06 14:38:03 Asked to terminate. Flushing stats before returning. out.

How do I prevent it from doing this?

Deleting collected counters though failed to createsocket or failed to send stats

In buffered client, if failed to createsocket or failed to send events due to connection errors, counters are being deleted in flush function.

GaugeDelta event Stats() should not send an absolute value of 0.

It appears to be copied from the Gauge event, which does not look like the correct logic for GaugeDelta.

fatal error stack overflow when using PrecisionTiming.String()

the code in event/precisiontiming.go has the String function calling the Payload function, and the payload function returns the precision timing object - this is causing infinite recursion.

package main

import "fmt"

type PrecisionTiming struct {
    Name string
}

func (e PrecisionTiming) Payload() interface{} {
    return e
}

func (e PrecisionTiming) String() string {
    return fmt.Sprintf("{Value: %+v}", e.Payload())
}

func main() {
    p := PrecisionTiming{}
    fmt.Printf("%s\n", p)
}

Package broken: *"github.com/quipo/statsd".StatsdBuffer does not implement "github.com/quipo/statsd".Statsd (missing CreateTCPSocket method)

Using StatsdBuffer now breaks my app. Trying to compile:

*"github.com/quipo/statsd".StatsdBuffer does not implement "github.com/quipo/statsd".Statsd (missing CreateTCPSocket method)