分散監視の基礎：4つのゴールデンシグナル

ForePaaSは、しばらくの間DevOpsの実験を行ってきました。最初はチームとして、そして今では会社全体で実験を行っています。理由は単純です。組織は成長しています。以前は、すべての機会に1つのチームしかありませんでした。彼女は製品のアーキテクチャ、設計、セキュリティに携わり、あらゆる問題に迅速に対応しました。現在、私たちは専門分野によっていくつかのチームに分かれています：フロントエンド、バックエンド、開発、運用...



以前の方法はそれほど効果的ではなく、品質と悪を犠牲にすることなく速度を維持しながら何かを変更する必要があることに気付きました逆もまた同様です。



以前は、チームdevopsと呼んでいましたが、実際にはOpsを実行し、バックエンドでの開発も担当していました。週に1回、他の開発者がDevOpsチームに、本番環境にデプロイする必要のある新しいサービスを伝えました。これは時々問題を引き起こしました。一方では、DevOpsチームは開発者に何が起こっているのかを実際には理解していませんでしたが、他方では、開発者はサービスに責任を感じていませんでした。



最近、DevOpsのスタッフは、サービスコードの可用性、信頼性、品質について、開発者のこの責任を目覚めさせようとしています。まず、負荷がかかったことに驚いた開発者を安心させる必要がありました。新たな問題を診断するためにより多くの情報が必要だったため、システム監視を実装することにしました。



この記事では、モニタリングとは何か、それが何で食べられるかについて話し、いわゆる4つのゴールデンシグナルについて学び、メトリックとドリルダウンを使用して現在の問題を調査する方法について説明します。

 





サービスを監視するための4つのゴールデンシグナルを備えたGrafanaダッシュボードの例。

モニタリングとは何ですか？

監視とは、システムの状態に関する洞察を提供するメトリックの作成、収集、集約、および使用です。



システムを監視するには、そのソフトウェアとハ​​ードウェアのコンポーネントに関する情報が必要です。このような情報は、特別なプログラムまたはコードインストルメンテーションを使用して収集されたメトリックを通じて取得できます。



Instrumentationは、パフォーマンスを測定できるようにコードを変更しています。製品自体の機能に影響を与えず、単にメトリックを計算して提供するコードを追加しています。リクエストのレイテンシーを測定したいとしましょう。サービスが受信したリクエストを処理するのにかかる時間を計算するコードを追加します。



この方法で作成されたメトリックは、引き続き収集して他のメトリックと組み合わせる必要があります。これは通常されて行われて Metricbeat収集とのために Logstashに指標を割り出す Elasticsearch。次に、これらのメトリックを独自の目的に使用できます。通常、このスタックは、Elasticsearchでインデックス付けされたデータをレンダリングするKibanaによって補完され ます。

なぜ監視するのですか？

さまざまな理由でシステムを監視する必要があります。たとえば、アラートを生成してダッシュボードにデータを入力するために、システムの現在のステータスとそのバリエーションを監視します。アラートを受信すると、ダッシュボードで失敗の理由を探します。監視は、サービスの2つのバージョンを比較したり、長期的な傾向を分析したりするために使用される場合があります。

何を監視しますか？

サイト信頼性エンジニアリングには、 分散システムの監視に関する役立つ章があり、4つのゴールデンシグナルを追跡するためのGoogleのアプローチについて説明しています。

 



Beyer、B.、Jones C.、Murphy、N。＆Petoff、J。（2016）サイト信頼性エンジニアリング。Googleが本番システムを実行する方法。オライリー。無料のオンラインバージョン：https：  //landing.google.com/sre/sre-book/toc/index.html

•  — . .  — , .
  
  
•  — . API . , .
  
  
• .  (, 500- ) .  — , .
  
  
• , , . ? . . , , .
  
  

?

