signalfx-agent

module
v4.2.0+incompatible Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Mar 18, 2019 License: Apache-2.0

README

SignalFx Smart Agent

GoDoc CircleCI

The SignalFx Smart Agent is a metric agent written in Go for monitoring infrastructure and application services in a variety of different environments. It is meant as a successor to our previous collectd agent, but still uses that internally on Linux -- so any existing Python or C-based collectd plugins will still work without modification. On Windows collectd is not included, but the agent is capable of running python based collectd plugins without collectd. C-based collectd plugins are not available on Windows.

Concepts

The agent has three main components:

  1. Observers that discover applications and services running on the host
  2. Monitors that collect metrics from the host and applications
  3. The Writer that sends the metrics collected by monitors to SignalFx.
Observers

Observers watch the various environments that we support to discover running services and automatically configure the agent to send metrics for those services.

For a list of supported observers and their configurations, see Observer Config.

Monitors

Monitors collect metrics from the host system and services. They are configured under the monitors list in the agent config. For application-specific monitors, you can define discovery rules in your monitor configuration. A separate monitor instance is created for each discovered instance of applications that match a discovery rule. See Auto Discovery for more information.

Many of the monitors are built around collectd, an open source third-party monitor, and use it to collect metrics. Some other monitors do not use collectd. However, either type is configured in the same way.

For a list of supported monitors and their configurations, see Monitor Config.

The agent is primarily intended to monitor services/applications running on the same host as the agent. This is in keeping with the collectd model. The main issue with monitoring services on other hosts is that the host dimension that collectd sets on all metrics will currently get set to the hostname of the machine that the agent is running on. This allows everything to have a consistent host dimension so that metrics can be matched to a specific machine during metric analysis.

Writer

The writer collects metrics emitted by the configured monitors and sends them to SignalFx on a regular basis. There are a few things that can be configured in the writer, but this is generally only necessary if you have a very large number of metrics flowing through a single agent.

Installation

The agent is available for Linux in both a containerized and standalone form. Whatever form you use, the dependencies are completely bundled along with the agent, including a Java JRE runtime and a Python runtime, so there are no additional dependencies required. This means that the agent should work on any relatively modern Linux distribution (kernel version 2.6+).

The agent is also available on Windows in standalone form. It contains its own Python runtime, but has an external depencency on the Visual C++ Compiler for Python 2.7 in order to operate. The agent supports Windows Server 2008 and above.

To get started deploying the Smart Agent directly on a host, see the Smart Agent Quickstart guide.

Deployment

We support the following deployment/configuration management tools to automate the installation process. See Bundles for a list of underlying packages for the agent.

Installer Script

For non-containerized environments, there is a convenience script that you can run on your host to install the agent package. This is useful for testing and trials, but for full-scale deployments you will probably want to use a configuration management system like Chef or Puppet.

Linux

You can view the source for the installer script and use it on your hosts by running:

curl -sSL https://dl.signalfx.com/signalfx-agent.sh > /tmp/signalfx-agent.sh
sudo sh /tmp/signalfx-agent.sh YOUR_SIGNALFX_API_TOKEN
Windows

The Agent has two dependencies on Windows which must be satisfied before running the installer script.

The installer script is written for Powershell v3.0 and above and will not function correctly on earlier versions.

Once the dependencies have been installed, please run the installer script below. You can view the source for the installer script and use it on your hosts in powershell by running:

& {Set-ExecutionPolicy Bypass -Scope Process -Force; $script = ((New-Object System.Net.WebClient).DownloadString('https://dl.signalfx.com/signalfx-agent.ps1')); $params = @{access_token = "YOUR_SIGNALFX_API_TOKEN"}; Invoke-Command -ScriptBlock ([scriptblock]::Create(". {$script} $(&{$args} @params)"))}

The agent should be installed to \Program Files\SignalFx\SignalFxAgent, and the default configuration file should be installed at \ProgramData\SignalFxAgent.

Chef

We offer a Chef cookbook to install and configure the agent. See the cookbook source and on the Chef Supermarket.

Puppet

We also offer a Puppet manifest to install and configure the agent on Linux. See the manifest source and on the Puppet Forge.

Ansible

We also offer an Ansible Role to install and configure the Smart Agent on Linux. See the role source.

Salt

We also offer a Salt Formula to install and configure the Smart Agent on Linux. See the formula source.

Docker Image

See Docker Deployment for more information.

Kubernetes

See our Kubernetes setup instructions and the documentation on Monitoring Kubernetes for more information.

AWS Elastic Container Service (ECS)

See the ECS directory, which includes a sample config and task definition for the agent.

Bundles

We offer the agent in the following forms:

Debian Package

We provide a Debian package repository that you can make use of with the following commands:

