設定日誌分析的基本管線

選擇清理、剖析和建構日誌資料的工具可能會讓人不知所措 (而且價格昂貴)。但是，當您剛開始時，可以使用像 Metabase 這樣的 BI 工具進行臨時分析，並建立簡單的設定。以下是設定基本日誌分析管線的一些最佳實務。

使用資料連接器工具作為擷取的捷徑

像 Airbyte 這樣的工具可以快速連接到您的資料庫並為您建構日誌。選擇您的日誌來源，例如 AWS CloudTrail，並將其連接到資料庫，例如 Snowflake (相對容易、可擴充、成本合理的解決方案)，或 AWS Aurora Serverless Postgres (容易、有些可擴充、低成本的解決方案)。

其他 ETL 工具，例如 Fivetran 或 Stitch，其運作方式也類似。它們使用連接器將日誌資料從來源 (例如 CloudTrail) 移動到您的資料庫。您也可以同時使用 ETL 工具和執行資料建模，為您完成一些繁重的工作。

使用單一雲端供應商將所有項目集中在一處

Google Cloud Logging 與 BigQuery 連接，因此您可以自動將日誌擷取到您的資料倉儲中。AWS 有多個日誌記錄選項，例如 CloudTrail 或 CloudWatch，您可以將其連接到其資料庫選項之一，例如 Postgres for RDS。Azure Monitor 也具有日誌記錄和儲存功能。

進階使用案例：將多個 AWS 服務的日誌轉儲到 S3 儲存貯體中，並使用 Athena 查詢它們

如果您有一些雲端服務 (例如 AWS) 的經驗，您可以使用整套雲端服務從多個不同的服務中提取日誌，並將它們推送到一個中央位置，以準備進行分析。

例如，將來自 EC2 執行個體的 Web 伺服器或應用程式日誌連同您的 CloudTrail 日誌一起推送到 S3 儲存貯體中。將您的 S3 儲存貯體連接到查詢工具 (例如 Athena)，以便您可以建立一些表格以供分析使用。一旦您有了表格，您就可以連接到您的分析工具並建立疑難排解儀表板，例如將 EC2 事件對應到 CloudTrail 事件以進行根本原因分析的儀表板。

以下是一些您可以與 S3 和 Athena 一起使用的其他 AWS 日誌記錄選項

• CloudWatch：儲存應用程式、系統或自訂日誌
• RDS：儲存錯誤、慢速查詢或交易日誌
• Lambda：儲存包含執行詳細資訊、錯誤訊息和自訂日誌陳述式的 lambda 日誌
• 彈性負載平衡器 (ELB)：儲存包含用戶端 IP 位址、請求時間和回應狀態碼的 ELB 日誌

如果您想更進一步，您可以將 Athena 連接到 dbt，並學習如何在 SQL 中編寫您自己的資料轉換。dbt 簡化了版本控制、部署和測試，而無需執行個別工具。但是，如果您熟悉資料建模和開發人員工具，我們才建議您使用此設定。

批次載入日誌以提高效率

您應該將日誌直接批次載入到您的資料倉儲或 S3 等儲存選項中，以避免延遲和資源消耗。大多數雲端服務都提供批次服務，您可以在其中排程和佇列工作。請注意，如果您要為資料庫或日誌儲存付費，請先仔細檢查批次載入的價格，因為有些雲端服務會按批次上傳收費。

使用資料庫用戶端程式庫或連接器進行擷取

沒有權限存取連接器工具不是問題，但可能需要更多開發工作。使用現有的資料庫用戶端程式庫或驅動程式可以協助您在日誌記錄時直接將日誌擷取到儲存/資料倉儲中。

例如，Postgres 有驅動程式，而 MySQL 有連接器。使用其中一種來連接到您的資料庫，而無需重新發明輪子。

確保您的日誌包含時間戳記、來源、訊息和日誌層級

我們建議在您的日誌檔案中新增四個區域，以使日誌分析更順暢

• 時間戳記：這樣更容易建立事件順序。如果您使用分析工具建立效能監控或稽核與合規性的儀表板，時間戳記尤其重要。
• 來源：例如建立日誌的服務，以及日誌的來源位置/檔案/子服務。您可以使用服務欄位進行疑難排解，或僅僅評估配置給每個服務的資源。
• 日誌訊息：保持訊息清晰簡潔，以便您可以理解每個事件。重複使用關鍵字，以便在文字分析期間更輕鬆地篩選和找到您需要的內容。
• 日誌層級：您可以篩選諸如 ALERT 和 CRITICAL 等層級，以找出哪個日誌需要立即調查和回應。

其他日誌分析的最佳實務和想法

如果您以即時日誌分析或進階或頻繁的日誌分析為目標，則專門用於日誌記錄的工具往往更適合。如果您的團隊已經在使用 ELK 堆疊，則像 Grafana 這樣的工具可能很適合。

以下是一些額外資源，您可以使用這些資源在建立小型日誌記錄管線時做出決策

• 了解將資料科學原則應用於日誌記錄.
• 關於要使用哪個 AWS 資料庫和服務的指南。Google 也提供了文件。
• 了解可以協助您降低成本並隨著時間擴充規模的日誌儲存策略.