Infrastructure and Discovery monitoring modes
If you don't need your OneAgent to run in the full-stack monitoring mode, you can also use one of the two lightweight modes that provide you with the subset of OneAgent metrics, focusing on your host infrastructure:
Infrastructure Monitoring mode
Discovery mode
The table below shows an overview of available monitoring options for each of the monitoring modes.
| Discovery | Infrastructure | Full stack | |
|---|---|---|---|
| Topology discovery (hybrid cloud discovery and Smartscape) |  | | |
| Host criticality (detection of external services and app dependencies) | | | |
| Basic monitoring (host health, filesystem monitoring, OS Services Monitoring) | | | |
| Host process details | | | |
| Detailed disk analysis | | | |
| Network analysis | | | |
| Memory analysis | | | |
| Extensions | opt-in | opt-in | |
| Custom metrics | 100 / host | 15 / 256 MiB | |
| Log Management | opt-in | opt-in | opt-in |
| Tracing and profiling | | ||
| Application Security | opt-in | opt-in | opt-in |
For more information on Infrastructure Monitoring and Discovery modes for Application Security, see Application Security and monitoring modes
Discovery mode
OneAgent version 1.281+
OneAgent discovery mode provides basic metrics enabling you to discover your hosts and processes and learn the potential to extend your monitoring.
We recommend that you deploy OneAgent in Full-Stack Monitoring mode to monitor your business-critical applications. Similarly, we recommend that you monitor critical infrastructure, like databases, queues, and messaging systems with Infrastructure Monitoring. OneAgent in Discovery mode can be deployed across the remainder of your infrastructure for full visibility thanks to its relatively low cost.
Discovery mode is available only if you're using the Dynatrace Platform Subscription model. License consumption is via the Foundation & Discovery capability. To learn more, see Host monitoring (DPS). Discovery mode is currently available for Dynatrace SaaS, but will be added for Dynatrace Managed at a later date.
The following built-in metrics are available in the Discovery mode:
CPU
| Metric key | Name and description | Unit | Aggregations |
|---|---|---|---|
| builtin:host | AIX Entitlement configured Capacity Entitlement is the number of virtual processors assigned to the AIX partition. It’s measured in fractions of processor equal to 0.1 or 0.01. For more information about entitlement, see [Assigning the appropriate processor entitled capacity](https://dt-url.net/3n234vz) in official IMB documentation. | Ratio | autoavgmaxmin |
| builtin:host | AIX Entitlement used Percentage of entitlement used. Capacity Entitlement is the number of virtual cores assigned to the AIX partition. See For more information about entitlement, see [Assigning the appropriate processor entitled capacity](https://dt-url.net/3n234vz) in official IMB documentation. | Percent (%) | autoavgmaxmin |
| builtin:host | CPU idle Average CPU time, when the CPU didn't have anything to do | Percent (%) | autoavgmaxmin |
| builtin:host | CPU I/O wait Percentage of time when CPU was idle during which the system had an outstanding I/O request. It is not available on Windows. | Percent (%) | autoavgmaxmin |
| builtin:host | System load The average number of processes that are being executed by CPU or waiting to be executed by CPU over the last minute | Ratio | autoavgmaxmin |
| builtin:host | System load15m The average number of processes that are being executed by CPU or waiting to be executed by CPU over the last 15 minutes | Ratio | autoavgmaxmin |
| builtin:host | System load5m The average number of processes that are being executed by CPU or waiting to be executed by CPU over the last 5 minutes | Ratio | autoavgmaxmin |
| builtin:host | CPU other Average CPU time spent on other tasks: servicing interrupt requests (IRQ), running virtual machines under the control of the host's kernel (It means the host is a hypervisor for VMs). It's available only for Linux hosts | Percent (%) | autoavgmaxmin |
| builtin:host | AIX Physical consumed Total CPUs consumed by the AIX partition | Ratio | autoavgmaxmin |
| builtin:host | CPU steal Average CPU time, when a virtual machine waits to get CPU cycles from the hypervisor. In a virtual environment, CPU cycles are shared across virtual machines on the hypervisor server. If your virtualized host displays a high CPU steal, it means CPU cycles are being taken away from your virtual machine to serve other purposes. It may indicate an overloaded hypervisor. It's available only for Linux hosts | Percent (%) | autoavgmaxmin |
| builtin:host | CPU system Average CPU time when CPU was running in kernel mode | Percent (%) | autoavgmaxmin |
| builtin:host | CPU usage % Percentage of CPU time when CPU was utilized. A value close to 100% means most host processing resources are in use, and host CPUs can’t handle additional work | Percent (%) | autoavgmaxmin |
| builtin:host | CPU user Average CPU time when CPU was running in user mode | Percent (%) | autoavgmaxmin |
| builtin:host | AIX Kernel threads blocked Length of the swap queue. The swap queue contains the threads ready to run but swapped out with the currently running threads | Count | autoavgmaxmin |
| builtin:host | AIX Kernel threads I/O event wait Number of threads that are waiting for file system direct (cio) + Number of processes that are asleep waiting for buffered I/O | Count | autoavgmaxmin |
| builtin:host | AIX Kernel threads I/O message wait Number of threads that are sleeping and waiting for raw I/O operations at a particular time. Raw I/O operation allows applications to direct write to the Logical Volume Manager (LVM) layer | Count | autoavgmaxmin |
| builtin:host | AIX Kernel threads runnable Number of runnable threads (running or waiting for run time) (threads ready). The average number of runnable threads is seen in the first column of the vmstat command output | Count | autoavgmaxmin |
Memory
| Metric key | Name and description | Unit | Aggregations |
|---|---|---|---|
| builtin:host | Memory available The amount of memory (RAM) available on the host. The memory that is available for allocation to new or existing processes. Available memory is an estimation of how much memory is available for use without swapping. | Byte | autoavgmaxmin |
| builtin:host | Memory available % The percentage of memory (RAM) available on the host. The memory that is available for allocation to new or existing processes. Available memory is an estimation of how much memory is available for use without swapping. Shows available memory as percentages. | Percent (%) | autoavgmaxmin |
| builtin:host | Kernel memory The memory used by the system kernel. It includes memory used by core components of OS along with any device drivers.Typically, the number will be very small. | Byte | autoavgmaxmin |
| builtin:host | Memory reclaimable The memory usage for specific purposes. Reclaimable memory is calculated as available memory (estimation of how much memory is available for use without swapping) minus free memory (amount of memory that is currently not used for anything). For more information on reclaimable memory, see [this blog post](https://dt-url.net/bx024wr). | Byte | autoavgmaxmin |
| builtin:host | Memory total The amount of memory (RAM) installed on the system. | Byte | autovalue |
| builtin:host | Memory used % Shows percentage of memory currently used. Used memory is calculated by OneAgent as follows: used = total – available. So the used memory metric displayed in Dynatrace analysis views is not equal to the used memory metric displayed by system tools. At the same time, it’s important to remember that system tools report used memory the way they do due to historical reasons, and that this particular method of calculating used memory isn’t really representative of how the Linux kernel manages memory in modern systems. The difference in these measurements is in fact quite significant, too. Note: Calculated by taking 100% - "Memory available %". | Percent (%) | autoavgmaxmin |
| builtin:host | Memory used Used memory is calculated by OneAgent as follows: used = total – available. So the used memory metric displayed in Dynatrace analysis views is not equal to the used memory metric displayed by system tools. At the same time, it’s important to remember that system tools report used memory the way they do due to historical reasons, and that this particular method of calculating used memory isn’t really representative of how the Linux kernel manages memory in modern systems. The difference in these measurements is in fact quite significant, too. | Byte | autoavgmaxmin |
Availability
| Metric key | Name and description | Unit | Aggregations |
|---|---|---|---|
| builtin:host | Host availability Host availability state metric reported in 1 minute intervals | Count | autovalue |
| builtin:host | Host uptime Time since last host boot up. Requires OneAgent 1.259+. The metric is not supported for application-only OneAgent deployments. | Second | autoavgmaxmin |
Disk
| Metric key | Name and description | Unit | Aggregations |
|---|---|---|---|
| builtin:host | Disk available Amount of free space available for user in file system. On Linux and AIX it is free space available for unprivileged user. It doesn't contain part of free space reserved for the root. | Byte | autoavgmaxmin |
| builtin:host | Disk available % Percentage of free space available for user in file system. On Linux and AIX it is % of free space available for unprivileged user. It doesn't contain part of free space reserved for the root. | Percent (%) | autoavgmaxmin |
Enable Discovery mode
You enable Discovery mode at the host level, either during or after OneAgent installation.
To enable Discovery mode during OneAgent installation, use the --set-monitoring-mode=discovery parameter.
For more information, see the OneAgent installation documentation that's specific to your environment.
To enable Discovery mode after OneAgent installation, use one of these options:
- In Dynatrace
- Go to Hosts and open a host overview page.
- Select More (…) > Settings in the upper-right corner to display the Host settings page.
- Select Monitoring Mode and in the drop-down menu select Discovery.
- Select Save changes.
- Use the OneAgent command-line interface to set the
--set-monitoring-mode=discoveryparameter.
Code-module injection
For Application Security to work in Discovery mode, code-module injection is required. Code-module injection is disabled by default.
After enabling Discovery mode, you can enable the code-module injection for a single host.
- Go to the settings page of the desired host and select Host monitoring.
- Go to Monitoring mode.
- Go to Advanced settings.
- Turn on CodeModule Injection, then select Save changes.
Restart the monitored processes on the host.
For details on how Application Security works in Discovery mode, see Application Security: Discovery mode.
Infrastructure Monitoring mode
OneAgent in Infrastructure Monitoring mode automatically injects into processes to be able to monitor backing services written in Java and runtime metrics for supported languages. Learn how to disable auto-injection.
While Full-Stack mode provides complete application performance monitoring, code-level visibility, deep process monitoring, and Infrastructure Monitoring (including PaaS platforms) for use cases where less visibility is required, OneAgent can be configured for Infrastructure Monitoring mode, which provides physical and virtual infrastructure-centric monitoring, along with log monitoring and AIOps.
Enable Infrastructure Monitoring mode
You enable Infrastructure Monitoring mode at the host level, either during or after OneAgent installation.
OneAgent version 1.273+ The --set-infra-only command is now deprecated. Use the --set-monitoring-mode command instead.
To enable Infrastructure Monitoring mode during OneAgent installation, use the --set-monitoring-mode=infra-only parameter.
For more information, see the OneAgent installation documentation that's specific to your environment.
To enable Infrastructure Monitoring mode after OneAgent installation, use one of these options:
- In Dynatrace
- Go to Hosts or Hosts Classic (latest Dynatrace) and open a host overview page.
- Select More (…) > Settings in the upper-right corner to display the Host settings page.
- Select Monitoring Mode and in the drop-down menu select Infrastructure
- Select Save changes
- Use the OneAgent command-line interface to set the
--set-monitoring-mode=infra-onlyparameter. - Use the Settings API to enable Infrastructure Monitoring mode at scale.
- To download the schema, use GET a schema with
builtin:host.monitoringas the schemaId and create your configuration object using POST an object.
Process injection
Process injection provides you with additional data for Infrastructure Monitoring. Process injection is enabled by default.
If you run your OneAgent as a container with Infrastructure Monitoring mode enabled, process injection will not be performed.
Infrastructure Monitoring mode enables you to monitor any infrastructure component and backing service written in Java. You can monitor backing services supported by default (for example, Kafka or ActiveMQ), and you can also build your own custom JMX and PMI extensions for infrastructure components and use them in Infrastructure Monitoring mode.
Additionally, with process injection, Infrastructure Monitoring mode provides runtime metrics for:
Java
.NET
Node.js
Golang
PHP
Web servers such as Apache HTTP, NGINX, or Microsoft IIS.
Disable process auto-injection:
We don't recommend disabling auto-injection, but if you're required to do so due to strict security requirements, you can choose among a variety options. Note that disabling auto-injection also prevents Dynatrace from discovering vulnerabilities in your environment, even if you have Application Security enabled. You can disable automatic injection at the host or environment level.
Disable auto-injection for a single host
Add the following parameters to the installation command: --set-auto-injection-enabled=false.
If you use this command to disable automatic injection, you won't be able to control auto-injection mode using the Dynatrace web UI at Settings > Monitoring > Monitored technologies or using the OneAgent monitoring configuration API.
- Go to Hosts or Hosts Classic (latest Dynatrace) and open a host overview page.
- Select More (…) > Settings in the upper-right corner to display the Host settings page.
- Select Host Monitoring.
- Go to Advanced settings.
- Turn off ProcessAgent Injection, then select Save changes.
Restart the monitored processes on the host.
Use the OneAgent command line interface to set the --set-auto-injection-enabled=false parameter.
If you use oneagentctl to disable automatic injection, you won't be able to control auto-injection in Infrastructure Monitoring mode using the Dynatrace web UI at Settings > Monitoring > Monitored technologies or OneAgent monitoring configuration API.
Disable auto-injection for an environment
You can disable process injection for particular process groups using custom process monitoring rules.
Custom process monitoring rules give you fine-grained control over which processes OneAgent injects into, with an approach that scales easily within large environments. You don’t need to adjust your system configuration, and a few rules can cover thousands of processes.
For more information, see Process deep monitoring.
You can disable the collection on JMX/PMI and runtime metrics, which will result in disabling auto-injection in Infrastructure Monitoring mode.
- Go to Settings > Monitoring > Monitored technologies.
- In the list of supported technologies, search for the Java/.NET/Node.js/Golang/PHP runtime metrics + WebServer metrics in Infrastructure Mode entry.
- Select the pencil icon
to edit it and then disable it. Restart all processes on your infrastructure-monitored hosts.
You can also disable selected extensions collecting the metrics at the environment level.
-
Go to Settings > Monitoring > Monitored technologies.
-
Filter hosts by injection status
When you disable auto-injection, you can find such hosts using the Auto-injection filter on the Deployment Status page or OneAgent on a host API.
- Go to Deployment Status and then select the OneAgents tab.
- Select the Filter by box, select Auto-injection, and select Disabled manually. You can also use one of the filters below to check other reasons. Note that a filter appears only if a host with a respective status is available in your deployment.
- Enabled
Auto-injection was successfully enabled. - Disabled manually
Auto-injection was disabled after OneAgent installation, either using the Dynatrace web UI oroneagentctl. - Disabled on installation
Auto-injection was disabled during OneAgent installation . - Disabled on sanity check
Auto-injection wasn't enabled due to a failed test performed by the OneAgent installer before OneAgent installation started. Check the OneAgent installer log for details. - Failed on installation
Auto-injection failed due to an error during OneAgent installation. Check the OneAgent installer log for details.
Run the OneAgent on a host API call with the autoInjection parameter set to DISABLED_MANUAL. The returned payload contains the list of OneAgents with auto-injection disabled after OneAgent installation, via either the Dynatrace web UI or oneagentctl.
Virtualization monitoring
Dynatrace supports virtualization monitoring. To monitor the virtual components in your environment, you need to complete an extra step beyond initial setup. For full details, see Set up virtualization monitoring.
Frequently asked questions
Along with injection, the injected module becomes dynamically linked into the monitored technology. As a consequence, it becomes an integral part of the monitored process and can only be removed with a process restart. Depending on the OS (Windows/Linux/AIX), injection is performed in slightly different ways, but the outcome is quite similar.
The injection rules refer to the point in time when the a process of a supported technology is started. After it is started, the deep-code monitoring module of OneAgent remains dynamically linked to the monitored technology and can be unloaded only by restarting the monitored process.
With injection, the injected module becomes dynamically linked into the monitored technology. As a consequence, it becomes an integral part of the monitored process and can be removed only by restarting the monitored process.
OneAgent injects into a process each time a new process is started in the system. OneAgent identifies the launched process (by name, location, user space, and so on) and, if it's supported for injection and if the injection rules do not exclude it, OneAgent sets up a dynamic link between the monitored process and one of the OneAgent deep-code monitoring modules.
Disabled OneAgents effectively stop monitoring of your environment. However, the core of OneAgent, which is responsible for communication with the Dynatrace cluster, remains active. Because communication between OneAgent and Dynatrace clusters is always invoked on the OneAgent side, OneAgent needs to keep on sending its status and asking the cluster if it needs to start monitoring again.