ELKの原理と紹介

ELK を使用する理由:

一般に、必要な情報を取得するには、ログ ファイル内で直接 grep と awk を実行するログ分析シナリオを実行する必要があります。ただし、大規模なシナリオでは、この方法は非効率的であり、ログのボリュームが大きすぎる場合にアーカイブする方法、テキスト検索が遅すぎる場合にどうするか、複数の次元でクエリを実行する方法などの問題に直面します。集中的なログ管理が必要であり、すべてのサーバーでログを収集および要約する必要があります。一般的な解決策は、すべてのノード上のログを統一された方法で収集、管理、アクセスするための集中ログ収集システムを確立することです。

一般に、大規模システムは分散配置アーキテクチャを採用しており、異なるサービスモジュールが異なるサーバに配置されているため、問題が発生した場合、ほとんどの場合、システムから公開されるキー情報を基に、特定のサーバおよびサービスモジュールを特定する必要があります。ログ システムを使用すると、問題を特定する効率が向上します。

完全な集中ログ システムには、次の主な機能が含まれている必要があります。

• 収集 - 複数のソースからログ データを収集できます
• 送信 - ログデータを中央システムに安定して送信可能
• ストレージ - ログデータの保存方法
• 分析 - UI分析をサポートできます
• 警告 - エラー報告、監視メカニズムを提供できます。

ELK は完全なソリューション セットを提供しており、それらはすべてオープン ソース ソフトウェアであり、相互に連携して使用され、完全に接続され、多くのアプリケーションのニーズを効率的に満たします。現在主流のロギングシステム。

ELK の紹介:

ELKとは、Elasticsearch、Logstash、Kibanaを表す3つのオープンソースソフトウェアの略称であり、いずれもオープンソースソフトウェアです。新しい FileBeat が追加されました。これは、軽量のログ収集および処理ツール (エージェント) です。Filebeat は、リソースの使用量が少なく、さまざまなサーバー上のログを収集し、Logstash に送信するのに適しています。このツールは公式にも推奨されています。

Elasticsearch は、データの収集、分析、保存という 3 つの主要な機能を提供するオープンソースの分散型検索エンジンです。その機能には、分散型、ゼロ構成、自動検出、自動インデックス シャーディング、インデックス コピー メカニズム、Restful スタイル インターフェイス、複数のデータ ソース、自動検索ロードなどが含まれます。

Logstash は主にログの収集、分析、フィルタリングを行うためのツールであり、多数のデータ取得方法をサポートしています。一般的な作業方法は c/s アーキテクチャです。クライアントは、ログを収集する必要があるホストにインストールされます。サーバーは、各ノードで受信したログをフィルタリングおよび変更し、まとめて elasticsearch に送信します。

Kibana はオープン ソースの無料ツールでもあり、重要なデータ ログの要約、分析、検索に役立つ Logstash および ElasticSearch 用のログ分析に適した Web インターフェイスを提供します。

Filebeat は Beats の一部です。現在、Beats には 4 つのツールが含まれています。

