1. © 2022 TIS Inc.
ITシステムの運用現場にデータ分析を応用してみよう
「AIOpsで実現する効率化」
IT基盤技術推進部
池田 大輔

2. © 2022 TIS Inc. 2
発表者紹介
いけだ だいすけ
池田 大輔
所属: TIS株式会社
IT基盤技術推進部
役割: 運用レコメンドPF プロダクトオーナー
興味: 運用管理系の効率化
技術: Zabbix,AWS,Docker,Kubernetes,
JobScheduler,fluentd,Ansible,Golang
著書: 技術評論社「改訂2版 Zabbix統合監視徹底活用」
Twitter @ike_dai
Qiita https://qiita.com/ike_dai

3. © 2022 TIS Inc. 3
お伝えしたいこと
• システム運用におけるデータは様々な視点から分析可能と知っていただく
• そのためには気を付けないといけない点があることを知っていただく
ご自身の運用現場を振り返って考えてみる機会に！
発表アジェンダ
・AIOpsとは？
・運用現場へのデータ分析の応用のパターン
・AIOps適用に向けたハードル
・TIS開発の運用レコメンドプラットフォームでの分析例
・OSSの監視ツールZabbixでの分析機能紹介

4. © 2022 TIS Inc. 4
背景 ～ITシステム運用の現状と課題～
保守・運用者 運用対象のITシステム
◼ 構成の複雑化
◼ 環境の大規模化
◼ ビジネススピードに合わせた変化の迅速化
◼ 一人辺りのカバー範囲の拡大
◼ 要求される技術レベルの高度化
◼ スピード感維持のために属人化が進む
従来手法で運用していると…
• 人による定期モニタリングチェック
• ルールベースのアラート通知
• ・・・等
質の低下を招く
• トラブルの影響深刻化
• トラブルの増加
• 対応の長期化
DXシフト等も相まって
ITシステムの重要度の高まり
(停止の影響拡大)
極力人が介在せず、
機械的に自律的に動く仕組みが求められている

5. © 2022 TIS Inc. 5
AIOps？
• Gartnerによると
参照) https://www.gartner.com/en/information-technology/glossary/aiops-artificial-intelligence-operations
ビッグデータと機械学習の組み合わせによりIT運用プロセスの自動化を実現すること
(イベント相関分析/アノマリー検知/因果関係推定等)
2018年頃にはエンタープライズ企業の5%程度の導入だが、
2023年頃には30%程度まで拡大するだろうと予測
参照) https://www.gartner.com/smarterwithgartner/how-to-get-started-with-aiops

6. © 2022 TIS Inc. 6
運用の現場に存在するデータ
• モニタリングデータ
• アプリログ
• システムログ
• 構成情報
• 作業記録情報
• 問い合わせ履歴情報
• FAQ
• プロダクトドキュメント
• 運用手順書
• 設計ドキュメント
・・・等

7. © 2022 TIS Inc. 7
現行の運用データの活用の仕方
• モニタリングデータ
• アプリログ
• システムログ
• 構成情報
• 作業記録情報
• 問い合わせ履歴情報
• FAQ
• プロダクトドキュメント
• 運用手順書
• 設計ドキュメント
・・・等
パフォーマンス劣化発生
①状況把握
②暫定対処方法確認
③根本原因確認/対処検討
規模が小さかったり、
熟練者だったらすぐに情報に辿れるが・・・

8. © 2022 TIS Inc. 8
運用現場へのデータ分析応用
• 万能な仕組みの実現は現状難しい
• 運用タスクを分解し、様々な切り口で小さな単位で分析するアプローチが現実的
運用タスク例
例1) モニタリングデータからいつもと様子がおかしい状況を確認
例3) 問い合わせ内容から類似問い合わせやナレッジを確認
例2) たくさんのログからあやしいものを見つける
いつもの周期傾向と異なっていないかの評価
いつもの値の大きさと異なっていないかの評価
いつもと上昇度合いが異なっていないかの評価
など
いつものログ流量と異なっていないかの評価
出力されているログの内容が異なっていないかの評価
ログ内に危険を知らせるキーワードが含まれていないかの評価
など
出現するキーワードが似ている情報がないかの評価
文章構造として似たような情報がないかの評価
過去に役に立った度合いの評価
など

