Istioはオープンソースサービスメッシュであり、開発者やオペレーターが分散マイクロサービスの環境でサービスをまとめて正常に制御、保護、接続するために使用できます。Istioはチーム向けの強力なツールですが、管理者にとっては正常性を完全に把握することも重要です。このブログ投稿では、Elasticオブザーバビリティを使用したIstioとマイクロサービスの監視について説明します。
Istioドキュメントでは、次のように説明されています。
Istioを使用すると、ロードバランシング、サービス間認証、監視などを使用して、デプロイされたサービスのネットワークを簡単に作成できます。サービスコードのコード変更はほとんどまたはまったく必要ありません。Istioサポートをサービスに追加するには、環境全体に特殊なサイドカープロキシをデプロイします。このプロキシは、マイクロサービス間のすべてのネットワーク通信を傍受し、次のようなコントロールプレーン機能を使用して、Istioを構成および管理します。
- HTTP、gRPC、WebSocket、TCPトラフィックの自動ロードバランシング。
- 豊富なルーティングルール、再試行、フェイルオーバー、フォールトインジェクションを使用した、詳細な粒度のトラフィック動作の制御。
- アクセス制御、レート制限、クォータをサポートする、接続・切断可能なポリシーレイヤーおよび構成API。
- クラスター入出力を含むクラスター内のすべてのトラフィックの自動メトリック、ログ、トレース。
- 強力なIDに基づく認証と許可を使用したクラスターでのサービス間通信の保護。
バージョン1.5より前のIstioはマイクロサービスアーキテクチャで構築され、コントロールプレーンと管理コンポーネントは次の複数のマイクロサービスから構成されていました。Pilot、Mixer、Galley、Citadel。
Metricbeatはこれらのマイクロサービスの監視をサポートしていましたが、バージョン1.5ではIstioのアーキテクチャがモノリシックアプローチに変更され、コントロールプレーンのアプリケーションが1つになりました。このアプリケーションはistiodです。Pilot、Galley、Citadelはistiodの一部になりましたが、Envoyプロキシからトラフィックメトリックを収集するMixerの機能は直接Istioプロキシで提供されます。Istioの現在のアーキテクチャは次のようになります。
Elasticで監視ソリューションを構築する
1.5より前のバージョンは、すでにIstio Metricbeatモジュールの複数のmetricsetでサポートされていましたが、このブログでは、KubernetesでIstioを実行する場合の新しいバージョンのサポートについて重点的に説明します。
コントロールプレーンメトリック
上記のIstioアーキテクチャの図のように、コントロールプレーンメトリックを収集できるリソースは1つのみです。Istiodは、Prometheusメトリックを収集できるPrometheusエクスポーターを提供します。
Prometheusエンドポイントからメトリックを使用するには、これらのメトリックを正常に収集し、フィルタリングして、保存するmetricsetが必要です。これを簡単に実現するには、Prometheusモジュールに基づいて軽量metricsetを作成し、メトリックフィルタリングなどの強力なオプションを活用して、ヒストグラムとタイプを使用します。
この新しい軽量metricsetの定義を確認しましょう。
input:
module: prometheus
metricset: collector
defaults:
metrics_path: /metrics
metrics_filters:
include: ["citadel_*", "galley_*", "pilot_*"]
exclude: ["^up$"]
use_types: true
rate_counters: true
これは、コレクターmetricsetがメトリックを取得し、不要なメトリックを除外するパスを定義します。また、レートとタイプを有効にし、データが正常にElasticsearchに保存され、データを最大限に活用できるようにします。
KubernetesクラスターでMetricbeatをデプロイするときにこのmetricsetを構成する方法は次のようになります。
- module: istio metricsets: ['istiod'] period:10s hosts: ['istiod.istio-system:15014']
istiodはIstiod Podを公開するKubernetesサービスの名前です。istio-systemはデプロイされる名前空間です。
以上です。すでに、istiodからメトリックを収集するためのistiod metricsetがあります。これは既製のダッシュボードにも付属していて、サービスメッシュのコントロールプレーンの概要と、独自のカスタムダッシュボードで使用できる複数のビジュアライゼーションを提供します。
データプレーンメトリック
istiod metricsetを使用してコントロールプレーンからメトリックを収集しているため、データプレーンからメトリックを収集して、監視を拡大できます。これにより、Istioで管理されるサービス間のトラフィックの概要をしっかりと把握できます。
前述のように、Mixerはこれらのデータプレーンメトリックを収集して提供するマイクロサービスでした。しかし、バージョン1.5以降では、これらのメトリックは、Prometheusエクスポーターを使用して、直接Istioから収集および公開されます。
必要な手順は、istiodのときのように別の軽量metricsetを指定し、次の追加のメトリックを収集するだけです。
input:
module: prometheus
metricset: collector
defaults:
metrics_path: /stats/prometheus
metrics_filters:
include: ["istio_*"]
exclude: ["^up$"]
use_types: true
rate_counters: true
前の手順と同じように、metrics_pathを設定し、必要なメトリックのみを保持し、タイプを使用して保存します。
不足している情報が1つあります。IPアドレスがわからないため、これらのプロキシコンテナーと通信する方法がわかりません。Metricbeatをデプロイする前にこれらのコンテナーのIPがわかっていたとしても、Metricbeatが起動した後にデプロイされるサービスからデータを収集することはできません。これらのコンテナーを自動的に特定し、起動するときにメトリックの収集を開始する方法が必要です。これは、Metricbeatのautodiscover機能に最適なジョブです。つまり、これらのコンテナーを特定するautodiscover条件を定義します。新しいIstio-proxyサイドカーコンテナーが特定されるたびに、Metricbeatが自動的にプロキシmetricsetを有効にし、そこからデータを取得し始めます。
次に、このautodiscover構成の例を示します。
metricbeat.autodiscover:
providers:
- type: kubernetes
node: ${NODE_NAME}
templates:
- condition:
contains:
kubernetes.annotations.prometheus.io/path: "/stats/prometheus"
config:
- module: istio
metricsets: ["proxy"]
hosts: "${data.host}:15090"
これで完了です。クラスターで実行中のすべてのIstioサイドカーコンテナーからメトリックを収集しています。そして、その場で新しいメトリックを特定できます。これはIstioモジュールのプロキシmetricsetであり、既製のダッシュボードにも付属しています。
また、KibanaでGraph分析を利用して、データとサービスの間の相関関係を探ることもできます。たとえば、次のグラフでは、サービスがどのように相互に接続し、HTTPステータスコードにどの程度強く関連付けられているかに関する概要を確認できます。500ステータスコードの強力な関係をもつサービスは、問題があり、調査すべきであることを示します。
現在のIstioの監視
Istioサービスメッシュを監視し始める場合は、Metricbeat 7.11をダウンロードし、ElasticsearchとKibanaを使用して効率的にメッシュの調査を開始します。クラスターをデプロイするための最速の方法は、Elasticsearch Serviceの無料試用版を導入することです。ご質問がある場合は、いつでもディスカッションフォーラムでサポートいたします。