コンテンツにスキップ 
私は、CPU、RAM、負荷、I/Oが素早く意味のある情報を提供するようにモニタリングを解釈する方法を紹介する。これにより、早い段階でボトルネックを認識し、ピークを正しく分類し、次のような対策を講じることができる。 パフォーマンス と可用性。.
中心点
- CPUコア を正しく設定してください：利用率と負荷は常にコア数に関連して設定する。.
- RAMとスワップ 読む：消費とスワップ活動の増加が減速を警告。.
- 負荷平均 を示す：IOwaitによる高負荷は、メモリまたはディスクのボトルネックを示している。.
- I/Oメトリクス check：%util、awaitとIOPSは飽和とキューを示しています。.
- ベースライン 利用する：トレンド、しきい値、アラームの設定と調整.
CPU使用率を正しく分類する
を評価する。 CPU-なぜなら、4コアの75 %と32コアの75 %では意味が違うからです。負荷が80 %以上の状態が長く続く場合は、コードの最適化を計画するか、容量を追加します。コアごとの総利用率に加えて、短いピークと継続的な負荷を分けるために、1分、5分、15分の負荷平均をチェックします。top/htopを使用することで、ホットスポットを即座に認識し、pidstatを使用してCPU時間が顕著な個々のプロセスを分離する。恒久的に高い値が非効率的なクエリを示している場合は、データベースのインデックス、キャッシュ、そして プロファイリング.
| 指標 | 健康エリア | 警報信号 | 次のステップ |
|---|---|---|---|
| CPU使用率 | 80以下 % | 85以上 %持続 | ホットスポットを見つけ、コード/クエリを最適化し、必要に応じてコアを追加する。 |
| 負荷平均 | コア数 | コアについて（5分/15分） | プロセスリストのチェック、IOwaitの明確化、キューの削減 |
私はまた、次のように区別している。 ユーザー-, システム-, イラク/ソフトイラク- そして steal-時間。システムやsoftirqが著しく増加した場合、カーネルやドライバ作業（ネットワーク/ストレージ）がクロックを消費する。仮想マシンのスティールが大きくなると、同じホスト上の隣人と競合する。 うるさい隣人-仕事に影響を与えたり、先送りしたりする。良いシェアは、意図的に優先順位の低い仕事を示している。積み上げ コンテキスト・スイッチ あるいは、vmstatのランキューエントリーが増えたら、ロック保持、スレッドプールが小さすぎるか、並列度が高すぎるかをチェックする。.
- CPUのクイックチェック：ユーザーとシステムを明確にし、ステイル（クラウド！）をチェックし、プロコアのホットスポットを特定する。.
- 熱と周波数： スロットリングは、高温とクロック周波数の低下によって示される。.
- ハイパースレッディング：論理スレッドはフルコアの代わりにはならないので、使用率は控えめに計画する。.
RAM、キャッシュ、スワップを理解する
中古を区別する RAM, なぜなら、Linuxは空きメモリをキャッシュとして積極的に使用するからである。アプリケーションが常にRAMを満たし、スワップが開始されると問題になる。ディスクへのアクセスはRAMへのアクセスよりもかなり時間がかかるため、定期的なスワップ・アクティビティはシステムを遅くする。メモリ使用量が数時間以上継続的に増加する場合、私はメモリリークをチェックし、印刷のシグナルとしてページフォルトを観察する。必要であれば、RAMを増やしたり、ガベージコレクションを最適化したり、個々のページのフットプリントを減らしたりする。 サービス内容.
| 指標 | 健康エリア | 警告信号 | 測定 |
|---|---|---|---|
| RAM使用量 | 80以下 % | 85 %以上、着実に増加 | リーク解析、キャッシュチューニング、必要に応じてRAMの拡張 |
| スワップ利用率 | アンダー10 % | 定期的な活動 | ストレージ要件の削減、スワップ性の調整、ストレージの高速化 |
| ページの不具合 | 低い／安定している | 急峰 | ホットセットの拡大、キャッシュの強化、クエリの緩和 |
私も観察している。 THP (Transparent Huge Pages）、NUMAローカリティ、OOMキラー。THPはレイテンシに敏感なワークロードではコンパクションの引き金になる可能性があるため、調整が理にかなっているかどうかをテストします。NUMAシステムでは、以下のような不均一性に注意しています。 保管場所 CPUソケットあたり。OOMキラーがプロセスをトリガーした場合、リザーブは使い果たされた。 vm.オーバーコミット-を設定する。メディアの速度が十分であれば、zram/zswapで圧力を和らげることができるが、私はいつも症状よりも原因（フットプリント）を優先する。.
- スワップを微調整する：積極的なスワップは避けるが、ページキャッシュを早々に置き換えないようにする。.
- ヒープとGCのプロファイルを定期的に取得し、デプロイ後のピーク消費量を比較する。.
- ハードキルを避けるために、余裕を持ったメモリ制限（コンテナ/サービス）を定義する。.
ロードアベレージを明確に読む
私はそれを読みます。 負荷 これは、実行中またはリソース待ちのプロセスをカウントする。1.0は1つのコアでフルに利用されていることを意味し、1.0は8つのコアでほとんど負荷がかかっていないことを意味する。5分または15分の負荷がコア数を上回った場合、その背後にIOwaitやブロックされたプロセスがあるかどうかを即座にチェックする。CPUに空きがあり、なおかつ負荷が高い場合は、I/Oボトルネックやロッキングを示すことが多い。典型的な誤解については、私は ロードアベレージの解釈, そうすれば、コア数をきれいに計算できる キャリブレーション.
無停止I/O（D-State）は負荷を増加させるが、CPUはほとんど増加させない。そのため、vmstat（r/b）と状態を含むプロセスリストで負荷を相関させている。分ウィンドウの短い負荷ピークは、多くの場合、無害である。経験則として、ラン・キューと負荷は平均コア数以下にとどまるべきである。 バッチ処理.
I/OとIOwaitを見えるようにする
私はこう考える 入出力 で iostat -x: %utilはデバイスがどれだけビジーかを示し、awaitはリクエストごとの平均待ち時間を示す。%utilが恒常的に100 %に近づいたり、awaitの値が2桁ミリ秒の範囲に上がったりすると、アクセスが蓄積している。IotopはI/O負荷の高い個々のプロセスを特定するのに役立ち、vmstatはwa列でIOwaitの割合を明らかにする。中程度のCPUで高いIOwaitは、ディスクの飽和かストレージの待ち時間を示す。原因と対策の詳細については、以下のページにまとめている。 IOウェイトを理解する ボトルネックを正確に特定できるようにね。 ディゾルブ.
| 指標 | 意味 | しきい値 | 測定 |
|---|---|---|---|
| 1TP3チュチール | デバイスの利用 | 90以上 % | ロードバランシング、SSD/NVMeの高速化、キューのチューニング |
| 待つ | 待ち時間/リクエスト | 上昇/高 | キャッシュの強化、インデックスの追加、ストレージの待ち時間の短縮 |
| IOPS | オペレーション/秒. | 目に見える彩度 | スループットの最適化、バッチ処理、非同期処理 仕事 |
また、筆記具の評価も行っている。 ライトバック とダーティ・ページがある。dirty_background/dirty_ratioのクォータが増加すると、システムはフラッシュを遅延させる。ジャーナリングとRAIDのリビルドは、対応するアプリケーションの負荷がないにもかかわらず、高いシステム/WAシェアで現れます。ボトルネックの原因がファイルシステム（マウントオプション、キューの深さ、スケジューラ）なのか、基礎となるデバイスなのか、LVM/RAIDアレイが個々のデバイスに不均等な負荷を与えていないかをチェックします。完全に利用されている場合は、垂直方向（より高速なミディアム）または水平方向（シャーディング、レプリカ）にスケーリングします。.
- 当面の対策DBの前のキャッシュ層を強化し、インデックスを強化し、RAMのホットセットを増やす。.
- スムーズな書き込みパス：バッチサイズ、非同期コミット、チェックポイント間隔のチェック。.
- ファイルシステムをチェックする：空きinode、断片化、必要に応じてマウントオプション（noatime）を設定する。.
接続を認識する：CPU、RAM、I/Oの相互作用
私は常にシステムを総合的に捉えている。 指標 は互いに影響し合う。CPUが低いのに負荷が高い場合は、I/O処理がブロックされていることが多く、CPUが高いのに負荷が一定である場合は、計算集約的なタスクが行われていることを示している。RAMの圧力が高まると、データがスワップに移動し、突然I/O負荷と長い待ち時間が発生する。逆に、ターゲットを絞ったキャッシングはI/O負荷を減らし、負荷とCPUのピークを下げる。その結果、最も効果的なポイントで対策を講じることができるようになる。 適用する.
ネットワーク・メトリクスを正しく評価する
私は組織する ネットワーク-スループット、レイテンシー、エラー、接続に沿ったシグナル。再送、ドロップ、エラーが発生した場合は、NIC、ドライバ、スイッチ、またはアプリケーションのボトルネックを探します。ss -sを使うと、フルリスト（ESTAB、SYN-RECV）、タイムウェイトフラッド、使い果たしたバックログを認識できる。Sar -nはp/s、err/s、drop/sを表示し、ethtool/nstatはNICエラーとオフロードの問題を明らかにする。名前解決が遅いとリクエスト全体が遅くなるので、DNSルックアップは別に測定している。.
- 再送が多い：MTU/フラグメンテーションをチェックし、バッファ（rmem/wmem）とオフロードを調整し、遅延パスを分析する。.
- SYNバックログがいっぱい：バックログを増やし、レート制限をチェックする、, コネクション・プーリング 最適化する。.
- P95/P99の外れ値：View Nagle/Delayed ACK、TLSネゴシエーション、Keep-Alive、セッションの再利用。.
仮想化とコンテナの検討
VMで私は次のように見ている。 steal, ハイパーバイザーのリテンションが目に見えてCPUを「奪う」ためだ。余分なヘッドルームを計画するか、クリティカルなワークロードを分離する。cpu.max/cpu.sharesは公平性をコントロールし、memory.maxとoom-killイベントはハードリミットを示す。スロットリングは、十分なコアが利用可能であるにもかかわらず、高い待機時間としてpidstat/Topで認識できる。ホスト・レベルだけでなく、コンテナ/ポッド単位で計測し、制限、リクエスト、実際の処理を関連付ける。 使用方法. .ノード・プレッシャー（PSI）はシステム全体の圧力を早い段階で確認するのに役立つ。.
トレンド、ベースライン、季節性
私は、CPU、RAM、負荷、I/Oを作成する。 ベースライン 時間帯や曜日ごとに、通常のパターンと実際の異常とを区別できるようにした。反復的なクーロン・ジョブ、バックアップ、または分析タスクは、予測可能なピークを引き起こします。異常値については、移動平均と95パーセンタイルを使って誤検出を減らしています。ユーザーの行動に変化があれば、週に一度、しきい値を調整します。ビジュアライゼーションには、試行錯誤を重ねた 監視ツール, トレンドをわかりやすく説明し、意思決定の時間を節約する。 約する.
私はベースラインを次のように補完している。 マーカーを配置する 負荷の跳ね上がりを分類するために、日次、週次、月次の季節性に注意しています。ロールアップ（1m、5m、1h）を選択し、ピークを平滑化しないようにする。負荷の変動が激しい場合は、「ロングテール」が見えるように、時間窓でp95/p99を評価する。.
しきい値とアラームを適切に設定
私は、アラームが単に音量を発生させるだけでなく、行動を引き起こすような形でアラームを定義している。 数量. .例えば、CPUでは5分間に80 %以上、RAMでは85 %以上、Loadでは15分間にCoresを使用する。IOwaitアラームは、vmstatのwaが定義したベースラインより大きくなったときに設定する。警告とクリティカルを組み合わせて、エスカレートする前に対策を講じられるようにしている。各シグナルを最初のステップと反応時間を説明するランブックにリンクしている。 セーブ.
アラームを症状別ではなく、原因別にグループ分けしている：ストレージの問題により、後続のアラーム（CPUアイドル、高負荷、タイムアウト）が多数発生する。 事件. .複数条件のアラート（負荷＞コアかつIOwait増加など）はノイズを減らす。メンテナンスウィンドウとミュートは、フォローアップと同様にプロセスの一部です：私は各インシデント後にしきい値を調整し、各アラートの明確な終了基準を文書化します。.
エラーパターンの迅速な診断
メモリリークは、徐々に増加する メモリ使用量, これはデプロイ後に返されません。データベース・インデックスの欠落は、高い I/O 負荷、待機値の増加、プロセス・リストでハングするクエリによって明らかになる。ループや正規表現の問題によるCPUのピークは、多くの場合、トラフィックイベントの直後に発生し、再起動まで持続する。フルボリュームは、増大するI/Oキューとスループットの低下で事前に確認することができる。私は、CPU/RAMプロファイルが正常であるにもかかわらず、応答時間が長くなることでネットワークの待ち時間が発生することを確認しています。 ネットワーク-レベルだ。
追加のサンプル：
- スティール・ハイ ノイジーな隣接ホストまたはオーバーブッキング状態のホスト - ワークロードを分離または移動。.
- GCブレークCPUは低下し、レイテンシは上昇し、ショートストップ・ザ・ワールドは停滞する。.
- THPコンパクションシステム時間が増加し、待ち時間がピークに達する。.
- ライトバックのヒントawait/waが高く、特にチェックポイントでは、フラッシュ/チェックポイント戦略をスムーズにする。.
- プール疲れ接続またはスレッドプールが一杯になり、多くのリクエストが待機している。.
- エフェメラル・ポート 或いは FD限界 達成：新規接続に失敗 - sysctl/ulimitsを増やし、再利用を有効にする。.
将来を見据えたキャパシティ・プランニングとコスト管理
私はトレンドデータからキャパシティの計画を立て、的を絞ったアップグレードができるようにしている。 タイミング-正しい方法で。CPUの95パーセンタイルが月に10 %増加する場合、私はアラームが定期的にトリガーされるポイントを計算する。RAMについては、スワップまでどれだけのヘッドルームが残っているか、またキャッシュによってどのように要件が減るかをチェックする。I/Oについては、まだ許容できる最高の待機値で計算し、無闇にスケーリングする前に、より高速なメディアへの投資を優先する。このようにして、システムの信頼性を維持し、コストを予測可能にする。 ボトルネック に反応する。.
私はキューイング効果を考慮している：%の使用率が～70～80になると、待ち時間は比例して長くなります。 ヘッドルーム ピーク時オーバープロビジョニングの代わりにライトサイジングを行うことで、コストを削減できる。小さなステップでのスケーリング、スポットとリザーブの組み合わせ、未使用リソースのスイッチオフなどだ。レイテンシがクリティカルパス以下であったり、シャーディングが複雑すぎる場合は垂直方向に拡張する。.
ツールスタック: top, vmstat, iostat, pidstat
私は、CPU、RAM、および 州 をソートして異常値を見る。それからvmstatでランキュー(r)、ブロックされたプロセス(b)、IOwait(wa)、コンテキストスイッチ(cs)を読み、iostat -xでデバイスごとに%util、await、r/s、w/sを評価し、飽和を素早く認識する。Pidstatは、プロセスごとのCPU時間、I/O、コンテキストスイッチを表示してくれる。また、エージェント経由で主要な数値をダッシュボードに集め、数日間のパターンをきれいに分析できるようにしています。 比べる.
必要に応じて補う：
- サル 過去のシステムデータ（CPU、RAM、ネットワーク、ブロックデバイス）。.
- ss およびソケット、バックログ、再送のネットリンク統計。.
- パーフェクト/eBPFベースのツールにより、大きなオーバーヘッドなしに深いホットパス解析を実現。.
- ストレース システムコールが疑われる場合、選択的にブロッカーを表示する。.
- fio 現実的なストレージプロファイルを測定し、目標値を導き出す。.
ログとトレースでメトリクスを接続
リンク 指標 ログや分散トレースとの相関関係：リクエストID、サービスタグ、バージョンタグ、リージョン、ノード。これにより、レイテンシーの増加から、特定の遅いクエリや外部依存関係の不具合への移行を見つけることができます。ダッシュボードでデプロイメントをマークし、数秒でリグレッションを認識できるようにしています。エラー率（Rate）と飽和度（Saturation）にレイテンシのパーセンタイルを追加します。 SLO ユーザー・エクスペリエンスを直接反映するアラームで。.
今後30日間の実践ガイド
第1週では、私は次のことを明確にした。 ベースライン を設定し、バックアップやレポートなどの定期的なタスクをマークする。2週目には、各シグナルに対する最初の介入を記述したアラームとランブックを設定する。3週目には、主な要因（遅いクエリ、インデックスの欠落、不要な直列化、小さすぎるキャッシュ）を最適化する。4週目には、負荷分散がどのように変化したかをチェックし、それに応じて容量や制限を調整する。これによって、モニタリングが事後的な観察から行動指向のモニタリングへと移行する、反復可能なサイクルが生まれる。 税金 はしません。
私は積極的にアラームをテストしている（ゲームデー）：人工的な負荷、低メモリ、スロットルされたI/Oを常にロールバックしている。明確な測定ポイント（「負荷がコア数より多く、かつWAが高い場合、...」）でランブックを改良する。インシデントがなくても、毎週ミニ・ポストモルテンムを実施し、学習効果を確保する。 ノイズ 削減する。30日間が終わるころには、強固なダッシュボード、きれいなしきい値、そして的を射た方法で対応する方法を知っているチームができていることだろう。.
簡単にまとめると
私は読んだ。 モニタリング-データは、CPUコア、メモリ利用率、負荷平均、I/Oインジケータのコンテキストで一貫して表示されます。CPUの経時的な高負荷、RAMの利用率の増加、コア数以上の負荷、IOwaitは、私にとって最も重要なアラーム候補です。top、vmstat、iostat、pidstat、クリアダッシュボードを使い、パターンを認識し、最も効果的な調整スクリューを選択する。ベースライン、意味のあるしきい値、ランブックは、数値を具体的で迅速なアクションに変換します。これにより、モニタリングを解釈し、ボトルネックを回避し、信頼性の高いユーザー・エクスペリエンスを確保することができます。 セキュア.
