Access log file

Flash Media Server 2 maintains an access log that includes statistics about client connections and stream activity. Flash Media Server 2 also maintains application logs for application activities and application logs for diagnostic logs. The application and diagnostic logs are an addition to operating system logs that log error and informational messages about Flash Media Server 2 operations.

The access log records information about requests by Flash Player and Flash Media Server 2 application instances. Using these logs, you can find out when a user connected to the server, the total bandwidth consumed during the session, and information about resources such as the streams accessed by the connection. You can use this information to determine which applications are the most frequently used.

The default access log is access.xx.log, which is located in the Flash Media Server 2 logs directory. The default configuration for Flash Media Server 2 creates a single access log per server. You can also configure Flash Media Server 2 to create a separate file per vhost. When logging is configured on a per-vhost basis, all logs for a particular vhost are found in a subdirectory within the logs directory. The name of the subdirectory matches the vhost name. Substitution strings can be found in the [] brackets, YYYY, MM, DD, and NN representing year, month, date, and version. You can use the substitution string to customize the filename of the access log.

To configure the server to create separate log files for each vhost, set the value of the Scope tag in the Server.xml file to "vhost" (see the description of the tag Scope).

Flash Media Server 2 defines event categories, and for each category it defines events that can be recorded. Logging can be customized to record all events or only specific events. This determines how much information is collected.

Event	Category	Description
connect-pending	application	Client connects to the server, waiting for the script to authenticate.
connect	application	Client connects to the server.
disconnect	application	Client disconnects.
publish	application	Client publishes a live stream.
unpublish	application	Client unpublishes a live stream.
play	application	Client plays a recorded or live stream.
pause	application	Client pauses playing a stream.
unpause	application	Client resumes playing a stream.
seek	application	Client jumps to a new location within a recorded stream.
stop	application	Client stops playing a recorded or live stream or stops publishing a live stream.
record	application	Client begins the recording of a stream.
recordstop	application	Client stops the recording of a stream.
server-start	application	Server has started.
server-stop	application	Server has stopped.
vhost-start	application	A virtual host has started.
vhost-stop	application	A virtual host has stopped.

Field	Event(s)	Description
x-event	application	Type of event.
x-category	application	Event category.
date	application	Date at which the event occurred.
time	application	Time at which the event occurred.
tz	application	Time zone information.
x-ctx	application	Event-dependent context information.
x-pid	application	Server process ID.
x-cpu-load	application	CPU load.
x-mem-load	application	Memory usage (as reported by the `getServerStats()` method).
x-adaptor	application	Adaptor name.
x-vhost	application	Virtual host name.
x-app	application	Application names.
x-appinst	application	Application instance names.
c-ip	application	Client IP address.
c-proto	application	Connection protocol: RTMP or RTMPT.
s-uri	application	URI of the Flash Media Server 2 application.
c-referrer	application	URI of the referrer.
c-user-agent	application	User agent.
c-client-id	application	Client ID.
cs-bytes	application	This field shows the number of bytes transferred from the client to the server. This information can be used to bill customers per session. To calculate the bandwidth usage per session, subtract the 'cs-bytes' in the 'connect' event from the 'cs-bytes' in the 'disconnect' event.
sc-bytes	application	This field shows the number of bytes transferred from the server to the client. This information can be used to bill customers per session. To calculate the bandwidth usage per session, subtract the 'sc-bytes' in the 'connect' event by the 'sc-bytes' in the 'disconnect' event
x-sname	application	Stream name.
x-file-size	application	Stream size in bytes.
x-file-length	application	Stream length in seconds.
x-spos	application	Stream position.
cs-stream-bytes	application	This field shows the number of bytes transferred from the client to the server per stream. To calculate the bandwidth usage per stream, subtract the 'cs-stream-bytes' in the 'publish' event by the 'cs-stream-bytes' in the 'unpublish' event.
sc-stream-bytes	application	This field shows the number of bytes transferred from the server to the client per stream. To calculate the bandwidth usage per stream, subtract the 'sc-stream-bytes' in the 'play' event by the 'sc-stream-bytes' in the 'stop' event.
cs-uri-stem	application	Stem portion of s-uri (omitting query) field.
cs-uri-query	application	Query portion alone of s-uri.
x-sname-query	application	Query portion of stream URI specified in play or publish.
x-file-name	application	Full path of the file representing x-sname stream.
x-file-ext	application	Stream type (currently this can be flv or mp3).
s-ip	application	IP address or addresses of the server.
x-duration	application	Duration of a stream or session event.
x-suri-query	application	Same as x-sname-query.
x-suri-stem	application	This is a composite field: cs-uri-stem + x-sname + x-file-ext.
x-suri	application	This is a composite field: cs-uri-stem + x-sname + x-file-ext + x-sname-query.
x-status	application	For a complete description of the x-status codes and descriptions, see the following table.

