자체 호스팅 MariaDB용 Database Monitoring 설정하기

이 페이지에서는 자체 호스팅 MariaDB 데이터베이스에 Database Monitoring을 설정하는 방법을 설명드릴게요. Database Monitoring은 쿼리 메트릭, 쿼리 샘플, explain plan, 연결 데이터, 시스템 메트릭, InnoDB 스토리지 엔진 원격 측정 등을 노출해 MariaDB 데이터베이스에 대한 깊은 가시성을 제공합니다.

에이전트는 읽기 전용 사용자로 로그인해 데이터베이스에서 직접 원격 측정을 수집해요. MariaDB 데이터베이스에 Database Monitoring을 활성화하려면 다음 단계를 따르세요.

1. 데이터베이스 파라미터 구성하기
2. 에이전트에 데이터베이스 액세스 권한 부여하기
3. 에이전트 설치하기

출처: 문서

본문

시작하기 전에 (Before you begin)

• 지원되는 MariaDB 버전: 10.5, 10.6, 10.11 또는 11.4. MariaDB용 Database Monitoring은 알려진 제한 사항과 함께 지원됩니다.
• 지원되는 Agent 버전: 7.61.0+
• 성능 영향: Database Monitoring의 기본 Agent 구성은 보수적이지만, 수집 간격이나 쿼리 샘플링 비율 같은 설정을 필요에 맞게 조정할 수 있어요. 대부분의 워크로드에서 에이전트는 데이터베이스 쿼리 실행 시간의 1% 미만, CPU의 1% 미만을 차지합니다. Database Monitoring은 기본 Agent 위에서 통합으로 실행돼요 (벤치마크 참고).
• 프록시, 로드 밸런서, 커넥션 풀러: Datadog Agent는 모니터링 대상 호스트에 직접 연결해야 해요. 자체 호스팅 데이터베이스의 경우 127.0.0.1이나 소켓이 선호됩니다. 에이전트는 프록시, 로드 밸런서, 커넥션 풀러를 통해 데이터베이스에 연결하면 안 돼요. 에이전트가 실행 중에 다른 호스트에 연결하면(장애 조치, 로드 밸런싱 등의 경우) 에이전트는 두 호스트 사이의 통계 차이를 계산해 부정확한 메트릭을 만들어내요.
• 데이터 보안 고려 사항: 에이전트가 데이터베이스에서 수집하는 데이터와 이를 안전하게 유지하는 방법은 민감 정보 (Sensitive information) 문서를 참고하세요.

MariaDB 설정 구성하기

쿼리 메트릭, 샘플, explain plan을 수집하려면 MariaDB performance schema를 활성화하고 커맨드 라인이나 설정 파일(예: mysql.conf)에서 다음 performance schema 옵션을 구성하세요.

참고: MySQL과 달리 MariaDB는 기본적으로 performance_schema가 꺼져 있어요. 명시적으로 활성화해야 해요.

파라미터	값	설명
performance_schema	ON	필수. performance schema를 활성화합니다. MariaDB는 기본적으로 이를 활성화하지 않아요.
max_digest_length	4096	더 큰 쿼리 수집에 필요합니다. 기본값으로 두면 1024자보다 긴 쿼리는 수집되지 않아요.
performance_schema_max_digest_length	4096	max_digest_length와 일치해야 해요.
performance_schema_max_sql_text_length	4096	max_digest_length와 일치해야 해요.
performance-schema-consumer-events-statements-current	ON	필수. 실행 중인 쿼리 모니터링을 활성화합니다.
performance-schema-consumer-events-waits-current	ON	필수. 대기 이벤트 수집을 활성화합니다.
performance-schema-consumer-events-statements-history-long	ON	권장. 모든 스레드에서 더 많은 최근 쿼리 추적을 활성화합니다. 활성화하면 빈도가 낮은 쿼리의 실행 세부 정보를 캡처할 가능성이 높아져요.
performance-schema-consumer-events-statements-history	ON	선택. 스레드별 최근 쿼리 기록 추적을 활성화합니다. 활성화하면 빈도가 낮은 쿼리의 실행 세부 정보를 캡처할 가능성이 높아져요.

