-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Adds a monitoring dashboard to Gradio apps that can be used to view usage #8478
Conversation
🪼 branch checks and previews
Install Gradio from this PR pip install https://gradio-builds.s3.amazonaws.com/c03269a6da2cb3e12a7716dcab2115655463867e/gradio-4.33.0-py3-none-any.whl Install Gradio Python Client from this PR pip install "gradio-client @ git+https://github.com/gradio-app/gradio@c03269a6da2cb3e12a7716dcab2115655463867e#subdirectory=client/python" Install Gradio JS Client from this PR npm install https://gradio-builds.s3.amazonaws.com/c03269a6da2cb3e12a7716dcab2115655463867e/gradio-client-1.1.0.tgz |
🦄 change detectedThis Pull Request includes changes to the following packages.
With the following changelog entry.
Maintainers or the PR author can modify the PR title to modify this entry.
|
gradio/analytics_dashboard.py
Outdated
if __name__ == "__main__": | ||
data["data"] = { | ||
random.randint(0, 1000000): { | ||
"time": time.time() - random.randint(0, 60 * 60 * 24 * 3), | ||
"status": random.choice( | ||
["success", "success", "failure", "pending", "queued"] | ||
), | ||
"function": random.choice(["predict", "chat", "chat"]), | ||
"process_time": random.randint(0, 10), | ||
} | ||
for r in range(random.randint(100, 200)) | ||
} | ||
|
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.
Is this real data or mock data?
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.
its mock data that's created if you run this file directly, but will use real data in gradio runtime
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.
cool
…radio into analytics_dashbaord
2 high-level points @aliabid94:
|
Disagree, because if your app prints a lot to console, you will lose the URL deep into console history. Also people will forget to enable it before launching an app, and then lose access to analytics. |
Ok I see what you mean. I still think we should another word than "analytics" like "monitoring" |
changed to "monitoring" |
@app.get("/monitoring/{key}") | ||
async def analytics_dashboard(key: str): | ||
if key == app.analytics_key: | ||
analytics_url = f"/monitoring/{app.analytics_key}/dashboard" | ||
if not app.analytics_enabled: | ||
from gradio.analytics_dashboard import data | ||
from gradio.analytics_dashboard import demo as dashboard | ||
|
||
mount_gradio_app(app, dashboard, path=analytics_url) | ||
dashboard._queue.start() | ||
analytics = app.get_blocks()._queue.event_analytics | ||
data["data"] = analytics | ||
app.analytics_enabled = True | ||
return RedirectResponse( | ||
url=analytics_url, status_code=status.HTTP_302_FOUND |
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.
If I understand correctly, this will start monitoring only after the first time a user visits this endpoint? Is that intentional - why do we want to do that?
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.
fwiw this essentially allows anyone to "start the monitoring" on anyone else's Gradio app
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.
Anyways, if we do do this, how about we also offer the ability for users to set a parameter in launch()
and if they set the parameter, the monitoring URL is immediately printed. I find that pattern more intuitive (and less cumbersome since you have the link immediately available).
Its also easier to describe and publicize -- get an API dashboard with just a single parameter!
I.e.
- A user can set
enable_monitoring=True
when the launch the app - If they forget, they can visible
/enable-monitoring
or something to start (I'm not sure if we need this at all btw)
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.
Nope, only starts the dashboard app when visiting the secret monitoring link, can add enable_monitoring=True
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.
If I understand correctly, this will start monitoring only after the first time a user visits this endpoint? Is that intentional - why do we want to do that?
Nvm I misunderstood, this is fine
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.
Maybe the parameter is still useful as a way to display the URL right there at launch but not a big deal either way
Nit: got this printed in the console:
|
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.
Very cool @aliabid94! This looks great & tested works well. There's lots more we can add, but we can ship this as a v1
This PR adds an analytics dashboard to show all requests processed by the queue and their status. To visit this dashboard, go to the
/analytics
endpoint. This print a secret URL to the console that you can visit to see the actual analytics dashboard.