はじめに
はじめまして！今回は25卒SREの内定者アルバイトとして取り組ませていただいている内容の1つを紹介させていただきます！
EKSのログ基盤としてFluentdからFluent Bitへの移行を計画している方のご参考になれば幸いです！
この記事の内容
- EKS上でのFluent BitのインストールとConfigmapなどの設定方法について
- Fluent Bit自体の監視をDatadogで利用可能にする方法について
背景
まず、Fluentd（Fluent Bit）とはなんぞや？ということですが、ざっくり言うと「アプリケーションログやsyslogなど様々なlogを集約し、任意のサービス（SQS・CloudWatch・Splunkなど）に送信するOSS」です！
引用元: https://fluentbit.io/
FluentdとFluent Bitの違いとは？
公式ドキュメントによると、実はFluent Bitは完全上位互換ではなく双方にメリットがあるらしく、どちらを使うかはユーザのニーズによって選択するみたいです。
Fluentdは大部分がRubyで実装されており、対応プラグインが豊富なことに対して、Fluent Bitは全てC言語で実装されており、軽量でパフォーマンスが優れているという特徴があります。
Fluentdの何が問題でなぜFluent Bitに移行するのか？
これまで稼働していたFluentdはログが欠損したり、OOMKilled、CrashLoopBackOffといった問題を抱えていました。
また、Fluentdのサポートは現在メンテナンスモードで、AWSはこれ以上Fluentdの更新を提供せず、近い将来に廃止する予定であることも明記されています。
以下AWS公式の抜粋です。
Container Insights support for Fluentd is now in maintenance mode, which means that AWS will not provide any further updates for Fluentd and that we are planning to deprecate it in near future. Additionally, the current Fluentd configuration for Container Insights is using an old version of the Fluentd Image fluent/fluentd-kubernetes-daemonset:v1.10.3-debian-cloudwatch-1.0 which does not have the latest improvement and security patches. For the latest Fluentd image supported by the open source community, see fluentd-kubernetes-daemonset.
We strongly recommend that you migrate to use FluentBit with Container Insights whenever possible. Using FluentBit as the log forwarder for Container Insights provides significant performance gains.
他には、Fluent Bitの方がFluentdよりもメモリ使用量が小さいなど様々な理由から、Fluentdの問題を解決するよりも、深く考えずにFluent Bitへ移行してしまった方が早いのではないか？という流れです！
Amazon CloudWatch Observability EKS add-onについて
当初はFluentdからFluent Bitへの移行でEKS add-on化も同時に行うことを計画していました。
Amazon CloudWatch Observability EKS add-onをインストールすると、EKS上でCloudWatchエージェントとFluent Bitエージェントが自動で起動してくれるみたいです。
ただ、以下チーム事情的な理由から導入は断念し、k8sのmanifestでインストールしてDaemonsetを起動することにしました。
- 起動するDaemonsetにnodeAffinityを設定する必要があったが、このadd-onだけそれを設定するオプションがなかった（サポートにも問い合わせましたが、このadd-onだけ存在しないという回答をいただきました）
- CloudWatchの監視コストが非常に高額になっていて、コスト削減のためにほぼ使われていないロググループを調査したところ、CloudWatchエージェントは不要だった
今回は触れないので、詳しくはインストール方法を参考にしてください。
Fluent Bitのインストール方法
Fluent Bitのインストール自体はとても単純です。
HelmChartでもインストールはできると思いますが、今回はQuickStartで公開されているmanifestがあるので、そこからダウンロードしました！
ダウンロードしたmanifestの調整
必要に応じて、不要な部分を削除します。ただし、最低限下記のリソースは残しておかないと動かないと思います。
また、DaemonSetでのenvに設定されているplaceholderも自身の設定に書き換えます
- ServiceAccount
- ClusterRole
- ClusterRoleBinding
- ConfigMap
- DaemonSet（fluent-bitのみ）
IAM Roleを作成してService Accountに関連付け
logを集約してCloudWatchへ送信するためにはCloudWatchAgentServerPolicyというIAMポリシーが必要です。クラスター用のOIDCプロバイダーを作成してAssumeRoleを実行する方法（IRSA）か、「AWS re:Invent 2023」で発表されたEKS Pod Identityを利用して、Service AccountへIAMロールを割り当てるようにします。
以下IRSAでの例です。
IAM Roleの作成（CloudFormation）
IAMRoleFluentBit:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument: !Sub
- '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::${AWS::AccountId}:oidc-provider/${EKSClusterOIDCEndpoint}"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"${EKSClusterOIDCEndpoint}:aud": "sts.amazonaws.com",
"${EKSClusterOIDCEndpoint}:sub": "system:serviceaccount:<NAMESPACE>:fluent-bit-service-account"
}
}
}
]
}'
- EKSClusterOIDCEndpoint: !ImportValue eks-cluster::EKSClusterOidConnectIssure
ManagedPolicyArns:
- arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
RoleName: !Sub fluent-bit
Service Accountの作成
apiVersion: v1
kind: ServiceAccount
metadata:
name: fluent-bit-service-account
namespace: <NAMESPACE>
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/fluent-bit
ConfigMapの移行
次にFluentdで用いていたConfigMapをFluent Bitに移行していきます。若干書き方が変わっていますが、本質的にやっていることは変わりません。以下ConfigMapの移行例です。
FluentdのConfigMap
fluent.conf: |
@include containers.conf
@include systemd.conf
@include host.conf
<match fluent.**>
@type null
</match>
containers.conf: |
<source>
@type tail
@id in_tail_container_logs
@label @containers
path /var/log/containers/*.log
exclude_path ["/var/log/containers/cloudwatch-agent*", "/var/log/containers/fluentd*"]
pos_file /var/log/fluentd-containers.log.pos
tag *
read_from_head true
<parse>
@type cri
time_format %Y-%m-%dT%H:%M:%S.%NZ
</parse>
</source>
<label @NORMAL>
<match **>
@type cloudwatch_logs
@id out_cloudwatch_logs_containers
region "#{ENV.fetch('REGION')}"
log_group_name "/aws/containerinsights/#{ENV.fetch('CLUSTER_NAME')}/application"
log_stream_name_key stream_name
remove_log_stream_name_key true
auto_create_stream true
<buffer>
flush_interval 5
chunk_limit_size 2m
queued_chunks_limit_size 32
retry_forever true
flush_thread_count 8
</buffer>
</match>
</label>
Fluent BitのConfigMap
fluent-bit.conf: |
[SERVICE]
Flush 5
Grace 30
Log_Level info
Daemon off
Parsers_File parsers.conf
storage.path /var/fluent-bit/state/flb-storage/
storage.sync normal
storage.checksum off
storage.backlog.mem_limit 5M
@INCLUDE application-log.conf
@INCLUDE dataplane-log.conf
@INCLUDE host-log.conf
application-log.conf: |
[INPUT]
Name tail
Tag application.*
Path /var/log/containers/*.log
Exclude_Path /var/log/containers/cloudwatch-agent*, /var/log/containers/fluent-bit*
multiline.parser docker, cri
DB /var/fluent-bit/state/flb_container.db
Mem_Buf_Limit 50MB
Skip_Long_Lines On
Refresh_Interval 10
Rotate_Wait 30
storage.type filesystem
Read_from_Head ${READ_FROM_HEAD}
[FILTER]
Name kubernetes
Match application.*
Kube_URL https://kubernetes.default.svc:443
Kube_Tag_Prefix application.var.log.containers.
Merge_Log On
Merge_Log_Key log_processed
K8S-Logging.Parser On
K8S-Logging.Exclude Off
Labels Off
Annotations Off
Use_Kubelet On
Kubelet_Port 10250
Buffer_Size 0
[OUTPUT]
Name cloudwatch_logs
Match application.*
region ${AWS_REGION}
log_group_name /aws/containerinsights/${CLUSTER_NAME}/application
log_stream_prefix ${HOST_NAME}-
auto_create_group true
extra_user_agent container-insights
また、このままではアプリケーション部分のlogがただの文字列として出力されてしまうので、parsers.confに以下の設定を追記して、[INPUT]のparserを追記したcriに書き換えます。（QuickStartのmanifestはdockerという名前も指定されmultiline.parserになっていますが、そのdockerを削除します）
[PARSER]
Name cri
Format regex
Regex ^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<logtag>[^ ]*) (?<log>.*)$
Time_Key time
Time_Format %Y-%m-%dT%H:%M:%S.%L%z
さらに、CloudWatch Logsでメトリクスフィルターを利用しているなどの関係でFluentdとフォーマットを統一したいときは、以下のフィルタを設定します。
[FILTER]
Name modify
Match application.*
Rename _p logtag
Rename log message
kustomizeのConfigMapGeneratorを利用
現状はk8sのmanifestをapplyすることで、ConfigMapも同時に変更が加えられDaemonSetを再起動する必要がありましたが、ConfigMapだけ変更する場合本番環境でこれが起きてしまうのは好ましくありません。
そこで、kustomizeのConfigMapGeneratorを使ってConfigMapを動的に生成することができます。
以下のようにディレクトリを構成します！
ディレクトリ構成例
fluent-bit/
├── config/
│ ├── application-log.conf
│ └── dataplane-log.conf
│ └── fluent-bit.conf
│ └── host-log.conf
│ └── parsers.conf
└── fluent-bit.yaml
└── kustomization.yaml
また、kustomization.yamlに以下の内容を追記します。
kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: <NAMESPACE>
resources:
- fluent-bit.yaml
configMapGenerator:
- name: fluent-bit-config
files:
- config/fluent-bit.conf
- config/application-log.conf
- config/parsers.conf
- config/dataplane-log.conf
- config/host-log.conf
これでKubernetesのマニフェストを柔軟に管理できるかつ、ConfigMapの変更をすぐ反映できるようになりました！
結果
欠損しまくっていたlogが正しく送信できるようになり、リソースの消費量も激減しました 🎉
- Fluentd
- Fluent Bit
※FluentdとFluent Bitが別Nodeに両立しているときのデータであり、載っているPodなど条件が全く異なる比較なので参考程度でお願いします。一応公式だと1/60のメモリ消費量だと言われています。
Fluent Bit自体の監視を導入
Fluent Bitを導入し終えたところですが、そもそもこのFluent Bitが正しくlogを送れているかも監視する必要がありそうです。（監視の監視）
そのため、Fluent BitのメトリクスをDatadogに送信する方法について今から紹介させていただきます！
基本的に公式ドキュメントの手順に従いますが、Datadogとのインテグレーション面で情報が足りていなかったので、そこを補足しながら説明します！
Fluent Bitのメトリクスを公開
まず、Fluent BitのHTTP Serverを有効にして、メトリクスを公開します。
以下の3行をapplication.confの[SEVICE]に追記します。
HTTP_Server On
HTTP_Listen 0.0.0.0
HTTP_Port 2020
fluent-bitのannotationにopenmetricsとして設定
https://docs.datadoghq.com/containers/kubernetes/prometheus/?tab=kubernetesadv2
↑を参考にfluent-bitのDaemonsetにannotationsを適用します
ad.datadoghq.com/fluent-bit.checks: |
{
"openmetrics": {
"init_config": {},
"instances": [
{
"openmetrics_endpoint": "http://%%host%%:2020/api/v1/metrics/prometheus",
"namespace": "fluentbit",
"metrics": [
".*"
]
}
]
}
}
metricsは全て取るように設定していますが、必要なメトリクスに絞ることもできます。また、ここで指定するnamespaceはDatadogのmetricsではprefixの役割をします。
（例えば、fluentbit_input_bytes_totalというメトリクスはDatadog上で、fluentbit.fluentbit_input_bytes.countと表示されます）
また、Datadog Agentがメトリクスにアクセスできるように、Daemonsetの設定で2020番ポートを解放する必要があります。
ports:
- containerPort: 2020
protocol: TCP
name: metrics
これで、Fluent BitのメトリクスがDatadogへ送信できるようになりました！
AlertやDashBoardの実装
メトリクスがDatadogへ送れるようになったところで、実際の運用についても少しだけ紹介させていただきます！
- そもそも正常に動いていてエラーが最小限に抑えられているか？
- 入力から出力へのlogが正しく送信できているか？
を監視する必要がありそうで、特に2つ目に関してはlogの収集（input）や転送（output）などpipelineで監視しておいた方が良いでしょう。
まず、異常系監視で使えそうなメトリクスは以下です。
| メトリクス名 | 説明 |
|---|---|
| fluentbit_output_errors_total | エラーが発生したチャンクの数 |
| fluentbit_output_dropped_records_total | 出力によってドロップされたlog数 |
これは、多発すると対応が必要になってくると思うので、Alertを作成する必要がありそうです。以下のクエリでAlertを作成してみました。
sum(last_5m):sum:fluentbit.fluentbit_output_errors.count{kube_cluster_name:<CLUSTER_NAME>} by {kube_node}.as_count() > 10
閾値は試験的なので今後の様子次第です。エラーはチャンク数なのに対して、ドロップはlog数なので注意する必要があります。
次に正常系監視で使えそうなメトリクスは以下です。
| メトリクス名 | 説明 |
|---|---|
| fluentbit_input_records_total | 入力層取り込んだlogの数 |
| fluentbit_filter_records_total | フィルタ層が取り込んだlogの数 |
| fluentbit_filter_drop_records_total | フィルタ層で設定した条件でドロップしたlogの数 |
| fluentbit_output_proc_records_total | 出力層が正常に送信したlogの数 |
pipelineのlog量を監視することによって、明らかにlogが少ないDaemonsetや、logが何らかの原因で送信できていない場合、どこの層が原因かを分析することができます。
あとは単純に負荷分析とかにも使えると思います。
しかし、Daemonsetごとの監視にしてしまうとlog量にかなり差があり、Alertの閾値を決め打ちすることが難しかったのでAlertは諦めてDashBoardを作成することにしました。
他にはメモリやバッファのリソース量が最適化どうかを監視するためにBuffering関係のメトリクスを利用する必要もありそうです。
また、kubernetesのメトリクスを用いてCPU使用率やメモリ使用率なども監視しリソース最適化に活用することもできます。
（余談です）
監視してみたところFluent Bitでメモリリークが発生していることが発覚したのですが、なぜか95%付近まで上がると、一旦下がってクラッシュはしない仕様になっていました。余力があったらこれも調査してみたいです。KarpenterによってNodeが入れ替わったり、Daemonsetに更新が入ることでこれは解決されますが...
まとめ
今回はFluentd CloudWatchからFluent Bitへの移行および、Fluent Bitの監視について紹介させていただきました！
Alertの閾値最適化やDaemonsetのリソースチューニングなどが今後の課題になってきそうです。
また、今回Fluent Bitのversionは1.9でインストールしましたが、PublicなECRリポジトリの最新がこれしかなかったです。（最新は3.1）
また、1.9と3.1ではメトリクスのエンドポイントと、取れるメトリクスが大きく変わるので今後対応が必要そうです。