FargateからFireLensで三つ股出力（2 of 2）

15916 ワード
FireLens AWS fluentbit Fargate AWS テキストリンク

前回のあらすじ：FargateタスクからFireLensに吐き出す準備ができた。

Step by Step

1. CWL

まずCWLへの吐き出しだが、前回記事の追記にも書いたように、いくつか注意点がある。

  • マネジメントコンソールの「FireLensの統合を有効にする」チェックボックスは、あくまでlog_routerコンテナをアプリコンテナのサイドカーとして追加するまでしかやらないので、ログを構成するための設定を忘れず行う必要がある。
  • 1) アプリコンテナのログ構成（logConfiguration）セクションに、awsfirelensドライバーへの書き出しを明記すること。
    • これによって、アプリコンテナからlog_routerコンテナへの書き出し経路が成立する。
    • そのままだと宛先不明でどこにもログが書かれないので、公式の例を参考にlogConfiguration→optionsを記述し、FireLensにCWL設定の詳細を教えてやる必要がある。この設定がFireLensコンテナに渡され、fluent-bit.confが自動生成される仕組み。
    • 最終的にCWLに書くのはFireLensコンテナ。
  • 2) log_routerコンテナのlogConfiguration→optionsに、awslogsドライバーへの書き出しを明記すること。
    • 書かないとエラーになる。
    • これはlog_routerコンテナ自身（fluent-bit）のシステムログ記録用で、アプリコンテナのログ出力設定はあくまでアプリコンテナ側のoptionsで書く（カスタム構成ファイルの場合はやや扱いが異なるが、これについては後述する）。
  • 3) タスク実行ロールのポリシーに、CreateLogGroup権限を加えること。
    • 前も似たようなハマリポイントがあったが、今回も要注意。
    • デフォルトで作成されるタスク実行ロールであるecsTaskExecutionRoleにAmazonECSTaskExecutionRolePolicyというAWSマネージドなポリシーが割り当てられているが、このポリシーにはlogs:CreateLogStreamとlogs:PutLogEventsは許可されているがlogs:CreateLogGroupの許可が入ってない。本来CWLプラグインに必要な権限が足りておらず、いつまで経ってもロググループが作成されず、従ってタスクも正常に作成されない。これはアプリコンテナだけでなく、log_routerコンテナも同様なので、双方でちゃんとロググループが作成されていることを確認すること（面倒なら自分で作成してもよい）。

わかってみれば理屈は通るのだが、若干面倒くさい。

実際の（アプリコンテナの）設定はこちら。
なお、前回流用したコンテナはログ出力検証には不向きだったので、タスク定義をnginx:latestに差し替えている。

新しいタスク定義のリビジョンが作成されたら、当該サービスでこのタスクを選択して更新。

abで軽く負荷をかけてみる。

% ab -n 1000 -c 5 http://XXX.XXX.XXX.XXX/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

（中略）

Percentage of the requests served within a certain time (ms)
  50%     15
  66%     16
  75%     17
  80%     17
  90%     31
  95%    104
  98%    233
  99%    236
 100%    271 (longest request)

無事、FireLens（log_routerコンテナ）経由でCWLにログが出力された。

2. KFH

二股にする前に、KFHとの1:1構成も試しておく。
KFHの作成手順は割愛するが、入力元をDirect PUT、出力先をS3とし、テストしやすいよう1MBまたは60秒で吐き出すバッファ設定にした以外は全てデフォルトで作成した。

設定 値
ストリーム名 kfh-firelens
入力元 Direct PUT
出力先 S3
バッファ設定 1MBまたは60秒

アプリコンテナの設定はこちら。

FireLensコンテナの設定は変更不要。
あとは、タスクロール（ログ出力など実行環境を整えるタスク実行ロールとは異なり、コンテナ上のアプリにAWSサービスへのアクセス権を与えるためのロール。役割としてはEC2におけるインスタンスプロファイルに近い）に、KFHへの書き込み権限も追加しておく。タスク実行ロールの方は、ここでは変えなくても動作する。

先ほど同様、サービスを新たなタスク定義で更新。デプロイが終わったのを確認後、abを流すと、KFHを経由してS3にログが出た。

3. CWL+KFH

3-1. 二股構成について

