MySQL Database Monitoring 설정 트러블슈팅
이 페이지에서는 MySQL에서 Database Monitoring을 설정하고 사용할 때 발생하는 일반적인 문제와 해결 방법을 설명드릴게요. Datadog은 최신 안정 버전의 Agent를 유지하고 최신 설정 문서를 따를 것을 권장합니다. 이 문서는 Agent 버전 릴리스에 따라 달라질 수 있어요.
출처: 문서
본문
일반적인 문제 진단하기
Database Monitoring 구성 후 데이터가 표시되지 않음
설정 지침을 따르고 에이전트를 구성한 뒤에도 데이터가 보이지 않는다면, 대부분 에이전트 구성이나 API 키에 문제가 있는 경우가 많아요. 트러블슈팅 가이드를 따라 에이전트에서 데이터를 받고 있는지 확인하세요.
시스템 메트릭 같은 다른 데이터는 받는데 Database Monitoring 데이터(쿼리 메트릭과 쿼리 샘플 등)는 받지 못한다면, 에이전트나 데이터베이스 구성에 문제가 있을 가능성이 높아요. 에이전트 구성이 설정 지침의 예시와 같은지 확인하고, 구성 파일의 위치를 다시 점검하세요.
디버깅을 시작하려면 먼저 Agent status 명령을 실행해 Datadog로 수집되고 전송되는 데이터에 대한 디버깅 정보를 확인하세요.
Config Errors 섹션을 확인해 구성 파일이 유효한지 확인하세요. 예를 들어 다음은 인스턴스 구성이 없거나 파일이 유효하지 않음을 나타냅니다.
Config Errors
==============
mysql
-----
Configuration file contains no valid instances
구성이 유효하다면 출력은 다음과 같아요.
=========
Collector
=========
Running Checks
==============
mysql (5.0.4)
-------------
Instance ID: mysql:505a0dd620ccaa2a
Configuration Source: file:/etc/datadog-agent/conf.d/mysql.d/conf.yaml
Total Runs: 32,439
Metric Samples: Last Run: 175, Total: 5,833,916
Events: Last Run: 0, Total: 0
Database Monitoring Query Metrics: Last Run: 2, Total: 51,074
Database Monitoring Query Samples: Last Run: 1, Total: 74,451
Service Checks: Last Run: 3, Total: 95,993
Average Execution Time : 1.798s
Last Execution Date : 2021-07-29 19:28:21 UTC (1627586901000)
Last Successful Execution Date : 2021-07-29 19:28:21 UTC (1627586901000)
metadata:
flavor: MySQL
version.build: unspecified
version.major: 5
version.minor: 7
version.patch: 34
version.raw: 5.7.34+unspecified
version.scheme: semver
출력에 다음 줄이 있고 값이 0보다 큰지 확인하세요.
Database Monitoring Query Metrics: Last Run: 2, Total: 51,074
Database Monitoring Query Samples: Last Run: 1, Total: 74,451
에이전트 구성이 올바르다고 확신되면 에이전트 로그에서 데이터베이스 통합 실행 시도와 관련한 경고나 오류를 확인하세요.
또한 Datadog Agent에서 check CLI 명령을 실행하고 출력에서 오류를 검사해 점검을 명시적으로 실행할 수도 있어요.
# 에이전트 자체 호스팅 설치의 경우
DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true datadog-agent check postgres -t 2
DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true datadog-agent check mysql -t 2
DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true datadog-agent check sqlserver -t 2
# 에이전트 컨테이너 기반 설치의 경우
DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true agent check postgres -t 2
DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true agent check mysql -t 2
DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true agent check sqlserver -t 2
쿼리에 explain plan이 없음
일부 또는 모든 쿼리에 explain plan이 없을 수 있어요. 이는 지원되지 않는 쿼리 명령, 지원되지 않는 클라이언트 애플리케이션이 만든 쿼리, 오래된 에이전트, 불완전한 데이터베이스 설정 때문일 수 있어요. explain plan 누락의 가능한 원인은 다음과 같습니다.
이벤트 statements 컨슈머가 없음
explain plan을 캡처하려면 이벤트 statements 컨슈머를 활성화해야 해요. 설정 파일(예: mysql.conf)에 다음 옵션을 추가하면 됩니다.
performance-schema-consumer-events-statements-current=ON
Datadog은 추가로 다음을 활성화할 것을 권장합니다.
performance-schema-consumer-events-statements-history-long=ON
이 옵션은 모든 스레드에서 더 많은 최근 쿼리 추적을 활성화합니다. 켜면 빈도가 낮은 쿼리의 실행 세부 정보를 캡처할 가능성이 높아져요.
explain plan 프로시저가 없음
에이전트는 datadog 스키마에 datadog.explain_statement(...) 프로시저가 존재해야 해요. 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 프로시저가 없음
에이전트는 에이전트가 샘플을 수집할 수 있는 모든 스키마에 explain_statement(...) 프로시저가 존재해야 해요.
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@'%';
에이전트가 지원되지 않는 버전으로 실행 중
에이전트가 7.36.1 이상 버전으로 실행 중인지 확인하세요. Datadog은 새 기능, 성능 개선, 보안 업데이트를 활용하기 위해 에이전트를 정기적으로 업데이트할 것을 권장합니다.
쿼리가 잘림 (Queries are truncated)
샘플 쿼리 텍스트 크기를 늘리는 방법은 잘린 쿼리 샘플에 대한 섹션을 참고하세요.
쿼리를 설명할 수 없음 (Query cannot be explained)
BEGIN, COMMIT, SHOW, USE, ALTER 같은 일부 쿼리는 데이터베이스에서 유효한 explain plan을 생성할 수 없어요. explain plan을 지원하는 쿼리는 SELECT, UPDATE, INSERT, DELETE, REPLACE뿐입니다.
쿼리가 비교적 빈도가 낮거나 빠르게 실행됨
쿼리가 데이터베이스 전체 실행 시간에서 유의미한 비중을 차지하지 않아 샘플링 대상으로 선택되지 않았을 수 있어요. 쿼리를 캡처하려면 샘플링 비율 높이기를 시도해 보세요.
쿼리 메트릭이 없음
쿼리 메트릭 데이터 누락을 진단하는 다음 단계를 따르기 전에 에이전트가 성공적으로 실행 중이고 에이전트 데이터 누락을 진단하는 단계를 따랐는지 확인하세요. 쿼리 메트릭 누락의 가능한 원인은 다음과 같습니다.
인덱스 메트릭이 없음
에이전트가 다음 오류를 표시하면:
Error querying mysql.innodb_index_stats: (1142, "SELECT command denied to user 'datadog'@'172.20.0.5' for table 'innodb_index_stats'")
인덱스 메트릭을 수집하기 위해 datadog 사용자에게 SELECT 권한을 부여해 오류를 해결하세요.
GRANT SELECT ON mysql.innodb_index_stats TO datadog@'%';
performance_schema가 활성화되어 있지 않음
에이전트는 performance_schema 옵션이 활성화되어 있어야 해요. MySQL은 기본적으로 이를 활성화하지만, 구성이나 클라우드 제공업체에 의해 꺼져 있을 수 있어요. 활성화하는 방법은 설정 지침을 참고하세요.
Google Cloud SQL 제한 사항
이 호스트는 Google Cloud SQL에서 관리하며 performance_schema를 지원하지 않아요. Google Cloud SQL의 제한 때문에 Datadog Database Monitoring은 16GB 미만 RAM의 인스턴스에서는 지원되지 않습니다.
특정 쿼리가 없음
일부 쿼리의 데이터는 있는데 Database Monitoring에서 특정 쿼리나 쿼리 집합이 보이길 기대한다면 이 가이드를 따르세요.
| 가능한 원인 | 해결 방법 |
|---|---|
| 쿼리가 "top query"가 아님. 즉 선택한 시간대의 어느 시점에서도 총 실행 시간 합계가 상위 200개 정규화된 쿼리에 들지 않음. | "Other Queries" 행으로 그룹화되었을 수 있어요. 어떤 쿼리가 추적되는지에 대한 자세한 내용은 수집된 데이터 (Data Collected)를 참고하세요. 추적되는 상위 쿼리 수는 Datadog 지원팀에 문의해 늘릴 수 있어요. |
events_statements_summary_by_digest가 가득 찼을 수 있음. |
performance_schema의 MySQL 테이블 events_statements_summary_by_digest는 저장하는 digest(정규화된 쿼리) 수에 최대 제한이 있어요. 유지 관리 작업으로 이 테이블을 정기적으로 잘라내면 모든 쿼리를 시간이 지나며 추적할 수 있어요. 자세한 내용은 고급 설정 (Advanced configuration)을 참고하세요. |
| 에이전트를 마지막으로 재시작한 뒤 쿼리가 한 번만 실행됨. | 쿼리 메트릭은 에이전트가 재시작된 뒤 두 개의 서로 다른 10초 구간에서 쿼리가 최소 한 번 이상 실행된 후에만 내보내져요. |
쿼리 샘플이 잘림
더 긴 쿼리는 데이터베이스 구성 때문에 전체 SQL 텍스트가 표시되지 않을 수 있어요. 워크로드에 맞게 약간의 튜닝이 필요해요.
Datadog Agent에 보이는 MySQL SQL 텍스트 길이는 다음 시스템 변수로 결정됩니다.
max_digest_length=4096
performance_schema_max_digest_length=4096
performance_schema_max_sql_text_length=4096
쿼리 활동이 없음
{% alert level="danger" %} 쿼리 활동(Query Activity)과 대기 이벤트(Wait Event) 수집은 Flexible Server에서 지원되지 않아요. 이 기능에는 Flexible Server 호스트에서 사용할 수 없는 MySQL 설정이 필요합니다. {% /alert %}
쿼리 활동 누락을 진단하는 다음 단계를 따르기 전에 에이전트가 성공적으로 실행 중이고 에이전트 데이터 누락을 진단하는 단계를 따랐는지 확인하세요. 쿼리 활동 누락의 가능한 원인은 다음과 같습니다.
performance-schema-consumer-events-waits-current가 활성화되어 있지 않음
에이전트는 performance-schema-consumer-events-waits-current 옵션이 활성화되어 있어야 해요. MySQL은 기본적으로 이를 꺼두지만, 클라우드 제공업체가 활성화했을 수 있어요. 활성화하는 방법은 설정 지침을 참고하세요. 또는 데이터베이스를 재시작하지 않으려면 런타임 설정 컨슈머를 설정하는 방법도 고려해 보세요. 에이전트가 런타임에 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@'%';
참고: 이 옵션은 추가로 performance_schema가 활성화되어 있어야 해요.
수집된 스키마에서 테이블이 없음
에이전트가 다음과 같이 시작하는 경고를 기록하면:
No tables were found across any of the N databases.
MySQL은 해당 테이블에 대한 권한을 가진 사용자에게만 INFORMATION_SCHEMA의 테이블을 노출하므로, 권한이 없는 datadog 사용자는 아무 테이블도 보지 못해요. REFERENCES 권한을 부여하면 에이전트에게 데이터를 읽을 능력 없이 테이블 메타데이터를 볼 수 있게 해 주므로 이 경고를 해결할 수 있어요.
GRANT REFERENCES ON *.* TO datadog@'%';
일부 테이블만 누락된 경우 부여가 그 테이블들을 포함하는지 확인하세요. 개별 컬럼에 범위가 한정된 부여는 부여된 컬럼만 노출하고, 하나의 데이터베이스나 테이블에 범위가 한정된 부여는 그 데이터베이스나 테이블만 다룹니다. 사용 가능한 범위는 스키마 수집 (Collecting schemas)을 참고하세요.
MySQL 쿼리 메트릭 및 샘플에서 스키마 또는 데이터베이스가 없음
schema 태그("database"라고도 함)는 쿼리를 만든 연결에 기본 데이터베이스(Default Database)가 설정된 경우에만 MySQL 쿼리 메트릭과 샘플에 표시돼요. 기본 데이터베이스는 애플리케이션이 데이터베이스 연결 파라미터에 "schema"를 지정하거나, 기존 연결에서 USE Statement를 실행해 설정합니다.
연결에 기본 데이터베이스가 구성되어 있지 않으면, 그 연결이 만든 어떤 쿼리에도 schema 태그가 없어요.
MariaDB 알려진 제한 사항
MariaDB를 사용한다면 MariaDB 트러블슈팅 가이드의 MariaDB 알려진 제한 사항을 참고하세요.