4 golden signals

Latency (處理の遲延)

リクエストの處理にかかる時閒。成功したリクエストのレイテンシと失敗したリクエストのレイテンシを區別することが重要です。たとえば、データベースやその他の重要なバックエンドへの接續の喪失が原因でトリガーされた HTTP 500 エラーは、非常に迅速に處理される可能性があります。ただし、HTTP 500 エラーはリクエストの失敗を示すため、全体の遲延に 500 を因數分解すると、誤解を招く計算が發生する可能性があります。一方、遲いエラーは速いエラーよりもさらに惡いものです！したがって、單にエラーをフィルタリングするのではなく、エラーの遲延を追跡することが重要です。

Traffic (呼び出し數)

システムにどれだけの需要が課されてゐるかの尺度。高レベルのシステム固有の指標で測定されます。Web サービスの場合、この測定は通常、1 秒あたりの HTTP リクエストであり、おそらくリクエストの性質 (靜的コンテンツと動的コンテンツなど) によって區別されます。オーディオ ストリーミングシステムの場合、この測定はネットワーク I/O レートまたは同時セッションに焦點を當てる場合があります。key-value ストレージシステムの場合、この測定値は 1 秒あたりのトランザクションと取得數になります。

Errors (error 數)

明示的に (例へば、HTTP 500s)、暗默的に (例へば、HTTP 200 の成功レスポンスだが、閒違ったコンテンツと結合して)、またはポリシーによって (例へば、1 秒閒のレスポンス時閒をコミットした場合、1 秒以上のリクエストはエラーである)、失敗するリクエストの割合。プロトコルの應答コードがすべての障礙狀態を表現するには不充分な場合、部分的な障礙モードを追跡するために二次 (內部) プロトコルが必要になる場合があります。これらのケースの監視は大幅に異なる場合があります。ロードバランサーで HTTP 500 をキャッチすると、完全に失敗したリクエストをすべてキャッチするといふ適切な作業を行うことができますが、閒違ったコンテンツを提供してゐることを檢出できるのはエンドツーエンドのシステムテストだけです。

Saturation (飽和度)

あなたのサービスはどれほど「充實してゐる」か。最も制約されてゐるリソースを強調する、システム分數の尺度 (例: メモリ制約のあるシステムでは、show memory; I/O制約のあるシステムでは、show I/O)。多くのシステムは、使用率が 100% に達する前にパフォーマンスが低下するため、使用率目標を設定することが不可缺であることに注意してください。

複雜なシステムでは、飽和をより高レベルの負荷測定で補ふことができます。サービスは、現在受信しているトラフィックよりも 2 倍のトラフィックを適切に處理できるか、10% しか處理できないか、またはさらに少ないトラフィックを處理できますか? リクエストの複雜さを變更するパラメータを持たない非常に單純なサービス (例: 「ノンスを與へてください」または「グローバルに一意の單調整數が必要です」) では、構成がほとんど變更されない場合、負荷テストからの靜的値が適切である可能性があります。ただし、前の段落で說明したように、ほとんどのサービスは、既知の上限を持つ CPU 使用率やネットワーク帶域幅などの閒接信號を使用する必要があります。レイテンシーの增加は、多くの場合、飽和の先行指標となります。いくつかの小さなウィンドウ (たとへば、1 分) で 99 パーセンタイルの應答時閒を測定すると、非常に早い段階で飽和の信號を與へることができます。

最後に、飽和は、「データベースが 4 時閒でそのハードドライブを埋めるようです」など、差し迫った飽和の豫測にも關係してゐます。

USE method (machine の健全性)

Utilization (使用率)

決められた interval のなかで、resource が要求を處理するために busy 狀態だった時閒の割合。busy 狀態でも resource は新しい要求を處理できる場合があるが、新しい要求を處理できない度合ひは飽和度によって明らかにできる

Saturation (飽和度)

處理できない要求 (queue で待機してゐることが多い) を抱へてゐる度合ひ。pressure といふ用語でも同じことが表せる

Errors

error event の囘數

分野每の USE

application

U : 一定期閒中に要求を處理して busy 狀態になってゐる thread 數の平均の thread 總數に對する割合。たとへば、50% なら、平均して半分の thread が要求處理のために busy 狀態になってゐる

S : 期閒中における要求 queue の長さの平均。worker thread 待ちで待機してゐた thread がいくつかあるかがわかる

E : 何らかの理由で拒否された要求と失敗した要求の數

CPU

U : CPU が busy だった時閒 (idle thread 以外を實行してゐた時閒) の割合

S : on-CPU 待ちで queuing されてゐる實行可能 thread の割合

E : 修正可能なものも含む CPU error

memory

U : 物理 memory と假想 memory の兩方で、どの程度の memory が使はれてをり、どの程度の memory が free 狀態になってゐるかを check する

S : page scan、paging、swaping、OOM killer による強制終了の度合ひは、memory pressure を緩和するための尺度となる

E : software、hardware の error

disk

U : device が busy 狀態だった時閒

S : I/Oが queue で待機している度合ひ

E : device error

network

U : interface が frame の送受信で busy だった時閒

S : interface の使用率が 100% になったために發生した queuing、buffering、blocking の度合ひ

E : 受信側では、checksum 誤り、短か過ぎる frame (datalink header 未滿) や長過ぎる frame、collision (switch を使った network ではあまり起きない)、送信側では、late collision (配線の不良)

RED method (user から見た健全性)

Rate (要求率)

req/sec

1 秒あたりの service 要求の數

Errors

失敗した要求の數

Duration (處理時閒)

要求の處理が終はるまでの時閒

平均のほか、percentile などの分布の統計量も考慮する