Your server logs contain thousands of events — requests, connections, errors, and data flows. Somewhere in that noise are the patterns that matter: which sources generate the most traffic, which protocols dominate, when traffic spikes occur, and which events are anomalous. This module turns raw log data into a structured traffic analysis with protocol breakdowns, Pareto-ranked source analysis, temporal patterns, destination analysis, and statistical anomaly detection. Upload a CSV of your log data and get answers in under 60 seconds.
What Is Traffic Analysis?
Traffic analysis examines event logs to understand who is generating traffic, what protocols or event types are used, where the traffic is going, and when it occurs. The goal is to turn a flat list of log entries into actionable intelligence: Are a few sources responsible for most of the traffic (Pareto distribution)? Is there a suspicious spike at 3 AM? Is one destination receiving a disproportionate share of requests? Are there anomalous events that deviate from the normal pattern?
The analysis works with any structured event data — not just network traffic. Server access logs, API request logs, firewall logs, application event logs, CDN logs, or any timestamped event data with a source identifier and event type can be analyzed. The module is designed to be generic: it adapts to whatever event structure your data has rather than requiring a specific log format.
For example, consider a web server access log with columns for timestamp, client IP (source), HTTP method (event type), requested URL (destination), response size (numeric measure), and user agent (event detail). The traffic analysis would show: which IPs generate the most requests (Pareto chart), how requests distribute across HTTP methods (protocol distribution), which URLs are most frequently accessed (destination analysis), hourly traffic patterns (temporal analysis), and which events fall outside normal bounds (anomaly detection).
Or consider a network firewall log with source IP, destination IP, protocol (TCP/UDP/ICMP), port, and bytes transferred. The module would reveal which protocols dominate, which source IPs are most active, which destinations receive the most connections, and which events are anomalous by volume or timing.
When to Use Traffic Analysis
Traffic analysis is valuable for operations teams, security analysts, and anyone who needs to understand patterns in event data.
Capacity planning: Understanding traffic patterns — peak hours, busiest days, growth trends — drives infrastructure decisions. If 80% of your API requests come from 3 clients, and one of them is growing 20% month-over-month, you can plan capacity proactively rather than reactively.
Security monitoring: Anomalous traffic patterns often indicate security issues: port scans, brute force attempts, data exfiltration, or compromised accounts. The anomaly detection feature flags events that deviate from the statistical norm, giving you a starting point for investigation.
Performance troubleshooting: When users report slowness, traffic analysis helps pinpoint the cause. Is one endpoint receiving disproportionate traffic? Is a single client flooding the server? Is there a time-of-day pattern that correlates with reported issues?
API usage monitoring: If you expose an API, understanding who calls it, how often, which endpoints they hit, and how request sizes distribute is essential for rate limiting, billing, deprecation decisions, and documentation priorities.
Content delivery analysis: CDN logs can be analyzed to understand which assets are requested most, where cache hit rates are low (driving origin loads), and how traffic distributes geographically.
What Data Do You Need?
You need a CSV with at least two columns:
Required: event_type — a categorical column identifying the type of event (HTTP method, protocol, request type, log level, action type). source_id — a categorical column identifying the source of the event (client IP, user ID, API key, service name, hostname).
Optional (for richer analysis): timestamp — a datetime column. If provided, the module generates temporal pattern analysis showing traffic volume over time, peak hours, and time-based anomalies. destination — a categorical column for the target of each event (URL path, destination IP, endpoint name, queue name). Enables destination analysis with traffic distribution. numeric_measure — a numeric column like response time, bytes transferred, request size, or processing duration. Enables size distribution analysis and numeric anomaly detection. event_detail — additional detail like user agent, status code, error message, or request parameters. Enables detailed drill-down analysis.
The module auto-detects time granularity when timestamps are provided. Parameters include: top_n (number of top items to display, default 10), anomaly_threshold (standard deviations from mean to flag anomalies, default 2), and time_granularity (auto, hourly, daily — default auto).
How to Read the Report
The report is organized as a progressive investigation, starting with the big picture and drilling into specifics.
The Overview and Data Pipeline slides show dataset size, column types, and preprocessing steps.
The Protocol Distribution chart is a horizontal bar chart showing the breakdown of event types (protocols, HTTP methods, or whatever your event_type column contains). Percentages are shown alongside counts. In most systems, you expect one or two event types to dominate (e.g., GET requests are typically 80%+ of web traffic). An unusual distribution — like POST requests suddenly exceeding GET — is worth investigating.
The Top Sources (Pareto) chart ranks sources by event count with a cumulative percentage line overlay. The Pareto principle often applies to traffic: a small number of sources generate most of the events. The cumulative line shows the 80/20 point — if 3 out of 100 sources generate 80% of traffic, your capacity planning should focus on those 3. Unexpected sources near the top may indicate bots, scrapers, or misconfigured clients.
The Temporal Patterns chart (when timestamp is provided) shows traffic volume over time. Look for regular cycles (daily patterns, weekly patterns), trends (growing or declining traffic), and spikes (events that break the normal pattern). Sudden spikes may correspond to incidents, deployments, marketing campaigns, or attacks.
The Top Destinations chart ranks endpoints, URLs, or target IPs by request volume. In web traffic, this tells you which pages or APIs are most popular. In network traffic, it identifies the most-contacted servers. Unexpected destinations at the top may indicate exfiltration or misconfiguration.
The Protocol x Source Heatmap shows the intersection of event types and sources as a cross-tabulation. This reveals whether certain sources use specific protocols disproportionately — for example, one IP that only sends UDP traffic in a normally TCP-dominated environment.
The Anomaly Detection section flags events that fall outside normal statistical bounds (beyond the configured threshold in standard deviations). The Executive Summary synthesizes all findings into key observations and recommended actions.
When to Use Something Else
If you need real-time log monitoring with alerting, you need a purpose-built observability platform (Datadog, Grafana, ELK). This module is designed for batch analysis of exported log data — answering "what happened" rather than "what is happening right now."
If your primary interest is time series forecasting from the log data (predicting future traffic levels), use the time series forecasting or ARIMA module after aggregating your logs into a daily or hourly time series.
If you want to detect anomalies specifically using machine learning rather than statistical thresholds, consider the Isolation Forest module, which uses ensemble methods to identify outliers in high-dimensional data.
If your logs are web analytics data (page views, sessions, user journeys), the GA4 Source Analysis or Page Engagement modules provide more targeted web analytics reporting.
The R Code Behind the Analysis
Every report includes the exact R code used to produce the results — reproducible, auditable, and citable. This is not AI-generated code that changes every run. The same data produces the same analysis every time.
The analysis uses table() and prop.table() for frequency distributions, cumsum() for Pareto cumulative percentages, and aggregate() for temporal binning. Cross-tabulations use xtabs(). Anomaly detection uses z-score thresholds based on mean() and sd(). Temporal analysis uses as.POSIXct() for time parsing with automatic granularity detection. Destination and source rankings use sort() and head() for top-N selection. Every step is visible in the code tab of your report, so you or an engineer can verify exactly what was done.