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

Overview

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.

Symptoms

• 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.

Common Root 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.

How to diagnose

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

Fixes

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

What to watch out for

• 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

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