9. © 2022 TIS Inc. 9
例1 モニタリングデータからいつもと何か様子がおかしいことを知る
Before
✓ 過去の傾向
✓ 熟練者の経験
✓ 一般的な情報 等
この値を超えたら
何か様子がおかしいとみなす
(判断基準)
After
✓ どのような動きをするか(時系列モデル)
✓ 値の統計情報がどうか(平均/中央/最大/最小/分散等)
✓ 将来的に推定される形状と比較してどうか 等
過去の動きの各種指標と比較して
状況が異なればおかしいとみなす

10. © 2022 TIS Inc. 10
参考) 時系列データに対する分析
• 時系列のデータのモデルとして代表的なもの(※その他、多くのものあり)
– 時系列データをモデル化し推定(時系列の動きを式として表現できる)
手法 概要
AR
(自己回帰モデル)
とある時点の値は、過去の値(複数)に回帰して算出される前提のモデル。
「過去の自己の値に係数をかけると将来の値が推測されるだろう」という考え方
MA
(移動平均モデル)
とある時点の値は、過去の自身の値に回帰されるわけではなく、過去のホワイトノイズの加
重和と現在のノイズ、平均値を足し合わせた形で表現されるモデル。
ARMA
(自己回帰移動平均モデル)
ARモデルとMAモデルを合わせたモデルで、過去の自身の値に回帰しつつ、ホワイトノイズ
の加重和も考慮されるモデル。
ブレが生じつつ周期的に変動するようなデータに適用しやすいモデル。
ARIMA
(自己回帰和分移動平均モデル)
トレンド傾向のあるデータなど非定常過程なデータに対し、データの差分を取り、定常化し
た後にARMAモデルを適用する表現。差分を取った表現が定常過程になるとは限らないので
調整が難しいケースもあり。
SARIMA
(季節自己回帰和分移動平均モデル)
ARIMAモデルに季節的な周期変動の要素も考慮して表現を行うモデル。
※簡易化のため一部正確性に欠ける表現がある点ご了承ください

11. © 2022 TIS Inc. 11
例2 たくさんのログからあやしいものをみつける
Before
✓ 過去の傾向
✓ 熟練者の経験
✓ アプリ仕様の理解 等
After
✓ 出力件数をベースに出力状況を数値化
✓ ログ内の単語の出力頻度ヒストグラム化 等
2022/3/2 10:00 Info xxx yyy
2022/3/2 10:23 Info ddd aaa
2022/3/2 12:34 Err failed exec
2022/3/3 09:45 Warn started
・・・
・・・
・・・
Error
failed
・・・
ブラックリスト
Info
Warn
・・・
ホワイトリスト
キーワード基準で評価
2022/3/2 10:00 Info xxx yyy
2022/3/2 10:23 Info ddd aaa
2022/3/2 12:34 Err failed exec
2022/3/3 09:45 Warn started
・・・
・・・
・・・
出力件数傾向
単語出力頻度分布
・・・
数値化して機械的に
評価できる形にして分析

12. © 2022 TIS Inc. 12
例3 問い合わせ内容から類似問い合わせやナレッジを確認
Before
✓ 熟練者の経験
✓ システム構成の知識
✓ アプリ仕様の理解 等
After
✓ 文書を解析し数値化
✓ 文書同士の距離(似ている度合い)等の算出
事象
xx/yy 10:00頃、サービスの応答
がなくなり、以下のようなログが発生
-----
Error: connection failed
-----
・・・
過去対応の履歴
キーワードをピックアップ
問い合わせ
検索して取り出す
事象
原因
対策
・・・
・・・
・・・
事象
xx/yy 10:00頃、サービスの応答
がなくなり、以下のようなログが発生
-----
Error: connection failed
-----
・・・
問い合わせ
事象
原因
対策
・・・
・・・
・・・
文書A
0.76
事象
原因
対策
・・・
・・・
・・・
文書B
0.32

