I would like to have a generic function/method in my code to be able to send events to dogstatsd.
I would like to be able to provide to the callers of this function/method the choice of alerting/priority level they want to use.

Something like this:

func (dds DataDogSVC) SendEvent(componentName string, eventName string, eventDescription string, extraTags []string, alertType statsd.EventAlertType) error

Unfortunately, I cannot do this because eventAlertType is not an exported type. (For reference, @Jasrags mentions this too in this PR: #19)

Right now, the method I defined looks like:

func (dds DataDogSVC) SendEvent(componentName string, eventName string, eventDescription string, extraTags []string, alertType string) error {
	eventAlertType := statsd.Info
	if alertType == "warning" {
		eventAlertType = statsd.Warning
	} else if alertType == "error" {
		eventAlertType = statsd.Error
	} else if alertType == "success" {
		eventAlertType = statsd.Success
	}
	//create the event and send it to dogstatsd

	return nil
}

I don't think it would be a tremendous change to export eventAlertType and eventPriority and would be a little bit nicer to use in my opinion.

I couldn't verify this from the source code, but my writes with this StatsD client were only successful if I closed the client after writing and instantiating a new client when writing again. Is this how the API of this is supposed to work?

Hi,

How do I easily make a ddtrace.Logger for use with the tracer.WithLogger option? I can't seem to find anything to help me create one from even a standard log. Do I really need to create my own custom wrapper?

It seems like a strange design decision to make that interface into something that the standard log in go doesn't implement out of the box?

Hi.
I'm facing a strange behavior in Flush(). When I run the code below, it doesn't finish flushing then results in deadlock failure.
https://play.golang.org/p/90sBE2ed9dV
Can someone help?

I'm investigating some packet drops in dogstatsd, which are caused by a producer that generates a lot of packets, and uses statsd.NewBuffered.

Because this system generates a lot of statsd packets, we (naively) assumed that a buffered statsd client would take load off of dogstatsd. However, we noticed that packets would get dropped frequently, and would follow a step function:

When buffering is enabled, the statsd client will periodically flush its entire internal buffer every 100 milliseconds, which can easily overload dogstatsd, forcing the kernel to drop packets. I think the primary advantage of buffering is to build up a packet so that it's as close to OptimalPayloadSize as it can be, but once we have a packet big enough to flush, it should be flushed so that there's a smoother distribution of packet sends.

Tags are a slice of strings in the documentation, but datadog-go documentation does not mention valid values for tags. datadog-go removes newlines from tags, but does not remove/escape other invalid characters like comma (,). Comma in tag value will be interpreted as multiple tags since tags are comma-separated in the UDP datagrams.

The page at https://docs.datadoghq.com/developers/guide/what-best-practices-are-recommended-for-naming-metrics-and-tags/ lists recommeded practice for naming tags, perhaps datadog-go should provide a function to sanitize the tag values according to those rules?

If a client is buffered, the buffer is not flushed when Close is called, leading to potential data loss.

12 factor apps use environment variables for configuration. This is also the approach you recommend for setting up Datadog in Kubernetes.

Even when we aren't using the Datadog Agent (eg. in dev environments and in local development), we would like to leave all the metrics sending code mostly unchanged. Since we aren't running the agent, DD_AGENT_HOST is left empty or unset. When we run statsd.New and pass in an empty string so the statsd client gets config from environment variables, if no environment variables are set, we get an error.

When statsd.New can't start because it can't find any environment variables like DD_AGENT_HOST, we'd like to just switch to the NoOpClient so all the code is unchanged and the app can still run. But you don't provide a way to detect this case, so we have to pre-emptively check the same environment variables you check, which breaks the abstraction.

A few ways to fix this:

• default to 127.0.0.1:8125 if the address isn't set in any other way - that way we don't have to make any changes, and for many people it would "just work"

• export an error representing cases where no address is set - that way we could check for this case explicitly

I can see that public statsd.Client methods are generally designed to be no-ops if the Client is nil. This has been a convenient way for us to disable Datadog e.g. for testing.

When coming back to this library after a while to double-check that this is indeed consistent and intended behavior, I noticed a test, TestNilSafe, that confirmed that this is intentional. However, I also discovered that there are several public methods, overlooked by TestNilSafe, that do not work if the client is nil:

• SetWriteTimeout
• Flush
• ServiceCheck
• SimpleServiceCheck

I figure that, for completeness, all of these should be fixed up – particularly the service checks...

Get this when trying to start the Tracer:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x4 pc=0x123e4]
goroutine 1 [running]:
xxxx/vendor/github.com/DataDog/datadog-go/statsd.(*Client).writeMetricUnsafe(0xd282a0, 0x1, 0x0, 0x0, 0xcf67e0, 0x4, 0x6, 0x57161e, 0x16, 0x0, ...)
        xxxxxxxxxxx/vendor/github.com/DataDog/datadog-go/statsd/statsd.go:442 +0x70
