로그 시작하기

개요

Datadog 로그 관리(또는 로그)를 사용하여 서버, 컨테이너, 클라우드 환경, 애플리케이션, 기존 로그 프로세서 및 포워더 등 여러 로깅 소스에서 로그를 수집할 수 있습니다. 기존 로깅에서는 비용 효율을 유지하기 위해 분석하고 유지할 로그를 따로 선정해야 했습니다. Datadog 제한없는 로그 수집(Logging without Limits*)을 이용하면 로그 수집, 프로세싱, 아카이브, 탐색, 모니터링을 로그 제한 없이 수행할 수 있습니다.

이번 페이지에서는 Datadog로 로그 관리를 시작하는 방법을 알려드리겠습니다. 계정이 아직 없다면 Datadog 계정을 만들어주세요.

로깅 소스 설정

로그 관리에서는 로그 익스플로러에서 데이터를 분석하고 탐색하거나 트레이싱메트릭을 연동하여 Datadog 전체에서 유용한 데이터를 연결하거나 가져온 로그를 Datadog Cloud SIEM에서 사용할 수 있습니다. Datadog 내 로그의 라이프사이클은 로깅 소스에서 로그를 가져오는 단계부터 시작합니다.

다양한 로그 설정 유형

서버

서버에서 Datadog으로 로그를 전달하는 데 사용할 수 있는 몇 가지 통합이 있습니다. 통합은 Agent의 설정 디렉터리 루트에서 conf.d/ 폴더 내 conf.yaml 파일에 있는 로그 설정 블록을 사용하여 서버에서 Datadog으로 로그를 전달합니다.

logs:
  - type: file
    path: /path/to/your/integration/access.log
    source: integration_name
    service: integration_name
    sourcecategory: http_web_access