참고: 권장되는 방법은 에이전트 액세스 권한을 부여하는 과정의 일부로 performance-schema-consumer-* 설정을 런타임에 동적으로 활성화하도록 하는 것입니다. 런타임 설정 컨슈머(Runtime setup consumers)를 참고하세요.

에이전트에 액세스 권한 부여하기

Datadog Agent는 통계와 쿼리를 수집하기 위해 데이터베이스에 대한 읽기 전용 액세스가 필요해요.

다음 지침은 datadog@'%'를 사용해 어떤 호스트에서든 로그인할 수 있는 권한을 에이전트에 부여합니다. datadog@'localhost'를 사용하면 datadog 사용자가 localhost에서만 로그인하도록 제한할 수 있어요. 자세한 내용은 MariaDB 문서를 참고하세요.

datadog 사용자를 만들고 기본 권한을 부여하세요.

CREATE USER datadog@'%' IDENTIFIED by '<UNIQUEPASSWORD>';
ALTER USER datadog@'%' WITH MAX_USER_CONNECTIONS 5;
GRANT REPLICATION CLIENT ON *.* TO datadog@'%';
GRANT PROCESS ON *.* TO datadog@'%';
GRANT SELECT ON performance_schema.* TO datadog@'%';

블로킹 쿼리 수집은 performance_schema와 함께 information_schema.INNODB_LOCK_WAITS와 INNODB_TRX를 사용하므로, 위의 PROCESS와 SELECT ON performance_schema.* 부여로 충분해요. 추가 부여는 필요하지 않아요. 블로킹 쿼리 수집은 기본적으로 꺼져 있어요. 인스턴스 구성에서 query_activity.collect_blocking_queries: true로 활성화하세요.

다음 스키마를 만드세요.

CREATE SCHEMA IF NOT EXISTS datadog;
GRANT EXECUTE ON datadog.* to datadog@'%';

에이전트가 explain plan을 수집할 수 있도록 explain_statement 프로시저를 만드세요.

DELIMITER $$
CREATE PROCEDURE datadog.explain_statement(IN query TEXT)
    SQL SECURITY DEFINER
BEGIN
    SET @explain := CONCAT('EXPLAIN FORMAT=json ', query);
    PREPARE stmt FROM @explain;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END $$
DELIMITER ;

추가로, explain plan을 수집하려는 모든 스키마에 이 프로시저를 만드세요. <YOUR_SCHEMA>를 데이터베이스 스키마로 바꾸세요.

DELIMITER $$
CREATE PROCEDURE <YOUR_SCHEMA>.explain_statement(IN query TEXT)
    SQL SECURITY DEFINER
BEGIN
    SET @explain := CONCAT('EXPLAIN FORMAT=json ', query);
    PREPARE stmt FROM @explain;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END $$
DELIMITER ;
GRANT EXECUTE ON PROCEDURE <YOUR_SCHEMA>.explain_statement TO datadog@'%';

인덱스 메트릭을 수집하려면 datadog 사용자에게 추가 권한을 부여하세요.

GRANT SELECT ON mysql.innodb_index_stats TO datadog@'%';

런타임 설정 컨슈머 (Runtime setup consumers)

Datadog은 에이전트가 런타임에 performance_schema.events_* 컨슈머를 활성화할 수 있도록 다음 프로시저를 만들 것을 권장합니다.

DELIMITER $$
CREATE PROCEDURE datadog.enable_events_statements_consumers()
    SQL SECURITY DEFINER
BEGIN
    UPDATE performance_schema.setup_consumers SET enabled='YES' WHERE name LIKE 'events_statements_%';
    UPDATE performance_schema.setup_consumers SET enabled='YES' WHERE name = 'events_waits_current';