13. © 2022 TIS Inc. 13
参考) 文書の数値化・類似度算出
• 文書情報を分析するための1手法
– TF-IDFとcos類似度を用いた文書類似度確認の例
文書内に出てくる各単語ごとに、以下の2つの指標を元に計算
・TF(TermFrequency)
→単語出現頻度
・IDF(InverseDocumentFrequency):
→逆文書頻度(全文書の中でどれぐらい頻繁に出てくるか)
全体的にあまり出てこない単語が特定の文書に頻繁に出ていると
その文書に対するその単語の特徴が強く出る
Error Info ・・・ aaa bbb
文書a 0.1 0.23 ・・・ 0 0
文書b 0.34 0.15 ・・・ 0.53 0
文書c 0.55 0.27 ・・・ 0.67 0.24
TF-IDF
文書を数値ベクトルに変換できる
2つのベクトルがどれぐらい似ているかを計算
ベクトル間の内積をベクトルの大きさで割った値
文書a 文書b 文書c
文書a 1 0.422 0.497
文書b 0.422 1 0.958
文書c 0.497 0.958 1
cos類似度
文書a = (0.1,0.23,0,0)
文書b = (0.34,0.15,0.53,0)
cos類似度(a,b) =
(0.1x0.34) + (0.23x0.15) + (0x0.53) + (0x0)
(0.1)2+(0.23)2+02 + 02 (0.34)2+(0.15)2+(0.53)2+02

14. © 2022 TIS Inc. 14
求められること
• 運用上の各種データを評価できる形で管理
– 数値情報から各種特徴を抽出
– 文書情報を評価できる形に数値化 等
• 知りたい状況に合わせて各種アプローチを組み合わせる
「人が時間をかけて対処していたこと」や
「詳しい人に聞かないとわからなかったこと」
を機械が支援できるように

15. © 2022 TIS Inc. 15
AIOps適用に向けたハードル
• 分析できる仕組みが徐々に充実している状況ではあるも
のの、適用するには検討事項があるのも事実
1
2
3
4
5
運用要件とのミスマッチ
異常系ケースの少なさ
データパターンの豊富さ
時間とともに変わる前提条件
評価する元データの質

16. © 2022 TIS Inc. 16
ハードル: 運用要件とのミスマッチ
課題感
対処例
統計に基づいて機械が判断している要素が強く、
100%確実なことが言えるわけではない
➡ 誤検出が許容されない場所への適用が困難
予測 異常じゃない 予測 異常
実際
異常じゃない 正常状態 過剰検知ケース
実際
異常 見逃しケース 予兆検知
✓ いきなり幅広く適用しようと考えない
✓ 既存の監視の仕組みとの併用
✓ 徐々に適用範囲を拡大
✓ 人の判断との併用から始める

17. © 2022 TIS Inc. 17
ハードル: 異常系ケースの少なさ
課題感
対処例
どういった評価になるかをPoCで確認したいが、
実際のトラブルはなかなか起こらないため効果が確認しにくい
✓ 過去データを用いた評価
✓ 意図的に負荷発生させて疑似的なトラブル状態を作る
✓ 疑似データを作成して評価する等も効果的
参考) https://zenn.dev/k8shiro/articles/handwriting_time-series_data_converter

18. © 2022 TIS Inc. 18
ハードル: データパターンの豊富さ
課題感
対処例
モニタリングデータ1つ取っても様々な傾向パターンがある
画一的な統計・分析手法では知れることに限りがある
※次ページに形状のパターン例を紹介
✓ 複数の観点から分析
✓ 各分析の結果を総合的に見て判断できるように

19. © 2022 TIS Inc. 19
参考) モニタリングデータの形状パターンと評価時に意識するポイント
トレンド傾向のあるデータ
単調 加法 乗法
0
10
0
1000
周期のあるデータ (どの単位で変動するかも考慮(日/週/月/年))
階段的な変動のあるデータ
スケールの異なるデータ
ARMA等用いて、
どの時間帯どういう傾向かを把握
ARIMA等用いた評価
線形近似を用いた推定等で傾向を把握
外れ値検知や変化点検知で変化の傾向を把握
正規化や標準化で
スケールを揃えた評価を行うケースもあり

20. © 2022 TIS Inc. 20
参考) モニタリングデータの形状パターンと評価時に意識するポイント
トレンド傾向のあるデータ
単調 加法 乗法
0
10
0
1000
周期のあるデータ (どの単位で変動するかも考慮(日/週/月/年))
階段的な変動のあるデータ
スケールの異なるデータ
ARMA等用いて、
どの時間帯どういう傾向かを把握
ARIMA等用いた評価
線形近似を用いた推測等で傾向を把握
外れ値検知や変化点検知で変化の傾向を把握
正規化や標準化で
スケールを揃えた評価を行うケースもあり
• 差分・階差計算
• 移動平均計算
• 対数変換計算
• 比率計算
等
で形状を変化させて評価するテクニックも

