Troubleshooting¶

Fixes for the problems you are most likely to hit with the Vector Log Pipeline.

HTTPS ingest returns 401¶

Cause: the request has no credentials, or the wrong ones.

Fix: send HTTP basic authentication with user vector and the password from /var/lib/vector/vector.env. If you changed the password, check that vector.env and the http_in password in /etc/vector/vector.yaml match.

A file in `/var/lib/vector/in/` is not picked up¶

Cause: the file name does not end in .log, or the vector user cannot read it.

Fix: use a .log name and make the file readable, for example chmod 0644 /var/lib/vector/in/<file>.log.

A record is missing from the output¶

Cause: its level is debug, so the redaction step drops it on purpose.

Fix: change the record's level, or change the redact transform in /etc/vector/vector.yaml.

Vector does not start after a config change¶

Cause: the configuration does not validate.

Fix: run the validation yourself to see the error:

sudo -u vector /opt/vector/bin/vector --config /etc/vector/vector.yaml validate

Fix the file and restart with sudo systemctl restart vector.

An S3 sink fails its health check¶

Cause: usually a missing IAM role, a policy that does not allow s3:ListBucket on the bucket, or a wrong bucket or region.

Fix: compare your role with /opt/sushi/etc/vector/iam-s3-sink.json.example, check the bucket and region in the sink, and read sudo journalctl -u vector -n 50 --no-pager.

First boot failed¶

Cause: sushi-vector-firstboot.service failed, so Vector did not start.

Fix: look at its log, then run it again and start Vector:

sudo journalctl -u sushi-vector-firstboot.service --no-pager
sudo systemctl restart sushi-vector-firstboot
sudo systemctl start vector

If it still fails, email info@softwaresushi.com with the instance ID and the log output.