StatsD Integration
Drop-in StatsD and DogStatsD compatibility. Change one config value to point your existing clients at TigerOps — zero application code changes, full metric history.
How It Works
Point Your Client to TigerOps
Change the StatsD host in your application configuration to statsd.ingest.atatus.net:8125. TigerOps accepts UDP and TCP StatsD packets with no protocol changes.
Configure Tags (Optional)
TigerOps supports DogStatsD tag format (#key:value) and Telegraf tag format (|#key:value). Existing DogStatsD clients work without modification.
Map Metrics to Dashboards
TigerOps auto-creates dashboards from incoming StatsD metric names using naming convention detection. custom.app.latency becomes a histogram dashboard automatically.
Set Threshold Alerts
Create TigerOps alert rules targeting your StatsD metric names. Alerts fire on counters, gauge thresholds, and timer percentile violations — no PromQL required.
What You Get Out of the Box
Protocol Compatibility
Full compatibility with the original StatsD UDP protocol, DogStatsD extensions (tags, events, service checks), and Telegraf StatsD format. Zero client changes needed.
TCP & UDP Support
Accept metrics over UDP (fire-and-forget) and TCP (guaranteed delivery) on port 8125. TLS encryption is available on port 8126 for secure metric transmission.
Counter & Gauge Tracking
Counters are stored as rate-per-second and cumulative. Gauges retain the last-reported value. TigerOps handles sampling rates (|@0.1) and extrapolates to true values.
Timer Percentiles
Timer metrics are stored as full histograms, not pre-computed percentiles. Query P50, P95, P99, or any other percentile at query time without re-instrumentation.
Tag Cardinality Management
TigerOps enforces configurable tag cardinality limits to prevent metric explosion from high-cardinality tag values like user IDs or request URLs.
Metric Name Mapping
Map legacy StatsD metric names to TigerOps conventions using regex-based rename rules. Normalize naming conventions from multiple applications without code changes.
StatsD Backend Config for TigerOps
Point your StatsD client or local StatsD server at TigerOps in one line.
# Option A: Direct client configuration
# Point your app's StatsD client directly at TigerOps
# Host: statsd.ingest.atatus.net Port: 8125 Protocol: UDP
# Node.js (hot-shots / node-statsd)
const StatsD = require('hot-shots')
const client = new StatsD({
host: 'statsd.ingest.atatus.net',
port: 8125,
globalTags: { env: 'production', service: 'api' }
})
# Python (statsd)
import statsd
c = statsd.StatsClient('statsd.ingest.atatus.net', 8125, prefix='myapp')
# Go (alexcesaro/statsd)
c, _ := statsd.New(
statsd.Address("statsd.ingest.atatus.net:8125"),
statsd.TagsFormat(statsd.Datadog),
statsd.Tags("env", "production", "service", "api"),
)
# Option B: Local StatsD server forwarding to TigerOps
# statsd.js config:
{
"backends": ["statsd-tigerops-backend"],
"tigerops": {
"apiKey": "${TIGEROPS_API_KEY}",
"host": "statsd.ingest.atatus.net",
"port": 8125
},
"flushInterval": 10000,
"percentThreshold": [50, 75, 90, 95, 99]
}
# Telegraf statsd input (recommended for high-throughput)
[[inputs.statsd]]
protocol = "udp"
service_address = ":8125"
percentiles = [50.0, 90.0, 95.0, 99.0]
datadog_extensions = true
[[outputs.http]]
url = "https://ingest.atatus.net/api/v1/write"
[outputs.http.headers]
Authorization = "Bearer ${TIGEROPS_API_KEY}"Common Questions
Is TigerOps compatible with DogStatsD clients?
Yes. TigerOps supports the DogStatsD v1.2 protocol including tags (|#key:value), events (_e{title,text}:), and service checks (_sc|name|status). Existing Datadog Agent or dogstatsd-go clients work without modification.
What happens to metrics that arrive without tags?
Tagless StatsD metrics are stored and queryable in TigerOps. You can add labels via the TigerOps metric mapping rules based on metric name prefixes. This is useful for legacy applications that cannot be easily re-instrumented.
How does TigerOps handle high-frequency StatsD metrics (100K+ per second)?
TigerOps's StatsD receiver aggregates metrics within a configurable flush interval (default 10 seconds) before storing. For extremely high frequencies, we recommend using the Telegraf statsd input with remote_write to TigerOps for additional buffering.
Can I forward StatsD metrics to TigerOps alongside another backend?
Yes. Use a StatsD forwarder like Telegraf or the statsd-proxy to fan out to both TigerOps and your existing backend simultaneously. This enables a parallel evaluation without changing application code.
Are StatsD sets (unique value counters) supported?
Yes. TigerOps stores StatsD set metrics and computes the unique value count per flush interval using HyperLogLog for memory efficiency. Large sets (millions of unique values) are supported with bounded memory.
Migrate Your StatsD Metrics in 60 Seconds
One config change. Full DogStatsD compatibility. AI anomaly detection on every metric.