curl -sSL https://dl.signalfx.com/debian.gpg > /etc/apt/trusted.gpg.d/signalfx.gpg
echo 'deb https://dl.signalfx.com/debs/signalfx-agent/final /' > /etc/apt/sources.list.d/signalfx-agent.list
apt-get update
apt-get install -y signalfx-agent
RPM Package

We provide a RHEL/RPM package repository that you can make use of with the following commands:

cat <<EOH > /etc/yum.repos.d/signalfx-agent.repo
[signalfx-agent]
name=SignalFx Agent Repository
baseurl=https://dl.signalfx.com/rpms/signalfx-agent/final
gpgcheck=1
gpgkey=https://dl.signalfx.com/yum-rpm.key
enabled=1
EOH

yum install -y signalfx-agent
Linux Standalone tar.gz

If you don't want to use a distro package, we offer a .tar.gz that can be deployed to the target host. This bundle is available for download on the Github Releases Page for each new release.

To use the bundle:

  1. Unarchive it to a directory of your choice on the target system.

  2. Ensure a valid configuration file is available somewhere on the target system. The main thing that the distro packages provide -- but that you will have to provide manually with the bundle -- is a run directory for the agent to use. Since you aren't installing from a package, there are three config options that you will especially want to consider:

  • internalStatusHost - This is the host name that the agent will listen on so that the signalfx-agent status command can read diagnostic information from a running agent. This is also the host name the agent will listen on to serve internal metrics about the agent. These metrics can can be scraped by the internal-metrics monitor. This will default to localhost if left blank.

  • internalStatusPort - This is the port that the agent will listen on so that the signalfx-agent status command can read diagnostic information from a running agent. This is also the host name the agent will listen on to serve internal metrics about the agent. These metrics can can be scraped by the internal-metrics monitor. This will default to 8095.

  • collectd.configDir - This is where the agent writes the managed collectd config, since collectd can only be configured by files. Note that this entire dir will be wiped by the agent upon startup so that it doesn't pick up stale collectd config, so be sure that it is not used for anything else. Also note that these files could have sensitive information in them if you have passwords configured for collectd monitors, so you might want to place this dir on a tmpfs mount to avoid credentials persisting on disk.

See the section on Privileges for information on the capabilities the agent requires.

  1. Run the agent by invoking the archive path signalfx-agent/bin/signalfx-agent -config <path to config.yaml>. By default, the agent logs only to stdout/err. If you want to persist logs, you must direct the output to a log file or other log management system. See the signalfx-agent command doc for more information on supported command flags.
Windows Standalone .zip

If you don't want to use the installer script, we offer a .zip that can be deployed to the target host. This bundle is available for download on the Github Releases Page for each new release.

Before proceeding make sure the following requirements are met.

To use the bundle:

  1. Unzip it to a directory of your choice on the target system.

  2. Ensure a valid configuration file is available somewhere on the target system. The main thing that the installer script provides -- but that you will have to provide manually with the bundle -- is a run directory for the agent to use. Since you aren't installing from a package, there are two config options that you will especially want to consider:

  • internalStatusHost - This is the host name that the agent will listen on so that the signalfx-agent status command can read diagnostic information from a running agent. This is also the host name the agent will listen on to serve internal metrics about the agent. These metrics can can be scraped by the internal-metrics monitor. This will default to localhost if left blank.

  • internalStatusPort - This is the port that the agent will listen on so that the signalfx-agent status command can read diagnostic information from a running agent. This is also the host name the agent will listen on to serve internal metrics about the agent. These metrics can can be scraped by the internal-metrics monitor. This will default to 8095.

See the section on Privileges for information on the capabilities the agent requires.

  1. Run the agent by invoking the agent executable SignalFxAgent\bin\signalfx-agent.exe -config <path to config.yaml>. By default, the agent logs only to stdout/err. If you want to persist logs, you must direct the output to a log file or other log management system. See the signalfx-agent command doc for more information on supported command flags.

  2. You may optionally install the agent as a Windows service by invoking the agent executable and specifying a few command line flags. The examples below show how to do install and start the agent as a Windows service.

  • Install Service

      PS> SignalFx\SignalFxAgent\bin\signalfx-agent.exe -service "install" -logEvents -config <path to config file>
    
  • Start Service

      PS> SignalFx\SignalFxAgent\bin\signalfx-agent.exe -service "start"
    
Privileges
Linux

When using the host observer, the agent requires the Linux capabilities DAC_READ_SEARCH and SYS_PTRACE, both of which are necessary to allow the agent to determine which processes are listening on network ports on the host. Otherwise, there is nothing built into the agent that requires privileges. When using a package to install the agent, the agent binary is given those capabilities in the package post-install script, but the agent is run as the signalfx-agent user. If you are not using the host observer, then you can strip those capabilities from the agent binary if so desired.