テクノロジースタックを例にとってみましょう。通常、カスタムソリューションではなく、一般的な標準ツールを選択します。利用可能な機能が私たちにとって十分でない場合を除いて。ほとんどのサービスをKubernetes環境にデプロイし、コードをインストルメント化して、各カスタムサービスに関するメトリックを取得します。これらのメトリックを収集してPrometheus用に準備するには、Prometheusクライアントライブラリの1つを使用し ます。ほとんどすべての一般的な言語用のクライアントライブラリがあります。ドキュメントでは、独自のライブラリを作成するために必要なすべてを見つけることができます。



サードパーティのオープンソースサービスの場合、通常、コミュニティから提案されたエクスポーターを利用します。エクスポーターは、サービスからメトリックを収集し、Prometheus用にフォーマットするコードです。これらは通常、Prometheusメトリックを生成しないサービスで使用されます。



メトリックをパイプラインに送信し、時系列としてPrometheusに保存します。さらに、Kubernetesのkube-state-metricsを使用して、 メトリックを収集してPrometheusに送信します。その後、Prometheusリクエストを使用して、Grafanaでダッシュボードとアラートを作成でき ます。ここでは技術的な詳細については説明しません。これらのツールを自分で試してみてください。彼らは詳細なドキュメントを持っています、あなたはそれを簡単に理解することができます。



たとえば、トラフィックを受信し、受信したリクエストを他のサービスを使用して処理する単純なAPIを見てみましょう。

ディレイ

レイテンシーは、リクエストの処理にかかる時間です。リクエストが成功した場合とエラーが発生した場合のレイテンシを別々に測定します。これらの統計が混同されないようにします。



通常、全体的な遅延が考慮されますが、これが常に適切な選択であるとは限りません。レイテンシーの分布は可用性の要件に沿っているため、追跡する方が適切です。特定のしきい値よりも速く処理される要求の割合は、一般的なサービスレベルインジケーター（SLI）です。このSLIのサービスレベル目標（SLO）の例を次に示します。

「24時間以内に、リクエストの99％が1秒未満で処理されるはずです。」

レイテンシメトリックを表す最も視覚的な方法は、時系列グラフを使用することです。メトリックをバケットに入れ、エクスポーターは毎分それらを収集します。このようにして、サービス待ち時間のn分位数を計算できます。



0 <n <1で、グラフにq値が含まれている場合、このグラフのn分位数は、q値のうちn * qを超えない値に等しくなります。つまり、xレコードのグラフの中央値0.5分位数は、xレコードの半分を超えない値に等しくなります。

 



APIレイテンシグラフグラフから



わかるように、ほとんどの場合、APIは1秒未満でリクエストの99％を処理します。ただし、SLOに対応しない2秒前後のピークもあります。

Prometheusを使用しているため、バケットサイズの選択には細心の注意を払う必要があります。Prometheusは、線形および指数関数的なバケットサイズを可能にします。推定誤差が考慮されている限り、どちらを選択してもかまいません 。



Prometheusは、分位数の正確な値を提供しません。分位数がどのバケットにあるかを判別し、線形補間を使用して概算値を計算します。

トラフィック

APIのトラフィックを測定するには、APIが毎秒受信するリクエストの数を数える必要があります。メトリックは1分に1回収集されるため、特定の1秒間の正確な値を取得することはできません。ただし、Prometheusのrate関数とirate関数を使用して、1秒あたりの平均リクエスト数を計算できます  。



この情報を表示するには、GrafanaSingleStatパネルを使用します。1秒あたりの現在の平均リクエスト数と傾向が表示されます。

 





APIが1秒あたりに受信するリクエスト数を示すGrafanaSingleStatパネルの例1秒



あたりのリクエスト数が突然変化すると、それが表示されます。数分でトラフィックが半分になると、問題があることがわかります。

エラー

明らかなエラーの割合を計算するのは簡単です。HTTP500応答をリクエストの総数で割ります。トラフィックと同様に、ここでは平均を使用します。



間隔はトラフィックの場合と同じである必要があります。これにより、1つのパネルでエラーのあるトラフィックを追跡しやすくなります。



過去5分間のエラー率が10％で、APIが1秒あたり200リクエストを処理しているとします。平均して、1秒あたり20回のエラーが発生したことは簡単に計算できます。

