| |
||||||||||||||||||||||||||||||||||||||||||||||||
| |
[解説] 管理しやすい警報メールとは (V5の場合)どこでメールの要素を定義するか。それが問題です。勉強をかねて考察してみましたが、まとめるほど複雑な情報量となりました。 なおV6以降の場合、アクションに障害・復旧の両方を定義できるのでずっと管理しやすくなりました。 アラートテンプレートでは、障害メールタイトル、障害メール本文、回復メールタイトル、回復メール本文が定義できます。（宛先も定義できますが、メール送信の効率的運用にそぐわないので省きます） アラートアクションでは、メール宛先、メールタイトル、メール本文を定義できます。 柔軟性は高いですが、理解しにくい点もあります。 まず最初に覚えておくことがあります。それは優先度です。 アラートアクションの障害通知と復旧通知で本文を定義し、アラートアクションでもメール本文を定義したとします。 この場合、障害通知にはアラートアクションのメール本文が使用されますが、復旧通知にはアラートテンプレートのメール本文が使用されます。 障害通知の場合 テンプレート定義＜アクション定義 復旧通知の場合 アクション定義＜テンプレート定義 あまりに面倒なので、図にしてみました。 テンプレート、アクション全てで値を設定した場合のメール文の生成のされかたです。  画面上部はアラートテンプレートの障害・復旧画面 画面下部はアラートアクションの設定画面 メール本文の定義の仕方 「柔軟性の高さは困りもの」 メールの文をどこで定義すべきか？ 組み合わせを検討したところ、およそ６４の組み合わせが考えられました。 その中から同じ効果になるもの、意味のないものを排除し、６つに絞りました。 最終的に、現実として運用できそうなものは３つになりました。
デフォルトの設定型 ・メールタイトルをアクションで定義 ・メール本文をアラートテンプレートで定義  結果 ・警告アラートでも障害アラートでも同じタイトルとなる ・メール本文の中で警告、障害の種類を記載しておく必要がある ・回復メールは回復用のタイトルにできる ・ログ出力アクションなどでも（多少）再利用しやすい アラートテンプレート集約型 ・メールタイトル、本文をアラートテンプレートで定義 ・アラートアクションのメールタイトル、メール本文は空白  結果 ・警告アラート、障害アラートで異なるメールタイトルを定義できる ・設定情報がわかりやすい ・どのメール送信先にも同じメールタイトル・文で送信できる ・回復メールは回復用のタイトルにできる ・新たにアラートテンプレートを追加したら、忘れずメールタイトルと本文を記述する。 ・警報メールの形式を、送信先アドレスによって変化させたい場合には向かない ・メール向けに構成されているので、ログ出力などに同じアラートテンプレートを使うのは限界がある アラートアクション集約型 ・メールタイトルをアラートテンプレートで、本文をアラートアクションで定義 ・アラートテンプレートの本文は空白、アラートアクションのタイトルは空白  結果 ・警告アラート、障害アラートで異なるメールタイトルを定義できる ・どのアラートテンプレートからの呼び出しでも、同じメール文で送信される ・回復メールは回復用のタイトルにできる ・回復メールの本文の冒頭に[RECOVER]という言葉が加えられる ・多数のアラートテンプレートでいちいちメール文を定義したくない場合に適している ・監視方法によって警報メールの形式を変化させたい場合は向かない ・他の監視ソフトウェアでも多く持ちいられている構成 アラートアクションに設定を集約した設定 最後に、アクション型の設定手順を記しておきます。 メンドクサイ監視はしない。メール本文は常に一定でいい。本文設定は一か所に集約。 複雑な通報をしない方にお勧めです。
障害メール変更後 （アラートテンプレート・ステップ２）  アラートテンプレートの「障害通知」「拡張フィールド管理」を開き、フィールド２へ障害メールタイトルを記載します。本文に相当するフィールド３は空白とします。（記載されていても構いません） 回復メール変更後 （アラートテンプレート・ステップ３）  アラートテンプレートのステップ３・復旧通知でも、フィールド２に回復メールのタイトルを記載します。 本文に相当するフィールド３を空白とします。 メール本文 （アラートアクション）  アラートアクションで、メールタイトルのフィールド２を空白とします。 フィールド３にメール本文を定義します。 このとき、メール本文の一行目に空改行を入れておきます。 これは回復のときに、自動で[RECOVER]という文章が一行目に追加されるからです。 メールタイトルに監視システムのユニークなキーワードを入れておくと、メール受信後のメール振り分けが 楽になります。 ここでは [BIZ-System] というキーワードを入れてみました。 これにより、障害メールの内容は以下のようになります。
これでタイトルだけでサーバトラブルとわかり、メール本文でWebSv02というサーバ上のHTTPモジュールで障害が起きたと判断できます。 メールにCurrent valueが含まれているので、メモリ使用率上昇の警告でも数値把握できます。 アラートアクションの設定でメール本文を定義すると、回復メールが発生したときは自動で[RECOVER]という文字列が一行目に挿入されます。 仕様のようです。 設定の確認 設定の時期が異なると、いろんな設定のアラートが混在してしまうかもしれません。 具体的にはアラートメールの送信設定（正確には「アクションの引数」）がどこで指定されているか、わからなくなるかもしれません。 その場合、アラートの引数がどこで設定されているかの確認画面があります。 操作メニューの[アラート管理]をクリックすると、アラート一覧が表示されます。 アラート登録の右にある目のマークをクリックして、詳細が表示できます。  アクションを選択すると、そのアクションの引数がどこから受けているかが表示されます。  設定の考察 ・メールタイトルにアラートレベル（障害や警告）を含まず、「Alert from _agent」等で統一できるなら、デフォルト型の構成も悪くない。 ・メールの文内に、アラートレベルによって自動で「障害」や「警告」などの文字を埋め込むことはできません。 アラートレベルを表す変数「_alert_priority_」は、アラートレベルを数値で表現します。 ・監視に、アラートのSyslog出力やSNS送信など、メール通報以外のニーズがあるかを検討する。ニーズがあればデフォルト型を検討し、Syslog出力の監視項目が多ければアラートテンプレートを複数構成する。 以下、状況別に考えてみました。 ・メールタイトルにアラートレベルを含める必要がない 警報メールを全て「障害レベル」で通報するなら、レベル分けは不要でしょう。 （全てのL2スイッチノードの死活を監視するだけ、等） この場合、メールタイトルをアラートアクションで定義しても問題ありません。 しかしウェブサーバのダウンは障害、CPU負荷上昇は警告でアラートを発生させるなら、メールタイトルにレベルが含まれているほうが便利です。 この場合はメールタイトルをアラートテンプレートで定義します。 ・複数のアラートテンプレートがあっても、メール本文は一か所で統一しておきたい アラートテンプレートでタイトルを設定し、アクションでメール本文を定義します。 通常、どんな障害が発生しても定型のメール文であることが多いです。 監視システムごとにメール定型自体変えてしまうのは、よほど必要性に迫られたときくらいでしょう。 つまり、大規模か複雑システムです。 あるいは監視体制が複数のチームに分かれている場合でしょう。 ・メール送信先は複数使い分ける必要があるか システム障害の種類によって、アラートメールを受け取る担当者が異なるか、です。 例えば各地域に支社が１０あり、各支社ビル内のネットワークスイッチを監視しているとします。 各支社ビルの障害は、各支社のチームへメール通報するとします。 チームが１０あるのですから、メールアクションを送信先別に１０個定義します。 監視しているスイッチのIPが異なるだけで、送信するメールの文面は同一でしょう。 であるなら１０のメールアクションひとつひとつにメールタイトル、メール本文を定義するのは手間です。 アラートテンプレートでメールタイトル、本文を定義し、メールを呼び分けるのが効果的です。 ・アラート発生条件が異なる監視項目が多数ある。 「監視対象の監視除外時間が異なる」 休日は監視しないシステム、夜間は監視しないシステム、定期的な再起動を行うシステム。 「最小アラーム数が異なる」 一度でもTCPの応答がないと障害発生、5分以上応答が無ければ障害発生のシステム 「監視システムによって通報メールに含む項目が異なる」 このようにアラートテンプレートが多数ある場合は、テンプレートの作成のたびに情報を定義するのは面倒です。メール本文をアクションで定義したほうが、運用のミスが少ないと思われます。 逆に、一つでしか使用されないテンプレートが多いなら、定義をテンプレート内に設定し、情報が定義されていないメールアクションを用意するなど、ハイブリッドな構成が効率的なこともあるでしょう。 |
|
||||||||||||||||||||||||||||||||||||||||||||||
 |