-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Context
IPFS monitoring deployed (2026-02-08) shows two anomalies that need investigation.
1. Ghost cluster peer ID
12D3KooWEa7paYzEqPf8Mr1h69XR4twJMZQW6Fz7MGT828aPTk5m appears in cluster monitor metrics (pinqueue, ping) but doesn't match any known ccs_peer_id in ansible inventory.
- ipfs1's recorded ID is
12D3KooWFdQri2MC...(different) - ipfs1 is currently offline
- Ghost peer shows
valid: Truein ping andpinqueue: 0
Possible causes:
- ipfs1 was re-provisioned and got a new cluster identity
- A test peer that was never cleaned up from CRDT state
Action: When ipfs1 comes back online, check its actual cluster peer ID (ipfs-cluster-ctl id). If it matches the ghost, update inventory/host_vars/ipfs1.yml. If not, remove the stale peer from cluster state.
2. IPv6 Tailscale addresses in swarm peers
meerkat and pihost show some peers connected via Tailscale IPv6 (fd7a:115c:a1e0::9, fd7a:115c:a1e0::c) instead of IPv4. The bandwidth collector's name map only covers IPv4 Tailscale IPs, so these show as raw addresses in metrics.
Action: Either add IPv6 Tailscale addresses to the ansible peer name mapping, or investigate why some connections prefer IPv6 over IPv4 and whether kubo can be configured to prefer IPv4 for cluster-internal traffic.
Related
- Monitoring role:
roles/ipfs-monitoring/in hrdag-ansible - Peer name map:
roles/ipfs-monitoring/defaults/main.yml(ipfs_extra_peer_names)
By PB & Claude