[0]　アラームシュミレーション
[1]　アラームシュミレーションのサンプル
[2]　アラームシュミレーションの実際
[3]　シュミレーション結果の検索
[4]　閾値の選択
[5]　まとめ
[6]　【参考】月のアラームログの集計 [Advanced]

アラームシュミレーション　　　テストトライアルにJump new

　ITSR(EEC)には、試験結果を何か月も蓄積しています。この試験結果を元に、アラームになる場合をシュミレーションします。timeoutの頻度や遅延の発生の頻度はITインフラ環境によって異なります。
　遅延については、アプリケーションの種類により、遅延に影響され易いもの（Voice、Fileサーバへのアクセス）と影響されにくいもの（WEB系）があります。
　よって、一概に、〇〇ms以上 であれば、業務に影響すると言うことができません。
レスポンス時間は速い方が良いですが、無駄な設備投資にならないようにバランスが必要です。

　エンドユーザ様の申告が１回あれば、どのような場合に影響があるかを明確にし、次からは、エンドユーザ様の申告前に不具合を事前に把握できるようにするのが、本アラームシュミレーション機能です。

　【補足】
　遅延に関するお客さまの不満の限界値 の項で記述しておりますが、ある遅延の閾値を超えるとエンドユーザ様の不満度が増します。この時の状態を把握することが重要です。
← 図は再掲

　このお客様の不満の限界値を超えない運用をしていくことが重要です。そのためには、常に現状を把握し、品質が常に改善する対策を継続して行うことが重要となってきます。

１．アラームシュミレーションのサンプル

　例えば、ある日の 16時過ぎに、「経理システムのレスポンスが遅くて仕事にならなかった」の申告があったとします。
　その時間帯の試験結果を以下に示します。
　　16:07:21 : 7.604
　　16:07:53 : 7.684
　　16:08:25 : 8.847
　　16:08:57 : 320.308　←
　　16:09:30 : 404.331　←
　　16:10:03 : 409.866　←
　　16:10:35 : 441.127　←
　　16:11:08 : 411.438　←
　　16:11:41 : 213.608　←
　　16:12:13 : 385.889　←
　　16:12:46 : 312.830　←
　　16:13:18 : 278.223　←
　　16:13:52 : 411.833　←
　　16:14:24 : 357.431　←
　　16:14:57 : 397.792　←
　　16:15:29 : 327.752　←
　　16:16:02 : 340.966　←
　　16:16:35 : 398.882　←
　　16:17:07 : 30.845
　　16:17:39 : 13.368
　　16:18:12 : 7.526
　　
　16:08～16:16ごろまで、遅延が発生していることが分かります。

　　遅延値が、300ms ～ 400ms になると、エンドユーザ様の使い勝手が悪くなることが推測されます。

２．アラームシュミレーションの実際

　アラームシュミレーションのTOP画面を次に示します。



　■ 月の選択　　　　シュミレーションを行う月を選択します。
　■ グループの選択　シュミレーションを行うグループを選択します。
　■ 閾値の選択　　　閾値を選択します。

　確定 ボタンを押すことによりシュミレーションを実行します。

３．シュミレーション結果の検索

　検索のTOP画面を次に示します。



　上の図の赤枠を選択して、確定 ボタンを押すと検索結果が表示されます。

■ シュミレーション結果　その１ 　遅延閾値 300ms 　　遅延連続回数 3回 　の場合


■ シュミレーション結果　その２ 　遅延閾値 350ms 　　遅延連続回数 3回 　の場合


■ シュミレーション結果　その３ 　遅延閾値 400ms 　　遅延連続回数 3回 　の場合

４．閾値の選択

　シュミュレーション結果を元に閾値の選択をします。
エンドユーザ様に、300ms, 350ms の閾値にアラームが発生した日時の業務への影響をヒヤリングします。

■　その１
　11月1日の16:10ごろ以外は、業務に支障が無かった場合には、
　遅延閾値 400ms 　　遅延連続回数 3回 　とします。

■　その２
　11月1日の16:10ごろ以外にも業務に影響を及ぼしたケースが多い場合は、
　遅延閾値 350ms 　　遅延連続回数 3回
　または、
　遅延閾値 300ms 　　遅延連続回数 3回 を選択します。

５．まとめ

　アラームシュミレーション機能を用いて、エンドユーザ様の申告前にトラブルを把握することができるようになります。
トラブルの把握は、あくまで、課題解決の入り口ですが、ＩＴインフラの状況を掴んでおられるお客様は非常に少なく、
　・今の状況で良いのか悪いのかさえ分からない。
のが実態です。

　トラブルを把握した後は、
　・EECの監視機器の登録推奨手順 と 品質が常に向上する施策
　・パケットキャプチャーによる分析
　・４Webサイト比較
　【問題解決事例集より】
　・office365が遅い 等
　を参考に、問題を絞り込み原因の発見、解決に繋げていきます。

６．【参考】月のアラームログの集計 [Advanced]

１．概要
(1) EECの通常のlog集計機能の Advanced バージョンです。
・土、日、祝日は省きたい。
・深夜、早朝帯は、省きたい。
・特定グループを省きたい。
・特定（複数も可能）の機器のみの表示をしたい。
等の検索を可能としました。

　[Advanced] では、発生時 を追加しました。

(2) 複数月の指定を可能にしました。

・過去１年分のデータを一括して検索することが可能です。
・ある特定の機器を絞り込み、過去に比べて品質が向上しているが一目で見ることができます。

２．具体的な絞り込み検索
(1) 特定のグループを省きたい例
グループ２ と グループ４を省きたい例
　(1) 除外グループ
と入力して下さい。

(2) 土、日、祝日を省く例
　例えば、2019年 7月の 土、日、祝日は、「6日、7日、13日、14日、15日、20日、21日、27日、28日」になります。
この日を省きたいと時は、
　(2) 除外日
と入力して下さい。 一桁の場合は、06 と 0 を付けて下さい

(3) 特定時間を省く例
　深夜、早朝帯　22:00 ～ 6:99 までの時間を省きたい場合は、
　(3) 除外時間
と入力して下さい。 一桁の場合は、06 と 0 を付けて下さい

(4) 特定文字列 を含むもののみ表示
　例：拠点名に　＿＿工場と言うように、「工場」と特定の一意の文字が付与されている場合、＿＿工場のみ表示することができます。
　(4) 特定文字列
　unix の grep 機能を利用しています。

(5) 除外したい項目を省く例
　例：名古屋工場 と 滋賀工場 を省きたい場合
　(5) 除外文字列
と入力して下さい。

３．検索事例
(1) 2019 年 06 月　 [拠点毎(回数をまとめて)[回復時]] [ダウンand遅延]　　の例
　以下、検索結果例


(2) 2019.7月で、土日祝日、かつ、深夜・早朝帯(22,23,00,01,02,03,04,05,06時台)を除いたアラーム状況　の表示例
　業務時間帯のトラブルのみ抽出します。
2019 年 07 月　 [日付順[回復時]] [ダウンand遅延]
■絞り込み 　(2) 除外日:06,07,13,14,15,20,21,27,28 　(3) 除外時間:22,23,00,01,02,03,04,05,06


(3) ある特定機器(10.1.16.17) の ７月、６月、５月、４月のデータの検索例
複数月の指定　 [日付順[回復時]] [ダウンand遅延]
■絞り込み 　(4) 特定文字列:10.1.16.17
　以下、検索結果例　 ６月に較べ、７月に改善が図られたことが分かります。
◇ 2019年 07月

◇ 2019年 06月

◇ 2019年 05月

◇ 2019年 04月

---