OpenSearch Performance Analyzerは、クラスタのCPU・JVMヒープ・スレッドプール・ディスクIOといった性能メトリクスを、OpenSearch本体（JVM）の負荷とは独立したエージェントから取得するプラグインです。OpenSearch 2.0以降のtarball版・Docker版に標準同梱され、REST APIをポート9600で公開します。ただしOpenSearch 3.0では根本原因分析を担うperformance-analyzer-rcaエージェントが削除され、監視・分析の推奨はTelemetryプラグイン（OpenTelemetry）へ移りました。この記事では、Performance Analyzerの有効化からメトリクスの取得・可視化、性能ボトルネックの切り分け、3.0以降の移行方針までを一次情報に基づいて整理します。バージョンは最新の3.7.0（2026年6月）を基準にしています。
まとめ：Performance Analyzerの要点
- Performance Analyzerはエージェント＋REST APIの2層構成。メトリクス取得APIはポート9600、有効化の操作はOpenSearch本体のポート9200で行う。
- OpenSearch 2.0以降はデフォルト同梱。使わない場合は明示的に無効化・アンインストールしてメモリを節約する。
- OpenSearch 3.0で
performance-analyzer-rcaエージェントが削除され、公式はTelemetryプラグイン（OpenTelemetry）への移行を推奨。メトリクス取得API自体は引き続き利用できる。 - 取得できる指標は
CPU_Utilization・Heap_Used・ThreadPool_QueueSize・Cache_Request_Hit・IO_TotThroughputなど。agg（集約）とdim（ディメンション）で粒度を指定する。 - マネージドのAmazon OpenSearch Serviceは監視をCloudWatchに寄せる設計で、ポート9600を自分で叩くのはセルフマネージド構成が対象。
Performance Analyzerの役割とアーキテクチャ
Performance Analyzerが他の監視手段と異なるのは、メトリクス収集をOpenSearchのJVMから切り離している点です。負荷が高くJVMが応答しづらい状況でも、エージェントが独立してメトリクスを書き出し続けるため、障害時こそ値が取れます。可視化ツールやアラート基盤は、このエージェントが公開するREST APIを叩いて指標を読みます。
エージェントとREST APIの2層構成（ポート9600・/dev/shm）
収集エージェントはクラスタの各ノードで動作し、メトリクスを共有メモリ領域/dev/shm/performanceanalyzer/に一時保存します。読み出しはポート9600のRESTエンドポイントで行い、認証はかかりません（後述のとおりクライアント・サーバー認証は未対応）。保存先が共有メモリのため、重い負荷では共有メモリを最大1GB程度確保します。
デフォルト同梱の状況とバージョン別の変化
Performance Analyzerプラグインは、OpenSearch 2.0以降のtarball／Dockerディストリビューションに含まれています。同梱されない構成で手動導入する場合は、MavenからプラグインのZIPを取得し、bin/opensearch-plugin install（標準のプラグインインストール手順）で各ノードに入れます。バージョン間の最大の分岐点は3.0で、根本原因分析エージェントperformance-analyzer-rcaが削除されました。RCAに依存した運用をしていた場合は、Telemetryプラグインへの置き換えが前提になります（詳細は後述）。OpenSearchの全体的な世代差やアップグレードの背景はOpenSearch 3.0の全体像を理解するための概要と背景で補足しています。
Performance Analyzerの有効化・設定・無効化
同梱されていても、メトリクス収集の有効／無効はクラスタ設定で切り替えます。有効化・無効化のPOSTはOpenSearch本体のポート9200に対して行い、メトリクスの読み出しだけが9600である点を混同しないでください。
クラスタ全体の有効化コマンド（ポート9200）
次のリクエストでクラスタ全体のPerformance Analyzerを有効化します。
curl -XPOST localhost:9200/_plugins/_performanceanalyzer/cluster/config \
-H 'Content-Type: application/json' -d '{"enabled": true}'設定ファイルとTLS・バインドホスト
詳細設定はconfig/opensearch-performance-analyzer/performance-analyzer.propertiesで行います。外部の監視サーバーから9600へ接続するには、webservice-bind-hostのコメントを外して0.0.0.0を指定します。通信の暗号化（TLS）はhttps-enabled = trueとサーバー証明書のパス指定で有効になりますが、証明書はルート認証局ではなくサーバー用を指定します。認証（クライアント／サーバー）は未対応のため、9600はファイアウォールやセキュリティグループで監視ホストのみに限定するのが安全です。
Docker・コンテナ運用での注意（/dev/shmの64MB問題）
Dockerの/dev/shmは既定で64MBしかなく、Performance Analyzerが必要とする最大1GBに届きません。ここが不足するとメトリクスが空になる典型的な原因になります。起動時にサイズを引き上げてください。
docker run --shm-size 1gb ...非Docker環境ではdf -hで/dev/shmの容量を確認し、不足する場合は/etc/fstabにtmpfsのsizeを追記して再マウントします。
無効化とアンインストール
ローカル検証などでメモリを節約したい場合は、収集を止めてからプラグインを削除します。
curl -XPOST localhost:9200/_plugins/_performanceanalyzer/cluster/config \
-H 'Content-Type: application/json' -d '{"enabled": false}'
bin/opensearch-plugin remove opensearch-performance-analyzerメトリクスの取得とクエリ（ポート9600 API）
メトリクスはポート9600の/_plugins/_performanceanalyzer/metricsから取得します。metrics（指標）・agg（集約）・dim（ディメンション）・nodesを組み合わせて、必要な粒度だけを取り出せます。
GET localhost:9600/_plugins/_performanceanalyzer/metrics?metrics=Latency,CPU_Utilization&agg=avg,max&dim=ShardID&nodes=allこの例は、シャード単位（dim=ShardID）のレイテンシとCPU使用率を、平均と最大（agg=avg,max）で全ノードから取得します。利用できる集約の単位は/_plugins/_performanceanalyzer/metrics/unitsで確認できます。
主要メトリクスとディメンション
実際に指定できる指標名は多岐にわたります。ボトルネック診断でよく使うものを挙げます。
| 分類 | メトリクス名 | 見るポイント |
|---|---|---|
| CPU | CPU_Utilization | ノード／オペレーション別の負荷偏り |
| JVMヒープ | Heap_Used / Heap_Max | 使用率とGC頻度の相関 |
| スレッドプール | ThreadPool_QueueSize / ThreadPool_QueueLatency / ThreadPool_ActiveThreads | 検索・書き込みの滞留と拒否 |
| キャッシュ | Cache_Request_Hit / Cache_Request_Miss / Cache_FieldData_Eviction | ヒット率と追い出しの発生 |
| サーキットブレーカー | CB_TrippedEvents / CB_EstimatedSize | メモリ保護の発動回数 |
| ディスクIO | IO_TotThroughput / IO_ReadThroughput / IO_WriteThroughput | マージやフラッシュ時の飽和 |
| 基本 | Latency / Disk_Utilization / Net_Throughput / ShardEvents | 全体傾向の把握 |
ディメンションはShardIDのほかOperationやIndexNameなどを指定でき、「どのシャード・どの操作が重いか」まで踏み込めます。単なる平均値では埋もれる偏りを、agg=maxとディメンション分割で表面化させるのがPerformance Analyzerの使いどころです。
メトリクスの可視化（PerfTop・Dashboards）
9600のAPIをそのまま叩く以外に、CLIダッシュボードのPerfTopで手軽に表示できます。PerfTopはJSONで行列グリッドを定義し、テーブル・折れ線・棒グラフを配置する仕組みで、既存のJSONを複製して改変するのが早道です。テーブルはディメンション別（例：CPU_Utilization×ShardIDでシャードごとに1行）、棒グラフはクラスタ集約で表示されます。継続的な監視や長期保存が必要なら、9600のメトリクスをPrometheusやGrafanaなど外部の観測基盤へ取り込む構成が現実的です。
性能ボトルネックの切り分け（メトリクス相関の型）
Performance Analyzerは値を出すだけで、原因は運用者が読み解きます。指標を単独で眺めず、症状と結びつけて相関を追うのが実務の要点です。以下は切り分けの型です。
レイテンシ悪化とスレッドプールの滞留
検索が遅いときはLatencyだけでなくThreadPool_QueueSizeとThreadPool_QueueLatencyを同時に見ます。キューが積み上がっているなら、遅いのは個々のクエリではなく処理能力の頭打ちです。ThreadPool_ActiveThreadsが上限に張り付いていれば、ノード追加かクエリの軽量化が先で、単純なヒープ増設では改善しません。拒否（reject）が出ているキューを特定して、そこに負荷を集めている操作をdim=Operationで洗い出します。
JVMヒープとGC
Heap_UsedがHeap_Maxに近い水準で高止まりし、GCが頻発している場合は、集約（aggregation）やフィールドデータの多用がヒープを食っている可能性が高いです。ヒープを増やす前に、重い集約クエリや大きなsizeのスクロールをdimで特定します。ヒープは物理メモリの半分・32GB未満が実務上の目安で、それ以上はGC停止時間が延びて逆効果になりがちです。
キャッシュとサーキットブレーカー
Cache_Request_Hitに対してCache_Request_Missが多く、Cache_FieldData_Evictionが頻発しているなら、キャッシュが小さいか、キャッシュに乗らないクエリ（毎回異なる時刻範囲など）が主因です。CB_TrippedEventsが増えているのはメモリ保護が働いている証拠で、単発のリクエストが大きすぎるサインです。ここを無視してヒープだけ増やすと、より大きなリクエストで再発します。
ディスク・ネットワークIO
書き込みが詰まるときはIO_WriteThroughputとDisk_Utilizationを見ます。インデックスのマージやフラッシュでディスクが飽和しているなら、リフレッシュ間隔の見直しやSSD化が効きます。シャード配置の偏りはdim=ShardIDのCPU・IOで可視化でき、ホットシャードが1ノードに集中しているならリバランスやシャード数の再設計が必要です。
RCA削除とTelemetryプラグインへの移行（3.0以降）
OpenSearch 3.0の破壊的変更として、performance-analyzer-rcaエージェントが削除されました。これはPerformance Analyzerのメトリクスをもとに、性能・信頼性の問題の根本原因を推定していたフレームワークです。公式は代替としてTelemetryプラグインを推奨しています。TelemetryはOpenTelemetryフレームワークを使い、軽量な既存のオープンソースエージェントと連携して、性能メトリクスを観測ストアへ送り出す設計です。
実務上の判断はこうです。9600のメトリクス取得API自体は3.x以降も残るので、生メトリクスを外部基盤へ流す使い方なら移行の緊急度は低い。一方、RCAの自動診断（例：シャードのホットスポット検知）に運用を依存していたなら、その機能はもう存在しないため、OpenTelemetryベースの監視パイプラインへ組み替える必要があります。新規に監視を設計するなら、RCAを前提にせず、最初からTelemetry／OpenTelemetry側で組むのが素直です。
Amazon OpenSearch Service（マネージド）での違い
ここまではセルフマネージド（EC2・コンテナ・オンプレ）でOpenSearchを自分で運用する前提です。マネージドのAmazon OpenSearch Serviceでは、クラスタ指標はCloudWatchへ自動発行され、監視はCloudWatch側で完結する設計になっています。ポート9600のエージェントAPIを自分で叩く運用は基本的に想定されていません。マネージドを使う場合の監視・料金・構築の全体像はAmazon OpenSearch Serviceとは？料金体系・構築手順・運用のポイントにまとめています。
メトリクス取得失敗時のトラブルシュート
- 9600が空・値が出ない：多くはDockerの
/dev/shmが64MBのままで容量不足。--shm-size 1gbで起動し直す。 - 収集が無効：9200の
cluster/configでenabled: trueになっているか確認する。有効化は9200、読み出しは9600と宛先が異なる。 - 外部から9600に届かない：
webservice-bind-hostが0.0.0.0になっているか、ファイアウォール／セキュリティグループが監視ホストを許可しているかを確認する。 - RCAのエンドポイントが404：OpenSearch 3.0でRCAエージェントは削除済み。Telemetry／OpenTelemetryへ切り替える。
よくある質問
Performance Analyzerはデフォルトで有効ですか？
プラグインはOpenSearch 2.0以降のtarball／Docker版に同梱されますが、メトリクス収集の有効化は9200の_plugins/_performanceanalyzer/cluster/configへのenabled: trueで明示的に行います。同梱＝収集が動いている、ではありません。
メトリクス取得はポート9600ですか、9200ですか？
メトリクスの読み出しはポート9600、有効化・無効化のPOSTはOpenSearch本体のポート9200です。宛先が分かれているため、9600でPOSTしても設定は変わりません。
RCA（根本原因分析）はまだ使えますか？
performance-analyzer-rcaエージェントはOpenSearch 3.0で削除されました。公式はTelemetryプラグイン（OpenTelemetry）への移行を推奨しています。生メトリクスを取得するAPIは引き続き使えます。
Amazon OpenSearch Serviceでも使えますか？
マネージドのAmazon OpenSearch Serviceは監視をCloudWatchに寄せる設計で、9600のエージェントAPIを自分で操作する運用は想定されていません。Performance Analyzerを直接使うのはセルフマネージド構成が対象です。
TelemetryプラグインとPerformance Analyzerは何が違いますか？
Performance Analyzerは独自エージェントと9600のRESTでメトリクスを公開する仕組み、TelemetryはOpenTelemetry標準で外部の観測基盤へメトリクスを送る仕組みです。3.0でRCAが消えて以降、根本原因分析まで含む監視はTelemetry側で組むのが公式の方向です。
