No data appearing

A server shows Offline, or its panels say “Collector may not be running” or “Metrics will appear once the collector starts sending data.” The checks below run on the affected server, ordered by how often each turns out to be the cause. (If just one panel is empty while the rest draw normally, that’s A panel is missing or empty, not this page.)

Give a fresh install 60 seconds

The collector sends its first batch about a minute after monitorable-collector.service starts, and the dashboard draws points shortly after they arrive. If you ran the install command less than a minute ago, this is the whole explanation.

Check the service is running

systemctl status monitorable-collector

Healthy looks like Active: active (running). A stopped collector looks like:

○ monitorable-collector.service - Monitorable OpenTelemetry Collector
     Loaded: loaded (/etc/systemd/system/monitorable-collector.service; enabled; preset: enabled)
     Active: inactive (dead) since Sat 2026-07-11 09:15:03 UTC; 14ms ago

Start it and confirm it stays up:

systemctl start monitorable-collector
systemctl is-active monitorable-collector

If the service is missing entirely (Unit monitorable-collector.service could not be found), the collector isn’t installed on this server — run the install command.

A running service does not by itself mean data is flowing: delivery failures don’t stop the service. The remaining checks read the logs:

journalctl -u monitorable-collector -f

The logs say “Exporting failed. Will retry the request after interval.”

info  internal/retry_sender.go:133  Exporting failed. Will retry the request after interval.
{..., "error": "failed to make an HTTP request: Post \"https://ingest-mon.ok9k.com/v1/metrics\":
dial tcp: lookup ingest-mon.ok9k.com on 1.1.1.1:53: no such host", "interval": "6.930527828s"}

The collector can’t reach the ingest endpoint — DNS failure, blocked outbound HTTPS, or a proxy in the way. It retries with backoff and keeps recent batches queued, so metrics resume on their own once the network path works. Confirm reachability from the server:

curl -s -o /dev/null -w '%{http_code}\n' https://ingest-mon.ok9k.com/v1/metrics

405

405 is the healthy answer — the endpoint is reachable and answering (it just doesn’t accept a plain GET). A DNS or connection error from curl means the server’s outbound path is the problem, not the collector.

The logs say “Exporting failed. Dropping data.” with HTTP Status Code 401

error  internal/queue_sender.go:50  Exporting failed. Dropping data.
{..., "error": "not retryable error: Permanent error: rpc error: code = Unauthenticated
desc = error exporting items, request to https://ingest-mon.ok9k.com/v1/metrics
responded with HTTP Status Code 401", "dropped_items": 194}

The endpoint rejected the collector’s API key, and this is not retried — each batch is dropped. Two common ways to get here:

• The key doesn’t match the server row in the dashboard (a hand-edited or copy-pasted-from-another-server key).
• The server was removed in the dashboard. Removing a server revokes its API key, so a collector still running on that server gets 401 from then on.

The fix is a fresh key: remove the server in the dashboard if it still exists (Server actions → Remove Server), add it again, and run the new install command from the dialog. Re-running the install with the new key replaces the stored one.

The logs say “Exporting failed. Dropping data.” with HTTP Status Code 404

error  internal/queue_sender.go:50  Exporting failed. Dropping data.
{..., "error": "not retryable error: Permanent error: rpc error: code = Unimplemented
desc = error exporting items, request to https://api-mon.ok9k.com/v1/metrics
responded with HTTP Status Code 404", "dropped_items": 194}

The collector is posting to an address that no longer serves ingest — this happens on collectors installed before a platform migration changed the ingest endpoint. Reinstall with a current install command: get it from the dashboard by removing and re-adding the server, then run it as root. The install rewrites the endpoint the service uses.

Still stuck

Collect the last minutes of collector logs:

journalctl -u monitorable-collector --since "-10m" --no-pager

and note your server’s status in the dashboard (Offline vs. Online with empty panels). Those two together identify almost every remaining case.