© Hitachi, Ltd. 2021. All rights reserved. Istioを活用したObservability基盤の構築と運用 CloudNative Days Spring 2021 Online 株式会社 日立製作所 研究開発グループ 井出 貴也

© Hitachi, Ltd. 2021. All rights reserved. はじめに ◇ SLI、SLOの決め方 ◇ アラート設計、インシデント管理 ◇ 監視結果に基づく運用の改善 1 Istioと監視系OSSを組み合わせ、アプリから透過的に サービスレベルを監視する基盤を構築した際の知見の共有 ◇ Observabilityとは何か ◇ IstioのObservability機能 ◇ Istioと監視系OSSの連携のTips セッションテーマ 話すこと 話さないこと

© Hitachi, Ltd. 2021. All rights reserved. 目次 2 1. 背景 2. IstioのObservability機能調査 3. Istioと監視系OSSの連携 4. 構築や運用を通したTips 5. まとめ

© Hitachi, Ltd. 2021. All rights reserved. 1. 背景 3

© Hitachi, Ltd. 2021. All rights reserved. What is Observability ? ※1 4 Testing Debugging Observability Monitoring 状態 実現手段 Observability Tracing Logging Metrics Profiling Test Events Analyzing Chaos Eng. Simulating etc. ※1. ソフトウェア分野では合意された定義が存在しない。あくまで発表者が理解した定義。元々は制御理論の用語 ▪ 対象システムへの任意の質問に手持ちのデータや知識でどれだけ答えられるか ▪ Observabilityの実現手段が監視やテスト。システムの内部状態を明らかにする システムが出力したデータを活用し、システム内部で何が・何故起きているか理解できる状態

© Hitachi, Ltd. 2021. All rights reserved. Why Observability ? 未知の現象への対応 5 ▪ 曖昧で変化の早いビジネス環境に合わせ、素早くかつ探索的にシステムを成長させる ◇ 複数チーム開発を可能にする分散システム ◇ 頻繁なコードの更新 ◇ 動的なスケーリング ◇ etc. → 「絶えずその挙動を変化させる、複雑な相互作用を持ったコンポーネント群」の運用 ▪ 何が起こるか想定しきれない ▪ この中にあって意思決定ができるよう、未知の現象に気付き、理解するに足るだけの データを収集・分析する体制を整える → Observability

© Hitachi, Ltd. 2021. All rights reserved. サービスレベルの監視 ▪ サービスレベル：サービス品質の指標になりうる監視データ。リクエスト応答時間やエラー率など※1 ▪ サービスレベルの監視はシステム監視では検知できないサービス品質劣化を検知できうる ▪ ただし、サービスレベル監視データはプラットフォーム側では取得できないことも多い ◇ 実際、Kubernetes単体では取得できず、アプリ側での対応が必要※2 6 運用者 ユーザ 応答が遅い Kubernetes ・ CPU使用率正常 ・ エラーログなし →問題に気付けず アプリ 応答時間 情報 ※1 書籍「Site Reliability Engineering」にて応答時間やエラー率はゴールデンシグナルと扱われる ※2 ブラックボックス監視はアプリによらず可能だが、ホワイトボックス監視に比べ情報量が落ちるほか副作用の恐れあり システム監視 サービスレベル監視 運用者 応答時間の 問題に気付く !! 監視 監視 シングルスレッド で動作 ?? アクセス

© Hitachi, Ltd. 2021. All rights reserved. サービスレベルの監視 ▪ サービスレベル：サービス品質の指標になりうる監視データ。リクエスト応答時間やエラー率など※1 ▪ サービスレベルの監視はシステム監視では検知できないサービス品質劣化を検知できうる ▪ ただし、サービスレベル監視データはプラットフォーム側では取得できないことも多い ◇ 実際、Kubernetes単体では取得できず、アプリ側での対応が必要 7 運用者 ユーザ 応答が遅い Kubernetes ・ CPU使用率正常 ・ エラーログなし →問題に気付けず アプリ 応答時間 情報 システム監視 サービスレベル監視 運用者 応答時間の 問題に気付く !! 監視 監視 シングルスレッド で動作 ?? アクセス ※1 書籍「Site Reliability Engineering」にて応答時間やエラー率はゴールデンシグナルと扱われる ※2 ブラックボックス監視はアプリによらず可能だが、ホワイトボックス監視に比べ情報量が落ちるほか副作用の恐れあり

