Visual Studio Code 내에 VS Code용 MySQL 셸을 설치하는 방법을 설명합니다.

VS Code 확장용 MySQL 셸 설치

1단계: Visual Studio Code를 연다.

2단계: 화면 좌측의 Extensions을 클릭한 후 검색란에 "MySQL Shell for VS Code"를 입력한다.

             - 아래 화면의 Extensions(①)을 클릭한 후 검색란(②)에 " MySQL Shell for VS Code"를 입력한다.

3단계: " MySQL Shell for VS Code" 확장 프로그램을 설치합니다.

            - 검색된 Extension 중 " MySQL Shell for VS Code"  [Install] 버튼을 클릭하여 설치합니다.

4단계: 설치가 완료되면 VS Code 화면의 좌측 하단에 아래와 같이 "MySQL Shell for VS Code" 아이콘을 볼 수 있다.

5단계: 설치를 완료한 후 VS Code를 재실행한다.

MySQL Shell for VS Code Components

좌측 메뉴에서 " MySQL Shell for VS Code" 아이콘을 클릭하면 아래와 같은 4개의 하위 메뉴를 볼 수 있다.

1) OPEN EDITIORS : DB 노트북, 단일 언어 스크립트, MySQL Shell 세션 편집기를 생성하고 관리 .(수정)

2) DATABASE CONNECTIONS :  DB 접속 환경을 설정할 수 있는 메뉴로 "Create New DB Connection"을 클릭한다.

아래와 같은 DB 접속 설정 화면을 볼 수 있다.

• Caption : 접속할 DB를 구분할 수 있는 임의의 명칭을 입력한다.
• Host Name or IP Address : Host명이나 IP 또는 endpoints 등을 입력한다.
• User Name : DB 계정을 입력한다.
• Store Password 버튼을 클릭하여 계정의 패스워드를 입력한다.

위의 내용이 입력되었으면 [OK] 버튼을 클릭하여 DB 접속 환경 정보를 저장한다.

아래 화면처럼 [DATABASE CONNECTIONS] Component 밑에 LocalDB 접속환경이 생성된 것을 확인할 수 있다.

DB 접속을 위해 아래 화면처럼 "Open New Database Connection" 을 클릭한다. 우측화면에 SQL 콘솔 화면이 나타나다.

MySQL8 이상에서는 Function Based Index를 지원한다.

Function Based Index 생성 시 주의할 점은 괄호를 묶어주어야 한다는 것이다.

 예제 1) 테이블 생성 시 FBI 생성

CREATE TABLE tbl (
  col1 LONGTEXT,
  INDEX idx1 ((SUBSTRING(col1, 1, 10)))
);
SELECT * FROM tbl WHERE SUBSTRING(col1, 1, 9) = '123456789';
SELECT * FROM tbl WHERE SUBSTRING(col1, 1, 10) = '1234567890';

예제 2) FBI 인덱스 생성

Create index fbi_index on animals((CONCAT (grp , name)));

Autoscaling Aurora Serverless

 Aurora 서버리스는 애플리케이션에서 발생된 부하를 기반으로 확장하도록 되어 있습니다. 다음 조건 중 하나가 충족되면 클러스터가 자동으로 ACU를 확장합니다.

• CPU 사용률이 70%를 초과하거나
• DB max connection의 90% 이상 사용

다음 조건이 모두 충족되면 클러스터가 자동으로 축소됩니다.

• CPU 사용률이 30% 미만으로 떨어지고
• DB max connection 의 40% 미만이 사용

사전 요구사항

아래 내용들이 사전에 설정된 상태에서 Python과 MySQL 연동을 설명합니다.

MySQL DB와 연동을 위한 여러 모듈이 있습니다. 본 문서에서는 Connector/Python 모듈을 이용하는 방법을 설명합니다.

Connector/Python 설치

pip install mysql-connector-python

Connector/Python 으로 MySQL 접속

connect()  생성자는 MySQL 서버에 대한 연결을 생성하고 MySQLConnection객체를 반환합니다.

다음 예에서는 MySQL 서버에 연결하는 방법을 보여줍니다.

try ~ except문을 사용하여 DB 접속 오류를 처리하고,  Error을 사용하여 오류를 catch 합니다.

