メインコンテンツまでスキップ
Sumo Logic Japanese

Kubernetes の収集のセットアップ

このページでは、Kubernetes 環境の収集プロセスを概説してから、ログおよびメトリクス収集の設定手順を説明します。Sumo Logic Kubernetes アプリケーションは、Kubernetes ワーカー ノードの作業を管理および監視するサービスを提供します。ただし、このサービスを実現するためには、API サーバ、etcd、Kube-System、およびワーカー ノードを含むマスタ ノード コントロール プレーンを監視する Kubernetes コントロール プレーン アプリケーションとの連携が必要です。設定プロセスでは、これらの両方のアプリケーションをセットアップします。

収集の概要

Sumo Logic は、Fluentbit、FluentD、Prometheus、および Falco を使用して、ログ、メトリクス、およびセキュリティ データを収集します。これらのコレクタは、すべてオープン ソースのコレクタで、Cloud Native Computing Foundation (CNCF) によって保守されています。収集されたデータは、集中型の FluentD パイプラインを通過して、メタデータ強化が実施されます。Sumo Logic は、コンテナ、ポッド、およびクラスタをタグ付けし、サービス、名前空間、およびデプロイを識別します。 

K8s_Centralized_Collection.png

ログとメトリクスのタイプ

ログとメトリクスの収集の設定

ステップ 1.Kubernetes アプリケーションのセットアップおよびインストール

ステップ 2.Kubernetes コントロール プレーン アプリケーションのインストール 

Kubernetes コントロール プレーン アプリケーションのインストール手順は、クラスタのプラットフォームによって異なります。このセクションでは、使用可能な Kubernetes プラットフォームについて説明します。ご使用のクラスタ環境に対応した手順を選択してください。

カスタム Kubernetes クラスタ

Kubernetes クラスタを独自に構築する場合は、このセクションで推奨されている手順に従ってください。Kubernetes アプリケーションのインストール時にログとメトリクスの収集が設定されたため、Kubernetes コントロール プレーン アプリケーションをインストールする準備が整っています。

Kubernetes コントロール プレーン アプリケーションをインストールするには、このページの手順に従ってください。

管理対象サービス プロバイダ

管理対象サービス プロバイダを使用する場合は、このセクションで推奨されている、ご使用の管理対象サービス用の手順に従ってください。Kubernetes アプリケーションのインストール時にログとメトリクスの収集が設定されたため、ご使用のプラットフォームに適したコントロール プレーン アプリケーションをインストールする準備が整っています。

ベスト プラクティス

Prometheus のスクレープ間隔のグローバル設定

インストール時に Prometheus のスクレープ間隔をグローバルに設定して、メトリクスの収集頻度を調整できます。たとえば、helm インストール コマンドに次のフラグを渡すと、スクレープ間隔が 30 秒ごと (デフォルト) ではなく、2 分ごとに設定されます。

--set prometheus-operator.prometheus.prometheusSpec.scrapeInterval=”2m”

これは values.yaml ファイルで設定することもでき、その場合は、scrape_interval を追加します。Prometheus のドキュメントを参考にしてください。

考慮事項:

  • メトリクス Source で生成されるメトリクス ボリュームが少ない場合は、スクレープ間隔を短くすることをお勧めします。
    • 生成されるメトリクス ボリュームが少ない Source の例
      • kube-controller-manager-metrics
      • kube-scheduler-metrics
    • 生成されるメトリクス ボリュームが多い Source の例
      • apiserver-metrics
      • Kube-state-metrics
  • スクレープ間隔を長くすると、一部のダッシュボード パネルに影響が及び、表示が不正確になる場合があります。

Fluentd の収集パフォーマンス

弊社では、Fluentd によるログとメトリクスの収集パフォーマンスについてベンチマークを実施しました。この結果をもとに、お客様は、ワークロードに必要な Fluentd レプリカの最適な数を決定していただけます。Fluentd デプロイのサイズを設定するときは、次の結果を使用してください。

Kubernetes バージョン 1.13 と Sumo Logic Helm チャート バージョン 0.6.0-0.8.0 を使用する場合、各 Fluentd レプリカでは、次を処理できます。