서버에서 로그 수집을 시작하는 방법은 다음과 같습니다.

  1. Datadog Agent가 준비되지 않았다면 플랫폼에 Agent를 설치하세요.

    참조: 로그를 수집하려면 Datadog Agent v6 이상의 버전이 필요합니다.

  2. Datadog Agent의 기본 설정에서는 로그 수집이 활성화되지 않은 상태입니다. 로그 수집을 활성화하려면 datadog.yaml 파일에서 logs_enabledtrue로 설정하세요.

    datadog.yaml

    ## @param logs_enabled - boolean - optional - default: false
        ## @env DD_LOGS_ENABLED - boolean - optional - default: false
        ## Enable Datadog Agent log collection by setting logs_enabled to true.
        logs_enabled: false
        
        ## @param logs_config - custom object - optional
        ## Enter specific configurations for your Log collection.
        ## Uncomment this parameter and the one below to enable them.
        ## See https://docs.datadoghq.com/agent/logs/
        logs_config:
        
          ## @param container_collect_all - boolean - optional - default: false
          ## @env DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL - boolean - optional - default: false
          ## Enable container log collection for all the containers (see ac_exclude to filter out containers)
          container_collect_all: false
        
          ## @param logs_dd_url - string - optional
          ## @env DD_LOGS_CONFIG_LOGS_DD_URL - string - optional
          ## Define the endpoint and port to hit when using a proxy for logs. The logs are forwarded in TCP
          ## therefore the proxy must be able to handle TCP connections.
          logs_dd_url: <ENDPOINT>:<PORT>
        
          ## @param logs_no_ssl - boolean - optional - default: false
          ## @env DD_LOGS_CONFIG_LOGS_NO_SSL - optional - default: false
          ## Disable the SSL encryption. This parameter should only be used when logs are
          ## forwarded locally to a proxy. It is highly recommended to then handle the SSL encryption
          ## on the proxy side.
          logs_no_ssl: false
        
          ## @param processing_rules - list of custom objects - optional
          ## @env DD_LOGS_CONFIG_PROCESSING_RULES - list of custom objects - optional
          ## Global processing rules that are applied to all logs. The available rules are
          ## "exclude_at_match", "include_at_match" and "mask_sequences". More information in Datadog documentation:
          ## https://docs.datadoghq.com/agent/logs/advanced_log_collection/#global-processing-rules
          processing_rules:
            - type: <RULE_TYPE>
              name: <RULE_NAME>
              pattern: <RULE_PATTERN>
        
          ## @param force_use_http - boolean - optional - default: false
          ## @env DD_LOGS_CONFIG_FORCE_USE_HTTP - boolean - optional - default: false
          ## By default, the Agent sends logs in HTTPS batches to port 443 if HTTPS connectivity can
          ## be established at Agent startup, and falls back to TCP otherwise. Set this parameter to `true` to
          ## always send logs with HTTPS (recommended).
          ## Warning: force_use_http means HTTP over TCP, not HTTP over HTTPS. Please use logs_no_ssl for HTTP over HTTPS.
          force_use_http: true
        
          ## @param force_use_tcp - boolean - optional - default: false
          ## @env DD_LOGS_CONFIG_FORCE_USE_TCP - boolean - optional - default: false
          ## By default, logs are sent through HTTPS if possible, set this parameter
          ## to `true` to always send logs via TCP. If `force_use_http` is set to `true`, this parameter
          ## is ignored.
          force_use_tcp: true
        
          ## @param use_compression - boolean - optional - default: true
          ## @env DD_LOGS_CONFIG_USE_COMPRESSION - boolean - optional - default: true
          ## This parameter is available when sending logs with HTTPS. If enabled, the Agent
          ## compresses logs before sending them.
          use_compression: true
        
          ## @param compression_level - integer - optional - default: 6
          ## @env DD_LOGS_CONFIG_COMPRESSION_LEVEL - boolean - optional - default: false
          ## The compression_level parameter accepts values from 0 (no compression)
          ## to 9 (maximum compression but higher resource usage). Only takes effect if
          ## `use_compression` is set to `true`.
          compression_level: 6
        
          ## @param batch_wait - integer - optional - default: 5
          ## @env DD_LOGS_CONFIG_BATCH_WAIT - integer - optional - default: 5
          ## The maximum time (in seconds) the Datadog Agent waits to fill each batch of logs before sending.
          batch_wait: 5
        
          ## @param open_files_limit - integer - optional - default: 500
          ## @env DD_LOGS_CONFIG_OPEN_FILES_LIMIT - integer - optional - default: 500
          ## The maximum number of files that can be tailed in parallel.
          ## Note: the default for Mac OS is 200. The default for
          ## all other systems is 500.
          open_files_limit: 500
        
          ## @param file_wildcard_selection_mode - string - optional - default: `by_name`
          ## @env DD_LOGS_CONFIG_FILE_WILDCARD_SELECTION_MODE - string - optional - default: `by_name`
          ## The strategy used to prioritize wildcard matches if they exceed the open file limit.
          ##
          ## Choices are `by_name` and `by_modification_time`.
          ##
          ## `by_name` means that each log source is considered and the matching files are ordered
          ## in reverse name order. While there are less than `logs_config.open_files_limit` files
          ## being tailed, this process repeats, collecting from each configured source.
          ##
          ## `by_modification_time` takes all log sources and first adds any log sources that
          ## point to a specific file. Next, it finds matches for all wildcard sources.
          ## This resulting list is ordered by which files have been most recently modified
          ## and the top `logs_config.open_files_limit` most recently modified files are
          ## chosen for tailing.
          ##
          ## WARNING: `by_modification_time` is less performant than `by_name` and will trigger
          ## more disk I/O at the configured wildcard log paths.
          file_wildcard_selection_mode: by_name
        
          ## @param max_message_size_bytes - integer - optional - default: 256000
          ## @env DD_LOGS_CONFIG_MAX_MESSAGE_SIZE_BYTES - integer - optional - default : 256000
          ## The maximum size of single log message in bytes. If maxMessageSizeBytes exceeds
          ## the documented API limit of 1MB - any payloads larger than 1MB will be dropped by the intake.
          https://docs.datadoghq.com/api/latest/logs/
          max_message_size_bytes: 256000
        
          ## @param integrations_logs_files_max_size - integer - optional - default: 10
          ## @env DD_LOGS_CONFIG_INTEGRATIONS_LOGS_FILES_MAX_SIZE - integer - optional - default: 10
          ## The max size in MB that an integration logs file is allowed to use
          integrations_logs_files_max_size
        
          ## @param integrations_logs_total_usage - integer - optional - default: 100
          ## @env DD_LOGS_CONFIG_INTEGRATIONS_LOGS_TOTAL_USAGE - integer - optional - default: 100
          ## The total combined usage all integrations logs files can use
          integrations_logs_total_usage
  3. Datadog Agent를 재시작합니다.

  4. 통합 활성화 절차를 따르거나, Datadog 사이트의 커스텀 파일 로그 수집 절차를 따라 진행합니다.

    참조: 커스텀 파일에서 로그를 수집하고 있으며 파일, TCP/UDP, journald, 또는 윈도우즈 이벤트(Windows Events)를 테일링(tailing)하는 예시가 필요한 경우 커스텀 로그 수집을 참조하세요.