import mysql.connector
from mysql.connector import errorcode

try:
  cnx = mysql.connector.connect(user='pymysql', password='pymysql123',
	                          host='127.0.0.1',
       	                      database='pymysqldb')
except mysql.connector.Error as err:
  if err.errno == errorcode.ER_ACCESS_DENIED_ERROR:
    print("Something is wrong with your user name or password")
  elif err.errno == errorcode.ER_BAD_DB_ERROR:
    print("Database does not exist")
  else:
    print(err)
else:
  cnx.close()

Inserting Data Using Connector/Python

데이터 삽입이나 업데이트는 커서라는 핸들러 구조를 사용하여 수행합니다. InnoDB와 같은 트랜잭션 스토리지 엔진을 사용하는 경우, DML(INSERT, UPDATE, DELETE) 명령문 후에 데이터를 커밋 해야 합니다 . 

이 예에서는 새 데이터를 삽입하는 방법을 보여줍니다. 두 번째는 새로 생성된 첫 번째 기본 키INSERT 의 값에 따라 달라집니다 . 이 예에서는 확장 형식을 사용하는 방법도 보여줍니다. 이 작업은 내일부터 급여가 50000으로 설정된 새 직원을 추가하는 것입니다.

1. MySQL 설정

- MySQL 설치 : Ver 8.0.32

- schema 생성 : pymysqldb

 create database pymysqldb default character set utf8mb4 collate utf8mb4_bin;

- 계정, 권한 생성 : pymysql

-- 계정생성
create user pymysql identified by 'pymysql123';
-- 권한 부여
grant all on pymysqldb.* to pymysql;

- 테이블 생성 : 

* 테이블 layout

파이썬 자체에는 MySQL을 인식하는 기능이 없습니다. 파이썬 코드에서 MySQL을 활용하기 위해 외부 라이브러리인 pymysql을 설치해야합니다.

pymysql 모듈 사용

1. pymysql 모듈 설치

pip install pymysql

2.   pymysql 임포트

import pymysql

3. 데이터베이스와 연동

pymysql을 임포트한 후 pymysql.connect()로 데이터베이스와 연동 하고 connectoin 객체를 conn 에 할당합니다.

import pymysql

conn = pymysql.connect(host='127.0.0.1', user='pymysql', password='pymysql123', db='pymysqldb', charset='utf8mb4')

② 커서(cursor)는 데이터베이스에 SQL 문을 실행하거나 실행된 결과를 돌려받는 통로로 생각하면 됩니다. ① 에서 연결한 연결자에 커서를 만들어야 합니다. cur라는 변수를 커서로 사용하겠습니다.

MySQL DB에서 어떤 경우에 LOCK이 발생하고 그 LOCK을 어떻게 찾아가는지에 대해

여러 시나리오에 따라 테스트를 해본다.

- 테스트 테이블 생성 : 테스트를 위한 테이블과 데이터를 생성한다.

-- create table
CREATE TABLE select_lock
(col1 varchar(50),
 col2 varchar(50));
 
 INSERT INTO select_lock VALUES('1st', 'first');
 INSERT INTO select_lock VALUES('2nd', 'second');
 
 commit;

💎 autocommit = OFF 일 때, select lock  발생

auto_commit = 0 일 때, select 일 경우에도 shared_read lock이 발생하여 DDL 수행 시 대기상태로 빠진다.

-  session A) SELECT 수행

SELECT * FROM select_lock;

• lock 정보 조회 : 다른 session에서 session C) 의 SQL 수행으로 LOCK 정보를 확인해 보면, LOCK_TYPE이 SHARED_READ로 보여지며 이 테이블의 row에 대한 LOCK을 잡는다. 같은 session에서 조회할 경우 LOCK 정보가 보이지 않는다. 이와같이 autocommit 이 off 인 session에서 select 만 할 경우에도 LOCK이 발생하며 다른 session에서 DML은 가능하지만 DDL 수행 시 waiting LOCK이 발생한다.