ここから二股。
普通に考えれば、アプリコンテナに記載するFireLens設定に二つ目の吐き出し先を追加するだけの話に思えるのだが、どうもECSやFargateのlogConfigurationからFireLensへは、一つしか設定のセットを流し込めないっぽい。直接、本家の書式でfluent-bit.confを作って、カスタム設定ファイルとして投入してやる必要があるようだ。
おまけにFargateの場合、設定ファイルをS3から取ってくる構成が現状取れないため、設定ファイルを焼き込んだカスタムfluent-bitイメージを作らないといけない（ECSにはこの制約はない）。

なお、これまではアプリコンテナに諸々設定してきたが、カスタム構成ファイルの場合、投入する先はアプリコンテナのlogConfiguration→Optionsではなく、どうやらFireLensコンテナ（fluent-bit）側のfirelensConfiguration→optionsであるようだ。逆にアプリコンテナ側のOptionsは空のままでよい。
本来、FireLensはアプリコンテナに書いたoptionsを自動的に読み取ってFireLensコンテナ上のfluent-bit.conf（またはfluentd.conf）をよしなに生成してくれる、fluent-bitやfluentdのコンテナ設定は忘れてOK、というところが魅力な気がするのだが、カスタム構成ファイルの場合はもう普通にfluent-bitコンテナにfluent-bitネイティブの設定を食わせてしまえ、ということらしい。

色々言いたいことはあるが、とりあえず公式の記載や先人の経験を参考に、カスタム構成ファイルを作ってみることにする。

※こちらのサイトを参考にさせていただきました。深謝。
FireLens を利用した Fargate タスクのログルーティング
AWS FireLensでfluentbitコンテナをカスタマイズする具体的な方法

3-2. タスク定義の作成

multiple-firelens-targetsという名前で、新たなタスク定義を作成する。

アプリコンテナのlogConfiguration。Nameも含めて、optionsセクションは空にしておく（Nameが残っていると、前回書いた通りエラーになる）。

log_routerコンテナのlogConfiguration。Auto-configureしつつ、ロググループの自動作成のみ手動で追加している。

いったん保存し、手元のターミナルを開く。

3-3. カスタム構成ファイルの作成

extra.confの名前で、これまで設定した二つの設定に相当するOUPUTセクションを持つ、以下のファイルを作成する。
FireLensは、このカスタム構成ファイルを取り込んでfluent-bit.confを生成してくれるようだ。

extra.conf
[OUTPUT]
 Name cloudwatch
 Match *
 region ap-northeast-1
 log_group_name web-firelens-fluent-bit
 log_stream_prefix web
 auto_create_group true

[OUTPUT]
 Name firehose
 Match *
 region ap-northeast-1
 delivery_stream kfh-firelens

なお、タブ区切りではなくスペース区切りが作法のようなので注意。途中まで、以下のようなエラーが多発してプチハマリしていた。

[ Error] Error in line 2: Each key must have a value

また、困った時はfluent-bitをデバッグモードにすると手掛かりが得られる可能性がある（自分は、KFHのストリーム名を微妙に間違えていた・・・）。
ファイル冒頭に以下の設定を入れるだけ。log_routerのCWLログストリームにwarnやdebugが出てくるので、それでデバッグできる。ファクトベースの切り分けをする上で、やっぱりログって大事だと再認識。

extra.conf
[SERVICE]
 Log_Level debug

...

3-4. カスタムlog_routerイメージの作成

ローカルのDocker環境で、FireLensイメージ（AWSカスタムのfluent-bitイメージ）をpullする。

% docker pull amazon/aws-for-fluent-bit

以下のDockerfileをextra.confと同じフォルダに用意し、イメージをbuildする（ここではイメージ名はfirelens-multiple-targetsとしている）。

Dockerfile
FROM amazon/aws-for-fluent-bit
COPY extra.conf /fluent-bit/etc/extra.conf

% docker build -t firelens-multiple-targets

3-5. ECRにカスタムイメージをpush

ECRレポジトリに対し、buildしたカスタムイメージをpushする。
ECRレポジトリの作成とログインは割愛するが、そこの準備ができていれば、あとは色々設定を調整しつつ以下を繰り返すだけ（ここでは、ECRのレポジトリ名をfirelens-ecrとしている。数字はお使いの環境の12桁のAWSアカウント番号）。

% docker build -t firelens-multiple-targets .
% docker tag firelens-multiple-targets:latest 012345678901.dkr.ecr.ap-northeast-1.amazonaws.com/firelens-ecr:latest
% docker push 012345678901.dkr.ecr.ap-northeast-1.amazonaws.com/firelens-ecr:latest

