karlheyes / icecast-kh

KH branch of icecast
GNU General Public License v2.0
298 stars 106 forks source link

Could you please clarify event data meaning? #117

Open alvassin opened 9 years ago

alvassin commented 9 years ago

Does it mean total outgoing traffic or just streaming (received / sent?)

EVENT global stream_kbytes_read $data
EVENT global stream_kbytes_sent $data

What is this?

EVENT global stats 0

Does it mean two conenctions to the STATS protocol?

EVENT global stats_connections 2

What is the difference between following events?

EVENT global source_client_connections $data
EVENT global source_total_connections $data

What this event means?

INFO full list end

Does it show just mount configuration, or display that new connection was handled via cmd auth handler?

EVENT $mount authenticator command

What is difference between FLUSH $mount and DELETE $mount events?

Is this event tied to yp directory, or it is just last track change date?

EVENT /11-31.mp3 metadata_updated 05/Aug/2015:23:39:49 +0300

Why following values differ?

EVENT /11-33.mp3 bitrate 192
EVENT /11-33.mp3 incoming_bitrate 192272
EVENT /11-33.mp3 outgoing_kbitrate 384

Is there any difference between stream started time & mount creation time?

EVENT $mount stream_start 04/Aug/2015:12:00:31 +0300
EVENT $mount connected 193513

What is queue_size?

EVENT /143-424.mp3 queue_size 64784
karlheyes commented 9 years ago

the global streamkbytes* for for the source streams, not for file serving. There is an argument for doing this with rate limited content like fallback files but is not currently counted for those, legacy reasons.

stats/stats_connections is the number/accumulated stats clients, so yes in relation to the STATS protocol.

source_total_connections is the total of relays and sources that have actually connected. The total could be removed later as it adds little value to stats that is not provided elsewhere.

"INFO full list end", was one that was added to identify the end of the big list at the beginning. When initially connected, you get a snapshot (a blast of content), and this just marks the end of it. After this then the stats are generated since the snapshot.

audio_codecid is the subyte for the ADTS, so yes either MP3 or AAC. Whether it adds much over the mime type I don't know.

The mount authenticator is just informational for the auth type involved, it is certainly something that could be expanded on or removed, as I've not had any real use of that.

FLUSH and DELETE are really tied to assist relaying. The NEW and DELETE are there to notify when sources are created/removed. This can allow for slaves to create relays immediately, rather than wait for polling by the slaves. The FLUSH is another informational thing. Relays, when they terminate, can restart immediately (eg if the TCP link breaks) and this triggers the FLUSH. A delayed restart, relay disable or source client termination would not trigger this (those should trigger a DELETE). The key reason for the flush is if a relay restarts then you can clear out the current stats for that mount (without removing the mount and avoiding a race with a NEW) and get a fresh set of stats in, and therefore not have any stale stats from a previous connection.

The metadata_updated is tied to the update of the track whether YP is involved or not.

I do have some work for creating the relays from a stats connection, but has not yet been merged in.

karl.

alvassin commented 9 years ago

@karlheyes thank you for such detailed answer!

Could you also please clarify, what means queue_size event (EVENT /143-424.mp3 queue_size 64784)?

karlheyes commented 9 years ago

Each source has a queue and it can vary in length between (typically ) to , lagging clients cause the length to increase until they either get kicked off or they catch up. The stat you mentioned is just the measure of the current length.

karl.

alvassin commented 9 years ago

Thank you very much! When i access /admin/stats, there is two different connections parameters: client_connections (as i understand, it contains sum of source, listener, web requests) and connections, which value is bigger. Does connections contain also internal icecast requests?

alvassin commented 9 years ago

Is it right, that source_relay_connections parameter displays how many connection has made current server as relay to source, located at another server?

karlheyes commented 9 years ago

connections also includes relays starting up, client_connections is externally triggered, source_relay_connections is the count of relay connection attempts to any server.

karl.