飽和

飽和状態を監視するには、サービス制限を定義する必要があります。APIの場合、どちらがより影響するかわからなかったため、プロセッサとメモリの両方のリソースを測定することから始めました。Kubernetesと kube-state-metricsは、コンテナーにこれらのメトリックを提供します。

 



API



飽和度測定のCPU使用率のグラフを使用すると、ダウンタイムを予測してリソースをスケジュールできます。たとえば、データベースストレージの場合、ディスクの空き容量とその空き容量を測定して、いつアクションを実行するかを理解できます。

分散サービスを監視するための詳細なダッシュボード

別のサービスを見てみましょう。たとえば、他のサービスのプロキシとして機能する分散API。このAPIには、異なるリージョンと複数のエンドポイントに複数のインスタンスがあります。それらのそれぞれは、独自のサービスのセットに依存しています。数十行のグラフを読むのはすぐに非常に難しくなります。システム全体を監視し、必要に応じて個々の障害を検出する機能が必要です。

 



APIの12インスタンスのCPU使用率グラフ



このために、ドリルダウンダッシュボードを使用します。 1つのパネルの各画面に、システムのグローバルビューが表示され、個々の要素をクリックして詳細を確認できます。彩度については、グラフを使用せず、プロセッサとメモリリソースの使用を示す色付きの長方形を使用します。リソース使用量が指定されたしきい値を超えると、長方形がオレンジ色に変わります。

 



API



インスタンスのCPUおよびメモリ使用量インジケーター長方形をクリックして詳細に移動すると、さまざまなAPIインスタンスを表すいくつかの色付きの長方形が表示されます。

 



APIインスタンスのCPU使用率インジケーター



1つのインスタンスだけに問題がある場合は、長方形をクリックして詳細を確認できます。ここには、インスタンスの領域、受信したリクエストなどが表示されます。

 



APIインスタンスの状態の詳細ビュー。左から右、上から下：プロバイダーリージョン、インスタンスホスト名、最終再起動日、1秒あたりのリクエスト数、CPU使用率、メモリ使用率、パスあたりの合計リクエスト数、パスあたりの合計エラー率。



エラーの割合についても同じことを行います。API自体または関連するサービスで、問題がどこにあるかを理解するために、APIの各エンドポイントをクリックしてエラーの割合を確認します。



ここには微妙な違いがありますが、成功したリクエストの遅延とエラーについても同じことを行いました。主な目標は、サービスが世界規模で問題ないことを確認することです。問題は、APIに多くの異なるエンドポイントがあり、それぞれが複数のサービスに依存していることです。各エンドポイントには、独自の遅延とトラフィックがあります。



サービスエンドポイントごとに個別のSLO（およびSLA）を設定するのは面倒です。一部のエンドポイントは、他のエンドポイントよりも公称遅延が高くなります。この場合、リファクタリングが必要になる場合があります。個別のSLOが必要な場合は、サービス全体をより小さなサービスに分割する必要があります。おそらく、私たちのサービスの範囲が広すぎることがわかります。

全体的なレイテンシーを監視するのが最善であると判断しました。細分性により、待ち時間の偏差が非常に大きくて注意を引く場合に、問題を調査することができます。

結論

これらの方法を使用してシステムを監視してきましたが、問題の検出にかかる時間と平均修復時間（MTTR）が短縮されていることに気付きました。詳細化により、グローバルな問題の実際の原因を見つけることができます。私たちにとって、この能力は大きく変化しました。



他の開発チームもこれらの方法を使い始めており、それらの利点だけを確認しています。現在、彼らはサービスの運営に責任があるだけではありません。さらに進んで、コードへの変更がサービスの動作にどのように影響するかを判断できます。

4つのゴールデンシグナルは、すべての問題を完全に解決するわけではありませんが、最も一般的なものでは非常に役立ちます。ほとんど労力をかけずに、監視を大幅に改善し、MTTRを削減することができました。それらの間に4つのゴールデンシグナルがある限り、必要な数のメトリックを追加します。