Field	Status Code	Description
connect-pending	100	Waiting for the application to authenticate.
connect	200	Successful connection.
	302	Application currently unavailable.
	400	Bad request; client connected to server using an unknown protocol.
	401	Connection rejected by the application script.
	403	Connection rejected by access module.
	404	Application not found.
	409	Resource limit exceeded.
	413	License limit exceeded.
	500	Server internal error.
	502	Bad gateway.
	503	Service unavailable; for instance, too many connections pending for authorization by access module.
play	200	Successful.
	400	Bad request (invalid arguments).
	401	Access denied by application.
	403	Play forbidden by stream module.
	404	Stream not found.
	415	Unsupported media type.
	500	Server internal error.
publish	200	Successful.
	400	Bad request (invalid arguments).
	401	Access denied by application.
	409	Stream is already being published
	415	Unsupported media type.
	500	Server internal error.
stop	200	Successful.
	408	Stream stopped because client disconnected.

Comments

*ron said on Jan 17, 2007 at 5:08 AM :

whats status code 278?
got that id in the access.log

MM tech writer said on Jan 18, 2007 at 5:51 PM :

A Flash Media Server engineer looked in the code and couldn't find status code 278. I would suggest calling Adobe Support to help you trouble shoot.

No screen name said on Jan 26, 2007 at 3:19 PM :

Please supply the units for x-spos. Also what is the relation between x-spos and x-duration?

tech_writer_00 said on Mar 27, 2007 at 4:31 PM :

x-spos is the position of the current stream in seconds.

Depending on the context, x-duration can mean different things:

For a stream: the number of seconds the stream has played.
For a session: the number of seconds the client has been connected.

The relationship between x-spos and x-duration in the context of the stream event: if the stream played straight through x-spos and x-duration would be the same.

No screen name said on Aug 30, 2007 at 6:48 AM :

Under which circumstancers would the sc-stream-bytes value for the play event other than 0? Simply trying to transfer the total traffic and duration for every video stream into a database. Direct approach would be to only transfer the sc-stream-bytes and x-duration value of stop events and treat every stop event as a unique video stream.

In other words, please explain the sentence: "To calculate the bandwidth usage per stream, subtract the 'sc-stream-bytes' in the 'play' event by the 'sc-stream-bytes' in the 'stop' event."

lewispringle said on Dec 4, 2008 at 12:44 PM :

I frequently find that I get stream unpublish events with a negative value for cs-stream-bytes. It appears to the casual observer to be a 32-bit-overflow bug with FMS.

I note - on those same bad loglines, that the cs-bytes value appears a reasonable >4GB number.

Is there any reliable way to tell how many bytes were streamed to an FMS server from Flash Media Encoder, if that number of bytes might exceed 4GB?

As examples of the cs-bytes/cs-stream-bytes values I received in one example logline:

8288855359 -301082487

tech_writer_00 said on Dec 8, 2008 at 10:35 AM :

Looks like this may be a bug. I've filed a bug -- engineering should follow up with you.
Thanks,
Jody

No screen name said on Jan 7, 2009 at 10:52 AM :

We too have logs with both "stop" and "disconnect" events with a negative "sc-bytes" value.

Adding 2**32 to the values I got while testing gives a reasonable looking numbers. Saddly we can't rely on doing that in production because we don't know how many times the counter wrapped.

We really need a fix for this. Is there a bug report for this problem that I can view or comment on? We are running Flash Media Interactive Server 3.0.

PS: I have subscribed to this page.

jody_b said on Jan 7, 2009 at 11:17 AM :

I've added your information to Bug #1934957 which is still open.
Engineering should be getting in touch with you to find out which version of the server you're using.

Thanks for letting us know.
Jody