5 STA のアラート

STA のアラート機能は、ユーザー定義のアラートポリシーに基づいてテープライブラリシステムでのイベントと状況を通知します。必要な数のアラートポリシーを作成できます。アラートポリシーは、アラートを送信する条件とイベントのタイプ、およびアラートが生成される頻度を識別します。オプションで、指定した電子メールアドレスにアラートを送信することを指定できます。

この章では、次のトピックについて説明します。

• 警告の動作方法

• アラート管理のユーザーの役割

• アラートポリシーの定義に関する詳細

• アラート電子メール

• アラートワークフロー

• アラート管理タスク

警告の動作方法

STA のアラートプロセスは、次の部分で構成されています。

• アラートポリシーの定義

• アラートの生成

• 生成されたアラートのモニタリング

アラートポリシーの定義

管理者権限を持つユーザーは、「Setup & Administration」タブの「Alerts Policies」画面からこの部分のプロセスを実行します。

アラートポリシーの作成時に、即時に有効にすることも、しばらくの間無効のままにすることもできます。さらに、いくつかのサンプルアラートポリシーが STA で提供されており、デフォルトで無効になっています (詳細は、STA のサンプルのアラートポリシーを参照してください)。有効になったアラートポリシーのみがアラートの生成に使用されます。

アラートポリシーを定義するには、次の情報を指定します。

• ポリシー名 – ポリシーの英数字の識別子。ポリシー名は一意である必要があります。

• ポリシーの説明 – ポリシーのオプションの説明。

• エンティティータイプ – エンティティーは、テープライブラリシステムのリソースまたはイベントです。アラートポリシーによって評価するエンティティーのタイプを指定する必要があります。オプションには、ライブラリ、ドライブ、メディア、交換、およびメディア検証が含まれます。完全なリストについては、アラートポリシーエンティティーを参照してください。

• 重要度 – このポリシーによって定義された条件が満たされるたびにアラートを生成する頻度を決定します。詳細は、アラートポリシーの重要度を参照してください。

• アラートの条件 – 該当するライブラリシステムのリソースを評価するユーザー定義の条件。アラート条件は、STA フィルタリング機能とほとんど同じ方法で機能します。詳細は、「Filter Data」ダイアログボックスを参照してください。

• 電子メール受信者 – ポリシーによってアラートが生成されるたびに電子メールを受信する電子メールアドレスのオプションのリスト。詳細は、アラート電子メールを参照してください。

アラートの生成

この部分のプロセスは、STA によって自動的に行われます。

STA は、有効になったアラートポリシーをバックグラウンドで連続的に評価します。特に、次のタイプのアクティビティーが発生するたびに、アラートポリシーが評価されます。

• 有効になったアラートポリシーが何らかの形で作成または変更される。

• ドライブ/メディアの交換が発生する。

• メディア検証の交換が発生する。

• モニター対象ライブラリから SNMP トラップを受信する。

• ライブラリデータの収集が発生する。

• STA アプリケーションまたはサーバーのイベントが発生する。

STA が、アラートポリシーの条件と重要度に基づいてアラートを生成する。ポリシーの条件が一致し、同じライブラリリソースとイベントの最後のアラートから十分な時間が経過した場合、新しいアラートが生成されます。期間は、ポリシーの重要度によって決まります。詳細は、アラートポリシーの重要度を参照してください。

アラートポリシーに電子メールアドレスが含まれている場合、アラートに関する詳細が含まれている電子メールが指定のアドレスに送信されます。詳細は、アラート電子メールを参照してください。

アラートポリシーの評価プロセスの詳細は、アラートポリシーの重要度の例を参照してください。

生成されたアラートのモニタリング

すべての STA ユーザーが、「Alerts Overview」画面の「Tape System Activity」タブからこの部分のプロセスを実行できます。

画面には、生成されたアラートのリストが表示され、ニーズに合わせてこのリストをソート、フィルタ、エクスポート、および印刷できます。オペレータ権限を持つユーザーは、選択したアラートに注釈を付けることもできます。

サイトでアラートワークフローを使用している場合、選択したアラートの状態を更新して、現在の進捗を反映させることができます。アラートワークフロー管理は、オプションの手動プロセスです。詳細は、アラートワークフローを参照してください。

アラート管理のユーザーの役割

表 5-1 にそれぞれの STA ユーザーの役割で使用可能なアラートポリシー定義アクティビティーのサマリーを示します。

表 5-1 アラートポリシーのユーザーの役割

ユーザーの役割	アラートポリシーのアクティビティー	画面
オペレータ以上	定義済みのアラートポリシーのリストを表示、フィルタ、および出力します。	「Setup & Administration」 > 「Alerts Policies」
管理者のみ	アラートポリシーを定義します。 アラートポリシーをコピーします。 ポリシーの名前を変更します。 ポリシーの条件を変更します。 電子メール受信者のリストを変更します。 アラートポリシーを有効または無効にします。 アラートポリシーを削除します。	「Setup & Administration」 > 「Alerts Policies」

表 5-2 にそれぞれの STA ユーザーの役割で使用可能なアラートモニタリングアクティビティーのサマリーを示します。

表 5-2 アラートのモニタリングのユーザーの役割

ユーザーの役割	アラートのモニタリングアクティビティー	画面
ビューア以上	生成されるすべてのアラートのリストを表示、フィルタ、および出力します。 アラートリストをスプレッドシートまたはドキュメントにエクスポートします。選択したアラートの詳細を表示します。 選択したアラートの状態を変更します。 消去したアラートを表示するか非表示にします。	「Tape System Activity」 > 「Alerts Overview」
オペレータ以上	アラートに注釈を付けます。	「Tape System Activity」 > 「Alerts Overview」

アラートポリシーの定義に関する詳細