© Hitachi, Ltd. 2021. All rights reserved. ※1 書籍「Site Reliability Engineering」にて応答時間やエラー率はゴールデンシグナルと扱われる ※2 ブラックボックス監視はアプリによらず可能だが、ホワイトボックス監視に比べ情報量が落ちるほか副作用の恐れあり サービスレベルの監視 ▪ サービスレベル：サービス品質の指標になりうる監視データ。リクエスト応答時間やエラー率など※1 ▪ サービスレベルの監視はシステム監視では検知できないサービス品質劣化を検知できうる ▪ ただし、サービスレベル監視データはプラットフォーム側では取得できないことも多い ◇ 実際、Kubernetes単体では取得できず、アプリ側での対応が必要※2 8 運用者 ユーザ 応答が遅い Kubernetes ・ CPU消費正常 ・ エラーログなし →問題に気付けず アプリ 応答時間 メトリクス システム監視 サービスレベル監視 運用者 応答時間の 問題に気付く !! 監視 監視 シングルスレッド で動作 ?? アクセス アプリ側での対応が必要 ✓ 無数に稼働しているアプリ全てがサービスレベルの 監視に対応できるとは限らない ✓ 対応できたとしても仕様がバラバラの可能性 ✓ 他社製品を利用していると改修も困難 どうすれば良いのか？

© Hitachi, Ltd. 2021. All rights reserved. 9 I s t i o

© Hitachi, Ltd. 2021. All rights reserved. Istioによるサービスレベルの取得 ▪ Istioは各アプリの前段にプロキシを配置し、アプリ間の通信を中継・制御するソフトウェア ▪ 中継する際の通信情報からサービスレベルの情報を収集 ▪ HTTPで通信を行うアプリは、その仕様に依らずサービスレベルの監視が可能 10 ▪ スループット ▪ 応答時間 ▪ エラー率 ▪ アクセスログ ▪ トレーシング ▪ etc. … Kubernetes アプリ 監視ツール (Prometheus等) アプリ Istio-proxy Istio-proxy レスポンス リクエスト レス時刻 – リク時刻 → 応答時間

© Hitachi, Ltd. 2021. All rights reserved. 監視系 OSS IstioのObservability対応 ▪ 監視系OSSのバンドル機能があったが、2020/12月リリースのv1.8から廃止※1 ◇ 理由：各監視系OSSの十全な機能を提供できないため ◇ 公式のドキュメントやサンプルに基づき、ユーザが自前で連携を行う → 連携のプラクティスを貯める必要はあるものの、高い自由度で連携可能 11 ※1 “Reworking our Addon Integrations” https://istio.io/latest/blog/2020/addon-rework/ Istio Istio 監視系 OSS バンドル 自由に 連携 Before After

© Hitachi, Ltd. 2021. All rights reserved. Istioを用いたObservability基盤の実践 ▪ 連携にあたってのプラクティスや注意点を洗い出す。 サンプル実装に縛られず、自前でIstioと各種監視系OSSを連携させる ▪ 監視系OSSの機能を十全に活かす。Operatorなども積極的に活用し、 本番環境にも通用しうる運用性・管理性をもたせる ◇ ただし、データ永続化やmTLSは時間都合により断念 ▪ 対象はObservability3本柱であるメトリクス、トレーシング、ロギング ◇ 活用機会や対応するOSSの多さを考慮 12

© Hitachi, Ltd. 2021. All rights reserved. 2. IstioのObservability機能調査 13

