メール以外の通信手段を持たない機器は、驚くほど多くあります。バックアップ装置、ネットワーク監視システム、ビル管理システム、プリンター、産業用コントローラー、古い計測機器などです。設計当時に利用できる連携方法がSMTPだったため、今もメールでアラートを送ります。デバイスごとにメールボックスを用意すれば、この不便な仕様を管理しやすい仕組みに変えられます。
多くの現場では、すべての機器から1つの共有アドレスへ送っています。40台のうち、どの機器が異常を訴えているのか調べる必要が生じるまでは、それでも機能します。
1つの共有アドレスでは対応できない理由
すべての通知をalerts@に集めるのは分かりやすい方法ですが、運用を続けるうちに必ず無理が生じます。
メーカーごとに書式が異なるため、件名も送信者名も統一されません。後から分類するには、各機器が出力する文面に合わせてルールを作る必要があります。ファームウェアの更新で予告なく表現が変わると、そのルールは動かなくなります。
メールの量が増えると、問題はさらに深刻になります。状態が頻繁に切り替わる監視機器や、失敗した処理を繰り返す装置など、通知の多い機器が1台あるだけで数百通のメールが発生し、ほかの通知が埋もれます。共有アドレスでは、すべての機器を受け付けるルールを止めずに、1つの送信元だけを無効にすることはできません。
どの機器から届いたのかも分かりにくくなります。デバイスごとにメールボックスがあれば、本文を読む前からアドレス自体で送信元を特定できます。
推測に頼らない振り分け
デバイスごとにメールボックスを設ける主な利点は、文面の解釈ではなく、構成そのものに基づいて振り分けられることです。
解析せずに識別。ups-basement@に届いたメールは、地下室のUPSからの通知です。ルールも件名の照合も不要で、メーカーがテンプレートを変更しても迷いません。
個別の処理。それぞれに専用の宛先があるため、ほかに影響を与えず、1台だけ通知を止めたり、頻度を制限したり、無視したりできます。
撤去時の処理も簡単。機器を廃止するときは、メールボックスを1つ削除するだけです。フィルターを変更し、ほかに依存しているものがないか心配する必要はありません。
送信元ごとの自動処理。1台の機器専用のメールボックスを読むスクリプトなら、届く書式があらかじめ分かります。複数の形式が混ざったメールを解析するより、はるかに確実です。この構成は、メールによるデータ取り込みで紹介しています。
費用について
デバイスごとのメールボックスが現実的なのは、ユーザー単位で課金されない場合だけです。この方法があまり使われないのも、それが理由です。
1ユーザーあたり$7なら、40台の機器からアラートを受け取るだけで年間$3,360かかります。これを承認する合理的な担当者はいないでしょう。プランごとに数の上限を設ける料金体系なら、40個のデバイス用メールボックスを作っても、契約中のプランを超える費用はかかりません。Proはドメインごとに300個、Agencyは1,000個まで利用できます。
ただし、共有ストレージは消費します。機器は休まず送信するため、通知メールも増え続けます。デバイス用メールボックスごとの容量制限と保存ルールは、任意ではなく必須です。その理由は、メールボックスのストレージ容量制限で説明しています。
多くの場合はエイリアスで十分
率直に言えば、多くの現場で適切なのはデバイスごとのメールボックスではなく、デバイスごとのエイリアスです。
各デバイスのメールを個別に処理する仕組みがなく、送信元を識別したいだけなら、エイリアスで目的を達成できます。個別のメールボックスを管理する必要も、それぞれの保存領域が増え続ける心配もありません。すべて同じ場所に届きますが、宛先アドレスを見れば送信元を確認できます。
デバイスごとのメールを個別に処理する場合、デバイスを担当するチームが異なり、ほかのチームのアラートを見せるべきでない場合、デバイスによって保存期間が異なる場合は、実際のメールボックスを選びます。1人がすべてを読み、何が何を送ったか分かればよい場合は、エイリアスが適しています。
メールボックスごとに利用できるエイリアスは、Starterで30個、Proで50個、Agencyで100個です。多くの設備群はこの範囲に収まり、メールボックスを大量に増やす必要がありません。
機器側の設定
デバイスごとのメールボックスで実際に手間がかかるのは機器側です。導入を決める前に把握しておきましょう。
メーカーによって、現在のSMTPサブミッションにどこまで対応しているかは大きく異なります。作業量を左右するのは、所有する機器の古さです。過去5年以内に購入した機器なら、ほとんどがそのまま動きます。20年前のビル管理システムでは、そうはいきません。その場合、後述するリレーを使うのは標準的な対応であり、珍しいことではありません。
古い機器は、RFC 6409で定義された認証付きSMTPサブミッションではなく、ポート25の認証なしSMTPしか使えないことがよくあります。すでに廃止された認証方式しか使えない機器や、TLSにまったく対応していない機器もあります。こうした機器は、現在のメールサービスへ直接送信できません。通常はローカルネットワーク上にリレーを設置し、機器から認証なしで受け取ったメールを、正しく認証して転送します。
現在の送信方式に対応する機器には、共通の認証情報ではなく、1台ずつ専用の認証情報を発行してください。完全には信頼できないネットワーク区画の機器に共有の認証情報を持たせるのは危険です。個別にすればリスクをなくせるうえ、1台のパスワードを変更してもほかには影響しません。
各機器の動作確認では、内蔵のテストボタンだけでなく、実際のアラートを発生させてください。メーカーのテストメールは、本物の通知とは異なるコード経路を通ることが多く、実際のアラートが失敗していてもテストだけは成功する場合があります。
設備全体を把握しやすくする命名方法
アドレスが唯一のラベルになるため、一覧を参照しなくても、設置場所と機器の種類が分かる名前にする必要があります。
ups-basement@やnas-office2@なら2年後に見ても意味が分かりますが、device7@では分かりません。すでに資産台帳があるなら、新しい命名体系を作るより、その識別番号を再利用してください。並行して別の方式を作っても、1年以内に台帳との対応がずれてしまいます。
届いた通知をどう扱うか
デバイスごとのメールボックスは、届いた通知に対して何らかの対応が行われて初めて役立ちます。誰も開かないメールボックスが並ぶだけでは失敗です。
デバイスごとに、人がアラートを読むのか、スクリプトが処理するのか、問題発生時に履歴を確認できるよう記録として保存するだけなのかを決めます。3つとも正しい選択です。決めないまま放置することだけは避けてください。未読の機器メールは、監視できているという誤った安心感を生みます。
本当に緊急な事象に、メールは適切な連絡手段ではありません。誰かを起こして対応させる必要がある機器は、オンコール担当者への緊急通知システムにつなぐべきです。メールボックスはアラームを伝える役割ではなく、記録を残す役割にします。