このセクションでは、アラートポリシーの作成時に役立つ追加の詳細を示します。次の情報が含まれています。

• アラートポリシーエンティティー

• アラートポリシーの重要度

• アラートポリシーのベストプラクティス

• STA のサンプルのアラートポリシー

アラートポリシーエンティティー

次のタイプのエンティティー、またはテープライブラリシステムのリソースまたはイベントについてアラートポリシーを定義できます。

• ライブラリコンプレックス

• ライブラリ

• ドライブ

• メディア

• ロボット

• CAP

• PTP – SL8500 ライブラリにのみ関連します。

• エレベータ – SL8500 ライブラリにのみ関連します。

• 交換 – 交換のアラートポリシーがほかのポリシータイプとどのように異なる方法で処理されるのかに関する詳細は、アラートポリシーの重要度を参照してください。

• メディア検証 – メディア検証が STA で有効になっている場合にのみ適用されます。アラートは、中間結果ではなく最終検証結果によってのみ呼び出されます。詳細は、STA メディア検証を参照してください。

• STA アプリケーション自体 – STA アプリケーションの再起動のたびに通知を受け取るため。

アラートポリシーの重要度

ポリシーの重要度は、アラートがポリシーから生成される頻度を決定します。重要度レベルは次のとおりです。

• 重大 – アラートは 1 時間に 1 回生成される可能性があります。

• 警告 – アラートは 24 時間ごとに 1 回生成される可能性があります。

• 情報 – 1 つのアラートのみが生成されます。ポリシーの条件を引き続き満たしている場合でも、追加のアラートは生成されません。

割り当てられる重要度レベルの影響を詳細に説明した例については、アラートポリシーの重要度の例を参照してください。

交換およびメディア検証アクティビティーのアラートポリシーと重要度

交換とメディア検証は持続リソースではなく別個のイベントであるため、時間の枠に関係なく、新しい交換または検証が処理され、ポリシーの条件が一致するたびに、交換とメディア検証のアラートポリシーがアラートを生成します。そのため、これらのアラートポリシーに割り当てる重要度レベルは無関係です。詳細は、次の例 4 と例 5 を参照してください。

さらに、交換とメディア検証のアラートポリシーでは、同じ交換または検証から複数のアラートを生成する可能性がある、重なり合うポリシーを作成しないように注意する必要があります。詳細は、多すぎるアラートの回避を参照してください。

アラートポリシーの重要度の例

次の例は、特定のポリシーの条件と重要度に基づいてアラートを生成する方法とその時期を示しています。これらの例は、ポリシーの重要度レベルがアラート生成の頻度にどのように影響を与えるかを示しています。この情報を使用すると、アラートポリシーに割り当てる重要度レベルを決定できます。

• 0 ドライブの「警告」ポリシー

• 例 1 ドライブの「情報」ポリシー

• 例 2 メディアの「重大」ポリシー

• 例 3 CAP の「重大」ポリシー

• 例 4 「Media Health Indicator」を使用した交換のポリシー

• 例 5 「Media Health Indicator」を使用したメディアの「警告」ポリシー

例 1   ドライブの「警告」ポリシー

このポリシーは、ドライブに「ACTION」または「EVALUATE」の健全性があるために注意を必要とする、ドライブのアラートを生成します。

ポリシーエンティティー: ドライブ

ポリシーの重要度: 警告 – アラートは 24 時間ごとに生成される可能性があります。

ポリシーの条件: 「Drive Health Indicator」が「ACTION」であるか、「Drive Health Indicator」が「EVALUATE」です。

時間	イベント	評価	結果
1 日目、05:00:17	ポリシーが作成され、有効にされます。 ドライブ 1 の健全性は「EVALUATE」です。 ドライブ 2 の健全性は「MONITOR」です。	ポリシーはすべてのドライブについて評価され、ドライブ 2 ではなくドライブ 1 について照合されます。	ドライブ 1 のアラートが生成され、電子メールが定義済みの受信者に送信されます。 ドライブ 2 のアラートはありません。
1 日目、08:12:24	ドライブ 1 の健全性は「ACTION」になります。 ドライブ 2 の健全性はまだ「MONITOR」です。	ポリシーはすべてのドライブについて評価され、ドライブ 2 ではなくドライブ 1 について照合されます。	ドライブ 1 の最後のアラートから 24 時間経過していないため、新しいアラートは生成されません。 ドライブ 2 のアラートはありません。
1 日目、13:37:01	ドライブ 1 の健全性はまだ「ACTION」です。 ドライブ 2 の健全性は「EVALUATE」になります。	ポリシーはすべてのドライブについて評価され、ドライブ 1 とドライブ 2 の両方について照合されます。	ドライブ 1 のアラートはありません。 ドライブ 2 のアラートが生成され、電子メールが定義済みの受信者に送信されます。
2 日目、05:01:03	ドライブ 1 の健全性はまだ「ACTION」です。 ドライブ 2 の健全性はまだ「EVALUATE」です。	ポリシーはすべてのドライブについて評価され、ドライブ 1 とドライブ 2 の両方について照合されます。	ドライブ 1 の前のアラートから 24 時間以上経過しているため、新しいアラートが生成され、電子メールが定義済みの受信者に送信されます。 ドライブ 2 の最後のアラートから 24 時間経過していないため、ドライブ 2 の新しいアラートはありません。
2 日目、17:08:43	新しい電子メール受信者がポリシーに追加されます。 ドライブ 1 の健全性はまだ「ACTION」です。 ドライブ 2 の健全性はまだ「EVALUATE」です。	ポリシーはすべてのドライブについて評価され、ドライブ 1 とドライブ 2 の両方について照合されます。	ドライブ 1 の新しいアラートはありません。 ドライブ 2 の前のアラートから 24 時間以上経過しているため、新しいアラートが生成され、電子メールが定義済みの受信者に送信されます。