© Hitachi, Ltd. 2021. All rights reserved. Istioで取得可能なデータの抜粋 ▪ Istio公式サイトの情報を整理し、 取得できるデータのマップを作成 ▪ HTTPにはサービスレベルの値を含む 重要なメトリクスが多い ▪ TCPは情報が限られる 14 ※1 データ量が膨大になる懸念あり。カスタムメトリクスとして適宜フィルタして取得する ※2 istiod: Istio-proxyに制御命令を送付するコントローラ。 メトリクス サービスレベル プロキシレベル HTTP トレーシング ロギング TCP istio-proxy istiod 秒間リクエスト数 リクエスト 応答時間 リクエスト エラー率 データサイズ コネクション数 プロキシ内部統計※1(リトライ回数など) istiodの状態※2 トレーシングデータ アクセスログ

© Hitachi, Ltd. 2021. All rights reserved. Observability基盤の取得対象 ▪ プロキシ内部統計情報以外を取得 ▪ プロキシ内部統計情報は粒度が細かく、量が多い 15 ※1 データ量が膨大になる懸念あり。カスタムメトリクスとして適宜フィルタして取得する ※2 istiod: Istio-proxyに制御命令を送付するコントローラ。 メトリクス サービスレベル プロキシレベル HTTP トレーシング ロギング TCP istio-proxy istiod 秒間リクエスト数 リクエスト 応答時間 リクエスト エラー率 データサイズ コネクション数 プロキシ内部統計※1(リトライ回数など) istiodの状態※2 トレーシングデータ アクセスログ

© Hitachi, Ltd. 2021. All rights reserved. Istioと連携可能な監視系OSSの整理 ▪ Istioが連携可能な監視系OSSを関係性含め可視化 ▪ Grafanaと連携可能なソフトウェアが多い 16 ダッシュボード有り ロギング メトリクス トレーシング ダッシュボード Istio Logstash fluentbit Promtail Elastic search Grafana Loki Kibana Prome theus Jaeger Zipkin Open Sensus Kiali Istio-proxy Istiod Grafana Grafana Tempo トレーシングはDataDogとLightstepとStackDriver にも対応。OSSではないため省略

© Hitachi, Ltd. 2021. All rights reserved. Observability基盤に用いるOSSの選定 ▪ Grafanaをメインのダッシュボードとし、Grafana連携に強みのあるOSSを選定 17 ダッシュボード有り ロギング メトリクス トレーシング ダッシュボード Istio Logstash fluentbit Promtail Elastic search Grafana Loki Kibana Prome theus Jaeger Zipkin Open Sensus Kiali Istio-proxy Istiod Grafana Grafana Tempo トレーシングはDataDogとLightstepとStackDriver にも対応。OSSではないため省略

© Hitachi, Ltd. 2021. All rights reserved. K8s metrics Observability基盤の設計 18 Prometheus Operator Jaeger Operator Kiali Operator Grafana Jaeger Kiali Prometheus Sample App(Bookinfo) Loki front app1 db app2 Istio-pxy Istio-pxy Istio-pxy Istio-pxy Access log Container log Traffic metrics Logs Metrics Logs istiod Traffic metrics Istio Operator Operator Lifecycle Manager Kubernetes Deploy manifests 運用者 Browse dashboards 監視系 Istio Operator 情報の流れ ダッシュボード App Grafana Operator Promtail Tracing Data Tracing Data Tracing Data

© Hitachi, Ltd. 2021. All rights reserved. 3. 監視系OSSとIstioの連携 19

© Hitachi, Ltd. 2021. All rights reserved. 解説の流れ 20 監視系 Istio Operator 情報の流れ ダッシュボード App K8s metrics Prometheus Operator Jaeger Operator Kiali Operator Grafana Jaeger Kiali Prometheus Sample App(Bookinfo) Loki front app1 db app2 Istio-pxy Istio-pxy Istio-pxy Istio-pxy Access log Container log Traffic metrics Logs Metrics Logs istiod Traffic metrics Istio Operator Operator Lifecycle Manager Kubernetes Deploy manifests 運用者 Browse dashboards Grafana Operator Promtail Tracing Data Tracing Data Tracing Data Loki・ Promtail p.23 Grafana p.25 Jaeger p.24 Prometheus p.21 構築中のため説明は省略

