(Legacy) Integrate Applications (Default App Checks)
We are sunsetting application checks in favor of Monitoring Integrations.
The Sysdig agent supports application monitoring with application check scripts or “app checks”. These are a set of plugins that poll for custom metrics from the specific applications which export them via status or management pages. For example, NGINX, Redis, MongoDB, Memcached and more.
Many app checks are enabled by default in the agent and when a supported application is found, the correct app check script will be called and metrics polled automatically.
However, if default connection parameters are changed in your
application, you will need to modify the app check connection parameters
in the Sysdig Agent configuration file (dragent.yaml)
to match your
application.
In some cases, you may also need to enable the metrics reporting functionality in the application before the agent can poll them.
This page details how to make configuration changes in the agent’s configuration file, and provides an application integration example. Click the Supported Applications links for application-specific details.
Python Version for App Checks:
As of agent version 9.9.0, the default version of Python used for app checks is Python 3.
Python 2 can still be used by setting the following option in your
dragent.yaml
:
python_binary: <path to python 2.7 binary>
For containerized agents, this path will be: /usr/bin/python2.7
Edit dragent.yaml to Integrate or Modify Application Checks
Out of the box, the Sysdig agent will gather and report on a wide variety of pre-defined metrics. It can also accommodate any number of custom parameters for additional metrics collection.
The agent relies on a pair of configuration files to define metrics collection parameters:
| The core configuration file. You can look at it to understand more about the default configurations provided. Location: " CAUTION. This file should never be edited. |
| The configuration file where parameters can be added, either directly in YAML as |
The “dragent.yaml
” file can be accessed and edited in several ways,
depending on how the agent was installed.
Review Understanding the Agent Config Files for details.
The examples in this section presume you are entering YAML code directly
intodragent.yaml,
under the app_checks
section.
Find the default settings
To find the default app-checks for already supported applications, check
the dragent.default.yaml
file.
(Location: /opt/draios/etc/dragent.default.yaml
.)
Sample format
app_checks:
- name: APP_NAME
check_module: APP_CHECK_SCRIPT
pattern:
comm: PROCESS_NAME
conf:
host: IP_ADDR
port: PORT
Parameter | Parameter 2 | Description | Sample Value |
---|---|---|---|
| The main section of | n/a | |
| Every check should have a unique | e.g. MongoDB | |
| The name of the Python plugin that polls the data from the designated application. All the app check scripts can be found inside the | e.g. elastic | |
| This section is used by the Sysdig agent to match a process with a check. Four kinds of keys can be specified along with any arguments to help distinguish them. | n/a | |
| Matches process name as seen in /proc/ | ||
| Matches based on the port used (i.e MySQL identified by 'port: 3306') | ||
| Matches any process arguments | ||
| Matches the process exe as seen in /proc/ | ||
| This section is specific for each plugin. You can specify any key/values that the plugins support. | ||
| Application-specific. A URL or IP address | ||
|
{…}
tokens can be used as values, which will be substituted with
values from process info.
Change the default settings
To override the defaults:
Copy relevant code blocks from
dragent.default.yaml
intodragent.yaml
. (Or copy the code from the appropriate app check integration page in this documentation section.)Any entries copied into
dragent.yaml
file will override similar entries indragent.default.yaml
.Never modify
dragent.default.yaml
, as it will be overwritten whenever the agent is updated.Modify the parameters as needed.
Be sure to use proper YAML. Pay attention to consistent spacing for indents (as shown) and list all check entries under an
app_checks:
section title.Save the changes and restart the agent.
Use
service restart agent
ordocker restart sysdig-agent
.
Metrics for the relevant application should appear in the Sysdig Monitor interface under the appropriate name.
Example 1: Change Name and Add Password
Here is a sample app-check entry for Redis. The app_checks
section was
copied from the dragent.default.yaml
file and modified for a specific
instance.
customerid: 831f3-Your-Access-Key-9401
tags: local:sf,acct:dev,svc:db
app_checks:
- name: redis-6380
check_module: redisdb
pattern:
comm: redis-server
conf:
host: 127.0.0.1
port: PORT
password: PASSWORD
Edits made:
The name to be displayed in the interface
A required password.
As the token PORT
is used, it will be translated to the actual port
where Redis is listening.
Example 2: Increase Polling Interval
The default interval for an application check to be run by the agent is set to every second. You can increase the interval per application check by adding the interval: parameter (under the -name section) and the number of seconds to wait before each run of the script.
interval:
must be put into each app check entry that should run less
often; there is no global setting.
Example: Run the NTP check once per minute:
app_checks:
- name: ntp
interval: 60
pattern:
comm: systemd
conf:
host: us.pool.ntp.org
Disabling
Disable a Single Application Check
Sometimes the default configuration shipped with the Sysdig agent does not work for you or you may not be interested in checks for a single application. To turn a single check off, add an entry like this to disable it:
app_checks:
- name: nginx
enabled: false
This entry overrides the default configuration of the nginx
check,
disabling it.
If you are using the ADDITIONAL_CONF
parameter to modify your
container agent’s configuration, you would add an entry like this to
your Docker run command (or Kubernetes manifest):
-e ADDITIONAL_CONF="app_checks:\n - name: nginx\n enabled: false\n"
Disable ALL Application Checks
If you do not need it or otherwise want to disable the application check
functionality, you can add the following entry to the agent’s user
settings configuration file /opt/draios/etc/dragent.yaml
:
app_checks_enabled: false
Restart the agent as shown immediately above for either the native Linux agent installation or the container agent installation.
Optional: Configure a Custom App-Check
Sysdig allows custom application check-script configurations to be
created for each individual container in the infrastructure, via the
environment variable SYSDIG_AGENT_CONF
. This avoids the need for
multiple edits and entries to achieve the container-specific
customization, by enabling application teams to configure their own
checks.
The SYSDIG_AGENT_CONF
variable stores a YAML-formatted configuration
for the app check, and is used to match app-check configurations. It can
be stored directly within the Docker file.
The syntax is the same as dragent.yaml
syntax.
The example below defines a per container app-check for Redis in the
Dockerfile, using the SYSDIG_AGENT_CONF
environment variable:
FROM redis
# This config file adds a password for accessing redis instance
ADD redis.conf /
ENV SYSDIG_AGENT_CONF { "app_checks": [{ "name": "redis", "check_module": "redisdb", "pattern": {"comm": "redis-server"}, "conf": { "host": "127.0.0.1", "port": "6379", "password": "protected"} }] }
ENTRYPOINT ["redis-server"]
CMD [ "/redis.conf" ]
The example below shows how parameters can be added to a container
started with docker run
, by either using the -e/–envflag
variable,
or injecting the parameters using an orchestration system (for example,
Kubernetes):
PER_CONTAINER_CONF='{ "app_checks": [{ "name": "redis", "check_module": "redisdb", "pattern": {"comm": "redis-server"}, "conf": { "host": "127.0.0.1", "port": "6379", "password": "protected"} }] }'
docker run --name redis -v /tmp/redis.conf:/etc/redis.conf -e SYSDIG_AGENT_CONF="${PER_CONTAINER_CONF}" -d redis /etc/redis.conf
Metrics Limit
Metric limits are defined by your payment plan. If more metrics are needed please contact your sales representative with your use case.
Note that a metric with the same name but different tag name will count
as a unique metric by the agent. Example: a metric 'user.clicks'
with
the tag 'country=us'
and another 'user.clicks'
with the
'tag country=it'
are considered two metrics which count towards the
limit.
Supported Applications
Below is the supported list of applications the agent will automatically poll.
Some app-check scripts will need to be configured since no defaults exist, while some applications may need to be configured to output their metrics. Click a highlighted link to see application-specific notes.
- Active MQ
- Apache
- Apache CouchDB
- Apache HBase
- Apache Kafka
- Apache Zookeeper
- Consul
- Couchbase
- Elasticsearch
- etcd
- fluentd
- Go
- HAProxy
- HDFS
- HTTP
- Jenkins
- JVM
- Lighttpd
- Memcached
- Mesos/Marathon
- MongoDB
- MySQL
- NGINX and NGINX Plus
- NTP
- PGBouncer
- PHP-FPM
- Postfix
- PostgreSQL
- Prometheus
- RabbitMQ
- RedisDB
- Supervisord
- SNMP
- TCP
You can also
Feedback
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.