ECS Fargate Datadog 연결

Kubernetes Pod은 같은 Pod안에 있는 컨테이너들은 다 같은 localhost안에 존재하는 것이다. 이는 ECS에도 똑같이 Task안에 있으면 같은 로컬호스트로 묶인다는 뜻이다!
즉 Datadog agent도 같은 로컬호스트에서 로그를 collect해야한다는 뜻이다

Kubernetes의 Log Collection방식은
https://kubernetes.io/docs/concepts/cluster-administration/logging/

다음의 홈페이지를 보면 알수 있는데 여기에서는 세가지의 방식이 소개가 된다

Cluster-level logging architectures

1. Using a node logging agent
   각 노드에다가 node-level logging agent를 두어 로깅하는 방식이다
   이 agent는 log를 노출하고 백엔드로 로그를 푸쉬하는 역할을 수행한다
   보통 로그 에이젼트는 로그 파일이 있는 디렉토리에 접근권한이 있는 컨테이너이다.
   각 노드에 띄어져 있어야함으로 DaemonSet방식으로 띄워져 있어야 한다
   컨테이너는 stdout, stderr에 로그를 적으면 agent가 모아서 forwarding한다

DaemonSet?

클러스터 내의 모든 노드(또는 특정 노드)에 동일한 Pod를 실행시키기 위한 Kubernetes 리소스
Example) 로그 수집기, 모니터링 에이전트, 네트워크 정책 관리자 같은 노드별로 실행되어야 하는 애플리케이션을 배포하는 데 사용

2. Using Sidecar Container with the logging agent

• 사이드카 컨테이너는 메인 애플리케이션 컨테이너와 함께 Pod 내에서 실행되는 보조 컨테이너
• 사이드카 컨테이너가 애플리케이션 로그를 읽고 이를 자신의 stdout이나 stderr로 출력합니다.
• 메인 애플리케이션 컨테이너가 로그를 파일이나 소켓에 쓰면, 사이드카 컨테이너가 이 로그를 읽어서 처리합니다.
• 로그가 사이드카 컨테이너의 stdout/stderr로 출력되기 때문에, Kubernetes의 kubelet이 이를 자동으로 수집하고 로그 에이전트를 통해 중앙 로그 시스템으로 전달할 수 있습니다.
• 사이드카 컨테이너에 로그 수집 에이전트(예: Fluentd, Logstash)를 실행하여 애플리케이션 컨테이너에서 발생하는 로그를 수집하고 처리합니다.
• 이 방법은 로그 수집 에이전트가 로그를 다양한 형식으로 처리하고 중앙 로그 시스템으로 포워딩하는 데 유용합니다.

1번과 2번 방식의 차이점

1. Node-level Logging Agent

   1. 각 노드에 DaemonSet으로 배포되는 로깅 에이전트를 사용하여 로그를 수집합니다. 이 에이전트는 노드에서 실행 중인 모든 컨테이너의 로그를 수집하여 중앙화된 로그 시스템으로 전달합니다.
   • 장점: 노드 수준에서 중앙 집중식 로그 수집을 쉽게 관리할 수 있으며, 새로운 애플리케이션이 추가될 때 별도의 로그 설정이 필요하지 않습니다.
   • 단점: 로그 형식이 다양하거나 애플리케이션이 다양한 방식으로 로그를 기록하는 경우 유연성이 부족할 수 있으며, 노드 자원에 부하가 있을 수 있습니다.
   • 유스케이스: 환경이 비교적 균일하고, 모든 노드에서 동일한 로깅 메커니즘을 사용하기에 적합합니다.

2. Sidecar Container with Logging Agent:

   • 개요: 메인 애플리케이션 컨테이너와 함께 사이드카 컨테이너를 사용하여 각 애플리케이션의 로그를 개별적으로 처리합니다. 이 방식은 애플리케이션이 표준 출력으로 로그를 기록하지 않는 경우 유용합니다.
   • 장점: 로그 스트림을 분리하여 처리할 수 있으며, 애플리케이션 코드에 변경 없이 다양한 로그 포맷을 처리할 수 있습니다.
   • 단점: 추가적인 컨테이너를 실행해야 하므로 약간의 오버헤드가 발생하며, 설정이 복잡할 수 있습니다.
   • 유스케이스: 다양한 로그 형식이나 여러 로그 파일을 사용하는 복잡한 애플리케이션, 또는 stdout/stderr에 로그를 기록할 수 없는 레거시 애플리케이션에 적합합니다.

3. Sidecar container with a logging agent

• node-level logging agent 가 상황에 맞지 않을때, 유연하지 않을때 사이드카 컨테이너가 내 어플리케이션과 함께 run 하게 하면 된다

4. Exposing logs directly from the applicatioin

• push logs directly from application