You should generally not run the agent as root unless you can't use capabilities for some reason.

Windows

On Windows the agent must be installed and run under an administrator account.

Configuration

The agent is configured primarily from a YAML file. By default, the agent config is installed at and looked for at /etc/signalfx/agent.yaml on Linux and \ProgramData\SignalFxAgent\agent.yaml on Windows. This can be overridden by the -config command line flag.

For the full schema of the config, see Config Schema.

For information on how to configure the agent from remote sources, such as other files on the filesystem or KV stores such as Etcd, see Remote Configuration.

Logging

Linux

Currently the agent only supports logging to stdout/stderr, which will generally be redirected by the init scripts we provide to either a file at /var/log/signalfx-agent.log or to the systemd journal on newer distros. The default log level is info, which will log anything noteworthy in the agent without spamming the logs too much. Most of the info level logs are on startup and upon service discovery changes. debug will create very verbose log output and should only be used when trying to resolve a problem with the agent.

Windows

On Windows, the agent will log to the console when executed directly in a shell. If the agent is configured as a windows service, log events will be logged to the Windows Event Log. Use the Event Viewer application to read the logs. The Event Viewer is located under Start > Administrative Tools > Event Viewer. You can see logged events from the agent service under Windows Logs > Application.

Proxy Support

To use an HTTP(S) proxy, set the environment variable HTTP_PROXY and/or HTTPS_PROXY in the container configuration to proxy either protocol. The SignalFx ingest and API servers both use HTTPS. If the NO_PROXY envvar exists, the agent will automatically append the local services to the envvar to not use the proxy.

If the agent is running as a local service on the host, refer to the host's service management documentation for how to pass environment variables to the agent service in order to enable proxy support when the agent service is started.

For example, if the host services are managed by systemd, create the /etc/systemd/system/signalfx-agent.service.d/myproxy.conf file and add the following to the file:

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:8080/"
Environment="HTTPS_PROXY=https://proxy.example.com:8081/"

Then execute systemctl daemon-reload and systemctl restart signalfx-agent.service to restart the agent service with proxy support.

Diagnostics

The agent serves diagnostic information on a UNIX domain socket at the path configured by the diagnosticsSocketPath option. The socket takes no input, but simply dumps its current status back upon connection. As a convenience, the command signalfx-agent status will read this socket and dump out its contents.

The agent status output has the following sections:

  • Version: The agent version and build time
  • Agent Configuration: The current configuration in use by the agent, with secret values replaced by *s. Default values will be shown here if they were not set in the agent config file.
  • Writer Status: The status and metrics about the writer component which writes datapoints to SignalFx.
  • Observers: The active observers in the agent
  • Monitor Configurations (Not necessarily active): A list of monitor configurations that are in place. If a configuration has a discovery rule but no discovered endpoints match that rule, there will not be any active instances of this monitor.
  • Active Monitors: Monitors instances that are actively monitoring something. There may be multiple instances of these per configuration above if there is a discovery rule that matches multiple services.
  • Discovered Endpoints: A list of the endpoints discovered by the agent's observers. The fields shown there will be the fields used when matching discovery rules to a discovered endpoint.
  • Bad Monitor Configurations: This will be a set of monitor configurations that did not validate and the associated error. Bad monitor configuration generally does not prevent the agent from starting up, but will prevent that monitor from ever instantiating.

Also see our FAQ for more troubleshooting help.

Development

If you wish to contribute to the agent, see the Developer's Guide.

Directories