© Hitachi, Ltd. 2021. All rights reserved. Prometheus との連携 1/2 ▪ Prometheusの構成は共有・連携※1のどちらにするか ◇ 運用負荷削減のため、共有構成を採用 21 連携構成 共有構成 Istio Prometheus Production Prometheus Production Prometheus 連携, データ集約 データ収集 データ収集 利点 ▪ 集約による負荷の削減 ▪ 責任分界点の明確化 ▪ 障害影響の局所化 ▪ 公式の推奨方法※2 ---- 懸念点 ▪ 構成複雑化 ▪ 管理負荷の増加 ▪ リソース消費増加 利点 ▪ 構成の単純化 ▪ 管理工数削減 ▪ リソース消費削減 ---- 懸念点 ▪ Prod Prometheus への負荷集中 ▪ 責任分界点の判断 ▪ 障害の伝播 ※1 名称は独自のもの ※2 Observability Best Practices https://istio.io/latest/docs/ops/best-practices/observability/#using-prometheus-for-production-scale-monitoring

© Hitachi, Ltd. 2021. All rights reserved. Prometheus との連携 2/2 ▪ kube-prometheusをベースにPrometheusを構築して省力化 ◇ Prometheus-Operatorコミュニティが提供する監視系ツールのパッケージ ◇ 設定済みPrometheusやGrafana、Alert Managerを構築できる ▪ 以下2種のデータの取得設定をPrometheusに投入する。 Prometheus Operatorを用いると管理しやすい ◇ Istio-proxy：PodMonitorにて設定 ◇ istiod：ServiceMonitorにて設定 ◇ 注意：spec.namespaceSeletor.any = true とすると動作せず。環境依存か 22

© Hitachi, Ltd. 2021. All rights reserved. Loki・Promtail との連携 ▪ LokiやPromtailにはOperatorが存在しないため、 HelmやTanka(推奨)にてデプロイ ◇ 今回はHelmを使用し、問題なく動作 ▪ Istioは初期状態だとアクセスログを出力しないため、 Istioデプロイ時の設定要 ◇ Istio Operatorを用いる場合、 spec.meshConfig.accessLogFile を設定する ◇ Jaeger用設定も含め、本基盤のIstioは 右の設定のみで一通りの動作が可能 # Observability基盤のIstio設定 apiVersion: install.istio.io/v1alpha1 kind: IstioOperator metadata: namespace: istio-system name: istio spec: profile: default meshConfig: accessLogFile: /dev/stdout enableTracing: true defaultConfig: tracing: sampling: 1 zipkin: address: :9411 Jaeger設定 Loki設定 23

© Hitachi, Ltd. 2021. All rights reserved. Jaegerとの連携 ▪ JaegerはOperatorを用いて、容易に本体をデプロイ可能 ▪ Istioとの連携方法 ◇ Istioデプロイ時の設定でトレーシングデータの送付先を指定 ◇ サンプリングレートも設定可能※1 。初期状態は1% ◇ トレーシング設定を反映するにはIstio-proxyの再起動が必要 ▪ なお、Isio連携以外にアプリ側でトレースIDの伝播を行う必要あり※2 ◇ Istio-proxyではリクエストの対応関係を判断できないため ◇ トレーススパン生成やJaegerへのデータ送付はIstio-proxyが実施 24 ※2 Trace-Context Propagation ↓ https://istio.io/latest/docs/tasks/observability/distributed-tracing/overview/#trace-context-propagation ※1 Podの proxy.istio.io/config アノテーションでも指定可能。Pod単位で異なる値を設定できる

