ログストレージを集中管理する方法

すべての人に挨拶！ 私はOnlantaでシステムエンジニアとして働いています。 私たちのプロジェクトの1つで、Elastic Stackの実装と保守に携わりました。 実質的に手動でログを収集することから、集中化された自動化されたプロセスに移行しました。 2年間、ソリューションのアーキテクチャは実質的に変更されておらず、他のプロジェクトで便利なツールを使用する予定です。 この投稿のいくつかの長所と短所とともに、その実装の歴史を共有します。







出所



2016年の初めには、管理者と開発者のログは、「指先で」、つまりSSHを介して彼が関心を持っているホストに接続して作業するエンジニアであったため、tail / grep / sedからユニバーサルセットを発見しました/ awkそして、必要なデータがこのホストで見つかることを望んでいました。







出所



また、別のサーバーがあり、すべてのサーバーからのログを含むすべてのディレクトリがNFSを介してマウントされ、誰もがそのログで何をしたいのかを考えるのに時間がかかりました。 さて、いくつかのパネルがアクティブに更新されたログに尾を引くtmuxは、大きなモニターの部外者にとって非常に印象的であり、生産の秘跡に関与する刺激的な雰囲気を作り出しました。



これはすべて機能しましたが、正確に大量のデータを迅速に処理することが必要になるまで、これは最も頻繁に何かが製品に落ちた瞬間に必要でした。



場合によっては、事件を調査するのにわずらわしい時間がかかりました。 その大部分は、ログの手動集約、BashおよびPython でのさまざまなスクリプトの松葉杖の起動、ログが分析のためにどこかにアップロードされるのを待つなどに費やされました。



一言で言えば、これはすべて非常に遅く、落胆に触発され、ログの一元化された保存に取り組む時だということを明確に示唆していました。



正直なところ、これを提供する技術スタックの役割の候補を選択する複雑なプロセスはありませんでした。当時ELKバンドルはすでに人気があり、良いドキュメントがあり、すべてのコンポーネントについてインターネット上に多数の記事がありました。 決定は即座に行われました。試してみる必要があります。







出所



スタックの最初のインストールは、それぞれがElasticsearch、Logstash、Kibanaのインスタンスを起動した3つの仮想マシンでウェビナー「Logstash：0-60 in 60」を見てから行われました。



さらに、エンドホストからLogstashサーバーへのログの配信で問題が発生しました。 実際のところ、Filebeat（テキストファイルからログを配信するための標準的なスタックソリューション）は、大きくて迅速に更新されるファイルでは、RAMで定期的にリークし、私たちの場合は全体としてそのタスクに対処できませんでした。



これに加えて、IBM AIXを実行しているマシンからアプリケーションサーバーログを配信する方法を見つける必要性が追加されました。アプリケーションの大部分は、このOSで特に機能するWebSphere Application Serverで実行されました。 FilebeatはGoで作成されており、2016年にはAIX向けの効率的なGoコンパイラはほとんどありませんでした。また、配信用のエージェントとしてLogstashを使用したくありませんでした。



いくつかのログ配信エージェントをテストしました：Filebeat、logstash-forwarder-java、 log-courier 、python-beaver、NXLog。 エージェントからは、高性能、システムリソースの低消費、Logstashとの容易な統合、およびエージェントの力を使用した基本的なデータ操作（複数行イベントのアセンブリなど）を実行できることが期待されました。



複数行のイベントのアセンブリについては、個別に言及する価値があります。 事実上、特定のファイルを読み取るエージェントの側でのみ実行できます。 Logstashにはかつて複数行フィルターがあり、現在は複数行コーデックが使用されていたにもかかわらず、複数のLogstashサーバーでのイベントバランシングと複数行処理を組み合わせようとする試みはすべて失敗しました。 この構成により、効率的なイベントバランシングがほぼ不可能になります。したがって、エージェントを選択する際の最も重要な要素は、複数行のサポートでした。



受賞者は次のように配布されました。Linuxを搭載したマシンのログクーリエ、AIXを搭載したマシンのNXLog。 この構成で、私たちは問題なくほぼ1年間生きました。ログが配信され、エージェントが落ちなかった（まあ、ほとんど）、誰もが幸せでした。



