JP7842308B2

JP7842308B2 - 監視システム、監視方法、及びプログラム

Info

Publication number: JP7842308B2
Application number: JP2025523236A
Authority: JP
Inventors: 健吾藤岡; 大地長谷川; 亮西村; 大助藤井
Original assignee: Rakuten Group Inc
Current assignee: Rakuten Group Inc
Priority date: 2023-05-26
Filing date: 2023-09-04
Publication date: 2026-04-07
Anticipated expiration: 2043-09-04
Also published as: EP4668118A1; JPWO2024247293A1; WO2024247293A1

Description

本開示は、監視システム、監視方法、及びプログラムに関する。

従来、サービスにおける異常の検知、復旧、又は分析といった種々の目的のために、監視対象となる装置の状態に関する状態データが解析されている。例えば、特許文献１には、ある装置の状態データが示す時系列的な状態の変化と、当該装置の実際の稼働状態と、の関係が学習されたモデルに基づいて、当該装置の異常の有無を判定するシステムが記載されている。特許文献２には、過去における装置のメモリ使用量の履歴と、現在における当該装置のメモリ使用量と、に基づいて、将来的な当該装置のメモリ使用量が閾値を超えるか否かを推定するシステムが記載されている。例えば、特許文献３には、システムに障害（異常の一例）が発生した場合に、当該システムにおける装置の状態に関する状態データと、当該システムに発生した障害を復旧するための復旧手順と、の関連度を計算する計算モデルに基づいて、当該システムに発生した障害を復旧させるために有効な復旧手順を特定することが記載されている。

国際公開２０１７／１６９９４９号公報特表２０２２－５１１９３８号公報特開２０２１－０１５３２１号公報

上記のような技術では、サービスにおける監視対象となる装置の状態に関する状態データに基づいて、サービスにおける異常に関する処理を実行することが求められている。

本開示の目的の１つは、サービスにおける監視対象となる装置の状態に関する状態データに基づいて、サービスにおける異常に関する処理を実行することである。

本開示に係る監視システムは、サービスにおける監視対象となる装置の状態に関する状態データを取得する状態データ取得部を含み、前記状態データに基づいて、前記サービスにおける異常に関する処理を実行する。

本開示によれば、サービスにおける監視対象となる装置の状態に関する状態データに基づいて、サービスにおける異常に関する処理を実行できる。

監視システムのハードウェア構成の一例を示す図である。通信サービスで異常が発生していない場合の通信装置の時系列的な通信量の変化の一例を示す図である。通信サービスで異常が検知された場合の通信装置の時系列的な通信量の変化の一例を示す図である。管理者端末に表示される通知の一例を示す図である。監視システムで実現される機能の一例を示す図である。状態データベースの一例を示す図である。期間設定部により設定される期間の一例を示す図である。監視システムで実行される処理の一例を示す図である。変形例１－１の監視システムで実現される機能の一例を示す図である。通信サービスで異常が検知された場合の通信装置の時系列的な通信量の変化の一例を示す図である。管理者端末に表示される通知の一例を示す図である。監視システムで実現される機能の一例を示す図である。状態データベースの一例を示す図である。クラスタリングの実行結果の一例を示す図である。監視システムで実行される処理の一例を示す図である。変形例の監視システムで実現される機能の一例を示す図である。

［１．第１実施形態］
本開示に係る監視システムの実施形態の一例である第１実施形態を説明する。第１実施形態では、サービスにおける異常に関する処理の一例を説明する。従来の技術では、種々の装置の種々の状態データが存在するので、サービスの提供者が、サービスにおける異常に関係のある状態データを特定できれば、サービスにおける異常の検知、復旧、又は分析といった種々の目的で利用できるので、非常に有用である。しかしながら、従来の技術は、装置の状態に関する種々の状態データの中から、どの状態データが異常に関係しているかを特定することはできない。そこで、第１実施形態の監視システムは、サービスにおける異常に状態データが関係するか否かを判定する。

［１－１．監視システムのハードウェア構成］
図１は、監視システムのハードウェア構成の一例を示す図である。例えば、監視システム１は、サーバ１０、通信装置２０、ユーザ端末３０、及び管理者端末４０を含む。サーバ１０、通信装置２０、ユーザ端末３０、及び管理者端末４０の各々は、ネットワークＮに接続可能である。例えば、ネットワークＮは、インターネット、公衆通信回線、又はＬＡＮである。

サーバ１０は、サーバコンピュータである。本実施形態では、通信事業者がサーバ１０を管理する場合を例に挙げる。例えば、サーバ１０は、制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、フラッシュメモリ等の不揮発性メモリと、の少なくとも一方を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。

通信装置２０は、他の装置と通信を行う装置である。例えば、通信装置２０は、通信事業者が管理する装置である。通信装置２０は、無線通信用の装置であってもよいし、有線通信用の装置であってもよい。通信装置２０は、ユーザによる通話及びデータ通信の少なくとも一方を中継する。例えば、通信装置２０は、公衆通信回線の基地局、構内交換機、無線ＬＡＮのアクセスポイント、ルーター、ハブ、リピータ、モデム、又は仮想化技術で利用されるサーバコンピュータである。通信装置２０は、完全仮想化クラウドネイティブモバイルネットワークをユーザに提供する通信事業者の装置であってもよい。

ユーザ端末３０は、通信サービスを利用するユーザのコンピュータである。例えば、ユーザ端末３０は、スマートフォン、タブレット、パーソナルコンピュータ、又はウェアラブル端末である。例えば、ユーザ端末３０は、制御部３１、記憶部３２、通信部３３、操作部３４、及び表示部３５を含む。制御部３１、記憶部３２、及び通信部３３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。操作部３４は、タッチパネル又はマウス等の入力デバイスである。表示部３５は、液晶又は有機ＥＬ等のディスプレイである。

管理者端末４０は、通信サービスにおける管理者のコンピュータである。例えば、管理者端末４０は、スマートフォン、タブレット、パーソナルコンピュータ、又はウェアラブル端末である。例えば、管理者端末４０は、制御部４１、記憶部４２、通信部４３、操作部４４、及び表示部４５を含む。制御部４１、記憶部４２、通信部４３、操作部４４、及び表示部４５のハードウェア構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部３４、及び表示部３５と同様であってよい。

なお、記憶部１２，３２，４２に記憶されるプログラムは、ネットワークＮを介して供給されてもよい。また、各コンピュータには、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、メモリカードスロット）と、外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）と、の少なくとも一方が含まれてもよい。例えば、情報記憶媒体に記憶されたプログラムが、読取部及び入出力部の少なくとも一方を介して供給されてもよい。

また、監視システム１は、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。例えば、監視システム１は、通信装置２０、ユーザ端末３０、及び管理者端末４０の少なくとも１つを含まなくてもよい。この場合、当該少なくとも１つは、監視システム１の外部に存在する。監視システム１は、サーバ１０だけを含んでもよい。監視システム１は、サーバ１０と、図１に示さない他のコンピュータと、を含んでもよい。監視システム１は、管理者端末４０だけを含んでもよい。監視システム１は、管理者端末４０と、図１に示さない他のコンピュータと、を含んでもよい。

［１－２．監視システムの概要］
本実施形態では、通信装置２０が、コンテナ化されたネットワーク機能であるＣＮＦ（Containerized Network Function）を有するサーバコンピュータである場合を例に挙げる。更に、ユーザ端末３０がスマートフォンである場合を例に挙げる。通信装置２０は、多数のユーザ端末３０の通信を中継する。例えば、通信装置２０が処理すべき通信量が、当該通信装置２０が処理可能な通信量に達すると、通信サービスで異常が発生する可能性がある。通信量は、ｂｐｓ等の公知の指標によって表現可能である。

例えば、通信サービスで異常が発生すると、管理者は、異常の要因となった通信装置２０を特定して復旧作業を行う。しかしながら、通信サービスでは、多数の通信装置２０が存在し、種々の異常が発生しうるので、管理者が、異常の要因となった通信装置２０を特定するのが難しいことがある。このとき、異常の要因となった通信装置２０は、それ以上の通信を処理しきれないので、通信量が飽和する場合がある。

通信量が飽和するとは、通信量が正の状態であり（通信量が０ではない状態であり）、かつ、通信量が変化しない又は略変化しないことである。通信量が変化しないとは、通信量の変化量が０のことである。通信量が略変化しないとは、通信量の変化量が閾値未満であることである。飽和の具体的な判定方法は、後述する。通信量は、上限値が定められていてもよいが、管理者が定めた上限値よりも多くの通信量を通信装置２０が処理可能な場合や、管理者が定めた上限値よりも低い通信量しか通信装置２０が処理できない場合もあり、さらには、管理者自身、通信装置２０の上限値を知らない場合もあるので、本実施形態では、通信量の上限値が定められていないものとする。このため、通信装置２０の通信量が一定程度に達したとしても、異常が検知されるわけではないものとする。

図２は、通信サービスで異常が発生していない場合の通信装置２０の時系列的な通信量の変化の一例を示す図である。図２の横軸は、時間を示す軸である。図２の縦軸は、通信量を示す軸である。図２の例では、通信事業者の施設に配置された３台の通信装置２０Ａ～２０Ｃの各々の通信量の変化が示されている。以降、通信装置２０Ａ～２０Ｃを区別しない時は、単に通信装置２０という。図２のように、通信サービスで異常が発生していない場合には、各通信装置２０の通信量は、飽和していない。即ち、各通信装置２０の通信量は、原則として、常に変化している。

図３は、通信サービスで異常が検知された場合の通信装置２０の時系列的な通信量の変化の一例を示す図である。図３の例では、時点ｔ００から時点ｔ０１までの期間において、通信装置２０Ｃの通信量が飽和している。当該期間では、通信装置２０Ｃは、それ以上の通信を処理できないので、ある特定のエリアで通信装置２０Ｃに接続を試みたユーザ端末３０が、通信サービスを利用できない可能性がある。このような場合に、ユーザは、通信サービスのコールセンターに連絡し、通信サービスを利用できないことを伝えることがある。

例えば、管理者は、複数のユーザからの問い合わせを受けて、異常が発生していることを把握する。この時点では、管理者は、どの通信装置２０が異常の要因であるかを特定しておらず、その後、時点ｔ０１が訪れて通信装置２０Ｃの通信量が下がり、異常が自然解消したものとする。更に、管理者は、ユーザからの問い合わせを受けなくなった場合に、異常が解消したことを特定したものとする。時点ｔ０１が訪れると、ユーザ端末３０が通信サービスを利用できるようになるので、異常が発生していた期間と、通信装置２０Ｃの通信量と、の間には相関関係がある。なお、本実施形態では、飽和開始タイミングから飽和終了タイミングまでの期間を異常が発生していた期間の一例として取り扱うが、飽和開始タイミングから飽和が終了していない現時点までの期間を異常が発生していた期間の一例として取り扱ってもよい。例えば、飽和開始タイミングから、管理者が指定した時点までの期間を異常が発生していた期間の一例として取り扱ってもよい。

例えば、サーバ１０は、異常が発生して解消した後に、通信装置２０Ａ～２０Ｃの各々の通信量を解析する。サーバ１０は、異常が発生していた期間において、通信装置２０Ｃの通信量が飽和していたことを特定する。サーバ１０は、今回発生した異常の特徴と、通信装置２０Ｃの通信量が当該異常に関係していることと、を関連付けて記憶しておく。サーバ１０は、同様の異常が再び発生した場合に、管理者端末４０に対し、通信装置２０Ｃの状態をチェックすることを促す通知を送信する。

図４は、管理者端末４０に表示される通知の一例を示す図である。例えば、管理者が、管理者端末４０にインストールされたメンテナンス用のツールを起動すると、サーバ１０から受信した通知を示す管理者画面ＳＣが表示部４５に表示される。管理者画面ＳＣには、過去に同様の異常が検知された場合に通信装置２０Ｃの通信量が飽和したので、今回も通信装置２０Ｃの状態をチェックすることを示すメッセージが表示される。

例えば、過去に通信装置２０Ｃの通信量が飽和した場合に、通信サービスのコールセンターが、ある特定のエリアＸから通信サービスを利用しようとしたユーザからの問い合わせを受けたとする。現時点で、コールセンターが、同じエリアＸから通信サービスを利用しようとしたユーザからの問い合わせを受けた場合に、エリアＸにおける通信サービスで異常が発生したことが検知される。この場合、サーバ１０は、管理者端末４０に対し、通信装置２０Ｃの状態を確認することを促す管理者画面ＳＣの表示データを送信する。

例えば、管理者端末４０は、管理者画面ＳＣの表示データを受信すると、通信装置２０Ｃの状態を確認することを促すメッセージを含む管理者画面ＳＣを表示部４５に表示させる。管理者画面ＳＣには、現在の通信装置２０Ｃの通信量を示すグラフが表示されてもよいし、過去に同様の異常が発生した時の通信装置２０Ｃの通信量を示すグラフが表示されてもよい。管理者は、管理者画面ＳＣを確認し、通信装置２０Ｃのメンテナンスを行う。通信装置２０Ｃのメンテナンス自体は、公知の方法で行われてもよい。

以上のように、監視システム１は、通信サービスで異常が発生して復旧した場合に、通信装置２０の通信量が飽和していたか否かを判定する。監視システム１は、通信装置２０の通信量が飽和していたか否かの判定結果に基づいて、通信サービスにおける異常に、通信装置２０の通信量が関係するか否かを判定する。例えば、同様の異常が再び発生した場合に、管理者が、異常の要因となった通信装置２０を特定しやすくなり、迅速に復旧作業を行うことができるようになる。以降、本実施形態の詳細を説明する。

［１－３．監視システムで実現される機能］
図５は、監視システム１で実現される機能の一例を示す図である。図５では、サーバ１０で実現される機能と、管理者端末４０で実現される機能と、が示されている。通信装置２０及びユーザ端末３０の各々の機能は、公知の通信サービスにおける機能と同様のため、図５では省略する。例えば、通信装置２０は、サーバ１０に対し、後述の状態データ又はその一部の情報を送信する機能を有する。ユーザ端末３０は、ユーザが通信サービスを利用するための機能を有する。

［１－３－１．サーバで実現される機能］
例えば、サーバ１０は、データ記憶部１００、状態データ取得部１０１、期間設定部１０２、正規化実行部１０３、飽和判定部１０４、関係判定部１０５、及び復旧処理実行部１０６を含む。データ記憶部１００は、記憶部１２により実現される。状態データ取得部１０１、期間設定部１０２、正規化実行部１０３、飽和判定部１０４、関係判定部１０５、及び復旧処理実行部１０６は、制御部１１により実現される。

［データ記憶部］
データ記憶部１００は、通信サービスに関するデータを記憶する。例えば、データ記憶部１００は、状態データベースＤＢを記憶する。

図６は、状態データベースＤＢの一例を示す図である。状態データベースＤＢは、複数の通信装置２０の各々の状態データが格納されたデータベースである。例えば、状態データベースＤＢには、複数の通信装置２０の各々の識別情報と、当該通信装置２０の状態を示す状態データと、が格納される。状態データベースＤＢには、他のデータが格納されてもよい。例えば、状態データベースＤＢには、飽和判定部の判定結果を示す情報、又は、関係判定部の判定結果を示す情報が格納されてもよい。

通信装置２０の識別情報は、任意の情報であってよく、例えば、ＩＰアドレス、装置名、又はＭＡＣアドレスであってもよい。状態データは、ある一時点における通信装置２０のピンポイントの状態を示してもよいが、本実施形態では、状態データは、通信装置２０の時系列的な状態の変化に関するデータである。通信装置２０の状態は、通信装置２０の負荷ということもできる。通信装置２０の状態は、ハードウェア的な状態を意味してもよいし、ソフトウェア的な状態を意味してもよい。

本実施形態では、通信装置２０の通信量が通信装置２０の状態に相当する場合を例に挙げるが、通信装置２０の他の状態が通信装置２０の状態に相当してもよい。他の状態としては、通信装置２０のリソースの消費量、サービスに対するリクエストの処理時間（レスポンスタイム）、又はリクエストに対して返されたエラーの数であってもよい。状態データは、ゴールデンシグナルメトリクスと呼ばれる指標であってもよいし、公知のベンチマークテストで利用されるその他の指標であってもよい。例えば、状態データは、ＣＰＵ使用量、メモリ使用量、電力消費量、通信速度、温度、又はこれらの組み合わせであってもよい。

