【課題】複雑な対象システムで発生した障害に対する対応手段を、容易に記述できるルールに基づいて、判定する。
【解決手段】対象システムの構成アイテムに障害が発生した場合、対応手段判定部１３０は、階層構造記憶部１２１が記憶した階層構造に基づいて、障害が発生した構成アイテムの上位の構成アイテムを判定し、状態記憶部１２３が記憶した障害状態に基づいて、判定した上位の構成アイテムの障害状態を判定し、上位の構成アイテムに障害が発生していないと判定した場合に、対応手段記憶部が記憶したアイテム正常対応手段に基づいて、その上位の構成アイテムに障害が発生していない場合の対応手段を、その障害に対する対応手段と判定する。 （もっと読む）

【課題】ログ分析に要する処理負荷を抑えつつ、異常発生の検出及び異常発生源の特定が可能なログ分析システムを提供する。
【解決手段】周波数変換手段１２は、詳細ログ情報を統合した概要ログ情報の時間軸分布を周波数軸分布に変換する。周波数帯強度算出手段１３は、概要ログ情報の周波数軸分布を参照し、監視対象の周波数帯における周波数帯強度を算出する。周波数帯強度監視手段１４は、周波数帯強度の時間変化を監視し、周波数帯強度の変動が所定のしきい値以上になると異常発生を検出する。異常特定手段１５は、異常発生時刻から所定時間さかのぼった時間における詳細ログ情報の時間軸分布に基づいて、異常発生源を特定する。 （もっと読む）

【課題】要素間の相関の存在および要素間の関係の時間変化を考慮しつつシステムの異常を検出し、その異常が発生した要素を特定することを可能とするコンピュータネットワーク等を提供する。
【解決手段】複数台のコンピュータが相互に接続されてなるコンピュータネットワーク１にあって、そのうち少なくとも１台が異常検出特定部１１６を有する異常検出特定装置１１であり、この異常検出特定部が、他のコンピュータで取得された特徴量から入力データを作成するデータ入力処理部２０１と、入力データをより次元数の少ない行列もしくはテンソルである複数の圧縮データに分割する特徴量分割・圧縮処理部２０３と、圧縮データに基づいていずれの要素で異常が発生したかを特定する異常検出特定手段とを有する。 （もっと読む）

【課題】プログラムやデータ等のソフトウェアにかかるバグが原因で、複数のオンライン端末で障害が発生したときに、その原因になったプログラムやデータを短時間に推定できる管理サーバを提供する。
【解決手段】管理サーバ１は、一定時間に、予め定めた台数を超える自動改札機２から同じ種類の障害の発生が通知されたとき、この障害に関連づけられている１または複数のプログラムやデータを抽出する。管理サーバ１は、抽出した１または複数のプログラムについて、現在のバージョンに設定するものと、旧バージョンに設定するものと、の組合せが異なる複数の設定パターンを生成する。そして、自動改札機２毎に、設定パターンでのテスト稼働を要求し、自動改札機２から通知された、テスト稼働における障害の発生有無に基づいて、今回発生した障害の原因であるプログラムを推定する。 （もっと読む）

【課題】各機器より個別に出力される複数のログに基づく故障原因の解析を効率化させることのできる故障原因推測方法の提供を目的とする。
【解決手段】コンピュータが実行する故障原因推測方法であって、同一の車に搭載されている複数の機器において個別に出力されたログデータを出力時間によって同期させ、単位時間ごとに各ログデータの特徴量を算出する特徴量算出手順と、出現頻度が閾値より低い特徴量が属する単位時間を抽出する単位時間抽出手順と、抽出された単位時間の各特徴量と、該単位時間の直前の単位時間の各特徴量とを統合する特徴量統合手順と、故障原因に対応付けられて記憶装置に記録されている複数の事例データの中から、統合された特徴量のパターンと最も類似する事例データを抽出する事例データ抽出手順と、抽出された事例データに対応付けられている故障原因を示す情報を出力する出力手順とを有する。 （もっと読む）

