SmartCARE API for Streaming Servers
With the appropriate configuration, the nginx streaming servers are capable of sending rsyslog data to the SmartCARE server (via UDP). Next, from the total mass of rsyslog data, the Collector module allocates entries on the unicast content streaming (DVR or VoD), processes them and writes to the mongoDB database (in the ngXxx collection).
Example of the rsyslog entry to be allocated:
|
Bash (Unix Shell) |
|
// 1 – playlist loading [remote_addr=192.168.10.201]/[http_x_forwarded_for=–]/[http_x_smartlabs_mac_address=E3:67:11:2A:9C:7B]/[redirector_session=]/[content_id=CH_7_53.ism]/[content_bw=]/[request_unique_id=18021-1537258314-494-28983511]/[msec=1537258314.497]/[upstream_cache_status=–]/[request=GET /dash/CH_7_53.ism/playlist.mpd?csi=65343a32373a37313a32623a39653a376323736d6c373233782331353337323532333932&utcstart=1537209860&utcend=1537210040&closefull HTTP/1.1]/[status=200]/[body_bytes_sent=10333]/[http_x_smartlabs_hls_buffer_total_bytes=–]/[http_x_smartlabs_hls_buffer_free_bytes=–]/[http_x_smartlabs_hls_chunk_duration=–]/[http_x_smartlabs_request_id=–]/[http_user_agent=–]/[upstream_addr=127.0.0.1:9000]/[request_send_time=0]/[request_time=0.003]/[upstream_response_time=0.003]/[csi=65343a32373a37313a32623a39653a376323736d6c373233782331353337323532333932] // 2 – chunk loading [remote_addr=192.168.10.201]/[http_x_forwarded_for=–]/[http_x_smartlabs_mac_address=E3:67:11:2A:9C:7B]/[redirector_session=]/[content_id=CH_7_32.ism/video]/[content_bw=bw3512000]/[request_unique_id=18384-1552385007-46-10841051]/[msec=1552385007.540]/[upstream_cache_status=HIT]/[request=GET /content/CH_7_32.ism/video/bw3512000/139711058844262.mp4 HTTP/1.1]/[status=200]/[body_bytes_sent=1789791]/[http_x_smartlabs_hls_buffer_total_bytes=–]/[http_x_smartlabs_hls_buffer_free_bytes=–]/[http_x_smartlabs_hls_chunk_duration=–]/[http_x_smartlabs_request_id=–]/[http_user_agent=SmartLabs/5.17009.1710 (albis8073; Albis-8073) SmartSDK/release-4.19.1-rc7.1 (https) Qt/4.8.4 API/0.44.3]/[upstream_addr=–]/[request_send_time=0]/[request_time=0.494]/[upstream_response_time=–]/[csi=–] |
If it is not possible to collect and transmit data about the unicast content streaming on the streaming server, similar data can be transmitted directly from subscriber devices. In this case, data about downloading playlists and chunks is transmitted by the devices to the streaming server, which passes them to the SmartCARE server in syslog format.
Format of Unicast Sessions Data
|
rsyslog entry parameter |
Transmitted by subscriber devices? |
Description |
|
remote_addr |
✔ |
IP address of the subscriber device. |
|
http_x_forwarded_for |
Identifying the originating IP address of a client connecting to a SmartCARE server. |
|
|
http_x_smartlabs_mac_address |
✔ |
UID of the subscriber device. |
|
redirector_session |
Session ID of the client device’s current playback |
|
|
content_id |
✔ |
ID of the content unit. |
|
content_bw |
✔ |
Bitrate of the content unit. |
|
request_unique_id |
✔ |
Event (request) unique ID. Used for debugging purposes. |
|
msec |
✔ |
Time in seconds at the moment of logging (up to milliseconds). |
|
upstream_cache_status |
Upstream cache access status. The status can be one of the following: “MISS”, “BYPASS”, “EXPIRED”, “STALE”, “UPDATING”, “REVALIDATED” or “HIT”. |
|
|
request |
✔ |
Content initial request string. Allows to determine the event (request) type: playlist loading or chunk loading. |
|
status |
✔ |
HTTP response status code. |
|
body_bytes_sent |
✔ |
Number of bytes sent to the subscriber device, excluding the response header. |
|
http_x_smartlabs_hls_buffer_total_bytes |
HLS buffer size of the subscriber device. |
|
|
http_x_smartlabs_hls_buffer_free_bytes |
Number of free bytes in the HLS buffer. |
|
|
http_x_smartlabs_hls_chunk_duration |
Chunk duration in seconds. |
|
|
http_x_smartlabs_request_id |
Unique ID of the specific HTTP request. Can be the same for different HTTP streaming servers. |
|
|
http_user_agent |
✔ |
Client application ID on the subscriber device, including software version, STB model and other data. |
|
upstream_addr |
IP address and port or path to the UNIX socket of the group server. If several servers are accessed during the request processing, their addresses are separated by a comma, for example: “192.168.1.1:80, 192.168.1.2:80, unix:/tmp / sock”. If there is an internal redirection from one server group to another using “X-Accel-Redirect” or “error_page“, addresses corresponding to different server groups are separated by a colon, for example, “192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80”. If the server cannot be selected, the variable stores the name of the server group. |
|
|
request_send_time |
Time to process the sendfile system call in milliseconds. |
|
|
request_time |
✔ |
Request processing time in seconds (up to milliseconds) — the time elapsed from the moment of reading the first bytes from the subscriber device to the moment of writing to the log after sending the last bytes to the device. |
|
upstream_response_time |
Time of responses received from upstream servers. If the request came to one group upstream, then to the next, the several values separated by a colon will be presented. |
|
|
csi |
✔ |
Client session ID. |