Log Management System
Design and implement comprehensive log management systems including rotation, retention policies, log forwarding, aggregation, storage strategies, and lifecycle management for scalable observability.
When to use me
Use this skill when:
- Designing log management infrastructure for applications or services
- Implementing log rotation and retention policies
- Setting up log forwarding to centralized aggregation systems
- Planning log storage strategies for cost and performance optimization
- Establishing log lifecycle management (ingestion, processing, storage, archival, deletion)
- Troubleshooting log pipeline issues or performance problems
- Scaling log management for high-volume applications
- Ensuring compliance with data retention requirements
What I do
1. Log Rotation & Retention
- Design rotation policies based on size, time, or both
- Implement retention strategies (time-based, size-based, event-based)
- Configure compression for rotated logs (gzip, zstd, lz4)
- Establish archival procedures for long-term storage
- Implement deletion policies for expired logs
- Monitor rotation health and alert on failures
2. Log Forwarding & Aggregation
- Design forwarding architecture (agent-based, daemon-based, library-based)
- Implement reliable delivery with retries and backoff
- Configure batching and buffering for efficiency
- Handle network failures and connection issues
- Implement load balancing across aggregation endpoints
- Monitor forwarding latency and throughput
3. Log Storage Strategies
- Hot storage for recent logs (fast query, high cost)
- Warm storage for medium-term logs (balanced cost/performance)
- Cold storage for archival logs (slow query, low cost)
- Tiered storage with automatic data movement between tiers
- Compression optimization per storage tier
- Cost management across storage classes
4. Lifecycle Management
- Ingestion pipeline design and optimization
- Processing and enrichment at ingestion time
- Indexing strategies for efficient querying
- Retention enforcement across storage tiers
- Archival procedures to long-term storage
- Deletion processes for compliance requirements
5. Performance & Scaling
- Throughput optimization for high-volume logs
- Latency management for real-time requirements
- Resource utilization monitoring and optimization
- Scalability planning for growth
- Bottleneck identification and resolution
- Capacity planning for storage and processing
Log Rotation Patterns
Size-Based Rotation
/var/log/app/app.log
/var/log/app/app.log.1.gz
/var/log/app/app.log.2.gz
/var/log/app/app.log.3.gz
...
Configuration:
- Max file size: 100MB, 1GB, etc.
- Number of rotations: 10, 100, 1000
- Compression: On rotation, on creation
- Permissions: Maintain appropriate file permissions
Time-Based Rotation
/var/log/app/app-2026-02-26.log
/var/log/app/app-2026-02-25.log.gz
/var/log/app/app-2026-02-24.log.gz
...
Configuration:
- Rotation interval: Hourly, daily, weekly, monthly
- Retention period: 7 days, 30 days, 90 days, 1 year
- Timezone handling: UTC, local time, with offsets
- Naming conventions: Date-based, timestamp-based
Hybrid Rotation
- Primary rotation: Size-based for active file
- Secondary rotation: Time-based for archived files
- Tertiary compression: Compression after time period
- Quaternary archival: Move to cold storage after retention
Forwarding Architectures
Agent-Based Forwarding
Application → Local File → Log Agent (Fluentd/Logstash) → Central Aggregation
Advantages:
- Decouples application from forwarding logic
- Can buffer during network outages
- Can process/enrich before forwarding
- Supports multiple input/output formats
Disadvantages:
- Additional resource consumption
- Configuration management overhead
- Potential single point of failure
Library/Direct Forwarding
Application → Logging Library → Central Aggregation
Advantages:
- Simpler architecture
- Lower latency
- Fewer moving parts
Disadvantages:
- Coupled to application lifecycle
- Limited buffering during outages
- May lose logs during application crashes
Sidecar Pattern (Containers)
Application Container → Sidecar Container → Central Aggregation
Advantages:
- Decoupled but co-located
- Shares container lifecycle
- Can use specialized sidecar images
Disadvantages:
- Additional container overhead
- Inter-container communication complexity
Storage Tier Strategy
Tier 1: Hot Storage (0-7 days)
- Purpose: Real-time debugging, recent issue investigation
- Characteristics: Fast query, full-text search, high availability
- Examples: Elasticsearch, Splunk, Cloud Logging
- Retention: 1-7 days typically
- Cost: Highest per GB
Tier 2: Warm Storage (8-30 days)
- Purpose: Trend analysis, weekly/monthly reporting
- Characteristics: Slower query, aggregated views, good availability
- Examples: Compressed files on fast storage, warmed indices
- Retention: 8-30 days typically
- Cost: Medium per GB
Tier 3: Cold Storage (31-365 days)
- Purpose: Compliance, occasional investigations, historical analysis
- Characteristics: Very slow query, batch processing, lower availability
- Examples: Object storage (S3, GCS), tape backup
- Retention: 31-365+ days
- Cost: Lowest per GB
Tier 4: Archival Storage (1+ years)
- Purpose: Legal requirements, historical records
- Characteristics: Extremely slow retrieval, write-once-read-rarely
- Examples: Glacier, deep archival services
- Retention: Years to decades
- Cost: Minimal but retrieval costs may apply
Examples
# Configure log rotation policy
npm run log-management:configure-rotation -- --max-size 100MB --keep-files 10 --compress gzip
# Set up log forwarding
npm run log-management:configure-forwarding -- --agent fluentd --destination elasticsearch --batch-size 1000
# Design storage strategy
npm run log-management:design-storage -- --hot-days 7 --warm-days 30 --cold-days 365 --archive-years 7
# Analyze current log management
npm run log-management:analyze -- --path /var/log --output analysis.json
# Implement lifecycle policy
npm run log-management:lifecycle -- --ingestion-kafka --processing-flink --storage-s3 --retention-90d
Output format
Log Management Configuration:
log_management:
rotation:
strategy: "size_and_time"
max_size_mb: 100
max_age_days: 7
compress_on_rotation: true
compression_algorithm: "gzip"
keep_rotated: 10
forwarding:
method: "agent_based"
agent: "fluentd"
configuration:
buffer:
type: "file"
path: "/var/log/fluentd-buffer"
flush_interval: 5
retry_limit: 10
destination:
type: "elasticsearch"
hosts: ["elasticsearch:9200"]
index: "app-logs-%Y.%m.%d"
storage:
tiers:
hot:
type: "elasticsearch"
retention_days: 7
replication: 2
warm:
type: "s3"
retention_days: 30
compression: "zstd"
cold:
type: "glacier"
retention_days: 365
retrieval_time: "3-5 hours"
lifecycle:
ingestion_rate_limit: "10000/s"
processing_enrichment: true
indexing_strategy: "daily_index"
retention_enforcement: "automated"
archival_schedule: "daily"
deletion_procedure: "secure_delete"
monitoring:
metrics:
- log_volume_per_second
- rotation_success_rate
- forwarding_latency
- storage_utilization
alerts:
- rotation_failed
- forwarding_stopped
- storage_90_percent_full
- retention_violation
Log Management Assessment:
Log Management System Assessment
───────────────────────────────
System: payment-platform
Assessment Date: 2026-02-26
Score: 65/100
Current State:
✅ Log rotation implemented (size-based, 100MB)
✅ Basic forwarding to centralized system
✅ Hot storage configured (7 days retention)
Areas for Improvement:
⚠️ No tiered storage strategy (all logs in hot storage)
⚠️ Limited buffering during network outages (lose logs after 100MB)
⚠️ No lifecycle management (manual archival/deletion)
⚠️ No compression for rotated logs
⚠️ Inconsistent retention across services
Critical Issues:
❌ No monitoring of log management system itself
❌ Single point of failure in forwarding pipeline
❌ No disaster recovery for log data
❌ Compliance risks with retention policies
Storage Cost Analysis:
- Current: $2,500/month (all logs in hot storage)
- Optimized: $850/month (with tiered strategy)
- Savings potential: 66% with proper tiering
Recommendations:
1. Implement tiered storage strategy immediately
2. Add buffering and retry logic to forwarding
3. Automate lifecycle management
4. Set up comprehensive monitoring
5. Create disaster recovery plan for log data
Implementation Timeline:
- Week 1-2: Tiered storage implementation
- Week 3-4: Forwarding reliability improvements
- Week 5-6: Lifecycle automation
- Week 7-8: Monitoring and alerting
- Ongoing: Regular review and optimization
Notes
- Log management is not "set and forget" - requires ongoing maintenance
- Cost optimization is critical - log storage can become expensive quickly
- Reliability matters - lost logs mean lost observability
- Compliance requirements vary by industry and region
- Scalability planning should anticipate 10x-100x growth
- Disaster recovery for logs is often overlooked but critical
- Security considerations include access control and encryption
- Performance monitoring of the log management system itself is essential
- Regular review of policies and configurations as needs evolve
- Document everything - rotation policies, retention rules, procedures
1---2name: log-management-system3description: Implement comprehensive log management including rotation, retention, forwarding, aggregation, storage, and lifecycle management4license: MIT5compatibility: opencode6metadata:7 audience: SREs, DevOps engineers, system administrators8 category: observability9---1011# Log Management System1213Design and implement comprehensive log management systems including rotation, retention policies, log forwarding, aggregation, storage strategies, and lifecycle management for scalable observability.1415## When to use me1617Use this skill when:18- Designing log management infrastructure for applications or services19- Implementing log rotation and retention policies20- Setting up log forwarding to centralized aggregation systems21- Planning log storage strategies for cost and performance optimization22- Establishing log lifecycle management (ingestion, processing, storage, archival, deletion)23- Troubleshooting log pipeline issues or performance problems24- Scaling log management for high-volume applications25- Ensuring compliance with data retention requirements2627## What I do2829### 1. Log Rotation & Retention30- **Design rotation policies** based on size, time, or both31- **Implement retention strategies** (time-based, size-based, event-based)32- **Configure compression** for rotated logs (gzip, zstd, lz4)33- **Establish archival procedures** for long-term storage34- **Implement deletion policies** for expired logs35- **Monitor rotation health** and alert on failures3637### 2. Log Forwarding & Aggregation38- **Design forwarding architecture** (agent-based, daemon-based, library-based)39- **Implement reliable delivery** with retries and backoff40- **Configure batching and buffering** for efficiency41- **Handle network failures** and connection issues42- **Implement load balancing** across aggregation endpoints43- **Monitor forwarding latency** and throughput4445### 3. Log Storage Strategies46- **Hot storage** for recent logs (fast query, high cost)47- **Warm storage** for medium-term logs (balanced cost/performance)48- **Cold storage** for archival logs (slow query, low cost)49- **Tiered storage** with automatic data movement between tiers50- **Compression optimization** per storage tier51- **Cost management** across storage classes5253### 4. Lifecycle Management54- **Ingestion pipeline** design and optimization55- **Processing and enrichment** at ingestion time56- **Indexing strategies** for efficient querying57- **Retention enforcement** across storage tiers58- **Archival procedures** to long-term storage59- **Deletion processes** for compliance requirements6061### 5. Performance & Scaling62- **Throughput optimization** for high-volume logs63- **Latency management** for real-time requirements64- **Resource utilization** monitoring and optimization65- **Scalability planning** for growth66- **Bottleneck identification** and resolution67- **Capacity planning** for storage and processing6869## Log Rotation Patterns7071### Size-Based Rotation72```73/var/log/app/app.log74/var/log/app/app.log.1.gz75/var/log/app/app.log.2.gz76/var/log/app/app.log.3.gz77...78```7980Configuration:81- **Max file size**: 100MB, 1GB, etc.82- **Number of rotations**: 10, 100, 100083- **Compression**: On rotation, on creation84- **Permissions**: Maintain appropriate file permissions8586### Time-Based Rotation87```88/var/log/app/app-2026-02-26.log89/var/log/app/app-2026-02-25.log.gz90/var/log/app/app-2026-02-24.log.gz91...92```9394Configuration:95- **Rotation interval**: Hourly, daily, weekly, monthly96- **Retention period**: 7 days, 30 days, 90 days, 1 year97- **Timezone handling**: UTC, local time, with offsets98- **Naming conventions**: Date-based, timestamp-based99100### Hybrid Rotation101- **Primary rotation**: Size-based for active file102- **Secondary rotation**: Time-based for archived files103- **Tertiary compression**: Compression after time period104- **Quaternary archival**: Move to cold storage after retention105106## Forwarding Architectures107108### Agent-Based Forwarding109```110Application → Local File → Log Agent (Fluentd/Logstash) → Central Aggregation111```112113**Advantages**:114- Decouples application from forwarding logic115- Can buffer during network outages116- Can process/enrich before forwarding117- Supports multiple input/output formats118119**Disadvantages**:120- Additional resource consumption121- Configuration management overhead122- Potential single point of failure123124### Library/Direct Forwarding125```126Application → Logging Library → Central Aggregation127```128129**Advantages**:130- Simpler architecture131- Lower latency132- Fewer moving parts133134**Disadvantages**:135- Coupled to application lifecycle136- Limited buffering during outages137- May lose logs during application crashes138139### Sidecar Pattern (Containers)140```141Application Container → Sidecar Container → Central Aggregation142```143144**Advantages**:145- Decoupled but co-located146- Shares container lifecycle147- Can use specialized sidecar images148149**Disadvantages**:150- Additional container overhead151- Inter-container communication complexity152153## Storage Tier Strategy154155### Tier 1: Hot Storage (0-7 days)156- **Purpose**: Real-time debugging, recent issue investigation157- **Characteristics**: Fast query, full-text search, high availability158- **Examples**: Elasticsearch, Splunk, Cloud Logging159- **Retention**: 1-7 days typically160- **Cost**: Highest per GB161162### Tier 2: Warm Storage (8-30 days)163- **Purpose**: Trend analysis, weekly/monthly reporting164- **Characteristics**: Slower query, aggregated views, good availability165- **Examples**: Compressed files on fast storage, warmed indices166- **Retention**: 8-30 days typically167- **Cost**: Medium per GB168169### Tier 3: Cold Storage (31-365 days)170- **Purpose**: Compliance, occasional investigations, historical analysis171- **Characteristics**: Very slow query, batch processing, lower availability172- **Examples**: Object storage (S3, GCS), tape backup173- **Retention**: 31-365+ days174- **Cost**: Lowest per GB175176### Tier 4: Archival Storage (1+ years)177- **Purpose**: Legal requirements, historical records178- **Characteristics**: Extremely slow retrieval, write-once-read-rarely179- **Examples**: Glacier, deep archival services180- **Retention**: Years to decades181- **Cost**: Minimal but retrieval costs may apply182183## Examples184185```bash186# Configure log rotation policy187npm run log-management:configure-rotation -- --max-size 100MB --keep-files 10 --compress gzip188189# Set up log forwarding190npm run log-management:configure-forwarding -- --agent fluentd --destination elasticsearch --batch-size 1000191192# Design storage strategy193npm run log-management:design-storage -- --hot-days 7 --warm-days 30 --cold-days 365 --archive-years 7194195# Analyze current log management196npm run log-management:analyze -- --path /var/log --output analysis.json197198# Implement lifecycle policy199npm run log-management:lifecycle -- --ingestion-kafka --processing-flink --storage-s3 --retention-90d200```201202## Output format203204### Log Management Configuration:205```yaml206log_management:207 rotation:208 strategy: "size_and_time"209 max_size_mb: 100210 max_age_days: 7211 compress_on_rotation: true212 compression_algorithm: "gzip"213 keep_rotated: 10214 215 forwarding:216 method: "agent_based"217 agent: "fluentd"218 configuration:219 buffer:220 type: "file"221 path: "/var/log/fluentd-buffer"222 flush_interval: 5223 retry_limit: 10224 destination:225 type: "elasticsearch"226 hosts: ["elasticsearch:9200"]227 index: "app-logs-%Y.%m.%d"228 229 storage:230 tiers:231 hot:232 type: "elasticsearch"233 retention_days: 7234 replication: 2235 warm:236 type: "s3"237 retention_days: 30238 compression: "zstd"239 cold:240 type: "glacier"241 retention_days: 365242 retrieval_time: "3-5 hours"243 244 lifecycle:245 ingestion_rate_limit: "10000/s"246 processing_enrichment: true247 indexing_strategy: "daily_index"248 retention_enforcement: "automated"249 archival_schedule: "daily"250 deletion_procedure: "secure_delete"251 252 monitoring:253 metrics:254 - log_volume_per_second255 - rotation_success_rate256 - forwarding_latency257 - storage_utilization258 alerts:259 - rotation_failed260 - forwarding_stopped261 - storage_90_percent_full262 - retention_violation263```264265### Log Management Assessment:266```267Log Management System Assessment268───────────────────────────────269System: payment-platform270Assessment Date: 2026-02-26271Score: 65/100272273Current State:274✅ Log rotation implemented (size-based, 100MB)275✅ Basic forwarding to centralized system276✅ Hot storage configured (7 days retention)277278Areas for Improvement:279⚠️ No tiered storage strategy (all logs in hot storage)280⚠️ Limited buffering during network outages (lose logs after 100MB)281⚠️ No lifecycle management (manual archival/deletion)282⚠️ No compression for rotated logs283⚠️ Inconsistent retention across services284285Critical Issues:286❌ No monitoring of log management system itself287❌ Single point of failure in forwarding pipeline288❌ No disaster recovery for log data289❌ Compliance risks with retention policies290291Storage Cost Analysis:292- Current: $2,500/month (all logs in hot storage)293- Optimized: $850/month (with tiered strategy)294- Savings potential: 66% with proper tiering295296Recommendations:2971. Implement tiered storage strategy immediately2982. Add buffering and retry logic to forwarding2993. Automate lifecycle management3004. Set up comprehensive monitoring3015. Create disaster recovery plan for log data302303Implementation Timeline:304- Week 1-2: Tiered storage implementation305- Week 3-4: Forwarding reliability improvements306- Week 5-6: Lifecycle automation307- Week 7-8: Monitoring and alerting308- Ongoing: Regular review and optimization309```310311## Notes312313- **Log management is not "set and forget"** - requires ongoing maintenance314- **Cost optimization is critical** - log storage can become expensive quickly315- **Reliability matters** - lost logs mean lost observability316- **Compliance requirements** vary by industry and region317- **Scalability planning** should anticipate 10x-100x growth318- **Disaster recovery** for logs is often overlooked but critical319- **Security considerations** include access control and encryption320- **Performance monitoring** of the log management system itself is essential321- **Regular review** of policies and configurations as needs evolve322- **Document everything** - rotation policies, retention rules, procedures