Amazon CloudWatch Agent Documentation

The Amazon CloudWatch Agent is a software component used to collect various types of telemetry data and send it to CloudWatch. Its primary capabilities include:

• System Metrics: Collects in-guest and EC2 instance-level metrics from Amazon EC2 and on-premises servers.
• Custom Metrics: Retrieves metrics from applications using the StatsD protocol (Linux and Windows) or the collectd protocol (Linux only).
• Logs: Collects logs from both Linux and Windows Server environments.
• Traces: Collects OpenTelemetry and AWS X-Ray traces.

The agent is built upon the telegraf and opentelemetry-collector open-source projects, allowing it to operate pipelines consisting of Telegraf and OpenTelemetry components.

The EC2 Tagger Processor scrapes metadata from the Instance Metadata Service (IMDS) in EC2 instances (including ECS EC2 or EKS EC2) and adds that metadata to the data point attributes of your metrics.

Key Details:

• Stability: stable
• Supported pipeline types: metrics
• Distributions: amazon-cloudwatch-agent

The Adapter Receiver is a stable component designed to bridge Telegraf and OpenTelemetry (OTEL). It receives metrics from Telegraf input plugins, filters out unsupported values, and converts them into the corresponding OTEL metric format.

Use Case: Use this receiver when you have existing Telegraf input plugins that you want to integrate into an OTEL-based pipeline before passing data to OTEL processors and exporters.

The AWS AppSignals processor is a [beta] feature used to reduce the cardinality of telemetry metrics and traces before they are exported.

It achieves cardinality reduction through three types of actions:

• keep: Retains specific metrics/traces based on selectors.
• drop: Removes specific metrics/traces based on selectors.
• replace: Modifies dimension values (supported for traces and metrics).

Key constraints:

• Traces: Only support the replace action and are implicitly pulled from the logs section of the CloudWatch Agent (CWA) configuration.
• Supported pipeline types: metrics and traces.
• Supported platforms: Currently supports eks. EC2 support is planned for the future.

The Rollup Processor is a beta-status processor for metrics pipeline types. It aggregates original data points into new data points based on specified attribute sets (rollups).

For example, if you define an attribute set of ["Attr1", "Attr2"], the processor creates a new data point containing only those two attributes, dropping all others. This allows exporters to aggregate metrics based on these specific groups. Additionally, the processor can be configured to drop the original data points to reduce the volume of data sent through the pipeline.

The Kafka Broker Process Detector identifies Kafka broker instances by searching for the kafka.Kafka main class within command-line arguments.

Important Usage Note: This detector is designed to be used as a sub-detector of the Java Process Detector. If used as a standalone detector, the resulting metadata will be incomplete. It relies on the Java Process Detector to provide the initial process context.

The Java Process Detector identifies and classifies Java processes on a system through a multi-step evaluation pipeline:

1. Verification: Confirms the process is running via a java executable.
2. Sub-detector Matching: Attempts to use specialized detectors (like the Tomcat Process Detector) for application-specific identification.
3. Categorization: Always prepends the JVM category to the resulting metadata.
4. Fallback Name Extraction: If sub-detectors fail to provide a name, it uses generic Java name extraction logic.
5. JMX Port Detection: Attempts to identify the JMX port to determine the metadata status.
6. Result Generation: Returns the final metadata object.

The cleaner identifies and deletes Amazon Machine Images (AMIs) used for integration tests that are older than 60 days. It follows these steps:

1. Search: It searches for AMIs with names matching the pattern cloudwatch-agent-integration-test*.
2. Age Check: It compares the AMI creation date against a 60-day threshold. (Note: The tool uses aws smithy go time to convert the AWS SDK v2 creation date pointer to a Go time object for comparison).
3. Deletion: If the AMI is older than 60 days, it is deleted.

The NVIDIA GPU Device Detector identifies NVIDIA GPU hardware and verifies driver availability using platform-specific detection methods:

Linux Detection

• Hardware: Checks for the existence of /dev/nvidia[0-9]+ device files.
• Drivers: Verifies the presence of the nvidia-smi utility.

Windows Detection

• Hardware: Performs a Windows registry check for the NVIDIA vendor ID (VEN_10DE).
• Drivers: Verifies the presence of the nvidia-smi.exe utility.

The Logs Input Plugin 'tails' log files and parses each log message. It behaves similarly to the Unix tail -F --lines=0 command:

• -F: Follows the file name, making it compatible with log rotation and allowing retries on inaccessible files.
• --lines=0: Starts reading from the end of the file (unless the from_beginning option is explicitly set to true).

The plugin expects messages to follow one of the Telegraf Input Data Formats.

tail -F --lines=0 myfile.log