這篇文章介紹了結構化日志記錄及其使用背後的基本原理。提供了一些簡單的例子來加強了解。
當我學習使用 AWS Lambda 和 Java 編寫無伺服器函數時，我遇到了結構化日志記錄的概念。這讓我對結構化日志的概念很好奇，是以我決定進一步探索它。
什麼是結構化日志記錄？
通常，應用程式生成的任何日志都是以某種方式格式化的純文字。
例如，這是來自 Java 應用程式的典型日志格式：
[Sun Apr 02 09:29:16 GMT] book.api.WeatherEventLambda INFO: [locationName: London, UK temperature: 22 action: record timestamp: 1564428928]
雖然這個日志是格式化的，但它不是結構化的。
我們可以看到它被格式化為以下元件：
- 時間戳（發生時）
- 完全合格的類名（從它出現的地方）
- 記錄級别（事件類型）
- 消息（這部分通常是非标準化的，是以從某種結構中獲益最多，正如我們将看到的那樣）
結構化日志不使用純文字格式，而是使用更正式的結構，例如 XML 或更常見的 JSON。
如果它是結構化的，那麼之前顯示的日志會像這樣：
請注意，message日志的這一部分是您通常感興趣的内容。但是，消息周圍有一大堆中繼資料，這些中繼資料在您嘗試執行的操作的上下文中可能有用，也可能沒有用。
根據您使用的日志記錄架構，您可以自定義顯示的中繼資料。上面顯示的示例是通過Log4J2日志架構從AWS Lambda函數（用 Java 編寫）生成的。
配置如下所示：
XML1個<?xml version="1.0" encoding="UTF-8"?>2個<配置 包= "com.amazonaws.services.lambda.runtime.log4j2" >3個 <附加物>4個 <拉姆達 名字= “拉姆達” >5個 < JsonLayout compact = "true" eventEol = "true" objectMessageAsJsonObject = "true" properties = "true" />6個 </拉姆達>7 </追加器>8個 <記錄器>9 <根 級别= “資訊” >10 < AppenderRef ref = "Lambda" />11 </根>12 </記錄器>13</配置>
在這種情況下，标簽JsonLayout告訴記錄器使用結構化格式（即）JSON。
請注意，我們将其用作 INFO 級别日志的附加程式，這意味着其他級别的日志（例如ERROR或DEBUG）将不會被結構化。在我看來，這種靈活性是有益的，因為您可能不想建構所有日志，而隻想建構您認為需要參與監控或分析的部分。
以下是生成日志的 AWS Lambda 函數的片段。它讀取一個天氣事件，用要記錄的值填充一個地圖，然後将該地圖傳遞給記錄器。
爪哇1個最終 天氣事件 weatherEvent = objectMapper。readValue ( request.getBody ( ) , WeatherEvent.class ) ; _2個的3個HashMap < Object , Object > message = new HashMap <> ();4個留言。放（“動作”，“記錄”）;5個留言。put ( "locationName" , weatherEvent . locationName );6個留言。把（“溫度”，weatherEvent。溫度）;7留言。把（“時間戳”，weatherEvent。時間戳）;8個的9記錄器。資訊（新 對象消息（消息））；
有不同的方法可以實作這一點。您可以編寫自己的類來實作 Log4J2 的接口，然後填充此類執行個體的字段并将該執行個體傳遞給記錄器。
那麼，這一切的意義何在？
為什麼要建構日志？
要回答這個問題，請假設您有一堆原木（例如實際的原木）：
如果我對您說，“檢查左下角頂部的日志”，您将不得不猜測我指的是哪一個。
現在考慮将這些日志構造成一個艙室。
現在，如果我對你說，“檢查構成前門的原木”，那麼你就知道該看哪裡了。
這就是結構好的原因。它使查找内容變得更加容易。
查詢您的日志
可以通過AWS CloudWatch、Kibana和Splunk等監控工具有效地為結構化日志建立索引。這意味着找到您想要的日志變得更加容易。這些工具提供了查詢日志的複雜方法，使故障排除或執行分析變得更加容易。
例如，此螢幕截圖顯示了如何在 AWS CloudWatch Insights 中搜尋發生牛津天氣事件的日志。我們指的是日志元件locationName下的屬性。message
您可以通過過濾和排序進行更複雜的查詢。例如，您可以說，“顯示溫度高于 20 度的前 10 個天氣事件”（在英國很少見）。
從日志中觸發事件
能夠查詢日志的另一個好處是您可以開始衡量事物。然後可以使用這些測量（在 AWS CloudWatch 中稱為名額 ）來觸發事件，例如發送通知。
在 AWS 中，這将通過建立一個表示您要測量的名額，然後根據該名額的條件設定CloudWatch 警報并使用該警報觸發通知（例如，SNS）來實作。
例如，如果您想在倫敦溫度超過 20 度時發送一封電子郵件，您可以為倫敦在一段時間内（比如 5 小時）的平均溫度讀數建立一個名額，然後建立一個将激活的警報當這個名額超過 20 度時。然後可以使用此警報觸發對 SNS 主題的通知。然後将通知 SNS 主題的訂戶，以便他們知道不要穿暖和的衣服。
結構化日志有缺點嗎？
關于是否使用結構化日志的決定應該由您為系統設想的整體監控和分析政策驅動。例如，如果您有一個無伺服器應用程式，它是與其他服務相關的更廣泛系統的一部分，那麼集中這些不同服務的日志是有意義的，這樣您就有一個統一的系統視圖。在這種情況下，将日志結構化将極大地幫助監控和分析。
另一方面，如果您有一個非常簡單的應用程式，它隻提供來自單個資料源的資料并且不連結到其他服務，則您可能不需要建構日志。我們不要忘記那句古老的格言：保持簡單，愚蠢。
是以，要回答“結構化日志有缺點嗎？”這個問題 - 僅當您在不需要的地方使用它時。當使用簡單的日志就可以正常工作時，您不想花時間進行額外的配置并且不必考慮結構。
結論
結構化日志記錄不僅可以幫助您更有效地分析日志，還可以幫助您在系統中建構更好的監控功能。除此之外，還可以通過相關查詢和設定名額和通知來增強業務分析，這些名額和通知可以表明系統中的趨勢。
簡而言之，結構化日志記錄不僅僅是日志記錄。它是一種驅動架構模式的工具，可增強監控和分析。