クラッシュしたLinuxサーバーを保存する5つのステップ

多くのLinuxサーバーを見てきましたが、1回の再起動なしで何年も24時間365日動作していました。 しかし、ハードウェア、ソフトウェア、およびネットワークの障害につながる可能性のある驚きに対して安全なコンピューターは1つではありません。 最も信頼性の高いサーバーでさえ、いつかは故障する可能性があります。 どうする 今日は、問題の原因を見つけて車を修理に出すために、まず何をすべきかについて学びます。









ちなみに、障害の直後の最初の時点で、非常に重要な質問に答える価値があります。 問題の原因がまったくない可能性があります。 しかし、自分より先に進まないようにしましょう。

トラブルシューティング：前と今

1980年代に、Linus TorvaldsがLinuxの概念に着手するずっと前にUnixシステム管理者として働き始めたとき、サーバーに何か問題があれば、それは本当の待ち伏せでした。 その後、問題を見つけるためのツールが比較的少なかったため、障害が発生したサーバーが再び機能するためには、多くの時間がかかりました。



今、すべてが以前とは完全に異なっています。 かつて、あるシステム管理者が問題サーバーについて非常に真剣に話してくれました：「私はそれを破壊して新しいものを手に入れました。」



昔はこれは当たり前のように聞こえましたが、今日では、仮想マシンとコンテナに基づいてITインフラストラクチャが構築されると...結局、必要に応じて新しいサーバーを展開することは、クラウド環境では一般的です。



ここで、 ChefやPuppetなどのDevOpsツールを追加する必要があります。これを使用すると 、古いサーバーを診断および修復するよりも新しいサーバーを作成する方が簡単です。 また、Docker Swarm、Mesosphere、Kubernetesなどの高レベルツールについて説明すると、管理者が問題を発見する前に、障害のあるサーバーの機能が自動的に復元されます。



この概念は非常に広まったため、 サーバーレスコンピューティングという名前が与えられました。 このような機能を提供するプラットフォームには、 AWS Lambda 、 Iron.io 、 Google Cloud Functionsなどがあります。



このアプローチのおかげで、クラウドサービスはサーバー管理を担当し、スケーリングの問題や他の多くのタスクを解決して、アプリケーションを実行するために必要なコンピューティングパワーをクライアントに提供します。



サーバーレスコンピューティング、仮想マシン、コンテナ-これらの抽象化レベルはすべて、実サーバーをユーザーから、そしてある程度はシステム管理者から隠します。 ただし、これらはすべて物理ハードウェアとオペレーティングシステムに基づいています。 そして、このレベルの何かが突然うまくいかない場合、誰かがすべてを整理する必要があります。 ですから、今日私たちが話していることはその関連性を決して失わないのです。



あるシステムオペレータとの会話を覚えています。 クラッシュ後の対処方法について彼が言ったのは、次のとおりです。「サーバーを再インストールすることが道です。 だから理解していない-車に何が起こったのか、そしてこれが将来起こるのを防ぐ方法。 単一の適切な管理者がそれを行うわけではありません。」 私はそれに同意します。 問題の原因が発見されるまで、問題を解決したと見なすことはできません。



したがって、障害が発生したサーバーの前に、または少なくとも問題の原因がそこにあると考えられます。 一緒に5つのステップを実行することを提案します。そこから検索を開始し、問題を解決する価値があります。

最初のステップ。 ハードウェアチェック

まず第一に-ハードウェアを確認してください。 私はそれが些細で時代遅れに聞こえるかもしれませんが、とにかく-それをしてください。 椅子から出て、サーバーラックに移動し、サーバーが通常の操作に必要なものすべてに正しく接続されていることを確認します。



問題の原因を検索してケーブル接続につながった回数をカウントすることはできません。 LEDを見ると、イーサネットケーブルが引き抜かれているか、サーバーの電源がオフになっていることが明らかになります。



もちろん、すべてが多少まともに見える場合は、サーバーにアクセスせずにこのコマンドでイーサネット接続のステータスを確認できます。

$ sudo ethtool eth0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼女の答えが「はい」と解釈できる場合、これは調査中のインターフェイスがネットワーク上でデータを交換できることを意味します。



ただし、デバイスを個人的に検査する機会を無視しないでください。 これは、たとえば、誰かが重要なケーブルを抜いて、サーバーまたはラック全体の電源を切ったことを知るのに役立ちます。 はい、それは途方もなく簡単ですが、システム障害の原因がまさにこれであることが驚くべきことです。



