XXパーセントの平均レイテンシーです。リクエストのレイテンシーを表します。XXが大きければ大きいほど遅いものに注目できる反面、局所的になるかもしれないことを示します。分かっている人も多いかもしれませんが、極端に遅いものがあり速度に差があるようなケースはP99が大きく、P99に比べてP50が小さいです。逆に、なだらかに差があるときはP50とP99の差は少ないです。このような情報から、トラフィックの安定度を知ることができます。詳しくは以下の文献を見るといいかもです。docs.aws.amazon.comここで注意して欲しいのは以下のコマンドのREADYに出る数はPodに含まれるコンテナ数です。controllerのPodは一つです。Line全体の俯瞰的なダッシュボードです。Service以下のようなサービスが使えます。LBに関わるようなメトリクスを取得することができます。項目をクリックすると以下のようになります。Trafficと呼びます。DeploymentDeployはプレフィクスがdeploy/が付いています。Podが複数あるときに活躍してきそうな感じはあります。Linkerdの管理画面では以下のようになっています。PodPodはプレフィクスがpo/が付いています。以下のようにProxyがあるため、InboundとOutboundのトラフィックを取得することができます。外部からそのサービスにトラフィックが流れ、レスポンスを返すまで。その時の外部通信などを全て含む。通信クライアントがServiceの場合はそのサービスの値が出る。test-2のInboundはtest-1である。そのサービスが使っている他のService。ここならtest-1のOutboundはtest-2である。ストリームをみるstatstatはかなりハイレベルなレイヤーの監視をすることができる。以下のようなコマンドを走らせることで見ることができます。ストリームではなく、バッジ的に値を算出するので一時的に状態が知りたい時は使うべきだと思います。percentilesを見ることができます。topstatよりも具体的にパスごとに何が起きているのかを確認することができます。f具体的な通信状態がわかるのが良いと思います。以下のようにパスごとのメトリクスを知ることができるのです。100.00%WebUIでは以下の通りです。tap以下のコマンドで具体的なServiceごとで見ることができます。ストリームで見られることが特徴ではないでしょうか。絶え間なく、各々のストリームについて知ることができます。response-length=15B...WebUIでは以下の通りです。ストリームの詳細まで見ることができるので、問題が深いときには見るべき点かなと思いました。知りたいこと今回はなぜレスポンスタイムにスパイクが起こるのかを検証していきます。以下のように二つのServiceが見られるようにします。毎秒3回のリクエストを一つあたり1000回のリクエストを送ります。実際に100ms以上のレスポンスを返せていない時は2000rqsであり、現在のテストは3rqsである。スパイクする原因はリソースが落ち着いている時は起きないと考える。負荷試験の必要性があり。付録linkerdコマンド以下のコマンドがあります。»プロフィール学生エンジニア。忘れてしまうので備忘録です。flaskでServerlessにホストするTelepresence概論スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。