こんにちは、インフラエンジニアのやすです。
この記事では、インフラ保守の作業の一環であるCPU使用率のアラート対応について、ご紹介します。
サーバが正常に動いているかどうかを把握するために、ZabbixやCloudwatchなどのなんらかの監視サービスでサーバを監視します。
対応の流れ
アラート受信
メールや電話で「CPU使用率が高い」旨の連絡を受けたら対応スタートです。
「アラートの連絡があったので、確認します」という旨の周知をしてから対応していきましょう。（最初に連絡しておくと、それを見た人から「すみません、今XX作業していてその影響です」などの連絡があって、すぐに解決するかもしれません）
状況確認
まずは、状況確認です。
下記の点を確認していきましょう。
CPU使用率が高い状況は継続中か？
まず、監視コンソールからCPU使用率が今も高いかを確認します。
監視製品のコンソールにログインできないのであれば、実際にサーバにログインしてvmstatで確認しましょう。
一時的なCPU使用率の高騰なら、対応不要です。
基本的には様子見で、頻発するようであれば原因を調査して対策を練ります。
継続してCPU使用が高騰している場合は、さらに確認を進めます。
CPU使用率の高いサービス（プロセス）は何か？
次に、topコマンドで何のプロセスがCPUを多く使っているのかを確認します。
たいていのシステムは、インフラ保守とアプリ保守で、担当チームがわかれているのが一般的です。
CPUを多く使っているプロセスが「インフラ寄りのプロセス」なら自分たちで引き続き対応、「アプリ寄りのプロセス（javaなど）」ならアプリチームに確認依頼をして任せても良いと思います。
作業影響か？
作業影響なら、対応不要です。
担当者に、アラート抑止の事前対応や調整をしておくよう注意喚起だけしておきましょう。
●●サーバのCPU使用率が高いのですが、誰か今なにか作業していますか？
定期処理の影響か？
決まった日時や曜日に動く定期処理の影響かを確認します。
調査資料の取得
対応が終わって落ち着いた後、「何が原因だったの？」という話になるので、できれば調査用の資料を取得しましょう。
多くの製品は「なにか問題が起きたら、まずこのコマンドで調査用の資料を取得して、サポートに連絡してください」というものがあります。
なので、そのやり方を事前に整理しておくとスムーズです。
暫定対処
サービス（プロセス）の再起動
CPU使用率が高い状態（100%に近い状態）が続いていて、作業影響でも定期処理の影響でもない場合は、使用率の高かったプロセスを再起動（停止、起動）することになります。
おそらくこれで解消するはず。。
解消すれば、ひとまず暫定対応はOKです。
OS再起動
サービスの再起動で解消しない場合は、OS再起動をしましょう。
ここまでやればCPU使用率の高い状態は解消されるはずです。
サービス（プロセス）を止めておく
OSの再起動がすぐにできない場合や（ほぼないと思いますが）OS再起動で事象が解決しない場合、対象のサービス（プロセス）だけ停止させておくという手もあります。OSごと止まる事態に発展するよりはマシでしょう。
原因調査
暫定対処まで終わったら、後日、原因調査を進めていきましょう。
規則性はないか？
過去に同様の事象が起きていないか、また、それと規則性がないかを確認します。
特定の曜日で起きるのか、特定の日にちで起きるのか、特定の時間帯で起きるのか、前日や前々日と比較してどうか、今週の他の曜日と比べてどうか、先週と比べてどうか、先月と比べてどうか、など「時間軸」を手掛かりに調べます。
ログになにか手掛かりはでていないか？
シスログやCPU使用率が高騰していたサービスのログに、なにか手掛かりがないかを確認します。ここでも問題が起きた時間帯を手掛かりにログを確認します。
製品サポート（ベンダー）に問い合わせ
なにかトラブルが起こったら、基本的にベンダーに問い合わせて確認を依頼します。
ベンダーの問い合わせ窓口や問い合わせ方法を整理しておくと良いです。
「自分の手で必ず解決しなければならない」というわけではないので、思うように調査が進まなくても悩み過ぎずにいきましょう。
原因調査はいつ終わる？
原因調査は、
「原因がわかる」
「おそらくコレが原因だろうということまでわかる」
「原因調査のハードルが高いことがわかる」
「原因がわからないことがわかる」
このいずれかのパターンまで調査が進めば完了です。
恒久対応
原因が判明したら、恒久対処を検討し、対応していきましょう。
システム的な設定変更による恒久対処のみではなく、運用（オペレーション）でカバーするという方法も選択肢にあります。
まとめ
この記事ではCPU使用率の高騰に対する対応方法をご紹介しました。
ではまた、ばいばーい♪