xxxx/vendor/github.com/DataDog/datadog-go/statsd.(*Client).addMetric(0xd282a0, 0x1, 0x0, 0x0, 0xcf67e0, 0x4, 0x6, 0x57161e, 0x16, 0x0, ...)
        xxxxxxxxxxx/vendor/github.com/DataDog/datadog-go/statsd/statsd.go:476 +0x64
xxxx/vendor/github.com/DataDog/datadog-go/statsd.(*Client).Count(0xd282a0, 0x57161e, 0x16, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x3ff00000, ...)
        xxxxxxxxxxx/vendor/github.com/DataDog/datadog-go/statsd/statsd.go:491 +0xb0
xxxx/vendor/github.com/DataDog/datadog-go/statsd.(*Client).Incr(0xd282a0, 0x57161e, 0x16, 0x0, 0x0, 0x0, 0x0, 0x3ff00000, 0xa6cb4210, 0x4582c0)
        xxxxxxxxxxx/vendor/github.com/DataDog/datadog-go/statsd/statsd.go:511 +0x5c
xxxx/vendor/gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer.newTracer(0xcc1de4, 0x1, 0x1, 0x6f)
        xxxxxxxxxxx/vendor/gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer/tracer.go:175 +0x7c
xxxx/vendor/gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer.Start(0xcc1de4, 0x1, 0x1)
        xxxxxxxxxxx/vendor/gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer/tracer.go:96 +0x40
main.main()
        xxxxxxxxxxx

can we get an client for the http interface in addition to the statsd client. I'm happy to do it myself, as long as it's something we want

There are two libraries supporting DataDog in the OpenTelemetry-Go contrib repo:

open-telemetry/opentelemetry-go-contrib#22
open-telemetry/opentelemetry-go-contrib#10

We're willing to move these into a Datadog-owned repository, just let us know.

Hi,

I am trying to use the distributions metric type, but this seems not to be documented in the DD statsD documentation https://docs.datadoghq.com/developers/dogstatsd/

I have tried, reading the code, to send the request directly to the DD statsD daemon but they do not appear in my DD dashboard.

Could you help me getting the feature to work?

Thank you

If I create a client with the Namespace set then all metrics will have this prefixed to the metric name. This includes the datadog.dogstatsd.* telemetry metrics as well as my application specific metrics. My assumption is that these "new" metrics will be considered custom (not free), as they have a different name. So I can either use the namespace feature or have custom (free) telemetry stats, but not both. This seems like a design limitation in the current implementation. My proposal would be a fix in which telemetry stats should not have the namespace prefixed to them.

UDP packets have a max length of ~64K, but the buffering logic in statsd.NewBuffered doesn't make any effort to keep single messages below this length.

