🚨 VictoriaMetrics Error: 'cannot unmarshal Graphite plaintext line ... unsupported format' — Cause, Fix, and Troubleshooting Guide

What this error means

VictoriaMetrics can ingest metrics over the Graphite plaintext protocol when you enable -graphiteListenAddr (conventionally :2003). Each line must be metric value timestamp, all whitespace-separated, with a numeric value and an epoch-seconds timestamp. When a line doesn’t fit that shape, VictoriaMetrics rejects it and logs the offending line verbatim:

cannot unmarshal Graphite plaintext line "cpu.load 1.5 abc": cannot parse timestamp "abc": unsupported format

Here the value (1.5) parsed fine, but the timestamp field held abc instead of a number. Graphite plaintext is positional — VictoriaMetrics does not guess which token is which — so a field in the wrong order, a stray unit suffix, or output aimed at the wrong port all surface as parse errors like this one.

Where records stall

• VictoriaMetrics logs cannot unmarshal Graphite plaintext line with the raw line quoted back.
• Some Graphite metrics land while others silently go missing (the malformed lines are dropped).
• A metric that worked from one client fails from another that formats or orders fields differently.
• Nothing arrives at all, and the client is actually writing to a port where no Graphite listener exists.
• Tagged series (name;tag=value) fail to parse when the tag syntax is malformed.

Following a record through the pipeline

First confirm the Graphite listener is actually enabled and on the port you think it is:

# Is -graphiteListenAddr set, and on which port?
ps aux | grep -E '[v]ictoria-metrics|[v]minsert' | grep -oE '\-graphiteListenAddr[^ ]*'

# Is something listening on 2003?
ss -ltnp | grep ':2003'

Send one known-good line by hand and watch whether it parses. This isolates a client-formatting bug from a listener/port problem:

# metric value timestamp — value and timestamp both numeric (epoch seconds)
printf 'cpu.load 1.5 %s\n' "$(date +%s)" | nc -q1 localhost 2003

Then replay the exact line from the error to confirm the fix and inspect what the client emits:

# Reproduce the failing line to see the same error
printf 'cpu.load 1.5 abc\n' | nc -q1 localhost 2003

Pipeline causes

• Fields out of order — the protocol requires metric value timestamp; swapping value and timestamp (or prepending the timestamp) breaks parsing.
• A non-numeric value or timestamp — a unit suffix (1.5ms), a comma decimal, or a word like abc where a number is expected.
• Malformed Graphite tags — tag segments not written as name;tag1=v1;tag2=v2, e.g. wrong separators or empty tag values.
• Sending to the wrong port — the client points at a port that isn’t the Graphite listener, so bytes are never parsed as Graphite at all.

Remediation

1. Send lines as metric value timestamp with a numeric value and an epoch-seconds timestamp. Fix the ordering and drop any non-numeric tokens:

# Wrong: non-numeric timestamp
cpu.load 1.5 abc

# Right: numeric value, epoch-seconds timestamp
cpu.load 1.5 1752278400

2. Use name;tag1=v1;tag2=v2 for tagged series. Attach tags to the metric name with semicolons, keeping the value and timestamp fields intact:

cpu.load;host=web-01;region=us-east 1.5 1752278400

3. Enable -graphiteListenAddr and point the client at the right port. Make sure the listener exists and the client targets it:

./victoria-metrics -graphiteListenAddr=:2003 \
  -storageDataPath=/var/lib/victoria-metrics

4. Validate the client output. Capture what your Graphite client (StatsD, collectd, a custom script) actually writes and confirm each line has exactly three whitespace-separated fields with numeric value and timestamp:

# Tee the client's output to eyeball the wire format
your-graphite-client | tee /tmp/graphite-out.txt | nc -q1 localhost 2003
head /tmp/graphite-out.txt

Keeping ingestion stable

• The timestamp is epoch seconds, not milliseconds — a millisecond timestamp parses as a number but lands far in the future.
• Graphite plaintext is positional and whitespace-delimited; embedded spaces or tabs inside the metric name will shift the fields and break parsing.
• A malformed line is dropped silently apart from the log entry — watch the ingestion logs, don’t assume every emitted line arrived.
• Confirm you’re not colliding with another service on :2003; if a real Graphite/carbon daemon also binds it, the client may be talking to the wrong one.

Related pipeline errors

• VictoriaMetrics Error Guide: cannot parse metric value
• VictoriaMetrics Error Guide: cannot parse timestamp
• VictoriaMetrics Error Guide: cannot parse labels