【課題】 メモリカード１とホストデバイスとの間で所定の規格で定められた仕様に従って、データの送受信制御を行うホストコントローラの評価を行うプログラムのデバッグ期間の短縮を行うことができるデバッグ装置を４０提供する。
【解決手段】 ホストコントローラの機能をエミュレーションするホストコントローラエミュレーション部４５と、デバッグ装置４０の内部において送受信する内部データを記憶するバッファ４４Ａ、５２、５３、５４、５８、５９と、バッファに記憶された内部データにもとづいて問題発生箇所を特定するデバッグ部５０と、データ比較部４４と、を有する。 （もっと読む）

【課題】依存関係モデルを構成するために必要となる論理式等の知識にシステム構成情報が付与されていない場合であっても、シンプトンの適用効率を向上させ、障害発生イベントの検出精度を高く維持することができる障害イベントの検出を支援する装置、方法及びコンピュータプログラムを提供する。
【解決手段】複数のコンポーネントを含むシステムのログ情報及び／又は障害情報を含む前記システムの履歴情報を収集する。収集された履歴情報及び記憶されているシンプトンに基づいて、シンプトンに適合するイベント群を特定する。イベント群それぞれを送出したコンポーネントの関連情報を含むシステム構成情報である部分構成情報を抽出する。特定されたイベント群及び抽出された部分構成情報に基づいて障害が発生したイベントが正常に検出されたか否かに関する正誤情報を取得し、取得した正誤情報及び抽出された部分構成情報に基づいてシンプトンを更新する。 （もっと読む）

【課題】プロセスに関する知識やログを用いなくとも計算機の障害を検知可能な方法を提供する
【解決手段】プロセス監視部２は、ＯＳ２１上のプロセスの情報を監視し、ＣＰＵや、メモリなど各種リソースの使用状況といったモニタリング情報を取得する。順位・グループ情報生成部３は、全てのプロセスについて、モニタリング情報から各種リソースの使用状況の順位付けや、使用状況の度合いに応じたグループ分けを行う。単語生成部４は、得られた順位・グループ情報とプロセス名とから特徴量抽出に用いる単語集を生成する。収集部１１は、生成された単語を収集し、障害時間帯推定部１２は、収集された単語から特徴的なキーワードを抽出し、障害を起こした計算機とその時間帯とを推定する。表示部１３は、障害の発生した計算機と時間帯とを表示する。 （もっと読む）

【課題】クライアントとサーバとを含む通信システムについて、サーバが輻輳状態にあるか否かが判断されるだけではなく、クライアントが輻輳状態にあるか否かも判断されるようにすること。
【解決手段】監視装置４０は、監視対象のコンピュータ１０、２０間を流れるパケットを受信するたびに、受信したパケットと同じコネクションにおいてその直前に受信したパケットとの受信時間間隔に基づいて、そのコネクションにおけるパケットの送信元が被擬ホストであるか否かを特定する。また、監視装置４０は、監視対象のコンピュータ１０、２０のそれぞれについて、そのコンピュータの有するコネクションの本数に対する被擬ホストとして特定したコネクションの本数の占める被擬割合を求める。また、監視装置４０は、その被擬割合が高いホストを、輻輳状態にあるホストとして割り出して、警告を出力する。 （もっと読む）

【課題】異常終了の原因となった関数を特定可能な情報処理装置、及び情報処理プログラムを提供する。
【解決手段】複数の関数による処理が異常終了した際に異常終了の原因となった変数情報を異常変数情報として特定すると共に、異常終了の原因となったアドレスを異常アドレスとして特定し、使用する際に、特定された異常アドレスにアクセスしたアクセス関数を、スタック情報により特定し、特定されたアクセス関数が演算した結果が異常変数情報である場合には、当該アクセス関数を異常終了の原因として特定し、異常変数情報がアクセス関数による演算した結果ではないと判定された場合には、アクセス関数が異常変数情報に代入した他の変数情報を異常変数情報とし、他の変数情報が記憶されているアドレスを異常アドレスとするように異常変数情報及び異常アドレスを更新する。 （もっと読む）

【課題】
運用管理サーバがイベント情報を取得しない情報処理装置を含めたイベント相関解析の結果を提供する。
【解決手段】
運用管理サーバにて、イベント情報取得対象の情報処理装置をイベント取得対象装置として構成情報に登録し、運用管理サーバに格納した複数のイベント情報から、予め格納したルールに適合するイベント情報を特定し、当該イベント情報が関連するネットワークサービスのサーバ装置を特定し、イベント情報を生成したクライアント情報処理装置で発生した当該イベントの要因がサーバ装置で発生したネットワークサービスに関するイベントであることを表示する。 （もっと読む）

