Kubernetes 上でエンタープライズグレードのクラウドネイティブロギングシステムを迅速に構築する方法

I. 概要

❝
ELKは、Elasticsearch、Logstash、Kibanaという3つのオープンソースソフトウェアプログラムの略称です。新ツール「Filebeat」が追加されました。Filebeatは軽量なログ収集・処理エージェントです。リソース消費が少なく、様々なサーバーからログを収集し、Logstashに送信するのに適しています。このツールは公式にも推奨されています。

一般的なフローチャートは次のとおりです。

1. Elasticsearchストレージ

❝
Elasticsearchは、データ収集、分析、保存という3つの主要機能を提供するオープンソースの分散検索エンジンです。分散アーキテクチャ、ゼロ設定、自動検出、自動インデックスシャーディング、インデックスレプリケーション、RESTful API、複数のデータソース、自動検索ロードバランシングなどの機能を備えています。

2. Filebeatログデータ収集

❝
Filebeatは、軽量ログコレクターであるBeatsファミリーのメンバーです。Beatsファミリーには実際には6つのメンバーがあります。初期のELKアーキテクチャでは、ログの収集と解析にLogstashが使用されていましたが、Logstashはメモリ、CPU、I/Oリソースを大量に消費します。Logstashと比較すると、BeatsのCPUとメモリの使用量は非常にわずかです。
❝
Filebeatは、ログデータを転送および一元管理するための軽量ツールです。Filebeatは、指定したログファイルまたは場所を監視し、ログイベントを収集します。

Beats には現在 6 つのツールが含まれています。

Packetbeat : ネットワークデータ（ネットワークトラフィックデータを収集）
Metricbeat : メトリクス（システム、プロセス、ファイルシステムレベルでCPUやメモリの使用状況などのデータを収集）
Filebeat : ログファイル（ファイルデータの収集）
Winlogbeat : Windows イベントログ (Windows イベントログデータを収集)
Auditbeat : 監査データ（監査ログを収集）
ハートビート: ランタイム監視 (システム実行中にデータを収集)

ワークフローは次のとおりです。

アドバンテージ

Filebeatは依存関係のないバイナリファイルです。リソースの消費量も非常に少ないです。

欠点

Filebeatの適用範囲は非常に限られているため、特定のシナリオでは問題が発生する可能性があります。バージョン5.xではフィルタリング機能も追加されました。

3. カフカ

❝
Kafkaはピーク時の処理を平準化するのに役立ちます。ELKはRedisをメッセージキューとして使用できますが、Redisはメッセージキューとしては得意ではなく、RedisクラスターはプロフェッショナルなメッセージパブリッシングシステムであるKafkaほど優れていません。Kafkaのインストールについては、以前の記事「Kafkaの原理紹介 + インストール + 基本操作 (Kafka on k8s) ^[1]」を参照してください。

4. Logstash フィルタリング

❝
Logstashは主にログの収集、分析、フィルタリングを行うツールであり、幅広いデータ取得方法をサポートしています。通常、クライアント/サーバーアーキテクチャで動作します。クライアントはログを収集する必要があるホストにインストールされ、サーバーは各ノードから受信したログのフィルタリング、変更、その他の操作を行い、Elasticsearchに送信します。

アドバンテージ

スケーラビリティ

❝
Beatsは複数のLogstashノード間で負荷分散する必要があります。高可用性を確保するには、少なくとも2つのLogstashノードを使用することをお勧めします。Logstashノードごとに1つのBeats入力のみをデプロイするのが一般的ですが、異なるデータソースに対して独立したエンドポイントを公開するために、Logstashノードごとに複数のBeats入力をデプロイすることもできます。

弾性

❝
Logstash の永続キューは、ノード間障害に対する保護を提供します。Logstash におけるディスクレベルの耐障害性を確保するには、ディスクの冗長性を確保することが不可欠です。オンプレミス環境では、RAID 構成が推奨されます。クラウド環境またはコンテナ環境で実行する場合は、データ SLA を反映したレプリケーションポリシーを備えた永続ディスクを使用することをお勧めします。

フィルタ可能