컨테이너

Datadog Agent v6 기준으로, Agent는 컨테이너에서 로그를 수집할 수 있습니다. 컨테이너화 서비스마다 Agent 배포 또는 실행 위치, 로그 라우팅 방법에 따라 구체적인 설정법을 안내하니 참조하시기 바랍니다.

예를 들어 도커(Docker)는 두 가지 유형의 Agent 설치가 가능합니다. 호스트에서 Agent를 도커 환경 외부에 설치하는 방법, 또는 컨테이너화된 버전의 Agent를 도커 환경 내부에 배포하는 방법이 있습니다.

쿠버네티스(Kubernetes)의 경우에는 Datadog Agent를 쿠버네티스 클러스터 내부에서 실행해야 합니다. 로그 수집은 DaemonSet 스펙, Helm 차트, 또는 Datadog Operator를 사용하여 설정할 수 있습니다.

컨테이너 서비스에서 로그를 수집하려면 앱 내 안내를 따라주세요.

클라우드

AWS, Azure, Google Cloud 등 여러 클라우드 제공업체의 로그를 Datadog으로 전달할 수 있습니다. 각 클라우드 제공업체에는 고유한 구성 지침이 있습니다.

예를 들어 AWS 서비스 로그는 주로 S3 버켓이나 클라우드와치(CloudWatch) 로그 그룹에 저장되는 경우가 많습니다. 이러한 로그를 구독하고 Amazon Kinesis 스트림으로 전송한 다음, 하나 이상의 대상으로 또 전송할 수 있습니다. Datadog는 Amazon Kinesis Delivery 스트림에 기본으로 설정된 전송 대상 중 하나입니다.

클라우드 서비스에서 로그를 수집하려면 앱 내 안내를 따라주세요.

클라이언트

Datadog는 클라우드에서 SDK나 라이브러리를 통한 로그 수집을 허용합니다. 예를 들어 datadog-logs SDK를 사용해 자바스크립트(Javascript) 클라이언트에서 Datadog로 로그를 보낼 수 있습니다.

클라이언트에서 로그 수집을 시작하려면 앱 내 지침을 따르세요.

기타

기존 로깅 서비스나 유틸리티(Rsyslog, FluentD, 로그스태시(Logstash) 등)를 사용 중이라면 Datadog에서 플러그인과 로그 전송 옵션을 지원합니다.

통합을 찾을 수 없다면 other integrations 상자에 입력하고, 통합을 이용할 수 있을 때 알림을 받아보세요.

클라우드 서비스에서 로그를 수집하려면 앱 내 안내를 따라주세요.

로그 탐색하기

로깅 소스를 설정하면 로그를 로그 익스플로러에서 살펴볼 수 있습니다. 익스플로러를 이용하면 로그를 필터링, 집계, 시각화할 수 있습니다.

예를 들어 추가로 조사하려는 서비스에서 로그가 유입되는 경우 service로 필터링합니다. 추가로 ERROR와 같은 status를 기준으로 필터링하고 Group into Patterns를 선택하여 서비스의 어느 부분에서 가장 많은 오류가 기록되는지 확인할 수 있습니다.

오류 패턴 기준으로 Log Explorer에서 필터링

가장 상위의 로깅 서비스를 보려면 로그를 Fields로 집계하고 Top List로 시각화하세요. info 또는 warn 등의 소스를 선택하고 드롭다운 메뉴에서 View Logs를 선택합니다. 사이드 패널에는 오류에 따라 로그가 채워지므로 주의가 필요한 호스트와 서비스를 빠르게 확인할 수 있습니다.

Log Explorer에서의 상위 목록

다음 단계

로깅 소스를 설정한 후에는 로그 익스플로러에서 로그를 살펴볼 수 있습니다. 또, 로그 관리의 다른 영역 역시 탐색할 수 있습니다.

로그 설정

로그의 상관관계

가이드

추가 읽기


*제한없는 로그 수집(Logging without Limits™)은 Datadog, Inc.의 상표입니다.