例 2   ドライブの「情報」ポリシー

この例は、 0 と同じポリシーの条件を表していますが、重要度は「情報」です。

ポリシーの条件: 「Drive Health Indicator」が「ACTION」であるか、「Drive Health Indicator」が「EVALUATE」です。

ポリシーエンティティー: ドライブ

ポリシーの重要度: 情報 – アラートは 1 回のみ生成されます。

時間	イベント	評価	結果
05:00:171	ポリシーが作成され、有効にされます。 ドライブ 1 の健全性は「EVALUATE」です。 ドライブ 2 の健全性は「MONITOR」です。	ポリシーはすべてのドライブについて評価され、ドライブ 2 ではなくドライブ 1 について照合されます。	ドライブ 1 のアラートが生成され、電子メールが定義済みの受信者に送信されます。このドライブでは、このポリシーによって追加のアラートは生成されません。 ドライブ 2 のアラートはありません。
08:12:24	ドライブ 1 の健全性は「ACTION」になります。 ドライブ 2 の健全性はまだ「MONITOR」です。	ポリシーはすべてのドライブについて評価され、ドライブ 2 ではなくドライブ 1 について照合されます。	ドライブ 1 の新しいアラートはありません。 ドライブ 2 のアラートはありません。
13:37:01	ドライブ 1 の健全性はまだ「ACTION」です。 ドライブ 2 の健全性は「EVALUATE」になります。	ポリシーはすべてのドライブについて評価され、ドライブ 1 とドライブ 2 の両方について照合されます。	ドライブ 1 の新しいアラートはありません。 ドライブ 2 のアラートが生成され、電子メールが定義済みの受信者に送信されます。このドライブでは、このポリシーによって追加のアラートは生成されません。
05:01:03	ドライブ 1 の健全性はまだ「ACTION」です。 ドライブ 2 の健全性は「USE」になります。	ポリシーはすべてのドライブについて評価され、ドライブ 2 ではなくドライブ 1 について照合されます。	ドライブ 1 についても、ドライブ 2 についても新しいアラートはありません。

例 3   メディアの「重大」ポリシー

このポリシーは、5135 FSC になる交換のアラートを生成します。この FSC は、テープリーダーの問題を示しており、できるかぎりすぐにメディアをライブラリから取り出して調べるべきです。

ポリシーエンティティー: メディア

ポリシーの重要度: 重大 – 交換アクティビティーによっては、アラートは 1 時間ごとに生成される可能性があります。

ポリシーの条件: 交換の FSC は 5135 です。

時間	イベント	評価	結果
08:00:53	ポリシーが作成され、有効にされます。	新しい交換が処理され、一致が見つからないときに、ポリシーが評価されます。	アラートは生成されません。
08:05:09	メディア A の交換で 5135 FSC が発生します。	新しい交換が処理され、メディア A について照合されると、ポリシーが評価されます。	メディア A のアラートが生成され、電子メールが定義済みの受信者に送信されます。 この交換では、このポリシーによって追加のアラートは生成されません。新しい交換が発生するまで、メディア A は、このポリシーからこれ以上のアラートを受け取りません (将来の交換でも 5135 FSC が発生すると想定します)。
09:13:17	メディア B の交換で 5135 FSC が発生します。	ポリシーは新しい交換について評価され、メディア B について照合されます。	メディア B のアラートが生成され、電子メールが定義済みの受信者に送信されます。 この交換では、このポリシーによって追加のアラートは生成されません。
10:35:22	メディア A の新しい交換で 5135 FSC が発生します。	ポリシーは新しい交換について評価され、メディア A について照合されます。	メディア A のアラートが生成され、電子メールが定義済みの受信者に送信されます。 この交換では、このポリシーによって追加のアラートは生成されません。

例 4   CAP の「重大」ポリシー

このポリシーは、注意が必要な CAP のアラートを生成します。

ポリシーエンティティー: CAP

ポリシーの重要度: 重大 – アラートは 1 時間ごとに生成される可能性があります。

ポリシーの条件: 「CAP Library Health」が「NOTOPERATIVE」であるか、「CAP Library Health」が「DEGRADED」です。

時間	イベント	評価	結果
14:05:10	ポリシーが作成され、有効にされます。 CAP 1A は「DEGRADED」状態です。	ポリシーはすべての CAP について評価され、CAP 1A について照合されます。	CAP 1A のアラートが生成され、電子メールが定義済みの受信者に送信されます。
15:01:12	CAP 2B は「NOTOPERATIVE」状態になります。	ポリシーはすべての CAP について評価され、CAP 1A と CAP 2B の両方について照合されます。	CAP 1A の新しいアラートはありません。 CAP 2B のアラートが生成され、電子メールが定義済みの受信者に送信されます。
15:05:20	CAP 1A はまだ「DEGRADED」で、CAP 2B はまだ「NOTOPERATIVE」です。	ポリシーはすべての CAP について評価され、CAP 1A と CAP 2B の両方について照合されます。	CAP 1A の新しいアラートが生成され、電子メールが定義済みの受信者に送信されます。 CAP 2B の新しいアラートはありません。
16:01:27	CAP 1A はまだ「DEGRADED」で、CAP 2B はまだ「NOTOPERATIVE」です。	ポリシーはすべての CAP について評価され、CAP 1A と CAP 2B の両方について照合されます。	CAP 1A の新しいアラートはありません。 CAP 2B の新しいアラートが生成され、電子メールが定義済みの受信者に送信されます。

例 5   「Media Health Indicator」を使用した交換のポリシー