❝
イベントフィールドに対して定期的な変換を実行します。イベント内のフィールドの名前変更、削除、置換、変更が可能です。

欠点

Logstashはリソースを大量に消費し、CPUとメモリを大量に消費します。さらに、メッセージキューキャッシュがないため、データ損失のリスクがあります。

5. Kibanaディスプレイ

❝
Kibanaもオープンソースの無料ツールです。Kibanaは、LogstashとElasticSearchが提供するログ分析用のユーザーフレンドリーなWebインターフェースを提供し、重要なデータログの集約、分析、検索に役立ちます。

FilebeatとLogstashの関係

❝
LogstashはJVM上で実行されるため、多くのリソースを消費します。そのため、作者は後にGo言語で軽量版のLogstash-Forwarderを開発しました。これは機能は少ないものの、リソース消費量は少なくなっています。しかし、作者は一人で開発を進めていました。Elastic.coに入社した後、ElasticはGo言語で開発され、専任チームを擁する別のオープンソースプロジェクト、Packetbeatも買収したため、Logstash-Forwarderの開発を同じGoチームに統合しました。そして、この新しいプロジェクトはFilebeatと名付けられました。

II. Helm3へのELKのインストール

詳細なフローチャートは次のとおりです。

1. 準備条件

1. Helmリポジトリを追加する

 $ helmリポジトリに elastic を追加します https://helm.elastic.co

2. Helm3を使ってElasticsearchをインストールする

1) カスタム値

❝
主な設定は、ストレージクラスの永続性とリソース制限です。私のコンピューターはリソースが限られているため、ここではリソース制限を大幅に削減しています。設定はご自身のニーズに合わせてカスタマイズできます。

 # クラスター名
クラスター名: "elasticsearch"
 ElasticSearch 6.8 以降には x-pack プラグインがプリインストールされており、その一部は無料ですが、ここでは無効にします。
 esConfig:
 elasticsearch.yml: |
ネットワークホスト: 0.0.0.0
クラスター名: "elasticsearch"
 xpack.security.enabled: falseリソース:
リクエスト:
メモリ: 1Gi
ボリュームクレームテンプレート:
ストレージクラス名: "bigdata-nfs-storage"
アクセスモード: [ "ReadWriteOnce" ]
リソース：
リクエスト:
ストレージ: 3Gi
 サービス：
タイプ: NodePort
ポート: 9000
ノードポート: 31311

❝
Kibana のセキュリティヒントを無効にします (Elasticsearch の組み込みセキュリティ機能は有効になっていません) : `xpack.security.enabled: false`

2) Elasticsearchのインストールを開始する

❝
公式イメージのダウンロードが遅いため、インストールプロセスは比較的遅くなります。

 $ helm install es elastic/elasticsearch -f my-values.yaml --namespace bigdata

 W1207 23 :10:57.980283 21465 warnings.go:70] policy/v1beta1 PodDisruptionBudget は v1.21 以降では非推奨、v1.25 以降では利用できません。policy/v1 PodDisruptionBudget を使用してください。
 W1207 23 :10:58.015416 21465 warnings.go:70] policy/v1beta1 PodDisruptionBudget は v1.21 以降では非推奨、v1.25 以降では利用できません。policy/v1 PodDisruptionBudget を使用してください。
名前: es
最終デプロイ日時: 2021年12月7日火曜日23:10:57
名前空間: ビッグデータ
ステータス: 展開済み
改訂: 1
注記:
 1.すべてのクラスタ メンバーが起動するのを確認します。
 $ kubectl get pods --namespace = bigdata -l app = elasticsearch-master -w2 。Helm テストを使用してクラスターの健全性をテストします。
 $ helm --namespace =ビッグデータテスト es

システムが正常に動作するには、すべてのポッドが正常に動作している必要があります。イメージのダウンロードが少し遅いため、しばらくお待ちいただいてから再度ご確認ください。

 $ kubectl get pod -n bigdata -l app = elasticsearch-master
 $ kubectl get pvc -nビッグデータ
$ kubectl get pod -n bigdata -l app = elasticsearch-master を監視します。