+-------------+---------------+-------------+-------------+-------------+----------------+------------------+------------------+------------------+-----------+
| object_type | object_schema | object_name | lock_type   | lock_status | processlist_id | processlist_user | processlist_host | processlist_info | thread_id |
+-------------+---------------+-------------+-------------+-------------+----------------+------------------+------------------+------------------+-----------+
| TABLE       | deldb         | select_lock | SHARED_READ | GRANTED     |             16 | root             | localhost        | NULL             |        57 |
+-------------+---------------+-------------+-------------+-------------+----------------+------------------+------------------+------------------+-----------+

- session B) DDL 수행

아래의 명령어와 같이 DDL을 수행하면 수행되지 않고 대기 상태로 된다. 즉 다른 session의 LOCK이 해소되기를 기다린다.

ALTER TABLE select_lock CHANGE col1 colA varchar(16);
-- 대기상태

- session C) lock 조회

위의 두 SQL을 실행한 상태에서 다른 session에서 아래의 SQL을 수행한다.

SELECT l.object_type, l.object_schema, l.object_name, l.lock_type, l.lock_status,
       t.processlist_id, t.processlist_user, t.processlist_host, t.processlist_time, t.processlist_info, 
       t.processlist_state,	t.thread_id
FROM   performance_schema.metadata_locks l
       inner join performance_schema.threads t on t.thread_id = l.owner_thread_id
WHERE  processlist_id <> connection_id();

아래의 결과와 같이 최초 autocommit이 OFF 인 session에서 LOCK을 발생시키고, 다른 session에서 수행한 DDL이 대기상태인 것을 알 수 있다. thread_id 또는 processlist_id 별로 LOCK_STATUS를 보면 동일한 id 중에 GRANTED 만 있는 processlist 또는 thread가 있는 것을 확인할 수 있다. 아래에서는 thread_id가 49 또는 processlist_id가 8 인 것을 볼 수 있다. 다른 process는 PENDING 이 있는 것을 볼 수 있다.

+-------------+---------------+-------------------+---------------------+-------------+-----------+----------------+------------------------------------------------------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME       | LOCK_TYPE           | LOCK_STATUS | THREAD_ID | PROCESSLIST_ID | PROCESSLIST_INFO                                     |
+-------------+---------------+-------------------+---------------------+-------------+-----------+----------------+------------------------------------------------------+
| TABLE       | deldb         | select_lock       | SHARED_READ         | GRANTED     |        49 |              8 | NULL                                                 |
| GLOBAL      | NULL          | NULL              | INTENTION_EXCLUSIVE | GRANTED     |        51 |             10 | ALTER TABLE select_lock CHANGE cola col1 varchar(16) |
| BACKUP LOCK | NULL          | NULL              | INTENTION_EXCLUSIVE | GRANTED     |        51 |             10 | ALTER TABLE select_lock CHANGE cola col1 varchar(16) |
| SCHEMA      | deldb         | NULL              | INTENTION_EXCLUSIVE | GRANTED     |        51 |             10 | ALTER TABLE select_lock CHANGE cola col1 varchar(16) |
| TABLE       | deldb         | select_lock       | SHARED_UPGRADABLE   | GRANTED     |        51 |             10 | ALTER TABLE select_lock CHANGE cola col1 varchar(16) |
| TABLESPACE  | NULL          | deldb/select_lock | INTENTION_EXCLUSIVE | GRANTED     |        51 |             10 | ALTER TABLE select_lock CHANGE cola col1 varchar(16) |
| TABLE       | deldb         | #sql-1698_a       | EXCLUSIVE           | GRANTED     |        51 |             10 | ALTER TABLE select_lock CHANGE cola col1 varchar(16) |
| TABLE       | deldb         | select_lock       | EXCLUSIVE           | PENDING     |        51 |             10 | ALTER TABLE select_lock CHANGE cola col1 varchar(16) |
+-------------+---------------+-------------------+---------------------+-------------+-----------+----------------+------------------------------------------------------+

processlist를 조회해 보면 STATE이 "Waiting for table metadata lock" 인 것을 볼 수 있으며 이는 다른 프로세스의 LOCK이 해소되기를 기다리는 상태인 것이다. 또는 threads 에서 processlist_state 에서도 확인할 수 있다.

