使用活動記錄檔監控檢視載入時間

確保以最佳方式為使用者呈現檢視是管理員的主要工作之一。使用活動日誌,可以實時識別效能問題,並解決出現的問題,以保持站台平穩運行。

本主題將介紹管理員如何使用 vizql_http_request 事件類型瞭解檢視載入時間,並對效能瓶頸問題進行疑難排解。

必要條件

要監控檢視載入時間,活動記錄檔資料必須採用結構化且可查詢的格式。繼續前,請確保滿足以下先決條件:

  • 活動記錄檔設定:設定活動記錄檔,在 AWS S3 儲存貯體這寫入活動記錄。

  • 資料匯入:將活動記錄產生的記錄檔匯入監視工具,比如 Splunk 或 Amazon EventBridge。也可以將其匯入雲端資料倉儲中,比如 Snowflake 或 Google BigQuery。目標是將資料轉換為可以輕鬆查詢與分析的格式。

附註:本主題未涵蓋將活動記錄檔資料匯入資料儲存的過程。如需詳細說明,請參閱設定活動記錄以及所選資料平台的文件。

開始使用

我們從哪裡開始呢?您可以透過關注儀表板或檢視的初始負載(也稱「啟動程序工作階段」事件)監視檢視效能。此事件通常會捕獲呈現檢視所需的大部分時間,從而清楚地指示載入所花費的時間。

要監視啟動程序事件:

  1. 開啟已設定的監視工具,比如 Splunk 或 Amazon EventBridge。

  2. 篩選這些值:

    1. eventType = vizql_http_request

    2. endpointName = bootstrapSession

    3. eventOutcome = success

  3. 在結果中找到 duration 欄位。

Vizql_http_request 事件的持續時間欄位表示作業完成所花費的時間(以毫秒為單位)。這有助於您追蹤與分析 Tableau 檢視的初始載入時間。

訣竅:不確定從何處入手嗎?使用管理員洞察入門工作簿中包含的「儀表板載入時間」儀表板。此儀表板顯示內容的載入時間與效能評級,有助於您識別有問題的檢視。然後可以使用活動記錄檔即時查看哪些使用者遇到問題,以及工作簿修訂可能對效能的影響。有關詳情,請參閱使用管理員洞察建立自訂檢視

監視錯誤

除效能外,還可以使用啟動程序工作階段資料查看使用者在檢視內容時是否發生錯誤。要查看這些錯誤,請搜尋 eventOutcome 與 eventOutcomeReason 欄位。這些欄位對於設定監視警報和提供調查起點很有用。例如,如果使用者在檢視儀表板時報告錯誤,則可以查看啟動程序工作階段以了解使用者互動歷程記錄。這有助於您查明觸發錯誤的原因並確定出現問題的起始時間。瞭解此資訊對於找出問題的根本原因非常重要。

  • eventOutcome:此欄位記錄每項作業的高等級成功或失敗類別(success、failure、client_error 或 internal_error)。

  • eventResultReason:此欄位提供有關所發生問題的更多詳細資訊,通常會記錄描述錯誤的 HTTP 狀態代碼。

要監視錯誤,請執行以下操作:

  1. 開啟已設定的監視工具,比如 Splunk 或 Amazon EventBridge。

  2. 篩選這些值:

    1. eventType = vizql_http_request

    2. endpointName = bootstrapSession

    3. eventOutcome != success

  3. 在結果中檢視 eventOutcomeReason 了解有關該錯誤的詳細資訊。

效能問題疑難排解

導致效能問題有很多因素,這讓調查變得困難。但您可以採用一些方法簡化該過程。本小節概述了使用啟動程序會話對工作簿效能進行故障排除的常見方法。首先,請確定問題是否僅限於一個或幾個工作簿。然後,請按照相關章節中的說明進行操作。

對單一工作簿進行疑難排解

如果效能問題與單一工作簿有關,請使用以下步驟。

  1. 確定工作簿修訂版本:

    檢查新的工作簿修訂版是否引入新的效能問題。可以透過在啟動程序工作階段中檢閱 workbookRevision 屬性執行此作業。此過程可能需要將使用者的存取情況與工作簿的先前版本進行比較。

    如果是新的修訂版本導致效能問題,請聯絡工作簿擁有者並與他們一起改進設計。

  2. 檢查具體使用者的問題:

    如果效能問題並非是某個工作簿修訂版的特定問題,請確定該問題是否僅影響某些使用者。您可以透過查看啟動程序工作階段中的 requestUriactorUserLuid 屬性執行此作業。requestUri 屬性提供正在存取的工作簿或檢視的 URL,而 actorUserLuid 屬性提供存取檢視的使用者。同時使用兩者可幫助您區分各個使用者工作階段。

    如果僅是某位具體使用者的問題,請尋找不同使用者之間的相似之處。例如,這可能是由於這些使用者正在存取的自訂檢視或他們與檢視交互的某些方式所致。您需要解析 requestURI 屬性以確定具體檢視。

  3. 檢閱列層級安全性:

    如果某些使用者遇到效能問題,且不是因自訂檢視所致,則問題可能與工作簿中實作的列層級安全性 (RLS) 有關。RLS 會顯著影響效能,尤其是在安全規則複雜或資料集很大的情況下。詳情請參閱Tableau 中的列層級安全性選項概觀.

工作簿子集疑難排解

如果效能問題涉及某個工作簿子集,請使用以下步驟。

  1. 確定常用資料來源:

    尋找受影響工作簿使用的資料來源中的共性。

    如果受影響的工作簿正在使用與資料庫伺服器或雲端資料倉庫的即時連線,則效能問題可能出在即時連線上。

    如果受影響的工作簿正在使用資料擷取,請檢查它們最近是否有更新。您可以使用 hist_publish_datasource 活動記錄檔中的事件類型或管理見解中的 TS 事件資料來源確定最近的變更。

  2. 檢閱資料來源效能:

    如果是即時連線,請監視資料庫伺服器或雲端資料倉庫的效能。檢查伺服器端最近是否有任何變更或問題。此步驟在 Tableau 外部執行。

    如果是擷取的資料來源,請檢視擷取過程以及所有最近的更新。確保已最佳化該擷取,並且資料不會過大或過複雜。有關詳情,請參閱在 Web 上建立擷取

重要注意事項

使用活動記錄檔監視檢視載入時間是掌握儀表板效能和使用者參與度的好方法。但並非每個儀表板或檢視渲染作業都會產生啟動程序工作階段事件。以下是一些不需要啟動程序工作階段事件的情境:

  • 快取儀表板:如果是從以前的快取中檢索到的儀表板或檢視。

  • 索引標籤切換:如果使用者在同一工作簿內切換製表符,並且載入或快取新製表符的內容。

透過使用 vizql_http_request 事件類型並專注於 bootstrapSession 事件,可以獲得有關檢視效能的寶貴見解並主動解決問題。

感謝您的意見反應!已成功提交您的意見回饋。謝謝!