最終的に、012345678901.dkr.ecr.ap-northeast-1.amazonaws.com/firelens-ecr:latestのような形で、カスタムイメージがECRに登録できていればOK。

このあたりで疲労の色が濃くなってくる。
やっぱり、せめてS3から設定ファイル取れるようにして欲しいなあ。。。

3-6. カスタム構成ファイルの指定

カスタムlog_routerイメージのpushが完了したら、ECSに戻って、先ほど保存したタスク定義に新たなリビジョンを作成する。
「JSONによる設定」を開き、imageセクションおよびfirelensConfigurationセクションを修正する（現時点では、これらのセクションはJSONでしか設定できない）。

ここで"config-file-type" : "s3"が使えるようになれば、3-3から3-5の作業は要らなくなるのだが、まあ仕方ない。

3-7. 動確

例によって、サービスから先程作成したリビジョンを選択し、デプロイ。

うまく行っていれば、abで負荷をかければCWLとKFH（S3）の両方にログが出力されるわけだが、

どうやら成功したようだ。

4. CWL+KFH+AES

最後はAESを加えた三つ股。ここまで来ていれば、さほど難しい話ではない。
ちなみに、少し前まではKFHを介して送る必要があったが、FireLensでElasticsearchプラグインがサポートされ、直接出力が可能になっている。
公式のタスク定義例を参考に、OUTPUTの追加を行う。

4-1. AESドメインの作成

まずはログの最後の投げ込み先となるAESドメインを作成する。だいたい10分から15分ほどかかる。
KFH同様、詳細は割愛するが、ほぼテスト用ドメインのデフォルトで作成した。

設定 値
ドメイン名 aes-firelens
タイプ 開発およびテスト
バージョン 7.7(latest)
データノード r5.large.elasticsearch x1、EBS
ネットワーク構成 パブリックアクセス
ドメインアクセスポリシー カスタムアクセスポリシー（アクセス元を現在のIPに制限）

4-2. タスクロールの更新

タスクからAESにもアクセスする必要があるので、タスクロールにAESへの書き込み許可を忘れずに追加しておく。
今回は一時的なテストなので、対象ドメインに対し"es:*"を許可する。

4-3. カスタム構成ファイルの更新

extra.confを三つ股に拡張する。ついでに、先んじてデバッグも有効化しておく。

extra.conf
[SERVICE]
 Log_Level debug

[OUTPUT]
 Name cloudwatch
 Match *
 region ap-northeast-1
 log_group_name web-firelens-fluent-bit
 log_stream_prefix web
 auto_create_group true

[OUTPUT]
 Name firehose
 Match *
 region ap-northeast-1
 delivery_stream kfh-firelens

[OUTPUT]
 Name es
 Match *
 Host search-aes-firelens-[文字列].ap-northeast-1.es.amazonaws.com
 Port 443
 Aws_Auth On
 Aws_Region ap-northeast-1
 tls On

AESのOUTPUT設定は正確には把握していなかったが、公式のlogConfiguration→option内容から大体推測できるのと、fluent-bitのElasticsearch用書式に準拠しているようだったので、そちらも参照しつつ記載した。

4-4. カスタムイメージの作成、ECRへのpush、リビジョンの更新

3-4、3-5、3-6と同様の操作を行う。

4-5. 動確

abでアクセスを発生させてみると、log_routerのシステムログに色々出てくる。fluent-bitという名前でインデックスを作成してくれている模様。

AESドメインを見ると、fluent-bitインデックスに数件のドキュメントが登録されている。_docタイプも、FireLensのスキーマを正確に反映しているようなので、どうやら無事書き込めているらしいことがわかる。

Kibanaでも問題なく可視化できた。

CWL、KFHも同時に出力されており、晴れて三つ股が完成したことになる。

まとめ

思わぬ長編になってしまったことからわかる通り、現状はそれなりに気合いが要求される。
仮にFargateでもS3からカスタム構成ファイルを取れるようになればコンテナのbuild/push回りは随分簡素化されるだろうし、そもそも普通にマネジメントコンソールから複数optionsが投入可能であって欲しいところ。

それでも、従来のCWLに一択に比べればかなり柔軟になったとは感じるし、カスタム構成ファイルを使えばサードパーティー製品への書き込みもできるようなので、あれこれ試行錯誤しただけの甲斐はあった。
あとは、CWLで課題だった「STDOUT出力されたものは何でもかんでも処理されてしまう問題」を解決できそうな正規表現によるフィルタリングに習熟すれば、大抵のログ出力要件には対応できるのではないだろうか。