21. © 2022 TIS Inc. 21
ハードル: 時間とともに変わる前提条件
課題感
対処例
運用当初とシステム構成やシステムの提供形態が変わって稼働傾向も異なってくる場合
評価の基準となるいつもの稼働傾向自体が変わってしまう
✓ 稼働傾向のモデルの再作成
✓ 運用関連イベントと連動した対応
✓ 常に新しい状態に対応した評価

22. © 2022 TIS Inc. 22
ハードル: 評価する元データの質
課題感
対処例
評価するためには特徴が表れるデータが必須
簡易的な監視にとどまっていたり、ログデータが個々バラバラに管理されている等
評価できる元データの質が良くない
✓ 運用で知りたいこと、普段調べていることから順次キャッチアップ
✓ Zabbix等様々な収集方法に対応した高機能な監視ツール活用し集約
✓ IPA公開の『非機能要求グレード2018※』と照らし合わせるのも有効
※https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html

23. © 2022 TIS Inc. 23
参考) 非機能要求グレード2018
• 独立行政法人 情報処理推進機構(IPA)が公開(2018/4に改訂版公開)
• ITシステム基盤の可用性や拡張性など非機能に関する要求を明確化するために活用できるツール
• 各種観点項目に対し、レベル感の目安を定義
運用監視項目の情報だけでなく、
業務処理量等他の要素についても検討
※引用) 非機能要求グレード2018 システム基盤の非機能要求に関する項目一覧

24. © 2022 TIS Inc. 24
実現するために使えるもの
自分で組むとなると
調整とか難しいところ多い。。
• AIOps関連の機能をもつ運用ツール・サービス
– Splunk
– Dynatrace
– ServiceNow
– Zabbix(後述)
– 運用レコメンドプラットフォーム(TIS開発)
– など
• 自分で処理を組むなら
– RやPythonを使ったプログラム
– Pythonの場合
• scikit-learn
– 分類、回帰分析、クラスタリング等各種分析処理が実装された機械学習ライブラリ
– TF-IDFとかcos類似度等々多岐にわたる処理が可能
• statsmodels
– 統計モデル処理やデータの統計値算出処理当が実装されたライブラリ
– ARMAの処理等々多岐にわたる処理が可能
• tslearn
– scikit-learn同様、各種機械学習処理用ライブラリ
– 時系列データのクラスタリングなど対応

25. © 2022 TIS Inc. 25
運用レコメンドプラットフォーム

26. © 2022 TIS Inc. 26
運用レコメンドプラットフォームとは
IT運用 効率化・品質向上への取組み
定常業務 定型業務 ⇒旗印は「標準化」
非定常業務 非定型業務 ⇒標準化できない
･･･>分析の技術を活かして機械的にフォローする仕組みが重要に
監視データ、ログデータ、作業履歴、構成情報等、運用データを
分析することで、非定型業務の効率化のための仕組みづくりを行う
統合ダッシュボード機能
関連する監視傾向情報
関連するログ情報
統合的に可視化
関連する作業履歴情報
運用データ分析機能
データの集約管理
健全性評価レポート機能
なんとなく
おかしいな..
従来…
運用レコメンドPFを使うと…
想定外の状況発生に早期に気づく
いつもの稼動傾向をモデル化 変化を機械検知
• いつもの状態と違う？
• どれぐらいの期間おかしい？
• その他の周辺の状況は？ 等々
保守・運用者
運用者が状況切り分けのために確認する
複数観点の情報を機械的にスコアリングしレポート
運用者の感覚で評価している箇所を排除
63%
リスク値 判定要素
CPU状態
メモリ状態
枯渇リスク無し
稼働傾向変化有り
継続1日以上変化状態
10%
75%
総合判断した
スコアリング
【例: サーバリソース枯渇健全評価】
運用情報の統合表示 いつもと違うを機械的に捉える 状況切り分け作業を機械化
TISが自社開発を推進

