Monitoring EC2 Host Logs with ClickStack
Monitor EC2 system logs with ClickStack by installing OpenTelemetry Collector on your instances. The collector automatically enriches logs with EC2 metadata (instance ID, region, availability zone, instance type). You'll learn how to:
- Install and configure OpenTelemetry Collector on EC2 instances
- Automatically enrich logs with EC2 metadata
- Send logs to ClickStack via OTLP
- Use a pre-built dashboard to visualize EC2 host logs with cloud context
A demo dataset with sample logs and simulated EC2 metadata is available for testing.
Time Required: 10-15 minutes
Integration with existing EC2 instance
This section covers installing OpenTelemetry Collector on your EC2 instances to collect system logs and send them to ClickStack with automatic EC2 metadata enrichment. This distributed architecture is production-ready and scales to multiple instances.
If ClickStack is running on the same EC2 instance whose logs you want to monitor, you can use the all-in-one approach similar to the Generic Host Logs guide. Mount /var/log into the ClickStack container and add the resourcedetection processor to your custom config to automatically capture EC2 metadata. This guide focuses on the more common distributed architecture for production deployments.
If you would like to test the EC2 host logs integration before configuring your production instance, you can test with our preconfigured setup and sample data in the "Demo dataset" section.
Prerequisites
- ClickStack instance running (can be on-premises, cloud, or local)
- EC2 instance running (Ubuntu, Amazon Linux, or other Linux distribution)
- Network connectivity from EC2 instance to ClickStack's OTLP endpoint (port 4318 for HTTP or 4317 for gRPC)
- EC2 instance metadata service accessible (enabled by default)
Verify EC2 metadata is accessible
From your EC2 instance, verify the metadata service is accessible:
You should see your instance ID, region, and instance type. If these commands fail, verify:
- The instance metadata service is enabled
- IMDSv2 is not blocked by security groups or network ACLs
- You're running these commands from the EC2 instance itself
EC2 metadata is available at http://169.254.169.254 from within the instance. The OpenTelemetry resourcedetection processor uses this endpoint to automatically enrich logs with cloud context.
Install OpenTelemetry Collector
Install the OpenTelemetry Collector Contrib distribution on your EC2 instance:
Create collector configuration
Create a configuration file for the OpenTelemetry Collector at /etc/otelcol-contrib/config.yaml:
Choose the configuration based on your Linux distribution:
- Modern Linux (Ubuntu 24.04+)
- Legacy Linux (Amazon Linux 2, RHEL, older Ubuntu)
Replace the following in the configuration:
YOUR_CLICKSTACK_HOST: The hostname or IP address where ClickStack is running- For local testing, you can use an SSH tunnel (see Troubleshooting section)
This configuration:
- Reads system log files from standard locations (
/var/log/syslogfor Ubuntu,/var/log/messagesfor Amazon Linux/RHEL) - Parses syslog format to extract structured fields (timestamp, hostname, unit/service, PID, message)
- Automatically detects and adds EC2 metadata using the resourcedetection processor
- Optionally includes EC2 tags (Name, Environment, Team) if present
- Sends logs to ClickStack via OTLP HTTP
The resourcedetection processor automatically adds these attributes to every log:
cloud.provider: "aws"cloud.platform: "aws_ec2"cloud.region: AWS region (e.g., "us-east-1")cloud.availability_zone: AZ (e.g., "us-east-1a")cloud.account.id: AWS account IDhost.id: EC2 instance ID (e.g., "i-1234567890abcdef0")host.type: Instance type (e.g., "t3.medium")host.name: Instance hostname
Set ClickStack API key
Export your ClickStack API key as an environment variable:
To make this persistent across reboots, add it to your shell profile:
Run the collector
Start the OpenTelemetry Collector:
Configure the collector to run as a systemd service so it starts automatically on boot and restarts on failure. See the OpenTelemetry Collector documentation for details.
Verifying Logs in HyperDX
Once the collector is running, log into HyperDX and verify logs are flowing with EC2 metadata:
- Navigate to the search view
- Set source to Logs
- Filter by
source:ec2-host-logs - Click on a log entry to expand it
- Verify you see EC2 metadata in the resource attributes:
cloud.providercloud.regionhost.id(instance ID)host.type(instance type)cloud.availability_zone
Demo dataset
For users who want to test the EC2 host logs integration before configuring their production instances, we provide a sample dataset with simulated EC2 metadata.
Download the sample dataset
Download the sample log file:
The dataset includes:
- System boot sequence
- SSH login activity (successful and failed attempts)
- Security incident (brute force attack with fail2ban response)
- Scheduled maintenance (cron jobs, anacron)
- Service restarts (rsyslog)
- Kernel messages and firewall activity
- Mix of normal operations and notable events
Create test collector configuration
Create a file named ec2-host-logs-demo.yaml with the following configuration:
For demo purposes, we manually add EC2 metadata using the resource processor. In production with real EC2 instances, use the resourcedetection processor which automatically queries the EC2 metadata API.
Verify logs in HyperDX
Once the collector is running:
- Open HyperDX and log in to your account (you may need to create an account first)
- Navigate to the Search view and set the source to
Logs - Set the time range to 2025-11-10 00:00:00 - 2025-11-13 00:00:00
- Filter by
source:ec2-demo - Expand a log entry to view EC2 metadata in the resource attributes
HyperDX displays timestamps in your browser's local timezone. The demo data spans 2025-11-11 00:00:00 - 2025-11-12 00:00:00 (UTC). The wide time range ensures you'll see the demo logs regardless of your location. Once you see the logs, you can narrow the range to a 24-hour period for clearer visualizations.
You should see logs with simulated EC2 context including:
- Instance ID:
i-0abc123def456789 - Region:
us-east-1 - Availability Zone:
us-east-1a - Instance Type:
t3.medium
Dashboards and visualization
To help you get started monitoring EC2 host logs with ClickStack, we provide essential visualizations with cloud context.
Import the pre-built dashboard
- Open HyperDX and navigate to the Dashboards section
- Click Import Dashboard in the upper right corner under the ellipses
- Upload the
host-logs-dashboard.jsonfile and click Finish Import
View the dashboard
The dashboard will be created with all visualizations pre-configured:
You can filter dashboard visualizations by EC2 context:
cloud.region:us-east-1- Show logs from specific regionhost.type:t3.medium- Filter by instance typehost.id:i-0abc123def456- Logs from specific instance
For the demo dataset, set the time range to 2025-11-11 00:00:00 - 2025-11-12 00:00:00 (UTC) (adjust based on your local timezone). The imported dashboard will not have a time range specified by default.
Troubleshooting
EC2 metadata not appearing in logs
Verify the EC2 metadata service is accessible:
If this fails, verify:
- The instance metadata service is enabled
- IMDSv2 is not blocked by security groups
- You're running the collector on the EC2 instance itself
Check collector logs for metadata errors:
No logs appearing in HyperDX
Verify syslog files exist and are being written:
Check collector can read the log files:
Verify network connectivity to ClickStack:
Check collector logs for errors:
Logs parsing incorrectly
Verify your syslog format:
For Ubuntu 24.04+:
For Amazon Linux 2 / Ubuntu 20.04:
If your format doesn't match, use the appropriate configuration tab in the Create collector configuration section based on your distribution.
Collector not starting as systemd service
Check service status:
View detailed logs:
Common issues:
- API key not set correctly in environment
- Config file syntax errors
- Permission issues reading log files
Next steps
After setting up EC2 host logs monitoring:
- Set up alerts for critical system events (service failures, authentication failures, disk warnings)
- Filter by EC2 metadata attributes (region, instance type, instance ID) to monitor specific resources
- Correlate EC2 host logs with application logs for comprehensive troubleshooting
- Create custom dashboards for security monitoring (SSH attempts, sudo usage, firewall blocks)