Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

異常検知ナイト LT登壇資料 はてな id:syou6162

5,663 views

Published on

異常検知ナイトのLT登壇資料です

Published in: Engineering
  • Be the first to comment

異常検知ナイト LT登壇資料 はてな id:syou6162

  1. 1. Mackerel: SaaS型の サーバー監視/管理 サービス Agentがサーバーの メトリックを収集、 グラフで可視化 静的な閾値による アラートの発砲、Slack などへの通知をサポート サービス(例: はてなブログ)/ ロール(例: DB、Proxy)で 分かりやすくグルーピング
  2. 2. 休日や夜間など 比較的負荷の 低いケース 平日を中心とした 比較的負荷の 高いケース 異常と判定されるケース 混合ガウス分布(GMM)を利用した異常検知 •  ユーザーのロール(DB、 Proxyなど)毎にGMMを構築、 定期的に再学習 •  cpu/memory/load average など約20次元のメトリックを 利用 •  高/低負荷などはあるが、 混合数はそれほどチューニ ングしなくても動いてくれる •  時系列的な要素は考慮で きていない 現在開発中!
  3. 3. 困りごと: パラメータチューニング用の 異常データの不足 •  時系列を考慮する異常検知モデル(状態空間モデル、特異スペクトル変換、近傍 法、自己回帰などなど)を使いたい •  チューニング難しすぎませんか問題。様々なハイパーパラメータが存在 –  例: window幅、近傍数(kNN)、スムージングパラメータ(ベイズ的手法) •  論文では「検証データのF値でハイパーパラメータ決定」と書いてあることも多いが、 現場ではチューニングに必要な異常なデータが常に取れるとは限らない –  ユーザー毎に異常検知モデルを自動で作るので、異常データは使い回せない –  例: 同じhFp response Hmeのデータでもお客さん毎に許容できるものは異なる –  サービスによっては一ヶ月ずっと平常で異常が取れないこともある –  利用し始めたばかりのユーザーはどうするか(コールドスタート) •  弊社に限らず困っている人も多いと思うので、アドバイスよろしくお願いします!

×