27. © 2022 TIS Inc. 27
提供する価値
トラブルの未然予防に向けた予兆検知
有識者が見ている情報・観点を形式化(属人化排除)
従来
運用者
常に注意深くチェック
怪しそうだな・・
運用レコメンドプラットフォーム
運用レコメンドPF
常にいつもの稼働傾向との
違いを自動チェック
実値
正常時
モデル値
実値
従来
運用者(有識者)
運用レコメンドプラットフォーム
システムログ 監視情報 システム構成情報
都度状況切り分けに必要な
情報をピックアップ
評価定義
運用シナリオ毎に
事前定義
運用レコメンドプラットフォーム
定義に従い必要な情報を
自動ピックアップ
定期的に状態を自動評価

28. © 2022 TIS Inc. 28
統合ダッシュボード機能
• 収集したシステム運用データや分析結果等を確認したり、各種設定を行うWebベースの
ダッシュボードサービスを提供します。
• 収集データ(監視情報、ログ情報、アラート情報等)の確認
• 分析により算出された状態変化の発生状況の確認
• 健全性評価機能のレポート結果の確認
• 分析対象設定や健全性評価機能のレポート定義等の各種設定管理

29. © 2022 TIS Inc. 29
運用データ分析機能
• 収集し蓄積された監視データ、ログデータに対し、以下4種類の分析を行い、
稼働傾向の変化を検出します。
1. 監視データ変化点分析
2. 監視データトレンド変化分析
3. 複数監視データ同士の相関変化分析
4. ログデータ出力傾向変化分析
※各分析処理のイメージは後述の内容を参照ください。

30. © 2022 TIS Inc. 30
分析機能仕組み 1 -監視データ変化点検知分析-
◼ 数値系監視結果データに対して、変化点の検出処理を実施する機能
◼ ① 指定した監視アイテムのデータに対し、正常状態時の分析パターンを生成
(周期性も考慮した変動パターンの生成。デフォルトは1週間の変動周期を考慮)
◼ ② 直近の監視データを用いて、①の正常パターンと比較して変化点が発生していないかを定期分析
(実行間隔はデフォルト30分に1回)
分析評価イメージ
評価のため、
内部では正常状態の傾向パターンを管理
突発的ではなく、
状態が変化し始めた点を検出
前半で紹介したARMAでモデル化し
実データとの差分値の変化分析

31. © 2022 TIS Inc. 31
分析機能仕組み 2 -監視データトレンド変化検知分析-
◼ 数値系監視結果データに対して、トレンド傾向(上昇/下降) の変化検知機能
◼ ① 指定した監視アイテムのデータに対し、正常状態時のトレンド傾向パターンを生成
(1週間のデータを元に6時間単位でデータの推移傾向をモデル化)
◼ ② 直近の監視データを用いて、①の正常パターンと比較して傾き加減が変化していないかを定期分析
(実行間隔はデフォルト6時間に1回)
分析評価イメージ

32. © 2022 TIS Inc. 32
分析機能仕組み 3 -複数監視データ同士の相関変化分析-
◼ 複数の監視データ同士の変動の相関変化を分析する機能を提供
◼ ① 任意の複数の監視項目のデータを用いてそれぞれの変動の相関関係の正常時パターンを算出
◼ ② 定期的に、直近データを用いて相関関係を算出、①正常時パターンと比較し変動が大きい箇所を検知
(実行間隔は調整可能。デフォルトは30分に1回)
◼ 複数の監視項目の選択のパターン例
◼ i. 同一のサーバの監視項目同士の相関を見るケース
◼ ii. 同一の監視項目(CPU使用率)のサーバ間の相関を見るケース
分析評価イメージ
正常状態時の相関係数を内部で保持
相関係数の変化箇所を検出
普段は出ていない相関が
出始めていることの検知の例

33. © 2022 TIS Inc. 33
参考) モデルの管理
• モデルの管理は運用者により自由に行える形式を採用
稼働傾向の前提が変わっても再モデリングして追随可能
最大2か月(8週間)のデータを用いて稼働傾向を算出