交換のアラートポリシーは、ポリシーの重要度が関係ないという点で、ほかのライブラリシステムコンポーネントのポリシーとは異なります。交換は別個のイベントであるため、ポリシーの重要度に関係なくポリシーの条件が満たされると、交換のアラートポリシーは常にアラートを生成します。この例では、この点について説明します。アラートがほとんど生成されない類似した例については、例 5-0 を参照してください。

ポリシーエンティティー: 交換

ポリシーの重要度: これは交換のアラートであるため、ポリシーの重要度は関係ありません。この場合、重要度は「情報」ですが、結果はすべての重要度レベルで同じです。健全性が「EVALUATE」のメディアが関与するすべての交換についてアラートが生成されます。

ポリシーの条件: 「Media Health Indicator」が「EVALUATE」です。

時間	イベント	評価	結果
1 日目、13:13:17	ポリシーが作成され、有効にされます。 メディア Z の健全性は「EVALUATE」です。	ポリシーはすべての交換について評価され、一致は見つかりません。	アラートは生成されません。
1 日目、14:43:09	健全性が「EVALUATE」のメディア Z の交換が発生します。	ポリシーはすべての交換について評価され、メディア Z について照合されます。	メディア Z のアラートが生成され、電子メールが定義済みの受信者に送信されます。
1 日目、07:20:24	健全性がまだ「EVALUATE」のメディア Z の別の交換が発生します。	ポリシーはすべての交換について評価され、メディア Z について照合されます。	メディア Z の新しいアラートが生成され、電子メールが定義済みの受信者に送信されます。
2 日目、15:05:19	健全性がまだ「EVALUATE」のメディア Z の別の交換が発生します。	ポリシーはすべての交換について評価され、メディア Z について照合されます。	メディア Z の新しいアラートが生成され、電子メールが定義済みの受信者に送信されます。

例 6   「Media Health Indicator」を使用したメディアの「警告」ポリシー

このポリシーは、健全性が「EVALUATE」のメディアのアラートを生成します。この例は例 5-0 と似ていますが、これはメディアのアラートポリシーであるためアラートはほとんど生成されません。

ポリシーエンティティー: メディア

ポリシーの重要度: 警告 – アラートは 24 時間ごとに生成される可能性があります。

ポリシーの条件: 「Media Health Indicator」が「EVALUATE」です。

時間	イベント	評価	結果
1 日目、13:13:17	ポリシーが作成され、有効にされます。 メディア Z の健全性は「EVALUATE」です。	ポリシーはすべてのメディアについて評価され、メディア Z について照合されます。	メディア Z のアラートが生成され、電子メールが定義済みの受信者に送信されます。
1 日目、14:43:09	健全性がまだ「EVALUATE」のメディア Z の交換が発生します。	ポリシーはすべてのメディアについて評価され、メディア Z について照合されます。	メディア Z の最後のアラートから 24 時間経過していないため、新しいアラートは生成されません。
2 日目、07:20:24	健全性がまだ「EVALUATE」のメディア Z の別の交換が発生します。	ポリシーはすべてのメディアについて評価され、メディア Z について照合されます。	メディア Z の最後のアラートからまだ 24 時間経過していないため、新しいアラートは生成されません。
2 日目、15:05:19	健全性がまだ「EVALUATE」のメディア Z の別の交換が発生します。	ポリシーはすべてのメディアについて評価され、メディア Z について照合されます。	メディア Z の前のアラートから 24 時間以上経過しているため、新しいアラートが生成され、電子メールが定義済みの受信者に送信されます。

アラートポリシーの条件

選択したアラートエンティティーに使用可能な属性に基づいて、アラートを定義できます。ただし、一部の属性では、実際にアラートを呼び出すイベントは作成されません。さらに、メディア検証のアラートポリシーでは、アラートは、中間結果ではなく最終検証結果によってのみ呼び出されます。

アラートポリシーのベストプラクティス

このセクションには、アラートポリシーの作成に関するいくつかのヒントが記載されています。

多すぎるアラートの回避

ポリシーエンティティータイプに固有の条件を使用してアラートポリシーを定義することをお勧めします。また、交換とメディア検証のアラートポリシーでは、交換と検証に固有であり、ドライブとメディアには使用できない条件を使用することをお勧めします。そうしない場合、重なり合うアラートポリシーが作成され、同じイベントまたはリソース属性について複数のアラートと電子メールが生成される可能性があります。

たとえば、次の 3 つすべてのポリシーを作成して有効にできます。

• メディアの警告ポリシー: 「Drive Health Indicator」が「MONITOR」であるか、「Drive Health Indicator」が「MONITOR」です

• ドライブの警告ポリシー: 「Drive Health Indicator」が「MONITOR」であるか、「Media Health Indicator」が「MONITOR」です

• 交換のポリシー: 「Drive Health Indicator」が「MONITOR」であるか、「Media Health Indicator」が「MONITOR」です

メディアとドライブのアラートポリシーはそれぞれ、健全性が「MONITOR」の各ドライブとメディアについて 24 時間ごとにアラートを生成します。さらに、交換のアラートポリシーは、健全性が「MONITOR」の各ドライブまたはメディアが交換で使用されるたびにアラートを生成します。健全性が「MONITOR」の単一のドライブまたはメディアから多数のアラートを受け取る可能性があります。

より適切な方法は、次のポリシーを作成して有効にすることです。

• メディアの警告ポリシー: 「Media Health Indicator」が「MONITOR」です

• ドライブの警告ポリシー: 「Drive Health Indicator」が「MONITOR」です

• 交換のポリシー: アラート: 「Drive Dump Available」が「True」です

論理グループを使用したアラートポリシーの定義

ドライブまたはメディアのアラートポリシーを定義する際に、選択条件で論理グループを使用できます。ドライブとメディアは一度に複数の論理グループに属することがあるため、条件の指定時には、通常は「Is」と「Isn't」演算子ではなく、「Contains」と「Doesn't Contain」演算子を使用する方が適しています。詳細は、論理グループでフィルタリングを参照してください。

