DatadogのDatabase Monitoringを検証しているのだが、ダッシュボードの使い方がまったくわからん。MySQL 8は対応してた。
— adachin👾SRE (@adachin0817) February 28, 2022
というわけで毎度Datadogの設定にハマる私ですが、今回は去年の10月頃にリリースされたDatadogの新機能である Database Monitoring を利用してAurora MySQL 8のクエリをモニタリングしてみました。Datadogのドキュメントとプラスして補足も兼ねてブログしたいと思います。
Database Monitoring
https://www.datadoghq.com/ja/product/database-monitoring/
Datadog データベースモニタリングでは、すべてのデータベースのクエリメトリクスと実行計画を1つの場所で見ることができます。データベースモニタリングでは、コストのかかるクエリや遅いクエリを素早くピンポイントで特定し、正確な実行内容を掘り下げてボトルネックに対処できます。また、クエリとホストメトリクスの相関関係により、リソースの制約がデータベースのパフォーマンスに与える影響を容易に特定し理解できます。1ホスト$ 70で利用可能。
データベースは日々生きているといっても過言ではありません。運用していくと突然アラートが鳴り、Webのレスポンスが悪くなり、大量のスロークエリが出現します。その中でどんなSQLが実行しているのか、コード内であればどこが問題なのかなど迅速に調査しながら改善する必要があります。そこでDatadogのAPM(以下ブログより)と今回のDatabase Monitoringを利用すれば調査の工数がかからなくなります。早速、初期設定があるので試していきましょう。
Setting Up Database Monitoring for Aurora managed MySQL
https://docs.datadoghq.com/ja/database_monitoring/setup_mysql/aurora/?tab=mysql57
※Aurora MySQL 8がまだなさそうなので5.7のドキュメントを参考にしています。
- パラメーターグループの修正
|
1 2 3 4 5 6 |
・performance_schema 1 ・performance_schema_consumer_events_statements_current 1 ・performance_schema_consumer_events_statements_history 1 ・performance_schema_consumer_events_statements_history_long 1 ・performance_schema_max_digest_length 4096 ・performance_schema_max_sql_text_length 4096 |
- datadog DBユーザーの作成と権限設定
|
1 2 3 4 |
CREATE USER datadog@'%' IDENTIFIED BY 'hogeeeee'; GRANT REPLICATION CLIENT ON *.* TO datadog@'%'; GRANT PROCESS ON *.* TO datadog@'%'; GRANT SELECT ON performance_schema.* TO datadog@'%'; |
- スキーマの作成
|
1 2 3 |
CREATE SCHEMA IF NOT EXISTS datadog; GRANT EXECUTE ON datadog.* to datadog@'%'; GRANT CREATE TEMPORARY TABLES ON datadog.* TO datadog@'%'; |
- explanを収集するようにストアドプロシージャの設定
|
1 2 3 4 5 6 7 8 9 10 11 |
DELIMITER $$ CREATE PROCEDURE hoge.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 hoge.explain_statement TO datadog@'%'; |
※hogeはDB名を指定すること
- ExplainPlanを収集するすべてのスキーマでストアドプロシージャを設定
|
1 2 3 4 5 6 7 8 9 10 11 |
DELIMITER $$ CREATE PROCEDURE hoge.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 hoge.explain_statement TO datadog@'%'; |
- performance_schema.events_statements_*を有効
|
1 2 3 4 5 6 7 8 |
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_%'; END $$ DELIMITER ; GRANT EXECUTE ON PROCEDURE datadog.enable_events_statements_consumers TO datadog@'%'; |
まずはクエリ監視のために追加するパラメーターグループですが、一旦クラスターとインスタンスの２つに設定しました。必ずDBの再起動をしないと反映されないので気をつけましょう。反映されているかは以下のSQL叩けば確認できます。
|
1 2 3 4 5 6 7 |
mysql> SHOW VARIABLES LIKE 'performance_schema'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | performance_schema | ON | +--------------------+-------+ 1 row in set (0.01 sec) |
また、Datadog Agentは統計とクエリを収集するために、データベースへの読み取り専用ユーザーが必要が必要になるので上記のように設定しましょう。
- Datadog Agentのインストールと設定
/etc/datadog-agent/conf.d/mysql.d/conf.yaml
|
1 2 3 4 5 6 7 8 |
init_config: instances: - dbm: true host: xxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com port: 1234 username: datadog password: hoge |
今回はテストなのでEC2にDatadog Agentをインストールしてライターインスタンスに対して接続してみました。ECS/FargateであればDatadogコンテナを準備すればいけますね。これで設定は完了となります。
APM > Databases
モニタリングすることができました！実際の動作しているクエリやレスポンスなどが可視化されていることで、スロークエリも早期発見や予測なども調査しやすくなったと思います。
まとめ
AWSにもRDS Performance Insightsがありますが、DatadogのDatabase Monitoringの方がより細かく可視化されているかなといった印象を受けました。コストは1ホスト$70で割高ですが、サービスの質をより上げるのには必要でしょうね。これからバシバシ活用していきます！
※ちなみにPerformance Insightsも条件付きなので忘れないようにしたいところですな。
0件のコメント