34. © 2022 TIS Inc. 34
分析機能仕組み 4 -ログデータ出力傾向変化分析-
◼ ログに含まれるキーワードの出力傾向情報を分析し、前日の同時間帯と比較して傾向が
変わってきたタイミングで検知
期待する効果
- キーワードマッチベースの検出では気づけない傾向変化を早期検知できるようになる
比較対象期間(前日の同時間帯データ)
2019/09/18 12:01:20 +09:00 warning Starting app server ...
2019/09/18 12:03:21 +09:00 info check test ok
2019/09/18 12:07:12 +09:00 info check test ok
2019/09/18 12:08:21 +09:00 info check test ok
2019/09/18 12:12:43 +09:00 warning Starting app server ...
2019/09/18 12:15:14 +09:00 warning rotate debug log
2019/09/18 12:16:45 +09:00 warning invalid type integer
2019/09/18 12:29:11 +09:00 info check test ok
2019/09/18 12:31:01 +09:00 warning Starting app server ...
2019/09/18 12:32:32 +09:00 info check test ok
評価対象期間(直近のデータ)
2019/09/19 12:05:23 +09:00 warning Starting app server ...
2019/09/19 12:06:22 +09:00 warning old test debug log
2019/09/19 12:07:21 +09:00 warning invalid type integer
2019/09/19 12:08:20 +09:00 warning invalid max connections parameters
2019/09/19 12:12:19 +09:00 warning Starting app server ...
2019/09/19 12:15:18 +09:00 warning rotate debug log
2019/09/19 12:16:17 +09:00 warning invalid type integer
2019/09/19 12:29:15 +09:00 warning less max connections parameters 200
2019/09/19 12:31:14 +09:00 warning Starting app server ...
2019/09/19 12:32:13 +09:00 info change debug level 3 to 4
変化度合
いを分析
文書内のキーワードの出力頻度分布という形で評価可能な数値化

35. © 2022 TIS Inc. 35
健全性評価機能による予兆検知の仕組み
アクセスの増加
従来の検知までの流れ
リソースの負荷上昇
レスポンスタイム増加
イベントの発生
閾値の秒数超過検出
運用レコメンドPFでのアプローチ
評価対象: アクセスログ
特定のキーワードが発生している？
昨日/先週と比較して増加/減少している？
昨日/先週と比較してキーワード出力傾向が変わっている？
評価対象: 各種リソースデータ
設定した閾値を超えている？
いつもの周期変動と異なっている？
いつものトレンド傾向と異なっている？
いつもと違う状態がどれぐらい続いている？
いつもと比べてどれぐらいの度合い上昇している？
このままいくと将来いつ頃超過上限に到達する？
設定した閾値を超えている？
いつもの周期変動と異なっている？
いつものトレンド傾向と異なっている？
いつもと違う状態がどれぐらい続いている？
いつもと比べてどれぐらいの度合い上昇している？
このままいくと将来いつ頃超過上限に到達する？
評価対象: レスポンスタイム値
アクセス増加の兆候を知る
リソース負荷の兆候を知る
レスポンスタイムの兆候を知る
事前定義をしてシナリオの括りで評価
トータルリスク度
35%
トータルリスク度
67%
トータルリスク度
78%
単なるアクセス増だけだと
問題にはならないケースも
リソース負荷も高まると
全体として危険状態に近づく
レスポンスタイムまで影響が
出ていると非常に危険な状態
としてさらにスコアが高まる
時刻t1での状態
時刻t2での状態
時刻t3での状態
※従来の閾値ベースの超過の観点も含めて評価
※各評価の間隔は数時間間隔程度を想定。
数分レベルで異常顕在化してしまうケース
では予兆発生を事前に捉えることはできない
運用データ分析機能 健全性評価レポート機能
前半で紹介した複数観点で総合的に見ていくを実現

