Platformオブザーバビリティも、セキュリティも、検索ソリューションも、Elasticsearchプラットフォームならすべて実現できます。Cloudお好みのクラウドプロバイダーでElasticを活用し、必要な答えを見つけられます。panelオブザーバビリティアプリやインフラをまとめて可視化し、問題を先回りして修正できます。ログ監視アプリケーションパフォーマンス監視インフラ監視シンセティック監視リアルユーザー監視ユニバーサルプロファイリングAIOpsOpenTelemetryオブザーバビリティの概要セキュリティサイバー脅威を広範囲で防御、調査し迅速に対応できます。脅威ハンティング調査とインシデントレスポンス脅威保護の自動化セキュリティの概要Searchあらゆるクラウドで迅速に検索結果を示し、パーソナライゼーションも高められます。次に取るべき行動を大規模かつ柔軟、スピーディに見つけられます。panel開発者コード関連のあらゆる情報やフォーラム、グループをご覧ください。コミュニティフォーラムダウンロードつながるテクノロジーやイノベーション、ニュースに関する最新情報をお届けします。イベントブログ学習スキルを磨き、将来の成功につなげましょう。Labsヘルプどのような問題でも、必要なサポートをご提供します。LinkedInrオープンソースのパフォーマンス監視ツールであるstagemonitorのプロジェクトマネージャーとして、優れてはいるものの経年劣化してきたGraphiteの時系列データベース(TSDB)に取って代わるバックエンドのデータベースを模索していました。TSDBとは、アプリの応答時間やサーバーのCPU使用率といった(パフォーマンス)指標データを保存する専用パッケージです。弊社では最終的に、簡単にインストールでき、スケーラブルで、さまざまな機能を備え、指標の視覚化もサポートするデータストアを探すことにしました。Elasticsearchは以前に使ったことがあったため、簡単にインストールでき、スケーラブルで、多くのアグリゲーション機能を備えていることは知っていましたし、Kibanaにすばらしい視覚化ツールがあることも分かっていました。時系列データに向いているかどうかは不明でした。弊社だけではありませんでした。Elasticsearchが勝者に選ばれていました。決定プロセスElasticsearchは、フリーテキスト、システムログ、データベースレコードをはじめとする構造化データや非構造化データを保存、検索、分析する優れたツールです。ひと工夫すれば、collectdやstatsdといったツールから取り込んだ時系列指標を保存する便利なプラットフォームにもなります。指標の増加に応じて手軽に拡張できます。Elasticsearchにはシャードやレプリカを活用した冗長性が組み込まれ、スナップショット&リストア機能で簡単にバックアップできるため、クラスタやデータを容易に管理できます。Elasticsearchはまた、高度なAPI駆動型のため、Logstashのような統合ツールを使用して、膨大なデータを効率的に処理するデータ処理パイプラインも簡単に構築できます。この混合システムにKibanaを追加すれば、複数のデータセットを取り込んで分析し、指標データや他のデータの相関を並べて表示するプラットフォームになります。目立たないのですがメリットはもう1つあります。値を計算した変換後の指標を保存し、表示されたエンドポイント値をグラフ化するのではなく、生の値を保存してから、Elasticsearchに搭載された一連の強力なアグリゲーション機能をこれらの保存済みの値に実行することです。指標を数か月間観察した後に異なる方法で計算または表示したいと思った場合、過去のデータと現在のデータのどちらのデータセットにも当初予定していたものとは違うアグリーション機能を簡単に実行できます。別の言い方をすれば、データを保存した時点では思いもよらなかった疑問が生じても、その答えを見つけることができるのです。Elasticsearchが時系列データベースに適していることはわかりましたが、では実際にどのように設定すればよいのでしょうか。最初のステップ:まず何よりも大切なのがマッピングです。マッピングをあらかじめ定義しておくと、Elasticsearchでのデータの分析や保存が最適化されます。以下は、stagemonitorで行ったマッピングのサンプルです。GitHubレポジトリでご覧いただけます。弊社ではアグリゲーション機能のみを構築しているためで、保存されるドキュメントを小さくしてディスク容量を節約しています。弊社の指標主体のユースケースでは、この点はたいした問題ではありません。ソースの無効化は望ましいことではありません。弊社では指標ドキュメントに対して全文検索を行わないため、文字列値を分析することがありません。host、applicationなどのフィールドに対するtermアグリゲーションの実行に限られるため、特定のホストで指標をフィルタリングするか、すべてのホストのリストを取得すれば用が足りるわけです。ヒープ使用量を少なくするために、できればdoc_valuesを使用することをお勧めします。他にもかなり挑戦的な最適化の手法が2つありますが、このどちらもすべてのユースケースに適しているわけではありません。"no"を使用することです。この設定により、インデックスのサイズは小さくなりますが、同時に値の検索ができなくなります。弊社ではグラフに、2.7182~3.1415の値というサブセットではなく、すべての値を表示するため、この点も問題ありません。最小のnumeric型(弊社の場合はfloat型)を使用すれば、インデックスをさらに最適化できます。各自のケースの要求値がfloat値の範囲外の場合は、double型を使用することが考えられます。長期保存に向けた最適化データを長期保存するための最適化の次の重要なステップは、すべてのデータにインデックス付けした後でインデックスを強制マージすることです(以前は「最適化」と言っていました)。このステップでは、既存のシャードを2~3つにマージして、この同じステップで削除済みのドキュメントを除去します。ご存知かもしれませんが、「最適化」という用語は、Elasticsearchでは誤解を招く可能性があります。このプロセスでは確かにリソースの使用が改善されますが、大量のCPUとディスクリソースを要する場合があります。システムが削除済みのドキュメントをパージした後、すべての根幹的なLuceneセグメントをマージするためです。強制マージをオフピークの時間帯、あるいはCPUやディスクリソースの多いノードで実行するよう推奨するのはこのためです。このマージプロセスはバックグランドで自動的に行われ、データがインデックスに書き込まれる最中にも行われます。操作によってインデックスが変更される可能性がなくなった時点で、このプロセスを明示的にコールするようにしています。最適化は通常、(毎時、毎日、毎週の)最新インデックスの作成後に24~48時間待機して、最後のほうのイベントもElasticsearchに到達できるようにします。一定期間待機した後にCuratorを使用して、最適化コールを簡単に処理できます。flushが自動的に適用されることです。stagemonitorを使用している場合は、最適化プロセスが毎晩自動的にトリガされるため、Curatorを使用する必要もありません。弊社では、上記のプロセスをテストするために、プラットフォームから2300万超の無作為のデータポイントのみをElasticsearchに送信しました。この数はおよそ1週間分のデータ量に匹敵します。以下は、データのサンプルです。2.20}インデックス付けと最適化のサイクルを数回繰り返したところ、次のような数値が示されました。510.9Mこの表からも最適化プロセスがいかに大切かが分かります。Elasticsearchを使用したこのバックグラウンド処理だけでも、長期保存に対して十分に実行する価値があります。これでElasticsearchにすべてのデータが保存されました。次に、このデータからどのようなことが分かるのかを見てみましょう。以下はその答えで、弊社のシステムで生成された図表のサンプルです。Githubリポジトリでコードをご覧いただけます。2.0のさまざまな機能を駆使すれば、時系列データを柔軟に操作して各自に適したものにすることができます。Aggregationを使えば、今まで以上に高度なデータポイントの分析と変換への道が開かれます。Winters法による予測を使ってデータが過去のパターンと一致しているかどうかを確認すること、さらには導関数を計算することなどが考えられます。最後になりますが、前述のマッピングではヒープの効率性を高めるために、doc_valuesを手動で有効にする必要がありました。doc_valuesがデフォルトで有効になっているため、ユーザーの手間が1つ省かれます。Barnsteinerは、オープンソースのパフォーマンス監視プロジェクトであるstagemonitorの開発者です。GmbHでeコマースのソリューション開発に取り組んでいます。B.V.の商標、ロゴ、または登録商標です。Foundationの商標です。