データベースの正常性やパフォーマンスを可視化するDatadog Database Monitoring

:::note info
この記事は [Datadog Advent Calendar 2023](https://qiita.com/advent-calendar/2023/datadog)  カレンダーの 24日目の記事です。
:::

本記事では業務で使用していて、非常に有用に感じたDatadogの Database Monitoring機能について、どのような情報が取得できるかをキャプチャと共に紹介します。

# Datadog Database Monitoring (DBM)について

公式ドキュメントはこちらとなります。
https://docs.datadoghq.com/ja/database_monitoring/

Datadog Database Monitoringは、すべてのホストにわたるデータベースの詳細な可視性を提供してくれる機能です。
何か問題が発生した時のトラブルシューティングや過去のクエリパフォーマンスメトリクスを掘り下げることが可能です。

執筆時点で対応しているDBは次の通りです。
- Postgres
- MySQL
- Oracle
- SQL Server

今回はSQL Server環境で有効化しています。

# リアルタイム監視やトラブルシューディングでの活用

## DBで滞留しているクエリの量・詳細の確認
DBMのView Related画面からクエリのWait状況を確認することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/b5d3bc9f-01b7-cd18-8574-e23105aea109.png)
各クエリをクリックすることでそれぞれのクエリの詳細を確認できるので、よく滞留しているクエリの分析をこちらから進めることが可能です。
過去に記録された情報と比べて異常(Anomaly)な状態が発生していると判断されるような場合には、その旨が表示されます。
![CPUAnomaly.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/704104c9-1eca-c2ae-e897-35e67bbcb62f.png)

また、収集されるクエリは正規化されてパラメータ部分は `?`に置き換えられるため、機密情報を閲覧できない開発者にも安心して共有することが可能です。
[データベースモニタリングの収集データ - 機密情報](https://docs.datadoghq.com/ja/database_monitoring/data_collected/#%E6%A9%9F%E5%AF%86%E6%83%85%E5%A0%B1)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/ff1ed2d5-e0c7-f9ef-d1fd-8087c38ecf68.png)


## 現在実行中のクエリの確認
View Related画面の `Active Connections` のタブから現在実行中のクエリを見ることができます。(数秒間隔で収集しているので少しラグはあり)
これによって長時間実行されているクエリの詳細や今どのくらいのクエリが実行されているかなどを確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/c2c065dc-8e98-a6b6-b3f9-7c71c1405f1c.png)

## ブロッキングが発生しているクエリの確認
`Blocking Queries` タブからはブロッキングによる影響や原因となった`Root Blocker`の詳細を確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/dba89c45-5e23-c1e8-c2b0-f8a94e9dbf4c.png)

ブロッキングのサンプルからは、`Root Blocker`からブロッキングが連なっている様子なども確認可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/61922683-957d-f35d-2d89-9fa09332acf0.png)


# 過去のクエリパフォーマンスの掘り下げ
## リソース使用率の高いクエリの調査
Query Metrics画面からは指定した期間のクエリの統計を見ることができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/bac2273a-2ebc-f5ef-8669-3493a0507e1d.png)

表示する情報は増やすことができ、以下の情報を表示することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/54ca8269-9c9a-bced-2d6a-cddffa61a211.png)
メモリ使用量が大きいクエリを改善したい場合などには、GrantMemory系にチェックを入れて表示した上でソートを行うことで、修正すべきクエリを探すことが可能となります。


## 各クエリの実行統計・実行計画の確認
各クエリの詳細な履歴として実行時間や実行計画を閲覧することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/c52a4f2a-4b63-b420-d1a0-359b606c8bdb.png)

実行計画は画面上でグラフィカルに見ることもできるし、リスト形式で見ることもできます。
ダウンロードしてSQLServer Management Studioなどを通して手元で確認することも可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/02832676-be30-8f0b-eaa8-ec83389f9506.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/af525e52-ccc4-c36e-c57a-8a058f28695f.png)

クエリのパフォーマンスの統計を見ていると一時的にパフォーマンスが悪化/改善しているような状況が見られることがあります。
それぞれで記録された実行計画が異なっていた場合には、特定の実行計画が原因であると推察でき、改善への検討に繋げることができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/dd5fa013-cb6f-0554-193e-388ebe8a70ed.png)


# Monitor(アラート通知)との連携

Database Monitoringによって取得されるメトリクスはMonitor側にも活用できます。
waitしているクエリの数は `sqlserver.activity.waits` に記録されるため、「CPU待ちが10セッション以上になったらアラートを飛ばしたい」などのような場合には次のようなアラートが設定できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299916/5db0c3b3-8a41-a0ca-e462-d3d70415685c.png)

クエリの実行回数など、周期的に安定しているメトリクスに関しては[異常検知モニター](https://docs.datadoghq.com/ja/monitors/types/anomaly/) などを設定すると通常値と異なる動きを検知できるようになります。

## カスタムクエリによるメトリクス化
カスタムクエリを設定することでDBのデータを元にメトリクスを作成できます。 ([カスタムメトリクスの収集(SQL Serverの場合)](https://docs.datadoghq.com/ja/integrations/guide/collect-sql-server-custom-metrics/))

こちらを活用することで
- 毎分レコードが登録されるはずのテーブルが未登録であったらアラート通知
- エラーログテーブルに大量にレコードが登録されたらアラート通知

のように登録されたデータを元にしたMonitorの作成も可能となります。

# 終わりに

Datadog Database Monitoringを活用することで、上記のような可視化による各種分析の効率化や、正常性に問題が生じたときにいち早く検出することができ、信頼性向上へと繋げることができます。

また、複数のデータベースを運用している場合にも、統一してモニタリングができるようになるため非常に有用です。