© Hitachi, Ltd. 2021. All rights reserved. Grafana との連携 ▪ Grafanaは前述のkube-prometheusでも導入できるが、 Grafana Operatorが有用であるため、Operator経由で導入すると良い ◇ 一方、kube-prometheusはダッシュボード群が作り込まれている。適宜移植する ▪ 各監視ツールとの連携 ◇ GrafanaDataSourceリソースにてPromtheus、Loki、Jaegerと連携 ◇ GrafanaDashboardリソースにてIstio公式ダッシュボード追加（5+1種）※1、2 ▪ GrafanaDashboardはPluginの取得やDataSource連携を宣言的に指定できる ◇ GUIからの直接編集はGrafanaコンテナの再起動で消えるため注意 25 ※1 https://istio.io/latest/docs/ops/integrations/grafana/ … 公式に提示されている5種のダッシュボード ※2 https://grafana.com/grafana/dashboards/13277 ... GrafanaサイトのIstioリポジトリにはWASM用のダッシュボードも存在

© Hitachi, Ltd. 2021. All rights reserved. Observability環境の稼働 ▪ Observability基盤を稼働させ、実際にリクエストの応答時間やエラー率など、 サービスレベルに関するデータを取得できることを確認 ▪ 多少の試行錯誤は必要だったものの、Istioや監視系OSSの公式Docsで情報が完結 26 メトリクス ロギング トレーシング スループット エラー率 応答時間

© Hitachi, Ltd. 2021. All rights reserved. 4. 構築や運用を通したTips 27

© Hitachi, Ltd. 2021. All rights reserved. 構成をシンプルに保つ Observabilityもスモールスタートに ▪ 最初はメトリクスだけで良い。最初から色々あっても使いこなせない ▪ その後、ロギング→トレーシング。 トレーシングは必要性を感じてからの導入で良い ▪ プロキシ内部統計のような細かいデータも同上。メリットと運用負荷を比較する Istioと監視系OSSの分離 ▪ システムの複雑化を避けるため、監視系OSSはIstioのメッシュ外に置く ▪ Istioの障害に監視系OSSが巻き込まれると原因分析もできない ▪ mTLS配下でも監視系OSSを分離できるかは要検証 ダッシュボードの集約 ▪ 一つのGUIでメトリクス、ロギング、トレーシングすべてに対応できるのは大きなメリット 28

© Hitachi, Ltd. 2021. All rights reserved. 構成管理 複数のOSS・Operatorを扱うと、どうしても構成は複雑化。一貫性のある管理を行う ファイルべースの宣言的な構成管理（ Single Source of Truth ） ▪ 各種構成をKubernetesマニフェストの状態でGit管理する → 再現性・操作の一貫性向上 ▪ PrometheusやGrafanaのOperatorはこの管理方法と相性が良い ▪ GrafanaのGUIの操作や、kubectl operatorなどのCLI操作で構成を変更すると ファイル管理の一貫性が崩れる。変更内容をマニフェストに反映し、状態を追えるようにする 管理方法の管理 ▪ OSSごとにHelm、Operator、OLM、CLI、GUIと管理方法が異なる ▪ マニフェストの作成方法をスクリプトやドキュメントで管理要 29

© Hitachi, Ltd. 2021. All rights reserved. Istio導入の検討 ▪ Istioは大きなシステム。簡単に抜き差しできるものではない ▪ 利点が懸念点を上回るか、自分にユースケース※1 は当てはまるか、 30 ▪ アプリ改修なしに、システム全体へ 一貫性のあるポリシーを適用 ▪ 多くの機能、高い品質 ◇ サービスレベル監視 ◇ 動的な通信制御 ◇ 通信暗号化や認証認可 ◇ VM連携 ▪ 活発な開発、etc. ▪ Service Meshレイヤー追加 によるシステム複雑化 ▪ 多数の機能に対する学習コスト ▪ Istio本体の管理コスト ▪ 消費リソースの増加 ▪ 2-10msの通信遅延 ▪ Kubernetesへのロックイン ▪ 3~6ヶ月単位のアップデート、etc. ※1 便利なユースケース集 ▪ Megan O’Keefe, “Istio by Example!”, https://www.istiobyexample.dev/ , 日本語版(少々古い) https://istiobyexample-ja.github.io/istiobyexample/ ▪ Istio公式ドキュメント(Tasks), https://istio.io/latest/docs/tasks/ 利点 懸念点

