Architecture Comparison: On-Premise Agent vs Cloud Telemetry API
Summary
The SignalWeave Starlink integration can collect metrics via two distinct paths. Each has tradeoffs that determine which is appropriate for a given deployment.
Side-by-Side Comparison
| On-Premise (Datadog Agent on LAN) | Cloud (Telemetry Stream API) | |
|---|---|---|
| How it connects | Datadog Agent on the same LAN as the dish, collects from the local device endpoint | Datadog Agent anywhere with internet, polls SpaceX telemetry stream |
| Auth | None — local network access only | OAuth2 service account (client_id + client_secret) |
| Who has access | Anyone on the dish's LAN | Enterprise Starlink accounts only |
| Requires satellite lock? | No — reports hardware telemetry even offline | Yes — only returns data when dish is online and connected to SpaceX backend |
| Metrics depth | 67 curated operational metrics — deep hardware state | ~16 user terminal fields, ~40 router fields — operational summary |
| Fleet scope | Multiple dishes on the same LAN — one Agent instance can monitor every terminal it can reach locally | Entire account's fleet in one stream |
| Deployment | Agent must be physically on-site (ship, campus, etc.) | Agent can run anywhere (AWS, data center, laptop) |
| Latency | Real-time (every 15s check cycle) | Near real-time (15s batches from SpaceX) |
| Works without internet? | Yes — collects locally, buffers until internet returns | No — requires internet to reach SpaceX API |
| Data retention | Continuous as long as Agent runs | 8-hour rolling window in SpaceX's stream |
What Each Approach Gives You
On-Premise Agent — Deep Hardware Telemetry
Metrics only available via local collection (NOT in the cloud API):
- All alert flags (water detection, motor current, PSU throttle, etc.)
- Dish alignment details (tilt angle, attitude uncertainty, boresight az/el)
- Subsystem ready states (CADY, SCP, L1L2, XPHY, AAP, RF)
- Power draw (dish watts, router watts)
- Boot initialization timing (RF ready, stable connection, first ping)
- Outage cause codes and duration
- GPS satellite count
- Ethernet link speed
- Software update progress
Cloud Telemetry API — Fleet-Wide Operational View
Metrics only available via cloud API (NOT in local Agent collection):
H3CellId— precise geolocation as H3 cell (can convert to lat/lon)SignalQuality— normalized 0-1 signal quality scoreCountryCode— ISO country code for current locationInTerritorialWaters— boolean for maritime regulatory compliance- Router WiFi client counts (2.4GHz, 5GHz, Ethernet)
- Router WiFi signal strength stats (min/max/avg per band)
- Router WAN bytes (rx/tx)
- IP allocation tracking (IPv4, IPv6)
The Key Drawback of Cloud API
The cloud API only reports data from online terminals. If a dish loses satellite lock (obstruction, rain fade, stowed, indoors, international waters gap), SpaceX's backend has no telemetry to stream. The API returns empty values until the dish reconnects.
This means:
- You cannot monitor a dish that is offline via the cloud API
- You cannot detect why a dish went offline via the cloud API (was it obstructed? thermal shutdown? power loss?)
- You only know a dish is down by the absence of data — no explicit "offline" signal
The on-premise Agent approach does NOT have this limitation. It collects hardware state regardless of satellite connectivity because it talks directly to the dish over the LAN.
On-Premise Agent: One Agent, Multiple Terminals
A single Datadog Agent on the same network as your Starlink terminals can collect from multiple dishes — you do not need a separate Agent per terminal. As long as the Agent can reach each dish's local endpoint over the LAN, one instance handles the full on-site fleet.
Configure each terminal in conf.yaml (or equivalent instance config). The Agent runs one check cycle per configured terminal on the same 15-second interval.
Which path — on-premise, cloud API, or both — is a deployment choice for your team. SignalWeave supports either mode; this doc describes the tradeoffs, not a prescribed architecture for a given industry or fleet size.
Data Availability During Connectivity Loss
This is the critical scenario for maritime/aviation customers:
| Scenario | Cloud API | On-Premise Agent |
|---|---|---|
| Dish online, connected | ✅ Full telemetry | ✅ Full telemetry |
| Dish online, no satellite lock | ❌ No data | ✅ Hardware telemetry (alerts, alignment, ready states) |
| Dish powered off | ❌ No data | ❌ No data |
| Ship in international waters (intermittent) | ⚠️ Gaps in data | ✅ Continuous (Agent buffers locally) |
| Rain fade / heavy obstruction | ⚠️ Gaps in data | ✅ Continuous |