2016年10月に、Beats 5.0を含むElastic Stackコンポーネントの5番目のバージョンがリリースされました。 このバージョンではすべてのBeatsエージェントで多くの作業が行われ、ログクーリエ（当時は独自の問題があった）を、現在使用しているFilebeatに置き換えることができました。



バージョン5.0に切り替えると、ログだけでなく一部のメトリックも収集し始めました：HTTPリクエストログをファイルに書き込む代わりに、Packetbeatが随所で使用されるようになり、Metricbeatはいくつかのサービスのシステムメトリックとメトリックを収集しました。



この時点で、ログを使用したエンジニアの作業ははるかに簡単になりました：関心のあるログを表示するためにどのサーバーに移動するかを知る必要がなくなり、情報の交換はチャットルームまたはメールでKibanaにリンクを転送するだけに簡素化され、以前に作成されたレポート数時間で、数秒で作成され始めました。 これは単に快適さの問題だとは言えません。作業の質、クローズドタスクの量と質、スタンドでの問題への対応速度の変化に気づきました。



ある時点で、YelpのElastAlertユーティリティを使用してアラートをエンジニアに送信し始めました。 そして、我々は考えました：すべてのアラートが標準形式を持ち、一元的に送信されるようにZabbixと統合してみませんか？ 解決策はすぐに見つかりました。ElastAlertでは、実際に使用したアラートを送信する代わりに、任意のコマンドを実行できます。



これで、ElastAlertルールがトリガーされると、bashスクリプトが複数行で実行され、ルールをトリガーしたイベントから引数で必要なデータが渡され、zabbix_senderがスクリプトから呼び出され、目的のノードのデータがZabbixに送信されます。



誰がイベントを生成し、Elasticsearchのどこにいるかに関するすべての情報が常に存在するため、統合に問題は生じませんでした。 たとえば、以前はWASアプリケーションサーバーを自動的に検出するメカニズムがあり、それらが生成するイベントでは、サーバー、クラスター、セルなどの名前が常に書き込まれます。 これにより、ElastAlertルールでquery_keyオプションを使用できるようになり、ルール条件がサーバーごとに個別に処理されるようになりました。 zabbix_senderを使用したスクリプトは、サーバーの正確な「座標」を取得し、対応するノードのデータがZabbixに送信されます。



私たちが本当に気に入っており、ログの集中コレクションのおかげで可能になった別のソリューションは、JIRAでタスクログを自動的に作成するためのスクリプトです。1日1回ログからすべてのエラーを取得し、タスクログがまだない場合はそれらを開始します。 同時に、一意のリクエストIDによる異なるインデックスから、調査に役立つすべての情報がタスクに取り込まれます。 結果は、必要な最小限の情報を備えた一種の標準ワークピースであり、エンジニアは必要に応じて補足することができます。



もちろん、スタック自体を監視するという問題に直面しました。 これは、一部は同じElastAlertを使用して、Zabbixを使用して実装され、スタックに組み込まれた標準監視（X-Packの監視コンポーネント）を使用して、Elasticsearch、Logstash、Kibanaの主要なパフォーマンスメトリックを取得します。 また、スタックサービス自体を備えたサーバーに、Fireholからnetdataをインストールしました。 特定のノードで現在何が起こっているかをリアルタイムで高解像度で確認する必要がある場合に役立ちます。



むかしむかし、Elasticsearchモニタリングモジュールが少し壊れていたため、それを見つけて修正し、あらゆる種類の有用なメトリックを追加してプルリクエストを行いました。 したがって、netdataは、基本的なJVMメトリック、インデックス付け、検索パフォーマンスインジケータ、トランザクションログ統計、インデックスセグメントなどを含むElasticsearchの最新バージョンを監視できるようになりました。 Netdataが気に入っており、Netdataに少し貢献できたことを嬉しく思います。



今日、ほぼ3年後、Elastic Stackは次のようになります。









エンジニアは、主に3つの方法でスタックを操作します。

• Kibanaのログとメトリックの表示と分析。
• GrafanaおよびKibanaのダッシュボード。
• SQLまたは組み込みクエリDSLを使用したElasticsearchへの直接クエリ。

合計で、これらすべてのリソースが割り当てられます：146 CPU、484GB RAM、17TBがElasticsearchデータウェアハウスに割り当てられます。



