Before you import Wowza Streaming Engine logs into Sawmill, check the Engine version: the Log4j 2 procedure applies to 4.8.8.01 and later, while 4.8.5 and earlier use a separate legacy Log4j 1.x configuration. Do not copy settings across those version families.
For the documented analysis workflow, enable the stats appender and import wowzastreamingengine_stats.log. Wowza identifies that file as the best choice for log analysis tools; Sawmill lists a Wowza plug-in that parses logs and supports filtered reports.
Check the Engine version before editing
The version determines which configuration file and syntax you should use. Wowza says Log4j 2 is available in Streaming Engine 4.8.8.01 and later; earlier releases use Log4j 1.x. The current analysis instructions cover 4.8.8.01 and later, while the legacy procedure covers 4.8.5 and earlier.
Find the exact version running in your installation before changing logging. Check the Engine interface or the installation details available to you, and confirm which release is actually serving your applications. A staging system and a production system may not be on the same release, especially if they were upgraded separately.
There is a documentation gap for versions 4.8.6 through 4.8.8.00 in the sources reviewed here. Do not guess that either procedure applies to that interval. Consult the documentation shipped for the exact version, or ask Wowza support, before editing a production configuration. The Wowza logging overview explains the version distinction and the Engine’s logging background.
Keep a copy of the configuration file before making changes. If the file has local edits, preserve them and change only what the instructions require. A copied example is not a reason to replace other appender references or logger settings that your installation already relies on.
Choose the matching configuration
For 4.8.8.01 and later, Wowza’s analysis procedure uses [install-dir]/conf/log4j2-config.xml. It asks you to enable the relevant appender references within the Root logger. For 4.8.5 and earlier, the legacy instructions use [install-dir]/conf/log4j.properties, with a different syntax and appender list.
| Engine version | Configuration file | Documented stats setting |
|---|---|---|
| 4.8.8.01 and later | [install-dir]/conf/log4j2-config.xml |
Enable serverStats in the Root logger appender references |
| 4.8.5 and earlier | [install-dir]/conf/log4j.properties |
Add serverStats to the log4j.rootCategory appender list |
| 4.8.6–4.8.8.00 | Check documentation for the exact release | Do not infer a procedure from either row above |
The table is a routing aid, not a substitute for the complete procedure. Read the official instructions for your release, then compare their example with the file on disk. Do not rename the file, convert the syntax, or add a Log4j 2 XML setting to a legacy properties file. The dedicated legacy Wowza analysis instructions are specifically for 4.8.5 and earlier.
If you manage several Engine instances, write down the version and configuration path for each one. This simple inventory prevents a common operational mistake: applying a familiar edit to a different host whose Engine version follows a different logging procedure.
Enable the documented appenders
For 4.8.8.01 and later, Wowza’s documented Root logger references are stdout, serverAccess, serverError, serverStats, vhostAccess, and vhostError. The example uses info for stdout, access, and stats logging, and warn for the error appenders. Follow the current example in the analysis procedure for Log4j 2 versions; do not assume that a similar-looking setting is equivalent.
The stats appender is central to this workflow because it produces the file Wowza recommends for analysis tools. The access and error appenders are also part of the documented setup. Their presence does not mean every question can be answered from the stats file alone: which fields appear depends on the selected appenders and logging configuration. Keep the setup aligned with the documentation and your diagnostic purpose.
For 4.8.5 and earlier, open [install-dir]/conf/log4j.properties and add serverStats to the log4j.rootCategory appender list, as the legacy procedure describes. Wowza’s example is log4j.rootCategory=INFO, stdout, serverAccess, serverError, serverStats. Do not use the XML references or Log4j 2 syntax for this older configuration.
Make the change during a maintenance window if logging behaviour or Engine restarts could affect your operation. Follow Wowza’s instructions for applying configuration changes to your release. Afterward, verify the file is being generated before relying on it; a saved edit alone does not demonstrate that the appender is active or that new records are reaching the expected location.
Find the stats log
Wowza identifies wowzastreamingengine_stats.log as the best log file to use with analysis tools in its documented setup. Engine logs are normally under [install-dir]/logs. The file you want is an Engine log, not a Manager log: Manager logs are under [install-dir]/manager/logs and serve a different purpose.
Locate the installation directory used by the running Engine, then look in its logs directory for the stats file. Check its modification time and whether it grows after the logging configuration is applied. If it is absent or unchanged, first confirm the version-specific procedure, the appender reference, the actual installation path, and the Engine’s own messages. Do not import an unrelated access log simply because its filename looks plausible.
It helps to keep an untouched copy of the source log before importing it into an analysis workflow. That gives you a reference if the parser reports a format issue or if you need to repeat an import after adjusting a profile. Avoid editing records in place: removing a line or changing a field can make later comparisons misleading.
Wowza Manager’s Logs tool is useful for small files and simple searches, but Wowza recommends downloading or accessing logs directly for files several megabytes or larger and for more complex searches. That is especially relevant when an investigation spans a long period or requires comparing many records. The Manager log viewing guidance distinguishes that viewing workflow from working with the files themselves.
Import the stats log into Sawmill
Sawmill lists a Wowza Streaming Engine plug-in. Its product description says the software can parse Wowza logs and create reports with filtering. Start by choosing the Wowza format or plug-in in your Sawmill installation, then point the import at a copy of wowzastreamingengine_stats.log. The Sawmill Wowza plug-in page describes the supported format.
Follow Sawmill’s own import prompts for the version you are using. The reviewed product information does not provide a version-by-version compatibility matrix, so do not assume that the plug-in recognises every customised Wowza format. A representative file is the practical test: check whether Sawmill identifies the fields and produces sensible records before scheduling or repeating imports on a larger log set.
If the file is rejected, or fields are missing, compare the actual record structure with the format expected by the plug-in. Wowza describes detailed default output as Extended Common Log Format, but appenders and configured fields determine what is written. Sawmill also allows custom log formats; that does not mean every custom variation is automatically parsed by its Wowza plug-in. Consult Sawmill’s supported log formats and product documentation rather than assuming a parser capability that is not documented.
Record the file used, the Engine version, and any import settings that matter to the report. This makes it easier to reproduce an investigation after a configuration change. If you are comparing records over time, keep the logging configuration consistent where possible, or note exactly when it changed so that a difference in fields is not mistaken for a change in traffic.
Choose a question before making a report
A report is useful when it answers a defined operational question. Wowza’s documented fields can include client IP (c-ip), protocol (c-proto), referrer (c-referrer), user agent (c-user-agent), bytes transferred (cs-bytes and cs-stream-bytes), stream ID (x-stream-id), connection URI (x-suri), and virtual host (x-vhost). The actual fields available depend on what your configuration records and retains.
For example, if you want to understand which protocols appear in connections, group or filter by c-proto if the imported log includes it. If you want to review transferred traffic, check which byte field is present and what it represents before aggregating it. If you need to distinguish streams or virtual hosts, look for x-stream-id or x-vhost rather than assuming the filename identifies them.
| Question to investigate | Fields to check | What to confirm first |
|---|---|---|
| Which client addresses appear? | c-ip |
Whether client IP is included in the imported records |
| Which protocol is recorded? | c-proto |
Whether the field is populated for the traffic in question |
| How much traffic is represented? | cs-bytes, cs-stream-bytes |
Which byte field is available and how it is defined |
| Which stream or host is involved? | x-stream-id, x-suri, x-vhost |
Whether the relevant identifiers are logged |
| What client software or source is shown? | c-user-agent, c-referrer |
Whether those fields are present and useful for this use case |
Use Sawmill’s filtering to narrow a report to the time, stream, client, or virtual host you are investigating, then aggregate only fields that support the question. An IP address is not a person’s identity, and a user agent is not a reliable census of viewers. Treat these as log attributes, not as proof of who watched or why a connection behaved as it did.
The same discipline helps when a report looks surprising. Confirm the source file, date range, configured fields, and filter conditions before drawing a conclusion. A report can accurately summarise the imported records while still being incomplete for the question you had in mind.
Validate the result and preserve version differences
Start with a small, known sample from the source file and compare it with the corresponding records in Sawmill. Check that timestamps, field values, and record counts behave as expected for the sample. If your format is customised, inspect a few representative lines from each relevant record type; do not presume that a successful import means every field was interpreted correctly.
Keep the Log4j 2 and legacy procedures separate in your notes. The 4.8.8.01-and-later XML setup and the 4.8.5-and-earlier properties setup solve the same broad need—recording stats for analysis—but use distinct configuration files and syntax. The interval between those documented version ranges remains a reason to check exact-release guidance rather than extrapolating.
When a report does not match expectations, check these points in order: is the imported file wowzastreamingengine_stats.log; is it from the Engine rather than Manager; did the relevant appender generate it; are the desired fields present; and are the Sawmill format and filters appropriate? This sequence separates a logging problem from an import problem or a report-definition problem.
For large or complex investigations, work from downloaded log files or the installation directory rather than relying on the Manager’s simple viewing workflow. Retain the original file and note any changes to logging. If you operate a separate continuous YouTube channel, log analysis is a different task from keeping that broadcast running; a troubleshooting guide for a cloud stream that does not resume after an outage covers that separate failure mode.
A log analysis workflow can tell you what was recorded, not what was never logged. If the fields needed to answer a question are absent, adjust logging through the documented procedure for the exact Engine version, then gather a fresh sample. Do not retrofit conclusions onto older files that did not contain those fields.
Keep the log workflow separate from live-channel operations
Wowza log analysis concerns records produced by Wowza Streaming Engine. It is not a requirement for every YouTube live channel, and Sawmill’s documented Wowza plug-in should not be treated as a general YouTube analytics tool. If you run a prerecorded loop on YouTube, your streaming setup and your server-log analysis are separate operational concerns.
For example, checking whether an encoding configuration is suitable for a long-running prerecorded stream is different from investigating a Wowza connection record. The bitrate guide for a 24/7 prerecorded YouTube stream addresses the former. If your channel uses a local playback process rather than Wowza, the guide to looping Hindi videos with NGINX RTMP and FFmpeg covers a different setup and should not be mistaken for a Wowza logging procedure.
If maintaining a continuous broadcast takes more attention than you can give it, StreamNeo can take the specific burden of keeping an uploaded video streaming to YouTube while your own computer is off. That is separate from log analysis: it does not turn Wowza logs into reports or replace version-specific Engine configuration.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Which Wowza log file should I import into Sawmill?
Use wowzastreamingengine_stats.log, which Wowza identifies as the best log file for analysis tools in its documented setup. Engine logs are normally under [install-dir]/logs; do not confuse them with Manager logs under [install-dir]/manager/logs.
How do I enable Wowza serverStats logging?
For 4.8.8.01 and later, follow Wowza’s Log4j 2 instructions in log4j2-config.xml and enable the documented Root logger appender references, including serverStats. For 4.8.5 and earlier, use the legacy log4j.properties procedure and add serverStats to the log4j.rootCategory list. Check exact-release documentation for versions in between.
Does Sawmill support Wowza Streaming Engine logs?
Sawmill lists a Wowza plug-in and describes parsing and filtered reporting for Wowza logs. The reviewed product material does not establish compatibility with every Engine version or custom format, so test a representative file and confirm the fields it imports.
What if the report is missing a field I need?
Check whether the field was configured and recorded in the source log before changing the report. If it is absent, use the logging documentation for your precise Engine version, then collect a new sample; Sawmill cannot report reliably on data the file does not contain.