TSifter 2022 paper - draft - yuuk1's Digital Garden

## Title - Fast Dimensionality Reduction of Time Series for Localizing Root Causes in Cloud Applications. - A Framework of Fast Preprocessing Time Series for Localizing Root Causes in Cloud Applications. - A Framework of Fast Preprocessing Time Series for Fault Localization in Cloud Applications. - TSifter: Fast Dimensionality Reduction of Multivariate Time Series for Fault Localization in Online Service Systems. - TSifter: A Framework for Dimensionality Reduction of Multivariate Time Series for Fault Localization in Cloud Applications. - TSifter: Feature Reduction with Clustering Change Points of Multivariate Time Series for Fault Localization in Cloud Applications. - TSifter: Feature Reduction in Multivariate Time Series for Fault Localization in Cloud Applications. - TSifter: A Feature Selection technique for Multivariate Time Series for Fault Localization in Cloud Applications. - "Multivariate Time Series Data Reduction for Efficient Fault Diagnosis in Cloud Applications" - Feature Reduction Techniques for Multivariate Time Series Data to Localize Faults in Cloud Applications - **Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications** - Feature Reduction of Multivariate Time Series Data for Improved Troubleshooting in Cloud Applications Cloud Applications or Online Service Systems or Distributed Applications or Large Scale Web Services ## 関連資料 - ChangeFinderのフレームワーク論文 - [[2006__TKDE__A Unifying Framework for Detecting Outliers and Change Points from Time Series]] - [[研究室内研究会202211アウトライン]] - [[研究室内研究会202210アウトライン]] - [[研究室内研究会202207アウトライン]] - [[研究室内研究会202206アウトライン]] - [[研究室内研究会202205 アウトライン]] - [[研究室内研究会202202アウトライン]] - [[研究室内研究会202201アウトライン]] - [[TSifter国際会議計画2021]] - [[TSifter実験 - MOC]] ![[Pasted image 20220721151725.png]] ## メモ - [[時系列解析とネットワーク解析におけるMetricSifterの位置づけ]] - [[MetricSifterの最大のセグメントの選択改良]] - [[IEEE ACCESS review comments for MetricSifter paper 202301]] - [[MetricSifter IEEE ACCESSカバーレター]] - [[MetricSifterの現場適用性の議論]] - [[MetricSifter論文のbackground再構成]] - [[MetricSifter Notations]] - [[MetricSifter 問題定義の変更のかわりにシミュレーション研究を充実させる]] - [[MetricSifter論文で実験結果からわかったこと]] - [[TSifter 変化点に重みを付ける]] - [[2つの集合の組み合わせのスコアの可視化]] - [[TSifterのシミュレーション研究の意義]] - [[変化点に基づくクラスタリングの部位評価]] - [[シミュレーションによるTSifterの評価結果]] - [[時系列の変化点に基づくクラスタリングであれば変化点のラグから因果の向きを決定できる]] - [[根本原因メトリクスは時系列の変化点位置が近傍の最大のクラスタに存在する]] - [[TSifterの真の根本原因メトリクスを確定させる]] - [[次元削減により根本原因メトリクスを誤削減しなければFault Localizationの精度が向上する]] - [[特徴量削減により故障箇所特定精度が向上する]] - [[Fault Localizationにおいてメトリクス粒度の特定は非常に困難である]] - [[TSifter論文では既存の次元削減手法と比較しないでよいのではないか]] - [[20230324 TSifterの統合評価内容]] - [[コールグラフを使用するAIOps Fault Localization論文]] - [[TSifter + Fault Localizationの性能の改善案]] - [[TSifter評価故障経路とそれ以外の有意差]] - [[TSifter 評価用の正確性定義の検討]] - [[時系列の異常パターンの評価データの収集とアノテーション]] - [[TSifterクラスタリングの評価検討]] - [[TSifter評価 PatternMatcherの分類器を使用]] - [[PatternMatcherのNN実装]] - [[PatternMatcherの問題点]] - [[メトリクスの変化開始時刻と障害発生時刻との間の遅延]] - [[ノード重み付き中心性による故障箇所特定]] - [[AIOpsデータセット作成法の調査テーブル (Dataview)]] - [IEEE Access citation style [Update 2022] - Paperpile](https://paperpile.com/s/ieee-access-citation-style/) ## 参考文献 - Introduction - [[2020__ICSME__Failures and Fixes - A Study of Software System Incident Response]] - [[The VOID Report 2021]] - [[The VOID Report 2022]] - [[クラウドのリソースメトリクスの非正規性を示す文献]] - 多数の異常: [[2018__ISSRE__Robust and Rapid Adaption for Concept Drift in Software System Anomaly Detection|Ma+, ISSRE2018]] - フェーズ１前処理 - [[2021__ISSRE__Identifying Root-Cause Metrics for Incident Diagnosis in Online Service Systems|PatternMatcher]] - [[2020__IPCCC__FluxInfer―Automatic Diagnosis of Performance Anomaly for Online Database System|FluxInfer]] - フェーズ２ - [[2019__ISSRE__FluxRank―A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation|FluxRank]] - [[2014__INFOCOM__CauseInfer―Automatic and distributed performance diagnosis with hierarchical causality graph in large distributed systems|CauseInfer]] - フェーズ３ - [[2019__ISSRE__FluxRank―A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation|FluxRank]] - [[2014__INFOCOM__CauseInfer―Automatic and distributed performance diagnosis with hierarchical causality graph in large distributed systems|CauseInfer]] - [[2022__ICWS__TS-InvarNet - Anomaly Detection and Localization based on Tempo-spatial KPI Invariants in Distributed Services|TS-InvarNet]] - [[2021__ATC__Jump-Starting Multivariate Time Series Anomaly Detection for Online Service Systems|JumpStarter]] - 統合評価 - その他 - [[2018__IWQoS__Robust and Rapid Clustering of KPIs for Large-Scale Anomaly Detection|ROCKA]]は異常検知の学習時間を前処理により削減 ## Major Tasks - [x] HDBSCANの実装と実験 - [ ] 予備実験のまとめ - 予備実験では、テストケースは1,2個でもいいかも - [ ] 異常検知 - [[時系列の異常パターンの評価データの収集とアノテーション]] - [ ] 異常パターンごとのメトリクスと正常パターンの準備 - パターンごとに10ずつ + 正常 100 - [ ] 各次元削減処理との性能比較 - [ ] クラスタリング - 閾値にどの程度敏感？ - 既存手法は、ピアソン相関を使用していることから、ノイズに敏感であるこを示す - 正解ラベルを用意して、相互情報量で比較 - [x] [[TSifter 障害の空間的影響伝搬に基づくGround Truthの定義]] - [ ] 故障局在化のための既存手法との比較 - 前処理を既存手法のままと比べて、性能が向上することを示す - Sock ShopとTrain Ticketの両方の実験 - [ ] [[2021__ISSRE__Identifying Root-Cause Metrics for Incident Diagnosis in Online Service Systems|PatternMatcher]] - [ ] [[2020__IPCCC__FluxInfer―Automatic Diagnosis of Performance Anomaly for Online Database System|FluxInfer]] - [ ] [[2019__ISSRE__FluxRank―A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation|FluxRank]] - [ ] [[2022__CCGrid__Generic and Robust Performance Diagnosis via Causal Inference for OLTP Database Systems|CauseRank]] - [ ] 時間コストの実験 - [ ] 各フェーズごとの実行時間の比較 - [ ] e-diagnosisとの比較 - [ ] 統合評価 - [ ] 故障箇所特定粒度の評価 - [ ] サービスレベル - [ ] コンテナレベル - [ ] メトリクスレベル - [ ] パラメータの敏感性の実験 - [ ] クラスタリング対象スコープの変更 - [ ] コンテナレベル - [ ] サービスレベル - [ ] ハイパーパラメータ - [ ] フェーズ１の閾値 - [ ] フェーズ３の距離閾値（HDBSCANの場合不要） - [ ] データセット (Optional) - [ ] 時系列長 - [ ] 1 hour - [ ] chaos duration [1min, 3min, 5min] - [ ] scrape interval - [ ] 5 sec interval - [ ] 30 sec interval - [ ] データセットの追加 - [ ] k8s内部メトリクス - [ ] node chaos - [ ] HTTP chaos - [ ] ワークロード増加 - [ ] 公開データセットの準備 (Optional) - [ ] [[AIOpsデータセット - Dejavu]] - [ ] [[2020 AIOps Challenge マイクロサービスアプリケーションの障害発見と根本原因の特定]] ## Minor tasks - [ ] eval_dataset validation visualize - [ ] 候補メトリクスがひとつもない場合はエラー - [ ] Neptuneへ - [ ] neptuneにapplicationカラムを追加 - [x] ts-verification-codeのmemory injectionエラー調査 - chaos injectedで停止してくれない問題 - ts-verification-codeを除外する - [-] #task no injection時のデータ収集 - [ ] クラスタリングでDTWを試す ## Abstract TBD ## 1 Introduction - **大規模なオンラインサービスシステム（例：ソーシャルメディア，電子商取引，Internet of Thingsなど）は、ユーザー体験の向上と保証を両立するために、サービスの機能の高頻度の追加・修正に加えて、高い信頼性を要求される。** - アプリケーションコードやシステム設定変更は、インシデントの引き金となりうるため、高頻度であるほど、インシデントの数は増加する。 [[SRE Workbook 障害トリガーと根本原因]] - [[The VOID Report 2022]]によると47%のインシデントの解決に2時間以上要していることがわかっている。 - 高信頼性を達成するためには、インシデントを迅速に診断し、緩和させることが急務となる。 - **一般的に、インシデントが発生すると、エンジニアは関連するすべてのメトリクスを収集して、システムの内部状態を調査し、障害を引き起こした故障を特定するための手がかりを発見することを目指す。** - （インシデント対応の流れの事例） - **インシデントに関連するメトリクスが数百から数千に及ぶため、それらのメトリクスからエンジニアが目視で手がかりを得ることは現実的ではない。** ([[2021__ISSRE__Identifying Root-Cause Metrics for Incident Diagnosis in Online Service Systems|PatternMatcher]]) - 大規模なオンラインサービスシステムのメトリクスは、多数の属性と属性値の組み合わせの数だけあるため、メトリクスの総数は組み合わせ爆発につながる。 - 故障箇所を特定するまでの時間を短縮するために、故障箇所の特定を自動化することが望ましい。 - **文献上では、多次元メトリクスを基にして、障害を引き起こした故障の局在化を自動化するための数多くの手法が提案されている。** - [[2021__ISSRE__Identifying Root-Cause Metrics for Incident Diagnosis in Online Service Systems|PatternMatcher]], [[2020__IPCCC__FluxInfer―Automatic Diagnosis of Performance Anomaly for Online Database System|FluxInfer]], [[2019__ISSRE__FluxRank―A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation|FluxRank]], [[2020__WWW__AutoMAP - Diagnose Your Microservice-based Web Application|AutoMAP]], [[2014__INFOCOM__CauseInfer―Automatic and distributed performance diagnosis with hierarchical causality graph in large distributed systems|CauseInfer]], [[2020__IWQoS__Localizing Failure Root Causes in a Microservice through Causality Inference|MicroCause]], [[2018__ICSOC__Microscope―Pinpoint Performance Issues with Causal Graphs in Micro-service Environments|Microscope]] - ベイジアンネットワークを用いた統計的因果探索手法や、グラフアルゴリズムを駆使して、故障を局在化する。 - **しかしながら、故障の局在化アルゴリズムに入力するデータの問題空間の縮小法に課題がある。** - 問題空間を小さくするために、既存手法の一部（[[2021__ISSRE__Identifying Root-Cause Metrics for Incident Diagnosis in Online Service Systems|PatternMatcher]]、[[2020__IPCCC__FluxInfer―Automatic Diagnosis of Performance Anomaly for Online Database System|FluxInfer]]、[[2019__ISSRE__FluxRank―A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation|FluxRank]]）は、前処理の段階で故障に関連のないメトリクスを除去している。 - 異常検知またはクラスタリングを行っている。 - 故障に関連する時系列データは異常を示すという観察のもとに、異常が検知されたメトリクスのみを入力データとする。 - 前処理のみの評価がなく、期待通りに動作しないことがある。前処理が期待通りに動作しなければ、原因の局所化性能が低下する。 - オンラインサービスシステムの故障局在化のための前処理に着目した文献は他にない。 - **本論文では、オンラインサービスシステムの故障局在化に向けて、問題空間を縮小するための前処理として、多次元時系列データの次元削減のためのフレームワークを設計する。** - 前処理では、時系列の個数の低減（フィルタリング） + 異常箇所のアノテーション + 異常度の付与。 - メトリクスの数と種類が多いため、メトリクスごとにモデルパラメータを調整したり、検出閾値を調整したりすることは、現実的ではない。 - 本フレームワークでは、次元削減のフェーズを次の3段階のオフライン処理に整理する。 - フェーズ１：単変量時系列異常検知 - フェーズ２：単変量時系列変化開始点検知 - フェーズ３：多変量時系列クラスタリング - **最後に、本研究は以下の点で貢献する。** 1. 既存研究の次元削減処理の課題を実証する。 2. 課題を解決するためのフレームワークを提案する。 3. 前処理段階での評価と、後続の処理を加えた統合評価 - 故障局在化アルゴリズムの出力の解釈性を高めるには、因果グラフに代表されるように、障害のImpactを示す出力形式が求められる。 - そのため、障害のImpactを考慮した評価基準を提示する。 ## 2 Background ### 2.1 Incident Response - インシデント対応のタイムラインを示す。 - （[[2019__ISSRE__FluxRank―A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation|FluxRank]]の図１を参考にする） - Failure Detection、Fault Localization、Failure Mitigation - 既存文献では、SLIメトリクスの異常を契機として、故障局在化のためのアルゴリズムを実行する。 - SLIメトリクスの例 [[Alibabaの3つのタイプの異常]] ### 2.2 Previous Dimentionality Reduction - 故障箇所特定の先行研究における次元削減手法を調査した結果を次の表に示す。 - [[Fault Localization向けの特徴削減手法の調査]] ### 2.3 An Empirical Study on Effectiveness - メトリクス数が増大すると、Recallが低下する。 - [[2022__NeurIPS__Root Cause Analysis of Failures in Microservices through Causal Discovery|Ikram+, NeurIPS2022]]では、"ε-Diagnosisは最高の実行時間を達成するが、ノード数が増加するとリコールが大きく低下するため、その有用性は限定的である。" - **既存の原因局在化手法の前処理を整理した上で、前処理の性能に課題があることを実験により実証する。** - 既存の原因局在化手法の前処理を次のように分類する。 1. 異常を含まない時系列を除去する 2. 変化点検知アルゴリズムを使用して、障害の開始時刻後に異常が検出された時系列を除去する [[2019__ISSRE__FluxRank―A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation|FluxRank]]の絶対微分値 3. 複数の異なる時系列を比較し、類似する時系列を除去する - 文献[[2019__WWW__ε-Diagnosis - Unsupervised and Real-time Diagnosis of Small-window Long-tail Latency in Large-scale Microservice Platforms|ε-Diagnosis]]の実験結果より、ピアソン相関ベースでは、うまくいかない？ - **障害の原因となるメトリクスの時系列の異常パターンは、文献[[2021__ISSRE__Identifying Root-Cause Metrics for Incident Diagnosis in Online Service Systems|PatternMatcher]]にて生産環境の調査に基づき次の13種類に分類されている。** - [[時系列の異常パターンの識別法]] - 本論文では、13種類の異常パターンの分類を採用する。 - 異常パターンに対して正しく予測可能かを予備実験にて確かめる。 - [[ε-Diagnosisの予備実験]] - [[TSifterクラスタリングの評価検討]] - [[拡張Dickey-Fuller検定|ADF検定]]、[[自己回帰モデル|ARモデル]]に基づく周期ベースの異常検知法との比較 ### 2.4 Problem Statement ## 3 Dimention Reduction Method ### 3.1 Overview - TSifterの設計は、インシデント対応に従事するエンジニアの次の３つの直感に依拠している。 1. 個々のメトリクスについて、時系列の異常を含まない時系列は、インシデントの症状または原因を特定する手がかりにはならない。 2. 個々のメトリクスについて、時系列に含まれる異常の開始時刻が、インシデントの開始時刻よりも後の時刻であれば、そのメトリクスは原因を特定する手がかりにはならない。 3. 同一の属性をもつ複数の時系列において、形状が類似する時系列は冗長である。 ### 3.2 PHASE1: Univariate Time Series Anomaly Detection - The observation interval is set to 30 minutes by default and the threshold is set empirically. ```python ols = OLS(x, add_constant(np.arange(1, x.size + 1))).fit() std = ols.resid.std() resids = ols.resid / std intersected_idxs: np.ndarray = np.where(np.diff(np.sign(resids)))[0] + 1 sections = np.split(resids, indices_or_sections=intersected_idxs) rsses = np.array([np.sum(errs**2) for errs in sections]) return np.max(rsses) ``` ### 3.3 PHASE2: Change Point Detection - SLIメトリクスに対する変化点検知を用いて障害の開始時刻を特定することにより、障害の開始時刻よりも後の時刻に開始した異常を除去する。 ### 3.4 PHASE 3: Multivariate Time Series Clustering 文献[[2018__IWQoS__Robust and Rapid Clustering of KPIs for Large-Scale Anomaly Detection|ROCKA]]でも述べられているように、メトリクスは様々なアプリケーションやシステムから収集されるため、クラスタの数を事前に決定することは困難である。（[[2022__ICWS__TS-InvarNet - Anomaly Detection and Localization based on Tempo-spatial KPI Invariants in Distributed Services|TS-InvarNet]]のFig. 4を参考にクラスタリングの結果を視覚的に例示する） - クラスタリングの対象範囲の決定 ### 3.5 Combinable Fault Localization Methods - [[2020__WWW__AutoMAP - Diagnose Your Microservice-based Web Application|AutoMAP]]のような各コンポーネントのメトリクスの種類と個数を揃える必要がある故障箇所特定手法とは組み合わせられない。 - 潜在的に組み合わせ可能な故障箇所特定手法 - ## 4 Experiments ### 4.1 Experimental Design - TSifterの有効性を実証するために、複数の実アプリケーションデータに基づいた実験的研究を行い、以下の研究課題（RQ）に答えることを目指しました。 - RQ1: TSifterは時系列データの次元削減にどのように機能するか？ - RQ2: TSifterの主要コンポーネントは全体のパフォーマンスに貢献しているか？ - RQ3: TSifterはどの程度効率的に動作するか？ - RQ4: 既存の故障局在化プロセスの前にTSifterを実行したときにTSifterは貢献しているか？ - RQ5: TSifterはデータセットのパラメータやハイパーパラメータにどの程度敏感か？ #### 4.1.1 Datasets - 注入される故障の種別は次のようになる。 - Resource - CPU hog - Memory hog - Network delay - Network loss - HTTP delay - Workload - 故障発生から障害検知まで時間差のある故障 #### 4.1.2 Evaluation Metrics - 障害の空間的なImpactを示す評価指標を設定する。 - 空間的なImpactを次のように定義する。 [[TSifter 障害の空間的影響伝搬に基づくGround Truthの定義]] - [[自動Fault Localizationにおいてtop-kがk=5が期待される]] #### 4.1.3 Baseline Approaches - フェーズ１に相当するベースラインアプローチ - [[2019__WWW__ε-Diagnosis - Unsupervised and Real-time Diagnosis of Small-window Long-tail Latency in Large-scale Microservice Platforms|ε-Diagnosis]] - K-S検定 [[2021__ISSRE__Identifying Root-Cause Metrics for Incident Diagnosis in Online Service Systems|PatternMatcher]] - 混合ガウス分布に基づく異常検知 [[2020__IPCCC__FluxInfer―Automatic Diagnosis of Performance Anomaly for Online Database System|FluxInfer]] - [[BIRCHによる時系列データの異常検知]] - [[フェーズ１としてBIRCHを検証する]] - [[z-scoreとn-sigmaによる異常検知]] - [[SPOT]] - フェーズ２に相当するベースラインアプローチ - [[2019__ISSRE__FluxRank―A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation|FluxRank]]のクラスタリング ### 4.2 Simulation Study ### 4.2 RQ1: Effectiveness of TSifter - 全体フェーズでの評価 - [[2022__NeurIPS__Root Cause Analysis of Failures in Microservices through Causal Discovery|RCD]] - [[2022__arXiv__CausalRCA - Causal Inference based Precise Fine-grained Root Cause Localization for Microservice Applications|CausalRCA]] - [[2021__ICSE__MicroDiag - Fine-grained Performance Diagnosis for Microservice Systems|MicroDiag]] (DirectLiNGAM only) - 根本原因メトリクスの残留 (Recall) - 次元削減率：Precision F1-score ### 4.3 RQ2: Contributions of Main Components - TSifterの各フェーズについて、ベースラインアプローチと性能を比較する。 ### 4.4 RQ3: Time Efficiency - TSifterの各フェーズの実行時間を比較する。 - 一部のフェーズをスキップしたときの実行時間の変化を評価する。 - 時系列長を変化させたときの実行時間を評価する。 ### 4.5 RQ4: Contributions for Fault Localization - TSifterの出力を入力する既存のFault Localization手法として、次の3つと比較する。 - [[2021__ISSRE__Identifying Root-Cause Metrics for Incident Diagnosis in Online Service Systems|PatternMatcher]] の異常パターンの分類に基づく手法 - [[2020__IPCCC__FluxInfer―Automatic Diagnosis of Performance Anomaly for Online Database System|FluxInfer]] の無向グラフとPageRank - [[2020__IWQoS__Localizing Failure Root Causes in a Microservice through Causality Inference|MicroCause]] - 比較の際に、TSifterの部分フェーズと完全フェーズとで比較することにより、TSifterの各フェーズの貢献を評価する。 ### 4.6 RQ5: Parameter Sensitivity - データセット - 時系列長の変化 - 故障時間の変化 - ハイパーパラメータ - フェーズ１ ## 5 Discussion ### 5.x Threats to Validity - TSifterの制約 - 実験では、Fluctuationをもつデータを発見できなかった。 - フェーズ１はFluctuationの異常箇所の識別に効果的ではない - 商用の実環境データでの評価 ## 6 Related Work - メトリクスを用いた故障局在化 - 問題空間の縮小 - [[2018__Middleware__Sieve Actionable Insights from Monitored Metrics|Sieve]]の[[2015__SIGMOD__k-Shape - Efficient and Accurate Clustering of Time Series|k-Shape]]による次元削減 - [[2018__IWQoS__Robust and Rapid Clustering of KPIs for Large-Scale Anomaly Detection|ROCKA]] - メトリクス以外のデータ（テキストログ・トレース）を用いた故障局在化 - [[2020__POMACS__Fast Dimensional Analysis for Root Cause Investigation in a Large-Scale Service Environment|Apriori]] - 障害検知や回復などの他のFailure Management ## 7 Conclusion - 本論文では、我々は、オンラインサービスシステムの故障局在化に向けて、問題空間を縮小するために、多変量時系列データの次元削減フレームワークを設計した。 - 我々のフレームワークと標準的な故障箇所特定手法の組み合わせを実機を用いたシミュレーション実験にて評価した結果、標準的な故障箇所特定手法の。 --- > 後述する我々の予備実験では、(1)故障箇所特定向けの既存の特徴量削減は、根本原因となる複数のメトリクスの一部を誤削減すること、(2)最先端の故障箇所特定手法は、根本故障メトリクスが全体に占める割合（根本故障割合：root fault proportion, RFP）が高いほど特定精度が向上すること、が明らかとなった。そのため、根本故障メトリクスの割合を高めるために、根本故障メトリクスを削減せずに、その他のメトリクスを削減可能な特徴量削減法が必要となる。第一の課題は、既存研究が提案あるいは採用されている特徴量削減手法を他の手法と比較しておらず、体系化されていない。そのため、既存の特徴量削減手法のどうしの位置づけが不明瞭である。第二の課題は、多くの既存の文献は、特徴量削減手法の性能を評価していないことである。そのため、特徴量削減の有無や特徴量削減手法の差異による故障箇所特定性能への影響が不明である。第三の課題は、(TODO)節に示す予備実験により、異常検知による特徴量削減手法が短時間の異常や非継続中の異常を正常であると誤判定する偽陽性を示すことである。