STA のサンプルのアラートポリシー

いくつかのサンプルアラートポリシーが STA で提供されます。これらのポリシーは、ポリシー作成の具体的な例を示すことを意図しており、すべてデフォルトで無効になっています。必要な数だけ有効にしてそのまま使用することも、ニーズに応じてより具体的なポリシーを作成するための開始点として使用することもできます。

注意: STA で提供される定義済みテンプレートとは異なり、サンプルアラートポリシーは書き込み保護されておらず、直接変更できます。ただし、サンプルポリシーを変更または削除した場合、オリジナルの状態に復元できません。変更する場合、サンプルポリシーをコピーしてコピーを変更し、オリジナルは未変更のままにすることをお勧めします。詳細は、アラートポリシーのコピーを参照してください。 また、提供されるサンプルポリシーのレコードを出力して、必要に応じて手動で再作成できるようにすることをお勧めします。詳細は、アラートポリシーのリストの管理を参照してください。

STA のすべてのサンプルアラートポリシーの名前に、「STA」接頭辞が付いています。サンプルポリシーのこの命名規則を保持し、独自のアラートポリシーの名前を付けるときには「STA」接頭辞を使用しないことをお勧めします。STA のサンプルアラートポリシーの「Date Created/Updated」は、STA アプリケーションが最後にインストールされたときの日付です。

アラート電子メール

アラートは、任意の数の電子メールアドレスに送信できます。電子メールで送信されたアラートによって、ユーザーは、STA アプリケーションにログインすることなく、テープライブラリシステムでの重要なイベントの通知を受けます。アラートは、STA のユーザー名を持たない従業員にも送信できます。

使用可能な電子メールアドレスは、「Configuration」–「Email」画面で STA に対して事前に定義しておく必要があります。手順については、『STA インストールおよび構成ガイド』を参照してください。

例 5-1 と例 5-2 は、受信することがあるアラート電子メールのテキストの例です。

例 5-1 サンプルの交換のアラート電子メール

Exchange Started at December 13, 2013 5:52:05 AM MDT and Ended at December 13, 2013 7:15:41 AM MDT
STA Drive Alert - 2013-12-13 07:20:46   (Drive HU1233210W)
Alert Summary:
   Policy Desc:    Generates an alert when the Drive Health Indicator is Evaluate and Drive Health Trend is Worse.
   Criteria Met:   Drive Health Indicator=EVALUATE and Drive Health Trend=WORSE
   STA Server:     sysbiz
 
DRIVE
   Serial Number:        HU1233210W
   Tray Serial Number:   UNKNOWN
   Model:                HpUltrium6
   Last Annotation:      
 
   Health Indicator:                  Evaluate
   Health Trend:                      Worse
   Suspicion Level:                   90.0
   Exchange Status:                   GOOD
   Exchange Tape Alerts - Warning:    0
   Exchange Tape Alerts - Critical:   0
   Alerts (30 days):                  3

例 5-2 サンプルの STA アプリケーションのアラート電子メール

STA STA Server Alert 2013-12-15 22:39:21 (STA Server bizsys)
Alert Summary:
   Policy Desc:    This policy will match when the STA software is restarted.
   Criteria Met:   staEngine: Server in an UNKNOWN State - Restarting.
   STA Server:     bizsys

アラートワークフロー

アラートワークフローは、「Alerts Overview」画面で選択したアラートに割り当てることができる定義済みの状態に基づくオプションの手動プロセスです。サイトにとって最適な方法でアラートワークフローを実装できますが、アラート状態の推奨される行程は次のとおりです。

1. 「New」– STA は、すべてのアラートの作成時にこの状態を割り当てます。

2. 「Acknowledged」– アラートが確認されました。

3. 「In Progress」– アラートが担当者に割り当てられ、評価されています。

4. 「Dismissed」– 担当者がアラートに関するすべてのアクティビティーを完了しました。デフォルトでは、消去されたすべてのアラートが「Alerts Overview」画面で非表示になりますが、オプションで表示することもできます。詳細は、消去したアラートの表示または非表示を参照してください。

アラート状態を使用した手動のワークフローの実装に関する詳細は、アラートの状態の変更を参照してください。

アラート管理タスク

アラートポリシー定義タスク  

• アラートポリシーのリストの管理

• アラートポリシーの作成

• アラートポリシーのコピー

• アラートポリシーの変更

• アラートポリシーの電子メール受信者の変更

• アラートポリシーの有効化または無効化

• アラートポリシーの削除

アラートモニタリングタスク 

• 生成されたアラートのリストの管理

• アラートの詳細の表示

• 消去したアラートの表示または非表示

• アラートの状態の変更

アラートポリシーのリストの管理

注: この手順では、オペレータ権限または管理者権限が必要です。

1. ナビゲーションバーで、「Setup & Administration」 > 「Alerts Policies」を選択します。
   図の説明 fg_navbaralrt.png
   
   

   「Alerts Policies」画面が表示され、サイトでのサンプルポリシーとユーザー定義ポリシーが示されます。

   
   図の説明 fg_alrtpolicies.png
   
   

2. 次のタスクを実行して、アラートポリシーのリストを管理できます。

   • 表レコードをフィルタします。「Filter Data」ダイアログボックスを使用したテーブルフィルタの変更を参照してください。

   • 表に適用されたフィルタをリセットします。現在のフィルタのクリアを参照してください。

   • 表をリフレッシュして、新しいポリシーを表示します。『STA 画面基本ガイド』を参照してください。

   • 出力可能な形式の表を別のブラウザのタブまたはウィンドウで表示します。『STA 画面基本ガイド』を参照してください。

