ステップ 1: CloudWatch の名前空間を作成するステップ 2: Fluentd をインストールするステップ 3: Fluentd のセットアップを検証する複数行ログのサポート (オプション) Fluentd からのログボリュームの縮小トラブルシューティング

(オプション) CloudWatch Logs へログを送信する DaemonSet として Fluentd を設定する

警告

Container Insights の Fluentd のサポートは現在メンテナンスモードになっています。つまり、AWS はこれ以上 Fluentd の更新を提供せず、近い将来に廃止する予定です。さらに、Container Insights の現在の Fluentd 構成は、最新の改善およびセキュリティパッチがない古いバージョンの Fluentd Image fluent/fluentd-kubernetes-daemonset:v1.10.3-debian-cloudwatch-1.0 を使用しています。オープンソースコミュニティでサポートされている最新の Fluentd イメージについては、「fluentd-kubernetes-daemonset」を参照してください。

可能な限り Container Insights で FluentBit を使用するように移行することを強くお勧めします。Container Insights のログフォワーダとして FluentBit を使用すると、パフォーマンスが大幅に向上します。

詳細については、「CloudWatch Logs へログを送信する DaemonSet として Fluent Bit を設定する」および「 Fluentd を既に使用している場合の違い」を参照してください。

コンテナからログを収集するように Fluentd をセットアップするには、「Amazon EKS および Kubernetes の Container Insights のクイックスタートセットアップ」のステップに従うか、このセクションのステップに従います。以下のステップでは、CloudWatch Logs へログを送信する DaemonSet として Fluentd を設定します。このステップを完了すると、Fluentd は、まだ存在していない場合は次のロググループを作成します。

ロググループ名	ログソース
`/aws/containerinsights/Cluster_Name/application`	`/var/log/containers` のすべてのログファイル
`/aws/containerinsights/Cluster_Name/host`	`/var/log/dmesg`、`/var/log/secure`、および `/var/log/messages` からのログ
`/aws/containerinsights/Cluster_Name/dataplane`	`/var/log/journal`、`kubelet.service`、および`kubeproxy.service` に対する `docker.service` のログ。

ステップ 1: CloudWatch の名前空間を作成する

CloudWatch に対して amazon-cloudwatch という Kubernetes 名前空間を作成するには、次のステップを使用します。すでにこの名前空間を作成している場合は、以下のステップをスキップできます。

CloudWatch の名前空間を作成するには

以下のコマンドを入力します。


kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cloudwatch-namespace.yaml

ステップ 2: Fluentd をインストールする

Fluentd をダウンロードして、このプロセスを開始します。これらのステップを完了すると、クラスターで次のリソースが作成されます。

fluentd 名前空間の amazon-cloudwatch という名前のサービスアカウント。このサービスアカウントは、DaemonSet Fluentd を実行するために使用されます。詳細については、Kubernetes Reference のサービスアカウントの管理を参照してください。
fluentd 名前空間の amazon-cloudwatch という名前のクラスターロール。このクラスターロールは、ポッドログの get、list、watch の各アクセス許可を fluentd サービスアカウントに付与します。詳細については、Kubernetes Reference の API の概要を参照してください。
fluentd-config 名前空間の amazon-cloudwatch という名前の ConfigMap。この ConfigMap には、Fluentd によって使用される設定が含まれています。詳細については、Kubernetes Tasks ドキュメントの「Configure a Pod to Use a ConfigMap」を参照してください。

Fluentd をインストールするには