로깅 방식	장점	단점	유스케이스
노드 수준 로깅 에이전트	중앙 집중식 로그 수집, 관리 용이, DaemonSet을 통한 일관된 배포	다양한 로그 형식 처리에 유연성 부족, 노드 자원에 부하 발생 가능	모든 노드에 표준화된 로깅이 필요한 경우, 균일한 환경에 적합
사이드카 컨테이너와 로깅 에이전트	유연한 로그 관리, 로그 스트림 분리, 애플리케이션 코드 변경 최소화	추가 컨테이너 오버헤드, 복잡한 설정	여러 로그 형식이나 레거시 애플리케이션에서 stdout/stderr에 로그를 기록하지 않는 복잡한 애플리케이션에 적합
커스텀 로깅 로직을 가진 사이드카 컨테이너	애플리케이션별 맞춤형 로그 처리 가능, 다양한 로그 포맷 환경에 유용	여러 사이드카 컨테이너로 인한 자원 사용 증가	특정 로그 처리나 라우팅 로직이 필요한 애플리케이션
애플리케이션에서 직접 로그 노출	로그 형식과 목적지에 대한 직접 제어, 추가 컨테이너 불필요	로그를 위해 애플리케이션 수정 필요, 중앙 집중 관리가 어려움	애플리케이션 코드를 수정하여 로그를 처리할 수 있는 간단한 애플리케이션, 외부 로깅 서비스와의 직접 통합이 필요한 경우

ECS 는 Fargate방식이고 stdout을 읽어오와서 로그 순환이 어렵다. 고로 3번방법을 이용하여 Datadog로 데이터를 보내 모니터링하는 방식을 사용하였다

https://docs.datadoghq.com/containers/amazon_ecs/logs/

다음의 document를 참조하였습니다. 먼저 테라폼 코드를 보며 구성을 생각해 보겠습니다.

// ECS Task Definition 생성
resource "aws_ecs_task_definition" "singsong_ecs_task_definition" {
  family                   = "{family_name}"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "1024"
  memory                   = "2048"
  execution_role_arn       = aws_iam_role.ecs_task_execution_role.arn
  container_definitions    = jsonencode([
    {
      name      = "{container_name}"
      image     = "${aws_ecr_repository.{repo_name}.repository_url}:latest"
      essential = true
      portMappings = [
        {
          containerPort = 8080
          hostPort      = 8080
        }
      ]
      logConfiguration = {
        logDriver = "awsfirelens"
        options = {
          Name           = "datadog"
          dd_message_key = "log"
          apikey         = var.datadog_api_key
          dd_service     = "{service_name}"
          dd_source      = "httpd"
          dd_tags        = "env:prod"
          provider       = "ecs"
		  Host           = "{host_url}"
          TLS            = "on"
        }
      }
    },
    {
      name      = "log-router"
      image     = "amazon/aws-for-fluent-bit:latest"
      essential = true
      firelensConfiguration = {
        type = "fluentbit"
        options = {
          "enable-ecs-log-metadata" = "true"
        }
      }
    },
    {
      name      = "datadog-agent"
      image     = "public.ecr.aws/datadog/agent:latest"
      essential = true
      environment = [
        {
          name  = "DD_API_KEY"
          value = var.datadog_api_key
        },
        {
          name  = "DD_SITE"
          value = var.datadog_url
        },
        {
          name  = "ECS_FARGATE"
          value = "true"
        },
      ],
      healthCheck = {
        command     = ["CMD-SHELL", "/probe.sh"]
        interval    = 30
        timeout     = 5
        retries     = 2
        startPeriod = 60
      }
    }
  ])
}

전체적인 컨테이너들에 대해서 설명을 해보자면

1. singsong-container:
   • 이 컨테이너는 로그를 awsfirelens라는 로그 드라이버를 사용하여 전송합니다.
   • awsfirelens는 FireLens라는 AWS의 로그 수집 및 전송 솔루션입니다. FireLens는 컨테이너 로그를 수집하여 다른 시스템(예: Datadog)으로 전송하는 데 사용됩니다.
   • logConfiguration 옵션에서 awsfirelens 드라이버를 설정하고, 로그를 Datadog으로 전송하기 위한 옵션을 지정합니다.
2. log-router:
   • 이 컨테이너는 amazon/aws-for-fluent-bit:latest 이미지를 사용하여 실행됩니다.
   • FireLens의 기능을 통해 Fluent Bit를 사용하여 로그를 수집하고 라우팅합니다.
   • Fluent Bit를 실행하여 로그를 수집하고 처리합니다. 여기서 설정된 옵션에 따라 로그는 Datadog으로 포워딩됩니다.
3. datadog-agent:
   • Datadog과 직접 통신하며, 로그와 메트릭을 Datadog 플랫폼으로 전송

즉 singsong-container에서 aws firelens + fluent bit을 통해 데이터를 수집하고 그런다음 바로 datadog으로 direct로 보내는 방식인것입니다.

이런 느낌으로 작동한다는 것입니다!

그래서 다음과 같이 구성을 하였고

이렇게 로그를 잘 수집하는 것을 알 수 있습니다

또한 Datadog agent를 통해서도 Metric 정보를 수집하여

이렇게 잘 가져오는 것을 확인할 수 있습니다!