{"id":13581489,"url":"https://github.com/prometheus/statsd_exporter","last_synced_at":"2025-04-06T10:32:31.996Z","repository":{"id":9293354,"uuid":"11129115","full_name":"prometheus/statsd_exporter","owner":"prometheus","description":"StatsD to Prometheus metrics exporter","archived":false,"fork":false,"pushed_at":"2024-09-16T09:35:43.000Z","size":12803,"stargazers_count":915,"open_issues_count":26,"forks_count":230,"subscribers_count":21,"default_branch":"master","last_synced_at":"2024-09-16T11:45:50.518Z","etag":null,"topics":["go","hacktoberfest","metrics","prometheus","prometheus-exporter","statsd","statsd-metrics"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/prometheus.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2013-07-02T16:14:24.000Z","updated_at":"2024-09-15T09:54:32.000Z","dependencies_parsed_at":"2023-09-26T23:09:35.951Z","dependency_job_id":"4623f783-30b8-4a32-8892-41e0a7c89f0f","html_url":"https://github.com/prometheus/statsd_exporter","commit_stats":{"total_commits":642,"total_committers":107,"mean_commits":6.0,"dds":0.8317757009345794,"last_synced_commit":"58769c7b4d128e7ceae1cf8d893260ed5b5afa4d"},"previous_names":["prometheus/statsd_bridge"],"tags_count":63,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/prometheus%2Fstatsd_exporter","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/prometheus%2Fstatsd_exporter/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/prometheus%2Fstatsd_exporter/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/prometheus%2Fstatsd_exporter/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/prometheus","download_url":"https://codeload.github.com/prometheus/statsd_exporter/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247470354,"owners_count":20944146,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["go","hacktoberfest","metrics","prometheus","prometheus-exporter","statsd","statsd-metrics"],"created_at":"2024-08-01T15:02:03.318Z","updated_at":"2025-04-06T10:32:31.402Z","avatar_url":"https://github.com/prometheus.png","language":"Go","funding_links":[],"categories":["Go","Exporters","Repositories"],"sub_categories":["Other monitoring systems"],"readme":"# statsd exporter [![Build Status](https://travis-ci.org/prometheus/statsd_exporter.svg)][travis]\n\n[![CircleCI](https://circleci.com/gh/prometheus/statsd_exporter/tree/master.svg?style=shield)][circleci]\n[![Docker Repository on Quay](https://quay.io/repository/prometheus/statsd-exporter/status)][quay]\n[![Docker Pulls](https://img.shields.io/docker/pulls/prom/statsd-exporter.svg)][hub]\n\n`statsd_exporter` receives StatsD-style metrics and exports them as Prometheus metrics.\n\n## Overview\n\nThe StatsD exporter is a drop-in replacement for StatsD.\nThis exporter translates StatsD metrics to Prometheus metrics via configured mapping rules.\n\nWe recommend using the exporter only as an intermediate solution, and switching to [native Prometheus instrumentation](http://prometheus.io/docs/instrumenting/clientlibs/) in the long term.\nWhile it is common to run centralized StatsD servers, the exporter works best as a [sidecar](https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar).\n\n### Transitioning from an existing StatsD setup\n\nThe relay feature allows for a gradual transition.\n\nIntroduce the exporter by adding it as a sidecar alongside the application instances.\nIn Kubernetes, this means adding it to the [pod](https://kubernetes.io/docs/concepts/workloads/pods/).\nUse the `--statsd.relay.address` to forward metrics to your existing StatsD UDP endpoint.\nRelaying forwards statsd events unmodified, preserving the original metric name and tags in any format.\n\n    +-------------+    +----------+                  +------------+\n    | Application +---\u003e| Exporter +-----------------\u003e|  StatsD    |\n    +-------------+    +----------+                  +------------+\n                              ^\n                              |                      +------------+\n                              +----------------------+ Prometheus |\n                                                     +------------+\n\n### Relaying from StatsD\n\nTo pipe metrics from an existing StatsD environment into Prometheus, configure StatsD's repeater backend to repeat all received metrics to a `statsd_exporter` process.\n\n    +----------+                         +-------------------+                        +--------------+\n    |  StatsD  |---(UDP/TCP repeater)---\u003e|  statsd_exporter  |\u003c---(scrape /metrics)---|  Prometheus  |\n    +----------+                         +-------------------+                        +--------------+\n\nThis allows trying out the exporter with minimal effort, but does not provide the per-instance metrics of the sidecar pattern.\n\n### Tagging Extensions\n\nThe exporter supports Librato, InfluxDB, DogStatsD, and SignalFX-style tags,\nwhich will be converted into Prometheus labels.\n\nFor Librato-style tags, they must be appended to the metric name with a\ndelimiting `#`, as so:\n\n```\nmetric.name#tagName=val,tag2Name=val2:0|c\n```\n\nSee the [statsd-librato-backend README](https://github.com/librato/statsd-librato-backend#tags)\nfor a more complete description.\n\nFor InfluxDB-style tags, they must be appended to the metric name with a\ndelimiting comma, as so:\n\n```\nmetric.name,tagName=val,tag2Name=val2:0|c\n```\n\nSee [this InfluxDB blog post](https://www.influxdata.com/blog/getting-started-with-sending-statsd-metrics-to-telegraf-influxdb/#introducing-influx-statsd)\nfor a larger overview.\n\n\nFor DogStatsD-style tags, they're appended as a `|#` delimited section at the\nend of the metric, as so:\n\n```\nmetric.name:0|c|#tagName:val,tag2Name:val2\n```\n\nSee [Tags](https://docs.datadoghq.com/developers/dogstatsd/data_types/#tagging)\nin the DogStatsD documentation for the concept description and\n[Datagram Format](https://docs.datadoghq.com/developers/dogstatsd/datagram_shell/).\nIf you encounter problems, note that this tagging style is incompatible with\nthe original `statsd` implementation.\nThe exporter also supports [DogStatD extended aggregations](https://github.com/prometheus/statsd_exporter/pull/558) in combination with DogStatsD tags, but not other tagging styles.\n\nFor [SignalFX dimension](https://github.com/signalfx/signalfx-agent/blob/main/docs/monitors/collectd-statsd.md#adding-dimensions-to-statsd-metrics), add the tags to the metric name in square brackets, as so:\n\n```\nmetric.name[tagName=val,tag2Name=val2]:0|c\n```\n\nBe aware: If you mix tag styles (e.g., Librato/InfluxDB with DogStatsD), the exporter will consider this an error and the behavior is undefined.\nAlso, tags without values (`#some_tag`) are not supported and will be ignored.\n\nThe exporter parses all tagging formats by default, but individual tagging formats can be disabled with command line flags:\n```\n--no-statsd.parse-dogstatsd-tags\n--no-statsd.parse-influxdb-tags\n--no-statsd.parse-librato-tags\n--no-statsd.parse-signalfx-tags\n```\n\nBy default, labels explicitly specified in configuration take precedence over labels from tags.\nTo set the label from the statsd event tag, use [`honor_labels`](#honor-labels).\n\n## Building and Running\n\nNOTE: Version 0.7.0 switched to the [kingpin](https://github.com/alecthomas/kingpin) flags library. With this change, flag behaviour is POSIX-ish:\n\n* long flags start with two dashes (`--version`)\n* boolean long flags are disabled by prefixing with no (`--flag-name` is true, `--no-flag-name` is false)\n* multiple short flags can be combined (but there currently is only one)\n* flag processing stops at the first `--`\n* see `--help` for a full list of flags\n\n## Lifecycle API\n\nThe `statsd_exporter` has an optional lifecycle API (disabled by default) that can be used to reload or quit the exporter \nby sending a `PUT` or `POST` request to the `/-/reload` or `/-/quit` endpoints.\n\n## Relay\n\nThe `statsd_exporter` has an optional mode that will buffer and relay incoming statsd lines to a remote server. This is useful to \"tee\" the data when migrating to using the exporter. The relay will flush the buffer at least once per second to avoid delaying delivery of metrics.\n\n## Tests\n\n    $ go test\n\n## Metric Mapping and Configuration\n\nThe `statsd_exporter` can be configured to translate specific dot-separated StatsD\nmetrics into labeled Prometheus metrics via a simple mapping language. The config\nfile is reloaded on SIGHUP.\n\nA mapping definition starts with a line matching the StatsD metric in question,\nwith `*`s acting as wildcards for each dot-separated metric component. The\nlines following the matching expression must contain one `label=\"value\"` pair\neach, and at least define the metric name (label name `name`). The Prometheus\nmetric is then constructed from these labels. `$n`-style references in the\nlabel value are replaced by the n-th wildcard match in the matching line,\nstarting at 1. Multiple matching definitions are separated by one or more empty\nlines. The first mapping rule that matches a StatsD metric wins.\n\nMetrics that don't match any mapping in the configuration file are translated\ninto Prometheus metrics without any labels and with any non-alphanumeric\ncharacters, including periods, translated into underscores.\n\nIn general, the different metric types are translated as follows:\n\n    StatsD gauge   -\u003e Prometheus gauge\n\n    StatsD counter -\u003e Prometheus counter\n\n    StatsD timer, histogram, distribution   -\u003e Prometheus summary or histogram\n\n### Glob matching\n\nThe default (and fastest) `glob` mapping style uses `*` to denote parts of the statsd metric name that may vary.\nThese varying parts can then be referenced in the construction of the Prometheus metric name and labels.\n\nAn example mapping configuration:\n\n```yaml\nmappings:\n- match: \"test.dispatcher.*.*.*\"\n  name: \"dispatcher_events_total\"\n  labels:\n    processor: \"$1\"\n    action: \"$2\"\n    outcome: \"$3\"\n    job: \"test_dispatcher\"\n- match: \"*.signup.*.*\"\n  name: \"signup_events_total\"\n  labels:\n    provider: \"$2\"\n    outcome: \"$3\"\n    job: \"${1}_server\"\n```\n\nThis would transform these example StatsD metrics into Prometheus metrics as\nfollows:\n\n    test.dispatcher.FooProcessor.send.success\n     =\u003e dispatcher_events_total{processor=\"FooProcessor\", action=\"send\", outcome=\"success\", job=\"test_dispatcher\"}\n\n    foo_product.signup.facebook.failure\n     =\u003e signup_events_total{provider=\"facebook\", outcome=\"failure\", job=\"foo_product_server\"}\n\n    test.web-server.foo.bar\n     =\u003e test_web_server_foo_bar{}\n\nEach mapping in the configuration file must define a `name` for the metric. The\nmetric's name can contain `$n`-style references to be replaced by the n-th\nwildcard match in the matching line. That allows for dynamic rewrites, such as:\n\n```yaml\nmappings:\n- match: \"test.*.*.counter\"\n  name: \"${2}_total\"\n  labels:\n    provider: \"$1\"\n```\n\nGlob matching offers the best performance for common mappings.\n\n#### Ordering glob rules\n\nList more specific matches before wildcards, from left to right:\n\n    a.b.c\n    a.b.*\n    a.*.d\n    a.*.*\n\nThis avoids unexpected shadowing of later rules, and performance impact from backtracking.\n\nAlternatively, you can disable mapping ordering altogether.\nWith unordered mapping, at each hierarchy level the most specific match wins.\nThis has the same effect as using the recommended ordering.\n\n### Regular expression matching\n\nThe `regex` mapping style uses regular expressions to match the full statsd metric name.\nUse it if the glob mapping is not flexible enough to pull structured data from the available statsd metric names.\n\nRegular expression matching is significantly slower than glob mapping as all mappings must be tested in order.\nBecause of this, **regex mappings are only executed after all glob mappings**.\nIn other words, glob mappings take preference over regex matches, irrespective of the order in which they are specified.\nRegular expression matches are always evaluated in order, and the first match wins.\n\nThe metric name can also contain references to regex matches. The mapping above\ncould be written as:\n\n```yaml\nmappings:\n- match: \"test\\\\.(\\\\w+)\\\\.(\\\\w+)\\\\.counter\"\n  match_type: regex\n  name: \"${2}_total\"\n  labels:\n    provider: \"$1\"\n- match: \"(.*)\\\\.(.*)--(.*)\\\\.status\\.(.*)\\\\.count\"\n  match_type: regex\n  name: \"request_total\"\n  labels:\n    hostname: \"$1\"\n    exec: \"$2\"\n    protocol: \"$3\"\n    code: \"$4\"\n```\n\nBe aware about yaml escape rules as a mapping like the following one will not work.\n```yaml\nmappings:\n- match: \"test\\\\.(\\w+)\\\\.(\\w+)\\\\.counter\"\n  match_type: regex\n  name: \"${2}_total\"\n  labels:\n    provider: \"$1\"\n```\n\n#### Special match groups\n\nWhen using regex, the match group `0` is the full match and can be used to attach labels to the metric.\nExample:\n\n```yaml\nmappings:\n- match: \".+\"\n  match_type: regex\n  name: \"$0\"\n  labels:\n    statsd_metric_name: \"$0\"\n```\n\nIf a metric `my.statsd_counter` is received, the metric name will **still** be mapped to `my_statsd_counter` (Prometheus compatible name).\nBut the metric will also have the label `statsd_metric_name` with the value `my.statsd_counter` (unchanged value).\n\nNote: If you use the `match` like the example (i.e. `.+`), be aware that it will be a \"catch-all\" block. So it should come at the very end of the mapping list.\n\nThe same is not achievable with glob matching, for more details check [this issue](https://github.com/prometheus/statsd_exporter/issues/444).\n\n### Naming, labels, and help\n\nPlease note that metrics with the same name must also have the same set of\nlabel names.\n\nIf the default metric help text is insufficient for your needs you may use the YAML\nconfiguration to specify a custom help text for each mapping:\n\n```yaml\nmappings:\n- match: \"http.request.*\"\n  help: \"Total number of http requests\"\n  name: \"http_requests_total\"\n  labels:\n    code: \"$1\"\n```\n\n### Honor labels\n\nBy default, labels specified in the mapping configuration take precedence over tags in the statsd event.\n\nTo set the label value to the original tag value, if present, specify `honor_labels: true` in the mapping configuration.\nIn this case, the label specified in the mapping acts as a default.\n\n### StatsD timers and distributions\n\nBy default, statsd timers and distributions (collectively \"observers\") are\nrepresented as a Prometheus summary with quantiles. You may optionally\nconfigure the [quantiles and acceptable\nerror](https://prometheus.io/docs/practices/histograms/#quantiles), as well\nas adjusting how the summary metric is aggregated:\n\n```yaml\nmappings:\n- match: \"test.timing.*.*.*\"\n  observer_type: summary\n  name: \"my_timer\"\n  labels:\n    provider: \"$2\"\n    outcome: \"$3\"\n    job: \"${1}_server\"\n  summary_options:\n    quantiles:\n      - quantile: 0.99\n        error: 0.001\n      - quantile: 0.95\n        error: 0.01\n      - quantile: 0.9\n        error: 0.05\n      - quantile: 0.5\n        error: 0.005\n    max_age: 30s\n    age_buckets: 3\n    buf_cap: 1000\n```\n\nThe default quantiles are 0.99, 0.9, and 0.5.\n\nThe default summary age is 10 minutes, the default number of buckets\nis 5 and the default buffer size is 500.\nSee also the [`golang_client` docs](https://godoc.org/github.com/prometheus/client_golang/prometheus#SummaryOpts).\nThe `max_summary_age` corresponds to `SummaryOptions.MaxAge`, `summary_age_buckets` to `SummaryOptions.AgeBuckets` and `stream_buffer_size` to `SummaryOptions.BufCap`.\n\nIn the configuration, one may also set the observer type to \"histogram\". For example,\nto set the observer type for a single timer metric:\n\n```yaml\nmappings:\n- match: \"test.timing.*.*.*\"\n  observer_type: histogram\n  histogram_options:\n    buckets: [ 0.01, 0.025, 0.05, 0.1 ]\n    native_histogram_bucket_factor: 1.1\n    native_histogram_max_buckets: 256\n  name: \"my_timer\"\n  labels:\n    provider: \"$2\"\n    outcome: \"$3\"\n    job: \"${1}_server\"\n```\n\nIf not set, then the default\n[Prometheus client \nvalues](https://godoc.org/github.com/prometheus/client_golang/prometheus#pkg-variables) \nare used for the histogram buckets:\n`[.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10]`.\n`+Inf` is added automatically.\nIf your Prometheus server is enabled to scrape native histograms (v2.40.0+), \nthen you can set the `native_histogram_bucket_factor` to configure precision of the\nbuckets in the sparse histogram. More about this in the original [client_golang docs](https://github.com/prometheus/client_golang/blob/449b46435075e6e069e05af920fe028b941033cf/prometheus/histogram.go#L399-L430).\nAlso, a configuration of the maximum number of buckets can be set with `native_histogram_max_buckets`, this\navoids the histograms to grow too large in memory. More about this in the original [client_golang docs](https://github.com/prometheus/client_golang/blob/449b46435075e6e069e05af920fe028b941033cf/prometheus/histogram.go#L443-L467).\n\n`observer_type` is only used when the statsd metric type is a timer, histogram, or distribution.\n`buckets` is only used when the statsd metric type is one of these, and the `observer_type` is set to `histogram`.\n\nTimers will be accepted with the `ms` statsd type.\nStatsd timer data is transmitted in milliseconds, while Prometheus expects the unit to be seconds.\nThe exporter converts all timer observations to seconds.\n\nHistogram and distribution events (`h` and `d` metric type) are not subject to unit conversion.\n\n### DogStatsD Client Behavior\n\n#### `timed()` decorator\n\nThe DogStatsD client's [timed](https://datadogpy.readthedocs.io/en/latest/#datadog.threadstats.base.ThreadStats.timed) decorator emits the metric in seconds but uses the `ms` type.\nSet [`use_ms=True`](https://datadogpy.readthedocs.io/en/latest/index.html?highlight=use_ms) to send the correct units.\n\n### Regular expression matching\n\nAnother capability when using YAML configuration is the ability to define matches\nusing raw regular expressions as opposed to the default globbing style of match.\nThis may allow for pulling structured data from otherwise poorly named statsd\nmetrics AND allow for more precise targetting of match rules. When no `match_type`\nparameter is specified the default value of `glob` will be assumed:\n\n```yaml\nmappings:\n- match: \"(.*)\\\\.(.*)--(.*)\\\\.status\\\\.(.*)\\\\.count\"\n  match_type: regex\n  name: \"request_total\"\n  labels:\n    hostname: \"$1\"\n    exec: \"$2\"\n    protocol: \"$3\"\n    code: \"$4\"\n```\n\n### Global defaults\n\nOne may also set defaults for the observer type, histogram options, summary options, and match type.\nThese will be used by all mappings that do not define them.\n\nAn option that can only be configured in `defaults` is `glob_disable_ordering`, which is `false` if omitted.\nBy setting this to `true`, `glob` match type will not honor the occurance of rules in the mapping rules file and always treat `*` as lower priority than a concrete string.\n\nSetting `buckets` or `quantiles` in the defaults is deprecated in favor of `histogram_options` and `summary_options`, which will override the deprecated values.\n\nIf `summary_options` is present in a mapping config, it will only override the fields set in the mapping. Unset fields in the mapping will take the values from the defaults. \n\n```yaml\ndefaults:\n  observer_type: histogram\n  histogram_options:\n    buckets: [.005, .01, .025, .05, .1, .25, .5, 1, 2.5 ]\n    native_histogram_bucket_factor: 1.1\n    native_histogram_max_buckets: 256\n  summary_options:\n    quantiles:\n      - quantile: 0.99\n        error: 0.001\n      - quantile: 0.95\n        error: 0.01\n      - quantile: 0.9\n        error: 0.05\n      - quantile: 0.5\n        error: 0.005\n    max_age: 5m\n    age_buckets: 2\n    buf_cap: 1000\n  match_type: glob\n  glob_disable_ordering: false\n  ttl: 0 # metrics do not expire\nmappings:\n# This will be a histogram using the buckets set in `defaults`.\n- match: \"test.timing.*.*.*\"\n  name: \"my_timer\"\n  labels:\n    provider: \"$2\"\n    outcome: \"$3\"\n    job: \"${1}_server\"\n# This will be a summary using the summary_options set in `defaults`\n- match: \"other.distribution.*.*.*\"\n  observer_type: summary\n  name: \"other_distribution\"\n  labels:\n    provider: \"$2\"\n    outcome: \"$3\"\n    job: \"${1}_server_other\"\n```\n\n### `drop` action\n\nYou may also drop metrics by specifying a \"drop\" action on a match. For\nexample:\n\n```yaml\nmappings:\n# This metric would match as normal.\n- match: \"test.timing.*.*.*\"\n  name: \"my_timer\"\n  labels:\n    provider: \"$2\"\n    outcome: \"$3\"\n    job: \"${1}_server\"\n# Any metric not matched will be dropped because \".\" matches all metrics.\n- match: \".\"\n  match_type: regex\n  action: drop\n  name: \"dropped\"\n```\n\nYou can drop any metric using the normal match syntax.\nThe default action is \"map\" which does the normal metrics mapping.\n\n### Explicit metric type mapping\n\nStatsD allows emitting of different metric types under the same metric name,\nbut the Prometheus client library can't merge those. For this use-case the\nmapping definition allows you to specify which metric type to match:\n\n```\nmappings:\n- match: \"test.foo.*\"\n  name: \"test_foo\"\n  match_metric_type: counter\n  labels:\n    provider: \"$1\"\n```\n\nPossible values for `match_metric_type` are `gauge`, `counter` and `observer`.\n\n### Mapping cache size and cache replacement policy\n\nThere is a cache used to improve the performance of the metric mapping, that can greatly improvement performance.\nThe cache has a default maximum of 1000 unique statsd metric names -\u003e prometheus metrics mappings that it can store.\nThis maximum can be adjusted using the `statsd.cache-size` flag.\n\nIf the maximum is reached, entries are by default rotated using the [least recently used replacement policy](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)). This strategy is optimal when memory is constrained as only the most recent entries are retained.\n\nAlternatively, you can choose a [random-replacement cache strategy](https://en.wikipedia.org/wiki/Cache_replacement_policies#Random_replacement_(RR)). This is less optimal if the cache is smaller than the cacheable set, but requires less locking. Use this for very high throughput, but make sure to allow for a cache that holds all metrics.\n\nThe optimal cache size is determined by the cardinality of the _incoming_ metrics.\n\n### Time series expiration\n\nThe `ttl` parameter can be used to define the expiration time for stale metrics.\nThe value is a time duration with valid time units: \"ns\", \"us\" (or \"µs\"),\n\"ms\", \"s\", \"m\", \"h\". For example, `ttl: 1m20s`. `0` value is used to indicate\nmetrics that do not expire.\n\n TTL configuration is stored for each mapped metric name/labels combination\n whenever new samples are received. This means that you cannot immediately\n expire a metric only by changing the mapping configuration. At least one\n sample must be received for updated mappings to take effect.\n\n### Unit conversions\n\nThe `scale` parameter can be used to define unit conversions for metric values. The value is a floating point number to scale metric values by. This can be useful for converting non-base units (e.g. milliseconds, kilobytes) to base units (e.g. seconds, bytes) as recommended in [prometheus best practices](https://prometheus.io/docs/practices/naming/).\n\n```yaml\nmappings:\n- match: foo.latency_ms\n  name: foo_latency_seconds\n  scale: 0.001\n- match: bar.processed_kb\n  name: bar_processed_bytes\n  scale: 1024\n- match: baz.latency_us\n  name: baz_latency_seconds\n  scale: 1e-6\n```\n\n### Event flushing configuration\n\n Internally `statsd_exporter` runs a goroutine for each network listener (UDP, TCP \u0026 Unix Socket).  These each receive and parse metrics received into an event.  For performance purposes, these events are queued internally and flushed to the main exporter goroutine periodically in batches.  The size of this queue and the flush criteria can be tuned with the `--statsd.event-queue-size`, `--statsd.event-flush-threshold` and `--statsd.event-flush-interval`.  However, the defaults should perform well even for very high traffic environments.\n\n## Using Docker\n\nYou can deploy this exporter using the [prom/statsd-exporter](https://registry.hub.docker.com/r/prom/statsd-exporter) Docker image.\n\nFor example:\n\n```bash\ndocker pull prom/statsd-exporter\n\ndocker run -d -p 9102:9102 -p 9125:9125 -p 9125:9125/udp \\\n        -v $PWD/statsd_mapping.yml:/tmp/statsd_mapping.yml \\\n        prom/statsd-exporter --statsd.mapping-config=/tmp/statsd_mapping.yml\n```\n\n## Library packages\n\nParts of the implementation of this exporter are available as separate packages.\nSee the [documentation](https://pkg.go.dev/github.com/prometheus/statsd_exporter/pkg) for details.\n\nFor the time being, there are *no stability guarantees* for library interfaces.\nWe will try to call out any significant changes in the [changelog](https://github.com/prometheus/statsd_exporter/blob/master/CHANGELOG.md).\nSemantic versioning of the exporter is based on the impact on users of the exporter, not users of the library.\n\nWe encourage re-use of these packages and welcome [issues](https://github.com/prometheus/statsd_exporter/issues?q=is%3Aopen+is%3Aissue+label%3Alibrary) related to their usability as a library.\n\n[circleci]: https://circleci.com/gh/prometheus/statsd_exporter\n[quay]: https://quay.io/repository/prometheus/statsd-exporter\n[hub]: https://hub.docker.com/r/prom/statsd-exporter/\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fprometheus%2Fstatsd_exporter","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fprometheus%2Fstatsd_exporter","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fprometheus%2Fstatsd_exporter/lists"}