Host Requirements for Agent Installation

Sysdig agents can be installed on a wide array of Linux hosts. Check your environment to ensure it meets the minimum supported platform, operating system, runtime, and orchestration requirements and use the appropriate installation instructions. 

Cloud Platform or Private Data Ctr 

Cloud Platforms Supported 

  • AWS Elastic Cloud Compute (EC2) and AWS Elastic Container Svc (ECS)
  • Google Cloud Provider (GCP) and Google Kubernetes Engine (GKE). 
  • Microsoft Azure and Microsoft Azure Container Service (AKS)

Private Data Center 

See the Supported Linux Distributions table, below. 

Container Runtimes

Sysdig supports Docker, RKT, and LXC. Agents can be installed inside a Docker container. 

Supported Linux Distributions 

Private_Data_Center.jpg

Orchestrator: Yes/No 

  • If NO orchestrator is used, follow the installation instructions for Agent Install: Standard 
  • If you ARE using an orchestrator what kind are you using? 

Supported Open Source Orchestrators 

SupportedOrchestrators.jpg


Supported Container Platforms 

SupportedContainers.jpg

See Agent Installation section in the User Guides 

 

Additional Requirements

Access Key

The installation of the Sysdig agent requires an access key. This key and the agent installation instructions are presented to you after activating your account and using a web-based wizard upon initial login.  The same information can also be found in the Settings > Agent Installation menu of the web interface after logging in.

Network connection

A small Sysdig agent (containerized or native) is installed into each host being monitored and will need to be able to connect to the Sysdig Monitor backend servers to report host metrics. The agent must be able to reach the address 'collector.sysdigcloud.com' (via multiple IPs) over port tcp/6666 default. If needed it can be changed to port 80; see this FAQ on changing the agent's port number.

Note: Our agent doesn't use HTTP protocol, thus does not support HTTP proxies. It is possible to use transparent TCP proxy: please contact Sysdig support for assistance. 
If a proxy is in use, it must be transparent. 

Tags

Tagging your hosts is highly recommended. Tags allow you to sort nodes of your infrastructure into custom groups in Sysdig Monitor.
Replace the [TAGS] parameter in configuration file with a comma-separated list in the form of TAG_NAME:TAG_VALUE. For example: role:webserver,location:europe.
See <Understanding the Agent Config Files>. 

TracePoints Support

All supported distribution released kernels have this support but if creating a custom kernel, it must support the following options:

CONFIG_TRACEPOINTS 
CONFIG_HAVE_SYSCALL_TRACEPOINTS

 

About Kernel Headers

The Sysdig agent requires a kernel module in order to install successfully on a host. This can be obtained in three ways:

  1. Agent compiles the module using kernel headers.
    If the hosts in your environment already have kernel header files pre-installed, no special action is needed. Or you can install the kernel headers manually; see below. 

  2. Agent auto-downloads precompiled modules from Sysdig's AWS storage location. 
    If it is able to auto-download, no special action is needed. If there is no internet connectivity, you can use method 3 (download from an internal URL). 

  3. Agent downloads precompiled modules from an internal URL.
    Use the environment variable SYSDIG_PROBE_URL.
    See also Understanding the Agent Config Files. Contact Sysdig support for assistance. 

To Install Kernel Headers Manually

In some cases, the host(s) in your environment may use Unix versions that do not match the provided headers, and the agent may fail to install correctly. In those cases, you must install the kernel headers manually.  

For Debian-syle distributions, run the command: apt-get -y install linux-headers-$(uname -r)

For RHEL-style distributions, run the command: yum -y install kernel-devel-$(uname -r)

NOTE: Some cloud hosting service providers supply pre-configured Linux instances with customized kernels. You may need to contact your provider's support desk for instructions on obtaining appropriate header files, or for installing the distribution's default kernel.

To Correct Kernel Header Errors in AWS 

During an agent installation in an Amazon machine image (AMI) you may encounter the following errors while the installer is trying to compile the Sysdig kernel module: 
"Unable to find kernel development files for the current kernel version" and "FATAL: Module sysdigcloud-probe not found". 

This indicates your machine is running a kernel in an older AMI for which the kernel headers are no longer available in the configured repositories. The issue has to do with Amazon purging packages in the yum repository when new Amazon Linux machine images are released.

The solution is either to update your kernel to a version for which header files are readily available (recommended), or perform a one-time installation of the kernel headers for your older AMI.

Option 1: Upgrade Your Host's Kernel

First install a new kernel and reboot your instance:

sudo yum -y install kernel
sudo reboot

After rebooting, check to see if the host is reporting metrics to your Sysdig account. If not, you may need to issue three more commands to install the required header files:

sudo yum -y install kernel-devel-$(uname -r)
sudo /usr/lib/dkms/dkms_autoinstaller start
sudo service dragent restart

Option 2: Install Older Kernel Headers

Although it is recommended to upgrade to the latest kernel for security and performance reasons, you can alternatively install the older headers for your AMI.  

Find the the AMI version string and install the appropriate headers with the commands:

releasever=$(cat /etc/os-release | grep 'VERSION_ID' | grep -Eo "[0-9]{4}\.[0-9]{2}")
sudo yum -y --releasever=${releasever} install kernel-devel-$(uname -r)

Issue the remaining commands to allow the Sydig Agent to start successfully:

sudo /usr/lib/dkms/dkms_autoinstaller start
sudo service dragent restart

 

Reference: Find Your AWS Instance Image Version

The file /etc/image-id shows information about the original machine image with which your instance was set up:

[ec2-user ~]$ cat /etc/image-id
image_name="amzn-ami-hvm"
image_version="2017.03" image_arch="x86_64"image_file="amzn-ami-hvm-2017.03.0.20170401-x86_64.ext4.gpt"image_stamp="26a3-ed31" image_date="20170402053945" recipe_name="amzn ami" recipe_id="47cfa924-413c-d460-f4f2-2af7-feb6-9e37-7c9f1d2b"

This file will not change as you install updates from the yum repository.

The file /etc/system-release will tell what version of the AWS image is currently installed:

[ec2-user ~]$ cat /etc/system-release
Amazon Linux AMI release 2017.03

This file is updated through yum as your host is updated and is part of the system-release RPM.

Have more questions? Submit a request