Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Custom Query で監視が捗った話 / Monitoring with Custom Query
Search
akitok
May 29, 2024
Technology
0
290
Custom Query で監視が捗った話 / Monitoring with Custom Query
2024-05-29 Japan Datadog User Group Meetup#4
https://datadog-jp.connpass.com/event/317091/
akitok
May 29, 2024
Tweet
Share
More Decks by akitok
See All by akitok
明日から始める持続可能なドキュメンテーション戦略 / Sustainable Documentation Strategies: Documentation as a Product
akitok_
12
6.8k
ZOZOTOWNのProduction Readiness Checklistと信頼性向上の取り組み / Improvement the reliability of ZOZOTOWN with Production Readiness Checklist
akitok_
8
11k
How to setup Production Ready Istio?
akitok_
1
2.3k
Datadogと歩むZOZOTOWNの可観測性 / Observability of ZOZOTOWN with Datadog
akitok_
4
11k
Other Decks in Technology
See All in Technology
コンテナ・K8s研修 - 前半 コンテナ基礎・ハンズオン【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
170
Classmethod流のPlatform Engineering / classmethod-platform-engineering-devio2024
tomoki10
0
470
エンジニアリングマネージャーはどう学んでいくのか #devsumi / How Do Engineering Managers Continue to Learn and Grow?
expajp
4
1.3k
ギークの理想が7つ集まるエムスリーで夢を叶えよう - エムスリー株式会社
m3_engineering
1
260
dxd2024-生成AIに振り回された3か月間の成功と失敗/dxd2024-link-and-motivation
lmi
2
260
サービスの持続的な成長と技術負債について
siva_official
PRO
10
4.4k
AOAI Dev Day - Opening Session
yoshidashingo
2
440
Docker互換のセキュアなコンテナ実行環境「Podman」超入門
devops_vtj
6
3.2k
シフトレフトで挑む セキュリティの生産性向上
sekido
PRO
0
270
テストケースの自動生成に生成AIの導入を試みた話と生成AIによる今後の期待
shift_evolve
0
180
年間一億円削減した時系列データベースのアーキテクチャ改善~不確実性の高いプロジェクトへの挑戦~
lycorptech_jp
PRO
3
2.9k
地理情報とAPIのトレンド
nagix
0
160
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
29
2.5k
GraphQLとの向き合い方2022年版
quramy
36
13k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
325
21k
Optimising Largest Contentful Paint
csswizardry
18
2.6k
GraphQLの誤解/rethinking-graphql
sonatard
59
9.6k
Being A Developer After 40
akosma
72
580k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
35
6.3k
Side Projects
sachag
451
42k
The Cult of Friendly URLs
andyhume
75
5.9k
The Invisible Side of Design
smashingmag
294
50k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
662
120k
Transcript
2024-05-29 Japan Datadog User Group Meetup#4 @akitok Custom Query で監視が捗った話
About me • Akito Kobayashi ◦ X(Twitter) / @akitok_ ◦
2024-01 ~ キャディ株式会社 Platform Team に Join ◦ Datadog 歴 4 年 ▪ 前職のファッション EC サイトでも ⼤変お世話になりました ◦ AlloyDB の Datadog DBM サポートを ⼼待ちにしています
© CADDi Inc. サプライチェーンにまつわる上流‧下流のデータを相互に補完し合う 3 部品調達プラットフォーム 調達‧⽣産機能の⼀括 請け負いによる モノづくりの変⾰ 図⾯データ活⽤クラウド
図⾯データの アセット化による 社内システムの変⾰ 設計 調達 製造 販売 Technology Knowledge What’s CADDi ?
Today’s theme • Custom Query ??? ◦ Datadog Integration や
Datadog DBM の設定がされているデータベースに対し、 任意のSQLクエリを投げて、良い感じにカスタムメトリクスにするやつ クエリを発⾏し、結果を カスタムメトリクスとし て取り扱う SELECT hoge FROM … Dashboard Monitor
Usecases ex.1: 売上などのビジネス指標を可視化したい ex.2: ログイン失敗率などパフォーマンス指標 を可視化したい 売上が確定している注⽂情報を 取得して、メトリクス化する ⽇次売上情報 ⽉次売上情報
ログイン 試⾏ テーブル 全体のログイン失敗率 ログイン失敗の多いユーザ ログイン試⾏テーブルからユーザの ログイン試⾏記録を取得して、 メトリクス化する 注⽂情報 テーブル
Outbox Table Our usecase • ⾮同期処理におけるパフォーマンス指標を取得したい! ◦ 具体的には、Outbox パターン *1で⾮同期イベント処理をしているシステムで、
処理遅延‧イベントの滞留を監視したい Publisher Messaging Queue イベ ント ID イベ ント 名 発⽣ 時刻 バイ ナリ … … … … … … イベントが発⽣したらレコード追加され、 イベントが publish されたらレコードを更新する *1 https://microservices.io/patterns/data/transactional-outbox.html … : イベント SELECT hoge FROM … 滞留イベント数 イベントの最⼤滞留時間
Settings • データベース側の設定 ◦ 各データベースに対して、Integration 設定や DBM 設定が済んでいれば OK! ▪
Datadog 監視⽤のデータベースユーザーの追加や、必要な権限設定などを ⾏う必要があります ◦ 詳細は、利⽤しているデータベースごとにドキュメントを確認してください ◦ 私たちのサービスでは、データベースは CloudSQL と AlloyDB を利⽤している ので、以下のドキュメントなどを参照しました ▪ Setting Up Database Monitoring for Google Cloud SQL managed Postgres
Settings • Datadog 側の設定 ◦ データベースごとの conf ファイルを Agent に設定する
▪ PostgreSQLの場合、conf.d/postgres.d/conf.yaml に設定を⾏う ▪ instances.custom_queries に発⾏したいクエリとそのメトリクス定義を書く • metrics_prefix: metrics の prefix • query: 発⾏する query • columns.name: metrics の suffix • columns.type: metrics type
Settings • Datadog 側の設定 ◦ 私たちのユースケースでは、以下のような設定を⾏いました init_config: instances: - dbm:
true host: "<HOSTNAME>" port: "5432" username: "datadog" password: "<PASSWORD>" custom_queries: - metric_prefix: outbox query: SELECT COALESCE(MAX(EXTRACT(EPOCH FROM AGE(CURRENT_TIMESTAMP, occurred_at))), 0) AS max_processing_delay FROM outbox WHERE is_published = false columns: - name: max_processing_delay type: gauge tags: - query:custom tags: - env:<ENV> • metrics 名は outbox.max_processing_delay • outbox テーブルで is_published = false である ⾏から、最⼤処理遅延(秒)を計算‧返却させる • is_published = false が 0 件であるとき、No Data ではなく、最⼤処理遅延時間は 0 として扱 いたいので、COALESCE 関数で null ではなく 0 を返却させる • custom_queries 単位で custom metrics である ことを⽰す tag を指定し、instances 単位で発⽣ 環境を⽰す tag を指定することで、metrics を 切り分けやすくする
Settings • Datadog 側の設定 ◦ 設定値について、より詳細に知りたい場合は Datadog が提供する以下のドキュメ ントや、conf.yaml.example などが参考になります
( すべて PostgreSQL の例です ) ▪ Postgres Custom Metric Collection ▪ https://github.com/DataDog/integrations-core/blob/master/postgres/dat adog_checks/postgres/data/conf.yaml.example
Point to note • tag を効果的に使おう ◦ パフォーマンス指標であれば、どの環境で発⽣しているかどうかは⾮常に重要 ◦ tag
を⽤いて、メトリクスの所属する環境、条件などを明らかにしよう ▪ 各 custom query の単位で tag を指定するのも OK ▪ Agent 単位で tag を指定するのも OK • select 結果が 0 lines だったときに、どう扱いたいか? ◦ select 結果が 0 lines のときには、No Data として記録される ▪ 0 というデータで保持したいのか ▪ そのまま No Data として取り扱って、No Data アラートを投げたいのか
Point to note • データ取得周期に注意しよう ◦ データ取得周期はデフォルトで 15 秒 ◦
データ取得クエリによるデータベースの負荷が気になる、あるいはもっと細かい 頻度でデータがほしい場合は、min_collection_interval でチューニングできる ◦ ただし、DB Integration や DBM によるメトリクス取得周期も min_collection_interval で制御されるので、考慮が必要 ◦ custom query のみ実⾏周期をチューニングできる collection_interval オプション が近々サポートされそう? → https://github.com/DataDog/integrations-core/pull/16957
Conclusion • Custom Query 便利! • ビジネス KPI の可視化を⽬指すも良し パフォーマンスボトルネックの発⾒を⽬指すも良し
• 重要なメトリクスの可観測性を確保し、ヘルシーなサービス運⽤を!