3) 検証

 $ helm --namespace =ビッグデータテスト es
 $ kubectl get pod,svc -n bigdata -l app = elasticsearch-master -oワイド
$ カール192.168.0.113:31311/_cat/health
 $ カール192.168.0.113:31311/_cat/nodes

4) 清掃

 $ helm uninstall es -n bigdata
 $ kubectl削除 pvc elasticsearch-master-elasticsearch-master-0 -nビッグデータ
$ kubectl削除 pvc elasticsearch-master-elasticsearch-master-1 -nビッグデータ
$ kubectl delete pvc elasticsearch-master-elasticsearch-master-2 -nビッグデータ

3. Helm3にKibanaをインストールする

1) カスタム値

ドメイン名（elasticsearch-master-headless.bigdata.svc.cluster.local）の由来が不明な方は、前回の記事「Kubernetes（k8s）DNS（CoreDNS）入門」 ^[2]を参照してください。

 $ cat <<EOF> my-values.yaml
 #Kibanaの設定ファイルはここで変更されています。デフォルトの場所は/usr/share/kibana/kibana.yamlです。
 キバナ設定:
 キバナ.yml: |
 サーバーポート: 5601
 server.host: "0.0.0.0"
 elasticsearch.hosts: [ "elasticsearch-master-headless.bigdata.svc.cluster.local:9200" ]リソース:
 リクエスト:
 CPU：「1000m」
 メモリ: "256Mi"
 制限:
 CPU：「1000m」
 メモリ：「1Gi」
 サービス：
 #タイプ: ClusterIP
 タイプ: NodePort
 ロードバランサーIP: ""
 ポート: 5601
 ノードポート: "30026"
 終了

2) Kibanaのインストールを開始する

 $ helm install kibana elastic/kibana -f my-values.yaml --namespace bigdata

3) 検証

 $ kubectl get pod,svc -n bigdata -l app = kibana

ブラウザ経由でアクセス: http://192.168.0.113:30026/

4) 清掃

 $ helmアンインストール kibana -n bigdata

4. Helm3にFilebeatをインストールする

❝
Filebeatはデフォルトでホストマシンの`/var/lib/docker/containers`にDockerログを収集します。Dockerのインストールパスを変更した場合、どのようにログを収集するのでしょうか？答えは簡単です。チャート内の`DaemonSet`ファイルの`hostPath`パラメータを変更するだけです。

 -名前: varlibdockercontainers
ホストパス:
パス: /var/lib/docker/containers # Dockerのインストールパスに置き換えます

もちろん、値をカスタマイズすることもできます。ここでは、カスタム値方式を使用してログ収集パスを変更することをお勧めします。

1) カスタム値

❝
デフォルトではデータは Elasticsearch (ES) に保存されますが、ここでは Kafka にデータを保存するように変更します。

 $ cat <<EOF> my-values.yaml
 デーモンセット:
 ファイルビート設定:
 ファイルビート.yml: |
 ファイルビート入力:
 - タイプ: コンテナ