END $$
DELIMITER ;
GRANT EXECUTE ON PROCEDURE datadog.enable_events_statements_consumers TO datadog@'%';

비밀번호를 안전하게 저장하기

Vault 같은 비밀 관리 소프트웨어로 비밀번호를 저장하세요. 그러면 에이전트 설정 파일에서 이 비밀번호를 ENC[<SECRET_NAME>]로 참조할 수 있어요. 예: ENC[datadog_user_database_password]. 자세한 내용은 비밀 관리 (Secrets Management)를 참고하세요.

이 페이지의 예시는 비밀번호가 저장된 비밀의 이름으로 datadog_user_database_password를 사용합니다. 비밀번호를 평문으로 참조하는 것도 가능하지만 권장되지는 않아요.

스키마 수집 (Collecting schemas)

Agent 7.65부터 Datadog Agent는 MariaDB 데이터베이스에서 스키마 정보를 수집할 수 있어요. 인스턴스 구성에서 collect_schemas.enabled: true로 활성화하세요 (Agent 7.68 이하에서는 schemas_collection을 사용하세요). 스키마 수집은 기본적으로 꺼져 있어요.

instances:
  - dbm: true
    ...
    collect_schemas:
      enabled: true

MariaDB 10.5 이상에서는 (MySQL과 마찬가지로) INFORMATION_SCHEMA가 권한을 가진 사용자에게만 테이블을 노출하므로, 부여 없이는 datadog 사용자가 아무 테이블도 보지 못해요. REFERENCES 권한을 부여하면 에이전트에게 테이블 데이터를 읽을 능력을 주지 않으면서 테이블 메타데이터를 표시할 수 있어요.

GRANT REFERENCES ON *.* TO datadog@'%';

REFERENCES는 INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS에서 외래 키 delete_rule과 update_rule 값을 수집하는 데에도 필요해요. 테이블 수준의 SELECT 권한으로는 그 뷰가 노출되지 않아요.

사용 가능한 collect_schemas 튜닝 옵션은 데이터베이스 스키마 탐색하기를 참고하세요.

에이전트 설치하기

Datadog Agent를 설치하면 MariaDB 모니터링에 사용되는 MySQL 점검도 함께 설치되는데, 이는 MariaDB에 Database Monitoring을 사용하는 데 필요해요. MariaDB 데이터베이스 호스트에 아직 에이전트를 설치하지 않았다면 Agent 설치 지침을 참고하세요.

호스트에서 실행되는 에이전트에 대해 이 점검을 구성하려면:

MariaDB 메트릭과 로그 수집을 시작하려면 에이전트의 구성 디렉토리 루트에 있는 conf.d/ 폴더의 mysql.d/conf.yaml 파일을 편집하세요. 사용자 지정 메트릭을 포함한 모든 구성 옵션은 샘플 mysql.d/conf.yaml을 참고하세요.

메트릭 수집 (Metric collection)

MariaDB 메트릭을 수집하려면 mysql.d/conf.yaml에 이 구성 블록을 추가하세요.

init_config:

instances:
  - dbm: true
    host: 127.0.0.1
    port: 3306
    username: datadog
    password: 'ENC[datadog_user_database_password]' # 앞선 CREATE USER 단계에서

참고: datadog 사용자는 MySQL 통합 구성에서 host: 127.0.0.1로 설정해야 하며, localhost가 아니라야 해요. 또는 sock을 사용할 수도 있어요.

메트릭과 이벤트는 dbms_flavor:mariadb로 태그가 지정되어 MariaDB 데이터를 MySQL 데이터와 구분할 수 있어요.

MariaDB 메트릭을 Datadog로 보내기 시작하려면 에이전트를 재시작하세요.

로그 수집 (선택 사항)

에이전트가 데이터베이스에서 수집하는 원격 측정 외에도, 데이터베이스 로그를 Datadog로 직접 보낼 수 있어요.

