Scalyr Agent

The Scalyr Agent is a daemon you can install on each of your servers. It uploads logs and system metrics to Scalyr. This second-generation agent is easy to install and manage, with minimal dependencies and resource requirements.

The agent can run on versions of Python 2 that are present on most servers (verified on Python 2.4 - 2.7). Resource requirements vary by workload; in our internal installations, the agent generally uses less than 15 MB RAM and 2% of CPU.


For standard installation instructions, go to the Agent Installation page.

How Scalyr Calculates Your Log Volume.

The Scalyr Agent uploads logs to our platform via the addEvents API call. In the case of a 1024-byte log event:

  • The text of the event is ingested and 1024 bytes is applied toward the customer's log volume.
  • Attributes (and their corresponding values) that are created by a parser are also included.
  • Attributes that were created by the Scalyr Agent or API client (and were not part of the raw log message) are billed at 1 byte per attribute and the total bytes consumed by the attribute value.

The following attributes are excluded from calculating log volume: - sessionInfo / serverInfo fields, such as app, launchTime, parser, session, machine, serverType, serverScope, sessionType, and serverHost. - The logfile attribute. - Internal Kubernetes attributes like containerName, containerId, pod_name, pod_namespace, namespace, pod_uid, k8s_container_name, original_file, scalyr-category, k8s_node, and container_id.

Main Config File (agent.json)

The Scalyr Agent is configured by editing config variables in the main agent.json config file.

On Linux systems, this file is located at:


And on Windows systems, at:

C:\Program Files (x86)\Scalyr\config\agent.json

The agent detects changes to the configuration file within 30 seconds. There is no need to restart the agent.

Modular Configuration (agent.d snippets)

You can spread your agent configuration across multiple files that we refer to as "snippets". This is convenient when using automated tools to manage your servers.

For instance, you could write a script that installs a product and also installs a Scalyr Agent to gather logs from that product. Your script can conveniently generate modular config snippets without having to parse and modify the main agent config file (or other modular snippets).

Modular snippets are stored in a special directory: /etc/scalyr-agent-2/agent.d on Linux, or C:\Program Files (x86)\Scalyr\config\agent.d on Windows. All files in this directory that end in .json are read by the agent and applied to the agent's configuration.

Modular snippets may also contain global configuration variables (e.g. api_key). However, a given global variable cannot be defined in more than 1 file. (The agent will terminate with an error message if a variable is defined in multiple locations.)

The agent automatically detects new, modified, or deleted snippets in the agent.d directory; you don't need to restart it.

Environment-Aware Config Variables

For convenience, a subset of agent config variables can be configured by simply setting their corresponding system environment variables. We refer to these config variables as "environment-aware," and their behavior is as follows:

If a variable is not defined in agent.json or a modular snippet, but its value is set in the environment, the Agent will fall back to the environment value at start-up.

Configuring via system environment variables has many use cases:

  • For example, to avoid embedding the API key directly in an insecure source-controlled config file, set it through an environment variable instead.
  • Another common use case is configuring Kubernetes cluster monitoring by materializing a Kubernetes ConfigMap as environment variables. The agent then associates the environment variable values to the corresponding agent config variables.

The naming of environment variables is usually SCALYR_<CONFIG_VARIABLE_NAME> where CONFIG_VARIABLE_NAME is the agent config variable you want to set. For example, the environment variable SCALYR_API_KEY maps to the api_key config variable (that the agent needs for uploading logs to Scalyr).

Uppercase names are an accepted convention for environment variables, but the Agent looks for both upper and lower case versions.

As stated, only a subset of config variables are environment-aware. These are mostly global-level variables and some Kubernetes monitor plugin variables. Please refer to the complete list of environment-aware variables.

Note: You must restart the agent for it to pick up new environment variable values. (The automatic detection of changes in agent.json config file and agent.d snippets does not apply.)

Mapping Environment Variables with import_vars

