Log Analysis

Log Analysis Skill

Overview

This skill provides techniques for effective log parsing, analysis, and insight extraction across infrastructure platforms. It covers log formats, parsing strategies, pattern recognition, and analysis methodologies.

Log Analysis Fundamentals

Log Anatomy

Every log entry typically contains:

[TIMESTAMP] [LEVEL] [SOURCE] [MESSAGE] [CONTEXT]

Key Fields:

• Timestamp: When the event occurred (critical for correlation)
• Level: Severity (DEBUG, INFO, WARN, ERROR, FATAL)
• Source: Component that generated the log
• Message: Human-readable description
• Context: Additional metadata (request ID, user ID, etc.)

Log Levels

Parsing Strategies

Structured Logs (JSON)

Most modern systems emit JSON logs:

{
  "timestamp": "2024-01-15T14:30:00.123Z",
  "level": "error",
  "message": "Database connection failed",
  "service": "api",
  "request_id": "req-abc123",
  "error": {
    "code": "CONN_TIMEOUT",
    "detail": "Connection timed out after 30000ms"
  }
}

Parsing approach: 1. Parse JSON structure 2. Extract standard fields 3. Flatten nested objects for analysis 4. Group by common attributes

Unstructured Logs (Plain Text)

Legacy systems often use plain text:

2024-01-15 14:30:00 ERROR [api.handler] Database connection failed: timeout after 30s

Parsing approach: 1. Identify timestamp format with regex 2. Extract level using keyword matching 3. Parse source from brackets/prefixes 4. Remainder is message

Mixed Format Logs

Some systems mix formats:

[14:30:00] INFO: Starting request processing {"request_id": "abc123"}

Parsing approach: 1. Split structured from unstructured portions 2. Parse each portion with appropriate strategy 3. Merge results

Analysis Techniques

Time-Based Analysis

Windowing: Group events by time period

Window: 1 minute
14:30 - 14:31: 5 errors
14:31 - 14:32: 12 errors  ← Spike detected
14:32 - 14:33: 3 errors

Correlation: Match events across systems by timestamp

14:30:01.123 [API]      Request received
14:30:01.125 [Auth]     Token validated
14:30:01.130 [Database] Query started
14:30:01.145 [Database] Query completed
14:30:01.147 [API]      Response sent

Pattern Recognition

Error Clustering: Group similar errors

Pattern: "Connection refused to {host}:{port}"
Instances:
  - Connection refused to db-1:5432 (15 times)
  - Connection refused to db-2:5432 (3 times)

Anomaly Detection: Identify unusual patterns

Normal: 10-20 requests/second
Current: 500 requests/second ← Anomaly

Frequency Analysis

Count by category:

Trend analysis:

Hour 1: 10 errors
Hour 2: 15 errors
Hour 3: 25 errors ← Trending up
Hour 4: 50 errors ← Accelerating

Root Cause Indicators

First occurrence: Often indicates trigger

First error: 14:30:01 - "Failed to connect to new endpoint"
Subsequent: 14:30:02+ - "Connection pool exhausted"

Cascade patterns: Later errors caused by earlier ones

14:30:01 [DB] Connection failed
14:30:02 [API] Database unavailable
14:30:02 [API] Database unavailable
14:30:03 [API] Database unavailable
        ↑ Cascade from initial DB failure

Log Retrieval Commands

Supabase

# Available services
api, postgres, auth, storage, realtime, edge-function

# MCP command
mcp__plugin_supabase_supabase__get_logs(project_id, service)

GitHub Actions

# List runs
gh run list --limit 20

# Get logs
gh run view <run-id> --log
gh run view <run-id> --log-failed

Railway

# Recent logs
railway logs

# Follow live
railway logs --follow

Output Formatting

Summary Format

## Log Analysis Summary

**Time Range**: {START} to {END}
**Total Entries**: {COUNT}
**Error Rate**: {PCT}%

### By Level
| Level | Count | % |
|-------|-------|---|
| ERROR | 50 | 5% |
| WARN | 100 | 10% |
| INFO | 850 | 85% |

### Top Errors
1. {Error 1} - {count} occurrences
2. {Error 2} - {count} occurrences

### Timeline
{Key events in chronological order}

### Recommendations
{Based on patterns found}

Detailed Format

For specific error investigation:

## Error Details: {ERROR_TYPE}