なお、状態データは、通信サービス又は他のサービスにおける業績に関する状態を示してもよい。他のサービスは、ユーザが通信サービスを介して利用するサービスであり、例えば、電子商取引サービス、旅行予約サービス、決済サービス、又は金融サービスである。例えば、状態データは、通信装置２０に接続中（通信サービス又は他のサービスにログイン中）のユーザの数、ユーザが通信装置２０を経由して実行した決済、又はユーザが通信装置２０を経由して行った注文であってもよい。決済数、決済額、注文数、及び注文額が増えるほど、通信装置２０の負荷が高まるので、決済数、決済額、注文数、及び注文額も、通信装置２０の状態に相当する。

本実施形態では、状態データには、通信装置２０の時系列的な状態の変化が示されている。例えば、状態データは、通信装置２０の状態が取得された日時と、当該日時における通信装置２０の状態を示す数値と、を含む。通信装置２０の状態は、数値ではなく、文字等の他の形式で表現されてもよい。本実施形態では、通信装置２０の通信量が通信装置２０の状態に相当するので、状態データは、通信装置２０の通信量が取得された日時と、当該日時における通信装置２０の通信量と、を含む。

なお、データ記憶部１００に記憶されるデータは、状態データベースＤＢに限られない。データ記憶部１００は、通信サービスに関する何らかのデータを記憶すればよい。例えば、データ記憶部１００は、飽和判定部１０４の判定結果を示すデータを記憶してもよい。データ記憶部１００は、関係判定部１０５の判定結果を示すデータを記憶してもよい。データ記憶部１００は、管理者端末４０に管理者画面ＳＣを表示させるために必要なデータを記憶してもよい。データ記憶部１００は、後述の処理で利用される各種閾値を記憶してもよい。閾値は、管理者が指定してもよいし、機械学習の手法や統計的な手法に基づいて決定されてもよい。

［状態データ取得部］
状態データ取得部１０１は、状態データを取得する。例えば、状態データ取得部１０１は、複数の通信装置２０の各々に対し、定期的（例えば、１秒～３０秒程度、又は、１分～５分程度）に、当該通信装置２０の状態を要求する。通信装置２０は、サーバ１０から、状態データ取得部１０１の要求を受信すると、サーバ１０に対し、自身の識別情報と、自身の状態を示す情報と、を送信する。状態データ取得部１０１は、当該通信装置２０の識別情報に関連付けられた状態データに、現在の日時と、通信装置２０から受信した情報と、を追加する。

なお、通信装置２０は、ある程度の期間の状態データを蓄積して、サーバ１０に対し、一度に状態データを送信してもよい。この場合、状態データ取得部１０１は、通信装置２０から、一度に状態データを取得して状態データベースＤＢに格納する。他にも例えば、状態データ取得部１０１は、定期的ではなく不定期的に、通信装置２０から状態データを取得してもよい。状態データ取得部１０１は、管理者が指示したタイミングで、通信装置２０から状態データを取得してもよい。

通信装置２０は、通信サービスにおける監視対象となる装置の一例である。監視対象となる装置は、任意の装置であってよく、通信装置２０に限られない。本実施形態で通信装置２０と記載した箇所は、監視対象となる他の装置に読み替えることができる。他の装置は、通信サービスで利用されている装置であればよく、例えば、サーバ１０、サーバ１０以外の他のコンピュータ、サーバ１０及び他のコンピュータに含まれるＣＰＵ・メモリ・ネットワークカード等の部品、バッテリー、アンテナ、通信ケーブル、又はセンサであってもよい。

本実施形態では、状態データ取得部１０１は、異常が検知された場合に、状態データを取得する。異常が検知された場合に取得される状態データは、異常が発生してから解消するまでの期間の全部又は一部における状態を示す。以降、この期間を異常期間という。状態データは、異常期間の全部又は一部だけではなく、異常期間以外の他の期間における状態も示してもよい。状態データ取得部１０１は、異常が発生してから解消するまでの間に、状態データを取得してもよいし、異常が解消した後に、事後的に状態データを取得してもよい。

本実施形態では、状態データには、あるピンポイントのタイミングにおける状態が示されるのではなく、状態データには、ある程度の長さを有する期間における状態が示される。例えば、状態データ取得部１０１は、期間設定部１０２により設定された期間における装置の時系列的な状態の変化に関する状態データを取得する。本実施形態では、後述の期間設定部１０２により飽和期間、基準期間、及び異常期間といった３つの期間が設定されるので、状態データ取得部１０１は、飽和期間、基準期間、及び異常期間の各々における通信装置２０の状態を示す状態データを取得する。

なお、状態データ取得部１０１は、飽和期間、基準期間、及び異常期間以外の他の期間における通信装置２０の状態を示す状態データを取得してもよい。例えば、状態データ取得部１０１は、飽和期間よりも前における通信装置２０の状態を示す状態データを取得してもよい。状態データ取得部１０１は、基準期間及び異常期間よりも後における通信装置２０の状態を示す状態データを取得してもよい。状態データ取得部１０１は、異常が発生した異常発生タイミングに関係なく、通信装置２０の状態を示す状態データを取得してもよい。状態データ取得部１０１は、状態データベースＤＢに格納された状態データを、任意のタイミングで取得可能である。

［期間設定部］
期間設定部１０２は、状態データに関する期間を設定する。状態データに関する期間とは、後述の関係判定部１０５の判定で利用される期間である。状態データに状態が示された全ての期間が後述の関係判定部１０５の判定で利用されてもよいが、本実施形態では、状態データに状態が示された一部の期間だけが後述の関係判定部１０５の判定で利用されるものとする。期間を設定するとは、期間の開始時点及び終了時点を決定することである。

図７は、期間設定部１０２により設定される期間の一例を示す図である。本実施形態では、期間設定部１０２が、飽和期間Ｔ１、基準期間Ｔ２、及び異常期間Ｔ３といった３つの期間を設定する場合を例に挙げる。図７のタイムウィンドウＷは、状態データのうち、関係判定部１０５等の処理で利用される期間である。図７の例では、基準期間Ｔ２及び異常期間Ｔ３を合わせた期間がタイムウィンドウＷになる。

例えば、期間設定部１０２は、飽和期間Ｔ１、基準期間Ｔ２、及び異常期間Ｔ３のうちの何れか１つ又は２つだけを設定してもよい。即ち、期間設定部１０２は、飽和期間Ｔ１だけ、基準期間Ｔ２だけ、異常期間Ｔ３だけ、飽和期間Ｔ１及び基準期間Ｔ２だけ、飽和期間Ｔ１及び異常期間Ｔ３だけ、又は、基準期間Ｔ２及び異常期間Ｔ３だけを設定してもよい。期間設定部１０２は、飽和期間Ｔ１、基準期間Ｔ２、及び異常期間Ｔ３を設定せずに、タイムウィンドウＷだけを設定してもよい。

例えば、期間設定部１０２は、飽和判定部１０４の判定結果に基づいて、状態データに関する飽和期間Ｔ１を設定する。図７の例では、期間設定部１０２は、状態データが示す状態が飽和を開始した飽和開始タイミングｔ１から、状態データが示す状態が飽和を終了した飽和終了タイミングｔ２までの期間を、飽和期間Ｔ１として設定する。飽和開始タイミングｔ１は、状態データに状態が示された日時のうち、飽和判定部１０４が飽和を開始したと判定した日時である。飽和終了タイミングｔ２は、状態データに状態が示された日時のうち、飽和判定部１０４が飽和を終了したと判定した日時である。なお、期間設定部１０２は、飽和開始タイミングｔ１から飽和が終了していない（飽和が継続している）現在のタイミングまでの期間を飽和期間Ｔ１として設定してもよい。例えば、期間設定部１０２は、飽和開始タイミングｔ１から、管理者が指定した時点までの期間を飽和期間Ｔ１として設定してもよい。

例えば、期間設定部１０２は、異常が検知された場合に、異常が発生した異常発生タイミングｔ３に基づいて、状態データに関する基準期間Ｔ２及び異常期間Ｔ３を設定する。本実施形態では、異常が検知された場合に、管理者が、管理者端末４０から、異常が発生したことを示す異常発生操作を行う。例えば、管理者は、ユーザから、異常が発生したことを示す問い合わせを受け付けると、異常発生操作を行う。

例えば、サーバ１０は、管理者端末４０から、異常発生操作を示す異常発生データを受信したか否かを判定することによって、異常が発生したか否かを判定する。サーバ１０は、管理者端末４０から異常発生データを受信しない場合には、異常が発生したと判定しない。管理者端末４０から異常発生データを受信した場合に、異常が発生したと判定する。サーバ１０が異常発生データを受信したタイミングが異常発生タイミングｔ３である。

なお、管理者は、ユーザからの問い合わせではなく、他の判断要素に基づいて、異常発生操作を行ってもよい。例えば、管理者は、管理者画面ＳＣ又はその他の画面で、通信装置２０の状態データを目視で確認して異常発生操作を行ってもよい。異常の発生を推定するプログラムの実行結果が管理者画面ＳＣ又はその他の画面に表示される場合、管理者は、当該実行結果を目視で確認して異常発生操作を行ってもよい。

また、サーバ１０が異常の発生を検知する方法自体は、任意の方法であってよく、管理者による異常発生操作に限られない。例えば、サーバ１０は、異常の発生を検知するための異常検知プログラムの実行結果に基づいて、異常の発生を検知してもよい。異常検知プログラムは、状態データに基づいて、異常が発生したか否かを判定する。例えば、異常検知プログラムは、状態データが示す状態が基準範囲を超えた場合に、異常が発生したと判定する。

例えば、異常検知プログラムは、状態データが示す状態が基準範囲を超えた状態が所定時間以上継続した場合に、異常が発生したと判定してもよい。異常検知プログラムは、状態データが示す状態が基準範囲を超えた回数又は頻度が閾値以上になった場合に、異常が発生したと判定してもよい。この場合、異常検知プログラムが異常と判定したタイミングが異常発生タイミングｔ３である。

図７の例では、期間設定部１０２は、基準期間Ｔ２の基準となる基準タイミングｔ４から、異常が発生した異常発生タイミングｔ３までの期間を、基準期間Ｔ２として設定する。例えば、基準タイミングｔ４は、異常発生タイミングｔ３の所定時間だけ前のタイミングである。基準タイミングｔ４は、現時点の所定時間だけ前のタイミングであってもよいし、管理者が指定したタイミングであってもよい。

例えば、期間設定部１０２は、異常発生タイミングｔ３から、異常が解消した異常解消タイミングｔ５までの期間を、異常期間Ｔ３として設定する。異常解消タイミングｔ５は、異常が解消したと判定されたタイミングである。本実施形態では、異常が解消した場合に、管理者が、管理者端末４０から、異常が解消したことを示す異常解消操作を行う。例えば、管理者は、ユーザから、異常が発生したことを示す問い合わせを受け付けなくなると、異常解消操作を行う。

例えば、サーバ１０は、管理者端末４０から、異常解消操作を示す異常解消データを受信したか否かを判定することによって、異常が解消したか否かを判定する。サーバ１０は、管理者端末４０から異常解消データを受信しない場合には、異常が解消したと判定しない。管理者端末４０から異常解消データを受信した場合に、異常が解消したと判定する。サーバ１０が異常解消データを受信したタイミングが異常解消タイミングｔ５である。

なお、管理者は、ユーザからの問い合わせではなく、他の判断要素に基づいて、異常解消操作を行ってもよい。例えば、管理者は、管理者画面ＳＣ又はその他の画面で、通信装置２０の状態データを目視で確認して異常解消操作を行ってもよい。異常の解消を推定するプログラムの実行結果が管理者画面ＳＣ又はその他の画面に表示される場合、管理者は、当該実行結果を目視で確認して異常解消操作を行ってもよい。

また、サーバ１０が異常の解消を検知する方法自体は、任意の方法であってよく、管理者による異常解消操作に限られない。例えば、サーバ１０は、異常の解消を検知するための異常解消プログラムの実行結果に基づいて、異常の解消を検知してもよい。異常解消プログラムは、状態データに基づいて、異常が解消したか否かを判定する。例えば、異常解消プログラムは、状態データが示す状態が基準範囲に収まった場合に、異常が解消したと判定する。

例えば、異常解消プログラムは、状態データが示す状態が基準範囲に収まった状態が所定時間以上継続した場合に、異常が解消したと判定してもよい。異常解消プログラムは、状態データが示す状態が基準範囲に収まった回数又は頻度が閾値以上になった場合に、異常が解消したと判定してもよい。この場合、異常解消プログラムが異常解消と判定したタイミングが異常解消タイミングｔ５である。

［正規化実行部］
正規化実行部１０３は、状態データに関する正規化を実行する。例えば、正規化実行部１０３は、複数の通信装置２０の各々の状態データに基づいて、正規化を実行する。正規化実行部１０３は、複数の通信装置２０の各々の状態データが示す状態の数値が、ある一定の範囲内に収まるように、正規化を実行する。正規化実行部１０３は、公知の正規化手法に基づいて、正規化を実行すればよい。例えば、正規化手法は、ｚスコア正規化手法、又は、最小－最大正規化手法であってもよい。

［飽和判定部］
飽和判定部１０４は、状態データに基づいて、通信装置２０の時系列的な状態が飽和しているか否かを判定する。飽和とは、状態データが示す状態の変化量が閾値未満になること、又は、当該変化量が当該閾値未満の状態が所定時間以上継続することである。通信量のように、原則として上限値が存在しない場合、通信量が増加すれば、変化量は、主に増加量を意味する。そのため、ある期間で変化量の合計が増加した後に、状態データが示す状態の増加量が閾値未満になること、又は、当該増加量が当該閾値未満の状態が所定時間以上継続することが、飽和に相当する。変化量は、ある一定程度の期間における積算値であってもよいし、ある時点と次の時点の変化量であってもよい。変化量は、通信量の減少量を意味してもよい。つまり、飽和判定部１０４は、状態データが示す当該変化量そのものの時系列的な変化に基づいて、当該飽和の判定を行う。

例えば、飽和判定部１０４は、状態データが示す状態の増加量が閾値以上の状態から、当該増加量が閾値未満の状態、又は、当該増加量が閾値未満の状態が所定時間以上継続した状態になった場合に、通信装置２０の時系列的な状態が飽和していると判定する。飽和判定部１０４は、状態データが示す状態の増加量が閾値未満の状態、又は、当該増加量が閾値未満の状態が所定時間以上継続した状態になったとしても、その前において、当該増加量が閾値未満の状態であれば、通信装置２０の時系列的な状態が飽和していないと判定する。例えば、飽和判定部１０４は、状態データが示す状態が閾値以上であり、かつ、当該状態の増加量が閾値未満の状態、又は、当該増加量が閾値未満の状態が所定時間以上継続した状態になった場合に、通信装置２０の時系列的な状態が飽和していると判定してもよい。飽和判定部１０４は、状態データが示す状態の増加量が閾値未満の状態、又は、当該増加量が閾値未満の状態が所定時間以上継続した状態になったとしても、当該状態が閾値未満であれば、通信装置２０の時系列的な状態が飽和していないと判定する。

例えば、飽和判定部１０４は、複数の通信装置２０の各々の状態データと、予め定められた閾値と、に基づいて、当該通信装置２０の時系列的な状態が飽和しているか否かを判定する。別の言い方をすれば、飽和判定部１０４は、通信装置２０の状態データごとに、予め定められた閾値に基づいて、当該状態データが示す時系列的な状態が飽和しているか否かを判定する。飽和判定部１０４が飽和を判定する際に参照される閾値は、管理者が指定してもよいし、過去の異常の傾向から計算されてもよい。閾値は、機械学習の手法を利用したモデルに基づいて決定されてもよい。

なお、飽和判定部１０４は、閾値を利用せずに、機械学習の手法を利用したモデルに基づいて、通信装置２０の状態が飽和しているか否かを判定してもよい。この場合、モデルには、訓練用の状態データが示す時系列的な状態の変化を入力とし、当該状態が飽和しているか否かを示すラベルを出力とする訓練データが学習されている。飽和判定部１０４は、学習済みのモデルに判定対象の状態データを入力し、モデルから出力されたラベルに基づいて、通信装置２０の状態が飽和しているか否かを判定してもよい。