ログ ボリューム メトリクス データ ポイント/分 (DPM)
1.3 Mb/s 0 DPM
750 KB/s 20K DPM
250 KB/s 40K DPM
0 バイト 50K DPM

このベンチマークは、使用する vCPU が 2 基、RAM が 8G の AWS EC2 M4.Large インスタンスで実施されました。

ベンチマーク設定

Fluentd によるログ収集のテストでは、さまざまなレートで実働負荷をかけることができる内部ログ ジェネレータが使用されました。

このメトリクス ワークロードの生成には、Prometheus メトリクスを生成する負荷ジェネレータ Avalanche が使用されました。Avalanche は、次のパラメータを使用して設定されました。

--metric-count=200
--series-count=100
--port=9006
--series-interval=60000
--metric-interval=60000
--value-interval=60

Avalanche で生成されたメトリクスは、Prometheus のインスタンスで収集されてから、Fluentd の単一レプリカに転送され、Sumo Logic HTTP Source エンドポイントに送信されました。

複数行ログのサポート

デフォルトでは、2019-11-17 07:14:12 形式の日付で始まる複数行ログの 1 行目と一致する正規表現が使用されます。

ログの日付形式が異なる場合は、複数行ログの 1 行目を検出するためのカスタム正規表現を指定できます。境界正規表現の設定についての詳細は、「複数行のログの収集」を参照してください。

新しいパーサは、次のように、values.yaml ファイルの fluent-bit 設定セクションの parsers キーの下に定義できます。

parsers:
  enabled: true
  regex:
    - name: multi_line
    regex: (?<log>^{"log":"\d{4}-\d{1,2}-\d{1,2} \d{2}:\d{2}:\d{2}.*)
    - name: new_parser_name
    ## This parser matches lines that start with time of the format : 07:14:12
    regex: (?<log>^{"log":"\d{2}:\d{2}:\d{2}.*)

Parser_Firstline で使用する正規表現には、1 つ以上の名前付きキャプチャ グループが必要です。

新しく定義したパーサを使用して複数行ログの 1 行目を検出するには、fluent-bit の Input plugin 設定の Parser_Firstline パラメータを次のように変更します。

Parser_Firstline new_parser_name

追加の optional パーサを使用して、複数行エントリを解釈および構造化することもできます。複数行がオンのとき、1 行目が Parser_Firstline と一致したら、残りの行は Parser_N と照合されます。

Parser_Firstline multi_line
Parser_1 optional_parser

Fluentd 自動スケーリング

Fluentd デプロイの自動スケーリングを有効にするオプションが提供されています。デフォルトでは無効です。

Fluentd の自動スケーリングを有効にするには、次の手順を実行します。

  • metrics-server 依存関係を有効にする 注意: metrics-server がすでにインストールされている場合、このステップは不要です。

## Configure metrics-server
## ref: https://github.com/helm/charts/blob/...er/values.yaml
metrics-server:
  enabled: true

  • Fluentd の自動スケーリングを有効にする

fluentd:
  ## Option to turn autoscaling on for fluentd and specify metrics for HPA.
  autoscaling:
    enabled: true

Fluentd ファイルベース バッファ

デフォルトでは、Fluentd バッファにはインメモリ バッファが使用されますが、本番環境では代わりにファイルベース バッファを使用することをお勧めします。

バッファ設定は、values.yaml ファイルの fluentd キーの下に次のように設定できます。

fluentd:
  ## Option to specify the Fluentd buffer as file/memory.
  buffer: "file"

複数のファイル パスが設定されており、そこにバッファ チャンクが保存されます。

パス ディレクトリに十分な領域があることを確認してください。ディスク領域の不足は、よく発生する問題です。

values.yaml ファイルの設定を変更したら、helm upgrade コマンドを実行して変更を適用する必要があります。

$ helm upgrade collection sumologic/sumologic --reuse-values -f values.yaml

公式の Fluentd バッファ ドキュメントは、次のリンクから参照してください。

  • この記事は役に立ちましたか?