**First Seen**: {TIMESTAMP}
**Last Seen**: {TIMESTAMP}
**Occurrences**: {COUNT}

### Sample Entry

{Full log entry}

### Context
{Surrounding log entries}

### Pattern
{What triggers this error}

### Impact
{What this error affects}

See patterns.md for platform-specific log patterns.

Platform-Specific Log Patterns

Supabase Log Patterns

API Gateway Logs

Request Log Format:

{
  "timestamp": "ISO8601",
  "method": "GET|POST|PUT|DELETE|PATCH",
  "path": "/rest/v1/table",
  "status_code": 200,
  "response_time": 45,
  "request_id": "uuid",
  "user_agent": "string"
}

Common Patterns:

Postgres Logs

Error Log Format:

2024-01-15 14:30:00.123 UTC [pid] LOG: statement: SELECT ...
2024-01-15 14:30:00.456 UTC [pid] ERROR: relation "table" does not exist
2024-01-15 14:30:00.789 UTC [pid] FATAL: too many connections

Common Patterns:

Connection States:

-- Healthy distribution
idle: Many (connections waiting)
active: Few (executing queries)
idle in transaction: Few (should release)

Warning Signs:

• High idle in transaction count → Connection leak
• High active with slow queries → Query optimization needed
• Approaching max_connections → Scale or optimize

Auth Logs

Login Event Format:

{
  "timestamp": "ISO8601",
  "event": "login|signup|logout|token_refresh",
  "user_id": "uuid",
  "provider": "email|google|github|...",
  "success": true|false,
  "error": "optional error message"
}

Common Patterns:

Edge Function Logs

Execution Log Format:

{
  "timestamp": "ISO8601",
  "function": "function-name",
  "execution_id": "uuid",
  "status": "success|error",
  "duration_ms": 150,
  "memory_used_mb": 32,
  "logs": ["console output"]
}

Common Patterns:

GitHub Actions Log Patterns

Workflow Run Logs

Run Status:

✓ completed (success)
✗ completed (failure)
○ in_progress
⊘ cancelled

Common Failure Patterns:

Timeout Patterns:

The job running on runner ... has exceeded the maximum execution time

Cache Patterns:

Cache not found for input keys: ...   # Cache miss
Cache restored from key: ...           # Cache hit

Test Failure Patterns

FAIL src/tests/example.test.ts
  ✕ should do something (5ms)

  Expected: "expected"
  Received: "actual"

Common Test Patterns:

Railway Log Patterns

Application Logs

Standard Output Format:

[timestamp] [level] message

Health Check Patterns:

Health check failed: Connection refused
Health check passed

Deployment Patterns:

Deploying from ...
Build started
Build completed in X seconds
Deploy started
Deploy completed

Common Patterns:

Build Logs

Nixpacks Patterns:

==> Building with Nixpacks
==> Installing dependencies
==> Running build command

Common Build Failures:

Log Correlation Strategies

By Request ID

Look for consistent request/correlation IDs across services:

[API]      request_id=abc123 - Request started
[Auth]     request_id=abc123 - Token validated
[Database] request_id=abc123 - Query executed
[API]      request_id=abc123 - Response sent

By Timestamp

Match events within a tight time window:

14:30:01.100 [Service A] Event 1
14:30:01.105 [Service B] Event 2  ← ~5ms later
14:30:01.110 [Service A] Event 3  ← ~10ms after Event 1

By User/Session

Track user journey:

user_id=user123 - Login
user_id=user123 - View dashboard
user_id=user123 - Submit order
user_id=user123 - Error: payment failed

Pattern Matching Regex

Error Extraction

# Generic error line
(?i)(error|fail|fatal|exception|crash)

# HTTP status codes
status[_:]?\s*(\d{3})

# Stack traces
at\s+[\w.]+\([^)]+\)

# Timestamps
\d{4}-\d{2}-\d{2}[T ]\d{2}:\d{2}:\d{2}

Postgres Specific

# Error messages
^ERROR:\s*(.+)$

# Duration logging
duration:\s*([\d.]+)\s*ms

# Connection info
connection.*from\s+([\d.]+)

Performance Metrics

# Response times
response[_-]?time[=:]\s*([\d.]+)

# Memory usage
memory[=:]\s*([\d.]+)\s*(MB|GB|KB)

# CPU usage
cpu[=:]\s*([\d.]+)%