アラートポリシーの作成

アラートポリシーを作成するには、この手順を使用します。「Alert Policies」ウィザードは、ポリシーに関するすべての情報を定義するための手順を順に示します。

注: この手順では、管理者権限が必要です。

1. ナビゲーションバーで、「Setup & Administration」 > 「Alerts Policies」を選択します。
   図の説明 fg_navbaralrt.png
   
   

   「Alerts Policies」画面が表示されます。

2. 「New Alert Policy」をクリックします。
   図の説明 fg_alrtpoladd.png
   
   

   「Alert Policies」ウィザードが表示されます。

3. 次のようにウィザードの最初の画面に入力します。

   1. 「Policy Name」フィールドに、一意の名前を入力します。

      入力には、長さ 250 文字までの英数字を含めることができます。

      
      

      注: STA で提供されるすべてのサンプルアラートポリシーに「STA」で始まる名前が付いているため、アラートポリシーに割り当てる名前の先頭にはこの接頭辞を付けないことをお勧めします。

      
      

   2. 「Policy Description」フィールドに、ポリシーのオプションの説明を入力します。この情報はアラート電子メールに含められます。このフィールドを使用して、このポリシーによって生成されるアラートの推奨される修正アクションを指定してもかまいません。

   3. 「Next」をクリックします。
      図の説明 fg_alrtwiz1.jpg
      
      

   
   

   注: ウィザードの任意の画面で、ダイアログボックスの上部にあるブレッドクラムリンクを選択して、次の画面またはすでにアクセスした任意の画面に直接移動できます。

   
   

4. 次のようにウィザードの 2 番目の画面に入力します。

   1. 「Entity Type」メニューで、このポリシーがアラートを生成する対象のライブラリシステムコンポーネントのタイプを選択します。タイプについては、アラートポリシーエンティティーを参照してください。

   2. 「Select Severity」フィールドで、アラートポリシーの重要度レベルを選択します。重要度レベルについては、アラートポリシーの重要度を参照してください。

   3. 「Next」をクリックします。
      図の説明 fg_alrtwiz2.jpg
      
      

5. ウィザードの 3 番目の画面で、次のようにアラートポリシーの条件を指定します。

   1. 「Filter Matching」フィールドで、指定するいずれかの条件と一致するか、すべての条件と一致するかを示します。

   2. 新しい空白の選択条件の行をダイアログボックスに追加するには、「Add New Filter Criteria Row」ボタンをクリックします。
      図の説明 fg_alrtaddcriteria.jpg
      
      

   3. 行のメニューとテキストフィールドを使用して、選択条件を指定します。各行の入力の詳細は、表 4-1 属性タイプ別のフィルタ演算子を参照してください。

      
      

      注: フィルタリングの属性を選択する際に、選択する属性の名前がわかっている場合は、最初の数文字を入力すると、メニュー内のその項目にカーソルをすばやく移動できます。

      
      

   4. 必要な数の選択条件の行を追加できます。

      
      

      注: 選択条件が論理グループに基づくときは、通常は「Is」と「Isn't」演算子ではなく、「Contains」と「Doesn't Contain」演算子を使用する方が適しています。これは、ドライブとメディアが一度に複数の論理グループに属することがあるためです。詳細は、論理グループでフィルタリングを参照してください。

      
      

   5. 条件を削除するには、削除する行で「Remove This Filter Criteria Row」ボタンをクリックします。
      図の説明 fg_alrtremcriteria.jpg
      
      

6. 条件が正しいことを確認して、「Next」をクリックします。
   図の説明 fg_alrtwiz3.jpg
   
   

7. 次のようにウィザードの 4 番目の画面に入力します。

   1. 「Email Recipients」メニューで、このポリシーによってアラートが生成されるたびに電子メールを送信する先の電子メールアドレスを選択します。

   2. 「Next」をクリックします。
      図の説明 fg_alrtwiz4.jpg
      
      

8. 次のようにウィザードの最後の画面に入力します。

   1. すべてのポリシー情報が正しいことを確認します。

   2. 次のように「Enable Alert Policy」チェックボックスを使用します。

      • ポリシーを作成し、即時に有効にするには、チェックボックスを選択します。

      • ポリシーを作成しても、現在のところは無効のままにしておくには、このチェックボックスを選択解除します。あとで有効にできます。詳細は、アラートポリシーの有効化または無効化を参照してください。

   3. 「Save」をクリックします。

      
      図の説明 fg_alrtwiz5.jpg
      
      

   ポリシーが作成されます。ポリシーが有効になっている場合、適切なライブラリシステムリソースがポリシーに対して即時に評価され、必要に応じてアラートが生成されます。ポリシーが無効になっている場合、現在のところポリシーは評価されません。

アラートポリシーのコピー

選択したアラートポリシーをコピーするには、この手順を使用します。ニーズに応じて、ユーザー定義ポリシーまたは STA のサンプルポリシーをコピーできます。次に、この手順のいくつかの用途を示します。

• 新しいポリシーのベースとして既存のポリシーを使用します。作成するポリシーに類似した既存のポリシーをコピーして、コピーを変更します。詳細は、アラートポリシーの変更を参照してください。

• STA のサンプルポリシーをコピーして、オリジナルバージョンを保持します。STA のサンプルポリシーは書き込み保護されておらず、オリジナルバージョンを変更した場合に復元する方法はないため、使用しない場合でもオリジナルバージョンのコピーを保持することをお勧めします。

注: この手順では、管理者権限が必要です。

1. ナビゲーションバーで、「Setup & Administration」 > 「Alerts Policies」を選択します。
   図の説明 fg_navbaralrt.png
   
   

   「Alerts Policies」画面が表示されます。

