1.パフォーマンス分析
2.ログ収集の選択：logstash /フィルター
3. Logstash最適化関連の構成
4. Redisの導入に関連する問題
5. Elasticsearchノードの最適化された構成
6.パフォーマンスチェック
1.パフォーマンス分析
サーバーハードウェアLinux：**** 1cpu4GRAM
各ログが250Byteであると想定します。
分析：
①logstash-Linux：1cpu 4GRAM
- 1秒あたり500ログ。
- 1秒あたりのルビー660ログを削除します。
- grokを削除した後、1秒あたり1000データ。
②filebeat-Linux：1cpu 4GRAM
- 1秒あたり2500〜3500データ。
- 各マシンは毎日処理できます：24時間60分60秒* 3000 * 250バイト= 64,800,000,000バイト、約64G。
③ボトルネックはRedisからLogstashでデータをフェッチしてESに保存し、Logstashを開いて1秒あたり約6000データを処理します。2つのLogstashを開いて1秒あたり約10,000データを処理します（CPUは基本的に実行されています）
④スクリプトでjava、rubyなどの環境変数をチェックするため、logstashの起動処理は多くのシステムリソースを消費し、起動後はリソース占有率が通常の状態に戻ります。
2.ログ収集の選択：**** logstash /フィルター
filebeatまたはlogstashの使用を要求する原則はありません。どちらも配送業者と同じ機能を持っています。
違いは次のとおりです。
- logstashはgrokやrubyなどの多くのプラグインを統合しているため、beatに比べて重いです。
- Logstashは起動後により多くのリソースを消費します。ハードウェアリソースが十分である場合、2つの間の違いを考慮する必要はありません。
- logstashはJVMに基づいており、クロスプラットフォームをサポートしていますが、beatはgolangで書かれていますが、AIXはサポートしていません。
- AIX 64ビットプラットフォームはjdk（jre）1.7 32ビットをインストールする必要があります。64ビットはサポートされていません。
- FilebeatはESに直接入力できますが、システムにlogstashがESに直接入力される状況があるため、さまざまなインデックスタイプが原因で複雑な検索が発生します。elsのソースに均一に入力することをお勧めします。
要約：
要約すると、logstash /フィルターには独自の利点がありますが、選択することをお勧めします：軽量であり、ログの収集に使用されるため、収集する必要がある各ログサーバーでfilebeatを構成し、logstashに統合して出力し、ログ処理を実行し、最後にlogstashで出力しますESを与える。
3. Logstash最適化関連の構成
最適化できるパラメーターは、ご使用のハードウェアに応じて最適化できます。
①パイプラインスレッドの数、公式の推奨はCPUコアの数と同じです
- デフォルトの構成---> pipeline.workers：2;
- ---> pipeline.workersとして最適化できます：CPUコア数（またはCPUコア数の数倍）。
②実際の出力のスレッド数
- デフォルトの構成---> pipeline.output.workers：1;
- ---> pipeline.output.workersに最適化できます：パイプラインスレッドにすぎません。
③毎回送信されるイベント数
- デフォルトの構成---> pipeline.batch.size：125;
- ---> pipeline.batch.size：1000に最適化できます。
④送信遅延
- デフォルトの構成---> pipeline.batch.delay：5;
- ---> pipeline.batch.size：10.に最適化できます。
要約：
- -wパラメーターを設定してパイプラインワーカーの数を指定することにより、構成ファイルlogstash.ymlを直接変更することもできます。これにより、フィルターと出力スレッドの数が増加します。必要に応じて、CPUコア数の数倍に設定しても安全です。スレッドはI / Oでアイドル状態です。
- デフォルトでは、各出力はパイプラインワーカースレッドでアクティブです。出力出力でワーカー設定を設定できます。この値は、パイプラインワーカーの数より大きくしないでください。
- また、出力のbatch_size数を設定することもできます。たとえば、ES出力はバッチサイズと一致します。
- フィルターをマルチラインに設定すると、piplineワーカーは自動的に1になります。filebeatを使用する場合は、マルチラインビートを使用することをお勧めします。logstashを配送業者として使用する場合は、マルチラインフィルターではなくマルチラインを入力に設定することをお勧めします。
LogstashのJVM構成ファイル：
Logstashは、JVMで実行する必要があるJavaベースのプログラムであり、jvm.optionsを構成することにより、JVMに設定できます。たとえば、最大メモリと最小メモリ、ガベージクリーニングメカニズムなどです。JVMのメモリ割り当ては、大きすぎても小さすぎてもいけません。大きすぎると、オペレーティングシステムの速度が低下します。開始するには小さすぎます。デフォルトは次のとおりです。
- Xms256m＃最小使用メモリ。
- Xmx1g＃メモリの最大使用。
4. Redisの導入に関連する問題
Filebeatはlogstash（インデクサー）に直接入力できますが、logstashにはストレージ機能がありません。再起動する必要がある場合は、最初に接続されているすべてのビートを停止してからlogstashを停止する必要があるため、操作とメンテナンスに問題が発生します。また、logstashが異常な場合、データが失われます。Redisを導入データバッファープール。logstashが異常停止すると、RedisクライアントからRedisにキャッシュされたデータを確認できます。
Redisはリスト（最大4,294,967,295をサポート）またはパブリッシュおよびサブスクライブストレージモードを使用できます。
RedisはELKバッファーキューを最適化します。
-
bind 0.0.0.0＃ローカルポートをリッスンしません。
-
requirepass ilinux.io＃安全な操作のためにパスワードを追加します。
-
永続ストレージを必要とせずにキューのみを実行し、すべての永続機能をオフにします。
スナップショット（RDBファイル）と追加ファイル（AOFファイル）。パフォーマンスが向上します。
保存 ""スナップショットを無効にします。
appendonly no RDBをオフにします。
-
メモリ消去戦略をオフにして、メモリ空間を最大化します。
maxmemory 0 #maxmemoryは0であり、Redisのメモリ使用量に制限がないことを示しています。
5. Elasticsearchノードの最適化された構成
サーバーのハードウェア構成、OSパラメータ：
1）/etc/sysctl.conf構成
# vim /etc/sysctl.confvm.swappiness = 1 #ES 推荐将此参数设置为 1，大幅降低 swap 分区的大小，强制最大程度的使用内存，注意，这里不要设置为 0, 这会很可能会造成 OOMnet.core.somaxconn = 65535 #定义了每个端口最大的监听队列的长度vm.max_map_count= 262144 #限制一个进程可以拥有的VMA(虚拟内存区域)的数量。虚拟内存区域是一个连续的虚拟地址空间区域。当VMA 的数量超过这个值，OOMfs.file-max = 518144 #设置 Linux 内核分配的文件句柄的最大数量# sysctl -p #生效一下
2）Limits.conf構成
# vim /etc/security/limits.confelasticsearch soft nofile 65535elasticsearch hard nofile 65535elasticsearch soft memlock unlimitedelasticsearch hard memlock unlimited
3）上記のパラメータを永続的に有効にするために、2つの場所を設定する必要があります。
# vim /etc/pam.d/common-session-noninteractive# vim /etc/pam.d/common-session
以下の属性を追加します。
セッションにはpam_limits.soが必要
再起動後に有効になる場合があります。
ElasticsearchのJVM構成ファイル：
-Xms2g
-Xmx2g
- 最小ヒープサイズ（Xms）と最大ヒープサイズ（Xmx）を互いに等しく設定します。
- Elasticsearchで使用できるヒープが多いほど、キャッシュに使用できるメモリが多くなります。ただし、ヒープが多すぎると、ガベージコレクションが長時間停止する可能性があることに注意してください。
- Xmxを物理RAMの50％以下に設定して、カーネルファイルシステムキャッシュ用に十分な物理メモリが確保されるようにします。
- JVMがオブジェクトポインターを圧縮するために使用する重要な値を超えてXmxを設定しないでください。正確なカットオフ値は異なりますが、32 GBに近くなります。32Gを超えないようにしてください。スペースが大きい場合は、インスタンスをいくつか実行して、1つのインスタンスのメモリが多すぎないようにしてください。
Elasticsearch構成ファイルの最適化パラメーター：
1）メイン構成ファイル
# vim elasticsearch.ymlbootstrap.memory_lock: true #锁住内存，不使用swap#缓存、线程等优化如下bootstrap.mlockall: truetransport.tcp.compress: trueindices.fielddata.cache.size: 40%indices.cache.filter.size: 30%indices.cache.filter.terms.size: 1024mbthreadpool: search: type: cached size: 100 queue_size: 2000
2）環境変数を設定する
# vim /etc/profile.d/elasticsearch.sh export ES_HE AP _SIZE=2g #Heap Size不超过物理内存的一半，且小于32G。
クラスターの最適化（私はクラスターを使用しませんでした）：
- ESは分散ストレージであり、同じcluster.nameが設定されると、自動的に検出され、クラスターに参加します。
- クラスタは自動的にマスターを選出し、マスターがダウンすると再選します。
- 「脳分裂」を防ぐために、クラスター内の数は奇数であることが好ましい。
- ノードを効果的に管理するには、ブロードキャスト検出をオフにします。Zen.ping.multicast.enabled：false、ユニキャストノードグループdiscovery.zen.ping.unicast.hosts：["ip1"、 "ip2"、 "ip3"]を設定します。
6.パフォーマンスチェック
入力と出力のパフォーマンスを確認します。
Logstashとそれに接続されているサービスは同じ速度で実行され、入力と出力と同じくらい高速にすることができます。
システムパラメータを確認します。
1）CPU
- CPUが過負荷になっていないかどうかを確認します。Linux / Unixシステムでは、top-Hを使用してプロセスパラメータと合計を表示できます。
- CPU使用率が高すぎる場合は、JVMヒープの確認に関する章に直接スキップして、Logstashワーカーの設定を確認してください。
2）メモリ
- LogstashはJava仮想マシンで実行されるため、割り当てた最大メモリのみを使用することに注意してください。
- 他のアプリケーションが大量のメモリを使用していることを確認します。これにより、Logstashがハードディスクスワップを使用するようになります。この状況は、アプリケーションが占有するメモリが物理メモリの範囲を超えた場合に発生します。
3）I / OモニタリングディスクI / Oチェックディスクの飽和
- Logstashプラグインを使用すると（たとえば、ファイル出力を使用して）、ディスクが飽和します。
- 多数のエラーが発生すると、Logstashが多数のエラーログを生成すると、ディスクも飽和状態になります。
- Linuxでは、iostat、dstat、またはその他のコマンドを使用してディスクI / Oを監視できます。
4）ネットワークI / Oを監視する
- ネットワーク操作に多くの入出力を使用すると、ネットワークが飽和します。
- Linuxのネットワーク状態を監視するには、dstatまたはiftopを使用できます。
JVMヒープを確認します。
- ヒープ設定が小さすぎると、CPU使用率が高くなりすぎます。これは、JVMのガベージコレクションメカニズムが原因です。
- この設定を確認する簡単な方法は、ヒープをサイズの2倍に設定してから、パフォーマンスの向上を検出することです。ヒープを物理メモリサイズを超えないように設定し、オペレーティングシステムや他のプロセス用に少なくとも1Gのメモリを予約してください。
- jmapやVisualVMなどのコマンドラインを使用して、JVMヒープをより正確に計算できます。