例えば、飽和判定部１０４は、ある通信装置２０の状態データが示す変化量が閾値以上であるか否かを判定することによって、当該通信装置２０の時系列的な状態が飽和しているか否かを判定する。飽和判定部１０４は、ある通信装置２０の状態データが示す変化量が閾値以上であると判定された場合には、当該通信装置２０の時系列的な状態が飽和していると判定しない。飽和判定部１０４は、ある通信装置２０の状態データが示す変化量が閾値未満であると判定された場合には、当該通信装置２０の時系列的な状態が飽和していると判定する。

例えば、飽和判定部１０４は、ある通信装置２０の状態データが示す変化量が閾値未満である状態が所定時間以上継続しているか否かを判定することによって、当該通信装置２０の時系列的な状態が飽和しているか否かを判定する。飽和判定部１０４は、ある通信装置２０の状態データが示す変化量が閾値未満である状態が所定時間以上継続していないと判定された場合には、当該通信装置２０の時系列的な状態が飽和していると判定しない。飽和判定部１０４は、ある通信装置２０の状態データが示す変化量が閾値未満である状態が所定時間以上継続していると判定された場合には、当該通信装置２０の時系列的な状態が飽和していると判定する。

本実施形態では、飽和判定部１０４は、異常が検知された場合に、通信装置２０の状態データに基づいて、当該通信装置２０の状態が飽和しているか否かを判定する。即ち、飽和判定部１０４は、異常が発生した後に、通信装置２０の状態データに基づいて、当該通信装置２０の状態が飽和しているか否かを判定する。例えば、飽和判定部１０４は、正規化が実行された状態データに基づいて、通信装置２０の状態が飽和しているか否かを判定する。飽和判定部１０４は、正規化が実行された状態データが示す状態に基づいて、通信装置２０の状態が飽和しているか否かを判定する。

なお、本実施形態では、飽和判定部１０４は、状態データが示す状態のうち、タイムウィンドウＷ内の状態に基づいて、当該状態が飽和しているか否かを判定する場合を説明する。飽和判定部１０４は、タイムウィンドウＷに関係なく、状態データが示す状態が飽和しているか否かを判定してもよい。例えば、飽和判定部１０４は、状態データが示す状態のうち、基準期間Ｔ２内の状態に基づいて、当該状態が飽和しているか否かを判定してもよい。飽和判定部１０４は、状態データが示す状態のうち、異常期間Ｔ３内の状態に基づいて、当該状態が飽和しているか否かを判定してもよい。飽和判定部１０４は、状態データが示す全期間の状態に基づいて、当該状態が飽和しているか否かを判定してもよい。

［関係判定部］
関係判定部１０５は、飽和判定部１０４の判定結果に基づいて、通信サービスにおける異常に状態データが関係するか否かを判定する。異常に状態データが関係するとは、異常と、状態データと、の間に相関関係があることである。異常が発生すると、状態データが示す状態が飽和する場合には、異常が状態データに関係する。異常が検知された場合に、状態データが示す状態が必ず飽和する必要はなく、異常と、状態データと、の間にある程度の相関関係があればよい。例えば、異常がｎ（ｎは、自然数）回発生した場合に、状態データが示す状態が飽和になっている回数がｋ（ｋは、ｎ以下の自然数）回以上である場合には、異常に状態データが関係する。ただし、ｋは、ｎの所定割合（例えば、７０％）以上であるものとする。

本実施形態では、関係判定部１０５は、異常が検知された場合に、異常に状態データが関係するか否かを判定する。即ち、関係判定部１０５は、異常が発生した後に、異常に状態データが関係するか否かを判定する。関係判定部１０５は、異常が解消する前に（即ち、異常期間Ｔ３中に）、異常に状態データが関係するか否かを判定してもよいが、本実施形態では、関係判定部１０５は、異常が解消した後に、異常に状態データが関係するか否かを判定する場合を例に挙げる。

例えば、関係判定部１０５は、状態データに変化が示された期間のうち、状態が飽和していると判定された飽和期間Ｔ１に基づいて、異常に状態データが関係するか否かを判定する。状態データに変化が示された期間とは、状態データが含むタイムスタンプの期間である。飽和期間Ｔ１は、飽和判定部１０４により通信装置２０の状態が飽和していると判定された期間である。即ち、飽和期間Ｔ１は、状態データが示す状態の変化量が閾値未満の期間、又は、状態データが示す状態の変化量が閾値未満の状態が継続している期間である。

例えば、関係判定部１０５は、状態データに変化が示された期間のうち、異常が発生している異常期間Ｔ３と、状態が飽和していると判定された飽和期間Ｔ１と、の一致度に基づいて、異常に状態データが関係するか否かを判定してもよい。ここでの一致度とは、飽和期間Ｔ１及び異常期間Ｔ３が重複する重複期間の長さ又は割合である。飽和期間Ｔ１及び異常期間Ｔ３が一致するほど、重複期間が長く又は重複期間の割合が高くなる。例えば、関係判定部１０５は、飽和期間Ｔ１及び異常期間Ｔ３が重複する重複期間を計算し、当該重複期間に基づいて、異常に状態データが関係するか否かを判定する。

例えば、関係判定部１０５は、重複期間の長さが閾値未満である場合には、異常に状態データが関係するとは判定せず、重複期間の長さが閾値以上である場合には、異常に状態データが関係すると判定する。閾値は、予め定められていてもよいし、飽和期間Ｔ１及び異常期間Ｔ３の少なくとも一方の長さに基づいて定められてもよい。例えば、関係判定部１０５は、重複期間が、飽和期間Ｔ１及び異常期間Ｔ３の少なくとも一方の所定割合（例えば、８割）未満であれば、異常に状態データが関係しないと判定し、重複期間が当該所定割合以上であれば、異常に状態データが関係すると判定してもよい。

なお、関係判定部１０５が、飽和期間Ｔ１に基づいて、異常に状態データが関係するか否かを判定する方法は、重複期間に基づく方法に限られない。例えば、関係判定部１０５は、飽和期間Ｔ１が異常発生タイミングｔ３を含むか否かを判定することによって、異常に状態データが関係するか否かを判定してもよい。この場合、関係判定部１０５は、飽和期間Ｔ１が異常発生タイミングｔ３を含まない場合には、異常に状態データが関係しないと判定し、飽和期間Ｔ１が異常発生タイミングｔ３を含む場合に、異常に状態データが関係すると判定してもよい。

他にも例えば、関係判定部１０５は、飽和期間Ｔ１の長さが閾値以上であるか否かを判定することによって、異常に状態データが関係するか否かを判定してもよい。関係判定部１０５は、飽和期間Ｔ１の長さが閾値未満である場合には、異常に状態データが関係しないと判定し、飽和期間Ｔ１の長さが閾値以上である場合に、異常に状態データが関係すると判定してもよい。

例えば、関係判定部１０５は、状態データに変化が示された期間のうち、異常が発生している異常期間Ｔ３よりも前の他の期間における状態の最高値に基づいて、異常に状態データが関係するか否かを判定してもよい。他の期間は、異常期間Ｔ３よりも前の期間であればよい。本実施形態では、基準期間Ｔ２が他の期間に相当する場合を例に挙げる。他の期間は、異常期間Ｔ３の直前でもよいし、異常期間Ｔ３の直前ではないが、異常期間Ｔ３からある程度前の期間であってもよい。他の期間は、基準期間Ｔ２よりも前の期間であってもよい。なお、異常期間Ｔ３は、異常発生タイミングｔ３から多少離れたタイミングを含んでもよい。最高値は、ある期間内における通信量の最大値である。

例えば、関係判定部１０５は、他の期間（本実施形態では、基準期間Ｔ２）における状態の最高値と、他の期間よりも前の期間における状態の最高値と、に基づいて、異常に状態データが関係するか否かを判定してもよい。他の期間よりも前の期間は、基準期間Ｔ２よりも前の期間である。例えば、他の期間よりも前の期間は、基準期間Ｔ２よりも前の全期間であってもよいし、基準期間Ｔ２よりも前の一部の期間であってもよい。最高値は、時系列的な変化のピークとなる値である。関係判定部１０５は、状態データベースＤＢを参照し、他の期間における最高値と、他の期間よりも前の期間における状態の最高値と、を取得する。

例えば、関係判定部１０５は、他の期間（本実施形態では、基準期間Ｔ２）における状態の最高値が、他の期間よりも前の期間における状態の最高値未満であるか否かを判定する。関係判定部１０５は、他の期間（本実施形態では、基準期間Ｔ２）における状態の最高値が、他の期間よりも前の期間における状態の最高値以上である場合には、異常に状態データが関係しないと判定し、他の期間（本実施形態では、基準期間Ｔ２）における状態の最高値が、他の期間よりも前の期間における状態の最高値未満である場合に、異常に状態データが関係すると判定する。

例えば、関係判定部１０５は、状態データに変化が示された期間のうち、異常が発生している異常期間Ｔ３における状態データが示す状態の最高値に基づいて、異常に状態データが関係するか否かを判定してもよい。関係判定部１０５は、異常期間Ｔ３における状態データが示す状態のうち、最高値を取得する。関係判定部１０５は、最高値が閾値未満であると判定された場合には、異常に状態データが関係するとは判定せず、最高値が閾値以上であると判定された場合に、異常に状態データが関係すると判定する。

例えば、関係判定部１０５は、状態データに変化が示された期間のうち、状態が飽和している飽和期間Ｔ１と、異常が発生している異常期間Ｔ３よりも前の他の期間と、の各々における状態の変化量に基づいて、異常に状態データが関係するか否かを判定してもよい。先述したように、基準期間Ｔ２は、他の期間の一例である。関係判定部１０５は、飽和期間Ｔ１における状態の変化量と、他の期間における状態の変化量と、の差が閾値以上であるか否かを判定する。関係判定部１０５は、当該差が閾値未満であると判定された場合には、異常に状態データが関係するとは判定せず、当該差が閾値以上であると判定された場合に、異常に状態データが関係すると判定する。

なお、関係判定部１０５は、上記説明した判定方法以外の他の判定方法に基づいて、異常に状態データが関係するか否かを判定してもよい。例えば、関係判定部１０５は、異常期間Ｔ３において状態データが示す状態が飽和しているが、異常が発生していない期間でも当該状態が飽和している場合には、定常的に飽和が発生する状態データなので、異常に状態データが関係しないと判定してもよい。一方、関係判定部１０５は、異常が発生していない期間では状態データが示す状態が飽和していないが、異常期間Ｔ３において状態データが示す状態が飽和している場合には、異常期間Ｔ３にだけ飽和が発生するので、異常に状態データが関係しないと判定してもよい。

［復旧処理実行部］
復旧処理実行部１０６は、異常が検知された場合に、異常に関係すると判定された状態データに基づいて、異常の復旧に関する復旧処理を実行する。復旧処理は、発生した異常に関係する何らかの処理であればよい。本実施形態では、異常に関係する状態データを管理者画面ＳＣに表示させる処理が復旧処理に相当する。復旧処理は、他の処理であってもよく、例えば、予め用意された復旧のためのプログラムを実行する処理、又は、管理者に電子メール等の通知を送信する処理であってもよい。

例えば、復旧処理実行部１０６は、異常が検知された場合に、管理者端末４０に対し、管理者画面ＳＣの表示データを送信することによって、管理者端末４０に管理者画面ＳＣを表示させる。復旧処理実行部１０６は、異常が検知された場合に、異常と関係する状態データを示す画像を、管理者画面ＳＣに表示させる。図４の例では、ある異常が発生した場合に、復旧処理実行部１０６は、過去に同じ以上が発生した場合に関係判定部１０５により判定された状態データが示す状態を、管理者画面ＳＣに表示させる。復旧処理実行部１０６は、ある異常が発生して当該異常と関係する状態データが特定された場合に、同じ異常が発生すると、当該異常と関係する状態データに基づいて、復旧処理を実行する。

［１－３－２．管理者端末で実現される機能］
例えば、管理者端末４０は、データ記憶部４００、操作受付部４０１、及び表示制御部４０２を含む。データ記憶部４００は、記憶部４２を主として実現される。操作受付部４０１及び表示制御部４０２は、制御部４１を主として実現される。

［データ記憶部］
データ記憶部４００は、管理者の業務に必要なデータを記憶する。例えば、データ記憶部４００は、管理者画面ＳＣを表示するために必要なデータを記憶する。データ記憶部４００は、管理者の業務に必要なメンテナンスツールを記憶してもよい。メンテナンスツール自体は、公知のツールであってよく、例えば、ハードウェア及びソフトウェアの少なくとも一方の状態を監視可能なツールであればよい。

［操作受付部］
操作受付部４０１は、管理者による各種操作を受け付ける。例えば、操作受付部４０１は、管理者画面ＳＣに対する操作を受け付ける。

［表示制御部］
表示制御部４０２は、各種画面を表示部４５に表示させる。例えば、表示制御部４０２は、管理者画面ＳＣを表示部４５に表示させる。

［１－４．監視システムで実行される処理］
図８は、監視システム１で実行される処理の一例を示す図である。制御部１１，４１が、それぞれ記憶部１２，４２に記憶されたプログラムを実行することによって、図８の処理が実行される。

図８のように、サーバ１０は、複数の通信装置２０の各々と通信し、状態データを取得して状態データベースＤＢに格納する（Ｓ１）。異常が発生すると、管理者端末４０は、管理者による異常発生操作を受け付ける（Ｓ２）。管理者端末４０は、サーバ１０に対し、異常発生操作が行われたことを示す異常発生データを送信する（Ｓ３）。サーバ１０は、管理者端末４０から、異常発生データを受信する（Ｓ４）。サーバ１０は、異常発生データを受信したタイミングを、異常が発生した異常発生タイミングｔ３として記憶部１２に記録する（Ｓ５）。なお、管理者が異常発生タイミングｔ３を指定してもよい。この場合、サーバ１０は、管理者が指定した異常発生タイミングｔ３を記憶部１２に記録する。

異常が解消すると、管理者端末４０は、管理者による異常解消操作を受け付ける（Ｓ６）。管理者端末４０は、サーバ１０に対し、異常解消操作が行われたことを示す異常解消データを送信する（Ｓ７）。サーバ１０は、管理者端末４０から、異常解消データを受信する（Ｓ８）。サーバ１０は、異常解消データを受信したタイミングを、異常が解消した異常解消タイミングｔ５として記憶部１２に記録する（Ｓ９）。なお、管理者が異常解消タイミングｔ５を指定してもよい。この場合、サーバ１０は、管理者が指定した異常解消タイミングｔ５を記憶部１２に記録する。

サーバ１０は、異常発生タイミングｔ３の所定時間前である基準タイミングｔ４から異常発生タイミングｔ３までの期間を、基準期間Ｔ２として設定する（Ｓ１０）。サーバ１０は、異常発生タイミングｔ３から異常解消タイミングｔ５までの期間を、異常期間Ｔ３として設定する（Ｓ１１）。サーバ１０は、状態データベースＤＢを参照し、異常発生タイミングｔ３を含む期間の状態データを、判定対象の状態データとして取得する（Ｓ１２）。判定対象の状態データは、Ｓ１３以降の処理の対象となる状態データである。以降の処理は、状態データごとに実行される。

サーバ１０は、判定対象の状態データを正規化する（Ｓ１３）。Ｓ１３では、サーバ１０は、正規化以外にも、判定対象の状態データに対し、標準化処理又は平滑化処理等の前処理を実行してもよい。他にも例えば、サーバ１０は、判定対象の状態データが示す状態が所定の閾値未満である場合には、Ｓ１４以降の処理を実行しないようにしてもよい。

サーバ１０は、正規化が実行された判定対象の状態データが示す状態が飽和しているか否かを判定する（Ｓ１４）。Ｓ１４では、サーバ１０は、状態データが示す状態の時系列的な変化量を計算する。サーバ１０は、時系列的な変化量が閾値未満の状態が継続している場合に、状態データが示す状態が飽和していると判定する。サーバ１０は、時系列的な変化量が閾値以上である場合、又は、時系列的な変化量が閾値未満の状態が継続していない場合に、状態データが示す状態が飽和していないと判定する。

Ｓ１４において、判定対象の状態データが示す状態が飽和していると判定されない場合（Ｓ１４：Ｎ）、サーバ１０は、判定対象の状態データが異常に関係ないと判定し（Ｓ１５）、Ｓ２１の処理に移行する。Ｓ１４において、判定対象の状態データが示す状態が飽和していると判定された場合（Ｓ１４：Ｙ）、サーバ１０は、飽和開始タイミングｔ１から飽和終了タイミングｔ２までの期間を、飽和期間Ｔ１として設定する（Ｓ１６）。