© Hitachi, Ltd. 2021. All rights reserved. 5. まとめ 31

© Hitachi, Ltd. 2021. All rights reserved. まとめ Observabilityとは「システムが出力したデータを活用し、 システム内部で何が・何故起きているのか理解できること」 ▪ 未知の現象に対処するため Istioと監視系OSSを組み合わせ、アプリから透過的に サービスレベルを監視する基盤を構築 ▪ Prometheus、Jaeger、Loki、Grafana を連携 構築および運用から得た知見 ▪ 構成をシンプルに保つこと、構成管理を行うこと ▪ Istioは利点と懸念点の両方を鑑みて導入を判断すること 32

© Hitachi, Ltd. 2021. All rights reserved. 今後の展望 ▪ Observabilityの実践 ◇ 安定性や利便性の向上、運用を通した課題の抽出 ◇ ある程度使えるものになれば社外公開したい ▪ mTLS対応の検証 ◇ 監視データを取得する際の証明書の設定・管理方法を整理する ▪ データ永続化対応 ◇ PV適用方法の整理や、監視データのディスク消費量を検証 ▪ 環境に応じた取得メトリクスの自動調整 ◇ 次ページ 33

© Hitachi, Ltd. 2021. All rights reserved. 環境に応じた取得メトリクスの自動変換 ▪ 同じ意味のメトリクスでも、環境が変わると算出方法や取得方法が異なりうる ◇ 例. CPU使用率が一方は 100% 換算、他方は (コア数)*100% 換算 ◇ 例. クラウドだと基盤機能で取得可能なメトリクスが、オンプレだと取得できない ▪ 個々のメトリクスを抽象的にマッピングさせ、複数環境への移植性を向上させる 34 On Premise Cloud A App 基盤監視機能 App Side Car 式 構成 Cloud A $val*$cores - On Premise $val add $sidecar デプロイ 変換処理 $val * $cores $val DB CPU Usage 変換マップ メトリクス変換機 運用者 CPU使用率 800% 300% 50% CPU使用率 300% CPU使用率 vCPUx16

© Hitachi, Ltd. 2021. All rights reserved. 参考文献 ▪ John Porcaro, “Observability (re)defined”, https://www.humio.com/whats-new/blog/observability-redefined, 2019 ▪ Betsy Beyer, Chris Jones, Niall Richard Murphy, Jennifer Petoff, “Site Reliability Engineering”, O'Reilly Media, Inc., 2017 ▪ Mike Julian, 松浦 隼人, “入門 監視 ―モダンなモニタリングのためのデザインパターン”, O'Reilly Media, Inc., 2019 ▪ Cindy Sridharan, “Distributed Systems Observability”, O'Reilly Media, Inc., 2018 ▪ Charity Majors, Liz Fong-Jones, George Miranda, “Observability Engineering”, O'Reilly Media, Inc., 2022(Early Release) ▪ Cindy Sridharan, “Monitoring in the time of Cloud Native”, https://copyconstruct.medium.com/monitoring-in-the-time-of- cloud-native-c87c7a5bfa3e, 2017 ▪ “Istio”, https://istio.io/latest/, Istio Authors, 2021 ▪ Megan O’Keefe, “Istio by Example!”, https://www.istiobyexample.dev/, 2021 ▪ “kube-prometheus”, https://github.com/prometheus-operator/kube-prometheus, prometheus-operator, 2021 ▪ “grafana-operator”, https://github.com/integr8ly/grafana-operator, integr8ly, 2021 ▪ “Tempo Documentation”, https://grafana.com/docs/tempo/latest/, Grafana Labs, 2021 ▪ “jaeger-operator”, https://github.com/jaegertracing/jaeger-operator, jaegertracing, 2021 ▪ “Installation Guide”, https://kiali.io/documentation/latest/installation-guide/, Kiali, 2021 ▪ “operator-lifecycle-manager”, https://github.com/operator-framework/operator-lifecycle-manager, operator-framework, 2021 ▪ Benjamin H. Sigelman, etc., “Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”, Google Technical Report (2010) 35