mysql> select * from information_schema.processlist;
+----+-----------------+-----------------+-------+---------+------+---------------------------------+------------------------------------------------------+
| ID | USER            | HOST            | DB    | COMMAND | TIME | STATE                           | INFO                                                 |
+----+-----------------+-----------------+-------+---------+------+---------------------------------+------------------------------------------------------+
|  8 | root            | localhost:63207 | deldb | Sleep   |  272 |                                 | NULL                                                 |
| 10 | root            | localhost:63240 | deldb | Query   |  242 | Waiting for table metadata lock | ALTER TABLE select_lock CHANGE cola col1 varchar(16) |
| 12 | root            | localhost:63450 | deldb | Query   |    0 | executing                       | select * from information_schema.processlist         |
|  5 | event_scheduler | localhost       | NULL  | Daemon  | 1943 | Waiting on empty queue          | NULL                                                 |
+----+-----------------+-----------------+-------+---------+------+---------------------------------+------------------------------------------------------+

lock를 유발한 session이 아닌 다른 session에서 metalock이 발생한 상태에서 테이블에 대한 어떤 작업을 수행할 경우 작업이 수행되지 않고 PENDING 상태로 대기한다.

즉, 다른 session에서 select를 수행할 경우에도 DDL이 수행되지 않고 PENDING 상태로 대기한다.

단, lock을 유발한 session에서는 DML, DDL 작업이 가능하다.

- LOCK 해소

1) 첫번째 session에서 commit 또는 rollback을 수행한다.

2) 첫번째 session을 찾아 kill 시킨다.

3) DDL session을 kill 시킨다.

💎 explain 을 수행할 때

session A) autocommit = OFF일 때, EXPLAIN 수행 시

EXPLAIN FORMAT=tree
select * from select_lock;

session B)

SELECT l.object_type, l.object_schema, l.object_name, l.lock_type, l.lock_status,
       t.processlist_id, t.processlist_user, t.processlist_host, t.processlist_time, t.processlist_info, 
       t.processlist_state,	t.thread_id
FROM   performance_schema.metadata_locks l
       inner join performance_schema.threads t on t.thread_id = l.owner_thread_id
WHERE  processlist_id <> connection_id();

수행결과 : 아래와 같이 SHARED_READ LOCK이 잡히는 것을 볼 수 있다. 즉, EXPLAIN을 수행하더라도 테이블에 SHARED_READ LOCK이 잡히는 것을 알 수 있다. 

+-------------+---------------+-------------+-------------+-------------+-----------+----------------+------------------+------------------+------------------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | LOCK_TYPE   | LOCK_STATUS | THREAD_ID | PROCESSLIST_ID | PROCESSLIST_HOST | PROCESSLIST_USER | PROCESSLIST_INFO |
+-------------+---------------+-------------+-------------+-------------+-----------+----------------+------------------+------------------+------------------+
| TABLE       | deldb         | select_lock | SHARED_READ | GRANTED     |       122 |             75 | localhost        | root             | NULL             |
+-------------+---------------+-------------+-------------+-------------+-----------+----------------+------------------+------------------+------------------+

💎 autocommit = OFF 일 때, DML lock  발생

💎 유휴 세션 Blocking 쿼리 식별

내부 InnoDB locking 정보와 Session 정보를 연관시킬 수 있습니다. 예를 들어, 어떤 InnoDB 트랜잭션 ID에 대해 해당 세션이 잠금을 보유하여 다른 트랜잭션을 차단할 수 있는 세션인지 알고 싶을 수 있습니다.

아래 예제는 INFORMATION_SCHEMA.INNODB_TRX 테이블과 performance_schema의 data_locks 및 data_lock_waits 테이블 조회 데이터입니다.

💎 Lock 유발 SQL 찾기

1. DML

  - session#1 DML 수행

  - session#2 session#1과 동일한 데이터에 대한 DML 수행

  - session#1의 SQL 찾기

SELECT  l.OBJECT_TYPE, l.OBJECT_SCHEMA, l.OBJECT_NAME, l.LOCK_TYPE, l.LOCK_STATUS,
        t.THREAD_ID, PROCESSLIST_ID, PROCESSLIST_HOST, PROCESSLIST_USER, PROCESSLIST_INFO,
        s.sql_text, s.statement_id