2. コピーするアラートポリシーを選択して、「Copy Alert Policy」をクリックします。
   図の説明 fg_alrtcopy.jpg
   
   

   「Alert Policies」ウィザードの最初の画面が表示されます。ポリシーのコピーには、次の点を除きオリジナルと同じすべての情報が含まれています。

   • 「Copy」という単語が「Policy Name」の最後に追加されます。

   • 電子メール受信者は定義されていません。

   • ポリシーは無効になっています (「Enable Alert Policy」チェックボックスは選択解除されています)。

     
     図の説明 fg_alrtcopyd.jpg
     
     

3. 「Policy Name」フィールドに、割り当てる名前を入力します。

4. 「Next」ボタン、またはダイアログボックスの上部にあるウィザードのブレッドクラムを使用して、変更する情報がある画面に移動します。これらの画面への入力の詳細は、アラートポリシーの作成を参照してください。単にオリジナルポリシーをコピーして保持する場合は、すべての情報を未変更のままにすることもできます。

5. 完了したら、「Save」をクリックします。

   新しいポリシーが作成され、「Alerts Policies」画面が情報で更新されます。

   次の例では、Drive-Diag-SL3000 ポリシーが Drive-Diag-SL8500 ポリシーからコピーされ、SL3000 ライブラリ内のドライブを評価するようアラートの条件が変更されました。

   
   図の説明 fg_alrtcopydone.jpg
   
   

アラートポリシーの変更

選択したアラートポリシーに次のいずれかの変更を行うには、この手順を使用します。

• ポリシー名を変更します。

• ポリシーの説明を変更します。

• このポリシーで評価するようにテープライブラリシステムのリソースまたはイベントを変更します。

• ポリシーの重要度を変更します。

• ポリシーの選択条件を追加、削除、または変更します。

• 電子メール受信者を追加または削除します。より直接的な方法については、アラートポリシーの電子メール受信者の変更を参照してください。

• ポリシーを有効または無効にします。より直接的な方法については、アラートポリシーの有効化または無効化を参照してください。

注: この手順では、管理者権限が必要です。

1. ナビゲーションバーで、「Setup & Administration」 > 「Alerts Policies」を選択します。
   図の説明 fg_navbaralrt.png
   
   

   「Alerts Policies」画面が表示されます。

2. 変更するアラートポリシーを選択して、「Edit Alert Policy」をクリックします。
   図の説明 fg_alrtpoledit.png
   
   

   「Alerts Policy」ウィザードの最初の画面が表示され、ポリシーの最新情報が表示されます。

   
   図の説明 fg_alrtwizedit.jpg
   
   

3. 「Next」ボタン、またはダイアログボックスの上部にあるウィザードのブレッドクラムを使用して、変更する情報がある画面に移動します。これらの画面への入力の詳細は、アラートポリシーの作成を参照してください。

4. 完了したら、「Save」をクリックします。

   ポリシーが更新され、「Alerts Policies」画面に変更が表示されます。

アラートポリシーの電子メール受信者の変更

選択したアラートポリシーの電子メール受信者を追加または削除するには、この手順を使用します。受信者には、ポリシーによって生成されるすべてのアラートが通知されます。「Configuration」–「Email」画面で STA に対して事前定義された、任意の数のアドレスを選択できます。詳細は、アラート電子メールを参照してください。

注: この手順では、管理者権限が必要です。

1. ナビゲーションバーで、「Setup & Administration」 > 「Alerts Policies」を選択します。
   図の説明 fg_navbaralrt.png
   
   

   「Alerts Policies」画面が表示されます。

2. 変更するポリシーを選択して、「Email Recipients」をクリックします。
   図の説明 fg_alrtpolemail.png
   
   

   「Email Recipients」ダイアログボックスが表示されます。

3. 「Email Recipients」メニューで、このポリシーから生成されるアラートを受信するアドレスの横にあるチェックボックスを選択します。アラートを受信しないアドレスの横にあるチェックボックスを選択解除します。
   図の説明 fg_alrtemaild.jpg
   
   

4. 「OK」をクリックします。

   変更に従ってポリシーが更新されます。

アラートポリシーの有効化または無効化

選択したアラートポリシーを有効または無効にするには、この手順を使用します。有効にしたポリシーのみがアラートを生成できます。

特定のポリシーによって生成されるすべてのアラートが必ず電子メール受信者に通知されるように、ポリシーを有効にする前に、受信者をポリシーに追加してください。手順については、アラートポリシーの電子メール受信者の変更を参照してください。

注: この手順では、管理者権限が必要です。

1. ナビゲーションバーで、「Setup & Administration」 > 「Alerts Policies」を選択します。
   図の説明 fg_navbaralrt.png
   
   

   「Alerts Policies」画面が表示されます。

2. 変更するポリシーを選択します。

   ポリシーが現在有効になっている場合、「Alerts Policies」ツールバーの「Disable Alert Policy」アイコンがアクティブになります。ポリシーが現在無効になっている場合、「Enable Alert Policy」アイコンがアクティブになります。

3. 「Enable/Disable Alert Policy」をクリックします。
   図の説明 fg_alrtpoldisable.png
   
   

   選択に従ってポリシーが更新されます。

   • ポリシーを有効にした場合、対応するテープライブラリのリソースまたはイベントがポリシーの条件に対して即時に評価され、必要に応じてアラートが生成されます。

   • ポリシーを無効にした場合、ポリシーのアラートは生成されなくなります。

アラートポリシーの削除

アラートポリシーを削除するには、この手順を使用します。ポリシーを削除しても、すでに生成されたアラートはこのポリシーから削除されません。「Alerts Overview」画面で引き続き表示できます。アラートポリシーを削除する前に無効にする必要はありません。

注: この手順では、管理者権限が必要です。