サーバ１０は、判定対象の状態データの基準期間Ｔ２における最高値である第１最高値が、当該状態データの基準期間Ｔ２よりも過去の期間における最高値である第２最高値以上であるか否かを判定する（Ｓ１７）。Ｓ１７において、第１最高値が第２最高値以上であると判定された場合（Ｓ１７：Ｙ）、サーバ１０は、Ｓ１５に移行し、判定対象の状態データが異常に関係ないと判定する。

Ｓ１７において、第１最高値が第２最高値未満であると判定された場合（Ｓ１７：Ｎ）、サーバ１０は、判定対象の状態データの異常期間Ｔ３における第３最高値が、第１最高値又は第２最高値以上であるか否かを判定する（Ｓ１８）。ここでは、サーバ１０が、第３最高値と、第１最高値又は第２最高値と、を比較する場合（即ち、第１最高値又は第２最高値の何れか一方だけが比較対象になる場合）を説明するが、サーバ１０が、第３最高値と、第１最高値及び第２最高値と、を比較してもよい。

Ｓ１８において、異常期間Ｔ３における最高値が第１最高値又は第２最高値未満であると判定された場合（Ｓ１８：Ｎ）、サーバ１０は、Ｓ１５に移行し、判定対象の状態データが異常に関係ないと判定する。Ｓ１８において、異常期間Ｔ３における最高値である第３最高値が第１最高値又は第２最高値以上であると判定された場合（Ｓ１８：Ｙ）、サーバ１０は、飽和期間Ｔ１及び異常期間Ｔ３の一致度が閾値以上であるか否かを判定する（Ｓ１９）。Ｓ１９において、飽和期間Ｔ１及び異常期間Ｔ３の一致度が閾値未満であると判定された場合（Ｓ１９：Ｎ）、サーバ１０は、Ｓ１５に移行し、判定対象の状態データが異常に関係ないと判定する。

Ｓ１９において、飽和期間Ｔ１及び異常期間Ｔ３の一致度が閾値以上であると判定された場合（Ｓ１９：Ｙ）、サーバ１０は、判定対象の状態データを、異常に関係のある状態データの候補として記憶部１２に記録する（Ｓ２０）。サーバ１０は、全ての状態データが判定対象になったか否かを判定する（Ｓ２１）。Ｓ２１において、まだ判定対象になっていない状態データが存在する場合（Ｓ２１：Ｎ）、Ｓ１２の処理に戻り、次の判定対象の状態データに対する処理が実行される。

Ｓ２１において、全ての状態データを判定したと判定された場合（Ｓ２１：Ｙ）、サーバ１０は、Ｓ２０で候補として記録された状態データの中から、異常に関係ある状態データとして判定し（Ｓ２２）、本処理は終了する。Ｓ２２では、サーバ１０は、Ｓ２０で候補として記録された状態データの各々の飽和期間Ｔ１及び基準期間Ｔ２における変化量等に基づいて、当該状態データと異常との関係度合いを示す特徴量を計算し、当該特徴量が高い順に所定数の状態データを、異常に関係ある状態データとして判定する。なお、Ｓ２２の処理が実行されずに、Ｓ２０で候補として記録された状態データが、そのまま異常に関係ある状態データとして判定されてもよい。

［１－５．実施形態のまとめ］
本実施形態の監視システム１は、通信装置２０の時系列的な状態の変化に関する状態データに基づいて、通信装置２０の状態が飽和しているか否かを判定する。監視システム１は、当該判定結果に基づいて、通信サービスにおける異常に状態データが関係するか否かを判定する。これにより、監視システム１は、通信サービスにおける異常に状態データが関係するか否かを判定できる。その結果、例えば、監視システム１は、異常の復旧を早めることができる。他にも例えば、監視システム１は、異常を迅速に検知したり、異常の要因を分析したりするといったことも可能になる。

また、監視システム１は、異常が検知された場合に、状態データの取得、通信装置２０の状態が飽和しているか否かの判定、及び異常に状態データが関係するか否かの判定を実行する。監視システム１は、異常が検知された場合に、異常に関係すると判定された状態データに基づいて、復旧処理を実行する。これにより、監視システム１は、異常が検知された場合の復旧を早めることができる。

また、監視システム１は、異常が検知された場合に、異常が発生した異常発生タイミングｔ３に基づいて、状態データに関する期間を設定する、監視システム１は、期間における通信装置２０の時系列的な状態の変化に関する状態データを取得する。これにより、監視システム１は、異常に関係のある期間における状態データに基づいて、異常に状態データが関係するか否かを判定できるので、判定精度が高まる。監視システム１は、異常に関係する状態データを精度よく特定することによって、異常の復旧を早めることができる。

また、監視システム１は、正規化が実行された状態データに基づいて、状態が飽和しているか否かを判定する。これにより、監視システム１は、通信装置２０ごとに通信量が変化する範囲が変わったとしても、その範囲を正規化によって吸収できるので、異常に状態データが関係するか否かの判定精度を高めることができる。

また、監視システム１は、状態データに変化が示された期間のうち、状態が飽和していると判定された飽和期間Ｔ１に基づいて、異常に状態データが関係するか否かを判定する。これにより、監視システム１は、飽和期間Ｔ１といった異常に直結する可能性が高い期間を利用して異常に状態データが関係するか否かを判定できるので、異常に状態データが関係するか否かの判定精度を高めることができる。

また、監視システム１は、状態データに変化が示された期間のうち、異常が発生している異常期間Ｔ３よりも前の他の期間における状態の最高値に基づいて、異常に状態データが関係するか否かを判定する。これにより、監視システム１は、例えば、異常が発生していない時から定常的に通信量が高くなるか否かを考慮したうえで、異常に状態データが関係するか否かを判定できるので、異常に状態データが関係するか否かの判定精度を高めることができる。

また、監視システム１は、異常期間Ｔ３よりも前の他の期間における状態の最高値と、他の期間よりも前の期間における状態の最高値と、に基づいて、異常に状態データが関係するか否かを判定する。これにより、監視システム１は、例えば、異常が発生していない時から定常的に通信量が高くなるか否かを考慮したうえで、異常に状態データが関係するか否かを判定できるので、異常に状態データが関係するか否かの判定精度を高めることができる。

また、監視システム１は、状態データに変化が示された期間のうち、異常が発生している異常期間Ｔ３における状態データが示す状態の最高値に基づいて、異常に状態データが関係するか否かを判定する。状態データが示す状態が飽和していたとしても、あまり高い値でなければ当該状態が異常に関係しない可能性があるので、監視システム１は、異常期間Ｔ３における状態データが示す状態の最高値を考慮して異常に状態データが関係するか否かを判定することによって、異常に状態データが関係するか否かの判定精度を高めることができる。

また、監視システム１は、状態データに変化が示された期間のうち、異常が発生している異常期間Ｔ３と、状態が飽和していると判定された飽和期間Ｔ１と、の一致度に基づいて、異常に状態データが関係するか否かを判定する。飽和期間Ｔ１及び異常期間Ｔ３の一致度が高いほど、異常に状態データが関係している度合いが高いと考えられるので、監視システム１は、一致度を利用することによって、異常に状態データが関係するか否かの判定精度を高めることができる。

また、監視システム１は、状態データに変化が示された期間のうち、状態が飽和している飽和期間Ｔ１と、異常が発生している異常期間Ｔ３よりも前の他の期間と、の各々における状態の変化量に基づいて、異常に状態データが関係するか否かを判定する。これにより、監視システム１は、ある状態データが示す状態が飽和していたとしても、定常的に飽和しやすい状態なのかを考慮したうえで、異常に状態データが関係するか否かを判定できるので、異常に状態データが関係するか否かの判定精度を高めることができる。

［１－６．変形例］
本開示は、以上に説明した実施形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。

［１－６－１．変形例１－１］
図９は、変形例１－１の監視システム１で実現される機能の一例を示す図である。変形例１－１の監視システム１は、検知処理実行部１０７を含む。検知処理実行部１０７は、制御部１１により実現される。例えば、実施形態では、異常が検知された場合に一連の処理が実行される場合を説明したが、一連の処理は、異常が検知される前に実行されてもよい。変形例１－１では、飽和判定部１０４の判定結果が異常の検知に利用される場合を説明する。なお、変形例１－１では、状態データのうち、一連の処理で利用される期間（図７のタイムウィンドウＷに相当する期間）は、現時点の所定期間（例えば、１５分程度）だけ前の時点から現時点までの期間とする。

変形例１－１の状態データ取得部１０１は、異常が検知される前に、状態データを取得する。状態データ取得部１０１による状態データの取得方法は、実施形態と同様である。状態データ取得部１０１は、通信サービスの稼働中にリアルタイムで状態データを取得する。状態データ取得部１０１は、異常の発生有無に関係なく、状態データを取得する。変形例１－１の飽和判定部１０４は、異常が検知される前に、状態データに基づいて、状態が飽和しているか否かを判定する。飽和判定部１０４による飽和の判定方法も、実施形態と同様である。飽和判定部１０４は、異常の発生有無に関係なく、状態データが示す状態が飽和しているか否かを判定する。

変形例１－１の関係判定部１０５は、異常が検知される前に、異常に状態データが関係するか否かを判定する。関係判定部１０５は、異常の発生有無に関係なく、状態データが示す状態が異常に関係するか否かを判定する。例えば、関係判定部１０５は、状態データが示す状態が飽和していないと判定された場合には、当該状態が異常に関係しないと判定し、状態データが示す状態が飽和していると判定された場合には、当該状態が異常に関係すると判定する。

検知処理実行部１０７は、異常に関係すると判定された状態データに基づいて、異常の検知に関する検知処理を実行する。検知処理は、発生した異常を検知する何らかの処理であればよい。変形例１－１では、異常の発生を管理者画面ＳＣに表示させる処理が検知処理に相当する。例えば、検知処理実行部１０７は、異常が検知された場合に、異常が検知されたことを示す画像を、管理者画面ＳＣに表示させる。検知処理実行部１０７は、管理者に対し、電子メール等の手段を利用して通知を送信することによって、検知処理を実行してもよい。

変形例１－１の監視システム１は、異常が検知される前に、状態データの取得、通信装置２０の状態が飽和しているか否かの判定、及び異常に状態データが関係するか否かの判定を実行する。監視システム１は、異常に関係すると判定された状態データに基づいて、異常の検知に関する検知処理を実行する。これにより、監視システム１は、迅速に異常を検知できる。

［１－６－２．変形例１－２］
例えば、監視システム１は、通信サービス以外の他のサービスにも適用可能である。例えば、監視システム１は、電子商取引サービス、旅行予約サービス、金融サービス、決済サービス、オンラインフリーマーケットサービス、又は動画配信サービスといった他のサービスにおける異常に、当該他のサービスにおける装置の状態データが関係するか否かを判定してもよい。

例えば、監視システム１は、複数のサービスの各々における異常に、当該サービス又は他のサービスにおける装置の状態データが関係するか否かを判定してもよい。監視システム１は、クラウドインフラストラクチャ又はクラウドプラットフォームにおけるテナントと読み換えられる。監視システム１は、ソフトウェア構成又はハードウェア構成を含むオファリングサービス群から選択される複数のオファリングサービスによって構成される。

変形例１－２の状態データ取得部１０１は、複数のサービスの各々における装置の状態データを取得する。状態データ取得部１０１が個々のサービスにおける装置の状態データを取得する処理は、実施形態と同様であってよい。状態データ取得部１０１は、複数のサービスの各々の装置と通信し、当該装置の状態データを取得する。

変形例１－２の飽和判定部１０４は、複数のサービスの各々における装置の状態データに基づいて、当該装置が飽和しているか否かを判定する。飽和判定部１０４が個々のサービスにおける装置の状態データに基づいて飽和を判定する処理は、実施形態と同様であってよい。

変形例１－２の関係判定部１０５は、飽和判定部１０４の判定結果に基づいて、複数のサービスの各々における異常に状態データが関係するか否かを判定する。関係判定部１０５が個々のサービスにおける異常に状態データが関係するか否かを判定する処理は、実施形態と同様であってよい。

変形例１－２の監視システム１は、複数のサービスの各々における装置の状態データを取得する。監視システム１は、複数のサービスの各々における装置の状態データに基づいて、装置が飽和しているか否かを判定する。監視システム１は、当該判定結果に基づいて、複数のサービスの各々における異常に状態データが関係するか否かを判定する。これにより、監視システム１は、複数のサービスの各々の異常に対応できる。

［１－６－３．その他の変形例］
例えば、上記変形例を組み合わせてもよい。

例えば、実施形態では、サーバ１０で主な処理が実行される場合を説明したが、サーバ１０で実行されるものとして説明した処理は、管理者端末４０又は他のコンピュータで実行されてもよいし、複数のコンピュータで分担されてもよい。

［２．第２実施形態］
本開示に係る監視システム１の別実施形態の一例である第２実施形態を説明する。第２実施形態では、サービスにおける異常に関する処理の一例を説明する。従来の技術は、システムにおける種々の装置のうち、予め定められた装置の状態に基づいて復旧手順を特定することしかできない。システムに発生した異常には、種々の装置が関係していることがある。複数の装置の各々の状態データが密接に関連していたとしても、従来の技術は、これらの関連性を特定できない。そこで、第２実施形態の監視システム１は、サービスにおける監視対象となる装置の状態に関する状態データの関連性を特定する。

［２－１．第２実施形態の監視システムのハードウェア構成］
第２実施形態の監視システム１のハードウェア構成は、第１実施形態と同様であってよい。

［２－２．監視システムの概要］
本実施形態では、通信装置２０が、コンテナ化されたネットワーク機能であるＣＮＦ（Containerized Network Function）を有するサーバコンピュータである場合を例に挙げる。更に、ユーザ端末３０がスマートフォンである場合を例に挙げる。通信装置２０は、多数のユーザ端末３０の通信を中継する。例えば、通信装置２０が処理すべき通信量が、当該通信装置２０が処理可能な通信量に達すると、通信サービスで異常が発生する可能性がある。通信量は、ｂｐｓ等の公知の指標によって表現可能である。

例えば、通信サービスで異常が発生すると、管理者は、異常に関係する通信装置２０を特定して復旧作業を行う。しかしながら、通信サービスでは、ある１つの通信装置２０だけではなく、複数の通信装置２０が異常に関係することがある。例えば、特定のエリアで通信サービスの異常が発生した場合に、管理者が異常の要因として特定した通信装置２０以外にも、当該通信装置２０と関連性のある他の通信装置２０が異常に関係している可能性がある。管理者が、異常に関係する全ての通信装置２０を自力で特定するのは難しい。

例えば、通信装置２０が処理する通信量が閾値以上になった場合に異常を検知することも考えられるが、管理者が定めた上限値よりも多くの通信量を通信装置２０が処理可能な場合や、管理者が定めた上限値よりも低い通信量しか通信装置２０が処理できない場合もある。更に、管理者自身、通信装置２０の上限値を知らない場合もあるので、本実施形態では、異常と判定するための通信量の上限値が定められていない。このため、通信装置２０の通信量が一定程度に達したとしても、必ずしも異常に該当するとは限らない。

本実施形態では、サーバ１０は、通信サービスにおいて発生した異常に関係する通信装置２０の通信量と似た特徴を有する他の通信装置２０の通信量を特定する。例えば、異常に関係する通信装置２０は、管理者による分析によって特定される。後述の変形例のように、異常に関係する通信装置２０は、通信量の飽和によって特定されてもよい。上記他の通信装置２０は、異常と関係している可能性があるので、上記他の通信装置２０を特定することは、異常の検知や復旧等に有用である。

図１０は、通信サービスで異常が検知された場合の通信装置２０の時系列的な通信量の変化の一例を示す図である。図１０の横軸は、時間軸である。図１０の縦軸は、通信量を示す軸である。図１０の例では、通信事業者の施設に配置された５台の通信装置２０Ａ～２０Ｅの各々の通信量の変化が示されている。以降、通信装置２０Ａ～２０Ｅを区別しない時は、単に通信装置２０という。

図１０の例では、ある特定の時点で、通信装置２０Ａの通信量が急激に増加する。その後、通信装置２０Ａは、ある一定量以上の通信を処理できなくなり、通信量が飽和する。この場合、ある特定のエリアで通信装置２０Ａに接続を試みたユーザ端末３０が、通信サービスを利用できなくなる。即ち、当該エリアにおける通信サービスに異常が発生する。ユーザは、通信サービスのコールセンターに連絡し、通信サービスを利用できないことを伝えることがある。

