Use this file to discover all available pages before exploring further.
Configure your applications with robust logging using Archil disks that automatically flow to Amazon S3 storage. Simply mount an Archil disk and point your regular application loggers to it - no S3 APIs required.
Transparent S3 Integration
Write to normal filesystem paths and logs automatically sync to S3
Instance Isolation
Each instance creates its own directory for proper ownership separation
Infinite Capacity
Never run out of capacity because your logs are going to S3
Standard Logging Libraries
Use your existing logging setup - Python logging, winston, etc.
First, create an Archil disk for your logging infrastructure. Follow the Quickstart Guide to create a disk, then mount it in shared mode to allow multiple instances to write logs simultaneously.
# Create the mount directorysudo mkdir -p /mnt/logs# Mount the Archil disk in shared modesudo archil mount <disk-name> /mnt/logs --region aws-us-east-1 --shared
Each application instance should create its own directory within the mounted filesystem. We recommend doing this as part of a startup script or on application startup:
# Create instance-specific log directory using hostnameINSTANCE_DIR="/mnt/logs/$(hostname)"mkdir -p "$INSTANCE_DIR"# Or use a custom instance identifierINSTANCE_ID="${INSTANCE_ID:-$(date +%s)-$$}"INSTANCE_DIR="/mnt/logs/instance-${INSTANCE_ID}"mkdir -p "$INSTANCE_DIR"
With Archil, you don’t need traditional log rotation because logs are automatically offloaded to S3, where there’s infinite capacity. The standardized logging approach implements automatic minute-based rotation across all languages, creating new log files every minute with the consistent naming pattern service_YYYYMMDDTHH_MM_00Z.log for natural chronological organization while maintaining optimal query performance.
One of the key advantages of using Archil for logging is that your logs automatically flow to S3, giving you access to all of S3’s built-in cost optimization features. You can leverage S3’s intelligent tiering and lifecycle policies to automatically move your log data to cheaper storage classes over time without any application changes.Configure lifecycle policies on your S3 bucket to automatically transition logs to cheaper storage classes:
Once your logs are flowing to S3 through Archil, you can use Amazon Athena to run SQL queries directly against your log data without needing to load it into a database.
Create a table in Athena that leverages the standardized filename format for efficient time-based partitioning. The standardized service_YYYYMMDDTHH_MM_00Z.log format enables Athena to automatically partition data by time:
-- Find all errors in the last 24 hours (leverages time partitioning)SELECT timestamp, instance_id, messageFROM application_logsWHERE level = 'ERROR' AND year = '2024' AND month = '07' AND day = '29' AND timestamp >= date_format(date_add('hour', -24, now()), '%Y-%m-%d %H:%i:%s')ORDER BY timestamp DESCLIMIT 100;-- Count errors by instance (with partition pruning)SELECT instance_id, COUNT(*) as error_countFROM application_logsWHERE level = 'ERROR' AND year = '2024' AND month = '07' AND day >= '28' AND timestamp >= date_format(date_add('day', -1, now()), '%Y-%m-%d')GROUP BY instance_idORDER BY error_count DESC;
-- Analyze log volume by hourSELECT date_format(from_iso8601_timestamp(timestamp), '%Y-%m-%d %H:00:00') as hour, COUNT(*) as log_count, COUNT(DISTINCT instance_id) as active_instancesFROM application_logsWHERE timestamp >= date_format(date_add('day', -7, now()), '%Y-%m-%d')GROUP BY date_format(from_iso8601_timestamp(timestamp), '%Y-%m-%d %H:00:00')ORDER BY hour;-- Find instances with unusual activitySELECT instance_id, COUNT(*) as total_logs, COUNT(CASE WHEN level = 'ERROR' THEN 1 END) as error_logs, COUNT(CASE WHEN level = 'WARN' THEN 1 END) as warn_logsFROM application_logsWHERE timestamp >= date_format(date_add('hour', -1, now()), '%Y-%m-%d %H:%i:%s')GROUP BY instance_idHAVING COUNT(*) > 1000 OR COUNT(CASE WHEN level = 'ERROR' THEN 1 END) > 10ORDER BY total_logs DESC;
-- Search for specific patterns in log messagesSELECT timestamp, instance_id, level, messageFROM application_logsWHERE message LIKE '%timeout%' OR message LIKE '%connection%' OR message LIKE '%failed%'AND timestamp >= date_format(date_add('hour', -6, now()), '%Y-%m-%d %H:%i:%s')ORDER BY timestamp DESC;-- Analyze function call patternsSELECT module, function, COUNT(*) as call_count, COUNT(CASE WHEN level = 'ERROR' THEN 1 END) as error_countFROM application_logsWHERE timestamp >= date_format(date_add('day', -1, now()), '%Y-%m-%d')GROUP BY module, functionHAVING COUNT(*) > 100ORDER BY call_count DESC;