Sensor: Ephemeral and Cloud-Init
Use the Ephemeral deployment for autoscaling groups, short-lived cloud instances, CI workers, disposable test hosts, and immutable virtual machines. The deployment template installs a Sensor when each instance starts.
Prerequisites
- Linux image with systemd and
curl - Kernel 5.4 or newer with BTF
x86_64oraarch64- Root-capable cloud-init or user data
- Outbound connectivity to the Console
- A unique instance identity available at boot
Generate the template
- Open Sensors > Deploy.
- Select Ephemeral.
- Choose Standard or Telecom.
- Enter a node-name prefix and useful tags.
- Generate the fleet token and cloud-init template.
- Add the generated template to the launch template, image configuration, or autoscaling group.
Ephemeral deployments use a reusable fleet token because instances may be created long after the template is published. The default token lifetime is 365 days and it can be revoked from the Console.
Store the token in your cloud secret or protected launch-template mechanism. Do not publish it in a reusable image, source repository, or unprotected instance metadata.
Use unique node names
Every instance must derive a unique name. Good sources include:
- cloud instance ID;
- provider instance name;
- autoscaling group plus instance ID;
- CI pipeline plus job ID.
Do not use only the image name or autoscaling-group name. Reused names make current and terminated instances difficult to distinguish.
Bake versus bootstrap
Prefer a small launch-time bootstrap generated by the Console. This ensures new instances download the current approved Sensor version and receive a unique identity.
If your environment requires a pre-baked image:
- do not bake enrolled certificates or Sensor state into the image;
- do not start the Sensor during image creation;
- inject the token and unique node identity only at instance launch;
- update the image template when the supported bootstrap flow changes.
Verify an autoscaling deployment
Launch one canary instance and confirm:
- the Sensor service becomes active;
- a unique Sensor appears in Fleet;
- the correct group and site tags are present;
- runtime events arrive before the instance is terminated;
- scale-out creates distinct Sensor records;
- scale-in does not leave active records that appear healthy.
Historical evidence from a terminated instance remains governed by Console retention. The instance itself should be shown as offline or decommissioned, never as currently running.
Upgrades
Update the launch template or cloud-init source to the current Console-generated deployment flow, then replace instances through the normal autoscaling rollout. Do not rely on an in-place fleet upgrade for instances that are routinely replaced.
Use a canary template version before changing the full group.
Cleanup
Where the platform supports a termination hook, use the Console-provided decommission procedure before shutdown. Otherwise, define an operational policy for removing terminated Sensor records after confirming the instance no longer exists.
Revoking the fleet token prevents future enrollment from that template but does not stop already-enrolled Sensors.
Troubleshooting
| Symptom | Check |
|---|---|
| New instance never appears | cloud-init log, token status, Console URL, DNS, and system time. |
| Multiple instances share one name | Replace the naming expression with a provider instance ID. |
| Golden image creates duplicate identities | Remove all Sensor state before image capture and install only at launch. |
| Token has expired or was revoked | Generate a new Ephemeral template and update the launch configuration. |
| Instances show stale after scale-in | Confirm termination and decommission or retire the old records. |