例えば、管理者は、複数のユーザからの問い合わせを受けて、異常が発生していることを把握する。この時点では、管理者は、どの通信装置２０が異常の要因であるかを特定しておらず、その後、通信装置２０Ａの通信量が下がり、異常が自然復旧したとする。更に、管理者は、ユーザからの問い合わせを受けなくなり、異常が自然復旧したことを把握する。異常が自然復旧すると、ユーザ端末３０が通信装置２０Ａを介して通信サービスを利用できるようになる。

例えば、管理者は、ある特定のエリアで発生した異常が発生して解消した後に、通信装置２０Ａ～２０Ｅの各々の通信量を解析する。管理者は、当該異常が発生していた期間において、通信装置２０Ａの通信量が急激に増加して飽和していたことを特定する。管理者は、管理者端末４０に対し、上記エリアで発生した異常に、通信装置２０Ａの通信量が関係することを示す情報を入力する。管理者端末４０は、サーバ１０に対し、当該情報をアップロードする。サーバ１０は、上記エリアと、通信装置２０Ａの通信量が当該エリアの異常に関係していることと、を関連付けて記憶する。

例えば、サーバ１０は、通信装置２０Ａ～２０Ｅの各々をクラスタリングすることによって、通信装置２０Ｂ～２０Ｅの各々の状態データの中から、通信装置２０Ａの状態データと関連性のある状態データがあるか否かを判定する。図１０の例であれば、クラスタリングによって、通信装置２０Ａの通信量の特徴と、通信装置２０Ｅの通信量の特徴と、が似ていることが特定される。

例えば、サーバ１０は、あるエリアにおける異常に、管理者が指定した通信装置２０Ａだけではなく、クラスタリングによって特定された通信装置２０Ｅも関係していることを記憶部１２に記録する。サーバ１０は、当該エリアで再び異常が発生した場合に、管理者端末４０に対し、通信装置２０Ａだけではなく、通信装置２０Ｅの状態もチェックすることを促す通知を送信する。

図１１は、管理者端末４０に表示される通知の一例を示す図である。例えば、過去に通信装置２０Ａの通信量に異常が見られた場合に、通信サービスのコールセンターが、ある特定のエリアＸから通信サービスを利用しようとしたユーザからの問い合わせを受けたとする。現時点で、コールセンターが、同じエリアＸで通信サービスを利用しようとしたユーザからの問い合わせを受けた場合に、エリアＸにおける通信サービスで異常が発生したことが検知される。この場合、サーバ１０は、管理者端末４０に対し、管理者が指定した通信装置２０Ａと、クラスタリングによって特定された通信装置２０Ｅと、を確認することを促す管理者画面ＳＣの表示データを送信する。

例えば、管理者端末４０は、管理者画面ＳＣの表示データを受信すると、通信装置２０Ａの通信量と、通信装置２０Ａの通信量と関連性のある通信装置２０Ｅの通信量と、を確認することを促すメッセージが表示される。管理者画面ＳＣには、現在の通信装置２０Ａ，２０Ｅの各々の通信量を示すグラフが表示されてもよいし、過去に同様の異常が発生した時の通信装置２０Ａ，２０Ｅの各々の通信量を示すグラフが表示されてもよい。管理者は、管理者画面ＳＣを確認し、通信装置２０Ａ，２０Ｅのメンテナンスを行う。通信装置２０Ａ，２０Ｅの各々のメンテナンス自体は、公知の方法で行われてもよい。

以上のように、監視システム１は、通信サービスで異常が発生した場合に、異常と関係がある通信装置２０Ａと関連性のある通信装置２０Ｅを、クラスタリングによって特定する。例えば、監視システム１は、同様の異常が再び発生した場合に、管理者が、異常の要因となった通信装置２０を特定しやすくなるので、迅速に復旧作業を行うことができる。以降、監視システム１の詳細を説明する。

［２－３．監視システムで実現される機能］
図１２は、監視システム１で実現される機能の一例を示す図である。図１２では、サーバ１０で実現される機能と、管理者端末４０で実現される機能と、が示されている。通信装置２０及びユーザ端末３０の各々の機能は、公知の通信サービスにおける機能と同様のため、図１２では省略する。例えば、通信装置２０は、サーバ１０に対し、後述の状態データ又はその一部の情報を送信する機能を有する。ユーザ端末３０は、ユーザが通信サービスを利用するための機能を有する。

［２－３－１．サーバで実現される機能］
例えば、サーバ１０は、データ記憶部１００、状態データ取得部１０１、クラスタリング実行部１０８、関連データ特定部１０９、及び復旧処理実行部１０６を含む。データ記憶部１００は、記憶部１２により実現される。状態データ取得部１０１、クラスタリング実行部１０８、関連データ特定部１０９、及び復旧処理実行部１０６は、制御部１１により実現される。

図１３は、状態データベースＤＢの一例を示す図である。状態データベースＤＢは、複数の通信装置２０の各々の状態データが格納されたデータベースである。例えば、状態データベースＤＢには、複数の通信装置２０の各々を識別可能な装置識別情報、当該通信装置２０の状態を示す状態データ、後述の異常要因データに該当するか否かを識別可能な異常要因識別情報、及び後述の関連データに該当するか否かを識別可能な関連識別情報が格納される。状態データベースＤＢには、他のデータが格納されてもよい。例えば、状態データベースＤＢには、通信装置２０が配置された場所等を示す情報が格納されてもよい。

通信装置２０の識別情報は、任意の情報であってよく、例えば、ＩＰアドレス、装置名、又はＭＡＣアドレスであってもよい。状態データは、本実施形態では、状態データは、通信装置２０の時系列的な状態の変化に関するデータである。通信装置２０の状態は、通信装置２０の負荷ということもできる。通信装置２０の状態は、ハードウェア的な状態を意味してもよいし、ソフトウェア的な状態を意味してもよい。

本実施形態では、複数の通信装置２０の各々の状態データは、通信装置２０の時系列的な状態の変化を示す。例えば、状態データは、通信装置２０の状態が取得された日時と、当該日時における通信装置２０の状態を示す数値と、を含む。通信装置２０の状態は、数値ではなく、文字等の他の形式で表現されてもよい。本実施形態では、通信装置２０の通信量が通信装置２０の状態に相当するので、状態データは、通信装置２０の通信量が取得された日時と、当該日時における通信装置２０の通信量と、を含む。

なお、複数の通信装置２０の各々の状態データは、通信装置２０の時系列的な状態の変化ではなく、あるピンポイント（１時点）における状態を示してもよい。例えば、ある状態データは、時系列的な状態の変化を示し、他の状態データは、あるピンポイントにおける状態を示してもよい。あるピンポイントにおける状態を示す状態データが多数集まることによって、多数の状態データの全体として、時系列的な状態の変化が示されてもよい。

また、データ記憶部１００に記憶されるデータは、状態データベースＤＢに限られない。データ記憶部１００は、通信サービスに関する何らかのデータを記憶すればよい。例えば、データ記憶部１００は、管理者端末４０に管理者画面ＳＣを表示させるために必要なデータを記憶してもよい。データ記憶部１００は、後述の処理で利用される各種閾値を記憶してもよい。閾値は、管理者が指定してもよいし、機械学習の手法や統計的な手法に基づいて決定されてもよい。

［状態データ取得部］
状態データ取得部１０１は、通信サービスにおける監視対象となる複数の通信装置２０の各々の状態に関する状態データを取得する。例えば、状態データ取得部１０１は、複数の通信装置２０の各々に対し、定期的（例えば、１秒～３０秒程度、又は、１分～５分程度）に、当該通信装置２０の状態を要求する。通信装置２０は、サーバ１０から、状態データ取得部１０１の要求を受信すると、サーバ１０に対し、自身の装置識別情報と、自身の状態を示す情報と、を送信する。状態データ取得部１０１は、当該通信装置２０の装置識別情報に関連付けられた状態データに、現在の日時と、通信装置２０から受信した情報と、を追加する。

本実施形態では、状態データには、あるピンポイントのタイミングにおける状態が示されるのではなく、状態データには、ある程度の長さを有する期間における状態が示される。状態データ取得部１０１は、過去の全期間における状態を示す状態データを取得してもよいが、本実施形態では、過去の一部の期間における状態を示す状態データを取得するものとする。例えば、状態データ取得部１０１は、異常が検知された時点を含む期間における装置の時系列的な状態の変化に関する状態データを取得する。

［クラスタリング実行部］
クラスタリング実行部１０８は、複数の通信装置２０の各々の状態データに関するクラスタリングを実行する。クラスタリングは、互いに似た特徴を有する状態データを特定する処理である。クラスタリングは、グルーピングと呼ばれることもある。クラスタリング実行部１０８は、互いに似た特徴を有する状態データが同じクラスタに属するように、クラスタリングを実行する。あるクラスタに属する複数の状態データの各々は、互いに似た特徴を示す。クラスタの数は、予め定められていてもよいし、特に定められていなくてもよい。

クラスタリングの手法自体は、公知の手法であってよい。例えば、クラスタリング実行部１０８は、ｋ－ｍｅａｎｓ、階層的クラスタリング、密度ベースクラスタリング、ガウス混合モデル、又はスペクトラルクラスタリングに基づいて、クラスタリングを実行してもよい。他にも例えば、クラスタリング実行部１０８は、機械学習の手法を利用して作成された機械学習モデルに基づいて、クラスタリングを実行してもよい。機械学習モデルも、公知の方法で作成されたモデルであってよい。例えば、クラスタリング実行部１０８は、ＲＮＮ（Recurrent Neural Network）、ＬＳＴＭ（Long Short Term Memory）、又はＴｒａｎｓｆｏｒｍｅｒベース等のモデルに対し、複数の通信装置２０の各々の状態データを入力することによって、クラスタリングを実行してもよい。

図１４は、クラスタリングの実行結果の一例を示す図である。図１４では、多数の通信装置２０の各々の状態データが特徴量化されたベクトル空間が示されている。図１４の白丸は、後述の異常関係データである。図１４の黒丸は、異常関係データ以外の他の状態データである。図１４の丸同士が近いことは、特徴が似ていることを意味する。本実施形態では、時系列的な状態の変化が状態データに示されているので、クラスタリング実行部１０８は、複数の通信装置２０の各々の状態データが示す時系列的な状態の変化に基づいて、クラスタリングを実行する。例えば、クラスタリング実行部１０８は、個々の状態データが示す波形の特徴量を計算する。

例えば、クラスタリング実行部１０８は、状態データの時間領域における特徴量を計算する。クラスタリング実行部１０８は、ある状態データが示す時系列的な状態の変化の平均値、分散、標準偏差、最小値、最大値、立ち上がりのタイミング、変化量の平均値、変化量の最大値、変化量の最小値、又はこれらの組み合わせを、当該状態データの時間領域における特徴量として計算する。クラスタリング実行部１０８は、ある状態データが示す状態が飽和した期間、その時の通信量、飽和の頻度、又はこれらの組み合わせを、当該状態データの時間領域における特徴量として計算してもよい。クラスタリング実行部１０８は、時間領域ではなく、状態データの周波数領域における特徴量を計算してもよい。

例えば、クラスタリング実行部１０８は、複数の状態データの各々の特徴量に基づいて、互いに特徴量が近い状態データ同士が同じクラスタに属するように、クラスタリングを実行する。機械学習モデルが利用される場合、状態データの特徴量は、埋め込み表現と呼ばれることもある。クラスタリングの実質的な処理は、機械学習モデルの内部で実行される。クラスタリング実行部１０８は、複数の状態データの各々を機械学習モデルに入力し、機械学習モデルからの出力を取得することによって、クラスタリングを実行する。例えば、機械学習モデルの出力は、複数の状態データの各々と、当該状態データが属するクラスタと、の関係を示すデータである。クラスタリングは、教師無し学習の手法が利用されてもよい。クラスタリング実行部１０８は、状態データが示す波形を画像として捉えて、画像の類否を判定する手法に基づいて、クラスタリングを実行してもよい。

本実施形態では、クラスタリング実行部１０８は、異常が検知された場合に、複数の装置の各々の状態データに基づいて、クラスタリングを実行する。例えば、クラスタリング実行部１０８は、サーバ１０が異常を検知した場合に自動的にクラスタリングを実行してもよいし、通信サービスの管理者が管理者端末４０で所定の操作を行った場合にクラスタリングを実行してもよい。クラスタリング実行部１０８は、異常が検知された後に、クラスタリングを実行すればよい。異常が検知される前にクラスタリングが実行される例は、後述の変形例２－１で説明する。

図１４の例では、４つの異常関係データが管理者によって指定されており、クラスタリング実行部１０８は、クラスタリングによって、クラスタＣ１～Ｃ４の４つを特定する。例えば、クラスタＣ１の中の白丸（異常関係データ）は、図１０及び図１１の例における通信装置２０Ａの状態データである。クラスタＣ１の中の黒丸の１つは、図１０及び図１１の例における通信装置２０Ｅの状態データである。他のクラスタＣ２～Ｃ４の各々における白丸は、通信装置２０Ａが異常の要因となるエリアＸ以外の他のエリアにおける異常の要因となった通信装置２０の状態データである。他のエリアについても、当該通信装置２０と関連性のある他の通信装置２０の状態データが、クラスタリングによって特定される。なお、クラスタＣ１～Ｃ４の各々に属する状態データの数は、互いに同じであってもよいし異なってもよい。

［関連データ特定部］
関連データ特定部１０９は、クラスタリングの実行結果に基づいて、サービスにおける異常の要因に関する状態データである異常要因データと関連性のある他の状態データである関連データを特定する。本実施形態では、管理者が、どの通信装置２０の状態データが異常要因データに相当するかを指定するものとする。サーバ１０は、管理者端末４０から、管理者が異常要因データとして指定した通信装置２０の状態データを示す情報を受信すると、状態データベースＤＢのうち、当該通信装置２０の装置識別情報に関連付けられた異常要因識別情報を更新する。図１３の例であれば、サーバ１０は、通信装置２０Ａの状態データが、エリアＸの異常の要因に関する異常要因データであることを示すように、通信装置２０Ａの異常要因識別情報を更新する。

関連データは、クラスタリングによって、異常要因データと似た特徴を有することが特定された状態データである。別の言い方をすれば、関連データは、異常要因データと同じクラスタに属する状態データである。関連データ特定部１０９は、１つの異常要因データに対し、少なくとも１つの関連データを特定する。異常要因データと似た特徴を有する状態データが存在しなければ、関連データ特定部１０９は、関連データを１つも特定しないこともある。関連データ特定部１０９は、状態データベースＤＢのうち、関連データとして特定された通信装置２０の状態データに関連付けられた関連情報を更新する。図１３の例であれば、関連データ特定部１０９は、通信装置２０Ｅの状態データを関連データとして特定するので、通信装置２０Ｅの状態データに関連付けられた関連情報を更新する。

なお、関連データ特定部１０９は、異常要因データとは同じクラスタに属していなくても、多少似た特徴を有している状態データであれば、関連データとして特定してもよい。例えば、関連データ特定部１０９は、異常要因データとは同じクラスタに属していないが、特徴量の違い（図１４の例であれば、ベクトル空間における距離）が閾値未満である状態データを、関連データとして特定してもよい。また、関連データ特定部１０９は、特徴量の違いを計算する場合、より特徴のあるデータポイント区間に重み（ウェイトパラメータ）をかけることで、より特徴のあるデータに近い関連データを特定することが可能となる。逆に、関連データ特定部１０９は、異常要因データと同じクラスタに属する状態データだったとしても、関連データとして特定しなくてもよい。例えば、関連データ特定部１０９は、異常要因データと同じクラスタに属する複数の状態データのうち、異常要因データの特徴量との差が小さい順に所定数の状態データを、関連データとして特定してもよい。

本実施形態では、関連データ特定部１０９は、異常が検知された場合に、関連データを特定する。例えば、関連データ特定部１０９は、サーバ１０が異常を検知した場合に自動的に関連データを特定してもよいし、通信サービスの管理者が管理者端末４０で所定の操作を行った場合に関連データを特定してもよい。関連データ特定部１０９は、異常が検知された後に、関連データを特定すればよい。異常が検知される前に関連データが特定される例は、後述の変形例２－１で説明する。