クラスター名を持つ cluster-info という名前の ConfigMap と、ログの送信先となる AWS リージョンを作成します。次のコマンドを実行し、プレースホルダーをクラスター名とリージョン名で更新します。
```
kubectl create configmap cluster-info \
--from-literal=cluster.name=cluster_name \
--from-literal=logs.region=region_name -n amazon-cloudwatch
```
次のコマンドを実行して、Fluentd DaemonSet をクラスターにダウンロードしてデプロイします。正しいアーキテクチャでコンテナイメージを使用していることを確認してください。サンプルマニフェストは x86 インスタンスでのみ機能し、クラスターに Advanced RISC Machine (ARM) インスタンスがある場合に CrashLoopBackOff を入力します。Fluentd daemonSet には、複数の基礎となるイメージに 1 つのタグを使用し、コンテナランタイムが適切なイメージをプルすることを可能にする、公式のマルチアーキテクチャ Docker イメージはありません。Fluentd ARM イメージでは、arm64 サフィックスが付いた別のタグが使用されます。
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/fluentd/fluentd.yaml
```
注記
Fluentd 構成を最適化し、Kubernetes API エンドポイントに対する Fluentd API リクエストの影響を最小限に抑えるための最近の変更により、Kubernetes フィルターの「監視」オプションはデフォルトで無効になっています。詳細については、fluent-plugin-kubernetes_metadata_filter を参照してください。
次のコマンドを実行してデプロイを検証します。各ノードには、fluentd-cloudwatch-* という名前の 1 つのノードが必要です。
```
kubectl get pods -n amazon-cloudwatch
```

ステップ 3: Fluentd のセットアップを検証する

Fluentd のセットアップを検証するには、次のステップを使用します。

Container Insights の Fluentd セットアップを検証するには

CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。
ナビゲーションペインで、[Log groups] (ロググループ) を選択します。Fluentd をコンテナにデプロイしたリージョンを選択していることを確認してください。

リージョンのロググループのリストは、以下のように表示されます。
- /aws/containerinsights/Cluster_Name/application
- /aws/containerinsights/Cluster_Name/host
- /aws/containerinsights/Cluster_Name/dataplane
これらのロググループが表示される場合、Fluentd のセットアップは検証済みです。

複数行ログのサポート

2019 年 8 月 19 日に、Fluentd によって収集されたログの複数行のログサポートを追加しました。

デフォルトでは、複数行のログエントリスターターは、空白のない任意の文字です。つまり、空白文字のない文字で始まるすべてのログ行は、新しい複数行のログエントリとみなされます。

独自のアプリケーションログで異なる複数行のスターターを使用している場合は、fluentd.yaml ファイルで 2 つの変更を行うことでそれらのログをサポートできます。

まず、exclude_path の containers セクションの fluentd.yaml フィールドにログファイルのパス名を追加することで、デフォルトの複数行サポートから除外します。次に例を示します。



<source>
  @type tail
  @id in_tail_container_logs
  @label @containers
  path /var/log/containers/*.log
  exclude_path ["full_pathname_of_log_file*", "full_pathname_of_log_file2*"]

次に、ログファイルのブロックを fluentd.yaml ファイルに追加します。以下の例は、複数行のスターターとしてタイムスタンプの正規表現を使用する CloudWatch エージェントのログファイルに使用されます。このブロックをコピーして fluentd.yaml に追加できます。示された行を変更して、使用するアプリケーションログファイル名と複数行のスターターを反映します。



<source>
  @type tail
  @id in_tail_cwagent_logs
  @label @cwagentlogs
  path /var/log/containers/cloudwatch-agent*
  pos_file /var/log/cloudwatch-agent.log.pos
  tag *
  read_from_head true
 <parse>
    @type json
    time_format %Y-%m-%dT%H:%M:%S.%NZ
 </parse>
</source>



<label @cwagentlogs>
  <filter **>
    @type kubernetes_metadata
    @id filter_kube_metadata_cwagent
  </filter>

  <filter **>
    @type record_transformer
    @id filter_cwagent_stream_transformer
    <record>
      stream_name ${tag_parts[3]}
    </record>
 </filter>

  <filter **>
    @type concat
    key log
    multiline_start_regexp /^\d{4}[-/]\d{1,2}[-/]\d{1,2}/
    separator ""
    flush_interval 5
    timeout_label @NORMAL
 </filter>

 <match **>
    @type relabel
    @label @NORMAL
 </match>
</label>

(オプション) Fluentd からのログボリュームの縮小

デフォルトでは、Fluentd アプリケーションログおよび Kubernetes メタデータを CloudWatch に送信します。CloudWatch に送信されるデータの量を減らす場合は、これらのデータソースが一方または両方の CloudWatch に送信されることを停止できます。

Fluentd アプリケーションログを停止するには、fluentd.yaml ファイルから次のセクションを削除します。



<source>
  @type tail
  @id in_tail_fluentd_logs
  @label @fluentdlogs
  path /var/log/containers/fluentd*
  pos_file /var/log/fluentd.log.pos
  tag *
  read_from_head true
   <parse>
   @type json
   time_format %Y-%m-%dT%H:%M:%S.%NZ
  </parse>
</source>  

<label @fluentdlogs>
  <filter **>
    @type kubernetes_metadata
    @id filter_kube_metadata_fluentd
  </filter>

  <filter **>
    @type record_transformer
    @id filter_fluentd_stream_transformer
    <record>
      stream_name ${tag_parts[3]}
    </record>
   </filter>

   <match **>
     @type relabel
     @label @NORMAL
   </match>
</label>

CloudWatch に送信されたログイベントに Kubernetes メタデータが追加されないように削除するには、 record_transformer ファイルの fluentd.yaml セクションに 1 行を追加します。このメタデータを削除するログソースに、次の行を追加します。


remove_keys $.kubernetes.pod_id, $.kubernetes.master_url, $.kubernetes.container_image_id, $.kubernetes.namespace_id

例:



<filter **>
  @type record_transformer
  @id filter_containers_stream_transformer
  <record>
    stream_name ${tag_parts[3]}
  </record>
  remove_keys $.kubernetes.pod_id, $.kubernetes.master_url, $.kubernetes.container_image_id, $.kubernetes.namespace_id
</filter>

トラブルシューティング

正しいリージョンで確認しているものの、これらのロググループが表示されない場合は、Fluentd DaemonSet ポッドのログでエラーを確認します。

次のコマンドを実行してステータスが Running であることを確認します。


kubectl get pods -n amazon-cloudwatch

前のコマンドの結果で、ポッドの名前が fluentd-cloudwatch で始まることに注意してください。次のコマンドでこのポッド名を使用します。


kubectl logs pod_name -n amazon-cloudwatch

ログに IAM アクセス権限に関連するエラーがある場合は、クラスターノードにアタッチされた IAM ロールを確認します。Amazon EKS クラスターの実行に必要なアクセス許可の詳細については、Amazon EKS ユーザーガイドの「Amazon EKS IAM ポリシー、ロール、アクセス許可」を参照してください。

ポッドのステータスが CreateContainerConfigError である場合は、次のコマンドを実行して正確なエラーを取得します。


kubectl describe pod pod_name -n amazon-cloudwatch

pod の状態が CrashLoopBackOff の場合は、Fluentd コンテナイメージのアーキテクチャが Fluentd をインストールしたときのノードと同じであることを確認します。クラスターに x86 ノードと ARM64 ノードの両方がある場合は、kubernetes.io/arch ラベルを使用して、イメージを正しいノードに配置できます。詳細については、kuberntes.io/arch をご参照ください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

CloudWatch Logs へログを送信する DaemonSet として Fluent Bit を設定する

(オプション) Amazon EKS コントロールプレーンのログ記録の設定