1. 公式ドキュメント:

   ファイルビート：

   https://www.elastic.co/cn/products/beats/filebeat
   https://www.elastic.co/guide/en/beats/filebeat/5.6/index.html

   Logstash：
   https://www.elastic.co/cn/products/logstash
   https://www.elastic.co/guide/en/logstash/5.6/index.html

   木場：

   https://www.elastic.co/cn/products/kibana

   https://www.elastic.co/guide/en/kibana/5.5/index.html

   Elasticsearch：
   https://www.elastic.co/cn/products/elasticsearch
   https://www.elastic.co/guide/en/elasticsearch/reference/5.6/index.html

   elasticsearch 中国語コミュニティ:
   https://elasticsearch.cn/

    

   ELK アーキテクチャ図:

   アーキテクチャ図 1:

    

   これは最も単純な ELK アーキテクチャです。利点は、セットアップが簡単で使いやすいことです。欠点は、Logstash が大量のリソースを消費し、実行に多くの CPU とメモリを消費することです。さらに、メッセージ キュー キャッシュがないため、データ損失のリスクがあります。

   このアーキテクチャでは、Logstash が各ノードに分散されて関連するログとデータが収集され、分析とフィルタリングの後、リモート サーバー上の Elasticsearch に送信されて保存されます。Elasticsearch はデータをシャードの形式で圧縮して保存し、ユーザーがクエリや操作を行うためのさまざまな API を提供します。また、ユーザーは Kibana Web をより直感的に構成して、ログを簡単にクエリし、データに基づいてレポートを生成することもできます。

   アーキテクチャ図 2:

    

   このアーキテクチャでは、メッセージ キュー メカニズムが導入されています。各ノードにある Logstash エージェントは、まずデータ/ログを Kafka (または Redis) に転送し、キュー内のメッセージまたはデータを間接的に Logstash に転送します。Logstash はデータをフィルタリングして分析し、その後、データを Elasticsearch ストレージに保存します。最後に、Kibana はログとデータをユーザーに提示します。Kafka (または Redis) の導入により、リモート Logstash サーバーが障害により実行を停止した場合でも、データの損失を避けるためにデータが最初に保存されます。

   アーキテクチャ図 3:

    

   このアーキテクチャは、コレクション側の logstash を Beat に置き換えます。これは、柔軟性が高く、リソースの消費が少なく、スケーラビリティが優れています。同時に、Logstash および Elasticsearch クラスターは、大規模クラスター システムの運用およびメンテナンスのログ データの監視とクエリをサポートするように構成できます。

   Filebeat の仕組み:

   Filebeat は、プロスペクトとハーベスターという 2 つの主要コンポーネントで構成されます。これら 2 つのコンポーネントは連携して、ファイルの変更を指定された出力に送信します。

    

   Harvester:単一ファイルの内容を読み取る役割を果たします。各ファイルはハーベスタを起動し、各ハーベスタは各ファイルを 1 行ずつ読み取り、ファイルの内容を指定された出力に送信します。Harvester はファイルのオープンとクローズを担当します。つまり、Harvester の実行中、ファイル記述子は開いています。収集中にファイルの名前が変更または削除された場合でも、Filebeat はファイルの読み取りを継続します。したがって、Harvester がシャットダウンされるまでディスクは解放されません。デフォルトでは、filebeat は、ファイルが到達するまでファイルを開いたままにしますclose_inactive(このオプションがオンになっている場合、filebeat は、ハーベスタが最後の行を読み取った時点から開始して、指定された時間内に更新されなくなったファイル ハンドルを閉じます)。ハンドルが閉じられます ファイルが変更された後、新しいハーベスタが開始されます。ファイル ハンドルを閉じるまでの時間は、ファイルの変更時間には依存しません。このパラメータが適切に構成されていない場合、ログはリアルタイムではない可能性があります。 scan_frequency パラメータによって決定され、デフォルトは 10 秒です。ハーベスタは内部タイムスタンプを使用して、ファイルが最後に収集された時刻を記録します。たとえば、5 分に設定すると、ハーベスタはファイルの最後の行を読み取った後、カウントダウンを開始します。 5 分間。5 分以内にファイルに変更がない場合、ファイル ハンドルは閉じられます。デフォルトは 5 分です。)。

   プロスペクター: Harvester の管理とすべての読書ソースの検索を担当します。

   ELK を使用する理由: 一般に、必要な情報を取得するには、ログ ファイル内で直接 grep と awk を実行するログ分析シナリオを実行する必要があります。ただし、大規模なシナリオでは、この方法は非効率的であり、ログのボリュームが大きすぎる場合にアーカイブする方法、テキスト検索が遅すぎる場合にどうするか、複数の次元でクエリを実行する方法などの問題に直面します。集中的なログ管理が必要であり、すべてのサーバーでログを収集および要約する必要があります。一般的な解決策は、すべてのノード上のログを統一された方法で収集、管理、アクセスするための集中ログ収集システムを確立することです。 一般に、大規模システムは分散配置アーキテクチャを採用しており、異なるサービスモジュールが異なるサーバに配置されているため、問題が発生した場合、ほとんどの場合、システムから公開されるキー情報を基に、特定のサーバおよびサービスモジュールを特定する必要があります。ログ システムを使用すると、問題を特定する効率が向上します。 完全な集中ログ システムには、次の主な機能が含まれている必要があります。 収集 - 複数のソースからログ データを収集できます 送信 - ログ データを中央システム ストレージに安定して送信できます - ログ データの保存方法分析 - UI 分析と警告をサポートできます - エラー レポートと監視メカニズムを提供できます ELK は完全なソリューション セットを提供しており、それらはすべてオープン ソース ソフトウェアであり、相互に連携して使用され、完全に接続され、多くのアプリケーションのニーズを効率的に満たします。現在主流のロギングシステム。 ELK の紹介: ELKとは、Elasticsearch、Logstash、Kibanaを表す3つのオープンソースソフトウェアの略称であり、いずれもオープンソースソフトウェアです。新しい FileBeat が追加されました。これは、軽量のログ収集および処理ツール (エージェント) です。Filebeat は、リソースの使用量が少なく、さまざまなサーバー上のログを収集し、Logstash に送信するのに適しています。このツールは公式にも推奨されています。 Elasticsearch は、データの収集、分析、保存という 3 つの主要な機能を提供するオープンソースの分散型検索エンジンです。その機能には、分散型、ゼロ構成、自動検出、自動インデックス シャーディング、インデックス コピー メカニズム、Restful スタイル インターフェイス、複数のデータ ソース、自動検索ロードなどが含まれます。 Logstash は主にログの収集、分析、フィルタリングを行うためのツールであり、多数のデータ取得方法をサポートしています。一般的な作業方法は c/s アーキテクチャです。クライアントは、ログを収集する必要があるホストにインストールされます。サーバーは、各ノードで受信したログをフィルタリングおよび変更し、まとめて elasticsearch に送信します。 Kibana はオープン ソースの無料ツールでもあり、重要なデータ ログの要約、分析、検索に役立つ Logstash および ElasticSearch 用のログ分析に適した Web インターフェイスを提供します。 Filebeat は Beats の一部です。現在、Beats には 4 つのツールが含まれています。 公式ドキュメント: ファイルビート： https://www.elastic.co/cn/products/beats/filebeat https://www.elastic.co/guide/en/beats/filebeat/5.6/index.html Logstash： https://www.elastic.co/cn/products/logstash https://www.elastic.co/guide/en/logstash/5.6/index.html 木場： https://www.elastic.co/cn/products/kibana https://www.elastic.co/guide/en/kibana/5.5/index.html Elasticsearch： https://www.elastic.co/cn/products/elasticsearch https://www.elastic.co/guide/en/elasticsearch/reference/5.6/index.html elasticsearch 中国語コミュニティ: https://elasticsearch.cn/   ELK アーキテクチャ図: アーキテクチャ図 1:   これは最も単純な ELK アーキテクチャです。利点は、セットアップが簡単で使いやすいことです。欠点は、Logstash が大量のリソースを消費し、実行に多くの CPU とメモリを消費することです。さらに、メッセージ キュー キャッシュがないため、データ損失のリスクがあります。 このアーキテクチャでは、Logstash が各ノードに分散されて関連するログとデータが収集され、分析とフィルタリングの後、リモート サーバー上の Elasticsearch に送信されて保存されます。Elasticsearch はデータをシャードの形式で圧縮して保存し、ユーザーがクエリや操作を行うためのさまざまな API を提供します。また、ユーザーは Kibana Web をより直感的に構成して、ログを簡単にクエリし、データに基づいてレポートを生成することもできます。 アーキテクチャ図 2:   此种架构引入了消息队列机制，位于各个节点上的Logstash Agent先将数据/日志传递给Kafka（或者Redis），并将队列中消息或数据间接传递给Logstash，Logstash过滤、分析后将数据传递给Elasticsearch存储。最后由Kibana将日志和数据呈现给用户。因为引入了Kafka（或者Redis）,所以即使远端Logstash server因故障停止运行，数据将会先被存储下来，从而避免数据丢失。 架构图三：   此种架构将收集端logstash替换为beats，更灵活，消耗资源更少，扩展性更强。同时可配置Logstash 和Elasticsearch 集群用于支持大集群系统的运维日志数据监控和查询。 Filebeat工作原理： Filebeat由两个主要组件组成：prospectors 和 harvesters。这两个组件协同工作将文件变动发送到指定的输出中。   Harvester（收割机）：负责读取单个文件内容。每个文件会启动一个Harvester，每个Harvester会逐行读取各个文件，并将文件内容发送到制定输出中。Harvester负责打开和关闭文件，意味在Harvester运行的时候，文件描述符处于打开状态，如果文件在收集中被重命名或者被删除，Filebeat会继续读取此文件。所以在Harvester关闭之前，磁盘不会被释放。默认情况filebeat会保持文件打开的状态，直到达到close_inactive（如果此选项开启，filebeat会在指定时间内将不再更新的文件句柄关闭，时间从harvester读取最后一行的时间开始计时。若文件句柄被关闭后，文件发生变化，则会启动一个新的harvester。关闭文件句柄的时间不取决于文件的修改时间，若此参数配置不当，则可能发生日志不实时的情况，由scan_frequency参数决定，默认10s。Harvester使用内部时间戳来记录文件最后被收集的时间。例如：设置5m，则在Harvester读取文件的最后一行之后，开始倒计时5分钟，若5分钟内文件无变化，则关闭文件句柄。默认5m）。 Prospector（勘测者）：负责管理Harvester并找到所有读取源。 filebeat.prospectors: - input_type: log paths: - /apps/logs/*/info.log Prospector会找到/apps/logs/*目录下的所有info.log文件，并为每个文件启动一个Harvester。Prospector会检查每个文件，看Harvester是否已经启动，是否需要启动，或者文件是否可以忽略。若Harvester关闭，只有在文件大小发生变化的时候Prospector才会执行检查。只能检测本地的文件。 Filebeat如何记录文件状态： 将文件状态记录在文件中（默认在/var/lib/filebeat/registry）。此状态可以记住Harvester收集文件的偏移量。若连接不上输出设备，如ES等，filebeat会记录发送前的最后一行，并再可以连接的时候继续发送。Filebeat在运行的时候，Prospector状态会被记录在内存中。Filebeat重启的时候，利用registry记录的状态来进行重建，用来还原到重启之前的状态。每个Prospector会为每个找到的文件记录一个状态，对于每个文件，Filebeat存储唯一标识符以检测文件是否先前被收集。 Filebeat如何保证事件至少被输出一次： Filebeat之所以能保证事件至少被传递到配置的输出一次，没有数据丢失，是因为filebeat将每个事件的传递状态保存在文件中。在未得到输出方确认时，filebeat会尝试一直发送，直到得到回应。若filebeat在传输过程中被关闭，则不会再关闭之前确认所有时事件。任何在filebeat关闭之前为确认的时间，都会在filebeat重启之后重新发送。这可确保至少发送一次，但有可能会重复。可通过设置shutdown_timeout 参数来设置关闭之前的等待事件回应的时间（默认禁用）。   Logstash工作原理： Logstash事件处理有三个阶段：inputs → filters → outputs。是一个接收，处理，转发日志的工具。支持系统日志，webserver日志，错误日志，应用日志，总之包括所有可以抛出来的日志类型。     Input：输入数据到logstash。 一些常用的输入为： file：从文件系统的文件中读取，类似于tial -f命令 syslog：在514端口上监听系统日志消息，并根据RFC3164标准进行解析 redis：从redis service中读取 beats：从filebeat中读取 Filters：数据中间处理，对数据进行操作。 一些常用的过滤器为： grok：解析任意文本数据，Grok 是 Logstash 最重要的插件。它的主要作用就是将文本格式的字符串，转换成为具体的结构化的数据，配合正则表达式使用。内置120多个解析语法。 官方提供的grok表达式：https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns grok在线调试：https://grokdebug.herokuapp.com/ mutate：对字段进行转换。例如对字段进行删除、替换、修改、重命名等。 drop：丢弃一部分events不进行处理。 clone：拷贝 event，这个过程中也可以添加或移除字段。 geoip：添加地理信息(为前台kibana图形化展示使用) Outputs：outputs是logstash处理管道的最末端组件。一个event可以在处理过程中经过多重输出，但是一旦所有的outputs都执行结束，这个event也就完成生命周期。 一些常见的outputs为： elasticsearch：可以高效的保存数据，并且能够方便和简单的进行查询。 file：将event数据保存到文件中。 graphite：将event数据发送到图形化组件中，一个很流行的开源存储图形化展示的组件。 Codecs：codecs 是基于数据流的过滤器，它可以作为input，output的一部分配置。Codecs可以帮助你轻松的分割发送过来已经被序列化的数据。 一些常见的codecs： json：使用json格式对数据进行编码/解码。 multiline：将汇多个事件中数据汇总为一个单一的行。比如：java异常信息和堆栈信息。 https://www.cnblogs.com/aresxin/p/8035137.html   来源： http://www.cnblogs.com/softidea/p/9801656.html Packetbeat（搜集网络流量数据） Topbeat（搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据） Filebeat（搜集文件数据） Winlogbeat（搜集 Windows 事件日志数据）

   Prospector会找到/apps/logs/*目录下的所有info.log文件，并为每个文件启动一个Harvester。Prospector会检查每个文件，看Harvester是否已经启动，是否需要启动，或者文件是否可以忽略。若Harvester关闭，只有在文件大小发生变化的时候Prospector才会执行检查。只能检测本地的文件。

   Filebeat如何记录文件状态：

   将文件状态记录在文件中（默认在/var/lib/filebeat/registry）。此状态可以记住Harvester收集文件的偏移量。若连接不上输出设备，如ES等，filebeat会记录发送前的最后一行，并再可以连接的时候继续发送。Filebeat在运行的时候，Prospector状态会被记录在内存中。Filebeat重启的时候，利用registry记录的状态来进行重建，用来还原到重启之前的状态。每个Prospector会为每个找到的文件记录一个状态，对于每个文件，Filebeat存储唯一标识符以检测文件是否先前被收集。

   Filebeat如何保证事件至少被输出一次：

   Filebeat之所以能保证事件至少被传递到配置的输出一次，没有数据丢失，是因为filebeat将每个事件的传递状态保存在文件中。在未得到输出方确认时，filebeat会尝试一直发送，直到得到回应。若filebeat在传输过程中被关闭，则不会再关闭之前确认所有时事件。任何在filebeat关闭之前为确认的时间，都会在filebeat重启之后重新发送。这可确保至少发送一次，但有可能会重复。可通过设置shutdown_timeout 参数来设置关闭之前的等待事件回应的时间（默认禁用）。

    

   Logstash工作原理：

   Logstash事件处理有三个阶段：inputs → filters → outputs。是一个接收，处理，转发日志的工具。支持系统日志，webserver日志，错误日志，应用日志，总之包括所有可以抛出来的日志类型。

    

    

   Input：输入数据到logstash。

   一些常用的输入为：

   file：从文件系统的文件中读取，类似于tial -f命令

   syslog：在514端口上监听系统日志消息，并根据RFC3164标准进行解析

   redis：从redis service中读取

   beats：从filebeat中读取

   Filters：数据中间处理，对数据进行操作。

   一些常用的过滤器为：

   grok：解析任意文本数据，Grok 是 Logstash 最重要的插件。它的主要作用就是将文本格式的字符串，转换成为具体的结构化的数据，配合正则表达式使用。内置120多个解析语法。

   官方提供的grok表达式：https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns
   grok在线调试：https://grokdebug.herokuapp.com/

   mutate：对字段进行转换。例如对字段进行删除、替换、修改、重命名等。

   drop：丢弃一部分events不进行处理。

   clone：拷贝 event，这个过程中也可以添加或移除字段。

   geoip：添加地理信息(为前台kibana图形化展示使用)

   Outputs：outputs是logstash处理管道的最末端组件。一个event可以在处理过程中经过多重输出，但是一旦所有的outputs都执行结束，这个event也就完成生命周期。

   一些常见的outputs为：

   elasticsearch：可以高效的保存数据，并且能够方便和简单的进行查询。

   file：将event数据保存到文件中。

   graphite：将event数据发送到图形化组件中，一个很流行的开源存储图形化展示的组件。

   Codecs：codecs 是基于数据流的过滤器，它可以作为input，output的一部分配置。Codecs可以帮助你轻松的分割发送过来已经被序列化的数据。

   一些常见的codecs：

   json：使用json格式对数据进行编码/解码。

   multiline：将汇多个事件中数据汇总为一个单一的行。比如：java异常信息和堆栈信息。

   https://www.cnblogs.com/aresxin/p/8035137.html

    

   来源： http://www.cnblogs.com/softidea/p/9801656.html

   1. Packetbeat（搜集网络流量数据）
   2. Topbeat（搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据）
   3. Filebeat（搜集文件数据）
   4. Winlogbeat（搜集 Windows 事件日志数据）