［復旧処理実行部］
復旧処理実行部１０６は、異常が検知された場合に、異常要因データと、関連データと、に基づいて、異常の復旧に関する復旧処理を実行する。復旧処理は、発生した異常に関係する何らかの処理であればよい。本実施形態では、異常に関係する状態データを管理者画面ＳＣに表示させる処理が復旧処理に相当する。復旧処理は、他の処理であってもよく、例えば、予め用意された復旧のためのプログラムを実行する処理、又は、管理者に電子メール等の通知を送信する処理であってもよい。

例えば、復旧処理実行部１０６は、異常が検知された場合に、異常要因データと、関連データと、に基づいて、管理者端末４０に対し、管理者画面ＳＣの表示データを送信することによって、管理者端末４０に管理者画面ＳＣを表示させる。復旧処理実行部１０６は、異常が検知された場合に、異常要因データと、関連データと、の各々を示す画像を、管理者画面ＳＣに表示させる。

図１２の例では、ある異常が発生した場合に、復旧処理実行部１０６は、過去に同じ以上が発生した場合に関連データ特定部１０９により判定された状態データが示す状態を、管理者画面ＳＣに表示させる。復旧処理実行部１０６は、ある異常が発生して当該異常と関係する状態データが特定された場合に、同じ異常が発生すると、当該異常と関係する状態データに基づいて、復旧処理を実行する。

図１３の状態データベースＤＢの例であれば、復旧処理実行部１０６は、エリアＸで異常が発生した場合に、状態データベースＤＢの異常要因識別情報を参照し、通信装置２０Ａの状態データが、当該異常の要因である異常要因データであることを特定する。更に、復旧処理実行部１０６は、状態データベースＤＢの関連識別情報を参照し、通信装置２０Ｅの状態データが、関連データであることを特定する。復旧処理実行部１０６は、当該特定された異常要因データ及び関連データに基づいて、管理者画面ＳＣの表示データを生成して管理者端末４０に送信する。

［２－３－２．管理者端末で実現される機能］
例えば、管理者端末４０は、データ記憶部４００、操作受付部４０１、及び表示制御部４０２を含む。データ記憶部４００は、記憶部４２を主として実現される。操作受付部４０１及び表示制御部４０２は、制御部４１を主として実現される。

［２－４．監視システムで実行される処理］
図１５は、監視システム１で実行される処理の一例を示す図である。制御部１１，４１が、それぞれ記憶部１２，４２に記憶されたプログラムを実行することによって、図１５の処理が実行される。

図１５のように、サーバ１０は、複数の通信装置２０の各々と通信し、状態データを取得して状態データベースＤＢに格納する（Ｓ１００）。Ｓ１００の処理は、定期的に実行される。異常が発生すると、管理者端末４０は、管理者による異常発生操作を受け付ける（Ｓ１０１）。管理者端末４０は、サーバ１０に対し、異常発生操作が行われたことを示す異常発生データを送信する（Ｓ１０２）。サーバ１０は、管理者端末４０から、異常発生データを受信する（Ｓ１０３）。サーバ１０は、異常発生データを受信したタイミングを、異常が発生した異常発生タイミングとして記憶部１２に記録する（Ｓ１０４）。なお、管理者が異常発生タイミングを指定してもよい。この場合、サーバ１０は、管理者が指定した異常発生タイミングを記憶部１２に記録する。

異常が解消すると、管理者端末４０は、管理者による異常解消操作を受け付ける（Ｓ１０５）。管理者端末４０は、サーバ１０に対し、異常解消操作が行われたことを示す異常解消データを送信する（Ｓ１０６）。サーバ１０は、管理者端末４０から、異常解消データを受信する（Ｓ１０７）。サーバ１０は、異常解消データを受信したタイミングを、異常が解消した異常解消タイミングとして記憶部１２に記録する（Ｓ１０８）。なお、管理者が異常解消タイミングを指定してもよい。この場合、サーバ１０は、管理者が指定した異常解消タイミングを記憶部１２に記録する。

管理者は、複数の通信装置２０の各々の状態データを分析し、異常要因データを特定する。管理者端末４０は、管理者が異常要因データを指定すると、サーバ１０に対し、異常要因データを識別可能な異常要因識別情報を送信する（Ｓ１０９）。図１０等の例であれば、管理者端末４０は、サーバ１０に対し、通信装置２０Ａの状態データが異常要因データであることを示す異常要因識別情報を送信する。

サーバ１０は、管理者端末４０から異常要因識別情報を受信すると（Ｓ１１０）、状態データベースＤＢを更新する（Ｓ１１１）。図１３の例であれば、サーバ１０は、状態データベースＤＢのうち、通信装置２０Ａの装置識別情報に関連付けられた異常要因識別情報を更新する。サーバ１０は、複数の通信装置２０の各々の状態データに基づいて、クラスタリングを実行する（Ｓ１１２）。サーバ１０は、クラスタリングの実行結果に基づいて、異常要因データと関連性のある関連データを特定し（Ｓ１１３）、本処理は終了する。以降、同様の異常が発生した場合には、サーバ１０は、異常要因データと、関連データと、に基づいて、復旧処理を実行する。

［２－５．実施形態のまとめ］
本実施形態の監視システム１は、複数の通信装置２０の各々の状態に関する状態データを取得する。監視システム１は、複数の通信装置２０の各々の状態データに関するクラスタリングを実行する。監視システム１は、クラスタリングの実行結果に基づいて、関連データを特定するので、通信装置２０の状態データの関連性を特定できる。例えば、監視システム１は、管理者が関連データの存在に気付けなかったとしても、クラスタリングによって関連データを特定できるので、管理者が異常発生時の復旧を迅速に行うことができる。監視システム１は、管理者の業務を支援できる。

また、監視システム１は、異常が検知された場合に、複数の通信装置２０の各々の状態データを取得する。監視システム１は、異常が検知された場合に、複数の通信装置２０の各々の状態データに基づいて、クラスタリングを実行する。監視システム１は、異常が検知された場合に、関連データを特定する。監視システム１は、異常が検知された場合に、異常要因データと、関連データと、に基づいて、復旧処理を実行する。監視システム１は、復旧処理によって、通信サービスにおける異常を迅速に復旧できる。例えば、監視システム１は、似た異常が再び発生した場合に、管理者に異常要因データ及び関連データをチェックさせることができるので、管理者の業務を効果的に支援できる。

また、監視システム１は、監視システム１は、複数の通信装置２０の各々の状態データが示す時系列的な状態の変化に基づいて、クラスタリングを実行する。監視システム１は、通信装置２０の状態の時系列的な変化から、状態データの関連性を特定できる。例えば、監視システム１は、異常要因データと時系列的な特徴が似た状態データを、関連データとして特定することによって、状態データの時系列的な変化に基づいて、より精度のたかい復旧処理を実行できる。

［２－６．変形例］
本開示は、以上に説明した実施形態に限定されない。本開示は、本開示の趣旨を逸脱しない範囲で、適宜変更可能である。

図１６は、変形例の監視システム１で実現される機能の一例を示す図である。変形例の監視システム１は、検知処理実行部１１０、飽和判定部１０４、及び異常要因データ特定部１１１を含む。検知処理実行部１１０、飽和判定部１０４、及び異常要因データ特定部１１１は、制御部１１により実現される。

［２－６－１．変形例２－１］
例えば、実施形態では、異常が検知された場合に一連の処理が実行される場合を説明したが、一連の処理は、異常が検知される前に実行されてもよい。変形例２－１では、関連データ特定部１０９により特定された関連データが、実施形態のような異常の復旧ではなく、異常の検知に利用される場合を説明する。

変形例２－１の状態データ取得部１０１は、異常が検知される前に、複数の通信装置２０の各々の状態データを取得する。状態データ取得部１０１による状態データの取得方法は、実施形態と同様である。状態データ取得部１０１は、通信サービスの稼働中にリアルタイムで状態データを取得する。状態データ取得部１０１は、異常の発生有無に関係なく、状態データを取得する。例えば、実際には異常が発生していたとしても、監視システム１で異常が検知される前であれば、上記「異常が検知される前」に相当する。

変形例２－１のクラスタリング実行部１０８は、異常が検知される前に、複数の通信装置２０の各々の状態データに基づいて、クラスタリングを実行する。クラスタリングの実行方法も、実施形態と同様である。クラスタリング実行部１０８は、異常の発生有無に関係なく、クラスタリングを実行する。変形例２－１の関連データ特定部１０９は、異常が検知される前に、関連データを特定する。関連データの特定方法も、実施形態と同様である。関連データ特定部１０９は、異常の発生有無に関係なく、関連データを特定する。

監視システム１は、検知処理実行部１１０を含む。検知処理実行部１１０は、異常要因データと、関連データと、に基づいて、異常の検知に関する検知処理を実行する。検知処理は、発生した異常を検知する何らかの処理であればよい。変形例２－１では、異常の発生を管理者画面ＳＣに表示させる処理が検知処理に相当する。例えば、検知処理実行部１１０は、異常が検知された場合に、異常が検知されたことを示す画像を、管理者画面ＳＣに表示させる。検知処理実行部１１０は、管理者に対し、電子メール等の手段を利用して通知を送信することによって、検知処理を実行してもよい。

変形例２－１では、異常要因データと、関連データと、の各々に、異常が発生したか否かを示す基準が関連付けられているものとする。当該基準は、過去に発生した異常に基づいて定められるものとする。例えば、何らかの閾値であってもよいし、後述の変形例２－２のように飽和が発生したか否かであってもよい。検知処理実行部１１０は、異常要因データと、関連データと、の各々が当該基準を満たしたか否かを判定する。

例えば、検知処理実行部１１０は、異常要因データと、関連データと、の少なくとも一方が当該基準を満たしたと判定した場合に、検知処理を実行する。なお、検知処理実行部１１０は、異常要因データと、関連データと、の両方が上記基準を満たしたと判定した場合に検知処理を実行してもよい。検知処理実行部１１０は、異常要因データ又は関連データの何れか一方のみが上記基準を満たしたと判定した場合に検知処理を実行してもよい。

変形例２－１の監視システム１は、異常が検知される前に、複数の通信装置２０の各々の状態データの取得、クラスタリングの実行、及び関連データの特定を行う。監視システム１は、異常要因データと、関連データと、に基づいて、異常の検知に関する検知処理を実行する。これにより、監視システム１は、迅速に異常を検知できる。

［２－６－２．変形例２－２］
例えば、実施形態では、管理者が状態データを分析して異常要因データを指定する場合を例に挙げた。状態データは、監視システムによって分析されて、異常要因データとして分類されてもよい。例えば、通信サービスでは、多数の通信装置２０が存在し、種々の異常が発生しうるので、管理者が、異常の要因となった通信装置２０を特定するのが難しいことがある。このとき、異常の要因となった通信装置２０は、それ以上の通信を処理しきれないので、通信量が飽和する場合がある。

通信量が飽和するとは、通信量が正の状態であり（通信量が０ではない状態であり）、かつ、通信量が変化しない又は略変化しないことである。通信量が変化しないとは、通信量の変化量が０のことである。通信量が略変化しないとは、通信量の変化量が閾値未満であることである。飽和の具体的な判定方法は、後述する。通信量は、上限値が定められていてもよいが、管理者が定めた上限値よりも多くの通信量を通信装置２０が処理可能な場合や、管理者が定めた上限値よりも低い通信量しか通信装置２０が処理できない場合もあり、さらには、管理者自身、通信装置２０の上限値を知らない場合もあるので、通信量の上限値が定められていないものとする。このため、通信装置２０の通信量が一定程度に達したとしても、異常が検知されるわけではないものとする。

図１０の例であれば、通信装置２０Ａの通信量が急激に増加した後に、通信装置２０Ａの通信量が飽和している。当該期間では、通信装置２０Ａは、それ以上の通信を処理できないので、ある特定のエリアで通信装置２０Ａに接続を試みたユーザ端末３０が、通信サービスを利用できない可能性がある。なお、変形例２－２では、飽和開始タイミングから飽和終了タイミングまでの期間を異常が発生していた期間の一例として取り扱うが、飽和開始タイミングから飽和が終了していない現時点までの期間を異常が発生していた期間の一例として取り扱ってもよい。例えば、飽和開始タイミングから、管理者が指定した時点までの期間を異常が発生していた期間の一例として取り扱ってもよい。

変形例２－２の監視システム１は、飽和判定部１０４及び異常要因データ特定部１１１を含む。飽和判定部１０４は、複数の通信装置２０の各々の状態データに基づいて、当該通信装置２０の状態データが示す状態が飽和しているか否かを判定する。飽和判定部１０４が判定する飽和は、状態データが示す状態の変化量が閾値未満になること、又は、当該変化量が当該閾値未満の状態が所定時間以上継続することである。通信量のように、原則として上限値が存在しない場合、通信量が増加すれば、変化量は、主に増加量を意味する。そのため、ある期間で変化量の合計が増加した後に、状態データが示す状態の増加量が閾値未満になること、又は、当該増加量が当該閾値未満の状態が所定時間以上継続することが、飽和に相当する。変化量は、ある一定程度の期間における積算値であってもよいし、ある時点と次の時点の変化量であってもよい。変化量は、通信量の減少量を意味してもよい。つまり、飽和判定部１０４は、状態データが示す当該変化量そのものの時系列的な変化に基づいて、当該飽和の判定を行う。

例えば、飽和判定部１０４は、異常が検知された場合に、通信装置２０の状態データに基づいて、当該通信装置２０の状態が飽和しているか否かを判定する。即ち、飽和判定部１０４は、異常が発生した後に、通信装置２０の状態データに基づいて、当該通信装置２０の状態が飽和しているか否かを判定する。例えば、飽和判定部１０４は、正規化が実行された状態データに基づいて、通信装置２０の状態が飽和しているか否かを判定する。飽和判定部１０４は、正規化が実行された状態データが示す状態に基づいて、通信装置２０の状態が飽和しているか否かを判定する。

なお、飽和判定部１０４は、状態データが示す状態のうち、所定のタイムウィンドウ内の状態に基づいて、当該状態が飽和しているか否かを判定してもよい。飽和判定部１０４は、タイムウィンドウに関係なく、状態データが示す状態が飽和しているか否かを判定してもよい。例えば、飽和判定部１０４は、状態データが示す状態のうち、基準期間内の状態に基づいて、当該状態が飽和しているか否かを判定してもよい。飽和判定部１０４は、状態データが示す状態のうち、異常が発生している異常期間内の状態に基づいて、当該状態が飽和しているか否かを判定してもよい。飽和判定部１０４は、状態データが示す全期間の状態に基づいて、当該状態が飽和しているか否かを判定してもよい。

異常要因データ特定部１１１は、複数の通信装置２０の各々の状態データのうち、当該通信装置２０の状態が飽和していると判定された状態データを、異常要因データとして特定する。図１０の例であれば、通信装置２０Ａの状態が飽和の傾向を示しているので、異常要因データ特定部１１１は、通信装置２０Ａの状態データを、異常要因データとして特定する。異常要因データが特定された後の処理は、実施形態と同様である。

変形例２－２の監視システム１は、複数の通信装置２０の各々の状態データに基づいて、当該通信装置２０の状態が飽和しているか否かを判定する。監視システム１は、複数の通信装置２０の各々の状態データのうち、状態が飽和していると判定された状態データを、異常要因データとして特定する。これにより、監視システム１は、通信サービスにおける異常に状態データが関係するか否かを判定できる。その結果、例えば、監視システム１は、異常の復旧を早めることができる。他にも例えば、監視システム１は、異常を迅速に検知したり、異常の要因を分析したりするといったことも可能になる。

［２－６－３．変形例２－３］
例えば、複数の通信装置２０の各々の状態データは、当該通信装置２０が管理する時間に基づいて生成される。複数の通信装置２０の各々が管理する時間は、互いにずれていることがある。この場合、複数の通信装置２０の各々の状態データの互いの時間軸がずれていることがある。このため、クラスタリング実行部１０８は、複数の通信装置２０の各々の状態データの時間軸を揃えてから、当該時間軸が揃えられた当該状態データに基づいて、クラスタリングを実行してもよい。

例えば、クラスタリング実行部１０８は、複数の通信装置２０の各々から、当該通信装置２０が管理する現在の時間を取得する。クラスタリング実行部１０８は、通信装置２０ごとに、サーバ１０が管理する現在の時間と、当該通信装置２０が管理する現在の時間と、のずれを計算する。クラスタリング実行部１０８は、通信装置２０ごとに、当該ずれが閾値よりも小さくなるように（例えば、当該ずれが０になるように）、当該通信装置２０の時間軸をずらすことによって、複数の通信装置２０の各々の時間軸を揃える。