The DataDog Java statsd client provides an interface for a NoopStatsD Client (https://github.com/DataDog/java-dogstatsd-client/blob/master/src/main/java/com/timgroup/statsd/NoOpStatsDClient.java)

This request, is requesting a similar interface to aid with testing. Having a NoopClient, will allow us to stub the client, when we are unit testing our buisness code, and or record statsd to ensure delivery (maybe?).

Hi, is it possible to call statsd.new only once and reuse that client for the whole application lifetime?

I seem to randomly run into sigsegv: segmentation violation panic on client.push after a few hour of running my application.

I'm using a singleton pattern with sync.once, if that helps

Calling profiler.Stop() if the profiler is unable to submit profiles hangs the shutdown process

I've encountered what I believe to be a deadlock in the Close() logic. When the main goroutine is closing, the mutex for the Client is acquired, we send a signal to all other goroutines to stop, then we wait for those goroutines to stop: https://github.com/DataDog/datadog-go/blob/master/statsd/statsd.go#L547-L555

func (c *Client) Close() error {
	if c == nil {
		return ErrNoClient
	}
	c.Lock() // <- acquire the lock here
	defer c.Unlock()
	select {
	case <-c.stop:
		return nil
	default:
	}
	close(c.stop)
	c.wg.Wait()

However, in the watch() goroutine, its possible for the ticker to fire after the main thread has acquired the mutex, but before the stop channel is closed. This means that the watch() goroutine will also try and acquire the same mutex here: https://github.com/DataDog/datadog-go/blob/master/statsd/statsd.go#L334 and block.

func (c *Client) watch() {
	ticker := time.NewTicker(c.flushTime)

	for {
		select {
		case <-ticker.C:
			c.Lock() // <- This blocks because the main goroutine holds the lock

Since the main goroutine waits for the watch() goroutine to exit here: https://github.com/DataDog/datadog-go/blob/master/statsd/statsd.go#L555, we have a deadlock.

func (c *Client) Close() error {
	if c == nil {
		return ErrNoClient
	}
	c.Lock() // <- acquire the lock here
	defer c.Unlock()
	select {
	case <-c.stop:
		return nil
	default:
	}
	close(c.stop)
	c.wg.Wait() # <- This deadlocks because `watch()` is waiting for c.Lock() to be released

func (c *Client) Count(name string, value int64, tags []string, rate float64) error

Count tracks how many times something happened per second. 

The relationship between value and rate is unspecified. Are they both used? How do they interact? If I'm just counting an event, usually I'm counting "total occurrences", not "times per second", because I'll compute times per second later.

Reading elsewhere suggests that "rate" should be a 0-1 value to control how often to actually send packets, so, a rate of "0.5" would indicate that 50% of packets should actually be sent, but I can't find anything in the datadog-go/statsd documentation that makes this explicit.

If not, when a client goes out of scope, there are 3 goroutines leaked:

• watch
• telemetry
• sendLoop

Currently there are no go.mod and go.sum files in the repo. go mod is currently adding v<version>-incompatible tags to go.mod files but they are prone to breaking whenever we go get -u the dependency in modules mode.

It'd be very helpful to have Go Modules support to make dependency management more deterministic.

"rate argument should normally be 1 or less than that, e.g. 0.1 if you want to only send every 10th call"
maybe even better call the argument sampleRate

Currently the "optimal" payload size is set to 1432 for UDP even if both statsd client and agent are running on the same host.

Using an MTU of slightly less than 1500 is a pretty conservative approach, appropriate at best for sending UDP datagrams over the internet or heterogeneous networks. The argument that fragmented UDP packets are completely lost if any one of their fragments is lost, while technically correct, is already unlikely to be a real factor in properly run datacenter networks and, even more so, when the communication happens purely over localhost.

On my mac, the localhost MTU defaults to 16K. On linux it also used to default to 16K, but has been 64K for quite a few years. In Windows the loopback MTU seems to be basically unlimited. On the BSDs I can only offer anecdotal evidence that the loopback MTU defaults to 16K (in line with that of macs).

I think it would be safe to raise the UDP MTU to slightly less than 16K if the agent address resolves to a loopback address, or even better to whatever number is returned by net.Interface.MTU for the loopback interface. This would bring benefits as it would cut down by an order of magnitude the number of syscalls made by the client (and by the agent).

In a nutshell, the proposed change would be adding here something along the lines of:

	if o.MaxBytesPerPayload == 0 {
		if isLoopback(c.addrOption) {
			o.MaxBytesPerPayload = OptimalLoopbackUDPPayloadSize // e.g. slightly less than 16K
		} else {   
			o.MaxBytesPerPayload = OptimalUDPPayloadSize
		}
	}

where isLoopback would parse/resolve the address and use net.IP.IsLoopback to check if the agent is running on loopback. This won't unfortunately cover the rather common case of client and agent being on the same host, but not talking via loopback (e.g. different pods on the same host in kubernetes) but it's a start (we could also further extend this to check if the IP of the agent matches one of the IPs of the interfaces of the host the client is running on, but this is a bit more sketchy so maybe it should be done later).

We would probably also need to change the buffer size of dogstatsd from 8K to 16K (even better, should be raised to 64K since MaxUDPPayloadSize is ~64K) and lowering dogstatsd_queue_size as needed to maintain the same memory usage. If this is not possible right away, it should be still feasible to raise the client's loopback optimal UDP payload size to slightly less than 8K. Note also that there seem to be no reason to not simply hardcode a 64K buffer for receiving UDP messages in dogstatsd, since we use only a single buffer: I opened a draft PR for that here.

Hello,

The API has a public function

func NewWithWriter(w statsdWriter) (*Client, error) {
	client := &Client{writer: w, SkipErrors: false}
	return client, nil
}

but statsdWriter is a private type, so only the package and tests can use this function. So, either make NewWithWriter private (rename to newWithWriter), or expose statsdWriter.

type statsdWriter interface {
	Write(data []byte) (n int, err error)
	SetWriteTimeout(time.Duration) error
	Close() error
}

With the later, one would then write TCP writers, and even direct to datadog via HTTP API writers.

happy to whip up a PR as well, but I wanted to get thoughts before doing that.

regards,

n

func Time(name, fn func()) that reports how long something took

... I can make a PR for it unless there is a reason this is not wanted @truthbk ...

According to the documentation, the way to pass a UDS path to statsd.New is by prefixing the string with unix://. However, an extra slash is passed down because of

The global default math/rand generator is protected by a mutex. In a highly concurrent application making lots of calls to the DD library and making use of the rate parameter to the API sample metrics so as to not drop packets and overload the statsd server, the use of rand.Float64 in statsd.Client.send can become a bottleneck.

Ideally, there would be an alternative API that allows the caller to pass in goroutine local math.rand.Rand, which is not protected by a mutex.

In the example code the tag is added like c.Tags = append(c.Tags, "us-east-1a") however if I understand correctly, this should be a pair.

I've checked the example in python library, and found the tag is : splitted string, making it a key and a value.

Is go-version library having special way setting tags or is it a typo?

I run my application with -race and found out a race condition when setting the namespace as per the docs:

// Create the client
c, err := statsd.New("127.0.0.1:8125")
...
// Prefix every metric with the app name
c.Namespace = "flubber."

I wrote a wee snippet to reproduce the problem:

package main

import (
	"log"
	"time"

	"github.com/DataDog/datadog-go/statsd"
)

func main() {
	client, err := statsd.New(
		"localhost:8888")
	if err != nil {
		log.Println("could not get datadog client")
		panic("could not get datadog client:" + err.Error())
	}

	client.Namespace = "another namespace"

	time.Sleep(time.Minute)
}

go run -race main.go

$ go run -race main.go
==================
WARNING: DATA RACE
Read at 0x00c000146008 by goroutine 19:
  github.com/DataDog/datadog-go/statsd.(*Client).send()
      /Users/aqueiroz/devel/go/pkg/mod/github.com/!data!dog/[email protected]+incompatible/statsd/statsd.go:467 +0x99
  github.com/DataDog/datadog-go/statsd.(*Client).telemetry()
      /Users/aqueiroz/devel/go/pkg/mod/github.com/!data!dog/[email protected]+incompatible/statsd/statsd.go:402 +0x252
  github.com/DataDog/datadog-go/statsd.newWithWriter.func2()
      /Users/aqueiroz/devel/go/pkg/mod/github.com/!data!dog/[email protected]+incompatible/statsd/statsd.go:357 +0xa7

Previous write at 0x00c000146008 by main goroutine:
  main.main()
      /Users/aqueiroz/devel/github.com/blacklane/ride-matcher/ddrace/main.go:20 +0x85

Goroutine 19 (running) created at:
  github.com/DataDog/datadog-go/statsd.newWithWriter()
      /Users/aqueiroz/devel/go/pkg/mod/github.com/!data!dog/[email protected]+incompatible/statsd/statsd.go:354 +0xfe6
  github.com/DataDog/datadog-go/statsd.New()
      /Users/aqueiroz/devel/go/pkg/mod/github.com/!data!dog/[email protected]+incompatible/statsd/statsd.go:272 +0x2b4
  main.main()
      /Users/aqueiroz/devel/github.com/blacklane/ride-matcher/ddrace/main.go:11 +0x58
==================
Found 1 data race(s)
exit status 66

Using statsd.WithNamespace instead of setting it latter on does not cause the race condition:

	client, err := statsd.New(
		"localhost:8888",
		statsd.WithNamespace("myApp."),
	)

Also statsd.Client states it's goroutine safe.

I'd suggest to do not export the Namespace field.

However it'd be a breaking change, so maybe deprecate the field, adjust the dos and put a warning on the statsd.Client doc?

Hello,

Could you guys please tag a 1.1.0 release? I am using glide and currently i have to bind my dep to a sha to pick up any new code. A 1.1.0 tag would help greatly! Thanks!

The last release was last April. Since then Unix Domain Socket support was added. Time for a new release?

Since the sockets are supported for both StatsD and APM setting DD_AGENT_HOST would break either DogStatd or APM as they both have different paths. As per the helm chart the socket paths are as followed /var/run/datadog/apm.socket and /var/run/datadog/dsd.socket.

Hi,

Is there an option to cancel the host resolving on the statsd creator?
My code running on docker while the agent running on another docker. So the container is not always run while the agent is already exists and we get an error that the lookup failed and "no such host".

In this case, is there any option to retry the resolving each time metric is send?

Tnx!

Similar to the other methods, it would be nice if the Event, SimpleEvent, ServiceCheck and SimpleServiceCheck methods also accepted a tags parameter. The current API feels inconsistent. And it makes it difficult to include event instance specific tags along with events.

I'm trying to send events using the following code:

r.statasd, err := statsd.New("127.0.0.1:8125")
event := statsd.NewEvent("New version published", 
		fmt.Sprintf("A new version (%d) of %s was deployed to namespace %s, using chart %s. Deploy status - %s", release.Version, release.Name, release.Namespace, release.Chart, status))

	event.Priority = statsd.Normal

	if (status == "DEPLOYED"){
		event.AlertType = statsd.Info
	} else {
		event.AlertType = statsd.Error
	}
	event.Hostname = release.Name

	event.Tags = []string {fmt.Sprintf("namespace:%s", release.Namespace)}

	r.statsd.Event(event)

But for some reason, I don't see the event on Datadog, no relevant logs on the local agent or the statsd (which has no logs :(). Agent is running using the following docker command:

DOCKER_CONTENT_TRUST=1 docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=<> -e DD_DOGSTATSD_NON_LOCAL_TRAFFIC=true -p 8125:8125 datadog/agent:latest

What am I missing?

It appears to be necessary to call Close() on statsd Clients to clean up cpu/memory resources.

How do I check whether a Client has been closed, so I can get a new client if needed?

Please check why Namespace is being ignored on SimpleEvent() calls

Hello,

Can you please tag and version this project?

I am the Debian Maintainer for datadog-go and versioning would help Debian keep up with development.

Somewhat misleading to have something look like it works fine, but it is just an early return because the client is nil.

The comment says This can be increased if your network has a greater MTU or you don't mind UDP datagrams getting fragmented. However, OptimalPayloadSize is a const. This probably should have a way to change it per client. I'm happy to do a PR if there is interest.

Hey there,

I was doing some reading of the codebase and I think stumbled upon a bug in the sendMsg method. Specifically, it seems that the length of the message is only checked if the client is in a buffered mode:

• datadog-go/statsd/statsd.go

  Lines 224 to 228 in 426ff2e

  	if c.bufferLength > 0 {
  	// return an error if message is bigger than OptimalPayloadSize
  	if len(msg) > MaxUDPPayloadSize {
  	return errors.New("message size exceeds MaxUDPPayloadSize")
  	}

Looking at it further, it seems the comment above the length check is at odds with what the code actually codes:

• datadog-go/statsd/statsd.go

  Line 225 in 426ff2e

  // return an error if message is bigger than OptimalPayloadSize

It's hard to know what the expected behavior truly is because the tests aren't currently ran for the function because it's unexported. Even then it seems to be at adds with the code itself:

• datadog-go/statsd/statsd_test.go

  Lines 341 to 351 in 426ff2e

  	func testSendMsg(t *testing.T) {
  	c := Client{bufferLength: 1}
  	err := c.sendMsg(strings.Repeat("x", OptimalPayloadSize))
  	if err != nil {
  	t.Errorf("Expected no error to be returned if message size is smaller or equal to MaxPayloadSize, got: %s", err.Error())
  	}
  	err = c.sendMsg(strings.Repeat("x", OptimalPayloadSize+1))
  	if err == nil {
  	t.Error("Expected error to be returned if message size is bigger that MaxPayloadSize")
  	}
  	}

If you export the function and try to run the test, it results in a panic which is probably why it is unexported:

panic: runtime error: invalid memory address or nil pointer dereference [recovered]
        panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x58 pc=0x7ea3b]

goroutine 26 [running]:
panic(0x17df00, 0xc4200140c0)
        /usr/local/Cellar/go/1.7.4/libexec/src/runtime/panic.go:500 +0x1a1
testing.tRunner.func1(0xc42009c480)
        /usr/local/Cellar/go/1.7.4/libexec/src/testing/testing.go:579 +0x25d
panic(0x17df00, 0xc4200140c0)
        /usr/local/Cellar/go/1.7.4/libexec/src/runtime/panic.go:458 +0x243
github.com/DataDog/datadog-go/statsd.(*Client).flush(0xc4200ae2a0, 0x0, 0x0)
        /Users/theckman/go/src/github.com/DataDog/datadog-go/statsd/statsd.go:201 +0xdb
github.com/DataDog/datadog-go/statsd.(*Client).append(0xc4200ae2a0, 0xc4200a8c00, 0x598, 0xc4200a8c00, 0x598)
        /Users/theckman/go/src/github.com/DataDog/datadog-go/statsd/statsd.go:141 +0xab
github.com/DataDog/datadog-go/statsd.(*Client).sendMsg(0xc4200ae2a0, 0xc4200a8c00, 0x598, 0x0, 0x0)
        /Users/theckman/go/src/github.com/DataDog/datadog-go/statsd/statsd.go:229 +0x124
github.com/DataDog/datadog-go/statsd.TestSendMsg(0xc42009c480)
        /Users/theckman/go/src/github.com/DataDog/datadog-go/statsd/statsd_test.go:343 +0xee
testing.tRunner(0xc42009c480, 0x1be4e8)
        /usr/local/Cellar/go/1.7.4/libexec/src/testing/testing.go:610 +0x81
created by testing.(*T).Run
        /usr/local/Cellar/go/1.7.4/libexec/src/testing/testing.go:646 +0x2ec
exit status 2

In short, I think the sendMsg method should check the length of the message whether or not it's a buffered client. Secondly, I think either the function's logic needs to be updated or the comment/tests need to be updated to match the expected behavior. Lastly, I think the changes in #22 should also be applied to sendMsg() / append().

go get github.com/DataDog/datadog-go/statsd produces the following error:

murmur/signalsd/src/github.com/DataDog/datadog-go/statsd/statsd.go:358: e.text undefined (type Event has no field or method text, but does have Text)

Hello,

I am observing no metrics being sent after upgrading to version 3.4.1 from 2.3.0.

I wrote a simple test to reproduce this behaviour and I am using Wireshark to observe the traffic I send. I can see via Wireshark that on version 3.4.1. the metrics are not being sent, whereas they are on 2.3.0.

If on version 3.4.1 I add a client.Flush() (as commented out in the below test) the metrics are sent. I expected the closing of the client to flush the metrics, as seen in the following lines
https://github.com/DataDog/datadog-go/blob/master/statsd/statsd.go#L568-L569'

Is this to be expected?

Go version: 1.14.0

Thanks,
Fraser

import (
	"testing"

	"github.com/DataDog/datadog-go/statsd"
)

func Test_BasicMetric(t *testing.T){
	client, err := statsd.New("127.0.0.1:8125")
	if err != nil {
		t.Fatalf("failed to create client: %s", err)
	}

	if err := client.Count("name", 1, []string{"tag"}, 1); err != nil {
		t.Fatalf("failed to send metric: %s", err)
	}

	// _ = client.Flush()

	if err := client.Close(); err != nil {
		t.Fatalf("failed to close client: %s", err)
	}
}

We've been using datadog in a kubernetes environment. We have datadog agent running as a daemonset and the client in our go apps running inside kubes on the cluster. However if the agent restarts (due to a daemonset config change, upgrade, etc) we don't see any metrics flowing even after the agent comes back online. It would be great if the client could automatically attempt to reconnect in the background so we don't have to roll the app to get stats flowing again.

Hi, in the README.md the asynchronous mode is recommended, but I couldn't find the WithAsyncUDS option mentioned. Is it missing from the code?

From https://github.com/DataDog/datadog-go#blocking-vs-asynchronous-behavior:

Currently, in 2.x, "blocking" is the default behavior to ensure backward compatibility. To use the "asynchronous" behavior, use the statsd.WithAsyncUDS() option. We recommend enabling the "asynchronous" mode.

If there're no plans to implement this option, it is safe to run a call in a goroutine if I don't care about the error?

go statsd.Incr(...)

Thanks!

Howdy, I'm using dogstatsd-go 3.3.0 and seeing this error:

ERROR | (pkg/dogstatsd/server.go:298 in parsePacket) | Dogstatsd: error parsing metrics: invalid metric value for
"faktory.jobs.BareStripe::WebhookReceiverWorker.perform:23.737378|ms|#env:production,env:production,env:production,env:production,env:production,queue:import_stripe_webhooks,jobtype:BareStripe::WebhookReceiverWorker"

(the env:production repetition is a separate issue)

Any idea why the API is sending metric lines that can't be parsed by the agent? I would expect either an error or for this API to escape any illegal characters before sending over the network. I couldn't find any documentation in the README or linked that talks about allowed characters in metric and tag names/values and I couldn't find any code which escaped characters in this repo.

Hello,

This new code landed in v3.0.0

Telemetry was first introduced in this PR: #91

This is the specific commit on the PR where the telemetry initially landed: b4f4ba0

These lines were ultimately added in master:

There is no mention in the PR description of the concept of telemetry being added. Furthermore, there are no documentations or configs mentioning telemetry.

I found these metrics being emitted during a read through of a TCP dump of the statsd traffic on our application:

sudo tcpdump -i any -n udp dst port 8125 -lev -s 0 -A
datadog.dogstatsd.client.packets_sent:1|c|#client:go,transport:udp
datadog.dogstatsd.client.bytes_sent:575|c|#client:go,transport:udp
datadog.dogstatsd.client.packets_dropped:1|c|#client:go,transport:udp
datadog.dogstatsd.client.bytes_dropped:521|c|#client:go,transport:udp
datadog.dogstatsd.client.packets_dropped_queue:0|c|#client:go,transport:udp
datadog.dogstatsd.client.bytes_dropped_queue:0|c|#client:go,transport:udp
datadog.dogstatsd.client.packets_dropped_writer:1|c|#client:go,transport:udp
datadog.dogstatsd.client.bytes_dropped_writer:521|c|#client:go,transport:udp

There should to be configuration available to turn this telemetry off, but there isn't, as far as I can tell.

Regards,
Cody

Is there any workaround this issue? or am I doing something wrong here?

I am using test code as it is :

`c, err := statsd.New("127.0.0.1:8125")
if err != nil {
log.Fatal(err)
}
// Prefix every metric with the app name
c.Namespace = "flubber."
// Send the EC2 availability zone as a tag with every metric
c.Tags = append(c.Tags, "us-east-1a")

	// Do some metrics!
	err = c.Gauge("request.queue_depth", 12, nil, 1)`

Response:

DEBUG: Bad line: 12.000000,g,#us-east-1a in msg "flubber.request.queue_depth:12.000000|g|#us-east-1a"

I am running this statsd agent locally (https://github.com/etsy/statsd, https://anomaly.io/statsd-install-and-config/)