もう1つの一般的なハードウェアの問題は肉眼では認識できません。 したがって、不良メモリはあらゆる種類の問題の原因です。



仮想マシンとコンテナはこれらの問題を隠すことができますが、特定の物理専用サーバーに関連する障害が自然に発生する場合は、そのメモリを確認してください。



メモリを含むコンピューターハードウェアのBIOS / UEFIレポートを表示するには、 dmidecodeコマンドを使用します 。

 $ sudo dmidecode --type memory
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここですべてが正常に見えても、実際にはそうではないかもしれません。 実際、SMBIOSデータは常に正確であるとは限りません。 したがって、 dmidecode



後でもメモリが疑わしい場合は、 Memtest86を使用します。 これは優れたメモリチェッカーですが、動作が遅いです。 サーバーで実行する場合は、チェックが完了するまで、このマシンを他の目的に使用できることを期待しないでください。



多くのメモリの問題に直面している場合-電源が不安定な場所でこれを見てきました-Linuxカーネルモジュールedac_coreをロードする必要があります。 このモジュールは、 不良セクションを探すためにメモリを常にチェックします 。 このモジュールをダウンロードするには、次のコマンドを使用します。

 $ sudo modprobe edac_core
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しばらく待って、次のコマンドを実行して何かが見えるかどうかを確認します。

 $ sudo grep "[0-9]" /sys/devices/system/edac/mc/mc*/csrow*/ch*_ce_count
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドは、メモリモジュール（名前がcsrow



始まるインジケーター）によって分類されたエラーの数の概要を表示します。 この情報を、メモリチャネル、スロット、コンポーネントのシリアル番号のdmidecode



データと比較すると、不良メモリバーを特定するのに役立ちます。

ステップ2 問題の真の原因を見つける

そのため、サーバーは奇妙な動作を開始しましたが、サーバーからの煙はまだ消えていません。 サーバービジネスですか？ 問題を解決する前に、まずその原因を正確に特定する必要があります。 たとえば、ユーザーがサーバーアプリケーションの奇妙さについて苦情を言う場合は、まず問題の原因がクライアントの障害ではないことを確認してください。



たとえば、ある友人が、IBM Tivoli Storage Managerを使用して作業できないとユーザーが言ったことを教えてくれました。 もちろん、最初はサーバーがすべての罪を犯しているように見えました。 しかし、最終的に、管理者は問題がサーバー部分にまったく関係ないことを発見しました。 その理由は、Windowsクライアント3076895のパッチの失敗です 。 しかし、このセキュリティ更新プログラムが失敗したため、発生したことがサーバー側の問題のように見えました。



また、サーバー自体またはサーバーアプリケーションが問題の原因であるかどうかを理解する必要があります。 たとえば、サーバープログラムはそのようなものを動作させることができ、ハードウェアは完璧な状態にあります。



手始めに-最も明白。 アプリは機能しますか？ これを確認するには多くの方法があります。 私のお気に入りの2つを次に示します。

 $ sudo ps -ef | grep apache2 $ sudo netstat -plunt | grep apache2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たとえば、Apache Webサーバーが機能していないことが判明した場合は、次のコマンドで起動できます。

 $ sudo service apache2 start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

簡単に言えば、サーバーを診断して問題の原因を探す前に、サーバーに問題があるのか​​、それとも何か他の問題があるのか​​を調べてください。 障害の原因がどこにあるかを正確に理解した場合にのみ、適切な質問をして、何が起こったのかをさらに分析することができます。



これは、予期しない車の停車と比較できます。 車はそれ以上進まないことがわかっていますが、サービスにドラッグする前に、タンク内にガスがあるかどうかを確認することをお勧めします。

ステップ3 topコマンドを使用する

したがって、すべてのパスがサーバーにつながることが判明した場合、システムをチェックするための別の重要なツール-topコマンドがあります。 サーバーの平均負荷の確認、ページングファイルの使用、プロセスが使用するシステムリソースの確認を行うことができます。 このユーティリティは、システムに関する一般情報を表示し、Linuxサーバーで実行中のすべてのプロセスに関するデータを表示します。 以下は、このコマンドが表示するデータの詳細な説明です。 ここでは、サーバーの問題を見つけるのに役立つ多くの情報を見つけることができます。 ここでは、問題領域を見つけるのに役立つtop