【課題】仮想化環境において生じる障害の原因箇所の特定を容易かつ迅速に行えるようにする。
【解決手段】物理サーバ２０と通信可能に管理サーバ１０を接続し、管理サーバ１０に、物理サーバ２０で生じたイベントの履歴である第１のイベント履歴と、仮想サーバ２１２で生じたイベントの履歴である第２のイベント履歴とを蓄積記憶する。管理サーバ１０は、仮想サーバ２１２で動作している業務プロセス２１２２の障害に関するイベントを受信すると、当該イベントを発した仮想サーバ２１２に関するイベント履歴である第１のイベント履歴と、記憶しているテーブルを用いて取得される、上記イベントを発した仮想サーバ２１２を実現している物理サーバ２０に関するイベント履歴である第２のイベント履歴とを、蓄積記憶している上記イベント履歴から検索し、その検索結果に基づき障害の原因を特定する。 （もっと読む）

【課題】性能低下を引き起こしている原因箇所を精度良く特定すること。
【解決手段】本発明に係るクラスタシステムにおける性能低下の原因箇所の特定方法は、サービスの提供に必要な複数のリソースにより構成されるクラスタシステムにおける性能低下の原因箇所の特定方法であって、リソースの稼働状況を監視すると共に、当該リソースの性能低下を示唆する性能監視項目を監視するステップ（Ｓ１０１）と、当該監視結果に基づいてリソースの性能低下を判断し、リソース間の影響関係から性能低下の原因であるリソースを特定するステップ（Ｓ１０２）と、を有する。 （もっと読む）

【課題】多数通知される障害内容から障害の発生原因を予測して利用者へ通知すると共に、障害の発生原因と発生パターンの関係を逐次更新する。
【解決手段】障害の検出機能を備えた複数の機器から少なくとも障害の識別情報および障害の発生機器の識別情報を含む障害通知をそれぞれ受信する。次に、受信された障害通知を解析して所定の時間内に発生した障害に係る障害番号を発生機器毎にグループ化し、各グループを発生パターンとして抽出する。次に、過去に生じた障害に係る発生パターンと過去の障害の発生原因との関係を表す登録情報を参照し、抽出された発生パターンと過去発生パターンとの一致度を発生原因毎に計算する。そして、各発生原因に対する一致度を比較して障害通知に係る発生原因を特定する。 （もっと読む）

【課題】業務上の機密に係る情報を含むログを遠隔地に送付することなく、リモートメンテナンスを可能とするリモートメンテナンスシステム等を提供する。
【解決手段】リモートメンテナンスシステム１００は、保守対象計算機２と、保守対象計算機と同一のＬＡＮに接続されていない保守端末４と、保守対象計算機と同一のＬＡＮに接続され、かつ保守端末からインターネットを介してアクセス可能なリモートメンテナンス装置１とを有し、このリモートメンテナンス装置が、障害情報データを蓄積する障害情報蓄積手段１１と、蓄積された障害情報データに保守対象計算機においてエラーが発生したことを示す内容が含まれるか否かを判断する異常検出手段１２と、異常検出手段の判断に基づいて起動され、障害情報データをさらに詳しく分析し、該分析結果を保守端末に送信する分析手段１４とを有するものとした。 （もっと読む）

【課題】
同一パッケージ内に複数のコアを持つマイコンであっても、1個の監視部のみで、マイコンの暴走を正しく監視する。
【解決手段】
ＷＤＣ監視部１９は、マイコン１０から入力される周期的な出力に基づくＷＤＣ信号の周期性が崩れると、前記マイコンの異常発生を判定する。また、前記マイコン内の処理は、各々のコアからアクセス可能なＲＡＭ１４内に各コア毎の更新領域を予め確保し、タイマ部１６より複数のコアに対して一定周期でタイミングを通知する機能をもっている。前記タイマ部から通知されるタイミングに従って、全てのコアが各々のＲＡＭを更新履歴が判るように更新する処理と、少なくとも一つのコアがＲＡＭの更新履歴を判定し、前記ＷＤＣ監視部１９への出力処理を交互に行うことにより、前記ＷＤＣ監視部１９に対して一定周期のＷＤＣ信号の出力を行う。 （もっと読む）

