期待する結果が明確なリクエストを選ぶ
例示的なレポートエンドポイントについて、ルートパターン、概算データサイズ、認証コンテキスト、バックグラウンド作業を生成するかどうかを記録します。テストアカウントと代表的なサニタイズ済みデータを使用してください。トークン、顧客識別子、完全なリクエストボディをインシデントメモにコピーしないでください。
初回リクエストの起動コストと、繰り返しの定常状態の動作を分離します。UTC の時間枠とリリースリビジョンを記録します。すべてのルートが遅いのか、大規模レポートのみが影響を受けているのか、遅延が 1 つの外部依存関係に従っているのかを判断します。これらの区別により、無関係なメトリクスの広範な収集よりも次の計測が有用になります。
二重計上せずにタイムラインを構築する
OpenTelemetry トレースは、サービス境界を越えて伝播されたコンテキストを通じて関連スパンを接続します。タイムスタンプを一致させるだけでは十分ではありません。ネストされた同期スパンと並列呼び出しは重複する可能性があります。非同期の子は親より長く生存する場合があるため、すべてのスパン duration を合計すると経過時間を二重計上する可能性があります。リクエストがいつ完了するかを決める操作に従ってください。
技術リファレンス: OpenTelemetry トレース · OpenTelemetry スパン終了時の動作.
| 区間 | 操作 | 確認事項 |
|---|---|---|
| 0~40 ms | ルーティングと認可 | このテストアカウントでは通常か? |
| 40~640 ms | データベース境界 | プール待ち、ロック待ち、実行のどれか? |
| 640~940 ms | 外部エンリッチメント | 接続、応答、再試行のどれか? |
| 940~1,020 ms | シリアライズ | ペイロードはどのくらい大きいか? |
最大の区間は調査すべき箇所を示唆するものであり、根本原因ではありません。API で計測されたデータベース区間には、クエリがデータベースに到達する前の接続待ちが含まれる場合があります。テレメトリの欠落も、作業が発生しなかったことを証明しません。サンプリングと計装の範囲を確認してください。
アプリケーションとホストの観測を関連付ける
同じ時間枠について、リクエストタイミング、エラー、データベース接続使用量、キューの経過時間、CPU、メモリ、ディスク圧力を収集します。同時実行されたバックアップ、移行、リリースを記録してください。単一の使用率スクリーンショットでは、リクエストに影響したバーストを見逃す可能性があります。
適切な保持期間とアクセス制御の下で、マスク済みログの相関 ID とタイムスタンプを使用します。生の秘密情報、顧客ペイロード、無制限のメトリクスラベルを避けてください。仮説に必要な境界に計装し、オーバーヘッドを確認します。新しいトレーシングエージェント自体も観測に値する変更です。
別のインシデントを起こさずにクエリを検査する
まずクエリ形状、入力サイズ特性、接続またはロック待ちを特定します。PostgreSQL EXPLAIN はプランを説明し、 EXPLAIN ANALYZE は実際に文を実行して計装オーバーヘッドを追加します。書き込みはデータを変更する可能性があり、高コストな読み取りも負荷を生みます。初期調査には分離された代表的なデータベースを使用してください。
プランナコストは経過ミリ秒ではありません。小さなテストテーブルでは、アプリケーションのより大きなデータセットとは異なるプランが得られる可能性があります。統計、インデックス、分布を確認し、変更後に同じクエリ形状を比較してください。タイミングを得るためだけに、未知の書き込みを本番の分析コマンドに貼り付けないでください。
技術リファレンス: PostgreSQL EXPLAIN.
1 つの変更で何が改善するはずか予測する
プール待ちが支配的な場合は、ワーカー接続、または不必要に接続を保持するリクエストを検査します。クエリ実行が支配的な場合は、プランと要求行を検査します。外部 API が支配的な場合は、タイムアウト、再試行、およびその作業を同期にする必要があるかを確認します。シリアライズ中の CPU 飽和は、別の実験を示します。
予測を書きます: エクスポートの同時実行を減らすと、エクスポートに時間がかかる一方で API プール待ちが減るはずです。これによりトレードオフが明らかになります。同じリクエストミックスを繰り返し、レイテンシとエラーを比較し、改善が単に障害を増大し続けるキューへ移しただけではないことを確認してください。
結果とその不確実性を保持する
元の観測、テストした変更、比較方法、残る不確実性を記録します。証拠が仮説と矛盾する場合は、適切な場合に分離した変更を元に戻し、別の境界を調査します。説明のない恒久的なチューニング変更を蓄積しないでください。
追加割り当てで対処できるリソース制約を計測が特定したときにサイズ変更します。次を使用します: ワークロード予算 を記録し、リリース回帰を次に取り込みます: インシデント概要。成果は根拠ある診断であり、約束されたレイテンシやプロバイダのベンチマークではありません。
公式リファレンス
この記事のドキュメントをレビューしました。例は計画用の演習であり、PrivacyNodes サーバーでテストされたコマンドではありません。インストールされているバージョンのドキュメントを確認してください。