を操作する便利な方法をいくつか紹介します。



最もメモリを消費するプロセスを見つけるには、キーボードからM



入力して、プロセスのリストを対話的にソートする必要があります。 最もCPUリソースを消費するアプリケーションを見つけるには、 P



入力してリストをソートしますP



アクティビティ時間でプロセスをソートするには、キーボードからT



を入力します。 ソート用の列を見やすくするには、 b



押します。



さらに、チームが対話形式で表示するプロセスデータは、 O



またはo



入力してフィルタリングできます。 次のプロンプトが表示され、フィルターを追加するよう求められます。

 add filter #1 (ignoring case) as: [!]FLD?VAL
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、テンプレートを入力して、たとえば、特定のプロセスでフィルタリングできます。 たとえば、フィルターCOMMAND=apache



おかげで、プログラムはApacheプロセスに関する情報のみを表示します。



top



のもう1つの便利な機能は、プロセスのフルパスと起動引数を出力することです。 このデータを表示するには、 c



キーを使用します。



V



文字を入力すると、同様のtop



機能がアクティブになります。 プロセス情報の階層表示に切り替えることができます。



さらに、 u



キーまたはU



キーを使用して特定のユーザーのプロセスを表示したり、 i



キーを押してプロセッサーリソースを消費しないプロセスを非表示にしたりできます。



top



長い間、システムの現在の状況を表示するための最も人気のある対話型Linuxユーティリティですが、代替手段もあります。 たとえば、プログラムhtopには機能の拡張セットがあり、よりシンプルで便利なグラフィカルインターフェイスNcursesが異なります。 htop



を使用する場合、マウスを使用してプロセスのリストを垂直および水平にスクロールして、完全なリストと完全なコマンドラインを表示できます。



top



問題top



教えてくれるとは思わない。 むしろ、私はこのツールを使用して、「でもこれは面白い」と思うようになり、さらに研究するように促します。 top



からのデータに基づいて、たとえば、どのログが最初に見る価値があるかがわかります。 less



、 grep



tail -f



コマンドの組み合わせを使用してログを調べます。

4番目のステップ。 ディスク容量のチェック

今日でも、テラバイト単位の情報をポケットに入れて持ち運べると、サーバーはまったく気付かないうちにディスク容量を使い果たす可能性があります。 これが発生すると、非常に奇妙なことがわかります。



ディスク容量を処理するために、古くからあるdfコマンドが役に立ちます。このコマンドの名前は「disk filesystem」の略語です。 その助けを借りて、ディスク上の空き領域と使用済み領域の概要を取得できます。



通常、 df



2つの方法で使用されます。

•  $ sudo df -h
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  ハードディスク上のデータを認識に便利な形式で表示します。 たとえば、ドライブのボリュームに関する情報はギガバイト単位で表示され、正確なバイト数の形式ではありません。
  
  
  
  

•  $ sudo df -i
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  使用されているiノードの数とファイルシステムに対する割合を表示します。
  
  

もう1つの便利なdf — T



フラグdf — T



ファイルシステムストレージのタイプに関するデータを表示できます。 たとえば、 $ sudo df -hT



という形式のコマンドは、使用されているディスク容量とファイルシステム上のデータの両方を表示します。



奇妙に思われる場合は、 Iostatコマンドを使用してさらに掘り下げることができます。 これは、高度なシステム監視ツールキットであるsysstatの一部です。 プロセッサに関する情報と、パーティションおよびネットワークファイルシステムのブロックストレージデバイスのI / Oサブシステムのデータが表示されます。



おそらく、このコマンドを呼び出す最も便利な方法は次のとおりです。

 $ iostat -xz 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドは、デバイスの読み取りおよび書き込みデータのボリュームに関する情報を表示します。 さらに、平均I / O時間をミリ秒単位で表示します。 この値が高いほど、ドライブが要求で過負荷になっているか、ハードウェアの問題に直面している可能性が高くなります。 いったい何？ ここで、 top



ユーティリティを使用して、MySQLサーバー（またはその上で実行されている他のDBMS）がロードされているかどうかを確認できます。 そのようなアプリケーションが見つからなかった場合、ディスクに何か問題がある可能性があります。



もう1つの重要な指標は、 %util



セクションにあり、デバイスの使用状況に関する情報が表示されます。 このインジケータは、デバイスの動作の強さを示します。 60％を超える値は、ディスクサブシステムのパフォーマンスが低いことを示します。 値が100％に近い場合、これはドライブがその限界で動作していることを意味します。



