This documentation is for Dash Enterprise.
Dash Enterprise is the fastest way to write & deploy Dash apps and
Jupyter notebooks.
10% of the Fortune 500 uses Dash Enterprise to productionize AI and
data science apps. Find out if your company is using Dash Enterprise.
This guide serves as a reference for common operations related to monitoring Dash Enterprise and the user-created resources that are running on it.
Monitoring-related information is available in the Dash Enterprise App Manager (as long as the system is healthy) as well as via kubectl commands.
The output of kubectl commands displays a real-time view of the Kubernetes objects
in your cluster. You don’t need to be experienced with Kubernetes objects to follow the steps in this guide.
Warning: Do not use
kubectlto edit or delete any objects in the cluster unless instructed by our customer success team.
The Monitoring page in the Dash Enterprise App Manager is only available when Dash Enterprise is installed on a single server.
We use core system to refer to the Dash Enterprise components that exclude user-created resources like Dash apps.
We recommend checking the health of the core system after a new installation or upgrade.
The best way to get an overview of core system health is to check the status of the appstack and buildstack. Appstack represents the Dash Enterprise web app
(referred to as the App Manager and Portal in documentation for Dash developers), and buildstack represents the set of tools Dash Enterprise uses to build Dash apps and
workspaces.
To check the health of the core system with kubectl:
sh
kubectl get dashenterprise -n plotly-systemIf both the appstack and buildstack are healthy, this indicates that your Dash Enterprise instance is running normally.
A provisioning status indicates that the appstack or buildstack is in the process of provisioning what it needs to be in a healthy state.
A pending status indicates that the appstack or buildstack is waiting for another resource before it can change to a provisioning
or healthy state.
You can use memory usage information to help inform decisions around memory limits.
You can view Dash Enterprise’s overall memory usage in relation to your licensed memory limit on the Platform and Users page (requires the admin role) as well as on the Monitoring page.
We recommend viewing current overall memory usage on the Platform and Users page because the information updates more frequently than that on the Monitoring page.
The Platform and Users page displays Memory Usage and Limits information similar to the example below.
<img>
In most cases, available memory is calculated using Licensed Memory, and Licensed Memory excludes memory reserved for the core system. If you use a different tool to monitor memory on the system, you’ll see different information for available or maximum memory.
If your organization has worked with us to choose a custom server size, or if you have temporarily scaled down your server, then the information displayed in Memory Usage and Limits, including Licensed Memory, is based on the actual memory of your server. In these cases, memory reserved for the core system is not factored into Licensed Memory, but is factored into Used and Available. It is normal for the Used and Available values to not add up to the displayed Licensed Memory.
Go to the Monitoring page to view historical data. Make sure that Memory is selected at the top of the page. At the bottom of the page, the Instance Memory graph displays the system’s overall memory usage over time. It considers everything on the system, including core system components.
You can select a time period that you want to view historical data for. It is not possible to view data older than 7 days.
<img>
The graph uses the local time from your browser. It is not possible to download the data.
There are two places where you can monitor the memory usage of a specific app in the App Manager: The App Info and the Monitoring page.
App information on the Monitoring page is only available to app owners and users with the admin role, but provides more app resource usage information than the App Info and is handy for comparing resource usage to other apps or to the system limits.
Known issue: Users who were recently given the
adminrole may need to log out and back in before they are able to see all apps.
Keep in mind that memory information on the Monitoring page uses MiB, while that in the App Info uses GiB.
Memory usage information for services (managed Redis and Postgres databases) is only available via kubectl.
You can view CPU information on the Monitoring page.
CPU information includes: * CPU usage: CPU millicores used in the last 5 mins * CPU %: CPU usage relative to the total system CPU
CPU usage is sometimes defined in other ways. If you use a different tool to monitor CPU on the system, you may see different data than what is displayed on the Monitoring page.
Overall CPU information on the Monitoring page considers everything on the system (including core system components) whereas app-specific CPU information considers app processes and their workspaces only.
To view current and historical overall CPU usage information, go to the Monitoring page and select CPU at the top of the page.
Current CPU usage and CPU % information is displayed at the top of the page.
<img>
At the bottom of the page, the Instance CPU % graph displays the system’s CPU % over time.
You can select a time period that you want to view historical data for. It is not possible to view data older than 7 days.
<img>
The graph uses the local time from your browser. It is not possible to download the data.
You must be the app owner or have the admin role to view app CPU usage information on the Monitoring page.
The table displays all apps that you own (or, if you have the admin role, it displays all apps on Dash Enterprise). By default, apps are listed in descending CPU % order. You can sort the table differently by selecting a column header. Selecting the same header multiple times cycles through descending, ascending, and unordered, in that order.
Known issue: Users who were recently given the
adminrole may need to log out and back in before they are able to see all apps.
If you need to temporarily stop some CPU-intensive apps, you can identify apps that are infrequently used by sorting them by Last Viewed or Total Views. See App Viewer Analytics for more information on app views, including known issues.
Data in the table is updated every 10 seconds.
<img>
Enter an app name in the search bar to find a specific app. Historical information becomes available when you select an app row (not the name, which takes you to the App Info).
The CPU %: app-name graph displays CPU % over time across the app’s processes and workspace.
<img>
You can select a time period that you want to view historical data for. It is not possible to view data older than 7 days.
If there is replica data for your selected time period, the Replicas graph is displayed. It represents the app’s web process replica count over time (particularly useful for apps that autoscale).
<img>
Note that the data in the table updates more frequently than that in the graphs. All graphs use the local time from your browser. It is not possible to download the data.
Most logs can be viewed from the App Manager as well as with kubectl, and outputs may vary based on the method used.
When viewing logs with kubectl, you’ll be interacting with pods, which are small, sometimes short-lived Kubernetes objects that represent a set of containers. Resources created from the
Dash Enterprise App Manager, like Dash apps, run inside these containers. By finding the pod corresponding to the resource whose logs you want to view,
you can view the resource’s logs.
App build logs in the App Manager have a maximum of 5000 lines (this limit is shared with the app’s other logs), and any logs older than 7 days are cleared. They span multiple app builds, not just the latest.
Pods that are responsible for app builds are cleaned up when the build finishes, so their logs are only available via kubectl for as long as the build is in progress.
If you want to view build logs after a build has completed, view them in the App Manager.
App runtime logs in the App Manager have a maximum of 5000 lines (this limit is shared with the app’s other logs), and any logs older than 7 days are cleared. They span multiple app deployments, not just the latest.
App runtime logs obtained via kubectl are not subject to the 5000 line and 7 day limitations, but are only available for the latest app deployment. This is because when Dash developers restart or deploy a new version of an app, the system cleans up the pods responsible for running past versions.
Workspace build logs in the App Manager have a maximum of 5000 lines (this limit is shared with the app’s other logs), and any logs older than 7 days are cleared.
Workspace debug logs are runtime logs printed by Theia, the framework behind Dash Enterprise Workspaces. These logs are usually not very expansive,
but can sometimes help with debugging.
To view workspace debug logs with kubectl:
sh
kubectl logs -l app=workspace-<app-name> -n dash-apps<app-name> is the name of the app whose workspace debug logs you want to view.Support bundles can also provide information about the health of the system.
The analysis displayed when you generate a support bundle is determined by Plotly-made analyzers and is specific to
the state of the cluster at the moment you generated it, as are the contents of the support bundle itself. Support bundles can help
us investigate your Dash Enterprise instance when you contact us for support.