Satellites are straightforward to deploy using a Docker image (with or without a Helm chart), AWS/AMI, or a Debian package. Installation and configuration differ depending on the environment you’re installing to, but you’ll need the following information for all installation types.
As part of your Satellite configuration, you’ll need a Satellite key. Lightstep uses this key to authenticate and communicate with the Hypothesis Engine. Satellite keys expire after 1 year for security purposes. You’re notified by email when the key is about to expire. See Generate Satellite Keys for instructions for generating and renewing keys.
Only users with the Admin role can generate Satellite keys.
The Satellites don’t have high CPU requirements and don’t benefit from having more cores added. We recommend 2-4 CPU cores per Satellite.
We recommend using machines with 2 CPU and 16 GB of memory each.
Lightstep Satellites are generally run in a Docker container or in a dedicated virtual machine instance. We recommend provisioning memory-optimized instances, such as r5.large, n1-highmem-2, or E2 v3 for AWS, GCP, and Azure, respectively. However, smaller instance types may be appropriate for development or testing environments. Satellites have no storage requirements. You can find recommended settings for memory (needed when configuring your Satellites) here.
The Satellites have been tested to handle 250 MB per minute of total ingress per instance. Higher ingress creates memory pressure that might cause the Satellite to exceed its memory allocation and can create internal queuing in the Satellite that might cause dropped or delayed spans.
Learn more about monitoring and tuning your Satellites here.
Given the above recommendations, it is possible to allocate multiple Satellite instances to the same virtual machine or physical hardware. Remember to ensure you have enough CPU, memory, and network I/O for all the Satellites when stacking them.
If you want to enable autoscaling for your Satellite pool, we recommend using the ingress to determine scaling. The above recommendation is to keep the ingress below 250 MB per minute per instance. Your autoscaling framework might allow using StatsD metrics to determine scaling. You can use the metrics discussed above: satellite_bytes_received_thrift and satellite_bytes_received_grpc.
Example Autoscaling Configuration for AWS
Below is an example configuration you might use for AWS.
Whitelist to Allow Outbound Traffic
You must allow outbound traffic from the satellites by whitelisting the following IP addresses, on TCP ports