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

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

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

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

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

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

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

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 をご参照ください。