手つかずのUNIXサーバーが暴走し始めたときに最初に確認することは何ですか？
だからあなたはこのきちんとセットアップされたUNIXサーバーを持っています、そしてそれは超高速でうまく機能し、そしてすべてが何ヶ月も素晴らしいです、そして突然あらゆる種類の奇妙なエラーがさまざまな異なるサービスに現れ始めます、そしてそれらのどれもそれ自体ではあまり意味がありません、ましてや一緒に。
マシンへのsshセッションを取得したらすぐに確認する必要がある安価なものは何ですか？
私は特に、自明ではないコマンドやまれな状況を強調するトラウマストーリーに興味がありますが、明らかなことは人によって異なると思うので、それらすべてを自由にリストすることができます。
一次：応答性がありますか？
ログインできない場合は、さらに大きな問題が発生しています。これには通常、ハードウェア障害とソフトウェア障害の2つの種類があります。どちらも壊滅的な可能性があります。 DFAエラーを防ぐには、最初に一般的なハードウェアの状態を確認します。通常は、一目見ただけで十分です。
2次：システムの基礎となる構造は正常で正常ですか？
システムの「ゴールデントライアド」を確認します。
- 処理に十分なCPU時間は無料です
- ストレージ用に十分なディスク容量があります
- ワークロード用に十分なメモリが解放されます
過去数十年で、トライアドは通信（ネットワーキング）を含む「クワッド」に拡大しました。
- 接続性は機能的で応答性が高く、容量があります
番目の順序：問題の重大度はどれくらいですか？
どのプログラムまたはサービスが影響を受けますか？重大度の降順で、それは体系的（システム全体）、クラスター化（プログラムのグループ）、または分離（特定のプログラム）ですか？プログラムのクラスターは通常、特定の基盤となるサービスに障害が発生したか、応答しなくなったためにトリップしています。体系的な問題はこれに関連する場合がありますが（DNSまたはIPの競合を考えてください）、通常はどこを見ればよいかを知ることが重要です。
4次：診断ツールは問題に関連する有用なデータを提供していますか？これで、システムの状態（2次）とシステムのどの部分で問題が発生しているか（3次）に関する情報が得られました。問題のある場所を簡単に絞り込むことができます。
エラーメッセージまたはログファイルは、この旅の一般的な中間地点である必要があります。
CPUの問題：
- loadav
- 上
- strace
ディスク容量/ I-Oの問題：
- df
- デュ
- lsof
- iostat
- vmstat
メモリの問題：
- 自由
接続の問題：
- ping
- ルート（およびarpとrarpとその仲間）
- iptables、ipchains、ipfw（そこにいるBSDの人々のために）
- tracerouteまたはmtr
- ホスト、nslookup、またはDig
- netstat
最も一般的な苦情（私が聞いた）::
電子メールが十分な速度で配信されていない（送信から受信者による受信まで1分以上）か、電子メールが送信の試みを拒否しています。これは通常、スパムストーム中に開始されるPostfixのレートリミッターに帰着し、内部配信を受け入れる機能に影響を与えます。
実際の例：
ただし、これが常に当てはまるとは限りません。あるときは、サービスの再起動に関係なく問題が解決しませんでした。それで3分後、周りを見回し始める時が来ました。 CPUはビジーでしたが、100％未満でしたが、2コアのボックスで負荷が15に急上昇し、さらに高くなると脅迫していました。最上位のコマンドは、メールシステムがメールスキャナーとともにオーバードライブ状態にあることを明らかにしましたが、amavisの子プロセスは見られませんでした。それが手がかりでした-メールキューコマンド（mailq）は、過去20分間に150以上の未配信メッセージを示し、そのうちの80％以上がスパムでした。子メールスキャナープロセスの数を増やしながら（バックログの処理を支援するために）レートリミッターを下げる（スパムストームの取り込み率を下げる）ための迅速な調整と、それに続くサービスの再起動により、問題が解決され、システムは短時間で配達を完了します。
問題の原因は、amavisの親プロセスが死んでしまったことであり、子プロセスは最終的にすべてコースを実行しました（メモリリークを防ぐために、非常に多くのスキャンの後に自己終了します）。そのため、必要なスパム/ウイルススキャンを実行するために...シンエア...に接続しようとするSMTPプロセスがpostfixにありました。私が使用していたディストリビューションには、更新されない古いパッケージがありました。インストールは1年ほどで置き換えられる予定だったので、いくつかのバグ修正を含む最新バージョンにインストールを手動で「上書き」しました。それ以来、私は同じ問題を抱えていません。
通常は「who」の後に「last」が続きます
私が長年管理してきたマシンの問題の山は、「手つかず」の定義が非常に緩いためでした。多くの場合、誰かが何かをしました:)
さて、始めましょう。
これは一度私を噛みました、私は何千もの異なることを試したり、あちこちでサービスを無効にしたり、再起動したりするのに何時間も費やしました。問題は何でしたか？完全にディスク容量が不足しています。
したがって、突然問題が発生したサーバーをデバッグするときに最初に入力するのは次のとおりです。
df -h
私は今それを決して忘れません。それは私に多くの無駄な努力を節約しただけです。私が共有したいと思った。
top（またはhtop）
Dmesgにエラーがないかチェックする-私は通常、dmesg | tailから始めます。これは、問題がまだ発生していない可能性があり、サーバーがエラーの原因となっていることを実行しようとしているためです。
可能であれば、管理用のNICを除くすべてのNICを常にシャットダウンしてみます。
Linuxでは、通常、dmesgと/ var/log/messagesまたは/ var/log/syslogをチェックします。 dmesgは、それが突然のハードウェア障害であるかどうかを示します。他の多くの問題がシステムログに表示されます。
ホストで （at）sar のようなものを実行することはほぼ必須です。 CPU、ネットワーク、メモリ、およびディスクI/O（とりわけ）の履歴スナップショットを取得できることの有用性は、控えめに言っても過言ではありません。
過去24時間にホストが何をしていたかを調べ、問題が発生し始めた時期を確認することで、障害を診断できたことが何度もあります。
私が最初に行うことは、ディスク容量のチェックだと思います（他の人が言っているように）。簡単なチェックで「一般的な」問題が明らかにならない場合は、さらに調査します。
私がやりたいことの1つは、システムのスナップショットをキャプチャすることです。後でこれらをgrepして、目を引いたものを探すことができます。
lsof > /tmp/lsof.tmp &
ps auxfw > /tmp/ps.tmp &
netstat -anp > /tmp/netstat.tmp &
そこからトラブルシューティング101がありますが、保存されたログをgrepする方が少し速いことがわかりました。ログイン中に状態が解消された場合は、続行するか、変更を探す必要があります。
top df-hおよび常に/ var/logをチェックして、パーティションがいっぱいになっていないことを確認します。それは私に数回完全なメルトダウンを引き起こしました。
私が最初にチェックするのは「トップ」です（奇妙なプロセスがありますか？メモリやCPU時間を占有するプロセスがあります）。
何も表示されない場合は、「誰」をチェックして、何らかの理由で他の誰かが私のマシンにいるかどうかを確認します。
たぶん、ファイルシステムがマウント解除されました。 'cat/etc/mtab'、次に 'fstab'を呼び出して、起動時にすべてが正しく起動することを確認します。
稼働時間をチェックして、ボックスのユーザー数が妥当であることを確認してから（自分だけである必要があります）、var/log/auth.logをざっと見て、問題がないかどうかを確認します。
これらはキャッチオールです。ボックスがスローするエラーによっては、問題の原因となっている特定のプロセスを調べる必要がある場合があります。
df -ha
ハードドライブがいっぱいで、誰かが警告を受け取っていないかどうかを確認する
htopまたはtop
メモリとCPU使用率をチェックするために異常に高くはありません。
または、ボックスが応答しない場合は、vm-wareクライアントに移動し、そこからcpu/ramを確認します。