大家都知道istio可以幫助我們實現灰度釋出、流量監控、流量治理等功能。每一個功能都幫助我們在不同場景中實現不同的業務。那Istio是如何幫助我們實現監控和日誌採集的呢？
這裡我們依然以Bookinfo應用程式作為貫穿此任務的示例程式。首先在叢集中安裝並部署Istio。
1 收集遙測資料
建立一個新的YAML檔案，用來儲存Istio將自動生成和收集的新度量標準和日誌流的配置。如下圖所示：
通過命令$ kubectl apply -f new_telemetry.yaml推送剛剛配置的YAML檔案。然後去請求應用程式來生成流量，例如在本用例中就可以訪問Bookinfo完成訪問。
接下來我們就可以驗證是否採集到了剛剛的請求資料。在Kubernetes環境中，通過執行以下命令為Prometheus設定埠轉發：
$ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath='{.items[0].metadata.name}') 9090:9090 &
通過Prometheus UI檢視新指標的值。執行對istio_double_request_count度量值的查詢。Console選項卡中顯示的表 包含類似於以下內容的條目：
驗證是否已建立日誌流並正在為請求填充日誌流。在Kubernetes環境中，搜尋istio-telemetry pod的日誌，如下所示：
從列印的資訊中，我們可以清楚的看到日誌級別、生成時間、例項名稱、訪問元件名稱等等資訊。
2 遙測配置
在上面的實踐中，我們已經完成了Istio收集資料並列印日誌的一個過程。
那麼Istio是如何做到的呢？其實我們已經給Istio做了配置，指示Mixer自動生成並上報服務網格中採集的metric資訊和日誌流。在這個配置中我們主要設定了mixer的三個功能：
-
從Istio的屬性中生成例項資訊，比如在我們上面的實踐中列印的metric和日誌資訊。
-
建立出adapter介面卡，可以幫助我們處理生成的例項。
-
根據定義的規則向adapter傳送例項資訊。
3 metrics配置
配置metrics是為了指示Mixer將metric傳送到Prometheus。它使用三個模組來進行配置：例項配置、處理程式配置和規則配置。
metric配置的模組定義了用於生成metric。此例項配置根據Envoy報告的屬性（由Mixer自身生成）告訴Mixer 如何為任何給定請求生成metric。
dimensions為每個例項指定一組維度。提供了根據查詢的不同需求和方向對metric據進行分片，聚合和分析的方法。例如，可能需要在對應用程式行為進行故障排除時僅考慮對特定目標服務的請求。
4 日誌配置
日誌配置指示Mixer將日誌條目傳送到stdout。它同樣使用三個模組來進行配置：例項配置，處理程式 配置和規則配置。
logentry配置的部分定義了用於生成日誌條目例項。此例項配置告訴Mixer 如何 根據Envoy報告的屬性為請求生成日誌條目。
severity引數用於指示任何生成的日誌級別 logentry。在此示例中，使用了引數值"warning"。此值將由logentry 處理程式對映到支援的日誌記錄級別。
Timestamp引數提供所有日誌條目的時間資訊。在此示例中，時間request.time由Envoy 提供的屬性值提供。
variables引數允許操作員配置每個值中應包含的值logentry。一組表示式控制從Istio屬性和文字值到構成a的值的對映logentry。在此示例中，每個logentry例項都有一個名為latency使用屬性值填充的欄位response.duration。如果沒有已知值response.duration，則該latency欄位將設定為持續時間 0ms。
stdio配置定義了處理程式命名newhandler。處理程式spec配置stdio介面卡程式碼處理接收 logentry例項的方式。該severity_levels引數控制欄位的logentry 值如何severity對映到支援的日誌記錄級別。這裡，值"warning"被對映到WARNING日誌級別。該 outputAsJson引數指示介面卡生成JSON格式的日誌行。
rule配置定義一個新的規則命名newlogstdio。該規則指示Mixer將所有newlog.logentry例項傳送到 newhandler.stdio處理程式。由於match引數設定為true，因此將對網格中的所有請求執行規則。