© Hitachi, Ltd. 2021. All rights reserved. Trademarks ▪ Istioは、Google LLCの米国における登録商標または 商標です ▪ Envoy Proxyは、The Linux Foundationの米国また はその他の国における登録商標または商標です ▪ Kubernetesは、The Linux Foundationの米国または その他の国における登録商標または商標です ▪ Prometheusは、The Linux Foundationの米国また はその他の国における登録商標または商標です ▪ Grafanaは、Grafana Labsの米国またはその他の国に おける登録商標または商標です ▪ Grafana Lokiは、Grafana Labsの米国またはその他の 国における登録商標または商標です ▪ Jaegerは、 The Linux Foundationの米国またはその 他の国における登録商標または商標です ▪ Kialiは、 Red Hat, Inc.の米国またはその他の国におけ る登録商標または商標です ▪ Datadogは、Datadog, Inc.の米国またはその他の国 における登録商標または商標です ▪ StackDriverは、Google LLCの米国における登録商標 または商標です ▪ Dynatraceは、Dynatrace LLCの米国における登録商 標または商標です ▪ OpenTracingは、The Linux Foundationの米国また はその他の国における登録商標または商標です ▪ その他記載の会社名、製品名、サービス名、その他固 有名詞は、それぞれの会社の商標または登録商標です ▪ 本発表中の文章、図では、TM、🄬マークは表記しており ません。 36

© Hitachi, Ltd. 2021. All rights reserved. Appendix

© Hitachi, Ltd. 2021. All rights reserved. Observabilityの側面 38 ▪ Observabilityの目的は「未知の現象に対応すること」こと ▪ 目的を達成するには、データを集める以外の側面もある データから洞察を得られるようにする Data Mining、Profiling、 Dependency Analyzing 未知の現象のとり得る範囲を狭める System Design、Testing Chaos Engineering 必要なデータを得られるようにする Monitoring、Tracing、Logging システム 未知の 現象 データ 洞察 対応

© Hitachi, Ltd. 2021. All rights reserved. Istio-proxyのObservabilityデータ出力仕様 39 ▪ メトリクスはPull型、トレース情報はPush型、ログはNode経由で送付 ▪ PrometheusはIstio-proxyの宛先情報が必要、Istio-proxyはJaegerの宛先情報が必要 Node Kubernetes Cluster Promtail コンテナログ Prome theus Istio-proxy アプリ Jaeger 標準出力 Push Pull

© Hitachi, Ltd. 2021. All rights reserved. Classifying Metrics Based on Request or Response ▪ Istio-1.8で追加された機能。URLやHTTP Headerの情報を加工し、監視データに付与 ▪ 監視データの解像度を大きく向上（L4 → L7）できるため、非常に強力。 例えば、Webページ単位やユーザ別、アクセス元ブラウザごとのエラー率を算出できる ▪ Web Assembly(WASM)を用いて実装されたプラグインの公式実装としても要注目 40 Front Service 1. 属性生成プラグイン (WASM)をデプロイ Prometheus Request Response Original Info Metrics 2. 分類ルール を設定 ユーザ 3. メトリクスの 動的分類 通信 ルールに基づきメトリク スに情報を付与 4. メトリクス保存

© Hitachi, Ltd. 2021. All rights reserved. Google トレーシング規格に関わる国際動向 41 OpenTracing OpenCensus OpenTelemetry W3C Distributed Tracing WG 規格詳細化 CNCF W3C Dapper Zipkin Jaeger Google社の分散トレーシ ングシステムの設計をまと めた論文 Dynatrace 2010年 Googleの分散トレーシン グライブラリ（モニタリング もサポート） 分散トレーシング仕様の標 準化（データ細部は除く） 2016年 2019年 OpenCensus と OpenTracing の統合仕様およびライブラリ群 種々の製品/OSSが乱立 標準化 派生 統合 統合 2020年 トレーシングデータ構造の細部を OpenTelemetryベースに標準化 ベース仕様 標準化

No content