回答:
ファーストオーダー：応答性がありますか？
ログインできない場合は、さらに大きな問題が発生しています。これには通常、ハードウェア障害とソフトウェア障害の2つの種類があります。どちらも壊滅的な可能性があります。DFAエラーを防ぐには、最初に一般的なハードウェアの状態を確認します。通常は、簡単な一見だけで十分です。
2次：システムの基礎となる構造は、正常で正常ですか？
システムの「ゴールデントライアド」を確認します。
過去数十年で、トライアドは通信（ネットワーク）を含む「クワッド」に拡大しました。
3次：問題の重大度は？
どのプログラムまたはサービスが影響を受けますか？重大度の降順で、それは全身的（システム全体）、クラスター化（プログラムのグループ）、または分離（特定のプログラム）ですか？特定の基になるサービスが失敗したか、応答しなくなったため、プログラムのクラスターは通常、作動しています。体系的な問題はこれに関連している場合があります（DNSまたはIPの競合を考えてください）が、通常はどこを見るかを知ることが重要です。
4次：診断ツールは問題に関連する有用なデータを提供していますか？ システムの状態（2次）と問題が発生している部分（3次）についての情報が得られたので、問題の場所を簡単に絞り込むことができます。
エラーメッセージまたはログファイルは、この旅における一般的なウェイポイントである必要があります。
CPUの問題：
ディスク容量/ IOの問題：
メモリの問題：
接続の問題：
（私が聞いた）最も一般的な不満：
メールが十分に速く配信されていない（送信から受信者が受信するまでに1分以上）、またはメールが送信を拒否しています。これは通常、スパムストーム中にキックインするPostfixのレートリミッターに帰着します。これは、内部配信を受け入れる機能に影響を与えます。
実際の例：
ただし、これは常に当てはまるわけではありません。かつては、サービスの再起動に関係なく問題が解決しませんでした。だから3分後には周りを見回す時間でした。CPUはビジーでしたが100％未満でしたが、2コアのボックスで負荷が15に急上昇し、さらに高くなると脅迫されていました。topコマンドは、メールシステムがメールスキャナーと共にオーバードライブ状態にあることを明らかにしましたが、表示されるamavis子プロセスはありませんでした。それが手がかりでした-メールキューコマンド（mailq）は、150以上の未配信メッセージを表示し、その80％以上がスパムでした、過去20分間。子メールスキャナープロセスの数を増やしながら（バックログを処理するために）レートリミッターを下げ（スパムストームの取り込み率を下げました）、その後サービスを再起動して、問題を解決し、システムは問題なく解決しました短納期でお届けします。
この問題の原因は、amavis親プロセスが死んでしまったことと、子プロセスが最終的にすべてのコースを実行したことです（メモリリークを防ぐために、非常に多くのスキャンの後に自己終了します）。したがって、必要なスパム/ウイルススキャンを実行するために...薄層...に接続しようとするSMTPプロセスがpostfixにありました。私が使用していたディストリビューションには、決してアップデートされない古いパッケージがありました。インストールは1年ほどで置き換えられる予定だったため、いくつかのバグ修正を含む最新バージョンに手動で「上書き」しました。それ以来、私は同じ問題を抱えていません。
通常は「誰」の後に「最後」が続く
私が何年にもわたって管理してきたマシンの問題の山は、「手つかず」の非常に緩い定義が原因でした-誰かが何かをしたことがよくあります:)
最初にチェックするのは「トップ」です（奇妙なプロセスがあります。メモリまたはCPU時間を占有するプロセスです）。
そこに何も表示されない場合は、「誰か」をチェックして、何らかの理由で誰かが私のマシンにいるかどうかを確認します。
ファイルシステムがマウント解除されたのかもしれません。「cat / etc / mtab」を呼び出してから「fstab」を呼び出して、起動時にすべてが正しく起動することを確認してください。
稼働時間をチェックして、ボックスのユーザー数が妥当であることを確認し（あなただけである必要があります）、var / log / auth.logを調べて、そこに問題がないかどうかを確認します。
これらは包括的なものです。ボックスがスローしているエラーによっては、問題の原因となっている特定のプロセスを調べる必要がある場合があります。
ホストで（at）sarなどを実行することはほぼ必須です。CPU、ネットワーク、メモリ、およびディスクI / Oの履歴スナップショットを取得できることの有用性は、（特に）控えめに言っても過言ではありません。
ホストが過去24時間に何をしていたかを調査し、問題が発生し始めた時期を確認することで、障害を診断することが何度もありました。
私が最初に行うことは、（他の人が述べたように）ディスク容量のチェックだと思います。単純なチェックで「一般的な」問題が明らかにならない場合は、さらに調査します。
私がやりたいことの1つは、システムのスナップショットをキャプチャすることです。これらを後でgrepして、私の目を引いたものを探すことができます。
lsof > /tmp/lsof.tmp &
ps auxfw > /tmp/ps.tmp &
netstat -anp > /tmp/netstat.tmp &
そこから101のトラブルシューティングですが、保存されたログをgrepする方が少し高速であることがわかります。ログイン中に状態がクリアされた場合は、続行するか、変更を探す必要があります。