glancelog
A fast, Rust-based rapid log analysis.
Overview
glancelog is a rapid log analysis tool that helps systems administrators and security professionals understand their logs by reducing complexity and highlighting patterns. It works by "hashing" log entries - replacing variable data (like numbers, IPs, timestamps) with placeholder characters, then counting how often each pattern appears.
Features
- Multiple log format support: Automatically detects Syslog, RSyslog, Journalctl, EVTX (Windows Event Logs), Secure logs, and more
- Pattern-based analysis: Groups similar log entries to identify what's normal
- Multiple analysis modes:
- Hash mode: Show log patterns with occurrence counts
- Daemon mode: Report log entries by daemon/service
- Host mode: Report log entries by host
- Word count mode: Find qualitatively important words
- Time-based graphs: Visualize log activity over seconds, minutes, hours, days, months, or years
- Flexible filtering: Use stopword files to fine-tune what gets filtered
- Sample display: Show actual log samples for rare entries
- Fast: Built in Rust for excellent performance
Installation
From source
Usage
Basic Commands
Print log lines as-is:
# or use short form
Hash a syslog file, showing patterns:
Get a daemon report:
Get a host report:
Find qualitatively important words:
Graph Commands
Show activity over first 60 seconds:
Show activity over first 60 minutes:
Show activity over first 24 hours:
Track specific patterns:
| |
Graph a specific time range:
# Show hourly activity for a specific date (graphs the full day)
# Show minute-by-minute activity starting from a specific date
# Show second-by-second activity for a 5-minute window
Note: When using --from and --to with graph modes, the graph duration is automatically calculated based on the time range. For example, --hgraph --from "2025-11-14" --to "2025-11-15" will graph 24 hours instead of the default 24 hours starting from the first log entry.
Analysis Modes
-p, --print: Print log lines as-is (respects--from/--tofilters)--hash: Show log patterns with occurrence counts (default)--daemon: Report log entries by daemon/service--host: Report log entries by host--wordcount: Find qualitatively important words--sgraph,--mgraph,--hgraph,--dgraph,--mograph,--ygraph: Time-based graphs
Options
--sample: Show sample output for entries appearing 3 or fewer times (default)--nosample: Don't show samples, only show hashed patterns--allsample: Show samples for all entries instead of hashed patterns-l, --lowcount <NUMBER>: Set threshold for rare vs common events (default: 3)--from <DATETIME>: Filter logs from this datetime (formats: "YYYY-MM-DD HH:MM:SS", "YYYY-MM-DD HH:MM", or "YYYY-MM-DD")--to <DATETIME>: Filter logs to this datetime (formats: "YYYY-MM-DD HH:MM:SS", "YYYY-MM-DD HH:MM", or "YYYY-MM-DD")--filter: Use filter files during processing (default for most modes)--nofilter: Don't use filter files--filter-dir <DIR>: Custom directory for filter files (overridesGLANCELOG_FILTERDIRand default paths)--export-filters [DIR]: Export embedded default filters to a directory (defaults to~/.glancelog/filters)--wide: Use wider graph characters for better visibility--tick <CHAR>: Change the tick character used in graphs (default:#)-v: Verbose output (shows detected log format and entry count)
How It Works
glancelog uses a simple but effective algorithm:
- Parse: Automatically detect and parse log format
- Hash: Replace variable data (numbers, IPs, etc.) with
#characters - Count: Count how many times each hashed pattern appears
- Display: Show patterns sorted by frequency
The philosophy is that:
- Common patterns (high count) are likely normal behavior
- Rare patterns (low count) may indicate issues or anomalies
- By removing certainty (common patterns), you're left with uncertainty (things to investigate)
Filter Files
Filter files contain regular expressions (one per line) that define what should be replaced with #.
Embedded Default Filters
glancelog includes embedded default filter files that are compiled directly into the binary. These filters work automatically as a fallback when no external filter files are found, ensuring the tool works out-of-the-box without requiring separate filter file installation.
Filter Search Paths
glancelog searches for filter files in the following locations (in priority order):
- Custom directory (via
--filter-diroption) - highest priority - Environment variable (
GLANCELOG_FILTERDIR) - User home directory:
~/.glancelog/filters/(cross-platform) - Current directory:
./filters/ - System directories (Unix/Linux only):
/var/lib/glancelog/filters//usr/local/glancelog/var/lib/filters//opt/glancelog/var/lib/filters/
- Embedded defaults - Built into the binary as a fallback
Cross-Platform Home Directory Paths
The home directory filter location varies by operating system:
- Linux:
/home/username/.glancelog/filters/ - macOS:
/Users/username/.glancelog/filters/ - BSD:
/home/username/.glancelog/filters/ - Windows:
C:\Users\username\.glancelog\filters\
Standard Filter Files
hash.stopwords: Used in hash modewords.stopwords: Used in wordcount modedaemon.stopwords: Used in daemon modehost.stopwords: Used in host mode
Exporting Embedded Filters
To customize the default filters, you can export the embedded filters to your filesystem:
Export to home directory (recommended):
# Export to ~/.glancelog/filters/
# All filter files are now available for editing
# hash.stopwords words.stopwords daemon.stopwords host.stopwords
Export to custom directory:
# Export to a specific directory
# Now you can edit and use them
After exporting, you can edit the filter files to add your own regex patterns or remove patterns you don't need. The exported files will take precedence over the embedded defaults based on the filter search priority.
Custom Filter Directory
You can specify a custom filter directory using:
Command-line option:
# Use custom filter directory
# Works with all modes
Environment variable:
# Set for current session
# Or per-command
GLANCELOG_FILTERDIR=/tmp/filters
User home directory (recommended for personal filters):
# Create your personal filter directory
# Add custom regex patterns
# Use automatically (no flags needed)
Priority Example:
# CLI --filter-dir overrides environment variable and home directory
GLANCELOG_FILTERDIR=/filters
# Uses /tmp/filters (CLI has highest priority)
Examples
Finding Issues
# Look for uncommon patterns that might indicate problems
# Find what's generating the most log entries
# See which hosts are most active
# Customize the threshold for rare vs common events
# Filter logs by time range
# Filter logs from a specific date onwards
# Print only logs from a specific time range
Understanding Activity Patterns
# Visualize activity throughout the day
# Track error patterns minute-by-minute
|
# Analyze journalctl logs (systemd)
|
# Find which systemd services are most active
|
Analyzing Windows Event Logs (EVTX)
# Print EVTX events as-is
# Analyze Windows Security event log
# See which event sources are most active
# Analyze events by computer/host
# Find important event patterns
Note: EVTX files are Windows Event Log files typically exported from Windows Event Viewer. You can export them using:
- Event Viewer → Right-click log → Save All Events As → Select EVTX format
- PowerShell:
wevtutil epl Security Security.evtx
Analyzing Apache Web Server Logs
# Print Apache access logs with timestamps
# Analyze request patterns
# See which HTTP methods are most common
# Analyze requests by IP address
# Filter logs by date range
# Show hourly request activity
Supported Apache Formats:
- Common Log Format (CLF):
IP - user [timestamp] "request" status bytes - Combined Log Format:
IP - user [timestamp] "request" status bytes "referer" "user-agent"
Example Apache logs:
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326
192.168.1.1 - - [10/Oct/2000:14:10:20 -0700] "POST /api/login HTTP/1.1" 302 512 "-" "curl/7.68.0"
Analyzing AWS Load Balancer Logs
glancelog supports both Classic ELB and Application Load Balancer (ALB) log formats.
# Print AWS ELB logs with timestamps
# Analyze ELB request patterns
# See which HTTP methods are most common
# Analyze requests by client IP
# Show hourly request activity
AWS ELB Format Example:
2015-05-01T23:00:00.123456Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000073 0.001048 0.000057 200 200 0 29 "GET http://www.example.com:80/ HTTP/1.1" "curl/7.38.0" - -
AWS ALB Format Example:
http 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 0.000 0.001 0.000 200 200 34 366 "GET https://www.example.com:443/ HTTP/2.0" "curl/7.46.0" ...
Note: AWS ELB/ALB logs can be exported from your AWS Console or retrieved from S3 buckets where they're automatically stored.
Analyzing MySQL Logs
# Print MySQL general query log with timestamps
# Analyze query patterns
# See query types (Query, Connect, Quit, Execute)
# Analyze activity by thread
# Show hourly query activity
MySQL General Log Format Example:
2025-11-14T10:00:00.123456Z 5 Connect root@localhost on test_db using TCP/IP
2025-11-14T10:00:01.234567Z 5 Query SELECT * FROM users WHERE id = 123
2025-11-14T10:00:02.345678Z 5 Quit
Note: Enable MySQL general log with SET GLOBAL general_log = 'ON'; and SET GLOBAL log_output = 'FILE';
Analyzing PostgreSQL Logs
# Print PostgreSQL logs with timestamps
# Analyze log message patterns
# See log levels (LOG, ERROR, WARNING, etc.)
# Analyze activity by user@database
# Show hourly activity
PostgreSQL Log Format Example:
2025-11-14 10:00:00.123 UTC [12345] postgres@testdb LOG: database system is ready to accept connections
2025-11-14 10:00:03.456 UTC [12347] admin@testdb ERROR: relation "nonexistent_table" does not exist at character 15
2025-11-14 10:00:07.890 UTC [12349] postgres@postgres FATAL: the database system is shutting down
Note: PostgreSQL logs must be in single-line format. Configure with log_destination = 'stderr' and logging_collector = on in postgresql.conf.
Finding Keywords for Monitoring
# Find important words to monitor with swatch/logwatch
Supported Log Formats
- Syslog (BSD syslog format)
- RSyslog (with high-precision timestamps)
- Journalctl (systemd journal logs)
- EVTX (Windows Event Log binary format)
- Apache Common Log Format (CLF)
- Apache Combined Log Format
- AWS Classic Elastic Load Balancer (ELB) logs
- AWS Application Load Balancer (ALB) logs
- MySQL General Query Log
- PostgreSQL logs (single-line format)
- Secure log (authentication logs)
- Raw text (fallback for unrecognized formats)
Building and Development
Standard Build
# Build
# Run tests
# Build and install
Cross-Platform Builds (Static Binaries)
Use the Makefile to build static binaries for multiple platforms:
# Build for all supported platforms
# Build for specific platforms
# Install required rustup targets
# View available targets
# Clean dist directory
Static Build Strategy:
-
Linux: Uses musl libc for fully static binaries that work on any Linux distribution without dependencies
- Target:
x86_64-unknown-linux-muslandaarch64-unknown-linux-musl - No shared library dependencies - runs everywhere
- Target:
-
Windows: Static CRT linking for minimal dependencies
- Target:
x86_64-pc-windows-msvc,i686-pc-windows-msvc, andaarch64-pc-windows-msvc - Links CRT statically using
-C target-feature=+crt-static - Supports 64-bit, 32-bit, and ARM64 Windows
- Target:
-
macOS: Limited static linking (system frameworks remain dynamic)
- Target:
x86_64-apple-darwinandaarch64-apple-darwin - macOS doesn't support fully static binaries
- Target:
Supported Platforms:
- Linux: x64 (static), arm64 (static)
- macOS: x64, arm64
- Windows: x64 (static), x86/32-bit (static), arm64 (static)
All binaries are placed in the dist/ directory with naming format: glancelog-{platform}-{arch}[.exe]
Verification:
# Verify Linux binary is static
# Output: ... statically linked ...
# Output: statically linked (no dependencies)
Cross-Compilation Requirements:
Some targets require additional tools to be installed:
# For Linux ARM64 musl cross-compilation (on Linux x64 host)
# For Windows cross-compilation
# - On Windows: Install Visual Studio Build Tools with MSVC
# - On Linux: Cross-compilation to Windows MSVC is not well supported
# Use GitHub Actions or build on Windows
Note: macOS targets can only be fully built on macOS hosts with Xcode. Cross-compilation from Linux to macOS is not easily supported. The Makefile will skip targets that cannot be built and show warnings.
Automated Release Builds (GitHub Actions)
The repository includes a GitHub Actions workflow that automatically builds release binaries for all supported platforms when you push a version tag:
# Create and push a release tag
The workflow will:
- ✅ Build static binaries for Linux (x64, ARM64) using musl
- ✅ Build binaries for macOS (x64, ARM64)
- ✅ Build static binaries for Windows (x64, x86/32-bit, ARM64) using MSVC
- ✅ Create a GitHub Release with all binaries
- ✅ Verify Linux binaries are statically linked
- ✅ Use cargo caching for faster builds
Release Assets:
glancelog-linux-x64- Fully static, works on any Linuxglancelog-linux-arm64- Fully static ARM64 binaryglancelog-macos-x64- Intel Mac binaryglancelog-macos-arm64- Apple Silicon (M1/M2/M3) binaryglancelog-windows-x64.exe- Static Windows x64 binaryglancelog-windows-x86.exe- Static Windows 32-bit binaryglancelog-windows-arm64.exe- Static Windows ARM64 binary
Manual Workflow Dispatch:
You can also trigger builds manually from the GitHub Actions tab without creating a tag.
Using glancelog as a Library
glancelog can be used as a library in your Rust projects for programmatic log analysis.
Add to your project
Add glancelog to your Cargo.toml:
[]
= { = "../glancelog" } # Use path for local development
# or
= { = "https://github.com/kost/glancelog" }
Basic Usage
use ;
Hash Analysis
Analyze log patterns by removing variable data:
use ;
Reading from stdin
use ;
Daemon and Host Analysis
use ;
Time-based Graphs
Visualize log activity over time:
use ;
Time Filtering
Filter logs by date/time range:
use CrunchLog;
use ;
Custom Filters
Create custom regex-based filters:
use Filter;
Word Count Analysis
Find qualitatively important words:
use ;
Working with Log Entries
Access individual log entries:
use CrunchLog;
Advanced: Custom Time Ranges with Graphs
use ;
use ;
API Overview
Core Types:
CrunchLog- Main log container with parsed entriesLogEntry- Individual log entry with timestamp, host, daemon, and messageFilter- Regex-based filter for removing variable dataSuperHash- Pattern analyzer with countingGraphHash- Time-based visualization
Enums:
HashMode::Hash- Standard pattern hashingHashMode::Daemon- Group by daemon/serviceHashMode::Host- Group by hostHashMode::WordCount- Count important wordsSampleMode::None- Show hashed patterns onlySampleMode::Threshold- Show samples for rare eventsSampleMode::All- Show samples for all eventsGraphType::{Seconds, Minutes, Hours, Days, Months, Years}- Time granularity
Key Methods:
CrunchLog::from_file(path)- Load from fileCrunchLog::from_stdin()- Load from stdinCrunchLog::filter_by_time(from, to)- Filter by datetime rangeSuperHash::from_log(log, mode, filter)- Create analyzerSuperHash::set_sample_threshold(n)- Set rare event thresholdSuperHash::set_sample_mode(mode)- Configure samplingSuperHash::display()- Print results to stdoutGraphHash::new(log, type)- Create graphGraphHash::new_with_range(log, type, from, to)- Graph with time rangeGraphHash::set_tick(char)- Set graph characterGraphHash::set_wide(bool)- Use wider charactersGraphHash::display()- Print graph to stdout
License
MIT
Credits
Inspired by the petit - original Python-based log analysis concepts.