當我們沒有使用雲原生方案部署應用時採用的日誌方案往往是 ELK 技術棧。
這套技術方案比較成熟，穩定性也很高，所以幾乎成為了當時的標配。
可是隨著我們使用 kubernetes 步入雲原生的時代後， kubernetes 把以往的作業系統上的許多底層都遮蔽，再由他提供了一些標準介面。
同時在 kubernetes 中的日誌來源也比傳統虛擬機器多，比如可能有容器、kubernetes 自身的事件、日誌等。
我們的日誌採集方案也得與時俱進，kubernetes 的官方部落格有介紹提供一下幾種方案：
節點採集
第一種方案是在節點中採集日誌，我們知道 kubernetes 是分為 master 排程節點以及 worker 工作節點；我們的應用都是執行在 worker 節點中的。
在 kubernetes 環境中更推薦使用標準的 stdout/stderr 作為日誌輸出，這樣 kubernetes 更方便做統一處理。
以我們的 docker 執行時為例，預設情況下我們的標準輸入檔案會寫入到 /var/log 目錄中。
如上圖所示：我們可以在 kubernetes 的每一個 worker 節點中部署一個 DaemonSet 型別的採集器（filebeat 等），再由他去採集該節點下 /var/log 的日誌，最終由他將日誌採集後發往日誌處理的後端，比如 elasticsearch 等元件中。
這種方案的好處是資源佔用較低，往往是有多少個 worker 節點就可以部署多少個採集器。
而且和業務的耦合度低，業務和採集器不管誰進行重啟或升級互相都不會產生影響。
但缺點也比較明顯，整個節點的日誌採集瓶頸都在這個採集器這裡了，如果某些 worker 節點的 Pod 數量不均衡，或者是本身日誌產生也不平均時就會出現明顯的負債不平衡。
而且也無法針對某些日誌高峰場景進行調優（畢竟所有的 Pod 都是使用的一個日誌採集器）。
所以節點級的日誌採集更適用與該 worker 節點負債較低的時候使用，也更容易維護。
Sidecar 代理模式
第二種相對於第一種可以理解為由集中式的日誌採集分散到各個應用 Pod 中自行採集。
需要為每一個業務 Pod 掛載一個邊車（sidecar）進行日誌採集，由於邊車和業務 Pod 共享的是一個儲存，所以可以很方便的讀取到日誌。
由於它是和應用掛載在一起的，所以資源佔用自然會比節點採集更多，同理耦合度也增加了，採集元件的升級可能還會影響的業務 Pod。
但同樣的帶來好處就是可以針對單個 Pod 更精細的控制採集方案。
比如對於一些日誌寫入頻繁的應用，可以將 filebeat 的配置提高，甚至還可以將這種高負載的日誌單獨寫入一個 elasticsearch 中，這樣可以與普通負載的日誌進行資源隔離。
這個方案更適用與叢集規模較大的場景，需要做一些精細化配置。
我們其實也是採用的也是這個方案，不過具體細節稍有不同。
我們沒有直接使用標準輸入和輸出，原因如下：
日誌格式沒法統一，導致最終查詢的時候無法做一些標準化的限制（比如我們要求每個日誌都需要帶業務 id、traceId 等，查詢時候有這些業務指標就很容易沉澱一些標準的查詢語句。）
最終我們還是採用了 Java 的老朋友，logback 配置了自己的日誌格式，所有的應用都會根據這個模版進行日誌輸出。
同時利用日誌框架的批次寫入、緩衝等特性還更容易進行日誌的效能調優。（只使用標準輸出時對應用來說是黑盒。）
最終我們的技術方案是：
直接寫入
還有一種方案是直接寫入，這個其實和 kubernetes 本身就沒有太多關係了。
由業務自己呼叫 elasticsearch 或者其他的儲存元件的 API 進行寫入，這種通常適用於對效能要求較高的場景，略過了中間的採集步驟，直接寫入儲存端。
這個我在 VictoriaLogs：一款超低佔用的 ElasticSearch 替代方案中介紹過，我需要在 broker 的攔截器中埋點訊息資訊，從而可以生成一個訊息🆔的鏈路資訊。
因為需要攔截訊息的傳送、消費的各個階段，加上併發壓力較高，所以對日誌的寫入效能要求還是蠻高的。
因此就需要在攔截器中直接對寫入到日誌儲存。
這裡考慮到我這裡的但一場景，以及對資源的消耗，最終選取了
victoriaLog這個日誌儲存。
而在傳送日誌的時候也得用了高效能的日誌發生框架，這裡選取了aliyun-log-java-producer然後做了一些定製。
這個庫支援以下一些功能：
- 高效能：批次傳送、多執行緒等
- 自動重試
- 非同步非阻塞
- 資源控制（可以對記憶體、數量進行控制）
因為這是為阿里雲日誌服務的一個元件，程式碼裡硬編碼了只能寫入阿里的日誌服務。
所以拿來稍加改造後，現在可以支援自定義傳送到任意後端，只需要在初始化時自定義實現傳送回撥介面即可：
ProducerConfig producerConfig = new ProducerConfig();
producerConfig.setSenderArgs(new Object[]{vlogUrl, client});
producerConfig.setSender((batch, args) -> {
StringBuilder body = new StringBuilder();
for (String s : batch.getLogItemsString()) {
body.append("{\"create\":{}}");
body.append("\n");
body.append(s);
body.append("\n");
}
RequestBody requestBody =
RequestBody.create(MediaType.parse("application/json"), body.toString());
Request request =
new Request.Builder()
.url(String.format("%s/insert/elasticsearch/_bulk", args[0]))
.post(requestBody)
.build();
OkHttpClient okHttpClient = (OkHttpClient) args[1];
try (Response response = okHttpClient.newCall(request).execute()) {
if (response.isSuccessful()) {
} else {
log.error("Request failed with error code: " + response);
}
} catch (IOException e) {
log.error("Send vlogs failed", e);
throw e;
}
});
logProducer = new LogProducer(producerConfig);
考慮到這個庫只是對阿里雲日誌服務的一個元件，加上程式碼已經很久沒維護了，所以就沒有將這部分程式碼提交到社群，感興趣的評論區留言。
日誌安全
日誌是一個非常基礎但又很敏感的功能，首先是編碼規範上要避免列印一些敏感資訊；比如身份證、密碼等；同時對日誌的訪問也要最好許可權控制。
在我們內部的研效平臺中，對於日誌、監控等功能都是和應用許可權掛鉤的。
簡單來說就是關閉了統一查詢 ES 的入口，只在應用層級提供查詢，類似於：
圖來自於 orbit 產品。
OpenTelemetry
當然講到日誌目前自然也逃不過 OpenTelemetry，作為當前雲原生可觀測性的標準也提供了對應的日誌元件。
OpenTelemetry 也定義了結構化的日誌格式：
{"resourceLogs":[{"resource":{"attributes":[{"key":"resource-attr","value":{"stringValue":"resource-attr-val-1"}}]},"scopeLogs":[{"scope":{},"logRecords":[{"timeUnixNano":"1581452773000000789","severityNumber":9,"severityText":"Info""body":{"stringValue":"This is a log message"},"attributes":[{"key":"app","value":{"stringValue":"server"}},{"key":"instance_num","value":{"intValue":"1"}}],"droppedAttributesCount":1,"traceId":"08040201000000000000000000000000","spanId":"0102040800000000"},{"timeUnixNano":"1581452773000000789","severityNumber":9,"severityText":"Info","body":{"stringValue":"something happened"},"attributes":[{"key":"customer","value":{"stringValue":"acme"}},{"key":"env","value":{"stringValue":"dev"}}],"droppedAttributesCount":1,"traceId":"","spanId":""}]}]}]}
我們可以配置 otel.logs.exporter=otlp (default) 可以將日誌輸出到 oetl-collector 中，再由他輸出到後端儲存中。
雖然這樣 otel-collectoer 就成為瓶頸了，但我們也可以部署多個副本來降低壓力。
同時也可以在應用中指定不同的 endpoint(otel.exporter.otlp.endpoint=http://127.0.0.1:4317) 來區分日誌的 collector，與其他型別的 collector 做到資源隔離。
不過目前社群關於日誌的實踐還比較少，而且由於版本 1.0 版本 release 的時間也不算長，穩定性和之前的 filebeat 相比還得需要時間檢驗。
總結
理想情況下，我們需要將可觀測性的三個重要元件都關聯起來才能更好的排查定位問題。
比如當收到監控系統透過指標變化發出的報警時，可以透過鏈路追蹤定位具體是哪個系統觸發的問題。
之後透過 traceID 定位到具體的日誌，再透過日誌的上下文列出更多日誌資訊，這樣整個鏈條就可以串聯起來，可以極大的提高效率。
參考連結：
- https://github.com/aliyun/aliyun-log-java-producer
- https://kubernetes.io/docs/concepts/cluster-administration/logging/
- https://coding.net/help/docs/orbit/env/logs-event/intro.html
- https://opentelemetry.io/docs/concepts/signals/logs/