FROM performance_schema.metadata_locks l
        INNER JOIN performance_schema.threads t ON t.THREAD_ID = l.OWNER_THREAD_ID
        INNER JOIN performance_schema.events_statements_current  s ON t.THREAD_ID = s.THREAD_ID
WHERE PROCESSLIST_ID <> CONNECTION_ID();

2. DDL

1. row lock

   - insert, update, delete : transaction 을 종료하지 않았을 경우

Datadog 데이터베이스 모니터링은 InnoDB 스토리지 엔진에 대한 쿼리 지표, 쿼리 샘플, 실행 계획, 연결 데이터, 시스템 지표 및 원격 측정 등을 제공하여 MySQL 데이터베이스에 대한 가시적인 모니터링을 제공합니다.

에이전트는 읽기 전용 사용자로 로그인하여 데이터베이스에서 직접 원격 분석을 수집합니다. MySQL 데이터베이스에서 데이터베이스 모니터링을 활성화하려면 다음 설정을 수행합니다.

• 데이터베이스 매개변수 구성
• 에이전트에 데이터베이스 액세스 권한 부여
• 에이전트 설치
• RDS 통합 설치

본 문서에서는 Aurora MySQL 3.04.0(Mysql 8.0.28) 버전을 기준을 설명합니다.

MySQL 설정 구성

DB parameter 그룹에서 다음을 구성한 후 설정이 적용되도록 서버를 다시 시작합니다.(아래 파라미터는 MySQL 5.7 이상에 적용됩니다.

에이전트 액세스 권한 부여

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

1) 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@'%';

2) 스키마를 생성합니다.

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

3) datadog 에이전트가 실행 계획을 수집할 수 있도록 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 ;

실행 계획을 수집하려는 모든 스키마에 이 프로시저를 생성합니다.

아래의 <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에서는 에이전트에 런타임 시 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@'%';

Install the Agent

Aurora 호스트를 모니터링하려면 Datadog 에이전트를 설치하고 각 인스턴스 엔드포인트에 원격으로 연결하도록 구성합니다. 에이전트는 데이터베이스에서 실행할 필요가 없으며 데이터베이스에 연결하기만 하면 됩니다.

RDS로 DB를 구축한 경우, 별도의 EC2나 Docker container 또는 kubernetes pod에 설치할 수 있습니다.

본 문서에서는 별도의 EC2에 Agent 설치를 설명합니다.

루트 디렉터리의 conf.d/ 폴더에서 mysql.d/conf.yaml 파일을 편집합니다.

MySQL 지표를 수집하려면 mysql.d/conf.yaml에 다음 구성 블록을 추가하세요.

init_config:

instances:
  - dbm: true
    host: '<AWS_INSTANCE_ENDPOINT>'
    port: 3306
    username: datadog
    password: '<YOUR_CHOSEN_PASSWORD>'

에이전트 설정 예제

One agent connecting to multiple hosts

여러 원격 데이터베이스 인스턴스에 연결하기 위해 단일 에이전트 호스트를 구성하는 것이 일반적입니다 여러 호스트에 연결하려면 MySQL 통합 구성에서 각 호스트에 대한 항목을 생성합니다.안정적인 성능을 보장하기 위해 에이전트당 인스턴스 수를 최대 10개의 데이터베이스 인스턴스로 설정합니다.

init_config:
instances:
  - dbm: true
    host: products-primary.123456789012.us-east-1.rds.amazonaws.com
    port: 3306
    username: datadog
    password: '<PASSWORD>'
    tags:
      - 'env:prod'
      - 'team:team-discovery'
      - 'service:product-recommendation'
  - dbm: true
    host: products–replica-1.us-east-1.rds.amazonaws.com
    port: 3306
    username: datadog
    password: '<PASSWORD>'
    options:
      replication: true
    tags:
      - 'env:prod'
      - 'team:team-discovery'
      - 'service:product-recommendation'
  - dbm: true
    host: products–replica-2.us-east-1.rds.amazonaws.com
    port: 3306
    username: datadog
    password: '<PASSWORD>'
    options:
      replication: true
    tags:
      - 'env:prod'
      - 'team:team-discovery'
      - 'service:product-recommendation'
    [...]

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

