手つかずのUNIXサーバーが暴走し始めたときに最初に確認することは何ですか?


10

したがって、このきちんとセットアップされたUNIXサーバーを使用すると、超高速で正常に動作し、数か月間すべてが素晴らしい状態になり、突然、あらゆる種類の奇妙なエラーがさまざまな異なるサービスで発生し始め、それ自体ではあまり意味がありません。 、一緒にはるかに少ない。

マシンへのsshセッションを取得したらすぐに確認すべき安価なものは何ですか?

私は特に、明白ではないコマンドやまれな状況を強調するトラウマストーリーに興味がありますが、明白なことは人によって異なるため、自由にリストアップすることができます。

回答:


19

ファーストオーダー:応答性がありますか?

ログインできない場合は、さらに大きな問題が発生しています。これには通常、ハードウェア障害とソフトウェア障害の2つの種類があります。どちらも壊滅的な可能性があります。DFAエラーを防ぐには、最初に一般的なハードウェアの状態を確認します。通常は、簡単な一見だけで十分です。

2次:システムの基礎となる構造は、正常で正常ですか?

システムの「ゴールデントライアド」を確認します。

  • 十分なCPU時間が処理のために空いている
  • ストレージ用に十分なディスク領域が空いている
  • ワークロードに十分なメモリが解放されている

過去数十年で、トライアドは通信(ネットワーク)を含む「クワッド」に拡大しました。

  • 接続は機能的で応答性が高く、容量があります

3次:問題の重大度は?

どのプログラムまたはサービスが影響を受けますか?重大度の降順で、それは全身的(システム全体)、クラスター化(プログラムのグループ)、または分離(特定のプログラム)ですか?特定の基になるサービスが失敗したか、応答しなくなったため、プログラムのクラスターは通常、作動しています。体系的な問題はこれに関連している場合があります(DNSまたはIPの競合を考えてください)が、通常はどこを見るかを知ることが重要です。

4次:診断ツールは問題に関連する有用なデータを提供していますか? システムの状態(2次)と問題が発生している部分(3次)についての情報が得られたので、問題の場所を簡単に絞り込むことができます。

エラーメッセージまたはログファイルは、この旅における一般的なウェイポイントである必要があります。

CPUの問題:

  • loadav
  • strace

ディスク容量/ IOの問題:

  • df
  • du
  • lsof
  • iostat
  • vmstat

メモリの問題:

  • 自由

接続の問題:

  • ping
  • ルート(およびarpとrarpとその仲間)
  • iptables、ipchains、ipfw(これらのBSD関係者向け)
  • tracerouteまたはmtr
  • hosts、nslookup、またはdig
  • netstat

(私が聞いた)最も一般的な不満

メールが十分に速く配信されていない(送信から受信者が受信するまでに1分以上)、またはメールが送信を拒否しています。これは通常、スパムストーム中にキックインするPostfixのレートリミッターに帰着します。これは、内部配信を受け入れる機能に影響を与えます。

実際の例:

ただし、これは常に当てはまるわけではありません。かつては、サービスの再起動に関係なく問題が解決しませんでした。だから3分後には周りを見回す時間でした。CPUはビジーでしたが100%未満でしたが、2コアのボックスで負荷が15に急上昇し、さらに高くなると脅迫されていました。topコマンドは、メールシステムがメールスキャナーと共にオーバードライブ状態にあることを明らかにしましたが、表示されるamavis子プロセスはありませんでした。それが手がかりでした-メールキューコマンド(mailq)は、150以上の未配信メッセージを表示し、その80%以上がスパムでした、過去20分間。子メールスキャナープロセスの数を増やしながら(バックログを処理するために)レートリミッターを下げ(スパムストームの取り込み率を下げました)、その後サービスを再起動して、問題を解決し、システムは問題なく解決しました短納期でお届けします。

この問題の原因は、amavis親プロセスが死んでしまったことと、子プロセスが最終的にすべてのコースを実行したことです(メモリリークを防ぐために、非常に多くのスキャンの後に自己終了します)。したがって、必要なスパム/ウイルススキャンを実行するために...薄層...に接続しようとするSMTPプロセスがpostfixにありました。私が使用していたディストリビューションには、決してアップデートされない古いパッケージがありました。インストールは1年ほどで置き換えられる予定だったため、いくつかのバグ修正を含む最新バージョンに手動で「上書き」しました。それ以来、私は同じ問題を抱えていません。


5

通常は「誰」の後に「最後」が続く

私が何年にもわたって管理してきたマシンの問題の山は、「手つかず」の非常に緩い定義が原因でした-誰かが何かをしたことがよくあります:)


4

さて、始めましょう。

これは私を一度噛み締め、何千ものさまざまなことを試したり、あちこちでサービスを無効にしたり、再起動したりするなど、何時間も費やしました。問題は何でしたか?完全にディスク容量が不足しています。

したがって、突然問題が発生したサーバーをデバッグするときに最初に入力するのは次のとおりです。

df -h

今は決して忘れません。それは私に多くの無駄な努力を救いました。共有したいと思いました。




1

エラーがないかdmesgを確認します。通常はで始めdmesg | tailます。これは、まだ問題が発生している可能性があり、サーバーはエラーの原因を何でもしようとしているためです。


0

最初にチェックするのは「トップ」です(奇妙なプロセスがあります。メモリまたはCPU時間を占有するプロセスです)。

そこに何も表示されない場合は、「誰か」をチェックして、何らかの理由で誰かが私のマシンにいるかどうかを確認します。

ファイルシステムがマウント解除されたのかもしれません。「cat / etc / mtab」を呼び出してから「fstab」を呼び出して、起動時にすべてが正しく起動することを確認してください。

稼働時間をチェックして、ボックスのユーザー数が妥当であることを確認し(あなただけである必要があります)、var / log / auth.logを調べて、そこに問題がないかどうかを確認します。

これらは包括的なものです。ボックスがスローしているエラーによっては、問題の原因となっている特定のプロセスを調べる必要がある場合があります。


0

top df -hは常に/ var / logをチェックして、パーティションがいっぱいになっていないことを確認します。それは私に数回完全に溶けてしまいました。


0

df -ha

ハードドライブがいっぱいで、誰かが警告を受けていないかどうかを確認する

htopまたはtop

メモリとCPUの使用率が異常に高くないことを確認します。

または、ボックスが応答しない場合は、vm-wareクライアントに移動して、そこからcpu / ramを確認します。


0

ホストで(at)sarなどを実行することはほぼ必須です。CPU、ネットワーク、メモリ、およびディスクI / Oの履歴スナップショットを取得できることの有用性は、(特に)控えめに言っても過言ではありません。

ホストが過去24時間に何をしていたかを調査し、問題が発生し始めた時期を確認することで、障害を診断することが何度もありました。


0

Linuxでは、通常、dmesgと/ var / log / messagesまたは/ var / log / syslogを確認します。dmesgは、それが突然のハードウェア障害であるかどうかを示します。他の多くの問題がシステムログに表示されます。


0

私が最初に行うことは、(他の人が述べたように)ディスク容量のチェックだと思います。単純なチェックで「一般的な」問題が明らかにならない場合は、さらに調査します。

私がやりたいことの1つは、システムのスナップショットをキャプチャすることです。これらを後でgrepして、私の目を引いたものを探すことができます。

lsof > /tmp/lsof.tmp &
ps auxfw > /tmp/ps.tmp &
netstat -anp > /tmp/netstat.tmp &

そこから101のトラブルシューティングですが、保存されたログをgrepする方が少し高速であることがわかります。ログイン中に状態がクリアされた場合は、続行するか、変更を探す必要があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.