36. © 2022 TIS Inc. 36
参考) 2022/3時点 対応している評価観点一覧
関数 説明 評価結果の取り扱い
閾値の上限超過発生チェック 指定の閾値の上限超過が直近いつ発生したかを評価 直近発生している程リスク高
閾値の上限超過時間割合チェック 指定の閾値の上限超過していた時間が評価期間中どのぐらいの割合かを評価 割合が高い程リスク高
閾値に対する到達率チェック 指定の閾値の値を100%としたときに実値が何%に到達しているかを評価 到達率が超過する程リスク高
前週と比較した平均値の変化度合い
チェック
平均値との増減度合いが前週と比較して何%かを評価 率が高い程リスク高
各種変化検知発生チェック 稼働周期変化、トレンド傾向変化、相関変化、ログキーワード出力傾向変化等
各種分析による変化が直近いつ発生したかを評価
直近発生している程リスク高
各種変化検知発生頻度チェック 上記各種分析による変化がどの程度の頻度で発生していたかを評価 高頻度な程リスク高
各種変化検知の度合いチェック 上記各種分析による変化がどの程度大きな変化であったかを評価 度合いが大きい程リスク高
各種変化の発生継続時間チェック 上記各種変化が変化した状態でどの程度の時間経過したかを評価 継続時間が長い程リスク高
指定値への到達予測時間チェック このペースで増減するといつ指定値に到達すると推測されるかを評価 残り時間が短い程リスク高
各種評価観点を柔軟に組み合わせて評価レポートの算出を行う
これまで人がグラフを見て判断していた観点で判定できる
いつもの稼働傾向から乖離したタイミング

37. © 2022 TIS Inc. 37
適用例
とあるWebサービスにて
– これまではトラブル予防のため、定期的に稼働傾向のグラフ状態の確認作業を実施
• サービス利用傾向変化、それに伴うリソース枯渇状況変化、システム応答速度の変化等
• 切り分け基準は、確認者の過去経験から来るなど属人的
運用業務に合わせて
見るべき項目・観点を定義
例) ストレージの増強要否の切り分けシナリオ
定義に含まれるデータは自動集約、
いつもの稼働傾向およびその変化を機械的に評価
各観点の結果を元に対応が必要となる
リスクスコアを算出
以下の流れを運用レコメンドPFにて代行
既存の監視ツールやログ収集ツールからデータ集約
No. 項目 観点
1 利用傾向 アクセスログの変化
2 ストレージ使用率 周期変動の変化
3 ストレージ使用率 前週からの増加度合い
4 ストレージ使用率 トレンド傾向の変化
5 ストレージ使用率 上限到達予測時間残り期間
… … …
運用レコメンド
PF
監視ツール
Zabbix
監視サービス
Azure
monitor
ログツール
fluentd 正常時の稼働傾向をモデリング
変化の状況を検知
No. 項目 観点 リスクスコア
1 利用傾向 アクセスログの変化
2 ストレージ使用率 周期変動の変化
3 ストレージ使用率 前週からの増加度合い
4 ストレージ使用率 トレンド傾向の変化
5 ストレージ使用率 上限到達予測時間残り期
間
… … …
30%
20%
60%
85%
65%
ストレージ増強対応が必要なリスク状況: 60%

38. © 2022 TIS Inc. 38
参考情報) Zabbix6.0でも評価系の機能が拡張

39. © 2022 TIS Inc. 39
Zabbix6.0
• OSSの監視ツールZabbix
• 新版となる6.0が2022/2/14リリース
• 1つ大きな機能として監視データの分析機能が追加
• 以下のような関数が追加され、収集した監視データに対し、異常発生を推
測するための情報算出が可能に
– いずれの関数も「計算アイテム」、「トリガー」で活用可能
関数 概要
baselinedev 過去データを用いて値のブレ度合い(標準偏差)を算出し、評価対象の
直近の値がブレ度合いのどの程度に収まるかを評価
baselinewma 過去データを用いて加重移動平均値を算出し、評価対象の直近の値の
予測評価
trendstl 過去データを「季節周期性要素、トレンド要素、その他要素(残差)」
に分解し、その他要素のブレ度合いがどの程度かを評価

