LightStep

LightStep Documentation

Welcome to the LightStep developer hub. You'll find comprehensive guides and documentation to help you start working with LightStep as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

Install and Configure Satellites

Satellites are straightforward to deploy using a Docker image, 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.

Satellite Key

As part of your Satellite configuration, you'll need a Satellite key. LightStep uses this keyc to authenticate and communicate with the LightStep SaaS. 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.

CPU Requirements

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.

Memory Requirements

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.

Ingress

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.

Satellites emit two metrics about their ingress you can use for monitoring and scaling: satellite_bytes_received_thrift and satellite_bytes_received_grpc.

Stacking Satellites

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.

Autoscaling

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 443 and 8043.

  • 130.211.23.15
  • 35.184.80.225
  • 35.190.51.206
  • 35.190.69.91
  • 35.224.59.21
  • 35.231.95.136

Install and Configure Satellites


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.