【課題】ネットワーク機器の構成の変更やその機器のアプリケーションソフトウェアのバージョンアップに伴う設定情報の変更を簡易に実現可能な設定情報管理装置、設定情報管理方法および設定情報管理プログラムを得ること。
【解決手段】ネットワーク管理装置１０４は監視対象ネットワーク１０３を構成する各ネットワーク機器の設定情報をコンフィグレーション管理サーバ１０１から受け取ってそのコンフィグレーションデータベースに格納している。ネットワーク機器の使用するアプリケーションソフトウェアのバージョンが変更されたとき、あるいはこれに伴って障害が発生したとき、データ処理上で連携関係にある他のネットワーク機器との関係でコンフィグレーションデータベースが検索され、該当するコンフィグレーションの書き換えが行われる。 （もっと読む）

【課題】医用モダリティなどのモニタ・保守（点検）および修理を高信頼性をもって低コストで行なうことができ、トラブル発生時に問題解決策をユーザやサービスエンジニアに提供する。
【解決手段】診断ネットワークシステム１０は、複数の分散形試験ユニット１２と、マスタ分散形試験ユニット３４と、通信媒体で相互に接続して情報の伝達を可能にしたネットワーク１３と、複数の分散形試験ユニット１２と通信を行うシステムモニタユニット１６とを備える。システムモニタユニット１６は、動作情報に関する情報を基に編集された編集情報データベースと、収集された情報を解析して複数のデバイスについて点検修理が必要か否かを常時、判定する手段と、ユーザインタフェース１８との通信に応じて点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニットと、を備えたものである。 （もっと読む）

根本原因分析エンジンが、イベントの持続期間およびイベントの段階的な削除を用いて分析精度を向上させると共に必要な計算回数を減らす。イベントの通知を受信する都度、関連するルールのマッチング率が再計算される。計算結果は分析エンジン内のルールメモリに保存される。各イベントは有効期間を有し、持続期間が満了した場合、当該イベントがルールメモリから削除される。ルールメモリに保存されたイベントは、ルールメモリに保存された他のイベントに影響を及ぼすことなく削除できる。分析エンジンは次いで、削除されたイベントに関係して影響を受けたルールに関してのみ再計算を実行することにより、各ルールのマッチング率を再計算することができる。分析エンジンが増加分または減少分のイベントを処理するため、計算コストを減らすことができる。分析エンジンは、たとえ１つ以上の条件要素が真でない場合でも、最も可能性の高い結論を判定することができる。

（もっと読む）

【課題】 ＴＡＤＤＭは、ソフトウェア・アプリケーションの特定の使用シナリオに関与するソフトウェア・コンポーネントを隔離することができない。同様にＴＡＤＤＭは、自動的に実行されず、基準環境で取られたスナップショットとシナリオとを比較することができない。
【解決手段】 好ましい実施形態は、問題が発生した使用シナリオに関与するソフトウェア・コンポーネントを隔離することによって、ソフトウェア問題を隔離するプロセスを加速させるため、問題の性質を検出しこれを解決するための、メカニズムを提供する。次に好ましい実施形態は、障害のあるソフトウェア・アプリケーションのインフラストラクチャ内で基準使用シナリオを自動的に実行すること、および、問題が発生した使用シナリオの結果を、基準シナリオから予測される結果と比較することによって、ソフトウェア・コンポーネントをテストする。
好ましい実施形態は、インストール・プロセス用の使用シナリオ記述子を定義することによって、製品またはパッチが正常にインストールされたかどうかをチェックするために、インストール・プロセスの最後に使用することができる。好ましい実施形態は、使用シナリオのテスト行程にも使用することができる。具体的に言えば、好ましい実施形態によって、ユーザは、生産環境においてパッチを適用する前に、各回帰シナリオについて使用シナリオ記述子を作成することができる。さらに、好ましい実施形態は、テスト環境において使用シナリオ発見プロセスを自動的に実行し、その結果をコンパレータに検証させることができる。 （もっと読む）