Overview
LogCentral's filtering feature helps you reduce storage costs by automatically dropping unwanted logs before they're stored in your system.
By setting up filter patterns, you can prevent noisy, repetitive, or unnecessary log entries from consuming your storage quota—keeping only the logs that matter most to your organization.
How to Access
Navigate to your location's details page to find the Filter Rules section. You'll need appropriate permissions to manage filtering rules for your location.
Main Features
Enable/Disable Filtering
Control whether your filter rules are active with a simple toggle.
When filtering is disabled, all logs are stored as usual.
When enabled, logs matching your patterns are dropped before storage.
Pattern Management
Add regex patterns that match the logs you want to drop. The system supports:
Up to 50 filter patterns per location
Maximum 500 characters per pattern
Regex pattern validation with error feedback
Easy pattern removal when rules are no longer needed
Example Pattern
One of our customers uses this pattern in their Cisco Meraki logs to filter noise:
(pattern:\\\\s*allow all|flows allow|ip_flow_end)
Test Your Patterns
Before committing to filter rules, test them against your actual log data:
Preview which logs would be matched and dropped
See sample log lines that match your patterns
Test against the last 7 days of log data
Validate that your regex patterns work as expected
Storage Savings Preview
Make informed decisions about filtering with detailed savings information:
Volume reduction percentage showing what portion of logs would be filtered
Bytes saved displaying the actual storage impact
Sample matches demonstrating which log entries will be dropped
This helps you understand the cost-benefit of each filter rule before enabling it.
Regex Syntax Guide
LogCentral uses standard regex patterns to match log messages. Here's what you need to know:
Basic Syntax
Literal text: Matches exactly (e.g.,
errormatches "error")Dot (.): Matches any single character
Asterisk (*): Repeats the previous character 0 or more times
Plus (+): Repeats the previous character 1 or more times
Question mark (?): Makes the previous character optional
Pipe (|): OR operator (e.g.,
error|warningmatches either)Character classes:
[abc]matches a, b, or cNegated classes:
[^abc]matches anything except a, b, or cAnchors:
^for start of message,$for end of message
Common Patterns
\d- Any digit (0-9)\w- Any word character (letter, digit, underscore)\s- Any whitespace character\b- Word boundary.*- Any characters (use sparingly)
Examples
Drop all DEBUG logs:
DEBUGDrop health checks:
\/health|\/ping|\/statusDrop specific IP:
192\.168\.1\.100(note: escape the dots)Drop a range of codes:
HTTP [45]\d{2}(matches 400-599)Drop multiple keywords:
(test|staging|development)
Pattern Limits & Safety
To protect system performance, certain pattern types are not allowed:
Technical Limits:
Maximum 50 patterns per location
Maximum 500 characters per individual pattern
Maximum 10,000 characters total across all patterns
Blocked Pattern Types:
Excessive wildcards like
.*.*.*(causes catastrophic backtracking)Very large repetitions like
.{1000}Deeply nested groups (3+ levels)
Extremely long escape sequences
Important Note: Patterns are case-insensitive by default, so ERROR will match "error", "Error", and "ERROR".
How Filters Work
What Gets Matched
Filters match against the MESSAGE field of your logs - the actual log content, not metadata like timestamps or hostnames.
Multiple Pattern Logic
When you have multiple patterns:
A log is dropped if it matches ANY of your patterns
All patterns work together with OR logic
If a log matches pattern #1 OR pattern #2 OR pattern #3... it's dropped
Performance Tips
More specific patterns are faster than broad wildcards
Start with the most common patterns first
Avoid
.*at the beginning of patterns when possibleTest patterns before enabling to ensure they work as expected
Best Practices
✅ Do:
Test patterns with the preview feature before enabling
Start with narrow, specific patterns
Document why each pattern exists (for team members)
Review filter effectiveness regularly using savings metrics
Keep patterns readable - break complex patterns into multiple simpler ones
❌ Don't:
Use overly broad patterns like
.*aloneFilter logs you might need for debugging later
Enable filters without testing first
Create overlapping patterns (consolidate them)
Filter security-relevant logs
Common Use Cases
Reduce Noise from Verbose Applications
Drop debug-level logs from chatty services that generate thousands of entries per minute but provide little value in production.
Filter Out Health Checks
Eliminate repetitive health check pings from load balancers that clutter your logs without adding operational insight.
Block Spam or Bot Traffic
Remove automated scanner logs or bot requests that don't represent real user activity.
Comply with Data Policies
Drop logs containing sensitive information that shouldn't be stored, helping you meet compliance requirements.
Focus on Critical Events
Filter out informational messages to keep only warnings, errors, and critical events that require attention.
Space Savings
The filtering system provides transparent visibility into your potential storage savings. By testing patterns against recent log data, you can see exactly how much volume would be reduced before enabling filters. This data-driven approach helps you:
Optimize storage costs without guessing
Identify the highest-impact filter patterns
Balance between log retention and cost efficiency
Make confident decisions about which logs to keep
Remember that filtered logs are dropped permanently—they won't be available for search or analysis later. Choose your filter patterns carefully to ensure you're not losing valuable diagnostic information.