1. 기본적으로 MariaDB는 모든 것을 /var/log/syslog에 기록하는데, 이를 읽으려면 root 액세스가 필요해요. 로그에 더 쉽게 접근하려면 다음 단계를 따르세요.

   1. /etc/mysql/conf.d/mysqld_safe_syslog.cnf를 편집하고 모든 줄을 주석 처리하세요.
   2. /etc/mysql/my.cnf를 편집해 원하는 로깅 설정을 활성화하세요. 예를 들어 general, error, slow query 로그를 활성화하려면 다음 구성을 사용하세요.

     [mysqld_safe]
     log_error = /var/log/mysql/mysql_error.log
   
     [mysqld]
     general_log = on
     general_log_file = /var/log/mysql/mysql.log
     log_error = /var/log/mysql/mysql_error.log
     slow_query_log = on
     slow_query_log_file = /var/log/mysql/mysql_slow.log
     long_query_time = 3
   

파일을 저장하고 MariaDB를 재시작하세요. 에이전트가 /var/log/mysql 디렉토리와 그 안의 모든 파일에 대해 읽기 권한을 갖도록 하세요. logrotate 구성에서 이러한 파일이 고려되고 권한이 올바르게 설정되었는지 다시 확인하세요. /etc/logrotate.d/mysql-server에는 다음과 유사한 내용이 있어야 해요.

  /var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql_slow.log {
          daily
          rotate 7
          missingok
          create 644 mysql adm
          Compress
  }

1. 로그 수집은 Datadog Agent에서 기본적으로 꺼져 있어요. datadog.yaml 파일에서 활성화하세요.

   logs_enabled: true
   

2. MariaDB 로그 수집을 시작하려면 mysql.d/conf.yaml 파일에 이 구성 블록을 추가하세요.

   logs:
     - type: file
       path: "<ERROR_LOG_FILE_PATH>"
       source: mysql
       service: "<SERVICE_NAME>"
   
     - type: file
       path: "<SLOW_QUERY_LOG_FILE_PATH>"
       source: mysql
       service: "<SERVICE_NAME>"
       log_processing_rules:
         - type: multi_line
           name: new_slow_query_log_entry
           pattern: "# Time:"
           # mysqld를 `--log-short-format`로 시작했다면 다음을 사용하세요:
           # pattern: "# Query_time:"
   
     - type: file
       path: "<GENERAL_LOG_FILE_PATH>"
       source: mysql
       service: "<SERVICE_NAME>"
       # 여러 줄 로그가 yyyy-mm-dd 형식의 날짜로 시작한다면 다음 처리 규칙의 주석을 해제하세요
       # log_processing_rules:
       #   - type: multi_line
       #     name: new_log_start_with_date
       #     pattern: \\d{4}\\-(0?[1-9]|1[012])\\-(0?[1-9]|[12][0-9]|3[01])
       # 로그가 yymmdd 형식의 날짜로 시작하지만 각 로그가 아닌 매 초마다 타임스탬프를 포함한다면 다음 처리 규칙의 주석을 해제하세요
       # log_processing_rules:
       #   - type: multi_line
       #     name: new_logs_do_not_always_start_with_timestamp
       #     pattern: \\t\\t\\s*\\d+\\s+|\\d{6}\\s+\\d{,2}:\\d{2}:\\d{2}\\t\\s*\\d+\\s+
   

3. 에이전트를 재시작하세요.

검증 (Validate)

에이전트의 status 하위 명령을 실행해 Checks 섹션에서 mysql을 찾아보세요. 또는 Databases 페이지를 방문해 시작할 수 있어요.

트러블슈팅

설명한 대로 통합과 에이전트를 설치하고 구성했는데 예상대로 동작하지 않으면 트러블슈팅 문서를 참고하세요.

더 알아보기 (Learn more)

추가로 도움이 되는 문서, 링크, 글:

• 기본 MySQL 통합