villasys.blogg.se - Statsd exporter

#Statsd exporter how to
#Statsd exporter code

In the short term we can focus the initial development of this plugin to encompass the UDP listening functionality and parsing StatsD messages into the well defined OT metrics types while OT metrics are being further discussed and iterated on.

The processor could have default aggregations applied as well as expose aggregation configuration to users via the similarly mentioned "Views API" from above. We will need a way to tell a downstream processor which raw data points should be grouped or not.

These raw OTLP formats are theoretical at this point to my understanding. We would defer aggregation to a processor (notably not exporters) for aggregating the raw OTLP metrics.

Make the statsdreceiver a simple mapper between incoming StatsD messages and raw OTLP Metric formats (key here is simple 1-1 mappings, no aggregation).

I believe this type of configuration has been discussed in several other places and is regarded as a "Views API" that could be some common configuration block/mechanism for reuse across the collector.

We can bake aggregation into the receiver plugin and expose some configuration to the user to be able override some aggregation defaults for the supported StatsD metric types.

There are a couple of potential routes we could take regarding aggregation: Here's a summary of my takeaways from yesterdays discussion please correct me if I misunderstood anything. Do you know of any further examples that might give insight into how they will play into the StatsD mappings?

#Statsd exporter how to

I'm digging more into the Measure and Measurement metric types to understand how to properly use them. The DogStatsD docs say Timers are not directly supported, but Histograms are basically an alias for Timers. I'm less certain about the Timer, Histogram, Set, Meter, and Distribution types outside of it looks like they will be supported through raw measurements. I can't see any immediate value in interpreting the incoming messages as StatsD types and then mapping StatsD types to OpenTelemetry metrics.įrom the Metrics spec I see the pre-aggregated types support counters and gauges, so those seem like natural mappings for the StatsD Gauge and Counter types. # By default a UDP listener endpoint: "host:port " # default "localhost:8125" # The format of the incoming UDP packets encoding: "dogstatsd " # no default until "statsd" is supported and that becomes default? Another options could be to make "dogstatsd" be the defaultįrom an implementation standpoint it seems we can simply parse the incoming StatsD messages directly out to the relevant OpenTelemetry metric types. Which application are you thinking of? I admit being more interested in (1) because it will provide benefit to a larger community of users than (2).

#Statsd exporter code

I wonder if the agent code is somewhat factored to support using only the logic we need, not the entire package.

I believe that using part or all of the DD agent for this purpose makes sense, but again I'm not too familiar with the code. Users may want to export metric data arriving via DogStatsD or other sources (OpenCensus, OTLP, Prometheus) using the Datadog agent code base, which is ordinarily the thing that receives DogStatsD data and transforms it into the protocol used by DD. I imagine such a receiver could be built from scratch pretty easily, just reading from sockets and parsing DogStatsD packets. Whether configured as an agent or a collector, users will send DogStatsD data over UDP or TCP or UNIX sockets. Users may want to receive DogStatsD data, convert into the common representation used in the otel-collector, then take advantage of the OTel collector's facilities such as filtering and remapping, before re-exporting data. I'm assuming there are at least two ways this will be used. I don't know the DD agent code well enough to know if it's meant for re-use in this way. We should talk about what we're trying to achieve, first.