モノレポ開発のエラー、誰が見る？Datadog で実現する適切なトリアージとエスカレーション

システムの可視化と最適化をDatadogと学ぶ
登壇資料
https://rosca.connpass.com/event/344126/

Transcript

1. モノレポ開発のエラー、誰が見る？ Datadog で実現する適切な トリアージとエスカレーション newmo株式会社 岩見彰太 github: @BIwashi x: @B_Sardine © 2025 newmo | #roscafe
2. 自己紹介 岩見彰太 Software Engineer @newmo株式会社 Platform Team CyberAgent → newmo 好きな Datadog の機能：Error Tracking GitHub: BIwashi X: @B_Sardine © 2025 newmo | #roscafe 2
3. 本日のテーマ モノレポ開発における エラー管理とトリアージの最適化 © 2025 newmo | #roscafe 3
4. Monorepo Development newmo ではモノレポで開発を行っている 全てのアプリケーションやマイクロサービスのコードを単一のリポジトリで管理 マイクロサービスとしての独立性を維持 開発効率と保守性の両立 背景 © 2025 newmo | #roscafe 4
5. Error Monitor の現状 Log Monitor アプリケーションログに対して、クエリした結果を通知 ログレベルをエラーにすべきではないところが残存 Monitor のクエリで - を使用して随時に除外 クエリにログファセットが多く使用 使用自体は問題ないが、予約済み属性（e.g. service / env / version ）を使用するところも facet になっ ており保守が大変 @gcp.project_id:hoge-dev -@log.attributes.error.message:"hoge が発生しました" -@code:foo ・・・ 背景 © 2025 newmo | #roscafe 5
6. Log Monitor と運用の課題 重要度の判定と除外 開発中はログが発生しても即座に修正まで行えないこともあった 重要なエラーも軽微なエラーも同一に通知されチャンネルの流量が増大 除外するためのクエリ修正が増加 オーナーシップの明確化 エラーがどのマイクロサービス起因なのかが分かりにくい マイクロサービスのオーナーが確認するまでは放置されがちに… 背景 © 2025 newmo | #roscafe 6
7. Log Monitor と運用の課題 重要度の判定と除外 開発中はログが発生しても即座に修正まで行えないこともあった 重要なエラーも軽微なエラーも同一に通知されチャンネルの流量が増大 除外するためのクエリ修正が増加 適切にトリアージができていない オーナーシップの明確化 エラーがどのマイクロサービス起因なのかが分かりにくい マイクロサービスのオーナーが確認するまでは放置されがちに… 適切にエスカレーションができていない 背景 © 2025 newmo | #roscafe 7
8. 課題 エラーの適切なトリアージ エラーのオーナーを明確化 © 2025 newmo | #roscafe 8
9. エラーの適切なトリアージ エラーを適切に選別する エラーを種類ごとに分類 重要度やステータスを個別管理 通知対象から適切に除外 エラー単位で除外 エラーのオーナーを明確化 適切にマイクロサービスを特定 attribute を適切に指定 オーナーに適切に通知 Error Message やグループメンションを活用 課題 © 2025 newmo | #roscafe 9
10. エラーの適切なトリアージ Error Tracking Case Management エラーを適切に選別する エラーを種類ごとに分類 重要度やステータスを個別管理 通知対象から適切に除外 エラー単位で除外 エラーのオーナーを明確化 Reference Tables Log Pipeline 適切にマイクロサービスを特定 attribute を適切に指定 オーナーに適切に通知 Error Message やグループメンションを活用 課題 © 2025 newmo | #roscafe 10
11. エラーの適切なトリアージ Error Tracking Case Management © 2025 newmo | #roscafe 11
12. Error Tracking エラーログに含まれている 特定の attibutes を元に Datadog がエラーを選別 error.message error.stack error.kind Error Tracking 引用: Datadog Error Tracking Backend © 2025 newmo | #roscafe 12
13. Issue エラーは Issue という単位で選別される Status という属性を持っている Error Tracking © 2025 newmo | #roscafe 13
14. Issue Status 4種類のステータスを持っている Error Tracking © 2025 newmo | #roscafe 14
15. For Review 問題が新規発生 or リグレッションして確認が必要な状態 Reviewed トリアージ済、現在修正中の状態 Ignored 何かアクションする必要がない状態 基本的に Error で表示すべきではないもの Resolved エラーを修正した状態 Error Tracking © 2025 newmo | #roscafe 15
16. Monitor の設定 Logs ではなく Error Tracking Error Tracking © 2025 newmo | #roscafe 16
17. New Issue を選択 新規の Issue が 作成 or リグレッションされた 時に通知 Error Tracking © 2025 newmo | #roscafe 17
18. New Issue の対象 New Issue の対象は新規発生した or リグレッションした Issue のみ リグレッション：一度 Resolved になった Issue が再発した時 Automatic resolution Datadog は以下の条件で自動的に Issue の Status を For Review -> Resolved に変更する 最後に issue の error が発生したのが14日以上前のバージョンで新しいバージョンで同様のエラー が初めて発生 もし version tag が存在してないなかった場合、14日以内にその issue にエラーが発生していな い場合 Error Tracking © 2025 newmo | #roscafe 18
19. Regression Detection 一度 Resolved になった Issue が再発した時に自動で For Review に変更 Regression というタグがつけられる Error Tracking 引用: Error Tracking | Datadog © 2025 newmo | #roscafe 19
20. Error Tracking 引用: Issue States in Error Tracking © 2025 newmo | #roscafe 20
21. Case Management チケットを作成して、Issue を管理 Error Tracking と連携して、Error Issue に紐づいた Case を作成可能 エラー発生理由や紐づくチケットなど を記載可能 Case Management © 2025 newmo | #roscafe 21
22. 余談：Workflow Automation で Linear と Casa Management 連携（構想） Casa Management ではデフォルトで Jira, ServiceNow と連携が可能 Linear を使用しているが、Datadog では公式で対応していない しかし Workflow Automation には Case Management のトリガーが存在 Linear 連携を自作可能（なはず） Case Management © 2025 newmo | #roscafe 22
23. Case Management © 2025 newmo | #roscafe 23
24. トリアージの流れ © 2025 newmo | #roscafe 24
25. 1. Slack の通知を確認 Slack の通知を確認 Error 内容の概要を確認して、Issue ペ ージに飛ぶ トリアージ © 2025 newmo | #roscafe 25
26. 2. Issue を確認 message や stack trace な どから原因を特定 状況によって Status を 変更 トリアージ © 2025 newmo | #roscafe 26
27. 原因が特定でき、修正が必要そうな場合 REVIEWED に変更（14日間は通知が来ません） Actions → Create a case で case を作成して、修正用の Liner のチケットを張るなどして紐づけておく 原因が特定できず、かつ発生頻度が非常に少ない場合 RESOLVED に変更（再度発生したら即座に regression として通知される） Actions → Create a case で case を作成して、発生条件やなぜ一旦放置としたかなどの理由をメモとして 記載しておく 原因も特定できているが、基本的に直す予定がない場合 IGNORED に変更（今後 error tracking 関係の Monitor の対象外になる） Actions → Create a case で case を作成して、放置理由を記載する トリアージ © 2025 newmo | #roscafe 27
28. 3. Case を作成 エラーの原因や修正方法な どを記載 チケットを作成して、修正 用のチケットを張るなどし て紐づけておく トリアージ © 2025 newmo | #roscafe 28
29. トリアージ © 2025 newmo | #roscafe 29
30. エラーのオーナーを明確化 Reference Tables Log Pipeline © 2025 newmo | #roscafe 30
31. マイクロサービス開発メンバーの Slack ユーザーグループにメンションをしたい アラートチャンネルには、全てのマイクロサービスのエラーが通知される マイクロサービスごとにチャンネルを分けることもできるが、まだそれをやるまでの規模ではない せっかく Monorepo なので、チャンネルもできるだけ分割しないで進めたい 開発メンバーも流動的に移動している オーナーメンバーがトリアージできていなかった場合はエスカレーションしたい マイクロサービス開発メンバーの Slack ユーザーグループにメンションをしたい Error Tracking の Issue の service（マイクロサービス単位）ごと オーナーを明確化 © 2025 newmo | #roscafe 31
32. 問題 Datadog の Monitor での Slack ユーザーグループへの通知はグループ ID を指定する必要がある <!subteam^GROUP_ID> という形式で指定する必要がある log.attributes.service でマイクロサービス名が特定できているが、そこに紐づくグループ ID がないの で、メンションできない オーナーを明確化 © 2025 newmo | #roscafe 32
33. Reference Tables Datdog にすでにある情報に メタデータを追加することができる csv 形式で指定 データソースは直接 Upload 以外に も、S3 / GCS / Azure Storage を指定 可能 Reference Tables © 2025 newmo | #roscafe 33
34. Reference Tables で Slack User Group ID を紐付ける csv に紐付けを記載 csv は github で管理 変更されたら GCS を更新 更新された csv を Datadog が自動反映 service,id,name component.hoge,aaaabbbb1234,alert-server-component-hoge component.fuga,cccdddd4567,alert-server-component-fuga component.piyo,eeefff8901,alert-server-component-piyo . . . Reference Tables © 2025 newmo | #roscafe 34
35. Lookup Processor で Reference Tables を指定 ログの service.name から Slack User Group ID を反映 ログに Slack User Group ID が含まれるよう になる Reference Tables © 2025 newmo | #roscafe 35
36. Monitor の Message で指定 ログの attributes に group id が追加されて いるのでそれを指定 Reference Tables © 2025 newmo | #roscafe 36
37. 動的にメンションする Slack User Group を変更 マイクロサービス名によってメンショ ン先を変える Reference Tables © 2025 newmo | #roscafe 37
38. まとめ © 2025 newmo | #roscafe 38
39. まとめ エラーの適切なトリアージ Error Tracking を使用して適切にエラーを選別 Status を活用してトリアージ Case Management でエラーの現状とチケットを紐付け エラーのオーナーを明確化 Reference Tables でマイクロサービス名と Slack User Group ID を紐付け エラーによってメンション先を変えることで、オーナーに適切に通知 Reference Tables © 2025 newmo | #roscafe 39