例えば、クラスタリング実行部１０８は、通信装置２０Ａが管理する時間が、サーバ１０が管理する時間よりも１５秒進んでいることを特定したとする。この場合、クラスタリング実行部１０８は、通信装置２０Ａの状態データが示す時間軸を、全体的に１５秒遅れるように変更する。他にも例えば、クラスタリング実行部１０８は、通信装置２０Ｂが管理する時間が、サーバ１０が管理する時間よりも２０秒遅れていることを特定したとする。この場合、クラスタリング実行部１０８は、通信装置２０Ｂの状態データが示す時間軸を、全体的に２０秒早まるように変更する。

なお、変形例２－３では、サーバ１０が管理する時間が基準になる場合を例に挙げたが、クラスタリング実行部１０８は、複数の通信装置２０の何れかが管理する時間を基準としてもよい。例えば、クラスタリング実行部１０８は、通信装置２０Ａが管理する時間を基準としてもよい。この場合、クラスタリング実行部１０８は、通信装置２０Ｂが管理する時間が、通信装置２０Ａが管理する時間よりも３２秒進んでいることを特定したとすると、通信装置２０Ｂの状態データが示す時間軸を、全体的に３２秒遅れるように変更する。クラスタリング実行部１０８は、通信装置２０Ｃが管理する時間が、通信装置２０Ａが管理する時間よりも２６秒遅れていることを特定したとすると、通信装置２０Ｃの状態データが示す時間軸を、全体的に２６秒早まるように変更する。クラスタリング実行部１０８は、通信装置２０Ａの時間軸は変更しない。

変形例２－３の監視システム１は、複数の通信装置２０の各々の状態データの時間軸を揃えてから、当該時間軸が揃えられた当該状態データに基づいて、クラスタリングを実行する。複数の通信装置２０の各々の状態データの時間軸がずれている場合には、本来は互いに似た特徴を有する状態データだったとしても、状態データ上の時間軸のずれによって、互いに似た特徴を有しないと判定される可能性がある。この点、監視システム１は、複数の通信装置２０の各々の状態データの時間軸を揃えることによって、関連データを特定する精度を高めることができる。

［２－６－４．変形例２－４］
例えば、通信装置２０Ａの状態データと、通信装置２０Ｂの状態データと、の間に関連性があったとしても、通信装置２０Ａの通信量が急激に上がった３０秒後に、通信装置２０Ｂの通信量が急激に上がるといったように、これらの関連性の間にタイムラグが発生することがある。この場合、同じ時点の通信量同士がクラスタリングで比較されると、特徴としては似ていないと判定されることがある。クラスタリング実行部１０８が、通信装置２０Ｂの状態データが示す波形を全体的に３０秒ずつ早めたうえで、通信装置２０Ａの状態データと比較すると、全体的な波形の特徴が似ていることを特定しやすくなる。このため、クラスタリング実行部１０８は、複数の通信装置２０の各々の状態データの時間軸をずらしてから、当該時間軸がずらされた当該状態データに基づいて、クラスタリングを実行してもよい。

変形例２－４では、時間軸をどの程度ずらすかを示すずらし量は、予め決められているものとする。更に、時間軸のずらし量として、複数のずらし量が定められているものとする。例えば、１０秒、２０秒、３０秒、４０秒、５０秒、及び６０秒といった６つのずらし量が定められているものとする。上記の例において、通信装置２０Ａの状態データが異常要因データだったとすると、クラスタリング実行部１０８は、通信装置２０Ｂの状態データの時間軸を、１０秒だけ早めたうえでクラスタリングを実行する。更に、クラスタリング実行部１０８は、通信装置２０Ｂの状態データの時間軸を、１０秒だけ遅くしたうえでクラスタリングを実行する。

以降同様に、クラスタリング実行部１０８は、通信装置２０Ｂの状態データの時間軸を、２０秒、３０秒、４０秒、５０秒、及び６０秒の各々だけ早めたうえでクラスタリングを実行する。更に、クラスタリング実行部１０８は、通信装置２０Ｂの状態データの時間軸を、２０秒、３０秒、４０秒、５０秒、及び６０秒の各々だけ遅くしたうえでクラスタリングを実行する。クラスタリング実行部１０８は、通信装置２０Ｃ等の以外の他の通信装置２０も同様にして、状態データの時間軸を、予め定められたずらし量だけ早めた又は遅くしたうえで、クラスタリングを実行する。

変形例２－４の関連データ特定部１０９は、上記のように時間軸がずらされたうえで実行されたクラスタリングの実行結果に基づいて、関連データを特定する。例えば、関連データ特定部１０９は、複数の上記ずらし量の何れかに基づくクラスタリングにより、異常要因データと同じクラスタに分類された状態データを、関連データとして特定する。関連データ特定部１０９は、複数の上記ずらし量の各々に基づくクラスタリングのうち、基準数以上のクラスタリングにより、異常要因データと同じクラスタに分類された状態データを、関連データとして特定してもよい。

上記の例であれば、クラスタリング実行部１０８は、通信装置２０Ｂの状態データの時間軸を全体的に３０秒早めるようにずらした場合の処理によって、通信装置２０Ａの状態データと、通信装置２０Ｂの状態データと、が似ていることを特定する。このため、先述したようなタイムラグが存在したとしても、クラスタリング実行部１０８は、通信装置２０Ａの状態データと、通信装置２０Ｂの状態データと、を同じクラスタに分類できる。クラスタリング実行部１０８は、上記複数のずらし量のうちの少なくとも１つについて、互いに類似すると判定した状態データ同士を、同じクラスタに分類する。

変形例２－４の監視システム１は、複数の通信装置２０の各々の状態データの時間軸をずらしてから、当該時間軸がずらされた当該状態データに基づいて、クラスタリングを実行する。監視システム１は、互いに関連性のある異常要因データ及び関連データの間にタイムラグがあったとしても、あえて時間軸をずらすことによって、タイムラグを吸収し、異常要因データと関連性のある関連データを特定できる。

［２－６－５．変形例２－５］
例えば、変形例２－４において、クラスタリング実行部１０８は、複数の通信装置２０の各々の状態データが示す時系列的な状態の変化のうちの一部の期間に基づいて、時間軸のずらし量を決定し、当該決定されたずらし量に基づいて、複数の通信装置２０の各々の状態データの時間軸をずらしてもよい。変形例２－５では、クラスタリング実行部１０８は、複数のずらし量の何れを利用するかを、状態データが示す期間のうちの一部だけを利用して決定する。

例えば、クラスタリング実行部１０８は、異常要因データが示す特徴的な期間を、上記一部の期間として決定する。当該期間を決定するための基準となる特徴は、予め定められているものとする。図１０の例であれば、通信装置２０Ａの状態データが異常要因データに相当する。更に、通信装置２０Ａの通信量が急激に上がったタイミングが異常の特徴を示す場合には、クラスタリング実行部１０８は、当該タイミングを含む期間を、上記一部の期間として決定する。当該期間は、管理者が手動で指定してもよい。

例えば、クラスタリング実行部１０８は、複数のずらし量の各々について、通信装置２０Ａの状態データのうちの上記一部の期間の状態変化と、他の通信装置２０の状態データのうちの上記一部の期間の状態変化と、を比較する。クラスタリング実行部１０８は、複数のずらし量のうち、最も状態変化の差が小さいずらし量を、時間軸のずらし量として決定する。クラスタリング実行部１０８は、当該決定されたずらし量に基づいて、変形例２－４で説明した処理を実行し、クラスタリングを実行する。ずらし量に基づくクラスタリングは、変形例２－４と同様であってよい。

変形例２－５の監視システム１は、複数の通信装置２０の各々の状態データが示す時系列的な状態の変化のうちの一部の期間に基づいて、時間軸のずらし量を決定し、当該決定されたずらし量に基づいて、複数の通信装置２０の各々の状態データの時間軸をずらす。監視システム１は、互いに関連性のある異常要因データ及び関連データの間にタイムラグがあったとしても、最適なずらし量で時間軸をずらすことによって、タイムラグを吸収し、異常要因データと関連性のある関連データを特定できる。監視システム１は、不要なずらし量に基づく処理を実行しなくて済むので、処理負荷を軽減できる。

［２－６－６．変形例２－６］
例えば、クラスタリング実行部１０８は、複数の通信装置２０の各々の状態データが示す値の差を計算し、当該計算された差に基づいて、クラスタリングを実行してもよい。図１０を例に挙げると、クラスタリング実行部１０８は、通信装置２０Ａの状態データである異常要因データと、通信装置２０Ｂ～２０Ｅの各々の状態データと、の差を計算する。当該差は、マハラノビス距離等の公知の指標が利用されてよい。クラスタリング実行部１０８は、当該差の変化量が閾値未満の状態データを、異常要因データと同じクラスタに分類する。

図１０の例では、通信装置２０Ａの状態データである異常要因データと、通信装置２０Ｅの状態データと、の差がある一定範囲に収まった状態が継続しているので、クラスタリング実行部１０８は、異常要因データと、通信装置２０Ｅの状態データと、を同じクラスタに分類する。即ち、クラスタリング実行部１０８は、異常要因データとの差がある程度存在したとしても、当該差が一定範囲に収まっている状態データであれば、異常要因データと同じクラスタに当該状態データを分類する。なお、クラスタリング実行部１０８は、変化量ではなく、当該差だけに基づいて、クラスタリングを実行してもよい。クラスタリングが実行された後の処理は、実施形態で説明した通りである。

変形例２－６の監視システム１は、複数の通信装置２０の各々の状態データが示す値の差を計算し、当該計算された差に基づいて、クラスタリングを実行する。これにより、監視システム１は、複数の通信装置２０の各々の状態データが示す差に着目したクラスタリングを実行し、クラスタリングの精度を高めることができる。

［２－６－７．変形例２－７］
例えば、通信装置２０によっては、強制的な再起動やシャットダウン等のいわゆるノードダウンによって、状態データの一部が取得されないことがある、この場合に、状態データ取得部１０１は、複数の通信装置２０のうち、状態データの一部が取得されなかった通信装置２０の当該全部又は当該一部が所定の値を示すように、状態データを取得してもよい。所定の値は、予め管理者が指定した値であってもよいし、その場で動的に計算されてもよい。

図１０の例において、通信装置２０Ｂの状態データのうちの一部が、通信装置２０Ｂの強制的な再起動によって欠損していたとする。この場合、状態データ取得部１０１は、状態データのうち、欠損していなかった部分の平均値で、欠損した部分を埋めてもよい。状態データ取得部１０１は、状態データのうち、欠損した部分を、管理者が指定した値で埋めてもよい。当該部分を埋めることは、パディングと呼ばれることもある。欠損した部分を埋める方法自体は、公知のパディングの方法を利用可能である。

変形例２－７の監視システム１は、複数の通信装置２０のうち、状態データの一部が取得されなかった通信装置２０の当該全部又は当該一部が所定の値を示すように、状態データを取得する。これにより、監視システム１は、状態データの一部が欠損していたとしても、クラスタリングを実行できる。

［２－６－８．変形例２－８］
例えば、クラスタリング実行部１０８は、複数の通信装置２０の各々の状態データと、当該状態データに関連付けられた属性と、に基づいて、クラスタリングを実行してもよい。属性は、何らかの観点で状態データを分類可能な情報であればよく、変形例２－８では、複数の通信装置２０の各々が配置された場所を示す場合を例に挙げる。場所は、市町村といったある程度広い範囲であってもよいし、通信装置２０がある建物、部屋、又はラックといったある程度狭い範囲であってもよい。属性は、通信装置２０が配置された場所に限られず、例えば、通信装置２０の性能、役割、又は種類であってもよい。属性は、状態データが意味する内容、又は、状態データのサンプリング周期等の取得条件であってもよい。通信装置２０の属性を示すデータは、データ記憶部１００に予め記憶されているものとする。

例えば、クラスタリング実行部１０８は、複数の通信装置２０の各々の状態データと、当該状態データに関連付けられた場所と、に基づいて、クラスタリングを実行する。クラスタリング実行部１０８は、同じ場所に配置された複数の通信装置２０の各々の状態データに基づいて、クラスタリングを実行する。クラスタリング実行部１０８は、複数の通信装置２０の各々の状態データ同士の特徴が似ていたとしても、異なる場所に配置された通信装置２０であれば、同じクラスタには属さないようにする。クラスタリング実行部１０８は、あくまで同じ場所に配置された複数の通信装置２０の中で、クラスタリングを実行する。

なお、場所以外の属性が利用される場合のクラスタリングも、上記と同様の方法で実行されてよい。例えば、クラスタリング実行部１０８は、同じ属性が関連付けられた複数の通信装置２０の各々の状態データに基づいて、クラスタリングを実行する。クラスタリング実行部１０８は、複数の通信装置２０の各々の状態データ同士の特徴が似ていたとしても、異なる属性が関連付けられた通信装置２０の状態データであれば、同じクラスタには属さないようにする。クラスタリング実行部１０８は、あくまで同じ属性が状態データに関連付けられた複数の通信装置２０の中で、クラスタリングを実行する。クラスタリングが実行された後の処理は、実施形態と同様である。

変形例２－８の監視システム１は、複数の通信装置２０の各々の状態データと、当該状態データに関連付けられた属性と、に基づいて、クラスタリングを実行する。これにより、監視システム１は、状態データの属性を考慮したクラスタリングを実行できるので、クラスタリングの精度を高めることができる。例えば、監視システム１は、同じ属性が状態データに関連付けられた複数の通信装置２０の中でクラスタリングを実行することで、状態データ同士の関連性を精度よく特定できる。

また、監視システム１は、複数の通信装置２０の各々の状態データと、当該状態データに関連付けられた場所と、に基づいて、クラスタリングを実行する。これにより、監視システム１は、通信装置２０が配置された場所を考慮したクラスタリングを実行できるので、クラスタリングの精度を高めることができる。例えば、監視システム１は、同じ場所に配置された複数の通信装置２０の中でクラスタリングを実行することで、状態データ同士の関連性を精度よく特定できる。

［２－６－９．変形例２－９］
例えば、変形例２－９において、クラスタリング実行部１０８は、複数の通信装置２０の各々の状態データに基づく時系列データを所定時間間隔で平均化してよい。例えば、状態データが１個／１秒の頻度で取得される場合、状態データの数量は３６００個／６０分となる。当該状態データを１分間隔で平均化すると、３６００個／６０分の状態データは６０個に削減される。変形例２－９のクラスタリング実行部１０８は、事前に状態データの平均化を行うことによって、平均化前の時系列データと類似する軽量の時系列データを作成することができ、クラスタリングの処理負荷を軽減できる。

［２－６－１０．その他の変形例］
例えば、上記変形例を組み合わせてもよい。

例えば、監視システム１は、ＳＮＳの投稿に基づいて、サービスにおける異常を検知してもよい。この場合、監視システム１は、ＳＮＳの投稿に関する投稿データを取得する。投稿データは、テキスト、画像、動画、ハッシュタグ、又はこれらの組み合わせであってもよい。監視システム１は、監視対象となるサービスの名前を含む投稿の数に基づいて、異常を検知する。監視システム１は、当該投稿の数が閾値以上になった場合に、異常を検知する。関連データ特定部１０９は、ＳＮＳにおける投稿データと、通信装置２０の状態データと、の関連性を特定してもよい。例えば、関連データ特定部１０９は、ＳＮＳにおける投稿の数が増えたタイミングと、通信装置２０の状態データが示す負荷が増加したタイミングと、の間に相関関係がある場合に、ＳＮＳにおける投稿データと、通信装置２０の状態データと、の間に関連性があることを特定してもよい。

例えば、監視システム１は、通信サービス以外の他のサービスにも適用可能である。例えば、監視システム１は、電子商取引サービス、旅行予約サービス、金融サービス、決済サービス、オンラインフリーマーケットサービス、又は動画配信サービスといった他のサービスにおける異常の要因となる異常要因データと関連性のある関連データを特定してもよい。監視対象となる装置は、これらのサービスで利用される装置であればよく、実施形態のような通信装置に限られない。例えば、監視対象となる装置は、サーバコンピュータ、パーソナルコンピュータ、タブレット、電源装置、プリンタ、スキャナ、又はその他の装置であってもよい。