40. © 2022 TIS Inc. 40
Zabbix6.0関数 - baselinedev -
過去データを用いて値のブレ度合い(標準偏差)を算出し、評価対象の直近の値が
ブレ度合いのどの程度に収まるかを評価
概要
設定例 baselinedev(/host/item, 1d:now/d+1d, “w”, 3)
イメージ
結果解釈
指定した監視アイテム
データを使って
直近1日の値を評価 評価のベースにするデータは
過去3シーズン分のデータ
今日
1週間前
同曜日
2週間前
同曜日
3週間前
同曜日 この期間のデータの標準偏差: σ
この期間全体の平均値: avgA
今日の期間の平均値: avgT
算出値=
𝑎𝑣𝑔𝑇 −𝑎𝑣𝑔𝐴
𝜎
直近のデータと平均値とのブレが求めた標準偏差に対してどの程度かを示した指標になっている。
結果の値が1を超えると68%、2を超えると95%、3超過だと99.7%の分布範囲内に
収まらないことを意味する。
(算出値が大きくなれば正規分布上一定の範囲から逸れた値が検出されている)
※Wikipediaより引用(https://ja.wikipedia.org/wiki/%E6%AD%A3%E8%A6%8F%E5%88%86%E5%B8%83)

41. © 2022 TIS Inc. 41
Zabbix6.0関数 - baselinewma -
過去データを用いて加重移動平均値を算出し、評価対象の直近の値の予測評価
概要
設定例 baselinewma(/host/item, 1d:now/d+1d, “w”, 3)
イメージ
結果解釈
指定した監視アイテム
データを使って
直近1日の値を評価 評価のベースにするデータは
過去3シーズン分のデータ
今日
1週間前
同曜日
2週間前
同曜日
3週間前
同曜日
1週間前平均値: v1
1週間前の加重: w1(値は3)
2週間前平均値: v2
2週間前の加重: w2(値は2)
3週間前平均値: v3
3週間前の加重: w3(値は1)
算出値=
𝑣1×𝑤1+𝑣2×𝑤2+𝑣3×𝑤3
𝑤1+𝑤2+𝑤3
最も直近のシーズンに比重をおきつつ、過去シーズンの平均値を考慮した推定結果が算出される
この算出値が推定されるベースライン値となるため実データとの差を見て問題ないかを確認する

42. © 2022 TIS Inc. 42
Zabbix6.0関数 - trendstl -
過去データを「季節周期性要素、トレンド要素、その他要素(残差)」に分解し、その他
要素のブレ度合いがどの程度かを評価
概要
設定例 trendstl(/host/item, 30d:now/d+1d, 1d, 1d, 2, “stddevpop”)
イメージ
結果解釈
指定した監視アイテム
データを使って
直近30日分データ
を基準にSTL分解し
直近1日
データを評価
元データ
0.1という結果が出た場合、
周期要素やトレンド要素を排除した変動要素に限定してデータを見て、
指定期間内のデータの内、過去のデータのばらつき具合に収まらない異常を示すデータ割合が10%程度あることを示す。
1日周期
前提で分解
2x偏差
超過した率を算出
偏差の算出アルゴリズム
stddevpop: 母集団標準偏差
stddevsam: 標本標準偏差
mad: 中央絶対偏差 (デフォルト)
季節周期要素
トレンド要素
その他要素
・指定の算出アルゴリズムに従い偏差を算出
・評価対象の期間の残差の値が
「偏差x第5引数指定値」を超過した件数をカウント
・超過していた件数の全体の率を算出
STL
分解

43. © 2022 TIS Inc. 43
詳しくは・・
• 細かい部分まで紹介しきれないので、詳しくはQiitaにまと
めました。
https://qiita.com/ike_dai/items/d2ae4842f44cef5dcbd3

44. © 2022 TIS Inc. 44
運用レコメンドプラットフォームとZabbixのすみわけ
• 運用レコメンドPFはZabbixよりも上位層で分析結果をとりまとめて判断することが可能
• Zabbix監視結果・分析結果を運用レコメンドPFのデータソースとして活用するイメージ
運用レコメンドプラットフォーム
Zabbix
データ収集
各種トリガーによる検知収集
クラウド
監視データ
オペレーション
履歴データ
・・・等
①集約
②各種組み合わせ評価
運用者
気付き

45. © 2022 TIS Inc. 45
まとめ
• 運用現場へのデータ分析の技術導入は今後ますます現実的なものに
• 導入する際には難しい面もある
• できること理解した上で徐々に適用を進めるアプローチを
お声がけください
• 運用レコメンドPFにご興味ある方
– 試しに使ってみたい
– 自社の運用サービスとの連携を考えてみたい 等々
• 運用レコメンドPFの開発を通し、チームの育成も推進中
– TISに興味を持った方などもぜひ
TIS株式会社
IT基盤技術推進部
運用レコメンドPFサービス窓口
opsbear.service@ml.tis.co.jp

46. THANK YOU