注意: STA のサンプルアラートポリシーを削除しないように注意してください。手動で再作成しないかぎり、復元できません。STA のすべてのサンプルアラートポリシーの名前に「STA」接頭辞が付いています。

1. ナビゲーションバーで、「Setup & Administration」 > 「Alerts Policies」を選択します。
   図の説明 fg_navbaralrt.png
   
   

   「Alerts Policies」画面が表示されます。

2. 削除するアラートポリシーを選択して、「Delete Alert Policy」をクリックします。
   図の説明 fg_alrtpoldelete.png
   
   

   「Delete」ダイアログボックスが表示されます。

3. 選択を確認して、「Yes」をクリックして削除を確認します。
   図の説明 fg_alrtdeleted.jpg
   
   

   ポリシーが削除され、「Alerts Policies」画面のリストが更新されます。

生成されたアラートのリストの管理

注: アラートの注釈付けを除き、この手順はすべての STA ユーザーが実行できます。注釈付けにはオペレータ権限が必要です。

1. ナビゲーションバーで、「Tape System Activity」 > 「Alerts Overview」を選択します。
   図の説明 fg_navbaralrtovw.png
   
   

   「Alerts Overview」画面が表示され、今までに生成されたすべてのアクティブな (消去されていない) アラートが示されます。

   
   図の説明 fg_alrtlist.jpg
   
   

2. 次の手順を実行して、アラートのリストを管理できます。

   • 出力可能な形式の表を別のブラウザのタブまたはウィンドウで表示します。『STA 画面基本ガイド』を参照してください。

   • アラートに注釈を付けます。『STA 画面基本ガイド』を参照してください。

   • アラートのリストをエクスポートします。『STA 画面基本ガイド』を参照してください。

   • アラートのリストをフィルタします。「Filter Data」ダイアログボックスを使用したテーブルフィルタの変更を参照してください。

   • 表に適用されたフィルタをリセットします。現在のフィルタのクリアを参照してください。

   • 表をリフレッシュして、新しいアラートを表示します。『STA 画面基本ガイド』を参照してください。

   • 表を画面から切り離して、ブラウザ前景の別のウィンドウで表示します。『STA 画面基本ガイド』を参照してください。

   • 画面の特定のページに直接移動します。『STA 画面基本ガイド』を参照してください

アラートの詳細の表示

アラートを表示して、このアラートを呼び出したテープライブラリシステムのイベントまたは状態にトレースするには、この手順を使用します。

注: この手順は、ビューア以上の権限を持つすべての STA ユーザーが実行できます。

1. ナビゲーションバーで、「Tape System Activity」 > 「Alerts Overview」を選択します。
   図の説明 fg_navbaralrtovw.png
   
   

   「Alerts Overview」画面が表示されます。

2. 表示するアラートを選択して、「Detail View」をクリックします。
   図の説明 fg_alertselect.jpg
   
   

   「Detail View」で、選択したそれぞれのレコードに、関連情報が記載されたほかの画面へのいくつかのリンクが含まれています。

3. 「Alert Event Type」フィールドでリンク (この例では、Exchange) を選択して、アラートを呼び出したイベントの詳細を表示します。
   図の説明 fg_alrtexchange.jpg
   
   

   表示される情報を使用して、アラートの原因をトレースして、アクションを行う必要があるかどうかを判別できます。

   
   図の説明 fg_alrtexchdetail.jpg
   
   

アラートの状態の変更

サイトで実装されたアラートワークフロープロセスに従って、選択したアラートの状態を変更するには、この手順を使用します。このプロセスの詳細は、アラートワークフローを参照してください。

注: この手順は、ビューア以上の権限を持つすべての STA ユーザーが実行できます。

1. ナビゲーションバーで、「Tape System Activity」 > 「Alerts Overview」を選択します。
   図の説明 fg_navbaralrtovw.png
   
   

   「Alerts Overview」画面が表示されます。

2. 変更するアラートを選択して、「Change Alert State」をクリックします。複数のアラートを選択できます。
   図の説明 fg_alrtchangestate.jpg
   
   

   「Change Alert State」ダイアログボックスが表示されます。

3. メニューで、選択したアラートに割り当てる状態を選択します。使用可能な任意の状態を割り当ててから、「OK」をクリックできます。
   図の説明 fg_alrtack.jpg
   
   

   アラートが更新され、その新しい状態が「Alerts Overview」画面に表示されます。

   
   

   注: 選択したアラートを「Dismissed」に変更し、「Alerts Overview」画面が消去したアラートを非表示にするよう設定されている場合、アラートは表示から削除されます。消去したアラートの表示に関する詳細は、消去したアラートの表示または非表示を参照してください。

   
   
   
   図の説明 fg_alrtackdone.jpg
   
   

消去したアラートの表示または非表示

消去したアラートの表示を「Alerts Overview」画面で切り替えるには、この手順を使用します。アラートの消去方法の詳細は、アラートの状態の変更を参照してください。

注: この手順は、ビューア以上の権限を持つすべての STA ユーザーが実行できます。

1. ナビゲーションバーで、「Tape System Activity」 > 「Alerts Overview」を選択します。
   図の説明 fg_navbaralrtovw.png
   
   

   「Alerts Overview」画面が表示され、デフォルトでは消去したアラートはすべて非表示になっています。

2. 表のツールバーで「Show Dismissed Alerts」ボタンをクリックします。
   図の説明 fg_alrtshowdism.jpg
   
   

   消去したアラートが画面に表示されるようになり、ボタンのラベルが「Hide Dismissed Alerts」に変更されました。
   図の説明 fg_alrtshowdismdone.jpg
   
   

3. 消去したアラートを再度非表示にするには、「Hide Dismissed Alerts」ボタンをクリックします。
   図の説明 fg_alrthidedism.jpg