パス:
 - /var/log/コンテナ/*.log
 出力.elasticsearch:
 有効: false
 ホスト: '${NODE_NAME}'
 ホスト: '${ELASTICSEARCH_HOSTS:elasticsearch-master:9200}'
 出力.kafka:
 有効: true
 ホスト: ["kafka-headless.bigdata.svc.cluster.local:9092"]
 トピック: テスト
終了

2) Filefeatのインストールを開始する

 $ helm install filebeat elastic/filebeat -f my-values.yaml --namespace bigdata
 $ kubectlポッドを取得します--namespace = bigdata -l app = filebeat-filebeat -w

3) 検証

 # まずKafkaクライアントにログインします
$ kubectl exec --tty -i kafka-client --namespace bigdata --bash
 # 再消費データ
$ kafka -console -consumer .sh --bootstrap -server kafka.bigdata.svc.cluster.local:9092 --topicテスト

データが消費可能であることは、データが Kafka に保存されていることを意味します。

Kafka データのバックログを確認します。

 $ kubectl exec --tty -i kafka-client --namespace bigdata --bash
 $ kafka -consumer -groups .sh --bootstrap -server kafka-0.kafka-headless.bigdata.svc.cluster.local:9092 --describe --group mygroup

大量のデータがバックログにあることが判明しました。

次のステップは、Logstash をデプロイして Kafka データを消費し、最終的に Elasticsearch に保存することです。

4) 清掃

 $ helmアンインストール filebeat -n bigdata

5. Helm3にLogstashをインストールする

1) カスタム値

❝
[注意] ES と Kafka のアドレスを自分の環境のものに変更することを忘れないでください。

 $ cat <<EOF> my-values.yaml
 ログスタッシュ構成:
 ログスタッシュ.yml: |
 xpack.monitoring.enabled: false
 ログスタッシュパイプライン:
 ログスタッシュ.yml: |
 入力 {
 カフカ {
 bootstrap_servers => "kafka-headless.bigdata.svc.cluster.local:9092"
 トピック => ["テスト"]
 group_id => "mygroup"
 #メタデータを使用している場合は、次のバイトシリアル化は使用できません。使用するとエラーが発生します。
 #key_deserializer_class => "org.apache.kafka.common.serialization.ByteArrayDeserializer"
 #value_deserializer_class => "org.apache.kafka.common.serialization.ByteArrayDeserializer"
 コンシューマースレッド => 1
 # デフォルト値は false です。値が true の場合にのみメタデータが取得されます。
 decorate_events => true
 auto_offset_reset => "earliest"
 }
 }
 フィルター {
 変異 {
 # Kafka キーからデータを取得し、カンマで分割します
分割 => ["[@metadata][kafka][key]", ","]
 追加フィールド => {
 # 分割後の最初のデータをカスタム「インデックス」フィールドに配置します。
 "インデックス" => "%{[@metadata][kafka][key][0]}"
 }
 }
 }
 出力{
 エラスティックサーチ {
 プール最大 => 1000
 ルートあたりのプール最大数 => 200
 ホスト => ["elasticsearch-master-headless.bigdata.svc.cluster.local:9200"]
 インデックス => "test-%{+YYYY.MM.dd}"
 }
 }
 # リソースの制限
リソース：
 リクエスト:
 CPU：「100m」
 メモリ: "256Mi"
 制限:
 CPU：「1000m」
 メモリ：「1Gi」

 ボリュームクレームテンプレート:
 アクセスモード: ["ReadWriteOnce"]
 リソース：
 リクエスト:
 ストレージ: 3Gi
 終了

出力プラグインは、特定のターゲットにイベントを送信します。

❝
stdout { codec => rubydebug } // デバッグモードを有効にすると、出力がコンソールに表示されます

stdout: 標準出力。イベントを画面に出力します。

出力{
標準出力{
コーデック= > "rubydebug"
 }
 }

file: イベントをファイルに書き込みます。

出力{
ファイル {
パス= > "/data/logstash/%{host}/{application}
 コーデック => 行 { フォーマット => " %{メッセージ} "} }
 }
 }

Kafka: Kafka へのイベントの送信

出力{
カフカ{
 bootstrap_servers = > "localhost:9092"
 topic_id = > "test_topic" # 必須設定。メッセージが生成されるトピック。
 }
 }

Elasticsearch: Elasticsearchにログを保存する

出力{
エラスティックサーチ {
 #ユーザー => エラスティック
#パスワード => changeme
ホスト= > "localhost:9200"
インデックス= > "nginx-access-log-%{+YYYY.MM.dd}"
 }
 }

2) Logstashのインストールを開始する

 $ helm install logstash elastic/logstash -f my-values.yaml --namespace bigdata

 $ kubectl get pods --namespace = bigdata -l app = logstash-logstash

3) 検証

（1）Kibanaにログインしてインデックスが作成されているか確認します。

（2）ログを見る

 $ kubectl logs -f logstash-logstash-0 -n bigdata >ログ
$ tail -100 ログ

（3）Kafkaの消費状況を確認する

 $ kubectl exec --tty -i kafka-client --namespace bigdata --bash
 $ kafka-consumer-groups.sh --bootstrap-server kafka-0.kafka-headless.bigdata.svc.cluster.local:9092 --describe --group mygroup

(4) Kibanaでインデックスデータを表示する (Kibanaバージョン: 7.15.0) インデックススキーマを作成する

❝
管理-》スタック管理-》Kibana-》インデックスパターン

上記で作成したインデックスパターンを使用してデータをクエリする（Discover）

4) 清掃

 $ helm uninstall logstash -n bigdata

III. ELK関連のバックアップコンポーネントとバックアップ方法

Elasticsearch をバックアップする方法は 2 つあります。

elasticdump ^[3]やesm ^[4]などのツールを使用して、Elasticsearchに保存されているデータをテキストファイルにエクスポートします。これは、データ量が少ないシナリオに適しています。
この方法は、ElasticsearchのスナップショットAPIを利用して、Elasticsearchデータディレクトリ内のファイルをバックアップすることでスナップショットを作成します。大規模なデータセットを扱うシナリオに適しています。

1. Elasticsearchスナップショットバックアップ

利点: スナップショットを取得し、スナップショットバックアップ戦略を定義することで、自動化されたスナップショットストレージが可能になり、さまざまなバックアップニーズを満たすさまざまな戦略を定義できるようになります。
デメリット：復元プロセスの柔軟性が十分ではありません。バックアップ用のスナップショットは高速ですが、仮想マシンのスナップショットと同様に、復元はそれほど簡単ではありません。

1) バックアップディレクトリを設定する

以下のように、elasticsearch.yml 構成ファイルでバックアップパス path.repo を指定します。

パス.リポジトリ: [ "/mount/backups" , "/mount/longterm_backups" ]

設定が完了したら、スナップショットAPIを使用してリポジトリを作成できます。以下では、my_backupという名前のリポジトリを作成します。

 /_snapshot/my_backup を配置する
{
 「タイプ」 : 「fs」 、
 "設定" ： {
 「場所」 : 「/mount/backups/my_backup」
 }
 }

2) APIインターフェース経由でバックアップを開始する

スナップショットを使用すると、データの現在の状態を記録するバックアップ（スナップショットとも呼ばれます）を作成できます。以下に示すように、 snapshot_1という名前のスナップショットを作成します。

 /_snapshot/my_backup/snapshot_1 を配置しますか?wait_for_completion = true

❝
【ご注意】 wait_for_completion が true の場合、API はバックアップ完了後に結果を返します。それ以外の場合は、デフォルトで非同期実行されます。このパラメータを設定したのは、効果をすぐに確認できるようにするためです。オンラインで実行する場合は、このパラメータを設定する必要はなく、バックグラウンドで非同期実行してください。

3) 増分バックアップ

 /_snapshot/my_backup/snapshot_2 を配置しますか?wait_for_completion = true

❝
実行後、`/mount/backups/my_backup` のサイズが増加していることがわかります。これは、新しいデータがバックアップされたことを示しています。同じリポジトリ内で複数のスナップショットを取得する場合、Elasticsearch はバックアップ対象のデータセグメントファイルが変更されていないかどうかをチェックすることに注意してください。変更がない場合、処理は行われません。変更がある場合は、変更されたセグメントファイルのみをバックアップします。これにより、実質的に増分バックアップが実現されます。

4) データ復旧

次の API を呼び出すことによって、リカバリ機能をすぐに実装できます。

 POST /_snapshot/my_backup/snapshot_1/_restore ?wait_for_completion = true
 {
 「インデックス」 : 「index_1」 、
 「名前の変更」 : 「復元されたインデックス1」
 }

2. Elasticdump を使用して Elasticsearch データをバックアップおよび移行します。

インデックスデータをファイルにエクスポートします (バックアップ)。

 # インデックスマッピングデータをエクスポートする
$ エラスティックダンプ\
 --input = http://es インスタンスIP:9200/インデックス名/インデックスタイプ \
 --output = /data/my_index_mapping.json \ # 保存先ディレクトリ
--type =マッピング
# インデックスデータをエクスポートする
$ エラスティックダンプ\
 --input = http://es インスタンスIP:9200/インデックス名/インデックスタイプ \
 --output = /data/my_index.json \
 --type =データ

インデックスデータファイルをインデックスにインポート (復元) します。

 # データのインポートをインデックスにマッピングする
$ エラスティックダンプ\
 --output = http://es インスタンスIP:9200/index_name \
 --input = /home/indexdata/roll_vote_mapping.json \ # インポートデータディレクトリ
--type =マッピング
# ESドキュメントデータをインデックスにインポートする
$ エラスティックダンプ\
 --output = http:///es インスタンス IP:9200/index_name \
 --input = /home/indexdata/roll_vote.json \
 --type =データ

バックアップデータは別の Elasticsearch クラスターに直接インポートできます。

 $ elasticdump --input = http://127.0.0.1:9200/test_event --output = http://127.0.0.2:9200/test_event --type =データ

タイプ

`type` は、Elasticdump データのエクスポートおよびインポートのデータ型を指定します。Elasticdump ツールは以下のデータ型をサポートしています。

タイプ	説明する
マッピング	ESインデックスマッピング構造データ
データ	ESデータ
設定	ESインデックスライブラリのデフォルト設定
アナライザ	ESトークナイザー
テンプレート	ESテンプレート構造データ
エイリアス	ES インデックスエイリアス

3. ElasticsearchデータのESMバックアップと移行

Elasticsearchデータのバックアップ

 $ esm -s http://10.33.8.103:9201 -x "petition_data" -b 5 --count = 5000 --sliced_scroll_size = 10 --refresh -o = ./es_backup.bin

❝
-w はスレッド数を指定します。-b は一括リクエストのサイズをMB単位で指定します（デフォルトは5MB）。-c はスクロールリクエストの数を指定します。Elasticsearch データをインポートおよび復元します。

 $ esm -d http://172.16.20.20:9201 -y "petition_data6" -c 5000 -b 5 --refresh -i = ./dump.bin

IV. イースターエッグ

ELKアーキテクチャ（Elasticsearch、Flume、Kafka、Flink、Kibana）に非常によく似たロギングシステムアーキテクチャがもう1つあります。ただし、FilebeatがFlumeに、LogstashがFlinkに置き換えられている点が異なります。これについては後日記事でご紹介いたしますので、どうぞお楽しみに…

参考リンク

[1] Afkaの原理、インストール、基本操作の紹介（Kafka on k8s）: https://www.cnblogs.com/liugp/p/16461885.html

[2] Kubernetes（k8s）DNS（CoreDNS）入門： https://www.cnblogs.com/liugp/p/16387457.html

[3]elasticdump: https://github.com/elasticsearch-dump/elasticsearch-dump

[4]esm: https://github.com/medcl/esm

I. 概要

1. Elasticsearchストレージ

2. Filebeatログデータ収集

3. カフカ

4. Logstash フィルタリング

5. Kibanaディスプレイ

FilebeatとLogstashの関係

II. Helm3へのELKのインストール

1. 準備条件

2. Helm3を使ってElasticsearchをインストールする

1) カスタム値

2) Elasticsearchのインストールを開始する

3) 検証

4) 清掃

3. Helm3にKibanaをインストールする

1) カスタム値

2) Kibanaのインストールを開始する

3) 検証

4) 清掃

4. Helm3にFilebeatをインストールする

1) カスタム値

2) Filefeatのインストールを開始する

3) 検証

4) 清掃

5. Helm3にLogstashをインストールする

1) カスタム値

2) Logstashのインストールを開始する

3) 検証

4) 清掃

III. ELK関連のバックアップコンポーネントとバックアップ方法

1. Elasticsearchスナップショットバックアップ

1) バックアップディレクトリを設定する

2) APIインターフェース経由でバックアップを開始する

3) 増分バックアップ

4) データ復旧

2. Elasticdump を使用して Elasticsearch データをバックアップおよび移行します。

3. ElasticsearchデータのESMバックアップと移行

IV. イースターエッグ

参考リンク

関連するおすすめ記事

ランダムにおすすめされた記事

人気のタグ