A 64-bit Linux distribution with a minimum kernel version of 3.10, and support of docker-engine 1.7.1 or later, is required for each server instance.
Recommended Linux distributions: RedHat, Ubuntu, Amazon Machine Images (AMI), Amazon Linux 2.
For the Docker installation, running devicemapper in ’loopback mode’ is not supported. It has known performance problems and a different storage driver should be used.
Please see this note from our Replicated infrastructure partner: devicemapper-installation-warning.
Installing the latest version of Docker is recommended.
Cassandra is used as the metrics store for Sysdig agents. It is the most dynamic component of the system, and requires additional attention to ensure that your system is performing well and highly responsive.
This component is stateful, and should be treated more carefully than stateless components. Cassandra sizing is based on a minimum replication factor as well as the number of agents writing data.
A minimum replication factor of 3 is recommended for the Sysdig application, which allows the cluster to survive the failure of 1 Cassandra instance.
Each agent consumes anywhere from 500MB to 2GB of Cassandra storage, with average sizing at 1.5GB per agent. Because of Sysdig’s data aggregation model, this storage should comfortably handle multi-year history. This needs to then be multiplied by the replication factor to determine the total disk space required. A rough calculation might be:
= 150GB raw
X replication factor of 3
= 450GB total
To be safe we recommend that you size some additional disk space as buffer (say 25-50%) on top of that.
The following firewall/security configurations are required for inbound and outbound traffic for the Sysdig platform:
Agent communication (unencrypted).
Agent Communication (TLS/encrypted).
Sysdig Monitor user-interface access inbound.
Optional: Used if collecting Amazon Web Service (AWS) CloudWatch metrics. See Integrate AWS Account and CloudWatch Metrics (Optional).
Optional: Needed if using Sysdig Secure Image Scanning to download vulnerability definitions.
Must be open to Cloudflare IP ranges: https://www.cloudflare.com/ips/.
Replicated Management Console access (for on-premises installations that don't use Kubernetes).
Warning: Port 6666 should only be opened if agents will be communicating with the collectors without encryption.
Additional ports may need to be configured for the Replicated infrastructure manager. See Replicated port requirements for more information.
HTTP/HTTPS and Proxy Support
All non-airgapped hosts require outbound HTTP/S internet access for:
Pulling Sysdig/Agent containers from the Docker hub repository
Release update checks
Note: Sysdig does not support HTTP and HTTPS proxies for Sysdig platform components.
Summary: Plan Proxy Support for Notification Channels, CloudWatch Metrics, Capture Storage
In release #760 and newer of the Sysdig platform back-end, an option is available to configure outgoing HTTP/HTTPS connections via proxy. This has been tested and supports outgoing web connections needed to support the following features:
Amazon Simple Notification Service (SNS)
Gathering of AWS CloudWatch data
Capture storage to an AWS Simple Storage Service (S3) bucket
Proxied web connectivity to support authentication mechanisms (Security Assertion Markup Language (SAML), OpenID Connect, OAuth) are not supported at this time.
Configure Proxy Using JVM Options
The proxy settings are configured via the Java virtual machine (JVM) options passed to the Sysdig software components. JVM options can be added at any time, with a required restart.
# Optional: Sysdig Cloud application JVM options. For heavy load environments you'll need to tweak # the memory or garbage collection settings sysdigcloud.jvm.api.options: "" sysdigcloud.jvm.worker.options: "" sysdigcloud.jvm.collector.options: ""
Enter the proxy parameters, as in the example below.
This JVM options string will forward all HTTP and HTTPS traffic via outgoing port 8888 on a proxy at hostname proxy.example.com. The IP address may be specified instead of hostname.
-Dhttp.proxyHost=proxy.example.com -Dhttp.proxyPort=8888 -Dhttps.proxyPort=8888 -Dhttps.proxyHost=proxy.example.com # Optional: Sysdig Cloud application JVM options. For heavy load environments you'll need to tweak # the memory or garbage collection settings sysdigcloud.jvm.api.options: -Xms2048m -Xmx2048m -Dhttp.proxyHost=xxx.xxx.sysdig.com -Dhttp.proxyPort=80 -Dhttps.proxyHost=xxx.xxx.sysdig.com -Dhttps.proxyPort=80
Do not use local host or 127.0.0.1. By default, HTTP/HTTPS requests to localhost or 127.0.0.1 will not be directed by the back-end toward any configured proxy, which is necessary for the functioning of some web components internal to the Sysdig platform containers.
If you deploy the Sysdig platform in AWS, add an additional proxy parameter:
Rationale: This provides a work-around for the backend occasionally making HTTP requests to a special instance metadata address 169.254.169.254, which is undesirable when using a proxy.
This IP address will be excluded from proxying by default in a future release.
If you have additional proxy exclusions you wish to specify that are unique to your environment, these can also be added using the pipe separator.
For example, assume your deployment was in AWS and you also had a webhook target 192.168.1.2 that was not reachable via your proxy. To exclude both:
Kubernetes: when setting the
sysdigcloud.jvm.worker.optionsin the config.yaml for the ConfigMap, the pipe separator must be double-escaped, such as:
-Dhttps.proxyPort=80 -Dhttps.proxyHost=xx.xx.sysdig.com -Dhttp.nonProxyHosts=184.108.40.206\\|127.0.0.1\\|localhost\\|.sysdig.com"
The Sysdig platform requires the system clocks to be closely synchronized between hosts. When provisioning hosts for installation, ensure the system clocks are synchronized.
Sysdig recommends you install Network Time Protocol (NTP) to ensure all host clocks stay synchronized.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.