JP2022045680A - 障害原因特定プログラムおよび障害原因特定方法 - Google Patents

障害原因特定プログラムおよび障害原因特定方法 Download PDF

Info

Publication number
JP2022045680A
JP2022045680A JP2020151392A JP2020151392A JP2022045680A JP 2022045680 A JP2022045680 A JP 2022045680A JP 2020151392 A JP2020151392 A JP 2020151392A JP 2020151392 A JP2020151392 A JP 2020151392A JP 2022045680 A JP2022045680 A JP 2022045680A
Authority
JP
Japan
Prior art keywords
container
information
program
function
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2020151392A
Other languages
English (en)
Inventor
昌生 山本
Masao Yamamoto
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2020151392A priority Critical patent/JP2022045680A/ja
Priority to US17/368,899 priority patent/US11734098B2/en
Publication of JP2022045680A publication Critical patent/JP2022045680A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0712—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/076—Error or fault detection not based on redundancy by exceeding limits by exceeding a count or rate limit, e.g. word- or bit count limit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0778—Dumping, i.e. gathering error/state information after a fault for later diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45537—Provision of facilities of other operating environments, e.g. WINE
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815—Virtual

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)

Abstract

【課題】クラウドコンピューティングシステムのコンテナ環境において、異常が発生した場合に、コンテナ内の動作アプリケーションに問題が発生しているのか、ホストＯＳ側などの環境基盤側の問題なのかを切り分けることを課題とする。【解決手段】管理システムは、コンテナ環境で動作する各プロセスに関するプロセス情報を収集し、プロセス情報に基づき、コンテナごとにプロセスの派生関係を取得する。管理システムは、コンテナごとのプロセスの派生関係にしたがって、各プロセスの関数と各プロセスが動作するコンテナとを対応付けたシンボル情報を生成する。管理システムは、シンボル情報にしたがって、関数の頻度を集計した集計結果を生成し、集計結果に基づき、障害発生時の原因を特定する。【選択図】図２

Description

本発明は、障害原因特定プログラムおよび障害原因特定方法に関する。
クラウドコンピューティングシステムにおいて、コンテナ環境が利用されている。コンテナ環境はクラウドコンピューティングシステムにおいて使用される計算機基盤環境である。コンテナとは、ホストＯＳ（Operating System）上に論理的な区画を作り、そこでアプリケーションを動作させるために必要なランタイム（ライブラリやミドルウェア）をアプリケーションと１つにパッケージ化した実行環境である。
コンテナによる仮想化は、ハイパーバイザー型仮想化のようなゲストＯＳを持たない。そこで、プロセススケジューリングなど、コンテナ内のアプリプロセスのプロセス管理機能の一部はホストＯＳが担っている。このため、ハイパーバイザー型仮想化とは違い、コンテナ内のアプリケーションは、コンテナ内でのＰＩＤ（Process ID）とは別の値のホストＯＳ上のＰＩＤを持ち、ホストＯＳ上のＰＩＤのプロセス情報にはホストＯＳ情報として直接アクセスできる。なお、ホストＯＳ上からコンテナ内を隔離するために、コンテナ内のアプリケーションは、ホストＯＳ上のＰＩＤとは別にコンテナ内のＰＩＤも有している。
ここで、コンピューティングシステムにおいて異常が発生した場合、異常の原因を特定する技術として、トレース手段が知られている。例えば、コンテナ、ＣＰＵ（Central Processing Unit）、メモリ、仮想スイッチなど毎にリソース使用状況やデータの流れなどを採取し、どのコンポーネントで問題が発生しているかを切り分ける。
特表２０１８－５１８７６２号公報
しかし、トレース手段では問題発生箇所がコンテナ内の動作アプリケーションなのか、ホストＯＳなどの環境基盤側の問題なのかを切り分けることは困難である。
例えば、既存のＯＳ情報（プロセス情報）だけでは、コンテナ内のプロセスとホストＯＳ上プロセスの区別がつかず、ホストＯＳ上からアクセスして得られるプロセス情報は、あくまでもホストＯＳ上でのプロセス情報である。このため、ホストＯＳ上で見えているプロセスがコンテナ内のプロセスかどうか、またどのコンテナ内のプロセスかどうか識別できない。
一つの側面では、クラウドコンピューティングシステムのコンテナ環境において、異常が発生した場合に、コンテナ内の動作アプリケーションに問題が発生しているのか、ホストＯＳ側などの環境基盤側の問題なのかを切り分けることが可能な障害原因特定プログラムおよび障害原因特定方法を提供することを目的とする。
第１の案では、障害原因特定プログラムは、コンピュータに、コンテナ環境で動作する各プロセスに関するプロセス情報を収集する処理を実行させる。障害原因特定プログラムは、コンピュータに、前記プロセス情報に基づき、コンテナごとにプロセスの派生関係を取得する処理を実行させる。障害原因特定プログラムは、コンピュータに、前記コンテナごとの前記プロセスの派生関係にしたがって、前記各プロセスの関数と前記各プロセスが動作するコンテナとを対応付けたシンボル情報を生成する処理を実行させる。障害原因特定プログラムは、コンピュータに、前記シンボル情報にしたがって、前記関数の頻度を集計した集計結果を生成し、前記集計結果に基づき、障害発生時の原因を特定する処理を実行させる。
一側面において、クラウドコンピューティングシステムのコンテナ環境において、異常が発生した場合に、コンテナ内の動作アプリケーションに問題が発生しているのか、ホストＯＳ側などの環境基盤側の問題なのかを切り分けることが可能な障害原因特定プログラムおよび障害原因特定方法を提供することができる。
図１は、本開示に係る発明が適用される計算機システムの模式図である。 図２は、本開示に係る管理システムの機能ブロック図である。 図３は、サンプリング部が取得するサンプリングデータを示す図である。 図４は、サンプリングデータ間の親子関係を説明する説明図である。 図５は、プロセス間の親子関係を説明する説明図である。 図６は、コンテナ管理構造体を示す図である。 図７は、コンテナ名‐ＰＩＤマップ情報を示す図である。 図８は、コンテナ管理構造体／マップ情報作成の作成手順を説明するフローチャートである。 図９は、コンテナ管理構造体／マップ情報作成のプログラムの処理手順を説明するフローチャートである。 図１０は、オブジェクトファイル動的回収部の処理を説明するフローチャートである。 図１１は、コンテナコンテキストを説明する説明図である。 図１２は、コンテナコンテキスト毎シンボル解決部の処理を説明するフローチャートである。 図１３は、サンプリング対象の仮想環境を示す模式図である。 図１４は、ホストの解析結果の頻度出力部の出力を示す図である。 図１５は、ゲストの解析結果の頻度出力部の出力を示す図である。 図１６は、コンテナコンテキスト毎頻度出力部の出力を示す図である。 図１７は、問題発生箇所判定部の処理の手順を説明するフローチャートである。 図１８は、ハードウェア構成例を説明する図である。
以下に、本願の開示する障害原因特定プログラムおよび障害原因特定方法の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。
［計算機システムについて］
図１は、本開示に係る発明が適用される計算機システムの模式図である。図１に示すように、計算機システム１００は、一つ以上のサーバ装置１１０、一つ以上のクライアント端末１６０、管理システム２００、及びそれらを相互に接続するネットワーク１８０から構成される。なお、クライアント装置１６０Ａとクライアント装置１６０Ｂのいずれかを特定せずに指し示す場合は、符号を１６０とし、他の符号も同じ形式で表す。
サーバ装置１１０では、アプリケーションが稼働し、計算機システム１００の利用者に対して情報サービスを提供する。ユーザは、クライアント端末１６０を介して、サーバ装置１１０を利用する。サーバ装置１１０はアプリケーションを稼働させるための必要なハードウェアを備える。サーバ装置１１０の構成は同一である必要はなく、それぞれの用途に応じて異なる構成を備えてもよい。
サーバ装置１１０は、アプリケーションとＯＳが利用する論理的なシステム構成を動的に分割あるいは多重化する目的で、コンテナを稼働させるサーバ装置である。図１に示すようにサーバ装置１１０は、コンテナ１２０、コンテナ管理ソフト１３０、ホストＯＳ１４０、ハードウェア１５０、を備える。コンテナ１２０は、コンテナ管理ソフト１３０を通して、ホストＯＳ１４０のカーネルを共有することで、ハードウェア１５０に含まれるＣＰＵやメモリなどのリソースを隔離して作られた仮想的な空間である。なお、サーバ装置１１０のハードウェア１５０のＣＰＵは、後述するＰＭＣ（Ｐｅｆｏｒｍａｎｃｅ Ｍｏｎｉｔｏｒｉｎｇ Ｃｏｕｎｔｅｒ）と呼ばれるレジスタを備える。本開示に係る障害原因特定プログラムは、ＰＭＣのカウンタが設定された上限値を超えた際に発生するオーバーフロー割り込みに伴って、ＯＳカーネル中のドライバに後述するプロセスに関する情報の取得を指示する。本開示に係る障害原因特定プログラムは、サーバ装置１１０に実装されてサーバ装置１１０において実行されてもよいし、後述する管理システム２００に実装されて、サーバ装置１１０の外部からサーバ装置１１０の情報を取得し、障害原因の解析を管理システム２００において実行してもよい。
コンテナ１２０の内部には、アプリケーション１２２、ミドルウェア１２４、ライブラリ１２６が含まれる。アプリケーション１２２は、コンテナ１２０の内部で実行されるプログラムである。ミドルウェア１２４は、アプリケーション１２２を実行するために必要なソフトウェアである。ミドルウェア１２４は、ホストＯＳ１４０とアプリケーション１２２の中間に位置し、様々なソフトウェアから共通して利用される機能を提供する。ライブラリ１２６は、汎用性が高い複数のプログラムを再利用可能な形でひとまとまりにしたものである。
コンテナが仮想化技術と異なる点は、仮想マシンのような従来の仮想化技術では、仮想マシン上でゲストＯＳを起動させる必要があったが、コンテナではゲストＯＳを起動させることなく、アプリケーション実行環境を構築することができる。つまり、仮想マシンに比べて少ないリソースでのアプリケーションの実行が可能であるため、メモリやＣＰＵリソースを余分に使用することがない。
ネットワーク１８０は、有線通信、または、無線通信を介して通信する装置をそれぞれ相互に直結する。ネットワーク１８０には、複数の通信経路を構成するために、一つ以上の図示を省略したネットワークスイッチ、または、ルータを含んでもよい。また役割や伝送されるデータの特性に合わせて物理的、論理的に分割されていても良く、その分割は従来技術において一般的なものが利用されてもよい。このために、ＶＬＡＮ（Ｖｉｒｔｕａｌ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）のように論理的にネットワーク空間を分割し多重化する技術が用いられてもよい。
なお、アプリケーション（サーバ装置１１０）と利用者（クライアント端末１６０）との通信をサービスネットワークとして設け、管理システム２００とサーバ装置１１０の通信を管理ネットワークとして設けるなど、利用目的に合わせて別々に図示を省略したネットワークが構成されていてもよい。
一般にクラウドサービスでは、これらのシステム領域自体や、システム領域内に構築されたアプリケーション環境、さらにはアプリケーションが提供するＩＴサービスの利用に対して、従量課金を行う方式が採用されている。
管理システム２００は、サーバ装置１１０の構成や稼働状況を集中的に管理するためのものであり、計算機システム１００の運用管理を担当する管理者が主に利用する。管理システム２００は、サーバ装置１１０の運用状態を監視する少なくとも一つのコンピュータを備える。また、管理システム２００は、ＫＶＭスイッチを備えもよい。ＫＶＭスイッチは、複数のサーバ装置のコンソール（キーボード、マウス、モニタ）ポートに、ＫＶＭスイッチ本体を接続することで限られたコンソールで操作対象を切り替え、サーバ装置の操作管理を行う装置である。また、管理システム２００は、サーバ装置のコンソールを延長することができるＫＶＭエクステンダーを備えてもよい。ＫＶＭエクステンダーを用いることで、サーバ装置のマシンルームと運用管理室を空間的に分離することができる。また、管理システム２００は、サーバ装置やＫＶＭスイッチのコンソールの機能をラック１Ｕサイズに集約したデバイスであるコンソールドロワーを備えてもよい。コンソールドロワーを用いることで、コンソールの使用スペースをラック１Ｕサイズに集約することができ、省スペース化が可能となる。また、ラックに収納できることから作業員の安全性が確保される。
クライアント端末１６０は、ネットワーク１８０に接続されることによって、サーバ装置１１０との相互通信が可能となる。クライアント端末１６０を使用するユーザは、クライアント端末１６０を操作することで、サーバ装置１１０が提供するＩＴサービスを使用できる。すなわち、サーバ装置１１０は、クライアント端末１６０に入力されたユーザの要求に基づいて、アプリケーションの実行などの処理を行い、処理の結果をクライアント端末１６０に出力する。
［第一実施形態］
図２は、本開示に係る管理システムの機能ブロック図である。本開示に係る障害原因特定プログラムは、図１に示す管理システム２００に実装されて実行されるものであってもよいし、計算機システム１００のサーバ装置１１０に実装されて実行されてもよい。図２に示すように、本開示に係る管理システム２００は、制御部２１０と、記憶部２２０と、データ収集部２３０と、解析処理部２４０と、出力生成部２５０と、を備える。
制御部２１０は、管理システム２００全体を司る処理部であり、例えばＣＰＵなどのプロセッサにより実現される。ＣＰＵは、ＰＭＣ（Ｐｅｆｏｒｍａｎｃｅ Ｍｏｎｉｔｏｒｉｎｇ Ｃｏｕｎｔｅｒ）と呼ばれるレジスタを有する。ＰＭＣは、計算機システム１００におけるハードウェアに関係する活動をカウントし、蓄積するレジスタである。また、ＣＰＵは、ＰＭＣで監視するイベントの種類および、カウンタ上限値を設定するレジスタを有する。
ＰＭＣのカウンタが設定された上限値を超えるとオーバーフロー割り込みが発生する。オーバーフロー割り込みによって、ＯＳカーネル中のドライバ（ｓａｍｐｌｉｎｇ ｄｒｉｖｅｒ）が起動される。その為、ドライバは、起動されたタイミングで種々の情報、例えば、実行中のプロセスのＩＤ（以下、ＰＩＤ値）、実行中のプロセスの親プロセスのＩＤ（以下、ＰＰＩＤ値）、実行中の命令のメモリアドレス（以下、命令アドレス）であるプログラムカウンタ（ＰＣ）、その他のレジスタの値等を採取できる。ＰＭＣを用いることで、プログラムカウンタ（ＰＣ）による問題箇所と共に、その問題を引き起こした原因に関連する可能性のあるイベントの種類を特定することができる。
記憶部２２０は、制御部２１０が実行するプログラム、あるいは、制御部２１０が処理するデータを記憶し、主記憶装置や外部記憶装置などによって実現される。主記憶装置は、例えば、ＲＡＭと、ＲＯＭのようなメモリなどによって実現され、外部記憶装置は、ハードディスクやＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）によって実現される。
なお、記憶部２２０には、後述する問題発生箇所判定部２５８が判定に使用するためのデータとして、サーバ装置１１０の通常時の性能プロファイルの結果を予め記憶しておく。
［データ収集部について］
データ収集部２３０は、サンプリング部２３１、ＯＳ情報／環境情報収集部２３２、オブジェクトファイル静的回収部２３３、コンテナ管理構造体／マップ情報作成部２３４、オブジェクトファイル動的回収部２３５と、を備える。
サンプリング部２３１は、サーバ装置１１０が備えるＣＰＵのＰＭＣのカウンタが設定された上限値を超えた際のオーバーフロー割り込みを利用して、サンプリングデータとして、割り込み毎にその時点の動作プログラムを特定可能な情報であるＰＩＤ値、ＰＰＩＤ値、命令アドレスを取得する。図３は、サンプリング部２３１が取得するサンプリングデータを示す図である。図３に示すように、サンプリング部２３１は、サンプリングデータとして、ＰＩＤ値、ＰＰＩＤ値、命令アドレスを取得する。サンプリング部２３１が、サンプリングする間隔である収集周期、および、サンプリングを継続する時間である収集時間は、任意に設定可能である。例えば、収集周期１ｍｓ、収集時間３０秒と設定することができる。サンプリング部２３１は、取得した情報を記憶部２２０に記憶する。
ＯＳ情報／環境情報収集部２３２は、ホストＯＳ１４０からＯＳ情報として、ＰＩＤ値：プログラム名：プログラムのオブジェクトファイルのファイルパス、を対応付けて取得する。したがって、取得したＰＩＤ値からプログラム名を特定することができる。また、ＰＩＤ値に対してプログラムのオブジェクトファイルのファイルパスが対応付けられている為、取得したＰＩＤ値からオブジェクトファイルのファイルパス、すなわち、オブジェクトファイルのファイルシステム上の存在場所を特定することができる。
オブジェクトファイル静的回収部２３３は、ＯＳ情報／環境情報収集部２３２が、ホストＯＳ１４０からＯＳ情報として取得したＰＩＤ値：プログラム名：プログラムのオブジェクトファイルのファイルパス、の組情報から、当該ＰＩＤ値に対応するプログラムのオブジェクトファイルのファイルパスを特定し、オブジェクトファイルをコピーして回収する。
［コンテナ管理構造体／マップ情報作成部］
コンテナ管理構造体／マップ情報作成部２３４は、サンプリング部２３１が取得した動作プログラムを特定可能な情報であるＰＩＤ値、ＰＰＩＤ値、命令アドレスに基づいて、プロセス派生の親子関係（派生関係）のツリーを作成する。図４は、サンプリングデータ間の親子関係を説明する説明図である。図４に示すように、サンプリングデータの内のＰＩＤ値（図４の例の場合は３０６１）と、他のサンプリングデータの内のＰＰＩＤ値（図４の例の場合は３０６１）が一致する場合は、各サンプリングデータが示すプロセスの間に親子関係が存在する。
図５は、プロセス間の親子関係を説明する説明図である。コンテナ環境では、コンテナ管理ソフトをルートプロセスに持つプロセス間の親子関係のツリー構造が存在する。図５に示す通り、コンテナ管理プログラムの子プロセスがコンテナ本体に当たり、孫プロセス以降がコンテナで実行されるアプリケーションプログラムである。コンテナ管理構造体／マップ情報作成部２３４は、コンテナ管理プログラム名とそのＰＩＤ値に基づいて後述して説明する「コンテナ管理構造体」、および、「コンテナ名‐ＰＩＤマップ情報」を生成する。
図６は、コンテナ管理構造体を示す図である。図６に示すように、「コンテナ管理構造体」は、コンテナに関する情報を集約した情報である。具体的には、コンテナ管理構造体は、コンテナ管理プログラムのＰＩＤ、および、起動中のコンテナ数、に対して、コンテナ１個分（１コンテナコンテキスト）のコンテナ本体ＰＩＤ、コンテナ名、当該コンテナ内のプロセス数、マップへのポインタ、を全てのコンテナの数分、集約した情報である。
図７は、コンテナ名‐ＰＩＤマップ情報を示す図である。図７に示すように、「コンテナ名‐ＰＩＤマップ情報」は、特定のプロセスのＰＩＤ値と一致するＰＰＩＤ値を持つプロセスに関する情報を一組にして、全てのコンテナにわたって集約した情報である。図７を用いて「コンテナ名‐ＰＩＤマップ情報」について説明する。例えば、コンテナ名ｔｅｓｔ１で動作するプロセス／ｂｉｎ／ｂａｓｈは、ＰＩＤ値が１８８９８である。他方、同じコンテナｔｅｓｔ１で動作するプロセスｈｉｍｅｎｏ．ｅｘｅのＰＰＩＤ値は、１８８９８であり、プロセス／ｂｉｎ／ｂａｓｈのＰＩＤ値である１８８９８と一致する。このように、「コンテナ名‐ＰＩＤマップ情報」には、特定のプロセスのＰＩＤ値と一致するＰＰＩＤ値を持つプロセスを一組にして、プロセスに関する情報が集約されている。
図８は、コンテナ管理構造体／マップ情報作成の作成手順を説明するフローチャートである。図８を用いて、コンテナ管理構造体の作成手順を説明する。サンプリング部２３１が動作プログラムを特定可能な情報であるサンプリングデータ（ＰＩＤ値、ＰＰＩＤ値、命令アドレス）を取得する（ステップＳ１００）。
ホストＯＳ１４０が管理しているプロセス情報、および、サンプリング部２３１が取得した動作プログラムを特定可能な情報を入力データとして、これらの中から、コンテナ管理プログラムのＰＩＤ値をＰＰＩＤ値に持つサンプリングデータＡｉ（ｉ＝１，２，．．．，ｎ）を抽出する（ステップＳ１１０）。各サンプリングデータＡｉのＰＩＤ値を図６に示す「コンテナ管理構造体」の中の「コンテナ本体ＰＩＤ」として記憶部２２０に記憶する（ステップＳ１２０）。なお、本ステップにおいては、ホストＯＳ１４０が管理しているプロセス情報がメイン入力であり、サンプリング部２３１が取得した動作プログラムを特定可能な情報は、補助入力となる。これは、プロセスの中に、データ収集中には存在していたが、プロセス情報の回収時には既に終了していて存在しないプロセスがあり、そのようなプロセスの為の入力情報とする為である。なお、動作プログラムを特定可能な情報は、プログラム動作情報の一例である。
次に、各サンプリングデータＡｉに対し、図７に示す「コンテナ名‐ＰＩＤマップ情報」の為のメモリ領域（すなわち、データＢｉｊ領域（ｊ＝１，２，．．．，ｍ））を確保する（ステップＳ１３０）。ポインタを「コンテナ管理構造体」の中の該当するＡｉの「マップへのポインタ」に記録保持する（ステップＳ１４０）。なお、ポインタはプログラムからメモリに自在にアクセスする為のものである。
そして、入力データの中からＰＰＩＤ値にＡｉのＰＩＤ値を持つデータＢｉｊ（ｊ＝１，２，．．．，ｍ）を抽出する（ステップＳ１５０）。「ＰＩＤ値、ＰＰＩＤ値、コンテナ名」の組情報を必須として「コンテナ名‐ＰＩＤマップ情報」に記録保持する（ステップＳ１６０）。なお、ここで、コンテナ名の情報はコンテナ管理ソフトから取得する。また、図７に示す「コンテナ名‐ＰＩＤマップ情報」に含まれるプロセス名は、後述するシンボル解決処理時に追記する。
以降は、ステップＳ１５０からステップＳ１６０を繰り返すことによって、コンテナ管理プログラムをルートとしたプロセスの親子関係のツリー構造を「コンテナ管理構造体」、および、「コンテナ名‐ＰＩＤ値マップ情報」として生成する（ステップＳ１７０）。この内、少なくとも後処理に必要な「コンテナ名‐ＰＩＤマップ情報」は、記憶部２２０の主記憶装置か外部記憶装置に記憶しておく（ステップＳ１８０）。
図９は、コンテナ管理構造体／マップ情報作成のプログラムの処理手順を説明するフローチャートである。図９を用いて、コンテナ管理構造体／マップ情報作成部２３４を実現するプログラムの処理手順を説明する。プロセス情報を取得する（ステップＳ２００）。動作プログラム情報を取得する（ステップＳ２１０）。
ＰＰＩＤ値がコンテナ管理プログラムのＰＩＤ値か判定する（ステップＳ２２０）。プロセスのＰＰＩＤ値がコンテナ管理プログラムのＰＩＤ値の場合（ステップＳ２２０；ＹＥＳ）、コンテナ管理プログラムのＰＩＤ値をＰＰＩＤ値に持つデータをデータＡｉ（ｉ＝１，２，．．．）とする（ステップＳ２３０）。当該ＰＩＤ値をコンテナ管理構造体の「コンテナ本体ＰＩＤ」に記録する（ステップＳ２４０）。当該ＰＩＤ値を一時プロセスリストｐに追加する（ステップＳ２５０）。取得した全てのＰＩＤ値に対して、ステップＳ２２０からステップＳ２５０までを繰り返して実行する。
ステップＳ２２０において、ＰＰＩＤ値がコンテナ管理プログラムのＰＩＤ値ではないと判定された場合（ステップＳ２２０；ＮＯ）、ステップＳ２３０からステップＳ２５０までを実行せずに、次のＰＩＤ値に対してステップＳ２２０からステップＳ２５０を実行する。
取得した全てのＰＩＤ値に対してステップＳ２２０からステップＳ２５０までの処理の実行が完了したら、各データＡｉ（ｉ＝１，２，．．．）に対して、マップ情報用のメモリ領域を確保し、確保したメモリ領域に対応するポインタをコンテナ管理構造体に記録する（ステップＳ２６０）。
一時プロセスリストｐにＰＰＩＤ値があるか判定する（ステップＳ２７０）。一時プロセスリストｐにＰＰＩＤ値がある場合（ステップＳ２７０；ＹＥＳ）、当該ＰＩＤ、ＰＰＩＤ、コンテナ名を一組の情報として、当該データのポインタ先である「コンテナ名‐ＰＩＤマップ情報」に記録する（ステップＳ２８０）。当該ＰＩＤを一時プロセスリストｑに追加する（ステップＳ２９０）。取得した全てのＰＩＤに対して、ステップＳ２７０からステップＳ２９０までを繰り返して実行する。
取得した全てのＰＩＤに対して、ステップＳ２７０からステップＳ２９０までの処理の実行が完了したら、一時リストｑの中身が空か判定する（ステップＳ３００）。一時リストｑの中身が空の場合（ステップＳ３００；ＹＥＳ）、処理を終了する。一時リストｑの中身が空ではない場合（ステップＳ３００；ＮＯ）、一時リストｑの中身を一時リストｐに上書きした後に、一時リストｑを削除する（ステップＳ３１０）。一時リストｑの中身が空になるまで、ステップＳ２７０からステップＳ３００を繰り返す。
［オブジェクトファイル動的回収部］
オブジェクトファイル動的回収部２３５は、コンテナ消滅のタイミングで、オブジェクトファイルの回収を行う。コンテナ消滅自体のタイミングを捉えることは、消滅状態への遷移がファイル削除であることから、コンテナ管理ソフトの外部から捉えることは難しい。その為、オブジェクトファイル動的回収部２３５は、図１０に示す手順でオブジェクトファイルを回収する。
図１０は、オブジェクトファイル動的回収部の処理を説明するフローチャートである。図１０を用いて、オブジェクトファイル動的回収部２３５の処理を説明する。ホストＯＳ１４０のプロセス終結処理をフックする（ステップＳ４００）。なお、フックとはプログラムのプロセス、もしくは、プロセスで発生したイベントを奪い取ることである。ホストＯＳ１４０のプロセス終結処理をフックしたら、終結プロセスのＰＩＤ値がコンテナ管理ソフトのプロセス管理構造体に登録されているコンテナ本体のＰＩＤ値かどうか判定する（ステップＳ４１０）。終結プロセスのＰＩＤ値がコンテナ管理ソフトのプロセス管理構造体に登録されているコンテナ本体のＰＩＤ値の場合（ステップＳ４１０；ＹＥＳ）、コンテナ内プロセスのプロセス情報からオブジェクトファイルの場所を特定し、オブジェクトファイルを回収する（ステップＳ４２０）。なお、回収はコンテナ管理ソフトの機能を利用してコンテナ内からホストＯＳ上に回収する。終結プロセスのＰＩＤ値がコンテナ管理ソフトのプロセス管理構造体に登録されているコンテナ本体のＰＩＤ値ではない場合（ステップＳ４１０；ＮＯ）、プロセス情報のみ収集する（ステップＳ４３０）。
このようにオブジェクトファイル動的回収部２３５によれば、サンプリングデータの取得時に消滅コンテナがあった場合でも、プロセス終結処理をフックすることで、コンテナ内に存在していたオブジェクトファイルを回収することができる。その為、サンプリングデータの取得時に消滅コンテナがあった場合にも、コンテナコンテキスト毎の性能プロファイリングが可能となる。したがって、異常の発生箇所の特定をしやすくすることができる。
［解析処理部について］
図２に示すように、解析処理部２４０は、シンボル解決部２４２と、頻度集計部２４４と、を備える。そして、シンボル解決部２４２は、コンテナコンテキスト毎シンボル解決部２４３を備え、頻度集計部２４４は、コンテナコンテキスト毎頻度集計部２４５を備える。
シンボル解決部２４２は、データ収集部２３０が収集したデータに基づいてシンボル解決を実施する。ここで、シンボルとは、プロセス名、あるいは、プロセスで実行されるプログラム名、プログラム内の関数名、変数名等の名前識別子である。シンボル解決とは、ＣＰＵ、あるいは、ＯＳ等が処理対象を特定する為の識別情報（例えば、ＰＩＤ、レジスタ値、命令アドレスなど）をプロセス名、あるいは、プログラム内の名前識別子に対応付けること、あるいは、変換することなどをいう。すなわち、シンボル解決を実行することによって、サンプリングデータをプロセス名、あるいは、プログラム内の名前識別子に対応付けることが可能となる。
サンプリングしたデータのシンボル解決を実行することで、ユーザはサンプリングしたデータの解析結果から、どこに異常があるか判断できる。ただし、シンボル解決は、例えば、命令アドレスとシンボルとの対応関係を検索する処理を含むため、時間を要する。
コンテナコンテキスト毎シンボル解決部２４３は、コンテナコンテキスト毎にシンボル解決を実施する。なお、コンテナコンテキストとはコンテナ空間（ホストＯＳから見ると通常のユーザープロセスと同じ）から呼び出され実行される一連の処理を意味する。コンテナコンテキストには、コンテナ上で実行されるアプリケーションの処理の延長で実行されるホストＯＳ内の処理（システムコール処理など）も含む。同じコンテナに属する複数の処理（コンテキスト）は、同じコンテナコンテキストとする。
図１１は、コンテナコンテキストを説明する説明図である。図１１に示すように、コンテナコンテキストとは、コンテナの上で実行されるアプリケーションに関連して実行される一連の処理である。例えば、図１１に示す処理Ｃは、アプリケーションから、ライブラリが呼び出されて、ライブラリからＯＳが呼び出されて処理が実行される。同じコンテナに属する複数の処理は同じコンテナコンテキストであるから、図１１に示す処理Ａ、Ｂ、Ｃは、同一のコンテナコンテキストである。
図１２は、コンテナコンテキスト毎シンボル解決部の処理を説明するフローチャートである。図１２を用いて、コンテナコンテキスト毎シンボル解決部２４３の処理について説明する。なお、主体がコンテナコンテキスト毎シンボル解決部２４３ではない処理についてもフローチャートに記載して説明している。主体がコンテナコンテキスト毎シンボル解決部２４３ではない処理をコンテナコンテキスト毎シンボル解決部２４３の処理として含めてもよい。
サンプリング部２３１が、ＰＩＤ、ＰＰＩＤ、命令アドレスを取得する（ステップＳ５００）。ＯＳ情報／環境情報収集部２３２が、ホストＯＳ１４０からＯＳ情報として、ＰＩＤ：プログラム名：プログラムのオブジェクトファイルのファイルパス、の組情報を取得する（ステップＳ５１０）。したがって、これらの情報を参照することで、コンテナコンテキスト毎シンボル解決部２４３は、ＰＩＤから、プログラム名を特定することができる。
コンテナコンテキスト毎シンボル解決部２４３は、ＯＳ情報からオブジェクトファイルのファイルパス、すなわち、ファイルシステム上の存在場所を特定する（ステップＳ５２０）。コンテナコンテキスト毎シンボル解決部２４３は、「コンテナ名‐ＰＩＤマップ情報」を参照して、処理対象のＰＩＤが「コンテナ名‐ＰＩＤマップ情報」に含まれるか判定する（ステップＳ５３０）。
コンテナコンテキスト毎シンボル解決部２４３は、処理対象のＰＩＤが「コンテナ名‐ＰＩＤマップ情報」に含まれる場合（ステップＳ５３０；ＹＥＳ）、処理対象のＰＩＤに対応する該当オブジェクトファイルを「コンテナ名‐ＰＩＤマップ情報」から得られる当該ＰＩＤが動作していたコンテナ上から回収する（ステップＳ５４０）。コンテナコンテキスト毎シンボル解決部２４３は、オブジェクトファイルが回収されたら、シンボル名の前に当該マップ情報から得られる当該ＰＩＤのコンテナ名を当該シンボル（関数）が動作していたコンテナ名として付与する（ステップＳ５５０）。例えば、コンテナ名がｃｔｎ１、関数名がｆｏｏの場合は、「ｃｔｎ１：：ｆｏｏ」というシンボルとして出力する。コンテナコンテキスト毎シンボル解決部２４３は、シンボル名の前に、コンテナ名が付与されたら、収集データをコンテナ名でグルーピングする（ステップＳ５６０）。
コンテナコンテキスト毎シンボル解決部２４３は、処理対象のＰＩＤが「コンテナ名‐ＰＩＤマップ情報」に含まれない場合（ステップＳ５３０；ＮＯ）、ステップＳ５２０においてＯＳ情報から特定された場所から、オブジェクトファイルを回収する（ステップＳ５７０）。
以上から、コンテナコンテキスト毎シンボル解決部２４３は、各サンプリングデータ中の命令アドレスに関数名を対応付けることができる。また、コンテナコンテキスト毎シンボル解決部２４３は、コンテナ名でグルーピングしてデータを出力する為、コンテナコンテキスト毎の分析が可能となる。
頻度集計部２４４は、シンボル解決部２４２が命令アドレスに対応付けた関数名に基づいて、関数単位で頻度集計する。これにより、カウントに使用した性能イベントが、プログラム中のどの処理で多く発生したかを知ることができる。例えば、プログラム中のどの処理でＣＰＵ時間の多くを消費しているか、どの処理の命令が多く実行されたか、について知ることができる。
コンテナコンテキスト毎頻度集計部２４５は、コンテナコンテキスト毎シンボル解決部２４３がコンテナコンテキスト毎にシンボル解決を実施した結果に対して頻度集計を実施する。したがって、コンテナコンテキスト毎頻度集計部２４５によれば、コンテナ上で動作した処理の延長上で動作した一連の処理についても、その処理の頻度を把握することができる。
［出力生成部について］
図２に示すように、出力生成部２５０は、頻度出力部２５２と、コンテナコンテキスト毎頻度出力部２５４と、時間分割頻度順出力部２５６と、問題発生箇所判定部２５８と、を備える。
頻度出力部２５２は、シンボル解決部２４２が、サンプリングデータに基づいて、命令アドレスに関数名を対応付けたデータに対して、頻度集計部２４４が頻度集計した集計結果を、頻度順に出力する。
頻度出力部２５２の出力について具体例を用いて説明する。図１３は、サンプリング対象の仮想環境を示す模式図である。図１３に示すように、仮想環境は、ホスト４００に４つの物理ＣＰＵ（ｐＣＰＵ０_４１０、ｐＣＰＵ１_４２０、ｐＣＰＵ２_４３０、ｐＣＰＵ３_４４０）を備える。仮想マシン５００には、ホスト４００の物理ＣＰＵ（ｐＣＰＵ０_４１０）を用いて、仮想ＣＰＵ（ｖＣＰＵ０_５１０）が割り当てられ、物理ＣＰＵ（ｐＣＰＵ１_４２０）を用いて、仮想ＣＰＵ（ｖＣＰＵ１_５２０）が割り当てられている。また、仮想ＣＰＵ（ｖＣＰＵ０_５１０）を用いて、コンテナ(ｃｔｎ１_６１０)が構築され、物理ＣＰＵ（ｐＣＰＵ２_４３０）を用いて、コンテナ(ｃｔｎ２_６２０)が構築されている。図１３に示すように、アプリケーション（ｈｉｍｅｎｏ_７００）は、次の４つの実行環境にバインドして実行される。（１）物理ＣＰＵ（ｐＣＰＵ０_４１０）上で動作する仮想ＣＰＵ（ｖＣＰＵ０_５１０）に構築されるコンテナ(ｃｔｎ１_６１０)、（２）物理ＣＰＵ（ｐＣＰＵ１_４２０）上で動作する仮想ＣＰＵ（ｖＣＰＵ１_５２０）、（３）物理ＣＰＵ（ｐＣＰＵ２_４３０）に構築されるコンテナ(ｃｔｎ２_６２０)、（４）物理ＣＰＵ（ｐＣＰＵ３_４３０）。
図１４は、ホストの解析結果の頻度出力部の出力を示す図である。図１４を用いて、頻度出力部２５２の出力を説明する。図１４は、サンプリング部２３１が、収集周期１ｍｓ、収集時間３０秒で、サンプリングを行ったデータに対して、シンボル解決、および、頻度集計が行われた結果を高頻度順に表示している。図１４においてＴｏｔａｌの下に表示されている数字は、図１４の右端に表示されている各関数のホスト全体でのデータサンプリング数を示している。図１４においてｒａｔｉｏの下に表示されている数字は、図１４の右端に表示されている各関数のホスト全体における動作比率を示している。図１４においてｐＣＰＵ０、ｐＣＰＵ１、ｐＣＰＵ２、ｐＣＰＵ３の文字の下に表示される数字は、図１４の右端に表示されている各関数のｐＣＰＵ０、ｐＣＰＵ１、ｐＣＰＵ２、ｐＣＰＵ３の各物理ＣＰＵにおけるデータサンプリング数を示している。
図１４を参照すると、例えば、[ｃｔｎ２]：ｕｓｒ／ｂｉｎ／ｈｉｍｅｎｏ：：ｊａｃｏｂｉの左側に表示される数字から、コンテナ（ｃｔｎ２）の上で実行されるｈｉｍｅｎｏは、ホスト全体において２１．６６％の動作比率であることがわかる。また、コンテナ（ｃｔｎ２）の上で実行されるｈｉｍｅｎｏは、ホスト４００が備える４つの物理ＣＰＵの内、ｐＣＰＵ２のみで処理が実行され、ｐＣＰＵ２でのデータサンプリング数は２６００７であることがわかる。
このようにホストの解析結果の頻度出力部２５２の出力を確認することで、ホスト全体において、どの関数に最も処理が集中しているかを把握することができる。
図１５は、ゲストの解析結果の頻度出力部の出力を示す図である。図１５は、図１４と同じく、収集周期１ｍｓ、収集時間３０秒で、サンプリングを行ったデータに対して、シンボル解決、および、頻度集計が行われた結果を高頻度順に表示している。図１５においてＴｏｔａｌの下に表示されている数字は、図１５の右端に表示されている各関数のゲスト全体でのデータサンプリング数を示している。図１５においてｒａｔｉｏの下に表示されている数字は、図１５の右端に表示されている各関数のゲスト全体における動作比率を示している。図１５において、ｖＣＰＵ０、ｖＣＰＵ１の下に表示される数字は、図１５の右端に表示されている各関数のｖＣＰＵ０、ｖＣＰＵ１の各仮想ＣＰＵでのデータサンプリング数を示している。
図１５を参照すると、例えば、[ｃｔｎ１]：ｕｓｒ／ｂｉｎ／ｈｉｍｅｎｏ：：ｊａｃｏｂｉの左側に表示される数字から、コンテナ（ｃｔｎ１）の上で実行されるｈｉｍｅｎｏは、ゲスト全体において４２．９４％の動作比率であることがわかる。
このようにゲストの解析結果の頻度出力部２５２の出力を確認することで、ゲスト全体において、どの関数に最も処理が集中しているかを把握することができる。
コンテナコンテキスト毎頻度出力部２５４は、コンテナコンテキスト毎シンボル解決部２４３が、コンテナコンテキスト毎にシンボル解決を行った結果に対して、コンテナコンテキスト毎頻度集計部２４５がコンテナコンテキスト毎に頻度集計した結果を、頻度順に出力する。
図１６は、コンテナ（ｃｔｎ２）のコンテナコンテキスト毎の頻度集計の頻度出力を示す図である。図１６の右端に表示されている関数名の前にコンテナ名が付与された[ｃｔｎ２]：ｕｓｒ／ｂｉｎ／ｈｉｍｅｎｏ：：ｊａｃｏｂｉ、および、[ｃｔｎ２]：ｕｓｒ／ｌｉｂ６４／ｌｉｂｃ－２．２８．ｓｏ：：ｍｅｍｃｐｙは、コンテナ上で実行されるアプリケーションの関数である。また、図１６の右端に表示されているコンテナ上で実行されるアプリケーションの関数の下方に表示されているｐｒｅｐａｒｅ＿ｅｘｉｔｅ＿ｔｏ＿ｕｓｅｒｍｏｄｅから、ｎａｔｉｖｅ＿ｓｃｈｅｄ＿ｃｌｏｃｋまでに表示されている関数は、コンテナの処理延長上で動作したホストＯＳのカーネル関数である。また、図１６の右端の下端に表示されているｕｓｒ／ｂｉｎ／ｄｏｃｋｅｒ－ｃｏｎｔａｉｎｅｒｄ－ｓｈｉｍは、コンテナ本体プログラムである。
このように、コンテナコンテキスト毎頻度集計部２４５の集計結果をコンテナコンテキスト毎頻度出力部２５４が出力した結果を確認することで、コンテナ上で動作した処理の延長上で動作した一連の処理についても、その処理の頻度を把握することができる。
図１４、図１５、図１６を用いて説明したように、頻度出力部２５２は、サンプリンデータを取得したホスト毎、ゲスト毎、コンテナ毎に頻度集計した結果を出力することができる。したがって、頻度出力部２５２の出力を確認することで、異常が発生した場合に、異常が発生した箇所の絞り込み作業を効率的に実施することができる。
時間分割頻度順出力部２５６は、サンプリング部２３１がサンプリングデータを収集する収集時間全体を所定の時間間隔で区切り、所定の時間間隔で頻度集計した結果を時系列で出力する。
時間分割頻度順出力部２５６が出力した時系列データを確認することで、一時的に発生した性能の変化、あるいは、異常が検知可能となる。
問題発生箇所判定部２５８は、頻度出力部２５２、又は、コンテナコンテキスト毎頻度出力部２５４の出力結果と、通常時の性能プロファイルの結果と、を比較して異常について判定する。
図１７は、問題発生箇所判定部の処理の手順を説明するフローチャートである。図１７を用いて問題発生箇所判定部２５８の処理を説明する。頻度集計部２４４が集計したコンテナコンテキスト毎の各関数の頻度の集計結果を取得する（ステップＳ６００）。取得した各関数の頻度の集計結果に記憶部２２０に記憶された通常時の性能プロファイルの結果に登場しない関数が登場しているか判定する（ステップＳ６１０）。通常時の性能プロファイルの結果に登場しない関数が登場する場合（ステップＳ６１０；ＹＥＳ）、当該関数が登場するコンテナを抽出する（ステップＳ６２０）。次に、取得した各関数の頻度の集計結果と、通常時の性能プロファイルの結果とを比較して、関数比率が異なるコンテナがあるか判定する（ステップＳ６３０）。ここで、関数比率が異なるコンテナがあるか否かは、コンテナで実行される関数の中に、通常時と比較して所定の動作比率の差がある関数が存在するか否かを基準に判定してよい。例えば、通常時と比較して動作比率が１５ｐｏｉｎｔｓ以上異なる関数が存在するコンテナがある場合に、当該コンテナは関数比率が異なるコンテナであると判定してよい。関数比率が異なるコンテナがある場合（ステップＳ６３０；ＹＥＳ）、関数比率が異なるコンテナを抽出する（ステップＳ６４０）。関数比率が異なるコンテナが抽出されたら、抽出されたコンテナの全コンテナに対する割合が所定の閾値以上か判定する（ステップＳ６５０）。ここで、ステップＳ６５０における抽出されたコンテナの全コンテナに対する割合の所定の閾値は、例えば、９０％以上としてよい。抽出されたコンテナの全コンテナに対する割合が所定の閾値以上の場合（ステップＳ６５０；ＹＥＳ）、異常が発生した原因はインフラ側の問題と判定する（ステップＳ６６０）。
通常時の性能プロファイルの結果に登場しない関数は登場しない場合（ステップＳ６１０；ＮＯ）、取得した各関数の頻度の集計結果と、通常時の性能プロファイルの結果とを比較して、関数比率が異なるコンテナがあるか判定する（ステップＳ６７０）。関数比率が異なるコンテナがある場合（ステップＳ６７０；ＹＥＳ）、関数比率が異なるコンテナを抽出する（ステップＳ６４０）。
ステップＳ６７０において、関数比率が異なるコンテナがない場合（ステップＳ６７０；ＮＯ）、正常と判定する（ステップＳ７００）。
ステップＳ６５０において、抽出されたコンテナの全コンテナに対する割合が所定の閾値以上ではない場合（ステップＳ６５０；ＮＯ）、抽出されたコンテナの全コンテナに対する割合が所定の閾値以下か判定する（ステップＳ６８０）。ここで、ステップＳ６８０における抽出されたコンテナの全コンテナに対する割合の所定の閾値は、例えば、１０％以下としてよい。抽出されたコンテナの全コンテナに対する割合が所定の閾値以下の場合（ステップＳ６８０；ＹＥＳ）、異常が発生した箇所はコンテナ側であると判定する（ステップＳ６９０）。
ステップＳ６８０において、抽出されたコンテナの全コンテナに対する割合が所定の閾値以下ではない場合（ステップＳ６８０；ＮＯ）、異常が発生した箇所は不明であると判定する（ステップＳ７１０）。
このように問題発生箇所判定部２５８は、コンテナコンテキスト毎の性能プロファイリングの結果と、通常時の性能プロファイルの結果を比較することによって、異常が発生しているか否か、および、異常が発生している場合は、異常が発生している箇所はインフラ側かコンテナ側か、又は、異常の発生している箇所は不明かを判定する。したがって、クラウドコンピューティングシステムのコンテナ環境において、コンテナ内の動作アプリケーションに問題が発生しているのか、ホストＯＳ側などの問題なのかを切り分けることが可能となる。
次に、本開示に係る障害原因特定プログラムを実装した管理システム２００の処理について、以下の順序で説明する。
１．サンプリングデータの取得
２．コンテナ管理構造体、コンテナ名‐ＰＩＤ値マップ情報の作成
３．オブジェクトファイルの動的回収
４．コンテナコンテキスト毎のシンボル解決
５．コンテナコンテキスト毎の頻度集計
６．コンテナコンテキスト毎の頻度出力
７．問題発生箇所の判定
１．サンプリングデータの取得
管理システム２００は、サンプリング部２３１を介して、サーバ装置１１０からサンプリングデータを取得する。サンプリングデータを取得したら、ＯＳ情報／環境情報収集部２３２が、ホストＯＳ１４０からＯＳ情報として、ＰＩＤ：プログラム名：プログラムのオブジェクトファイルのファイルパス、の組情報を取得する。ＯＳ情報を取得したら、オブジェクトファイル静的回収部２３３は、ＯＳ情報として取得したＰＩＤ値から、当該ＰＩＤ値に対応するプログラムのオブジェクトファイルのファイルパスを特定し、オブジェクトファイルをコピーして回収する。
２．コンテナ管理構造体、コンテナ名‐ＰＩＤ値マップ情報の作成
管理システム２００は、サンプリングデータの取得が完了したら、コンテナ管理構造体、および、コンテナ名‐ＰＩＤマップ情報を作成する。コンテナ管理構造体、および、コンテナ名‐ＰＩＤマップ情報の作成手順は、前述の通りであるから説明を省略する。
３．オブジェクトファイルの動的回収
管理システム２００は、オブジェクトファイル動的回収部２３５を介して、コンテナ消滅のタイミングで消滅コンテナのオブジェクトファイルを回収する。
４．コンテナコンテキスト毎のシンボル解決
管理システム２００は、データ収集部２３０が収集したサンプリングデータ、オブジェクトファイルを用いて、コンテナコンテキスト毎シンボル解決部２４３を介して、コンテナコンテキスト毎にシンボル解決を実行する。コンテナコンテキスト毎のシンボル解決は、前述の通りであるから説明を省略する。
５．コンテナコンテキスト毎の頻度集計
管理システム２００は、コンテナコンテキスト毎のシンボル解決が完了したら、コンテナコンテキスト毎頻度集計部２４５を介して、コンテナコンテキスト毎に頻度集計を行う。コンテナコンテキスト毎の頻度集計は、前述の通りであるから説明を省略する。
６．コンテナコンテキスト毎の頻度出力
管理システム２００は、コンテナコンテキスト毎の頻度集計が完了したら、コンテナコンテキスト毎頻度出力部２５４を介して、コンテナコンテキスト毎の頻度集計の結果を頻度順に出力する。
７．問題発生箇所の判定
管理システム２００は、コンテナコンテキスト毎の頻度出力が完了したら、問題発生箇所判定部２５８を介して、コンテナコンテキスト毎の頻度出力の結果と、記憶部２２０に記憶された通常時の性能プロファイルの結果と、を比較して問題発生箇所について判定する。問題発生箇所の判定については前述の通りであるから、説明を省略する。
以上説明したように、本開示に係る障害原因特定プログラムを実装した管理システム２００によれば、クラウドコンピューティングシステムのコンテナ環境において、コンテナ内の動作アプリケーションに問題が発生しているのか、ホストＯＳ側などの環境基盤側の問題なのかを切り分けることが可能となる。
［数値等］
上記実施例で用いたサーバ台数、等は、あくまで一例であり、任意に変更することができる。
［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
［ハードウェア構成］
図１８は、ハードウェア構成例を説明する図である。図１８に示すように、情報処理装置８００は、通信装置８１０、ＨＤＤ（Hard Disk Drive）８２０、メモリ８３０、プロセッサ８４０を有する。また、図１８に示した各部は、バス等で相互に接続される。
通信装置８１０は、ネットワークインタフェースカードなどであり、他の装置との通信を行う。ＨＤＤ８２０は、図２に示した機能を動作させるプログラムやＤＢを記憶する。
プロセッサ８４０は、図２に示した各処理部と同様の処理を実行するプログラムをＨＤＤ８２０等から読み出してメモリ８３０に展開することで、図２等で説明した各機能を実行するプロセスを動作させる。例えば、このプロセスは、情報処理装置８００が有する各処理部と同様の機能を実行する。具体的には、プロセッサ８４０は、データ収集部２３０、解析処理部２４０、出力生成部２５０等と同様の機能を有するプログラムをＨＤＤ８２０等から読み出す。そして、プロセッサ８４０は、データ収集部２３０、解析処理部２４０、出力生成部２５０等と同様の処理を実行するプロセスを実行する。
このように、情報処理装置８００は、プログラムを読み出して実行することで障害原因特定方法を実行する情報処理装置として動作する。また、情報処理装置８００は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、情報処理装置８００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＭＯ（Magneto－Optical disk）、ＤＶＤ（Digital Versatile Disc）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。
２００ 管理システム
２１０ 制御部
２２０ 記憶部
２３０ データ収集部
２３１ サンプリング部
２３２ ＯＳ情報／環境情報収集部
２３３ オブジェクトファイル静的回収部
２３４ コンテナ管理構造体／マップ情報作成部
２３５ オブジェクトファイル動的回収部
２４０ 解析処理部
２４２ シンボル解決部
２４４ 頻度集計部
２４５ コンテナコンテキスト毎頻度集計部
２５０ 出力生成部
２５２ 頻度出力部
２５４ コンテナコンテキスト毎頻度出力部
２５６ 時間分割頻度順出力部
２５８ 問題発生箇所判定部

Claims (8)

  1. コンピュータに、
    コンテナ環境で動作する各プロセスに関するプロセス情報を収集し、
    前記プロセス情報に基づき、コンテナごとにプロセスの派生関係を取得し、
    前記コンテナごとの前記プロセスの派生関係にしたがって、前記各プロセスの関数と前記各プロセスが動作するコンテナとを対応付けたシンボル情報を生成し、
    前記シンボル情報にしたがって、前記関数の頻度を集計した集計結果を生成し、
    前記集計結果に基づき、障害発生時の原因を特定する処理を実行させることを特徴とする障害原因特定プログラム。
  2. 前記収集する処理は、
    一定間隔で、コンテナ内で動作する各動作プログラムに関する、前記各動作プログラムを起動した親プログラムに関する情報を含むプログラム動作情報を収集する処理を含み、
    前記取得する処理は、
    前記プロセス情報と前記プログラム動作情報とに基づき、前記プロセスの派生関係を取得し、
    前記生成する処理は、１つのコンテナから呼び出されて実行される一連の処理であるコンテナコンテキストごとに、前記集計結果を生成する、処理を含むことを特徴とする請求項１に記載の障害原因特定プログラム。
  3. 前記生成する処理は、
    前記プロセスの派生関係に含まれるプロセスについては、当該プロセスを実行するコンテナからオブジェクトファイルを回収し、前記プロセスの派生関係に含まれないプロセスについては、オペレーティングシステムからオブジェクトファイルを回収し、
    前記各プロセスの前記オブジェクトファイルを用いて前記各プロセスの関数を特定し、特定した関数を用いて前記シンボル情報を生成する、処理を含むことを特徴とする請求項２に記載の障害原因特定プログラム。
  4. 前記コンテナが消滅するタイミングで、前記コンテナ内で動作する各プロセスに関する各オブジェクトファイルを取得する、処理を前記コンピュータに実行させることを特徴とする請求項３に記載の障害原因特定プログラム。
  5. 前記取得する処理は、
    オペレーティングシステムのプロセス実行状況を監視し、
    前記オペレーティングシステムが実行を完了させる終結プロセスをフックし、
    前記終結プロセスの実行が終了する前に、前記終結プロセスのオブジェクトファイルを取得する、処理を含むことを特徴とする請求項４に記載の障害原因特定プログラム。
  6. 前記生成する処理は、
    前記コンテナ環境の通常運転時の前記コンテナコンテキストごとの前記関数の頻度である通常時の集計結果と、前記コンテナ環境の障害発生時の前記コンテナコンテキストごとの前記関数の頻度である異常時の集計結果とを生成する処理を含み、
    前記特定する処理は、
    前記通常時の集計結果と前記異常時の集計結果とを比較し、前記障害発生時の原因を特定する処理を含む、
    ことを特徴とする請求項２から４のいずれか一つに記載の障害原因特定プログラム。
  7. 前記特定する処理は、
    前記通常時の集計結果と前記異常時の集計結果とを比較し、登場する関数が異なるコンテナ、または、登場する関数比率が異なるコンテナを抽出し、
    抽出されたコンテナが全コンテナに占める割合を算出し、
    前記割合が閾値未満の場合は、コンテナ側の障害と特定し、前記割合が前記閾値以上の場合は、前記コンテナ環境を提供する基盤側の障害と特定する、
    処理を含むことを特徴とする請求項６に記載の障害原因特定プログラム。
  8. コンピュータが、
    コンテナ環境で動作する各プロセスに関するプロセス情報を収集し、
    前記プロセス情報に基づき、コンテナごとにプロセスの派生関係を取得し、
    前記コンテナごとの前記プロセスの派生関係にしたがって、前記各プロセスの関数と前記各プロセスが動作するコンテナとを対応付けたシンボル情報を生成し、
    前記シンボル情報にしたがって、前記関数の頻度を集計した集計結果を生成し、
    前記集計結果に基づき、障害発生時の原因を特定する
    処理を実行することを特徴とする障害原因特定方法。
JP2020151392A 2020-09-09 2020-09-09 障害原因特定プログラムおよび障害原因特定方法 Withdrawn JP2022045680A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2020151392A JP2022045680A (ja) 2020-09-09 2020-09-09 障害原因特定プログラムおよび障害原因特定方法
US17/368,899 US11734098B2 (en) 2020-09-09 2021-07-07 Computer-readable recording medium storing failure cause identification program and method of identifying failure cause

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020151392A JP2022045680A (ja) 2020-09-09 2020-09-09 障害原因特定プログラムおよび障害原因特定方法

Publications (1)

Publication Number Publication Date
JP2022045680A true JP2022045680A (ja) 2022-03-22

Family

ID=80470282

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020151392A Withdrawn JP2022045680A (ja) 2020-09-09 2020-09-09 障害原因特定プログラムおよび障害原因特定方法

Country Status (2)

Country Link
US (1) US11734098B2 (ja)
JP (1) JP2022045680A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023518136A (ja) * 2021-02-20 2023-04-28 ベイジン バイドゥ ネットコム サイエンス テクノロジー カンパニー リミテッド ファイル処理方法、装置、電子デバイス、記憶媒体、及びプログラム

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230042105A1 (en) * 2021-08-03 2023-02-09 Vertiv It Systems, Inc. System and method for optimizing computing resources and data flow in networks
CN114595198B (zh) * 2022-03-15 2023-09-05 抖音视界有限公司 崩溃解析方法、装置、电子设备及存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8473922B2 (en) * 2001-09-19 2013-06-25 Hewlett-Packard Development Company, L.P. Runtime monitoring in component-based systems
US10042697B2 (en) 2015-05-28 2018-08-07 Oracle International Corporation Automatic anomaly detection and resolution system
CN105389243B (zh) * 2015-10-26 2018-06-05 华为技术有限公司 一种容器监控方法和装置
US10367711B2 (en) * 2017-09-05 2019-07-30 Vmware, Inc. Protecting virtual computing instances from network failures
US20200341833A1 (en) * 2019-04-23 2020-10-29 Vmware, Inc. Processes and systems that determine abnormal states of systems of a distributed computing system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023518136A (ja) * 2021-02-20 2023-04-28 ベイジン バイドゥ ネットコム サイエンス テクノロジー カンパニー リミテッド ファイル処理方法、装置、電子デバイス、記憶媒体、及びプログラム

Also Published As

Publication number Publication date
US11734098B2 (en) 2023-08-22
US20220075678A1 (en) 2022-03-10

Similar Documents

Publication Publication Date Title
JP2022045680A (ja) 障害原因特定プログラムおよび障害原因特定方法
US8321863B2 (en) Security management device and method
US7496795B2 (en) Method, system, and computer program product for light weight memory leak detection
CN104360878B (zh) 一种应用软件部署的方法及装置
US10620877B2 (en) Managing a collection of data
US20160098390A1 (en) Command history analysis apparatus and command history analysis method
KR20080010341A (ko) 하드웨어 플랫폼 클래스들의 식별을 가속하기 위한 시스템및 방법
US8656225B2 (en) Network fault management in busy periods
CN112306802A (zh) 系统的数据获取方法、装置、介质和电子设备
JPWO2017110720A1 (ja) ログ分析システム、ログ分析方法及びプログラム
JP5740338B2 (ja) 仮想環境運用支援システム
US9021078B2 (en) Management method and management system
CN109189652A (zh) 一种封闭网络终端行为数据的采集方法及系统
JP7338246B2 (ja) 情報処理装置、ログ参照プログラム
US20170206143A1 (en) Management apparatus, management method, and computer-readable recording medium recorded with management program
WO2015049771A1 (ja) コンピュータシステム
JP2014174609A (ja) ハードウェア構成見積システム、ハードウェア構成見積方法及びハードウェア構成見積プログラム
Huffman Windows Performance Analysis Field Guide
JP5519436B2 (ja) システム安定度を分析する情報分析装置、情報分析方法、情報分析システムおよびプログラム
JPWO2018110327A1 (ja) 異常識別システム、方法及びプログラム
CN110928640A (zh) 一种云平台的虚拟机带内指标获取方法及系统
JP2015146148A (ja) 仮想マシン管理装置、仮想マシン管理方法、及び、仮想マシン管理プログラム
Halsey et al. Getting Advanced Information
JP7106979B2 (ja) 情報処理装置、情報処理プログラム及び情報処理方法
US20220318374A1 (en) Diagnosis apparatus, diagnosis method, and computer-readable recording medium

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230608

A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20240129