OpenTelemetry Collector on AWS User Guide

Overview

This image runs the OpenTelemetry Collector, the vendor-neutral, CNCF-graduated way to receive, process and export telemetry. The collector ingests traces, metrics and logs through pluggable receivers, transforms and batches them through processors, then exports them to dozens of observability backends. The image ships the feature-rich otelcol-contrib distribution as a ready-to-use telemetry pipeline appliance: otelcol-contrib.service is enabled and starts on boot running a self-contained sample pipeline, so the moment an engineer connects over SSH the collector is already processing telemetry.

This is a headless telemetry-pipeline service. There is no web interface and no credentials to manage. The collector runs as a long-lived daemon driven by a single declarative configuration file at /etc/otelcol-contrib/config.yaml. The OTLP receivers (gRPC 127.0.0.1:4317 and HTTP 127.0.0.1:4318), the health-check extension (127.0.0.1:13133) and the zPages extension (127.0.0.1:55679) are all bound to loopback only, so they answer on the instance without ever being exposed to the network. The instance security group opens port 22 only; you rebind the receivers and open whatever ingest ports your own telemetry sources need.

The file exporter output lives on a dedicated, independently resizable EBS data volume mounted at /var/lib/otelcol. The exported telemetry sits on durable storage rather than the operating system disk, and the data directory is owned by the collector's service user so the daemon can write to it.

Prerequisites

Before you deploy this image you need:

• An Amazon Web Services account where you can launch EC2 instances
• IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
• An EC2 key pair in the target Region for SSH access to the instance
• A VPC and subnet in the target Region, with a security group allowing inbound port 22 from your management network
• The AWS CLI (version 2) installed locally if you plan to deploy from the command line

Step 1: Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images choose AWS Marketplace AMIs and search for OpenTelemetry Collector. Select the cloudimg listing and choose Select, then Continue on the subscription summary.

Pick an instance type of t3.small or larger. Choose your EC2 key pair under Key pair (login). Under Network settings select your VPC and subnet, and either create or select a security group that opens port 22 from your management network. Leave the root volume at the default size or larger.

Select Launch instance. First boot initialisation takes a few seconds after the instance state becomes Running and the status checks pass; otelcol-contrib.service is already running its sample pipeline by the time you can connect.

Step 2: Launch the Instance from the AWS CLI

The following block launches an instance from the cloudimg OpenTelemetry Collector Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens port 22 from your management network.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type t3.small \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=otel-collector}]'

When the instance reaches the Running state and its status checks pass, note its public IP address or DNS name from the EC2 console or with aws ec2 describe-instances.

Step 3: Connect to Your Instance

Connect over SSH using your key pair and the login user for your operating system variant.

ssh -i <key-name>.pem ubuntu@<public-ip>

A welcome banner prints the most useful commands, and sudo cat /root/otel-collector-info.txt shows the full getting-started notes: what is running, the OTLP receiver ports, the health endpoint, where the pipeline configuration lives, and the common receiver, processor and exporter components.

Step 4: Verify the Service

The OpenTelemetry Collector runs as a system service that is enabled and started on boot. Confirm the daemon is active:

systemctl is-active otelcol-contrib

That prints active. For the full unit status, including the main PID, memory use and the command line the daemon is running, use:

systemctl status otelcol-contrib --no-pager

Confirm the installed binary and version, which is pinned to OpenTelemetry Collector 0.154.0 on this image:

otelcol-contrib --version

You should see otelcol-contrib version 0.154.0 reported. The otelcol-contrib binary is installed at /usr/bin/otelcol-contrib and resolves from any login shell.

Step 5: The Health Endpoint and OTLP Receivers

The collector enables the health_check extension, bound to loopback only (127.0.0.1:13133), so the endpoint answers on the instance but is never exposed to the network. Check it; it returns Server available with HTTP 200 while the collector is healthy:

curl -s http://127.0.0.1:13133

The sample pipeline configures the OpenTelemetry Protocol receivers on the standard ports, bound to loopback: gRPC on 127.0.0.1:4317 and HTTP on 127.0.0.1:4318. Confirm the collector is listening on the OTLP and health ports:

ss -tlnp | grep -E '4317|4318|13133'

You will see the collector process bound to 127.0.0.1:4317, 127.0.0.1:4318 and 127.0.0.1:13133. Point a locally running, instrumented application or an OpenTelemetry SDK at the OTLP endpoints to send it traces, metrics and logs. The zPages extension is also enabled on 127.0.0.1:55679, exposing a live view of the running pipeline at http://127.0.0.1:55679/debug/servicez.

To accept telemetry from across your network, change the otlp receiver endpoint values in the [receivers] section of the configuration to a network interface (for example 0.0.0.0:4317) and open the OTLP ports in the instance security group yourself; the receivers stay bound to loopback by default.

Step 6: Edit the Pipeline

The OpenTelemetry Collector reads its pipeline from a single declarative configuration file at /etc/otelcol-contrib/config.yaml. The shipped configuration is a self-contained sample that needs no external dependencies. View the receivers, processors, exporters and the pipeline wiring:

sed -n '1,60p' /etc/otelcol-contrib/config.yaml

The sample pipeline pairs an otlp receiver (gRPC and HTTP) and a hostmetrics receiver (real host telemetry) with a batch processor, then fans out to a file exporter that writes JSON telemetry to the data volume and a debug exporter visible in the journal. The health_check and zpages extensions are listed under service.extensions.

To build your own pipeline, replace the sample receivers and exporters with your own. Common receiver components ingest from your sources: otlp for OpenTelemetry Protocol, prometheus for Prometheus scrape targets, hostmetrics for host telemetry, journald and syslog and filelog for logs. Chain processor components to shape records: batch, memory_limiter, filter, transform and resource. Fan out to exporter components to ship the telemetry: otlp, otlphttp, prometheus, loki, kafka, file and debug.

After editing the configuration, validate it before reloading, then restart the service to apply your changes. These customer-facing commands validate and reload your pipeline:

sudo otelcol-contrib validate --config /etc/otelcol-contrib/config.yaml
sudo systemctl restart otelcol-contrib

Open whatever ingest ports your pipeline needs in the instance security group. The telemetry the sample file exporter writes appears as JSON on the data volume:

sudo head -c 400 /var/lib/otelcol/telemetry.json

Step 7: The Data Volume

The file exporter writes its output to a dedicated EBS volume mounted at /var/lib/otelcol. This keeps the exported telemetry off the operating system disk and lets you resize or snapshot the volume independently. Confirm the mount with:

df -h /var/lib/otelcol

The data directory is owned by the collector's service user so the daemon can write to it. To grow the volume, expand the EBS volume in the AWS console, then grow the filesystem on the instance with sudo resize2fs on the underlying device. Point your own file exporter, or any exporter that writes to disk (for example a persistent sending queue), at this volume to keep its data off the OS disk.

Support

This image is published and supported by cloudimg. Support covers pipeline design, receiver and exporter configuration, processors and sampling, OTLP and Prometheus ingest, routing to your observability backend, the health-check and zPages extensions, scaling the collector, and upgrade planning. Contact cloudimg through the support channel listed on the AWS Marketplace listing.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.