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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Error Monitor の現状 Log Monitor アプリケーションログに対して、クエリした結果を通知ログレベルをエラーにすべきではないところが残存 Monitor のクエリで - を使用して随時に除外クエリにログファセットが多く使用使用自体は問題ないが、予約済み属性（e.g. service / env / version ）を使用するところも facet になっており保守が大変 @gcp.project_id:hoge-dev [email protected]:"hoge が発生しました" -@code:foo ・・・背景 © 2025 newmo | #roscafe 5

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Log Monitor と運用の課題重要度の判定と除外開発中はログが発生しても即座に修正まで行えないこともあった重要なエラーも軽微なエラーも同一に通知されチャンネルの流量が増大除外するためのクエリ修正が増加適切にトリアージができていないオーナーシップの明確化エラーがどのマイクロサービス起因なのかが分かりにくいマイクロサービスのオーナーが確認するまでは放置されがちに… 適切にエスカレーションができていない背景 © 2025 newmo | #roscafe 7

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

エラーの適切なトリアージ Error Tracking Case Management エラーを適切に選別するエラーを種類ごとに分類重要度やステータスを個別管理通知対象から適切に除外エラー単位で除外エラーのオーナーを明確化 Reference Tables Log Pipeline 適切にマイクロサービスを特定 attribute を適切に指定オーナーに適切に通知 Error Message やグループメンションを活用課題 © 2025 newmo | #roscafe 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

余談：Workflow Automation で Linear と Casa Management 連携（構想） Casa Management ではデフォルトで Jira, ServiceNow と連携が可能 Linear を使用しているが、Datadog では公式で対応していないしかし Workflow Automation には Case Management のトリガーが存在 Linear 連携を自作可能（なはず） Case Management © 2025 newmo | #roscafe 22

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

原因が特定でき、修正が必要そうな場合 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

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

マイクロサービス開発メンバーの Slack ユーザーグループにメンションをしたいアラートチャンネルには、全てのマイクロサービスのエラーが通知されるマイクロサービスごとにチャンネルを分けることもできるが、まだそれをやるまでの規模ではないせっかく Monorepo なので、チャンネルもできるだけ分割しないで進めたい開発メンバーも流動的に移動しているオーナーメンバーがトリアージできていなかった場合はエスカレーションしたいマイクロサービス開発メンバーの Slack ユーザーグループにメンションをしたい Error Tracking の Issue の service（マイクロサービス単位）ごとオーナーを明確化 © 2025 newmo | #roscafe 31

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

まとめエラーの適切なトリアージ Error Tracking を使用して適切にエラーを選別 Status を活用してトリアージ Case Management でエラーの現状とチケットを紐付けエラーのオーナーを明確化 Reference Tables でマイクロサービス名と Slack User Group ID を紐付けエラーによってメンション先を変えることで、オーナーに適切に通知 Reference Tables © 2025 newmo | #roscafe 39