最近、モニタリングの概念を紹介するブログを書きました Elasticsearch LogicMonitorを使用します。 Elasticsearch、特にフルELKスタック（Elasticsearch、 Lオグスタッシュ, KibANA), Amazon Webサービス （AWS）リリース Elasticsearchサービス 2015年後半。Elasticsearchクラスターの管理ではなくデータに重点を置きたい場合は、AmazonのElasticsearchが優れた代替手段です。 ただし、新しいサービスには、ノードレベルのアクセスとAPI機能に関して制限があります。 それでもLogicMonitorの強力な アクティブディスカバリー プロセスでは、これらの制限にもかかわらず、AmazonのElasticsearchを簡単に監視できます。
AWSのサービスに関する主要な目標のXNUMXつは、特定のオファリング（ネットワーキング、ノード、オペレーティングシステム）を構成する多くの内部の複雑さからユーザーを保護し、アプリケーションとのインターフェースに使用できるエンドポイントをユーザーに提供することです。
AWSのElasticsearchの場合、HTTP経由で利用できるのはアプリケーションレベルのAPIのみであり、これには制限があります。 たとえば、多くのAPIエンドポイントは利用できません。特に、シャードの割り当てなど、下位レベルのバックエンドの設定に影響を与えるエンドポイントは利用できません。 これは、サービスがそのような詳細を処理し、ユーザーが自分のデータに集中できるようにするためです。
ElasticsearchのもうXNUMXつの制限は、ノードレベルのアクセスです。 AWS Elasticsearchサービスクラスター（ドメイン）を構成する個々のノードへの直接ネットワーク接続は存在しないため、ノードレベルでのクラスターのモニタリングは困難です。 これは、LogicMonitorのアクティブディスカバリーの美しさです。 手順– / _cat / nodes APIを使用してAWSクラスターのノードを表示すると、次のように表示されます。
ご覧のとおり、ホスト名とIPアドレスは公開されておらず、公開されていても直接アクセスすることはできません。 ただし、Active Discoveryを使用することにより、LogicMonitorは、サーバー上の個々のディスクまたはボリュームを検出する方法と同様に、これらの個々のノードをクラスター内のインスタンスとして検出できます。 また、Elasticsearchがノードに自動的に割り当てるクールなマーベルコミック名を識別子として使用することで、LogicMonitorはこれらのインスタンスを検出し、/ _ nodesAPIを使用してメトリックの収集を開始できます。
/ _cluster / stats APIを介して利用できるクラスターレベルの統計に加えて、ノードレベルでの可視性があり、個々のノードのXNUMXつが、たとえば、ヒープスペースが不足しているか、に多くの時間を費やしているかを判断できます。ガベージコレクション。
AmazonのElasticsearchのもうXNUMXつの優れた機能は、クラスターをオンザフライで再構成できることです。 すでに本番環境にあるクラスターのメモリーが不足している場合は、サービスを中断することなく、より大きなインスタンスを使用するように再構成できます。 この再構成は、新しいインスタンスを透過的にスピンアップし、それらをクラスターに追加し、すべてのインデックスシャードを新しいインスタンスに再配置し、最後に元のインスタンスをクラスターから削除することによって実現されます。
Active Discoveryを使用しているため、このプロセスの動作を確認できます。 以下は、再構成中のクラスターを視覚化した画像です。 最初のXNUMXつのグラフには、個々のノードのヒープとクラスター全体のヒープが表示されます。 個々のノードのグラフの場合、新しいノードがクラスターに参加し、シャードの再配置が発生する正確なポイントを確認できます。 また、データの転送中は両方のノードセットがクラスターのメンバーであるため、クラスターヒープ全体の増加を確認できます。
最後に、以下の画像は、シャード再配置プロセスが完了し、元のノードがクラスターからドロップしたときのヒープドロップを示しています。
これは、LogicMonitor Active Discoveryの能力と、それを利用してアプリケーションレベルで重要な洞察を得る方法を示すもうXNUMXつの例です。