에이전트 구성 파일에서 직접 비밀번호를 선언하는 것이 가능하지만 Vault와 같은 비밀 관리 소프트웨어를 사용하여 데이터베이스 자격 증명을 다른 곳에 암호화하고 저장하는 것이 더 안전한 방법입니다. 에이전트는 ENC[] 구문을 사용하여 이러한 자격 증명을 읽을 수 있습니다.

init_config:
instances:
  - dbm: true
    host: localhost
    port: 3306
    username: datadog
    password: 'ENC[datadog_user_database_password]'

사용자 정의 쿼리 실행

사용자 정의 지표를 수집하려면 custom_queries 옵션을 사용합니다

init_config:
instances:
  - dbm: true
    host: localhost
    port: 3306
    username: datadog
    password: '<PASSWORD>'
    custom_queries:
    - query: SELECT age, salary, hours_worked, name FROM hr.employees;
      columns:
        - name: custom.employee_age
          type: gauge
        - name: custom.employee_salary
           type: gauge
        - name: custom.employee_hours
           type: count
        - name: name
           type: tag
      tags:
        - 'table:employees'

프록시를 통한 호스트 작업

에이전트가 Cloud SQL 인증 프록시와 같은 프록시를 통해 연결해야 하는 경우 모든 원격 분석에는 데이터베이스 인스턴스가 아닌 프록시의 호스트 이름으로 태그가 지정됩니다. reported_hostname 옵션을 사용하여 지정합니다.

init_config:
instances:
  - dbm: true
    host: localhost
    port: 5000
    username: datadog
    password: '<PASSWORD>'
    reported_hostname: products-primary
  - dbm: true
    host: localhost
    port: 5001
    username: datadog
    password: '<PASSWORD>'
    reported_hostname: products-replica-1

RDS 통합 설치

개요

Amazon Relational Database Service(RDS)는 클라우드에서 관계형 데이터베이스를 설정, 운영 및 확장하는 데 사용되는 웹 서비스입니다. 이 통합을 활성화하면 Datadog에서 모든 RDS 지표를 볼 수 있습니다.

참고: 환경 변수 DD_SITE가 datadoghq.com 외부의 지역으로 설정되어 있는지 확인하거나 다음과 변수를 설정합니다.

RDS 인스턴스를 모니터링하는 옵션에는 표준, 고급, 기본의 세 가지 옵션이 있습니다.

표준 통합을 위해서는 AWS 통합 페이지의 지표 수집 탭에서 RDS를 활성화해야 합니다. 이를 통해 CloudWatch 통합이 허용하는 만큼 인스턴스에 대한 지표를 받을 수 있습니다. 모든 RDS 엔진 유형이 지원됩니다.

이 통합을 위해 사전 설정된 대시보드에는 연결, 복제 지연, 읽기 작업 및 대기 시간, 컴퓨터, RAM, 쓰기 작업 및 대기 시간, 디스크 메트릭과 같은 메트릭 정보가 포함됩니다.

설정

설치

• Standard
• Enhanced
• Native

표준 RDS 통합의 경우 먼저 Amazon Web Services 통합을 설정해야 합니다. datadog에 로긴한 후 좌측 메뉴에서 [Integrations] 클릭 후 우측의 화면에서 "Amazon Web Services"를 클릭합니다.

구성

1) AWS integration page의 Metric Collection tab에서 RDS가 활성화되어 있는지 확인합니다. 아래 화면처럼 "AWS Integrations" 탭 클릭한 후 검색란에 rds 를 입력합니다.

2) Amazon RDS 지표를 수집하려면 Datadog IAM 정책에 다음 권한을 추가합니다.

rds:DescribeDBInstances	Describe RDS instances to add tags.
rds:ListTagsForResource	Add custom tags on RDS instances.
rds:DescribeEvents	Add events related to RDS databases.

3) Datadog - AWS RDS ingegration을 설치합니다.

사용법

Datadog의 지표 탐색기, 대시보드 및 Warning을 통해 MySQL, Aurora, MariaDB, SQL Server, Oracle 또는 PostgreSQL의 RDS 지표 및 지표에 액세스할 수 있습니다. 다음은 두 RDS의 여러 지표를 표시하는 Aurora 대시보드의 예입니다.