Path Synopsis
cmd
fakek8s
Package main contains a simple wrapper for the Fake K8s API Server to run it standalone
Package main contains a simple wrapper for the Fake K8s API Server to run it standalone
internal
core
Package core contains the central frame of the agent that hooks up the various subsystems.
Package core contains the central frame of the agent that hooks up the various subsystems.
core/config
Package config contains configuration structures and related helper logic for all agent components.
Package config contains configuration structures and related helper logic for all agent components.
core/config/sources
Package sources contains all of the config source logic.
Package sources contains all of the config source logic.
core/config/sources/vault
Package vault contains the logic for using Vault as a remote config source How to use auth methods with Vault Go client: https://groups.google.com/forum/#!msg/vault-tool/cS7J2KbAwZg/7pu6PYSRAAAJ
Package vault contains the logic for using Vault as a remote config source How to use auth methods with Vault Go client: https://groups.google.com/forum/#!msg/vault-tool/cS7J2KbAwZg/7pu6PYSRAAAJ
core/config/sources/zookeeper
Package zookeeper contains the logic for using Zookeeper as a config source.
Package zookeeper contains the logic for using Zookeeper as a config source.
core/dpfilters
Package dpfilters has logic describing the filtering of unwanted metrics.
Package dpfilters has logic describing the filtering of unwanted metrics.
core/hostid
Package hostid contains methods that can be called upon agent start up to determine host-specific values that uniquely identify a particular host, particularly ids that can be used to correlate metrics coming from this host to other metrics generated elsewhere, such as AWS CloudWatch metrics.
Package hostid contains methods that can be called upon agent start up to determine host-specific values that uniquely identify a particular host, particularly ids that can be used to correlate metrics coming from this host to other metrics generated elsewhere, such as AWS CloudWatch metrics.
core/propfilters
Package propfilters has logic describing the filtering of unwanted properties.
Package propfilters has logic describing the filtering of unwanted properties.
core/services
Package services has service endpoint types.
Package services has service endpoint types.
core/writer
Package writer contains the SignalFx writer.
Package writer contains the SignalFx writer.
monitors
Package monitors is the core logic for monitors.
Package monitors is the core logic for monitors.
monitors/cadvisor
Package cadvisor contains a monitor that pulls cadvisor stats either directly from cadvisor or from the kubelet /stats endpoint that exposes cadvisor.
Package cadvisor contains a monitor that pulls cadvisor stats either directly from cadvisor or from the kubelet /stats endpoint that exposes cadvisor.
monitors/collectd/activemq
Package activemq has an ActiveMQ Collectd monitor that uses GenericJMX
Package activemq has an ActiveMQ Collectd monitor that uses GenericJMX
monitors/collectd/custom
Package custom contains a custom collectd plugin monitor, for which you can specify your own config template and parameters.
Package custom contains a custom collectd plugin monitor, for which you can specify your own config template and parameters.
monitors/collectd/genericjmx
Package genericjmx coordinates the various monitors that rely on the GenericJMX Collectd plugin to pull JMX metrics.
Package genericjmx coordinates the various monitors that rely on the GenericJMX Collectd plugin to pull JMX metrics.
monitors/collectd/netinterface
Package netinterface wraps the "interface" collectd plugin for gather network interface metrics.
Package netinterface wraps the "interface" collectd plugin for gather network interface metrics.
monitors/docker
Package docker contains a monitor for getting metrics about containers running in a docker engine.
Package docker contains a monitor for getting metrics about containers running in a docker engine.
monitors/ecs
Package ecs contains a monitor for getting metrics about containers running in a docker engine.
Package ecs contains a monitor for getting metrics about containers running in a docker engine.
monitors/kubernetes/cluster
Package cluster contains a Kubernetes cluster monitor.
Package cluster contains a Kubernetes cluster monitor.
monitors/pyrunner
Package pyrunner holds the logic for managing Python plugins using a subprocess running Python.
Package pyrunner holds the logic for managing Python plugins using a subprocess running Python.
monitors/types
Package types exists to avoid circular references between things that need to reference common types
Package types exists to avoid circular references between things that need to reference common types
observers
Package observers contains the core logic for observers, which are what observe the environment to discover running services.
Package observers contains the core logic for observers, which are what observe the environment to discover running services.
observers/docker
Package docker is an observer that watches a docker daemon and reports container ports as service endpoints.
Package docker is an observer that watches a docker daemon and reports container ports as service endpoints.
observers/ecs
Package ecs is a file-based observer that is primarily meant for development and test purposes.
Package ecs is a file-based observer that is primarily meant for development and test purposes.
observers/file
Package file is a file-based observer that is primarily meant for development and test purposes.
Package file is a file-based observer that is primarily meant for development and test purposes.
observers/host
Package host observer that monitors the current host for active network listeners and reports them as service endpoints Use of this observer requires the CAP_SYS_PTRACE and CAP_DAC_READ_SEARCH capability in Linux.
Package host observer that monitors the current host for active network listeners and reports them as service endpoints Use of this observer requires the CAP_SYS_PTRACE and CAP_DAC_READ_SEARCH capability in Linux.
observers/kubernetes
Package kubernetes contains an observer that watches the Kubernetes API for pods that are running on the same node as the agent.
Package kubernetes contains an observer that watches the Kubernetes API for pods that are running on the same node as the agent.
selfdescribe
Package selfdescribe contains code that knows how to pull metadata from various agent component out into a well structured format that can be fed into other workflows to generate documentation or other resources such as chef recipies.
Package selfdescribe contains code that knows how to pull metadata from various agent component out into a well structured format that can be fed into other workflows to generate documentation or other resources such as chef recipies.
utils
Package utils hold miscelaneous utility functions
Package utils hold miscelaneous utility functions
utils/filter
Package filter contains common filtering logic that can be used to filter datapoints or various resources within other agent components, such as monitors.
Package filter contains common filtering logic that can be used to filter datapoints or various resources within other agent components, such as monitors.
pkg
apm Module

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL