本文へスキップ

用語辞典

WhaTapモニタリングを使っていると、プロジェクト、エージェント、メトリクスのように繰り返し出てくる言葉に出会います。このドキュメントはその用語の意味を1か所にまとめたものです。

WhaTapを初めて導入する方や、他の製品も合わせて使い始めた方が対象です。製品ドキュメントを読んでいて分からない言葉が出てきたら、このドキュメントで探してください。

用語は3つに分けています。製品に関係なく使うWhaTapサービス用語、WhaTap固有ではありませんが知っておくべきモニタリング一般用語、特定の製品でのみ使う製品別用語です。

用語辞典は継続的に更新されます。

WhaTapサービス用語​

製品に関係なくWhaTapサービス全般で使う用語です。

プロジェクト ​

モニタリングの基本単位です。プロジェクト単位でモニタリング対象を分け、メンバーの権限を管理します。

アプリケーション、サーバー、データベースのようにWhaTap製品を基準に作成します。製品が異なればプロジェクトも異なります。同じ製品でもFront、Gateway、APIのように用途別に分けられます。

グループ ​

複数のプロジェクトをまとめて管理する単位です。製品が異なるプロジェクトもまとめられます。たとえば1つのチームがサーバー、アプリケーション、データベースを使う場合、3つのプロジェクトを1つのグループにまとめます。

グループにメンバーを追加すると、グループ内のすべてのプロジェクトに同じ権限が適用されます。

1つのプロジェクトは1つのグループにのみ属します。グループに属さないプロジェクトもあります。

組織 ​

複数のグループをまとめて管理する最上位の単位です。ほとんどの場合、プロジェクトとグループだけで十分です。

運用管理サービス(MSP)企業のように複数の顧客をグループに分けて管理する場合に活用します。各グループのメンバーに権限を与えると、グループを独立して運用できます。

エージェント ​

モニタリング対象からデータを収集し、WhaTap収集サーバーへ送るプログラムです。WhaTapモニタリングはエージェントが送るデータで動作するため、製品を使うにはまずエージェントをインストールします。

エージェントは製品ごとに異なり、インストール場所と構成もモニタリング対象によって変わります。

TargetLocation
アプリケーション(APM)アプリケーションサーバー。アプリケーションとともに実行
サーバーモニタリングするサーバー
データベースDBサーバーではなく別のサーバー。エージェントがDBに接続して収集
コンテナ(Kubernetes)クラスター。マスターエージェントとノードエージェントで構成

1つのエージェントが複数の対象を収集することもあります。たとえばデータベースエージェントは、クラスターの代表ノード1か所にインストールすれば残りのノードを自動的に見つけて一緒に収集します。

エージェントの名前は製品に従います。Javaエージェント、PHPエージェント、サーバーエージェントのように呼びます。データベースだけは役割の異なるエージェントが3つあるため、それぞれの名前を使います。

ノート

製品別のインストール方法は各製品のインストールドキュメントを参照してください。

収集サーバー(Collection Server) ​

エージェントが送るモニタリングデータを受け取るサーバーです。SaaSではWhaTapが運用する収集サーバーを使うため、別途構築する必要はありません。

インスタンス ​

モニタリングの個別単位です。何を1つと数えるかは製品によって異なります。

ProductInstance
アプリケーション(APM)エージェントを適用したアプリケーションプロセス1つ。同じアプリケーションを複数台で起動すると、それぞれがインスタンス
サーバーサーバー1台
データベースDBノード1つ
コンテナ(Kubernetes)ノードまたはコンテナ1つ

メトリクス ​

モニタリング対象から収集した数値指標です。CPU使用率、レスポンス時間、トークン使用量のように時間とともに変わる値を時系列で保存します。

MXQL ​

WhaTapが収集したデータを直接照会するクエリ言語です。メトリクスクエリ言語という意味です。

標準画面では提供されない形でデータを抽出したり、収集値をそのまま確認したりするときに使います。文法と関数はMXQLガイドを参照してください。

メトリクスチャート (Metrics Chart)

収集されたデータを時系列チャートとして表示します。時間ゾーンを選択して測定項目を選ぶと結果が表示されます。

ダッシュボード

ダッシュボードを使用して、システム全体のステータスをリアルタイムで確認できます。ダッシュボードでは、進行中のトランザクション状況、終了トランザクションのレスポンス時間分布、ユーザー数、CPU、メモリ推移などの主要指標が表示されます。

ノート

キューブ ​

WhaTapが5分単位でまとめた統計データです。製品ごとにキューブがあり、キューブ分析はこのデータをもとに過去の区間を確認する機能です。

リアルタイム指標が現在の状態を示すのに対し、キューブは過去の区間を5分単位で振り返るときに使います。

ノート

製品別のキューブ画面は各製品のドキュメントを参照してください。保存方式はキューブデータストアに整理されています。

ウィジェット ​

ダッシュボードを構成する個別の要素です。チャート、表、数値など1つの指標や観点を表示します。ウィジェットを集めてダッシュボードを構成します。

フレックスボード

ユーザーが要望する方法でカスタマイズできるダッシュボードです。アプリケーション、サーバー、データベース、コンテナなどWhaTapプロジェクトのデータを画面に自由に配置できます。

ノート

詳細については、次の文書を参照してください。

アラート ​

設定した条件に該当する状況が発生すると、指定したチャネルで知らせる機能です。どの状況を検知するかはイベント設定で決めます。

イベント ​

モニタリング対象で検知した特定の状況です。どの状況をイベントとみなすかはイベント設定で条件として決め、イベントが発生するとアラートを送ります。

通知(Notification) ​

モニタリング対象に問題が発生すると、さまざまなチャネルでユーザーへリアルタイムに送る知らせです。

システムの特性に合わせてあらかじめ定義した通知ルールを提供し、必要であれば条件を直接設定できます。

oname · okind ​

エージェントを識別する2つの値です。対で使いますが、指すものが異なります。

OptionDescription
onameエージェントのオブジェクト名。エージェント1つを指す固有値
okindエージェントの種類。用途が同じエージェントをまとめる値

onameが名札ならokindは分類表です。たとえばモバイルUI用途のエージェントであればokindをmobile_uiに指定し、同じ用途でまとめて確認できます。

-Dwhatap.oname=web-01
-Dwhatap.okind=mobile_ui

モニタリング一般用語​

WhaTap固有ではありませんが、モニタリングを理解するために必要な用語です。

ログ (Log)

ログは、アプリケーションの実行中に発生するイベントやメッセージなどを記録したファイルです。

アプリケーションのアクティビティと発生した問題の原因を理解するには、ログファイルを確認する必要があります。

モニタリング

モニタリング(Monitoring)とは、ある対象を監視、観察するという意味です。ITサービス分野では、限られたコストとリソースでサービスを提供します。そのため、モニタリングを通じて予期しない状況やエラーに備え、克服することが重要です。

Observability(オブザーバビリティ) ​

システムが出力するデータから内部で何が起きているかを把握できる性質です。

モニタリングがあらかじめ決めた指標が正常範囲かを確認するものだとすれば、オブザーバビリティは予想しなかった問題が起きたときに原因まで追跡することに重点を置きます。

APM(Application Performance Management) ​

アプリケーションのパフォーマンス管理を意味します。アプリケーションのパフォーマンスはWebサービスのレスポンス速度で測定するため、APMはトランザクションを追跡し分析します。

  • Application、モニタリング対象のアプリケーション
  • Performance、レスポンス速度で測定するパフォーマンス
  • ManagementまたはMonitoring

WhaTapではアプリケーションモニタリング製品がAPMに該当します。

ノート

詳細は次のドキュメントを参照してください。

OpenMetrics ​

Prometheusのメトリクス形式を基にした時系列指標の標準です。WhaTapはこの形式で公開される指標を収集し、照会と分析ができます。

OpenAgent ​

PrometheusおよびOpenMetrics形式を公開するエンドポイントから指標を収集するエージェントです。Goでビルドした静的バイナリのため、別途ランタイムをインストールする必要がありません。

トポロジー ​

構成要素の間の呼び出し関係を図で表したものです。どの地点で遅延やエラーが発生するかを流れとして把握できます。

トランザクション (Transaction)

アプリケーションモニタリングによるトランザクションとは、アプリケーションにログインする単一リクエスト(request)がアプリケーションの処理過程を経てレスポンス(response)として返すまでの過程を指します。

TPS (Transactions Per Second)

毎秒処理されるトランザクションの数を意味します。サービス性能指標の基準になります。WhaTapは、プロジェクト全体のTPSをリアルタイムで表示します。

処理量

性能に関して処理量を完了できる要求数を意味します。これは、システムが処理するトランザクションの数を指します。

処理量は、秒単位または分単位で測定します。処理量は要求量と異なります。 処理量は、終了したリクエストの量です。1秒当たりのリクエスト量(RPS)が100、1秒当たりの処理量(TPS)が10である場合、90件のリクエストはまだ処理されていない状態です。

平均レスポンス時間

アプリケーションサーバーがユーザーにリクエストの結果を戻すのに掛かる時間です。WhaTapのサービスは、5秒間隔でトランザクションの平均レスポンス時間を計算します。平均レスポンス時間は、チューニング指標として意味があります。

スレッド (Thread)

プロセス内での実行単位です。すべてのプロセスには、1つ以上のスレッドが存在し、タスクを実行します。

また、2つ以上のスレッドを持つプロセスをマルチスレッドプロセス(multi-thread process)といいます。 各スレッドには、独自のスタックとレジスタがあります。

製品別用語​

特定の製品でのみ使う用語です。

アプリケーションモニタリング(APM)​

アクティブTX (Active Transaction)

進行中のトランザクションを意味します。

ノート

詳細については、次の文書を参照してください。

マルチトランザクション

MSAなど複数のアプリケーションの呼び出し関係を追跡する必要がある場合に問題が発生した場所と改善が必要な場所を特定できる機能です。

トランザクショントレース

単一トランザクションの実行過程で一連の処理過程を意味します。

TXマップ

終了した個々のトランザクションのレスポンス時間の分布図です。ヒットマップと同様に分布パターンによる問題点を発見し、分析することができます。

ヒットマップは、5分時間単位でトランザクションをグループ化して表示し、TXマップはトランザクションを個別に表示します。

Apdex (Application Performance Index)

Apdexは、アプリケーションの性能指標を意味します。Apdexは、レスポンス時間に基づいており、全体リクエストの満足度と受入率を数値化します。Apdexは、ユーザー満足度の指標として使用でき、0~1の間の値を持ちます。

ノート

詳細については、次の文書を参照してください。

ヒットマップ

レスポンス時間の分布チャートです。特定の期間のレスポンス時間の分布をひと目で確認できます。

トランザクションの発生場所によって、遅いトランザクションを簡単に見つけることができます。色分けされているのでエラーの発生有無についても迅速に見つけることができます。
X軸はトランザクションの終了時間、Y軸はレスポンス時間を意味します。ヒットマップ上の特定の範囲をドラッグすると、トランザクション一覧を表示する画面に移動します。

ノート

詳細については、次の文書を参照してください。

トップスタック (Top Stack)

トップスタックでは、トランザクションからスタック情報を収集して、実行中のメソッドの使用量統計を提供します。

スタックの最上位の使用量統計を使用して、サービスに最も影響を与えるメソッドを特定します。メソッドの呼び出し頻度を把握することで、CPUまたはメモリの負荷の原因を分析できます。

ノート

詳細については、次の文書を参照してください。

ユニークスタック (Unique Stack)

実行されたメソッドのセットが同じ場合の統計情報です。ユニークなスタックを通じて、一般的に使用されるスタックに関する情報を取得できます。

ユニークスタックに多く表示されている場合は、統計的に頻繁な呼び出しまたは長時間動作するメソッドです。

ノート

詳細については、次の文書を参照してください。

アクティブスタック (Active Stack)

実行中のトランザクションのスタック情報を収集する機能です。スタック情報は10秒ごとに収集されます。収集されたデータは統計によって確認できます。

統計情報は、長時間実行されるメソッドであるか、短時間に実行されるが頻繁に実行されるメソッドであるかを比率で識別できます。トランザクションの進行中にメソッドのレベルでどの部分が遅延しているかを確認できます。

ノート

詳細については、次の文書を参照してください。

ヒープメモリ (Heap Memory)

JVM(Java仮想マシン)は、プログラムを実行するためにメモリにデータ保存空間を割り当てます。

メモリ空間は、大きく3つの領域に分類されます。Static、Stack、Heap領域です。オブジェクト(インスタンス)、配列などの主要データは、Heapメモリ領域に保存されます。

ノート

詳細については、次の文書を参照してください。

同時接続ユーザー (Realtime User)

リアルタイムにブラウザのユーザー数を表示します。10秒ごとに、5分以内にトランザクションを行ったユーザーをカウントして表示します。

ユーザーはブラウザのIPに基づいてカウントします。エージェント設定でユーザーを区別するためにIPまたはクッキーを使用することができます。

アプリケーショントポロジー

プロジェクト範囲に含まれるすべてのアプリケーションのリレーションシップ情報を表現します。

アクティブステータス (Active Status)

アクティブTXの各ステータスごとの数を表示します。

  • METHOD:メソッド実行中の状態
  • SQL:SQLを実行中の状態
  • HTTPC:外部APIの呼び出し状態
  • DBC:トランザクションがConnection Poolから新しいConnectionを取得(get)しようとしている状態
  • SOCKET:外部にTCP Socketを接続している状態
ノート

詳細については、次の文書を参照してください。

MSA分析 (Microservices Architecture)

URLを基準に、各サービス間の呼び出し関係の割合を表示します。

CallerとCallee

  • Caller:サービスを呼び出したトランザクション(呼び出し元)を意味します。
  • Callee:サービスを呼び出されたトランザクション(呼び出し先)を意味します。

性能推移

指定した時間の性能に影響する情報を表示することができます。 また、各アプリケーションサーバーごとにグラフを確認できます。性能に大きな影響を与えるアプリケーションサーバーが何かを確認できます。

性能推移で表示できる情報は、以下の通りです。

  • リアルタイムユーザー
  • トランザクション/秒(合計)
  • レスポンス時間
  • CPU
  • ヒープメモリ
  • アクティブTX
  • 多く処理されたトランザクションTop 10
  • HTTP Call Top 10
  • SQL Top 10

リソースボード (Resource Board)

リソースボードからプロジェクトに登録されているすべてのサーバーをモニタリングできます。プロジェクト内のすべてのサーバーのサマリー情報とリアルタイムリソース使用量の変化を確認できるCPU Resource Mapマップを提供します。

全体リソースの規模、CPU、メモリ、プロセスの使用率の上位5つを表示します。リソースボードを使用すると、障害の状況をすぐに認識して対応します。

ノート

詳細については、次の文書を参照してください。

Kubernetesモニタリング​

マスターエージェント・ノードエージェント ​

Kubernetesモニタリングのエージェントです。2つを合わせてインストールします。

AgentDescription
whatap-master-agentクラスターレベルの指標を収集
whatap-node-agentノードとコンテナレベルの指標を収集

WhaTapオペレーター ​

KubernetesにWhaTapエージェントをインストールし管理するオペレーターです。WhatapAgentカスタムリソース(CR)に構成を記述すると、オペレーターがそのとおりにエージェントをデプロイします。

ログモニタリング​

ログモニタリング (Log Monitoring)

WhaTapのログモニタリングを通じてリアルタイムでログを表示することができます。 または、特定の時間、カテゴリ、タグ、またはフィルターを適用して、目的のログのみを選択的に表示することもできます。

ノート

詳細については、次の文書を参照してください。

ライブテール ​

収集中のログをリアルタイムで流しながら確認する画面です。保存しないログも、ログフィルター設定で表示有無をオンにするとライブテールで確認できます。

ログ探索 ​

収集したログを条件で絞り込んで確認する画面です。時間、カテゴリー、タグ、フィルターを組み合わせて必要なログだけを抽出します。

ログパーサー ​

形式が一定でないログをクエリできる構造に変換する機能です。正規表現とGROK文法を使うGROKパーサーと、JSONログを扱うJSONパーサーの2種類があります。

高速インデックス ​

ログを大量に収集する環境で検索速度を上げるために、あらかじめ作成しておくインデックスです。

ログの長期保管 ​

ログは容量が大きく長期間保管しにくいものです。長期保管は原本の代わりに統計の形に縮約して長く残す機能です。

個人情報の非識別化 ​

ログに含まれる個人情報をマスキングしたり、安全な値に置き換えたりする機能です。指定した機密情報は暗号化して保存します。

サーバーモニタリング​

リソースイコライザー

CPU、Memory、Disk I/O、Disk IOPSの上位5つのサーバーの一覧をリアルタイムで表示します。

CPUリソースマップ (CPU Resource Map)

全体サーバーのCPU使用量を示す分布図です。10分間のデータが表示され、10秒ごとに更新されます。

コンパウンドアイ

WhaTapエージェントがインストールされている各サーバーの目(Eye)として表現します。 コンパウンドアイは、サーバーを1か所に集めて表示します。

合計5種類の情報を提供します。

  • CPU使用量
  • メモリ使用量
  • Disk使用量
  • ネットワークのRx (受信量)
  • ネットワークのTx (送信量)
ノート

詳細については、次の文書を参照してください。

DISK I/O ​

Disk I/O(%)指標は、ディスクの使用率を示します。Disk I/O(%)が80%を超えると、システムの性能に影響を与える可能性があります。

デフォルトの警告値は 90%です。Disk I/O(%)が100%の場合は、ディスクがノンストップで動作しているという意味です。

DISK IOPS (Input/Output Operations Per Second)

毎秒の入力・出力操作を表す測定単位です。作業はKiB単位で測定されます。

基本ドライブ技術により、ボリュームタイプが単一のI/Oで計算する最大データ容量が決定されます。一般的にHDDのIOPS範囲は55-180です。SSDのIOPSは3,000~40,000です。

CPU Steal Time ​

CPU Steal Timeは、ハイパーバイザーが他の仮想プロセッサをサービスしている間、仮想CPUが物理CPUを待機する時間をパーセンテージで表示した値です。

仮想環境で動作するVM(Virtual Machine)は、単一ホストにある他のインスタンスとリソースを共有します。

CPU Steal Timeを使用すると、VMで動作するCPUが物理マシンからリソースを割り当てられるために待機している時間を知ることができます。

データベースモニタリング​

DBX · DMX · XOS ​

データベースモニタリングのエージェントです。他の製品は製品名をそのまま使いますが、データベースは役割の異なるエージェントが3つあるため、それぞれに名前を付けています。

AgentDescription
DBXデータベースに接続して指標を収集。DBサーバーではなく別のサーバーにインストール
DMXOracle Pro専用。別途提供
XOSDBサーバーのリソースを追加で収集。任意

Redisサーバー

インメモリ方式のデータリポジトリです。WhaTapでは、HTTPセッションを含むセッションリポジトリとして使用しています。

LLM Observability​

AI Agent ​

LLMを用いて自ら判断し、必要なツールを呼び出して作業を遂行するプログラムです。ユーザーの要求1つを処理するために、複数回のLLM呼び出しとツール実行を経ることもあります。

WhaTapがインストールするエージェントとは別の対象です。WhaTapエージェントはデータを収集する側で、AI Agentは観測される側です。

LLM ObservabilityはAI Agentの実行フローとトークン使用量、レスポンス性能を観測します。

SDK(Software Development Kit) ​

アプリケーションコードから直接呼び出して計測区間を宣言するライブラリです。whatap.llmのworkflowとagentで区間を囲むと、その中で発生したLLM呼び出しが1つのトランザクションにまとまります。

from whatap.llm import workflow

エージェントとは役割が異なります。エージェントはコードを修正せずに自動で計測し、SDKはコードに直接記述して区間の境界を決めます。自動計測だけでは望む単位にならないときにSDKで補います。

LLM(Large Language Model) ​

大量のテキストで学習し、自然言語を理解して生成するAIモデルです。大規模言語モデルとも呼びます。

呼び出すたびにトークン単位で課金され、同じプロンプトを送っても毎回異なるレスポンスを生成します。この2つのため、従来のアプリケーションとは異なる方法でコストと品質を観測する必要があります。