先來介紹 logs 收集的 ELK，EFK。額外還有 Filebeat，Loki，有空再額外多做說明

ELK 架構
傳統架構上比較成熟的 log 收集為 ELK（Elasticsearch + Logstash + Kibana）Logstash 負責收集，輸出到 Elasticsearch，最後用 Kibana 進行顯示。但缺點是 Logstash 佔用資源大，語法複雜

EFK 架構
相較於 Logstash 的“重”且稍微複雜的配置，EFK 作為一個新的日誌收集解決方案，提供了更簡單的選擇。在這個方案中，Fluentd 替代了 ELK 中的 Logstash，以“一鍋端”的方式將部分日誌文件直接導入 Elasticsearch，然後利用 Kibana 呈現。

優點與不足之處
Fluentd 的主要優勢是低資源消耗和簡單語法。但也因此必須犧牲一些東西。例如，Fluentd 只能收集控制台日誌（使用 logs 命令查詢的日誌），不能收集非控制台日誌，因此無法完全滿足生產環境的需求。大多數未遵循雲原生開發理念的程序都會生成許多日誌文件，這使得容器內日誌難以收集。除非為每個 Pod 添加一個 Sidecar 並利用 tail -f 將日誌文件轉換為控制台日誌，否則操作起來非常麻煩。

此外，將 Elasticsearch 集群部署在 Kubernetes 集群中以存儲日誌並不推薦，因為這樣會浪費大量 Kubernetes 集群資源。因此，通常我們會選擇通過 Fluentd 將日誌收集到外部的 Elasticsearch 集群中。

在依賴 Elasticsearch 的情況下，維護難度和資源使用相對較高。

而我們使用的 fluent bit 他跟 fluentD 差別在於 fluent bit 是一種更輕量的數據收集和傳送的服務

Fluent Bit is a fast Log Processor and Forwarder for Linux, Embedded Linux, MacOS and BSD family operating systems.

Fluentd is an open source data collector for unified logging layer.

在我們的架構上是先讓 fluent-bit 接到 cloudwatch 內:

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html

resource "helm_release" "aws_cloudwatch_logs_for_fluent_bit" {
  name       = "aws-cloudwatch-logs"
  repository = "https://aws.github.io/eks-charts"
  chart      = "aws-for-fluent-bit"
  set {
    name  = "cloudWatch.region"
    value = var.region
  }
  set {
    name  = "cloudWatch.logGroupName"
    value = "/aws/app"
  }
  set {
    name  = "firehose.enabled"
    value = "false"
  }
  set {
    name  = "kinesis.enabled"
    value = "false"
  }
  set {
    name  = "elasticsearch.enabled"
    value = "false"
  }
}