合計で、Elastic Stackで動作する13台の仮想マシンがあります。「ホット」Elasticsearchノード用に4台、「ウォーム」ノード用に4台、Logstashを備えた4台のマシン、および1台のバランサーマシンです。 各ホットノードで、ElasticsearchはKibanaインスタンスを実行します。 これは最初から起こっており、今のところキバナを別の車に移動する必要はありません。



しかし、スタックの操作中にLogstashを別のマシンに移動させるという決定は、最も正確で効果的なものの1つであることが判明しました.JVM ElasticsearchとLogstashの間のCPU時間の激しい競争は、負荷のバースト中にあまり良い特別な効果をもたらさなかった。 ガベージコレクターが最も被害を受けました。







出所



過去30日間のデータをクラスターに保存します。現在は約120億のイベントです。 ホットノードは毎日、400-500GBのディスクに最大の圧縮率で新しいデータ（シャードレプリカデータを含む）を書き込みます。 Elasticsearchクラスターにはホット/ウォームアーキテクチャがありますが、比較的最近切り替えたため、「ホット」ノードよりも「ウォーム」ノードに保存されるデータが少なくなります。



典型的なワークロード：

• インデックス作成-ピークが30,000までの平均13,000 rps（レプリカ断片へのインデックス作成を除く）。
• 検索-5200 rps。

Elasticsearchホットノードで40〜50％のCPUマージンを維持することで、Kibana / Grafanaまたは外部監視システムからのインデックス付きイベントと大量のリクエストの突然の急増を簡単に経験できるようにします。 Elasticsearchノードを備えたホストのRAMの約50％は、JVMのページキャッシュとオフヒープのニーズに常に利用できます。



最初のクラスターの立ち上げから経過した時間の間に、ログと検索および分析プラットフォームを集約する手段として、Elastic Stackのプラス面とマイナス面のいくつかを自分で特定することができました。



スタックについて特に気に入っていること：

• 互いに十分に統合された製品の単一のエコシステムであり、必要なものはほぼすべて揃っています。 ビートはかつてあまり良くありませんでしたが、今では不満はありません。
• Logstashは、そのすべての極悪非道さを備えており、非常に柔軟で強力なプリプロセッサであり、生データで多くのことができます（そして、それができない場合は、いつでもスニペットをRubyで書くことができます）。
• プラグインを使用したElasticsearchは、クエリ言語としてSQLをサポートします。これにより、他のソフトウェアやクエリ言語としてSQLに近いユーザーとの統合が簡単になります。
• 高品質のドキュメント。新しい従業員を知っているプロジェクトにすばやく紹介できます。 したがって、スタックの操作は、特定の経験と「秘密の知識」を持っている1人のビジネスにはなりません。
• 収集を開始するために取得したデータの構造について事前に知る必要はありません。イベントをそのまま収集し始め、それらから抽出できる有用な情報を理解したら、「後方互換性」を失うことなくそれらを処理する方法を変更します。 このためのスタックには、インデックスのフィールドエイリアス、スクリプトフィールドなど、多くの便利なツールがあります。

出所



嫌いなもの：

• X-Packコンポーネントは、サブスクリプションモデルに従ってのみ配布されます。たとえば、Goldから、RBACまたはPDFレポートのみをサポートする場合は、Goldのすべての料金を支払う必要があります。 これは、たとえば、PlatinumのGraphのみが必要で、Machine Learningと、実際には必要のない他の機能のバンドルが購入できる場合に特にイライラします。 約1年前に個々のX-PackコンポーネントのライセンスについてElasticセールスチームと連絡を取ろうとしても、何も起こりませんでしたが、その後何かが変わった可能性があります。
• かなり頻繁にリリースされ、何らかの形で（毎回新しい）下位互換性が失われます。 変更ログを注意深く読み、事前に更新の準備をする必要があります。 選択するたびに、安定して動作する古いバージョンを使用するか、新しい機能とパフォーマンスの向上のためにアップグレードしてみてください。

一般的に、2016年に行った選択に非常に満足しており、Elastic Stackの操作経験を他のプロジェクトに移行する予定です。スタックによって提供されるツールはワークフローに非常に緊密に統合されており、それらを今すぐ拒否することは非常に困難です。