New Relic Elasticsearch OpenTelemetry (OTel) 統合は、業界標準のOpenTelemetryプロトコルを使用して、 Elasticsearchクラスターの包括的な監視を提供します。 OpenTelemetry Collector活用することで、 Elasticsearchストラクチャからメトリクスとログの両方を効率的に収集する統合パイプラインが得られ、 New Relicと直接統合される高速で信頼性の高い監視が保証されます。
重要
監視アプローチを選択してください:このOpenTelemetryベースの統合は、最新のベンダーニュートラル監視を提供します。 従来のアプローチを好む場合、または特定の互換性が必要な場合は、 標準のElasticsearchを参照してください。
この OpenTelemetry アプローチを選択する理由は何ですか?
- 統合されたデータ収集: シングルコレクターは、 Elasticsearchとホストシステムからのメトリクス、ログ、およびトレースを処理します。
- ベンダー中立性: あらゆる観察プラットフォームで動作するオープンソース標準を使用し、ベンダー ロックインはありません。
- 高パフォーマンス: 組み込みのバッチ処理、圧縮、カーディナリティ削減により、リソースへの影響が最小限に抑えられます。
- 将来性のあるアーキテクチャー: インフラストラクチャの成長に合わせて適応する、進化するオープンスタンダードに基づいて構築されています。
- ネイティブNew Relic : 最適化されたデータ処理とシームレスなダッシュボード エクスペリエンス。
ユースケース: eコマース企業が製品検索機能にElasticsearchを使用しています。この統合を使用することで、運用チームは検索サービスが正常かどうか、検索の応答速度がどれくらいであるかを確認し、メモリがなくなる前に通知を受け取ることができます。これらすべてを 1 つのダッシュボードから行うことができます。 顧客から検索結果の遅さについて苦情が寄せられると、チームはすべての監視データをまとめて確認することで、それが Elasticsearch の問題なのか、サーバーの問題なのか、それとも他の何かなのかをすぐに確認できます。
得られるもの
Elasticsearchを次の方法で監視します。
- Cluster健全性監視: ノードのステータス、シャードの分散、クラスタの状態を追跡します。
- パフォーマンス インサイト: モニター検索レイテンシ、インデックス作成率、およびJVMパフォーマンス メトリクス。
- リソース使用率: すべてのノードの CPU、メモリ、ディスク、ネットワークの使用状況を表示します。
- プロアクティブなアラート : 問題がユーザーに影響を与える前に、インテリジェントな警告値で通知を受け取ります。
- フルスタック相関: Elasticsearchメトリクスとアプリケーションおよびインフラストラクチャデータを接続します。
主要メトリクスの概要
次の重要なメトリクスを使用して、 Elasticsearchクラスタの健全性とパフォーマンスを監視します。
メトリクスカテゴリー | 何を測定しているか | 優先度 |
|---|
クラスタの健全性 | elasticsearch.cluster.health
- クラスター全体のステータス（緑/黄/赤） | 🔴 クリティカル |
シャードステータス | elasticsearch.cluster.shards
- 未割り当て、再配置中、または初期化中のシャード | 🔴 クリティカル |
ノードの可用性 | elasticsearch.cluster.data_nodes
- クラスター内のアクティブなデータノード | 🔴 クリティカル |
JVMヒープ使用量 | jvm.memory.heap.utilization
- メモリ使用率 | 🔴 クリティカル |
検索パフォーマンス | elasticsearch.node.operations.time
- クエリとフェッチのレイテンシ | 🟡 重要 |
インデックス作成のパフォーマンス | elasticsearch.node.operations.time
- インデックスと削除操作のタイミング | 🟡 重要 |
サーキットブレーカー | elasticsearch.breaker.tripped
- メモリ保護が起動 | 🟡 重要 |
リソースの使用 | system.cpu.utilization
、 system.memory.usage
- ホストシステムリソース | 🔵監視 |
完全なメトリクスリファレンス
この統合により、クラスター、ノード、 JVM 、ホストインフラストラクチャ全体で 60 以上のメトリクスが収集されます。 メトリクスの詳細な仕様については、以下のセクションを展開してください。
メトリック | 説明 | 属性 |
|---|
elasticsearch.cluster.in_flight_fetch
| シャード取得操作はまだ実行中です。 | — |
elasticsearch.cluster.nodes
| クラスター ノードの合計数。 | — |
elasticsearch.cluster.pending_tasks
| 実行を待機している保留中のクラスター レベルのタスク。 | — |
elasticsearch.cluster.state_update.time
| クラスターの状態の更新に費やされた累積時間。 | state
（どれでも）
type
(計算、コンテキスト構築、コミット、完了、マスター適用、通知)
|
メトリック | 説明 | 属性 |
|---|
elasticsearch.index.documents
| インデックスごとのドキュメント、状態ごとに分割。 | state
（アクティブ | 削除済み）
aggregation
(primary_shards | 合計)
|
elasticsearch.index.operations.merge.current
| アクティブなセグメントのマージ操作。 | aggregation (primary_shards | 合計) |
elasticsearch.index.operations.time
| インデックス レベルの操作に費やされた時間。 | operation
(インデックス、削除、取得、クエリ、フェッチ、スクロール、提案、マージ、更新、フラッシュ、ウォーマー)
aggregation
(primary_shards | 合計)
|
elasticsearch.indexing_pressure.memory.total.primary_rejections
| 一次段階のインデックス拒否の累計数。 | — |
メトリック | 説明 | 属性 |
|---|
elasticsearch.node.cache.count
| ノード シャード全体のクエリ キャッシュのヒットとミス。 | type （ヒット｜ミス） |
elasticsearch.node.cache.evictions
| ノード キャッシュの削除。 | cache_name (フィールドデータ | クエリ) |
elasticsearch.node.cache.memory.usage
| キャッシュメモリの使用量（バイト単位）。 | cache_name (フィールドデータ | クエリ) |
elasticsearch.node.cluster.io
| 内部クラスター ネットワーク I/O (バイト単位)。 | direction （受信｜送信） |
elasticsearch.node.documents
| ノードによってホストされるドキュメント。 | state （アクティブ | 削除済み） |
elasticsearch.node.disk.io.read
| ファイル ストア全体のディスク読み取りスループット (KiB)。 | — |
elasticsearch.node.disk.io.write
| ファイル ストア全体のディスク書き込みスループット (KiB)。 | — |
elasticsearch.node.fs.disk.available
| JVM で使用可能なディスク。 | — |
elasticsearch.node.fs.disk.total
| ノード上のディスク容量の合計。 | — |
elasticsearch.node.http.connections
| ノードによって提供される HTTP 接続。 | — |
elasticsearch.node.ingest.documents.current
| 現在取り込まれているドキュメント。 | — |
elasticsearch.node.ingest.operations.failed
| 累積的な取り込み失敗数。 | — |
elasticsearch.node.open_files
| 使用中のオープンファイル記述子。 | — |
elasticsearch.node.operations.completed
| ノードによって完了した操作。 | operation (インデックス、削除、取得、クエリ、フェッチ、スクロール、提案、マージ、更新、フラッシュ、ウォーマー) |
elasticsearch.node.operations.current
| 現在操作が進行中です。 | operation （同じセット） |
elasticsearch.node.operations.get.completed
| GET はヒットとミスを生みます。 | result （ヒット｜ミス） |
elasticsearch.node.operations.get.time
| GET ヒット/ミスの処理に費やされた時間。 | result （ヒット｜ミス） |
elasticsearch.node.shards.reserved.size
| 回復によるシャードの増加を予測します。 | — |
elasticsearch.node.thread_pool.tasks.finished
| スレッド プールごとに完了した (または拒否された) タスク。 | thread_pool_name
（どれでも）
state
(拒否 | 完了)
|
メトリック | 説明 | 属性 |
|---|
elasticsearch.os.cpu.load_avg.1m
| 1 分間の OS 負荷平均。 | — |
elasticsearch.os.cpu.load_avg.5m
| 5 分間の OS 負荷平均。 | — |
elasticsearch.os.cpu.load_avg.15m
| 15 分間の OS 負荷平均。 | — |
elasticsearch.os.memory
| Elasticsearch から見た物理メモリの使用量。 | state （無料｜中古） |
jvm.gc.collections.count
| ガベージコレクションの合計実行回数。 | name （コレクター名） |
jvm.gc.collections.elapsed
| ガベージコレクションに費やされた時間。 | name （コレクター名） |
jvm.memory.heap.max
| 使用可能な最大ヒープ メモリ。 | — |
jvm.memory.heap.used
| 現在使用中のヒープメモリ。 | — |
jvm.threads.count
| アクティブな JVM スレッド数。 | — |
メトリック | 説明 | 属性 |
|---|
system.cpu.time
| 状態ごとに分割された累積 CPU 時間。 | cpu
（論理CPU）
state
(上記と同じセット)
|
system.cpu.load_average.1m
| 1 分間のシステム負荷平均。 | — |
system.cpu.load_average.5m
| 5 分間のシステム負荷平均。 | — |
system.cpu.load_average.15m
| 15 分間のシステム負荷平均。 | — |
system.memory.utilization
| メモリ使用率。 | state （使用済み） |
system.disk.io
| デバイスあたりのディスク I/O スループット。 | device
（ディスク）
direction
(読み取り | 書き込み)
|
system.disk.operations
| デバイスごとのディスク操作。 | device
direction
(読み取り | 書き込み)
|
system.filesystem.usage
| 状態別のファイルシステム容量。 | device
state
(使用済み | 空き | 予約済み)
|
system.filesystem.utilization
| ファイルシステムの使用率。 | device
state
(使用済み)
|
system.network.io
| インターフェースあたりのネットワーク バイト。 | interface
direction
(受信 | 送信)
|
system.network.packets
| インターフェースごとのネットワーク パケット。 | interface
direction
(受信 | 送信)
|
process.cpu.utilization
| 最後のスクレイプ以降にプロセスによって使用された合計 CPU 時間の割合。0 から 1 までの値で表されます。 | process.pid
（PID）
process.executable.name
(バイナリ名)
process.owner
(ユーザー)
state
(ユーザー | システム | その他)
|
データの整理方法
Elasticsearch メトリクスが New Relic に送信されると、データの整理とフィルタリングに役立つ識別情報が含まれます。このメタデータは、すべてのメトリクスにクラスタ情報を自動的にタグ付けします。
タグ | それが何を特定するか |
|---|
elasticsearch.cluster.name
| Elasticsearchの一意の名前 |
このクラスター名タグを使用すると、次のことが可能になります。
- 複数のElasticsearch環境がある場合は、クラスタでメトリクスをフィルタリングします。
- 運用、ステージング、開発用のクラスター固有のダッシュボードを作成します。
- 個々のクラスターに対してターゲットを絞ったアラートを設定します。
- 同じクラスター識別子を使用して、さまざまな監視ツール間でデータを相関させます。
次のステップ
メトリクスを確認し、この統合が提供するものを理解した後:
- インテグレーションをインストールします- ステップバイステップのセットアップ ガイドに従ってください。
- アラートのセットアップ- クラスターの健全性やヒープ使用量などの重要なメトリクスのプロアクティブな監視を構成します。
- カスタムダッシュボードの作成- 特定のElasticsearchユースケースに合わせたビューを構築します。
- 関連するインテグレーションを探索する - 他のOpenTelemetry インテグレーションを使用してアプリケーション スタックを監視することを検討してください。