第3回では、シリアルコンソールを使えない場合の代替案である netconsole について紹介しました。今回は、 udplogger について紹介します。

udplogger は netconsole が送信したカーネルメッセージを受信するために作成されましたが、 syslog フォーマットに沿わないテキストメッセージを受信するためのプログラムとして利用することもできます。

bash は「 /dev/udp/IPアドレス/ポート番号」という構文を備えていますので、テキストメッセージを転送する用途で使用することができます。もし、 udplogger が待機しているIPアドレスが 192.168.0.1 でポート番号が 10000 の場合、以下のようにリダイレクト機能を用いて転送することが可能です。

$ while :; do date; sleep 1; done > /dev/udp/192.168.0.1/10000

もちろん、 date コマンドの出力に限らず、 UDP で転送できるサイズのメッセージであれば何にでも適用することができます。例えば、送信側のリソース使用状況を取得しながら予期せぬ再起動のような問題事象が発生するのを監視する場合を考えてみましょう。ローカルファイルとして書き出す方法で保存する場合、以下の選択肢のどちらにするかで悩むことになります。

1. 非同期書き込みで保存する場合、問題発生時にデータが失われてしまう可能性が高くなるが、普段の処理は高速にできる。
2. 同期書き込みで保存する場合、普段の処理は低速になるが、問題発生時にデータが失われる可能性を低くできる。
   
   もし、ローカルファイルとして書き出す代わりに udplogger に受信させるという方法を使える場合、以下のように選択肢が増えます。
   
   
3. 転送中のメッセージの欠落および受信側のクラッシュが発生した場合にはデータが失われてしまうが、送信側は普段の処理を高速にしながら、送信側の問題発生時にデータが失われる可能性も低くできる。

複数のコマンドを並行して実行することを仮定すると、各コマンドの出力が混在しないようにするための工夫が必要になります。ローカルファイルに書き出す場合、例えばプロセスIDをファイル名に含めるなどの方法で対応することになります。

$ bash -c 'command1 > /tmp/data.$$' &

$ bash -c 'command2 > /tmp/data.$$' &

$ bash -c 'command3 > /tmp/data.$$' &

udplogger に受信させる場合、送信元のIPアドレスとポート番号をログの中に含めてくれるため、送信側で対処しなくても、プロセスIDをファイル名に含めて区別するのと同様の結果が得られます。

$ bash -c 'command1 > /dev/udp/192.168.0.1/10000' &

$ bash -c 'command2 > /dev/udp/192.168.0.1/10000' &

$ bash -c 'command3 > /dev/udp/192.168.0.1/10000' &

udplogger が書きだすログファイルは、第1フィールドがメッセージを取り出した時刻（≒メッセージを受信した時刻≒メッセージが送信された時刻≒メッセージが出力された時刻）、第2フィールドがメッセージの送信元IPアドレスおよびポート番号、第3フィールド以降改行文字までがメッセージ1行分となっていますので、第2フィールドの値で振り分けを行うことで、特定の送信元からのメッセージだけを抽出することができるようになっています。

rsyslog に受信させる場合、 syslog 形式ではないメッセージを受信させるための %rawmsg% という指定と送信元のIPアドレスを記録させるための %fromhost-ip% という指定がありますが、送信元のポート番号を記録させるための指定が存在しません。そのため、送信側で区別できるように対処が必要になります。

udplogger であれば、送信側で特段の対処をすることなく、テキストメッセージを簡単に受信できることをご理解いただけましたでしょうか？

次回は、第2回から今回にかけて紹介した機能が活躍する SysRq について紹介します。

（半田哲夫）

コーヒーブレーク「サポートセンターの秘密」

サポートセンターに依頼をしてくる人で、回答を急いでいない人は基本的にいません（急いでいるのが自分だけだと思わないでくださいね）。回答に要する時間は、難易度など質問の内容によりますが、実はそれだけではなく、同じ質問であっても対応時間が大きく変わる場合があります。どうすれば少しでも早く回答をもらえるかは、読者の方にとって重要な関心事と思いますので、本コラムの中でもとりあげていきます。

さっそく門外不出の秘密の解説を・・・といきたいところですが、その前に準備が必要です。対応時間の短縮、効率化について説明するためには、サポートセンター内のプロセス（処理内容）の理解が前提となります。ところが、サポートセンターは、質問や依頼を入力すると結果が返ってくるブラックボックスであり、サポート業務を経験したことのない方には中の様子が想像しにくいでしょう。そこで最初に、サポートセンターとはどんなところなのか、から始めます。

サポートセンターの特徴として、以下があげられます。

• どんな依頼がくるか、内容や難易度は事前に知ることができず、予想もできない
• 依頼ごとに、対応に必要な時間は異なり、内容を確認するまでは予想できない
• そうした依頼を限られた人数で対応しなければならない

サポート技術者の人数を増やすほど、サポートセンターとして対応できる範囲は広がり、ひとりひとりの対応する時間や負担は減りますが、費用が増加し運用が苦しくなります。現実には、対応する範囲と契約数などを考慮して、体制を組み、その体制でやりくりするのが普通でしょう。

そんなサポートセンターで働くサポート技術者の仕事は、

• 案件のディスパッチを待つ
• 担当した案件について調査／検討を行い回答する

回答を早く得るということは、自分の依頼する内容の担当者へのディスパッチを最適化することに他なりません（オペレーティングシステムの知識を持たれる方であれば、スケジューラーのことを思い出されるかもしれません）。以上を前知識として、この後の回で具体的な最適化の手段（あるいは戦略）について取り上げていきたいと思います。

（原田季栄）

• Hinemos関連サービス
• Hinemos