로그 수집

로깅 설정

MySQL, MariaDB 및 Postgres 로그를 Amazon CloudWatch로 전달할 수 있습니다. Amazon CloudWatch로 Amazon Aurora MySQL RDS 로그를 보내도록 RDS 를 설정합니다.

Datadog에 로그 보내기

1. If you haven’t already, set up the Datadog log collection AWS Lambda function. 아직 설정하지 않았다면 Datadog 로그 수집 AWS Lambda 함수를 설정합니다.
2. Lambda 함수가 설치되면 RDS 로그가 포함된 CloudWatch 로그 그룹에 트리거를 수동으로 추가하고 해당 CloudWatch 로그 그룹을 선택하고 필터 이름(선택 사항)을 추가한 후 트리거를 추가합니다.

완료되면 Datadog Log 섹션으로 이동하여 로그를 탐색합니다.

참고문서 : https://docs.datadoghq.com/database_monitoring/setup_mysql/aurora/?tab=host

Amazon DynamoDB는 완전관리형 NoSQL 데이터베이스 서비스로서 원활한 확장성과 함께 빠르고 예측 가능한 성능을 제공합니다. DynamoDB는 분산 데이터베이스를 운영하고 크기 조정하는 데 따른 관리 부담을 줄여서 하드웨어 프로비저닝, 설정 및 구성, 복제, 소프트웨어 패치 또는 클러스터 크기 조정에 대해 걱정할 필요가 없게 합니다.

또한 DynamoDB는 유휴 시 암호화를 제공하여 중요한 데이터 보호와 관련된 운영 부담 및 복잡성을 제거합니다. 

DynamoDB를 통해 원하는 양의 데이터를 저장 및 검색하고 어느 수준의 요청 트래픽도 처리할 수 있는 데이터베이스 테이블을 생성할 수 있습니다. 다운타임 또는 성능 저하 없이 테이블의 처리 능력을 확장 또는 축소할 수 있습니다. 

DynamoDB는 만료된 항목을 테이블에서 자동으로 삭제할 수 있으므로 스토리지 사용량과 더 이상 관련 없는 데이터를 저장하는 비용을 줄일 수 있습니다.

DynamoDB 유지 시간(TTL)을 사용하여 항목 만료 

PyQt6 란

Python GUI 모듈입니다.  GUI를 지원하는 모듈은 많은데 tkinter와 pyqt 중 기능과 디자인 측면에서 더 우수하다고 생각된 pyqt를 선정했습니다.

PyQt는 Python + Qt를 합쳐서 지은 이름으로, C++ 기반의 GUI Framework인 Qt를 Python에서 사용할 수 있게 만든 패키지입니다.

PyQt6 설치

pip install 명령어로 pyqt6를 설치합니다.

pip install pyqt6

* SSL: CERTIFICATE_VERIFY_FAILED] 관련 오류가 발생하면 아래 문서 참조

pip package install SSL 인증서 Error 해결 (error: [SSL: CERTIFICATE_VERIFY_FAILED])

또는 아래처럼 입력하여 설치합니다.

pip install --trusted-host pypi.python.org --trusted-host files.pythonhosted.org --trusted-host pypi.org pyqt6

⚙ 창 만들기

* 패키지 import

from PyQt6.QtWidgets import QApplication, QWidget
# 명령줄 인수에 액세스하는 데 필요
import sys

from PyQt6.QtWidgets import QApplication, QWidget
# Only needed for access to command line arguments
import sys

# You need one (and only one) QApplication instance per application.
# 애플리케이션당 하나의 QApplication 인스턴스가 필요합니다.
# Pass in sys.argv to allow command line arguments for your app.
# 앱에 대한 명령줄 인수를 허용하려면 sys.argv를 전달합니다.
# If you know you won't use command line arguments QApplication([]) works too.
# 명령줄 인수를 사용하지 않는다는 것을 안다면 QApplication([])도 작동합니다.
app = QApplication(sys.argv)

# 창이 될 Qt 위젯을 만듭니다.
window = QWidget()

# 중요!!!!!! Windows는 기본적으로 숨겨져 있습니다.
window.show()  

# Start the event loop.
app.exec()