日志架構演進：從集中式到分布式的Kubernetes日志策略
當我們沒有使用云原生方案部署應用時采用的日志方案往往是 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);考慮到這個庫只是對阿里云日志服務的一個組件，加上代碼已經很久沒維護了，所以就沒有將這部分代碼提交到社區，感興趣的評論區留言。
日志安全
日志是一個非?；A但又很敏感的功能，首先是編碼規范上要避免打印一些敏感信息；比如身份證、密碼等；同時對日志的訪問也要最好權限控制。
在我們內部的研效平臺中，對于日志、監控等功能都是和應用權限掛鉤的。
簡單來說就是關閉了統一查詢 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/。