Even if a config variable is not environment-aware, you can still transfer its value from the environment by using variable substitution.

To do so, first list all of the variables you wish to import in a field named import_vars. Then use those variable names, prefixed by $, in string field values. For example:

    import_vars: [ "SCALYR_API_KEY" ],
    api_key: "$SCALYR_API_KEY",

Customize Hostname and Other Server Attributes

Server attributes are key-value pairs attached to log lines uploaded by the Scalyr Agent. These attributes become searchable fields in the Scalyr UI and are especially useful for determining the source of log data when there are multiple agents.

Server attributes are configured in the server_attributes section of the agent.json file.

A special server attribute is serverHost. By default, this attribute is automatically set to the hostname where the Scalyr Agent is running. If this hostname is something unhelpful like "ip-12-23-34-45", you can map it to a different name by explicitly setting serverHost as follows:

"server_attributes": {
    serverHost: "app-server-3",
    tier: "frontend",
    stage: "production",
    datacenter: "us-east-1c"

The agent should begin using this new name within 30 seconds. All subsequent events from this server will be listed under the new name. Older data will still be listed under the old hostname; the old name will disappear from the Overview page after 24 hours.

Uploading Log Files

To upload log files, edit the "logs" section of agent.json. This section lists each log file to upload.

logs: [
    path: "/var/log/httpd/access.log",
    attributes: {parser: "accessLog"}
    path: "/var/log/messages",
    attributes: {parser: "systemLog"}

This will upload the files /var/log/httpd/access.log and /var/log/httpd/messages to Scalyr. The parser property creates a configuration file, accessed from your account, specifying the rules to parse fields from your log messages. Choose a name that describes the log format, using letters, digits, spaces, hyphens, and underscores.

If a single agent will be sending logs to multiple accounts, the agent should be configured for Multiple Workers.

Scalyr includes a suite of standard log parsers. If your log matches one of the following formats, use the corresponding parser name and your logs will be parsed automatically.

Parser Log format
accessLog Standard web access logs ("extended" Apache format)
mysqlGeneralQueryLog MySQL "general" query log
mysqlSlowQueryLog MySQL slow query log
postgresLog Postgres log
json Logs where each line is a JSON object
keyValue Logs containing fields in the form key=value or key="value"
systemLog Supports several common system or error log formats
leveldbLog LevelDB LOG files

Once the Agent is installed and your logs are uploading to Scalyr, you can edit the Parsers configuration files. There you can even ask us to custom-build the parser for you (no extra charge).

For more information on parsing log files, see Log Parsers. See Built-In Parsers to view our built-in parser files, and Pre-Built Parsers to view some pre-built parsers.

You can specify additional fields in attributes. This allows you to distinguish between different log files from the same server. For instance, you might give the file a field like service: "memcache" to identify the service that generates this log; you could then add service = "memcache" to any query to search only your memcache logs.

You can use standard glob syntax to match multiple log files. * matches any text within a file or directory name, and ? matches a single character. For example, the following configuration uploads all log files ending with ".log" in the "app" directory:

logs: [
     path: "/var/log/app/*.log",
     attributes: {parser: "appLog"}

Note for Windows: For Windows systems, you must escape all backslashes present in any path value. For example, to monitor a log file at C:\WebServer\logs\access.log:

logs: [
     path: "C:\\WebServer\\logs\\access.log",
     attributes: {parser: "appLog"}

Associate log files with different API keys.

Each entry of the list in the `logs` section can be associated with a specific API key, allowing different log files to be uploaded to different Scalyr team accounts". Please see the multiple api keys section

Compressing Logs

By default, the Scalyr Agent compresses all uploaded logs using deflate compression.

To alter the compression algorithm or to turn off compression, add the following agent.json config line:

compression_type: <type>

Where <type> is "bz2", "deflate" or empty string "". (Be sure to use quotes around the value.)

`bz2`` compression may reduce network traffic and outbound traffic costs, however our performance testing indicated worse throughput.

Sampling High-Volume Logs

Sometimes, you might not want to upload all messages in a log. For instance, the log might be cluttered with noisy debug messages. Specify sampling rules in the agent configuration to either subsample certain messages (uploading only a random sample), or exclude them entirely. Each sampling rule contains a match_expression field, which is a regular expression, and a sampling_rate field, which is a fraction between 0 and 1. The agent finds the first match_expression that matches any portion of the log line, and uses the sampling_rate to decide whether to upload that message.

The following configuration will upload 10% of all messages containing the word "INFO", no messages containing the word "FINE", and (by default) all messages that don't contain either word:

logs: [
     path: "/var/log/app/*.log",
     attributes: {parser: "appLog"},
     sampling_rules: [
       { match_expression: "INFO", sampling_rate: 0.1 },
       { match_expression: "FINE", sampling_rate: 0 }

Sampling occurs before the log leaves your server; the lines excluded by the sampling rules are not sent to Scalyr.

In a match_expression, if your regular expression requires backslashes, you'll need to write them twice. For example, the regular expression \d{2} matches a two-digit number; in a match_expression, you would write \\d{2}. This is because the configuration file parser removes one level of backslashes.

Sampling Multi-line Messages

Sometimes a single logical message will appear as multiple lines of text in the log. For instance, Java applications often emit multi-line stack traces:


You can group these multi-line messages into a single message. This allows sampling and redaction rules to apply to the entire multi-line unit. (Note that it's also possible to group multi-line messages using a parsing rule in the Scalyr server, but this occurs after the agent has performed sampling and redaction.) To group multi-line messages, add a lineGroupers field to the log definition. For example:

  lineGroupers: [
      start: "^[^\\s]",
      continueThrough: "^[\\s]+at"

This rule creates a group whenever it sees a line that does not begin with whitespace (the start expression), and continuing through any line that begins with whitespace and the word "at" (the continueThrough expression). It will match Java stack traces in the format shown earlier.

In general, each lineGrouper has a start pattern and a continuation pattern. Whenever a log message containing the start pattern is observed, subsequent lines are then grouped together with that line according to the continuation rule.

If you have multiple lineGroupers, they are evaluated in order. The first rule whose start pattern matches a message, is applied to that message. The continuation pattern is then applied to subsequent messages from the same log.

Four different types of continuation pattern are supported. Each grouping rule should specify a start pattern, plus exactly one of the four continuation patterns:

continueThrough: all consecutive lines matching this pattern are included in the group. The first line (the line that matched the start pattern) does not need to match the continueThrough pattern. This is useful in cases such as a Java stack trace, where some indicator in the line (such as leading whitespace) indicates that it is an extension of the preceding line.

continuePast: all consecutive lines matching this pattern, plus one additional line, are included in the group. This is useful in cases where a log message ends with a continuation marker, such as a backslash, indicating that the following line is part of the same message.

haltBefore: all consecutive lines not matching this pattern are included in the group. This is useful where a log line contains a marker indicating that it begins a new message.

haltWith: all consecutive lines, up to and including the first line matching this pattern, are included in the group. This is useful where a log line ends with a termination marker, such as a semicolon.

Excluding Logs

Sometimes, a glob pattern alone is not expressive enough to capture the exact logs that should be uploaded to Scalyr. Often you are required to specify a more permissive glob pattern that matches more log file names than desired. To deal with such cases, you may specify a list of glob patterns in the exclude field. Any file that matches any exclude pattern from the list will not be sent to Scalyr.

For example, this configuration will copy all log files contained in the directory /var/logs/foo, but exclude those ending in a period and a series of digits (such as .1, .2, typical extensions for rotated logs):

logs: [
     path: "/var/log/foo/*",
     exclude: ["*.[0-9]*"]

You may specify more than one exclude glob pattern.

Renaming Log Files

You may also wish to rename your log file(s) before they are uploaded to the Scalyr servers. For example, your server might have a log file in the location /var/some_really_long_path/mylog.log, but you might want to give it a more concise and searchable name in Scalyr, e.g., /scalyr/access.log

You accomplish this using the rename_logfile option. rename_logfile can be a string (text), or a JSON object. It specifies the new name to use for the log file when uploading it to Scalyr. You can set this name using predefined variables described below.

Example: rename_logfile as a string

logs: [
    path: "/var/some_really_long_path/mylog.log",
    rename_logfile: "/scalyr/access.log"

You can use predefined variables that can be used to specify the log file name.

logs: [
    // To use the same filename but different path, use special variable $BASENAME
    path: "/var/log/some_directory/bar.log",
    rename_logfile: "/scalyr/$BASENAME"

Or keep the same file name without the file extension:

logs: [
    // To exclude the file extension use the $BASENAME_NO_EXT variable.
    // This will rename the file to /scalyr/bar.
    path: "/var/log/some_directory/bar.log",
    rename_logfile: "/scalyr/$BASENAME_NO_EXT"

You can specify multiple files with wildcards:

logs: [
    // You can use wildcards too
    path: "/var/log/some_directory/*.log",
    rename_logfile: "/scalyr/$BASENAME"

A full list of these directives:

Variable Meaning Example
$BASENAME The file name portion of the log file including file extension /scalyr/$BASENAME will upload the file /var/log/foo.log as /scalyr/foo.log
$BASENAME_NO_EXT The file name portion of the log file excluding file extension /scalyr/$BASENAME_NO_EXT will upload the file /var/log/foo.log as /scalyr/foo
$PATH[n] The 'n'th section of the file path /scalyr/$PATH1/$BASENAME will upload the file /var/log/foo.log as /scalyr/log/foo.log

Example: rename_logfile as a JSON object

Use this to match and replace file name(s) with a regular expression. Specifically, add a JSON object (dictionary) to the rename_logfile section with two attributes:

  • match that should match the log file name, and
  • replacement that should be the replacement pattern.

E.g., the following matches all files like /var/log/access123.log, /var/log/access9.log etc. and uploads them as /scalyr/access.log:

    rename_logfile: {
        match: "/var/log/access([0-9]+).log",
        replacement: "/scalyr/access.log"

Or the following uploads /var/log/access12_httpd.log as /scalyr/access_httpd.log and /var/log/access5_info.log as /scalyr/access_info.log:

    rename_logfile: {
        match: "/var/log/access([0-9]+)_([a-z]+).log",
        replacement: "/scalyr/access_\\2.log"

Log Redaction

You can instruct the agent to rewrite or delete certain portions of a log line. This can be used to redact passwords or other sensitive information. Redaction occurs before the log leaves your server; redacted text is not sent to Scalyr.

To use this feature, add a redaction_rules section. For example:

logs: [
     path: "/var/log/app/*.log",
     attributes: {parser: "appLog"},
     redaction_rules: [
       // Delete all instances of password=...
       { match_expression: "password=[^& ]*" },

       // Replace terms like "userInfo=username password" with "userInfo=username"
         match_expression: "userInfo=([^ ]+) [^ ]+",
         replacement: "userInfo=\\1"

Backslashes in a regex must be quoted (by repeating them). For example, the regular expression \d{2} matches a two-digit number; in a match_expression, you would write \\d{2}. This is because the config parser removes one level of backslashes. For more information on using regular expressions in Scalyr, see Regex.

Hashing: To substitute the matched expression with its hashed value, prefix the replacement group with H i.e. in the previous example, change the replacement to userInfo=\\H2. This will replace the matched expression with the hash of the second matched group (i.e. hash of the password). You can optionally set a salt to include with the cryptographic hash. It will look like:

// Replace terms like "userInfo=username password" with "userInfo=md5(password + optional salt E1F53135E559C253)"
   match_expression: "userInfo=([^ ]+) [^ ]+",
   replacement: "userInfo=\\H2",
   hash_salt: "E1F53135E559C253"

We currently only support MD5 hashing algorithm.

Log Rotation Support

The Scalyr agent supports log rotation. If a log is rotated while the agent is copying it to Scalyr, the agent will automatically check for uncopied bytes in the rotated log file before resuming copying from the original file location. The agent supports log rotation using both move and copytruncate. However copytruncate support has a few caveats listed below. No configuration is required to enabled this.

The logrotate copytruncate caveats are:

  • Support on Linux only.
  • Supports both the default number extension and dateext options.
  • If compress is enabled, delaycompress must also be enabled.
  • Only log extension is supported with extension option.

Agent Monitor Plugins

The agent provides additional data gathering tools, packaged as "plugins". There are a wide variety of plugins, for gathering process metrics, performance data from popular software packages such as MySQL, importing data from Graphite- compatible tools, and many more. See the Agent Plugins page for a complete list.

To use an agent plugin, add a clause to the monitors section of agent.json. For example, the following configuration will record process metrics for Tomcat, and will periodically log the Linux kernel version:

monitors: [
    module:          "scalyr_agent.builtin_monitors.linux_process_metrics",
    id:              "tomcat",
    commandline:     "java.*tomcat6"
  }, {
    module:          "scalyr_agent.builtin_monitors.shell_monitor",
    id:              "kernel-version",
    command:         "uname -r",
    sample_interval: 60

You can use the same plugin more than once. For instance, you could use two instances of the linux_process_metrics plugin to record metrics for two different processes.

sample_interval indicates how often data will be collected from that module (the number of seconds between collections). It defaults to 30. Note that built-in modules that collect rate information, such as linux_process_metrics, may yield odd results if a different sample interval is used.

You can create your own agent plugins. Plugins are written in Python, and can be as simple as a few lines of code. See the plugin authoring documentation for details.

On Linux systems, two plugins are enabled by default: the linux_system_metrics plugin (to gather basic system utilization data), and an instance of the linux_process_metrics module to gather resource usage statistics for the Scalyr Agent itself. (On Windows systems, the monitors are called windows_process_metrics and windows_system_metrics, and they are also enabled by default.)

If you don't want the data these monitors provide, disable these plugins by setting the following flags in the agent configuration:

implicit_metric_monitor: false,
implicit_agent_process_metrics_monitor: false,

You can also add a flag to turn off the automatic collection of the agent's diagnostic log (agent.log):

implicit_agent_log_collection: false,

This log is low volume, so normally we recommend that you allow it to be collected.

HTTP Proxies

The Scalyr Agent can be configured to use an HTTPS proxy if one is required to reach the Scalyr servers from your infrastructure. To use a proxy, please add the following to your agent.json configuration file, replacing the https_proxy URL with correct one for your infrastructure:

"use_requests_lib": true,
"https_proxy": ""

Note, you only need to configure a proxy for the HTTPS traffic, since all communication between the Scalyr Agent and Scalyr is done via HTTPS. However, if needed for other plugins, you may also configure an HTTP proxy using the `http_proxy` configuration option similar to `https_proxy` above.

Usually when configuring an HTTPS proxy you will also need to configure CA certificate bundle which agent uses to validate the server side certificate (in this case the HTTPS proxy one).

You can do that using ca_cert_path config option to point to your HTTPS proxy CA file as shown below:

// By default agent utilizes CA certs from /usr/share/scalyr-agent-2/certs/ca_certs
"ca_cert_path": "/home/user/.mitmproxy/mitmproxy-ca-cert.pem",

If you don't have direct access to the proxy CA bundle / certificate, you can also download it using openssl command:

openssl s_client -connect localhost:<proxy https port> -showcerts </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/proxy-ca-cert.crt

If your proxy requires authentication, you can specify credentials in the URI in this format: https://<username>:<password> as shown below:

"use_requests_lib": true,
"https_proxy": ""

Keep in mind that right now only HTTP Basic Auth is supported for proxies (HTTP Digest authentication is not supported).

Agent Status

The agent can report detailed status information about itself. This is useful for troubleshooting, e.g., if a log is not showing up in the Scalyr search UI.

On Linux, execute the following command. Note, you must be running as the same user as the agent (often root):

sudo scalyr-agent-2 status -v

On Windows, execute this command. You must be running as a user in the Administrators group and you may be asked to provide credentials:

scalyr-agent-2.exe status -v

If the agent is running, you should see a detailed report written to stdout. The report will include information about the agent process, configuration file(s), logs being copied, and monitor plugins. Note that some of the information applies only to the time period since the agent was last restarted or from when the agent's configuration was last updated.

Agent Logs

For diagnostic purposes, you may sometimes need to look at the agent's own log output. On Linux systems, the agent's logs are in this directory:


On Windows systems, the logs directory is:

C:\Program Files (x86)\Scalyr\logs

Most information of interest is in the file agent.log. This log file contains all errors generated by the agent. This directory also contains log files used for the metrics recorded by the agent as well as any plugins.


The latest agent release is 2.1.25. To determine which version you're running:

scalyr-agent-2 version

To upgrade the agent to the latest version, follow the appropriate instructions, according to the method you used to install the agent.

If you installed using yum

sudo yum update scalyr-agent-2

If you installed using apt-get

sudo apt-get install scalyr-agent-2

If you downloaded the RPM or Debian package directly

Get the latest build (see Package Download) and run one of the following commands:

sudo rpm -U scalyr-agent-2-2.1.25-1.noarch.rpm      # RPM
sudo rpm -U scalyr-agent-2-2.1.25-1.alt.noarch.rpm  # RPM for older sytems (CentOS 5, RHEL5)
sudo dpkg -i scalyr-agent-2_2.1.25_all.deb          # Debian package

If you installed by downloading the agent tarball

wget -q
scalyr-agent-2-config --upgrade-tarball scalyr-agent-2.1.25.tar.gz

On a Windows system

NOTE: The packaging process for the windows version of the agent has changed significantly in version 2.1.7 and if you have a prior version installed, please uninstall it manually from the Control Panel -> Uninstall a program and then install new one using windows install instruction.

Please, be on the safe side and do not forget to backup all config files.

There is no need to uninstall the previous version if it is greater than 2.1.6, just use the link above to install the new version.

Uninstalling the Agent

To remove the Scalyr Agent from a server, follow the appropriate instructions for your system.

If you installed using yum

sudo yum remove scalyr-agent-2
sudo yum remove scalyr-repo

If you installed using apt-get

sudo apt-get remove scalyr-agent-2
sudo apt-get remove scalyr-repo

If you installed by downloading the agent tarball

sudo scalyr-agent-2 stop

and then delete the directory where you unpacked the agent tarball.

On a Windows system

Use the Windows control panel in the usual fashion to remove the Scalyr application.

Troubleshooting: no data from host

If you are not seeing the data you expect on the Scalyr web site, the first step is to check whether the agent is uploading any data at all. Click the Overview link in the navigation bar, find the host in question, and click on the System dashboard link for that host. If the host does not appear, or the dashboard does not show any data, then the agent on that host is not running or is not successfully communicating with Scalyr.

To diagnose this, run the following command (Linux):

sudo scalyr-agent-2 status -v

For Windows:

scalyr-agent-2.exe status -v

This may tell you that the agent is not running. If so, try launching it (Linux):

sudo scalyr-agent-2 start

For Windows:

scalyr-agent-2.exe start

As a cross-check to verify whether the agent is running, you can execute ps aux | grep scalyr-agent. The output should include a command along the lines of python scalyr-agent-2.

When you start the agent, you may see an error message indicating that you have an incorrect API token. In this case, open agent.json, find the api_key line, and edit it so that it contains your key:

(log in to see your API token)

Make sure to include any trailing hyphen when copy/pasting the API key. Then launch the agent again.

If the agent is already running, the output of sudo scalyr-agent-2 status -v may contain information regarding any problems. If the agent is successfully sending data to Scalyr, you should see a message like this:

Last copy response status: 'success'

If it is having problems, you may instead see something like this:

Last copy response status: 'error/client/badParam'
Last copy response: '{   "message": "Couldn't decode API token ...xxxxx.",   "status": "error/client/badParam" }'

The error message should help you narrow down the problem. If the agent reports a network problem, you might check to see whether your host can connect to Scalyr or other public servers:


Always feel free to drop us a line at for assistance.

Troubleshooting: log not present

If the agent is running, but is not uploading a particular log file, check the agent status (Linux):

sudo scalyr-agent-2 status -v

For Windows:

scalyr-agent-2.exe status -v

Look for a status message for the log path in question. It should look like this:

Path /var/log/tomcat6/access_log: copied 19621786 bytes (178843 lines), 0 bytes pending, last checked Tue Aug 19 18:08:02 2014 UTC

If you don't see any such message, open agent.json, "logs" section, and verify that it contains an appropriate entry for the log file. For instance:

logs: [

    path: "/var/log/tomcat6/access_log",
    attributes: {parser: "accessLog"}

If the agent status does not contain a "Path" line in the status output but also contains text like "no matching readable file", then the log file may not exist, or its permissions may not allow reading by the user under which the agent is running. Verify that the path you've specified in the agent configuration matches the absolute path of your log file, and the user under which the agent is running has read access to the log and its parent directories. (To double-check the user under which the agent is running, look for "Executing user" in the agent status output.)

To run the agent as a different user, execute

sudo scalyr-agent-2-config --set-user XXXX

(where XXXX is the new username) and then restart the agent.

Note, only Linux can run the agent as a different user. On Windows, the agent is always run as Administrator.

Package Download

If you wish to install the Scalyr Agent packages yourself, you may download them from the following URLs. You must select which package is appropriate for your system.

For systems that use yum (except CentOS 5 or RHEL5), download the RPM from:

For systems that use apt-get, download the Debian package from:

For older distributions such as CentOS 5 or Redhat Enteprise Linux 5, download this RPM:

For systems that do not use yum or apt-get, you may download a tarball from here:

For Windows system, you can download an installer from:

Building Your Own Package

You can build your own custom scalyr-agent-2. This can be helpful if you wish to deploy custom plugins with your agent, or repackage the agent in some way that better fits your needs. You can create custom RPM, Debian, or tarball packages.

To learn how to create your own packages, please see the instructions hosted on the agent code repository.

SSL Requirements

All communication between the Scalyr Agent and Scalyr's servers is encrypted using SSL.

The agent is only able to verify SSL certificates if your system has the Python SSL package. Without the SSL package, communication is still encrypted, but an adversary with the ability to intercept and modify packets on your network could theoretically perform a MiTM attack and view or modify your log traffic.

To check whether a server has the SSL module installed, execute the following command:

python -m ssl

If it gives no output, you're all set. If you get a message like:

/usr/bin/python: No module named ssl

then you do not have the Python SSL module. The home page for this module is If your system supports pip, you can install it using:

pip install ssl

Otherwise, if you'd like to install the SSL module, contact us at for help.

Source Code

The source code for the agent is available on GitHub. Feel free to look around! We welcome requests, feedback, and bug reports.

If you are using the "classic" Scalyr Agent (most installations prior to late September 2014), see Scalyr Agent Classic for documentation. We encourage you to upgrade to the current agent; see Migrating from Scalyr Agent Classic. If you're not sure which agent you're using: if ps aux | grep 'scalyr-agent-[2]' has any output, then you're running the current agent.