이미지 출처 : https://1000logos.net/datadog-logo/
📝 에이전트에 접근 권한 부여
앞서 포스팅한 내용에 이어서,
이제 기본적인 파라미터 세팅은 완료된 상태이니 접근 권한 부여 및 에이전트 구성 단계 까지만 진행해주면 된다.
참고로, 접근 권한 부여 + 에이전트 구성 단계를 미리 해놓고 마지막에 파라미터 세팅을 진행해도 따로 문제는 없었다!
순서는 중요하지 않은 듯
이제 DBM 연동 문서에서 에이전트에 접근 권한 부여 탭에 있는 부분을 세팅 해 줄건데,
이건 그냥 차례대로 쿼리 수행해주면 된다.
✏️ Datadog 사용자 생성 및 기본 권한 부여
먼저, Datadog 사용자 생성 및 기본 권한 부여 단계이다.
CREATE USER datadog@'%' IDENTIFIED by '<UNIQUEPASSWORD>'; //사용자 생성 및 IP 접속 허용
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@'%'; //MYSQL의 performance_schema 정보 조회 권한✏️ Datadog 전용 스키마 생성 및 권한 부여
다음은, Datadog 전용 스키마 생성 및 권한 부여 단계이다.
CREATE SCHEMA IF NOT EXISTS datadog; //Datadog이 자체적으로 사용할 스키마 생성
GRANT EXECUTE ON datadog.* to datadog@'%'; //프로시저 실행 권한 부여
GRANT CREATE TEMPORARY TABLES ON datadog.* TO datadog@'%'; //임시 테이블 생성 권한 부여✏️ explain_statement 생성 절차 (Datadog 스키마)
그리고 에이전트가 설명 계획을 수집할 수 있도록 explain_statement 생성 절차를 진행해준다.
EXPLAIN FORMAT=JSON 구문을 실행해 쿼리의 실행 계획을 분석하는 스토어드 프로시저 생성하며,
SQL SECURITY DEFINER 구문은 호출자 권한이 아닌 작성자 권한으로 실행되도록 하는 구문이라고 한다!
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_statement 생성 절차 (개인 스키마)
또한, 위 절차는 Datadog 뿐만 아니라 본인이 설명 계획을 수집하려는 모든 DB 스키마에 대해서도 생성이 필요하다고 한다.
<YOUR_SCHEMA> 부분에 본인의 DB 스키마를 넣어서 생성해주면 된다.
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@'%';✏️ Performance Schema 소비자 활성화 단계
추가로 Performance Schema 소비자(consumer) 활성화 단계가 필요하다.
아래 절차를 통해 Datadog Agent가 실행 시점에 호출해 필요한 consumer를 활성화할 수 있도록 한다!
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@'%';✏️ SELECT 권한 부여
이제 여기까지만 적용하면 되는 줄 알고 ..
적용 후에 위에서 만든 Datadog 계정으로 DB에 직접 접근 해 보려고 했는데 ㅜㅜ
접근이 불가능 하다는 에러 메세지가 발생했다.
확인해보니 문서 하단에 MySQL에서 테이블 스키마를 수집하려면 Datadog 에이전트가 해당 테이블에 대한 SELECT 권한을 가져야 한다고 나와있다..
GRANT SELECT ON <YOUR_SCHEMA>.* TO 'datadog'@'%';이렇게 넣어주면 됨!!!
근데 이런 설정은 그냥 에이전트 권한 부여하는 부분에 같이 적어주면 안되나요..
어차피 MYSQL 문서인데 ㅜㅜ 😭😭😭
여튼 이렇게까지 설정을 진행하면 생성한 Datadog 계정으로 DB 접근까지 정상적으로 된다~
📝 에이전트 설치 및 구성 단계
✏️ datadog-values.yaml 파일 수정
이제 마지막으로 에이전트 설치 및 구성 단계까지만 진행해주면 끝이다!
(참고로, 나는 EKS 환경에서 세팅을 진행하기 때문에 kubernetes 설정 단계를 참고함.)
에이전트 구성 또한 DBM 설정 가이드를 참고 해 진행 해 주면 되며, 내가 진행 할 내용은 EKS 환경에 datadog agent가 이미 설치되어 있고, datadog-values.yaml 파일이 이미 기본 세팅 되어있다는 가정하에 연동을 하는거니까 이게 안되어있다면 먼저 세팅을 해 준뒤 따라해주면 됨! (관련자료 : Kubernetes에 Datadog Agent 설치하기 )
여튼 세팅하는 방법은 간단하다. 기존에 있던 datadog-values.yaml 파일에 아래와 같은 설정을 추가 하면 된다.
clusterAgent:
confd:
mysql.yaml: |-
cluster_check: true
init_config:
instances:
- dbm: true
host: <INSTANCE_ADDRESS>
port: 3306
username: datadog
password: 'ENC[datadog_user_database_password]'
clusterChecksRunner:
enabled: true파일 수정 뒤에는,
helm install datadog-agent -f datadog-values.yaml datadog/datadog
OR
helm upgrade -f datadog-values.yaml datadog-agent datadog/datadog명령을 입력 해 주면 되는데, datadog-agent가 이미 설치되어 있을때는 upgrade 명령만 수행하면 되는 것 같다.
💬 datadog-agent-clusterchecks- pod란?
위와 같은 명령을 입력하면, datadog-agent-clusterchecks- 라는 명칭의 pod가 2개 생성될텐데,
해당 pod의 역할은 다음과 같다고 한다.
Datadog에서 쿠버네티스 클러스터 환경의 데이터베이스(MySQL 등) 모니터링(DBM)을 구성할 때,
클러스터 전체에 걸친 체크 작업을 수행하는 전용 경량 에이전트 역할을 하는 것이 바로 Cluster Check Runner (CLC Runner)입니다.
CLC runner 방식은 기존 에이전트보다 적은 리소스를 사용하는 라이트한 버전의 에이전트를 배포하여 클러스터 에이전트에 설정한 check (현재의 경우, mysql)를 실행하는 방식입니다.
아마 단일 노드에 설치된 Datadog Agent가 이런 클러스터 체크까지 담당하는것은 부담이 집중되기 때문에, 분산 실행을 통한 부하 최소화를 위해 추가로 클러스터 체크 에이전트를 배포하는 듯 하다!
참고자료 : 클러스터 검사 러너
❌ datadog-values.yaml 파일 수정 중 주의 사항
그리고 설정 중 추가로 주의할 점이 있는데
첫번째로, password: 'ENC[datadog_user_database_password]' 설정 부분이다!
password를 ENC[] 안에 감싸주는건, Datadog의 비밀 관리 시스템(Secrets Management)을 이용했을때만 감싸줘야 한다. 따라서, ENC[] 안에 들어가야 하는건 비밀번호 평문이 아니라, Secrets Management로 등록한 Secret name 이어야 한다는 것!
나는 평문을 계속 넣어주다 보니 계속 연동이 안되고 password 관련 오류가 Datadog Logs탭에 계속 찍혔다.
만약 평문을 넣어주고 싶다면 password: 'password' 이렇게 넣어주면 된다!
(단 Datadog은 보안상 이유로 Secrets Management 사용을 권장함)
참고자료 : 시크릿 관리
두번째는, clusterAgent와 clusterChecksRunner의 위치이다!
해당 설정은 datadog:의 하위가 아닌 yaml 파일의 최상단에 위치해야 한다는 점!
datadog: # 일반적인 설정들
apiKey: YOUR_API_KEY
site: datadoghq.com
clusterAgent: # 최상위 위치!
enabled: true
...
clusterChecksRunner: # 역시 최상위!
enabled: true혹시 clusterAgent 설정과 clusterChecksRunner 설정을 추가 했는데도, pod가 추가적으로 생기지 않는다면 위치가 둘다 최상위 인지 한번 체크를 해 보면 좋을 듯 하다~
여기까지 완료하면 DBM 설정 끝!
이제 Datadog APM -> Database Monitoring 에서 모니터링 가능하다!
