作者:iyacontrol
出處:https://zhuanlan.zhihu.com/p/269398999
Istio為網格內的所有服務通信生成詳細的遙測。這種遙測功能提供了服務行為的可觀察性，使運維同學可以對應用程序進行故障排除，維護和優化，而不會給服務開發人員帶來任何額外負擔。通過Istio，可以全面瞭解受監控的服務如何與其他服務以及與Istio組件本身進行交互。
Istio生成以下遙測類型，以提供整體服務網格可觀察性：
Metrics
. Istio根據監控的四個“黃金信號”(延遲，流量，錯誤和飽和度)生成一組服務指標。 Istio還提供了網格控制平面的詳細指標。還提供了基於這些指標構建的一組默認的網格監控儀表板。
Distributed Traces
. Istio為每種服務生成分佈式跟蹤範圍，從而使我們可以詳細瞭解網格中的調用流程和服務依賴性。
Access Logs
. 當流量流入網格內的服務時，Istio可以生成每個請求的完整記錄，包括源和目標元數據。該信息使我們能夠審核服務行為，可以到單個工作負載實例級別。
本文我們主要講述logs。
Logs 簡介
為什麼我們需要logs？
這裡講到的log，只包含代理Envoy的訪問日誌，不包含業務本身日誌。
Envoy的訪問日誌包含了豐富的流量信息，如下：
Start time -- 請求開始時間
Method -- 請求使用方法
Protocol -- HTTP/1.1或HTTP/2。如果協議為TCP，則值為-
Response Code -- HTTP響應代碼。如果請求是TCP請求，則值為-
Response Flags -- 如果超出標準響應代碼，該字段提供了有關響應或連接的更多詳細信息。 HTTP和TCP請求的可能值包括
UH
(沒有健康的上游主機)；UF
(上游連接失敗)；UO
(上游溢出)；NR
(未配置路由)；URX
(由於上游重試限制或達到最大連接嘗試而被拒絕)Bytes Received / Bytes Sent -- body接收或發送的字節。對於WebSocket連接，發送的字節將包括響應頭字節
Response Duration -- 從開始時間到從上游主機讀取到第一個字節的請求的總持續時間(以毫秒為單位)
Upstream Service Time -- 上游主機處理請求所花費的時間(以毫秒為單位)。如果要將服務時間與網絡延遲進行比較，這很有用。
X-Forwarded-For
User-Agent -- 該字符串允許服務器標識軟件請求代理的特定類型
Request ID -- Envoy使用x-request-id標頭唯一標識每個請求。這對於跨多個微服務的分佈式跟蹤和穩定的訪問日誌記錄尤其重要
Authority --
Host
(HTTP/1.1)或Authority
(HTTP/2) header的值
此外還包括 流量五元組信息 ,通過五元組信息，我們可以清楚知道流量從哪裡來，到哪裡去。
UPSTREAM_CLUSTER
DOWNSTREAM_REMOTE_ADDRESS
DOWNSTREAM_LOCAL_ADDRESS
UPSTREAM_LOCAL_ADDRESS
UPSTREAM_HOST
在使用istio的過程中，由於引入了代理，整個訪問鏈路更長了，會使一些問題的排查變得複雜。比如當請求返回503等狀態碼的時候，我們無法確定是服務本身返回，還是代理返回。而envoy 用access log 記錄流量信息，我們可以基於訪問日誌進行更細粒度的故障定位。
配置
Istio中對於accesslog的設置，主要通過以下配置項完成：
meshConfig.accessLogFile
-- 如果設置為/dev/stdout
，表示開啟accesslog功能。以標準輸出的形式打印日誌，該日誌我們可以使用kuebctl logs ...
查看具體日誌，本質上這些日誌由docker收集，並存儲到主機的指定位置。如果想禁用accesslog，則設置該項值為""。meshConfig.accessLogEncoding
-- 設置為JSON
或TEXT
選擇訪問日誌的輸出格式。-
meshConfig.accessLogFormat
-- 此項允許用戶通過實際需要自定義訪問日誌的格式。
實戰
在生產環境中，我們使用filebeat + kafka + es + clickhouse + kibana+ superset的組合。具體架構如下：
採集端
採集端選型輕量級日誌收集組件filebeat，通過其Autodiscover功能，可以實現只收集指定容器的日誌，並且具備靈活性。
當我們的應用在容器上運行時，容器的彈性決定了傳統的基於配置文件的發現收集目標的方式不再適用。自動發現可以跟蹤它們並在發生更改時調整設置。通過定義配置模板，自動發現子系統可以在服務開始運行時對其進行監視。
我們選擇kubernetes autodiscovery，具體在filebeat配置增加如下設置：
<code>filebeat.autodiscover:
providers:
- type: kubernetes
templates:
- condition:
equals:
kubernetes.container.image: "docker.io/istio/proxyv2:1.7.3"
config:
- module: envoy
log:
input:
type: container
paths:
- /var/log/containers/*-${data.kubernetes.container.id}.log/<code>通過condition條件匹配，我們只採集了istio數據平面envoy的訪問日誌。
Kafka
由於我們的日誌量比較大，所以引入了kafka。避免在高峰期由於寫入壓力太大，導致數據丟失。
ES + Kibana
將日誌寫到es中，是為了短期debug的時候，方便從海量日誌中搜索關鍵信息，出於成本的考慮，es只保留最近3天的日誌。
Clickhouse + superset
中期來看，我們會將原始日誌進行聚合，然後將聚合後的數據存儲到clickhouse中，並在superset中展示。這些聚合的結果，通過不同的維度反應了各個服務的流量信息。
實際我們的聚合後展示效果如下：
對於訪問日誌的分析展示，其實通過另外一個維度補強了基於metrcis的監控。
其實我們依舊保留了一份完整的原始日誌，存放到雲上的對象存儲中，主要為了長期存儲，便於業務在出問題的時候進行故障回溯。目前離線分析方案，使用了presto。離線分析這塊，也是我們後續發力的地方。
作者:iyacontrol
出處:https://zhuanlan.zhihu.com/p/269398999