［３．付記］
例えば、監視システムは、下記のような構成も可能である。

［３－１．第１実施形態に係る付記］
（１－１）
サービスにおける監視対象となる装置の時系列的な状態の変化に関する状態データを取得する状態データ取得部と、
前記状態データに基づいて、前記状態が飽和しているか否かを判定する飽和判定部と、
前記飽和判定部の判定結果に基づいて、前記サービスにおける異常に前記状態データが関係するか否かを判定する関係判定部と、
を含む監視システム。
（１－２）
前記状態データ取得部は、前記異常が検知された場合に、前記状態データを取得し、
前記飽和判定部は、前記異常が検知された場合に、前記状態データに基づいて、前記状態が飽和しているか否かを判定し、
前記関係判定部は、前記異常が検知された場合に、前記異常に前記状態データが関係するか否かを判定し、
前記監視システムは、前記異常が検知された場合に、前記異常に関係すると判定された前記状態データに基づいて、前記異常の復旧に関する復旧処理を実行する復旧処理実行部を更に含む、
（１－１）に記載の監視システム。
（１－３）
前記状態データ取得部は、前記異常が検知される前に、前記状態データを取得し、
前記飽和判定部は、前記異常が検知される前に、前記状態データに基づいて、前記状態が飽和しているか否かを判定し、
前記関係判定部は、前記異常が検知される前に、前記異常に前記状態データが関係するか否かを判定し、
前記監視システムは、前記異常に関係すると判定された前記状態データに基づいて、前記異常の検知に関する検知処理を実行する検知処理実行部を更に含む、
（１－１）又は（１－２）に記載の監視システム。
（１－４）
前記状態データ取得部は、複数の前記サービスの各々における前記装置の前記状態データを取得し、
前記飽和判定部は、前記複数のサービスの各々における前記装置の前記状態データに基づいて、前記装置が飽和しているか否かを判定し、
前記関係判定部は、前記飽和判定部の判定結果に基づいて、前記複数のサービスの各々における前記異常に前記状態データが関係するか否かを判定する、
（１－１）～（１－３）の何れかに記載の監視システム。
（１－５）
前記監視システムは、前記異常が検知された場合に、前記異常が発生した異常発生タイミングに基づいて、前記状態データに関する期間を設定する期間設定部を更に含み、
前記状態データ取得部は、前記期間における前記装置の時系列的な状態の変化に関する前記状態データを取得する、
（１－１）～（１－４）の何れかに記載の監視システム。
（１－６）
前記監視システムは、前記状態データに関する正規化を実行する正規化実行部を更に含み、
前記飽和判定部は、前記正規化が実行された前記状態データに基づいて、前記状態が飽和しているか否かを判定する、
（１－１）～（１－５）の何れかに記載の監視システム。
（１－７）
前記関係判定部は、前記状態データに前記変化が示された期間のうち、前記状態が飽和していると判定された飽和期間に基づいて、前記異常に前記状態データが関係するか否かを判定する、
（１－１）～（１－６）の何れかに記載の監視システム。
（１－８）
前記関係判定部は、前記状態データに前記変化が示された期間のうち、前記異常が発生している異常期間よりも前の他の期間における前記状態の最高値に基づいて、前記異常に前記状態データが関係するか否かを判定する、
（１－１）～（１－７）の何れかに記載の監視システム。
（１－９）
前記他の期間は、前記異常期間よりも前の期間であり、
前記関係判定部は、前記他の期間における前記状態の最高値と、前記他の期間よりも前の期間における前記状態の最高値と、に基づいて、前記異常に前記状態データが関係するか否かを判定する、
（１－８）に記載の監視システム。
（１－１０）
前記関係判定部は、前記状態データに前記変化が示された期間のうち、前記異常が発生している異常期間における前記状態データが示す前記状態の最高値に基づいて、前記異常に前記状態データが関係するか否かを判定する、
（１－１）～（１－９）の何れかに記載の監視システム。
（１－１１）
前記関係判定部は、前記状態データに前記変化が示された期間のうち、前記異常が発生している異常期間と、前記状態が飽和していると判定された飽和期間と、の一致度に基づいて、前記異常に前記状態データが関係するか否かを判定する、
（１－１）～（１－１０）の何れかに記載の監視システム。
（１－１２）
前記関係判定部は、前記状態データに前記変化が示された期間のうち、前記状態が飽和している飽和期間と、前記異常が発生している異常期間よりも前の他の期間と、の各々における前記状態の変化量に基づいて、前記異常に前記状態データが関係するか否かを判定する、
（１－１）～（１－１１）の何れかに記載の監視システム。

［３－２．第２実施形態に係る付記］
（２－１）
サービスにおける監視対象となる複数の装置の各々の状態に関する状態データを取得する状態データ取得部と、
前記複数の装置の各々の前記状態データに関するクラスタリングを実行するクラスタリング実行部と、
前記クラスタリングの実行結果に基づいて、前記サービスにおける異常の要因に関する前記状態データである異常要因データと関連性のある他の前記状態データである関連データを特定する関連データ特定部と、
を含む監視システム。
（２－２）
前記状態データ取得部は、前記異常が検知された場合に、前記複数の装置の各々の前記状態データを取得し、
前記クラスタリング実行部は、前記異常が検知された場合に、前記複数の装置の各々の前記状態データに基づいて、前記クラスタリングを実行し、
前記関連データ特定部は、前記異常が検知された場合に、前記関連データを特定し、
前記監視システムは、前記異常が検知された場合に、前記異常要因データと、前記関連データと、に基づいて、前記異常の復旧に関する復旧処理を実行する復旧処理実行部を更に含む、
（２－１）に記載の監視システム。
（２－３）
前記状態データ取得部は、前記異常が検知される前に、前記複数の装置の各々の前記状態データを取得し、
前記クラスタリング実行部は、前記異常が検知される前に、前記複数の装置の各々の前記状態データに基づいて、前記クラスタリングを実行し、
前記関連データ特定部は、前記異常が検知される前に、前記関連データを特定し、
前記監視システムは、前記異常要因データと、前記関連データと、に基づいて、前記異常の検知に関する検知処理を実行する検知処理実行部を更に含む、
（２－１）又は（２－２）に記載の監視システム。
（２－４）
前記複数の装置の各々の前記状態データは、当該装置の時系列的な前記状態の変化を示し、
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データが示す時系列的な前記状態の変化に基づいて、前記クラスタリングを実行する、
（２－１）～（２－３）の何れかに記載の監視システム。
（２－５）
前記監視システムは、
前記複数の装置の各々の前記状態データに基づいて、当該前記状態データが示す前記状態が飽和しているか否かを判定する飽和判定部と、
前記複数の装置の各々の前記状態データのうち、前記状態が飽和していると判定された前記状態データを、前記異常要因データとして特定する異常要因データ特定部と、
を更に含む（２－４）に記載の監視システム。
（２－６）
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データの時間軸を揃えてから、当該時間軸が揃えられた当該状態データに基づいて、前記クラスタリングを実行する、
（２－４）又は（２－５）に記載の監視システム。
（２－７）
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データの時間軸をずらしてから、当該時間軸がずらされた当該状態データに基づいて、前記クラスタリングを実行する、
（２－４）～（２－６）の何れかに記載の監視システム。
（２－８）
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データが示す時系列的な前記状態の変化のうちの一部の期間に基づいて、前記時間軸のずらし量を決定し、当該決定されたずらし量に基づいて、前記複数の装置の各々の前記状態データの時間軸をずらす、
（２－７）に記載の監視システム。
（２－９）
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データが示す値の差を計算し、当該計算された差に基づいて、前記クラスタリングを実行する、
（２－１）～（２－８）の何れかに記載の監視システム。
（２－１０）
前記状態データ取得部は、前記複数の装置のうち、前記状態データの一部が取得されなかった前記装置の当該全部又は当該一部が所定の値を示すように、前記状態データを取得する、
（２－１）～（２－９）の何れかに記載の監視システム。
（２－１１）
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データと、当該状態データに関連付けられた属性と、に基づいて、前記クラスタリングを実行する、
（２－１）～（２－１０）の何れかに記載の監視システム。
（２－１２）
前記属性は、前記複数の装置の各々が配置された場所を示し、
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データと、当該状態データに関連付けられた前記場所と、に基づいて、前記クラスタリングを実行する、
（２－１１）に記載の監視システム。

Claims

サービスにおける監視対象となる装置の時系列的な状態の変化に関する状態データを取得する状態データ取得部と、
前記状態データに基づいて、前記状態が飽和しているか否かを判定する飽和判定部と、
前記飽和判定部の判定結果に基づいて、前記サービスにおける異常に前記状態データが関係するか否かを判定する関係判定部と、
を含む監視システム。
前記状態データ取得部は、前記異常が検知された場合に、前記状態データを取得し、
前記飽和判定部は、前記異常が検知された場合に、前記状態データに基づいて、前記状態が飽和しているか否かを判定し、
前記関係判定部は、前記異常が検知された場合に、前記異常に前記状態データが関係するか否かを判定し、
前記監視システムは、前記異常が検知された場合に、前記異常に関係すると判定された前記状態データに基づいて、前記異常の復旧に関する復旧処理を実行する復旧処理実行部を更に含む、
請求項１に記載の監視システム。
前記状態データ取得部は、前記異常が検知される前に、前記状態データを取得し、
前記飽和判定部は、前記異常が検知される前に、前記状態データに基づいて、前記状態が飽和しているか否かを判定し、
前記関係判定部は、前記異常が検知される前に、前記異常に前記状態データが関係するか否かを判定し、
前記監視システムは、前記異常に関係すると判定された前記状態データに基づいて、前記異常の検知に関する検知処理を実行する検知処理実行部を更に含む、
請求項１又は２に記載の監視システム。
前記状態データ取得部は、複数の前記サービスの各々における前記装置の前記状態データを取得し、
前記飽和判定部は、前記複数のサービスの各々における前記装置の前記状態データに基づいて、前記装置が飽和しているか否かを判定し、
前記関係判定部は、前記飽和判定部の判定結果に基づいて、前記複数のサービスの各々における前記異常に前記状態データが関係するか否かを判定する、
請求項１又は２に記載の監視システム。
前記監視システムは、前記異常が検知された場合に、前記異常が発生した異常発生タイミングに基づいて、前記状態データに関する期間を設定する期間設定部を更に含み、
前記状態データ取得部は、前記期間における前記装置の時系列的な状態の変化に関する前記状態データを取得する、
請求項１又は２に記載の監視システム。
前記監視システムは、前記状態データに関する正規化を実行する正規化実行部を更に含み、
前記飽和判定部は、前記正規化が実行された前記状態データに基づいて、前記状態が飽和しているか否かを判定する、
請求項１又は２に記載の監視システム。
前記関係判定部は、前記状態データに前記変化が示された期間のうち、前記状態が飽和していると判定された飽和期間に基づいて、前記異常に前記状態データが関係するか否かを判定する、
請求項１又は２に記載の監視システム。
前記関係判定部は、前記状態データに前記変化が示された期間のうち、前記異常が発生している異常期間よりも前の他の期間における前記状態の最高値に基づいて、前記異常に前記状態データが関係するか否かを判定する、
請求項１又は２に記載の監視システム。
前記関係判定部は、前記他の期間における前記状態の最高値と、前記他の期間よりも前の期間における前記状態の最高値と、に基づいて、前記異常に前記状態データが関係するか否かを判定する、
請求項８に記載の監視システム。
前記関係判定部は、前記状態データに前記変化が示された期間のうち、前記異常が発生している異常期間における前記状態データが示す前記状態の最高値に基づいて、前記異常に前記状態データが関係するか否かを判定する、
請求項１又は２に記載の監視システム。
前記関係判定部は、前記状態データに前記変化が示された期間のうち、前記異常が発生している異常期間と、前記状態が飽和していると判定された飽和期間と、の一致度に基づいて、前記異常に前記状態データが関係するか否かを判定する、
請求項１又は２に記載の監視システム。
前記関係判定部は、前記状態データに前記変化が示された期間のうち、前記状態が飽和している飽和期間と、前記異常が発生している異常期間よりも前の他の期間と、の各々における前記状態の変化量に基づいて、前記異常に前記状態データが関係するか否かを判定する、
請求項１又は２に記載の監視システム。
サービスにおける監視対象となる複数の装置の各々の状態に関する状態データを取得する状態データ取得部と、
前記複数の装置の各々の前記状態データに関するクラスタリングを実行するクラスタリング実行部と、
前記クラスタリングの実行結果に基づいて、前記サービスにおける異常の要因に関する前記状態データである異常要因データと関連性のある他の前記状態データである関連データを特定する関連データ特定部と、
を含む監視システム。
前記状態データ取得部は、前記異常が検知された場合に、前記複数の装置の各々の前記状態データを取得し、
前記クラスタリング実行部は、前記異常が検知された場合に、前記複数の装置の各々の前記状態データに基づいて、前記クラスタリングを実行し、
前記関連データ特定部は、前記異常が検知された場合に、前記関連データを特定し、
前記監視システムは、前記異常が検知された場合に、前記異常要因データと、前記関連データと、に基づいて、前記異常の復旧に関する復旧処理を実行する復旧処理実行部を更に含む、
請求項１３に記載の監視システム。
前記状態データ取得部は、前記異常が検知される前に、前記複数の装置の各々の前記状態データを取得し、
前記クラスタリング実行部は、前記異常が検知される前に、前記複数の装置の各々の前記状態データに基づいて、前記クラスタリングを実行し、
前記関連データ特定部は、前記異常が検知される前に、前記関連データを特定し、
前記監視システムは、前記異常要因データと、前記関連データと、に基づいて、前記異常の検知に関する検知処理を実行する検知処理実行部を更に含む、
請求項１３又は１４に記載の監視システム。
前記複数の装置の各々の前記状態データは、当該装置の時系列的な前記状態の変化を示し、
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データが示す時系列的な前記状態の変化に基づいて、前記クラスタリングを実行する、
請求項１３又は１４に記載の監視システム。
前記監視システムは、
前記複数の装置の各々の前記状態データに基づいて、当該前記状態データが示す前記状態が飽和しているか否かを判定する飽和判定部と、
前記複数の装置の各々の前記状態データのうち、前記状態が飽和していると判定された前記状態データを、前記異常要因データとして特定する異常要因データ特定部と、
を更に含む請求項１６に記載の監視システム。
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データの時間軸を揃えてから、当該時間軸が揃えられた当該状態データに基づいて、前記クラスタリングを実行する、
請求項１６に記載の監視システム。
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データの時間軸をずらしてから、当該時間軸がずらされた当該状態データに基づいて、前記クラスタリングを実行する、
請求項１６に記載の監視システム。
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データが示す時系列的な前記状態の変化のうちの一部の期間に基づいて、前記時間軸のずらし量を決定し、当該決定されたずらし量に基づいて、前記複数の装置の各々の前記状態データの時間軸をずらす、
請求項１９に記載の監視システム。
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データが示す値の差を計算し、当該計算された差に基づいて、前記クラスタリングを実行する、
請求項１３又は１４に記載の監視システム。
前記状態データ取得部は、前記複数の装置のうち、前記状態データの一部が取得されなかった前記装置の当該全部又は当該一部が所定の値を示すように、前記状態データを取得する、
請求項１３又は１４に記載の監視システム。
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データと、当該状態データに関連付けられた属性と、に基づいて、前記クラスタリングを実行する、
請求項１３又は１４に記載の監視システム。
前記属性は、前記複数の装置の各々が配置された場所を示し、
前記クラスタリング実行部は、前記複数の装置の各々の前記状態データと、当該状態データに関連付けられた前記場所と、に基づいて、前記クラスタリングを実行する、
請求項２３に記載の監視システム。
サービスにおける監視対象となる装置の時系列的な状態の変化に関する状態データを取得する状態データ取得ステップと、
前記状態データに基づいて、前記状態が飽和しているか否かを判定する飽和判定ステップと、
前記飽和判定ステップの判定結果に基づいて、前記サービスにおける異常に前記状態データが関係するか否かを判定する関係判定ステップと、
を含む監視方法。
サービスにおける監視対象となる装置の時系列的な状態の変化に関する状態データを取得する状態データ取得部、
前記状態データに基づいて、前記状態が飽和しているか否かを判定する飽和判定部、
前記飽和判定部の判定結果に基づいて、前記サービスにおける異常に前記状態データが関係するか否かを判定する関係判定部、
としてコンピュータを機能させるためのプログラム。