Three log separate log files are written by Rocket Streaming Audio Server:
error.log
- A log of and informative output. Also written to standard output (the console) for ease of use and journald integration.access.log
- A log of listener session statisticsplaylist.log
- A log of "song performances", showing how many listeners were connected to each mount every time the metadata changes.On Linux, logs are written to the /var/log/rsas
directory by default. On Windows, logs are written to %APPDATA%\Oscillicious\Rocket Streaming Audio Server\logs
. The log
directory can be customized in your configuration file as shown:
<paths>
<logdir>/var/log/icecast2/</logdir>
<webroot>/usr/share/rsas/webroot</webroot>
</paths>
You can customize the log filenames and log rotation settings via a <logging>
section like this:
<logging>
<access>
<filename>access.log</filename>
<maxsize>10MB</maxsize>
<maxlogs>10</maxlogs>
</access>
<error>
<filename>error.log</filename>
<maxsize>10MB</maxsize>
<maxlogs>10</maxlogs>
</error>
<playlist>
<filename>playlist.log</filename>
<maxsize>10MB</maxsize>
<maxlogs>10</maxlogs>
</playlist>
</logging>
Rocket Streaming Audio Server strives for Icecast-compatibility, and so the access.log
and playlist.log
are written in the exact same format Icecast uses.
This is so that RSAS can integrate with your existing listener statistics software or log parsing infrastructure, with you having to make any changes.
Logs are automatically rotated once they reach 10 MB in size and on each start of the application. Rotated logs have a number inserted
to their filenames, like access.1.log
, access.2.log
, and so on.
The access log is formatted in the "Combined Log Format", with an extra field at the end indicating how many seconds a listener was connected for (session duration). This format is identical to that used by Icecast.
The access log format is:
%ip% %unused% %unused% [%timestamp%] "%request_line%" %response_status_code% %response_size% "%referrer%" "%user_agent%" %session_duration%
A hyphen indicates the information was not available.
An example snippet from an access log is:
138.197.151.0 - - [30/Jul/2019:17:58:00 +0000] "GET /rock HTTP/1.1" 200 352415 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" 21
192.164.12.0 - - [30/Jul/2019:17:59:27 +0000] "GET /jazz HTTP/1.1" 200 32819529 "-" "ExoPlayerWrapper/5.0.12 (Linux;Android 8.0.0) ExoPlayerLib/2.4.3" 2049
121.199.67.0 - - [30/Jul/2019:17:59:30 +0000] "GET /jazz HTTP/1.1" 200 6635562 "-" "NSPlayer/12.00.7601.24382 WMFSDK/12.00.7601.24382" 829
The playlist log contains a record of each metadata update sent by connected sources, and the number of listeners connected to the mount when the metadata update occurred. This information can be used to tally the number of "performances" of each track played, which is required by some music royalty reporting agencies.
The RSAS playlist log is in the same format as Icecast's playlist log.
The format of the playlist log is:
%timestamp%|%mount%|%listener_count%|%metadata%
An example snippet from a playlist log is:
19/Jul/2019:12:53:13 -0400|/rock|45|The Rolling Stones - Gimme Shelter
19/Jul/2019:12:53:21 -0400|/jazz|83|Miles Davis - So What
19/Jul/2019:12:56:53 -0400|/rock|50|Aerosmith - Walk This Way
19/Jul/2019:12:58:02 -0400|/jazz|86|Etta James - At Last