IaC & config management

Enterprise Starlink deployments rarely stop at one Agent and one terminal. Platform teams need repeatable, auditable configuration across vessels, campuses, aircraft hangars, and remote sites—without SSHing to every host to edit conf.yaml by hand.

This guide covers how to manage the SignalWeave Starlink Datadog Native Integration at fleet scale using infrastructure-as-code (IaC) and configuration-management patterns. It complements the Onboarding guide (first install) and Configuration reference (option details).

What you are managing

The integration is a standard Datadog Agent check. Everything lives in one file:

There is no separate SignalWeave daemon, sidecar, or cloud config service for on-premise collection. Your IaC pipeline renders and deploys this YAML; the Agent loads it on restart.

Per Agent host you configure:

• init_config — fleet-wide defaults (metric group toggles, shared settings)
• instances — one block per Starlink terminal reachable on the local LAN (dish_ip, tags, optional per-terminal overrides)

One Agent on the same network can monitor multiple terminals. Model inventory at the Agent host level: each host gets a conf.yaml listing every dish it can reach on port 9200.

Enterprise deployment model

Think in four layers:

Keep terminal inventory in a structured source of truth (CMDB, fleet database, YAML/JSON in Git)—not only in someone's spreadsheet. IaC templates read from that inventory and render per-host config.

Recommended tag dimensions

Apply tags consistently at collection time so dashboards, monitors, and SLOs roll up correctly:

The check also emits hardware-derived tags (device_id, hardware_version, software_version, etc.) automatically—use your operational tags for fleet context; use device_id for terminal identity across IP changes.

Configuration management patterns

Any tool that can template a file, enforce permissions, and restart the Agent works. Common choices:

SignalWeave does not ship a vendor-specific Terraform provider or Ansible role today. Treat the check like any other Datadog integration: your existing Datadog Agent automation plus a templated conf.yaml.

Git layout

A practical repo structure for multi-site fleets:

├── inventory/
│   ├── production/
│   │   ├── sites.yaml          # site/vessel metadata
│   │   └── agents.yaml         # agent host → terminal list mapping
│   └── staging/
│       └── ...
├── templates/
│   └── signalweave_starlink_conf.yaml.j2
├── group_vars/
│   └── datadog_agents.yml      # shared init_config defaults
└── playbooks/
    └── deploy-starlink-check.yml

inventory/production/agents.yaml (example):

  - hostname: dd-agent-ship-alpha
    site: example-cruise-ship
    fleet: maritime-fleet
    region: caribbean
    env: production
    terminals:
      - ip: 10.0.1.1:9200
        location: deck-14-forward
      - ip: 10.0.2.1:9200
        location: deck-14-aft

  - hostname: dd-agent-campus-hq
    site: hq-campus
    fleet: enterprise-land
    region: us-east
    env: production
    terminals:
      - ip: 192.168.100.1:9200
        location: roof-north

Keep inventory environment-separated (production/ vs staging/). Never mix lab dish IPs into production Agent configs.

Ansible example

Template driven by host inventory:

templates/signalweave_starlink_conf.yaml.j2

{% for key, value in starlink_init_config | default({}) | dictsort %}
  {{ key }}: {{ value | lower }}
{% endfor %}

instances:
{% for terminal in starlink_terminals %}
  - dish_ip: {{ terminal.ip }}
    tags:
      - fleet:{{ starlink_fleet }}
      - site:{{ starlink_site }}
      - region:{{ starlink_region }}
      - terminal_location:{{ terminal.location }}
      - env:{{ starlink_env }}
{% endfor %}

playbooks/deploy-starlink-check.yml

  hosts: datadog_agents
  become: true
  tasks:
    - name: Ensure integration directory exists
      file:
        path: /etc/datadog-agent/conf.d/signalweave_starlink.d
        state: directory
        owner: dd-agent
        group: dd-agent
        mode: "0750"

    - name: Render conf.yaml
      template:
        src: ../templates/signalweave_starlink_conf.yaml.j2
        dest: /etc/datadog-agent/conf.d/signalweave_starlink.d/conf.yaml
        owner: dd-agent
        group: dd-agent
        mode: "0640"
      notify: Restart Datadog Agent

  handlers:
    - name: Restart Datadog Agent
      systemd:
        name: datadog-agent
        state: restarted

Post-deploy validation (add as a task or CI step):

Expect [OK] and 67 metric samples per instance. See Onboarding guide §4.

Terraform + cloud-init

When Agent hosts are VMs or edge appliances, provision the config at boot:

  filename = "${path.module}/rendered/${each.key}/conf.yaml"
  content  = templatefile("${path.module}/templates/conf.yaml.tftpl", {
    init_config = var.starlink_init_config
    instances   = each.value.terminals
    tags        = each.value.common_tags
  })
}

# Pass rendered file via cloud-init, SSM, or configuration management

Use Terraform for host lifecycle; use Ansible or similar for ongoing config drift if terminals are added frequently without reprovisioning.

Bandwidth-aware defaults at scale

On bandwidth-constrained links, set metric group defaults once in init_config for an entire environment:

  collect_alignment: false
  collect_power: false
  collect_outage: false
  collect_init_timing: false
  collect_ready_states: false
  collect_location: false

Manage these toggles in group_vars or Terraform variables—not per-host copies—so a policy change rolls out with one merge. See Configuration reference for the full toggle list and payload impact (~67 metrics / ~1.1 KB per terminal at full collection).

Rollout strategy

For enterprise fleets, avoid big-bang deploys:

1. Pilot site — one Agent host, one or two terminals; validate check output and Datadog dashboards.
2. Canary cohort — a small percentage of sites; watch starlink.can_connect and custom metric volume.
3. Regional waves — deploy by region or fleet segment with a rollback playbook.
4. Full fleet — automate via CI/CD; require green check status before marking a wave complete.

Rollback: revert the previous conf.yaml from Git and restart the Agent. Historical metrics remain tied to device_id tags.

Change management

Track config changes in Git with PR review. Pair with Datadog's Agent flare or config diff tooling when troubleshooting drift on a host.

Drift detection

Hosts that were edited manually will diverge from Git. Options:

• Re-run configuration management on a schedule (Ansible --check / enforce mode)
• Compare deployed file hash against expected artifact in CI
• Datadog Fleet Automation or custom audit scripts listing conf.d/signalweave_starlink.d/ contents

Treat unexpected manual edits as incidents—reconcile back to the repo source of truth.

CI validation

Before deploy, lint rendered YAML:

python3 -c "import yaml; yaml.safe_load(open('conf.yaml'))"

# Optional: datadog-agent check on a staging host or container with network to lab dishes
datadog-agent check signalweave_starlink

In CI, validate that every dish_ip in inventory resolves to a known terminal record and that required tags are present.

Security and compliance notes

• On-premise collection requires LAN access to terminals on port 9200 only—no Starlink credentials in conf.yaml.
• Restrict file permissions: owner dd-agent, mode 0640 (Linux).
• Config repos often contain internal IPs and site names—keep inventory repos private; scope CI secrets accordingly.
• Outbound Agent traffic remains standard Datadog HTTPS (443); no inbound firewall rules on the Agent.

If you also use the cloud telemetry API path (enterprise Starlink accounts), OAuth credentials belong in Datadog secrets or your vault—not in plain Git. See Architecture comparison.

Related docs

• Onboarding guide — first install, verification, post-deploy checklist
• Configuration reference — metric groups, multi-dish patterns, full conf.yaml
• Architecture comparison — on-premise Agent vs cloud telemetry API