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 は、コンテナ、ポッド、およびクラスタをタグ付けし、サービス、名前空間、およびデプロイを識別します。
ログとメトリクスのタイプ
ログとメトリクスの収集の設定
ステップ 1.Kubernetes アプリケーションのセットアップおよびインストール
ステップ 2.Kubernetes コントロール プレーン アプリケーションのインストール
Kubernetes コントロール プレーン アプリケーションのインストール手順は、クラスタのプラットフォームによって異なります。このセクションでは、使用可能な Kubernetes プラットフォームについて説明します。ご使用のクラスタ環境に対応した手順を選択してください。
カスタム Kubernetes クラスタ
Kubernetes クラスタを独自に構築する場合は、このセクションで推奨されている手順に従ってください。Kubernetes アプリケーションのインストール時にログとメトリクスの収集が設定されたため、Kubernetes コントロール プレーン アプリケーションをインストールする準備が整っています。
Kubernetes コントロール プレーン アプリケーションをインストールするには、このページの手順に従ってください。
管理対象サービス プロバイダ
管理対象サービス プロバイダを使用する場合は、このセクションで推奨されている、ご使用の管理対象サービス用の手順に従ってください。Kubernetes アプリケーションのインストール時にログとメトリクスの収集が設定されたため、ご使用のプラットフォームに適したコントロール プレーン アプリケーションをインストールする準備が整っています。
- Amazon EKS - コントロール プレーン: EKS コントロール プレーンの状態や API サーバ、Scheduler、Control Manager、およびワーカー ノードの運用状況を把握できます。
- Azure Kubernetes Service (AKS) - コントロール プレーン: AKS コントロール プレーンの状態や API サーバ、Scheduler、Control Manager、およびワーカー ノードの運用状況を把握できます。
- Google Kubernetes Engine (GKE) - コントロール プレーン: GKE コントロール プレーンの状態や API サーバ、Scheduler、Control Manager、およびワーカー ノードの運用状況を把握できます。
ベスト プラクティス
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
- 生成されるメトリクス ボリュームが少ない Source の例
- スクレープ間隔を長くすると、一部のダッシュボード パネルに影響が及び、表示が不正確になる場合があります。
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 バッファ ドキュメントは、次のリンクから参照してください。