-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated the metrics reporting url #36
Changes from 5 commits
5205d64
afae228
5adb666
8fe9120
7f43012
28a4997
0521877
c60c3e6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,14 +1,28 @@ | ||
// Temporarily hardcoded catalyst node | ||
const METRICS_REPORTING_BASE_URL = 'wss://sao-canary-catalyst-0.livepeer.fun'; | ||
// Temporarily hardcoded catalyst node, in production we need to point to .studio | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this be pointing to .studio then? Or is this waiting on something? The discussion was a bit confusing to me. This library should only be used in "production" or very similar, production-like environments. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @victorges Are you able to clarify? Is livepeer.fun another staging environment or is it production? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My understanding from the conversation is that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Reporting URL should have the same TLD as the playback URL. If playback is from .studio, use studio, etc. Canary (.fun) is a second staging environment created for multi-node catalyst development. Regular staging is under When multi-node goes to production, we will have studio, monster and fun URLs. .fun is the closest we will have to that, since it is the only multi-node deployment we have right now. Although, the SDK here could just keep the same TLD anyway (maybe with a list of allowed ones) and that should be future-proof. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could already implement this to keep the same tld as the sourceUrl, but if they are not live yet, then we would not be actually be reporting any metrics right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right! But we cannot deploy/use this on any environment before multi-node is deployed (which is what enables this API). Unless we want to release a version that only works on the canary environment anyway. We cannot use metrics from canary (fun) for production (studio) streams anyway, it's a separate timeseries database. So sending them to canary or not sending at all (like trying to send to playback.livepeer.studio) does not make any difference in practice. |
||
const METRICS_REPORTING_BASE_URL = 'wss://nyc-canary-catalyst-0.livepeer.fun'; | ||
|
||
function videoNameFromPlaybackUrl(url: string): string | undefined { | ||
const filename: string[] = url.split('/'); | ||
const videoName = filename[filename.length - 2]; | ||
return videoName ? videoName.split('.')[0] : undefined; | ||
const PLAYLIST_NAME = 'index.m3u8'; | ||
const ASSET_URL_PART_VALUE = 'hls'; | ||
const RECORDING_URL_PART_VALUE = 'recordings'; | ||
|
||
// Example url the playback id needs to be found in | ||
// https://livepeercdn.com/hls/<playback-id>/index.m3u8 | ||
// https://livepeercdn.com/recordings/<playback-id>/index.m3u8 | ||
function playbackIdFromPlaybackUrl(url: string): string | undefined { | ||
const parts = url.split('/'); | ||
const playlistPartIndex = parts.indexOf(PLAYLIST_NAME); | ||
const assetPartIndex = parts.indexOf(ASSET_URL_PART_VALUE); | ||
const recordingPartIndex = parts.indexOf(RECORDING_URL_PART_VALUE); | ||
|
||
// Check if the url is valid | ||
return (assetPartIndex !== -1 || recordingPartIndex !== -1) && | ||
playlistPartIndex !== -1 | ||
? parts[playlistPartIndex - 1] | ||
: undefined; | ||
} | ||
|
||
export function createMetricsReportingUrl(src: string): string | undefined { | ||
const videoName = videoNameFromPlaybackUrl(src); | ||
const videoName = playbackIdFromPlaybackUrl(src); | ||
return videoName | ||
? `${METRICS_REPORTING_BASE_URL}/json_video+${videoName}.js` | ||
: undefined; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we deliberately not handle this case? I am not sure what the playlist names look like, or why we'd want to ignore
master
overindex
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thought is that if this is not an agreed livepeer url, we end processing some random string as playbackID. Then we try to connect a WS to an incorrect URL. So it's going to fail anyway.
If we want it to be more elastic, I can just check that the last parameter contains
.m3u8
and not the specific playlist name.What are your thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO we should ignore anything that doesn't look like a Livepeer URL. We don't want to end up sending metrics about non-existing streams when people use the player for non-Livepeer resources (which we should support).