現在地

第3回「 netconsole ノススメ」


第2回では、カーネルパニックまで至らない場合の情報取得方法として、シリアルコンソールを紹介しました。今回は、シリアルコンソールを使えない場合の代替案である netconsole について紹介します。

netconsole とは、カーネルが出力するメッセージを取得するための、比較的簡単な方法です。
信頼性という点ではシリアルコンソールの方が上であると考えられますが、 netconsole であれば、ホストへのログインが許可されていない仮想化環境のゲストや、シリアルコンソールの有効化/無効化のために再起動することが困難なサーバーでも使うことができます。また、ネットワークを介してログを送信するため、多数のサーバーのカーネルメッセージを1台で受信させたり、クラスタ構成の場合には相手方のサーバーを受信側に指定したりといった利用方法も可能です。

netconsole を使用する上での注意点としては、以下の点が挙げられます。

  1. 送信側のカーネルのバージョン
  2. 送信側が使用するネットワークインターフェース
  3. 受信側が使用するプログラム

1. 送信側のカーネルのバージョン

netconsole の送信側はカーネルモジュールの機能を使用するため、制約事項や不具合情報に注意が必要です。例えば、 RHEL 5 で、かつ bonding デバイスを使用している場合には、カーネル 2.6.18-238.el5 以降 (*1) が必要になるという制約事項があります。また、(遭遇事例を聞いたことはありませんが) RHEL 6 では、 vmxnet3 ドライバを使用している場合に競合状態が発生してカーネルパニックになる可能性があるという問題がカーネル 2.6.32-431.17.1.el6 で修正 (*2) されたとの不具合情報があります。

(*1) https://access.redhat.com/site/solutions/35174
(*2) https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.5_Technical_Notes/kernel.html の BZ#1083175 および BZ#1063271

2. 送信側が使用するネットワークインターフェース

再起動中などネットワークインターフェースが稼働していない状態のログを取得することはできません。また、 netconsole による送信は UDP を使用しているため、ネットワークの輻輳などによりメッセージの重複や欠落が発生する可能性があります。
可能であれば、通信トラフィックの少ない監視用インターフェースを利用するようにしましょう。

ハードウェアによっては、シリアルコンソールの出力を UDP パケットにして転送する機能を備えている場合があります。また、市販されているシリアルと Ethernet との間の変換を行う外付けアダプターを追加すれば、シリアルコンソールの出力を UDP パケットにして転送することも可能であると考えます。
この方法は、シリアルコンソールを利用することによる信頼性と、 UDP パケットとして扱うことによる利便性の両方を期待することができます。また、カーネルモジュールの機能を使用しないため、送信側の注意点を解決しやすくなることが期待できます。

3. 受信側が使用するプログラム

受信側では、メッセージを受信するためのプログラムを稼働させる必要があります。また、 UDP を使用した受信を行うため、大量のトラフィックが殺到した場合、バッファ不足などによりログの欠落が発生する可能性があります。

UDP を使用した受信ができるプログラムとしては netcat socat rsyslog などがありますが、ここでは netconsole のメッセージを受信するために作成された udplogger を紹介します。

udplogger は以下の特徴を備えています。

  1. タイムスタンプを付与して保存できるため、送信側がタイミング情報を付与する必要が無い。
  2. 送信元のIPアドレスとポート番号を付与して保存できるため、複数の送信元からのメッセージを受信する場合でも、プロセス1個で受信することができる。
  3. ログファイルは午前0時を境に自動的に切り換えられるため、ローテーションを行ったり古いファイルを削除したりするための中断が発生しないようにできる。
  4. 受信バッファのサイズを指定できるため、 SysRq-t のように大量のメッセージが殺到しても、取りこぼしが発生しにくい。
  5. 改行文字が届くのを待ってから保存するため、1行分のメッセージが複数回に分けて送信された場合でも、行単位で正しく保存できる。また、タイムアウト機能により、改行文字が届かなかった場合でも自動的に保存できる。
  6. C言語で記述された依存関係の少ないシンプルなプログラムであるため、リソース消費が少なく、他のパッケージのアップデートの影響を受けにくい。
  7. 受信専用のプログラムであるため、ファイアウォールで通過を許可する必要のある宛先ポート番号も1つで済む。

udplogger は http://sourceforge.jp/projects/akari/scm/svn/tree/head/branches/udplogger/ からダウンロードできます。次回は、この udplogger を活用する方法について紹介します。

(半田哲夫)

コーヒーブレーク「サポート担当者を困らせる50の方法」

サポートセンターにいると、しばしば、サポート担当者を困らせる依頼者を見かけることがあります。今回はよく見かけるパターンについてご紹介します。

「回答を信用しない依頼者」
サポート技術者も万能ではありません。わからないこともありますし、間違った判断をすることもあります。しかし、少なくとも「依頼者にとって最良と思う内容」を回答しているわけです。それに対して、「本当ですか?」と聞かれるとサポート担当者は困ります。
「自説を説明する依頼者」
発生している問題や不具合について、「これはおそらく・・・」とか「自分が思うには・・・」と自分の意見を書いてある依頼を見かけます。好意的に考えれば、サポート技術者に参考情報を提供していると考えられなくもありませんが、サポートセンターは依頼者の仮説を確認するところではありません。特に具体的な根拠や理由もなく「・・・という気がします」と言われても、何と答えて良いかサポート担当者は困ります。
「上から目線の依頼者」
サポート担当者は、依頼者を助けることを目的としています。つまり、依頼者の仲間であり味方です。そのサポート担当者に対して、上から目線や高圧的な調子で連絡をしてくる依頼者があります。問題を抱えて困っているから依頼してきているはずなのにどうしてこんな言い方になるのかなとサポート担当者は不思議に思い、困ります。

他にもまだまだありますが、きりがないのでこのくらいにしておこうと思います。でもご安心ください。サポート担当者は、どんな依頼に対しても自分達のできる最善を尽くします。それが私たちの仕事ですから。

(原田季栄)