ディスク検証ユーティリティを使用するときは、正確に分析していることに注意してください。



たとえば、複数の物理ディスクで構成される論理ドライブの100％の負荷は、システムが常に一部のI / O操作を処理していることを意味するだけです。 重要なのは、物理ディスクで何が起こるかです。 したがって、論理ドライブを分析している場合、ディスクユーティリティは有用な情報を提供しないことに注意してください。

ステップ5 ログを確認する

リストの最後に、重要度ではなく順番にのみログをチェックしています。 通常、これらは/var/log



さまざまなサービスの個別のフォルダーにあります。



Linuxの初心者にとって、ログファイルはひどいハッシュのように見えるかもしれません。 これらは、オペレーティングシステムとアプリケーションの動作に関する情報を記録するテキストファイルです。 エントリには2種類あります。 1つのレコードは、システムまたはプログラムで発生することです。たとえば、各トランザクションまたはデータの移動です。 2番目はエラーメッセージです。 ログファイルには両方を含めることができます。 これらのファイルは単純に巨大になる可能性があります。



通常、ログファイル内のデータは非常に不思議に見えますが、それを把握する必要があります。 たとえば、 ここでは、Digital Oceanからこのトピックを紹介しています。



ログを確認するのに役立つ多くのツールがあります。 たとえば、 dmesg 。 このユーティリティは、カーネルメッセージを表示します。 通常、それらは多数あるため、次の簡単なコマンドラインスクリプトを使用して、最後の10エントリを表示します。

 $ dmesg | tail
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

何が起こっているのかをリアルタイムで追跡したいですか？ 問題を探しているとき、私は間違いなくこれを必要とします。 これを実現するには、 -f



してtail



コマンドを使用しtail



。 次のようになります。

 $ dmesg | tail -f /var/log/syslog
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のコマンドはsyslog



ファイルを監視し、新しいイベントに関する情報を受け取ると、それらを画面に表示します。



別の便利なコマンドラインスクリプトを次に示します。

 $ sudo find /var/log -type f -mtime -1 -exec tail -Fn0 {} +
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ログをスキャンし、考えられる問題を示します。



systemdがシステムで使用されている場合、雑誌を操作するための組み込みツールJournalctlを使用する必要があります。 Systemdは、 journald



デーモンを使用してロギング管理を集中化します。 他のLinuxログとは異なり、 journald



はテキスト形式ではなくバイナリ形式でデータを保存します。



システムの再起動後、ログを保持するようにjournald



を構成すると便利です。 これを行うには、次のコマンドを使用します。

 $ sudo mkdir -p /var/log/journal
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エントリの永続的な保存を有効にするには、/ /etc/systemd/journald.conf



ファイルを編集して次を含める必要があります。

 [Journal] Storage=persistent
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのログを使用する最も一般的な方法は、次のコマンドを使用することです。

 journalctl -b
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後の再起動後、すべてのログエントリが表示されます。 システムがリブートされた場合、このコマンドを使用する前に何が起こったかを見ることができます：

 $ journalctl -b -1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、以前のサーバーセッションで作成されたログエントリを表示できます。

journalctl



使用方法に関する有用な資料を以下に示します。



ログは非常に大きいため、ログを扱うのは困難です。 したがって、コマンドラインツール（ grep



、 awk



など）を使用して対処できますが、ログを表示するための特別なプログラムを使用すると便利です。



たとえば、私はGraylogオープンソースログ管理システムが好きです。 彼女はさまざまな情報を収集、索引付け、分析します。 データを操作するためのMongoDBと 、ログファイルを検索するためのElasticsearchに基づいています。 Graylogは、サーバーの状態監視を簡素化します。 Graylogは、組み込みのLinuxツールと比較すると、よりシンプルで便利です。 さらに、その便利な機能の中でも、Chef、Puppet、 Ansibleなどの多くのDevOpsシステムで動作する機能に注目することができます。

まとめ

サーバーとの関係に関係なく、最も長く機能したサーバーとしてギネスブックに含まれない場合があります。 しかし、サーバーを可能な限り安定させ、問題の根底に到達してそれらを修正することは価値のある目標です。 本日お話ししたことが、この目標の達成に役立つことを願っています。



親愛なる読者！ また、クラッシュしたサーバーでは通常何をしますか？