Presto Web UI 可以用來檢查和監控Presto集羣，以及運行的查詢。他所提供的關於查詢的詳細信息可以更好的理解以及調整整個集羣和單個查詢。
需要注意的是，Presto Web UI所展示的信息都來自於Presto系統表，關於Presto系統表之後文章中再補充，這裏不再多說；
當你進入Presto Web時，你將會看到如同1所示的界面：主要分爲上下兩部分，上面描述了集羣信息，下面是查詢列表；
首頁
集羣信息
Running Queries
當前在集羣中正在執行的查詢的個數。包含所有用戶提交的查詢；例如，如果Alice正在執行兩個查詢，Bob正在執行五個查詢，那麼在這個指標下顯示的是7。
Queued Queries
當前集羣隊列中正在等待的查詢的個數，也是包含所有用戶的查詢。隊列中的查詢表示這些查詢正在等待Coordinator根據Resource Group的配置爲他們安排調度；
Blocked Queries
集羣中被阻塞的查詢的個數；被阻塞的查詢意味着該查詢因爲缺少可用的Splits或者資源而無法繼續執行（關於Splits的概念 以及查詢何時被阻塞可以參考上一篇文章：Presto On Everything）；
Active Workers
集羣中當前活躍的節點的個數；任何手動會自動添加或刪除的節點都會註冊到Discovery 服務，同時這裏展示的數字將會更新、
Runnable Drivers
集羣中可運行的Drivers的平均數量（當Task被創建之後，他爲每一個Split實例化一個Driver，每一個Driver就是一個Pipeline 中Operators的實例，並對來自Split的數據進行處理，一旦Driver完成，數據將會被傳給下一個Split），
Reserved Memory
集羣中Reserved Memory的大小，單位是bytes。(關於Reserved Memory的概念請參考上一篇文章：Presto On Everything)
Rows/Sec
集羣中所有查詢在每一秒鐘處理的行數
Bytes/Sec
集羣中所有查詢在一秒鐘處理的總共的Bytes
Worker Parallelism
Worker的併發總數，在集羣中運行的所有Worker和所有查詢的CPU Time總和
查詢列表
WBE UI首頁下部分就是查詢列表的展示，當前列表中可以展示的查詢的數量時可以配置的。如圖二所示
如圖所示你可以根據一些條件過濾和定位你想要的查詢；同時提供了搜索輸入框用於定位查詢，輸入的值會匹配很多項，包括：用戶名、查詢發起人，查詢source，查詢ID，resource group甚至SQL文本，和查詢狀態。同樣你可以根據後面預設的一些狀態（running, queued, finished, and failed）對查詢進行篩選；
最左邊的控件允許你確定顯示的查詢的排序順序、重新排序的時間以及要顯示的查詢的最大數量。
下面的每一行表示一個查詢，左側如圖三所示，右側爲查詢的SQL文本；
根據圖三可以觀察當前查詢的細節； 對於每個查詢運行，左上角的文本是查詢ID，圖三中爲：20190803_224130_00010_iukvw
前面是YYYYMMDD_HHMMSS格式的日期，具體的時間是當前查詢運行時的時間，後半部分是一個自增的計數器，00010的含義表示這個查詢時Coordinator重啓以來第10個查詢，最後的字符：iukvw，是隨機生成的Coordinator的標識符，每次coordinator重啓會充值標識符和計數器。
後面緊跟的三個值： ec2-user , presto-cli , 以及global 分別表示，提交該查詢的用戶，查詢的來源，當前查詢的Resource Group。在實例中，當前查詢的用戶是ec2-user，查詢時通過Presto-cli提交的，如果你在Presto CLI中提交SQL 時使用–user指定用戶，那麼界面該查詢展示的就是你所指定的用戶。至於查詢來源除了Presto-CLI之外也可以是：Presto-jdbc ，當你使用JDBC連接Presto時。
圖三最下面的9個指標對應下面的表格；
| Completed Splits: 查詢的已完成Splits的數目。這個例子顯示了25個已完成的Splits。在查詢執行的開始時和執行完成時這個值是0。當查詢正在進行期間這個值會一直增加 | Running Splits: 查詢中正在運行的運行Splits的數量。當查詢完成時，這個值總是0。但是，在執行過程中，隨着Splits的運行和完成，這個數字會發生變化 | Queued Splits： 當前查詢裏出於隊列中的Splits數。當查詢完成時，這個值總是0。但是，在執行期間，這個數字會發生變化 |
|---|---|---|
| Wall Time： 執行查詢所花費的Wall Time。即使在分頁結果時，此值也會繼續增長 | Total Wall Time: 此值與Wall Time相同，但它也包括排隊時間。Wall Time不包括查詢排隊的任何時間。這是您觀察的總時間，從您提交查詢到您接收結果 | CPU Time： 處理查詢所花費的總CPU時間。這個值通常比wallTine時間大，因爲如果使用四個CPU花費1秒來處理一個查詢，那麼總的CPU時間是4秒 |
| Current Total Reserved Memory：當前用於查詢執行總的reserved memory使用。對於已完成的查詢，此值爲0 | Peak Total Memory： 查詢執行期間的峯值總內存使用量。查詢執行期間的某些操作可能需要大量內存，瞭解峯值是多大是很有用的 | Cumulative User Memory： 在整個查詢處理過程中使用的累積內存。這並不意味着所有的內存都是同時使用的。它是累積的內存總量 |
Presto Web UI中的許多圖標和值都有彈出的工具提示，當您將鼠標懸停在圖像上時，這些工具提示是可見的。如果您不確定某個特定值代表什麼，這將非常有用。
當正在運行的查詢在等待某些東西(如資源或要處理的其他Splits)時可能會發生BLOCKED狀態。看到查詢往返於此狀態是正常的，但是如果查詢陷入BLOCKED狀態，可能存在許多潛在的理由，這可能表明當前查詢或者集羣可能存在問題，如果發現有查詢卡在這個狀態，那麼應該檢查集羣的狀態和相關配置，也可能是這個查詢需要非常大的內存或者計算開銷很大。 此外，如果客戶端沒有獲取到返回的結果，或者不能足夠快地讀取結果，反壓機制也會使查詢處於BLOCKED狀態
如果查詢長時間出於PLANNING狀態，這通常發生在較大的複雜的查詢中，因爲查詢要進行大量的規劃和優化處理；但是如果你經常看到這個狀態，並且查詢出於該狀態很長時間，那很可能是因爲coordinator內存問題導致的（之前曾遇到過因HiveMetaStore服務而導致的長時間的PLANNING狀態）。
查詢明細視圖：
通過點擊查詢ID可以跳轉到該查詢的明細界面，如圖四所示
Overview頁面包括查詢列表的查詢細節信息如圖4.1下：
最下面爲Stage部分如圖5所示
這是一個簡單的SELECTCOUNT(*)的查詢，所以只有兩個stages
Stage0 是一個單任務的Stage，運行在coordinator上並且合併來自Stage1的Task（共4個）的數據，以完成最後的聚合；
Stage1是一個分佈式的Stage，他在所有的Worker上執行Task，這個Stage負責讀取數據並進行部分聚合；
其中每個Stage的指標如下：
TIME—SCHEDULED
在完成Stage的所有Task之前，該Stage被調度的時間。
TIME—BLOCKED
因等待數據被阻塞的時間
TIME—CPU
Stage中所有Task的總共的CPU時間
MEMORY–CUMULATIVE
在整個Stage 運行期間的累積內存。這並不意味着所有的內存都是同時使用的
MEMORY—CURRENT
當前stage總共的reserved內存，當查詢結束時，改值爲0
MEMORY—BUFFERS
當前正在等待被處理的數據所消耗的內存
MEMORY—PEAK
該Stage的峯值總內存。查詢執行期間的某些操作可能需要大量內存，瞭解峯值是多少是很有用的。
TASKS—PENDING
Stage中待完成的Task的數量，執行完成時，爲0
TASKS—BLOCKED
stage阻塞Task的數量。當查詢完成時，這個值總是0。但是，在執行過程中，隨着Task在阻塞狀態和運行狀態之間移動，這個數字會發生變化
TASKS—TOTAL
已經完成的Task的數量
最後的圖6描述了Stage更多的細節：
如圖6中指標具體含義如下表所示：
| 字段 | 描述 |
|---|---|
| ID | Task的標識符，StageID.TaskID,中間用點分割，如0.0即Stage0的第0個任務 |
| Host | Task運行所在的Worker節點 |
| State | Task的狀態：PENDING , RUNNING , or BLOCKED |
| Pending Splits | Task的掛起的Splits的數量。此值在Task運行時更改，並在Task完成時顯示0 |
| Running Splits | Task 中正在運行的Splits的數量，在Task運行時改變，Task完成後顯示0 |
| Blocked Splits | Task 中出於阻塞狀態的任務數，Task完成後爲0 |
| CompletedSplits | Task完成的Splits的數量 |
| Rows | Task處理的行數 |
| Rows/s | 每秒處理的行數 |
| Bytes | Task處理的字節數 |
| Bytes/s | Task每秒處理的字節數 |
| Elapsed | Task調度期間 wall time的總和 |
| CPU Time | Task調度期間CPU時間總和 |
| Buffered | 當前等待被處理的緩存數據大小 |
執行計劃（Live Plan）
Live Plan頁面中你可以實時查詢執行處理過程；如圖7所示
在查詢執行期間，計劃中的計數器在查詢執行過程中更新。Plan中的值與Overview選項卡中描述的相同，但是它們在查詢執行計劃上實時覆蓋。 查看此視圖有助於可視化查詢被阻塞或花費大量時間的位置，以便診斷或改進性能問題
Stage Performance
Stage Performance提供了查詢處理完成後Stage 性能的詳細可視化。如圖8所示
該視圖可以看作是Live Plan視圖的下鑽，在Live Plan視圖中可以看到Stage中Task的operator pipeline。計劃中的值與Overview選項卡中描述的值相同。 查看此視圖有助於瞭解查詢在何處卡住或花費大量時間，以便診斷或修復性能問題。您可以單擊每個operator來訪問詳細信息
