自己紹介

岩見彰太

Software Engineer @newmo株式会社

Platform Team

CyberAgent → newmo

好きな Datadog の機能：Error Tracking

GitHub: BIwashi
X: @B_Sardine

Monorepo Development

• newmo ではモノレポで開発を行っている
  • 全てのアプリケーションやマイクロサービスのコードを単一のリポジトリで管理
  • マイクロサービスとしての独立性を維持
  • 開発効率と保守性の両立

Error Monitor の現状

Log Monitor

• アプリケーションログに対して、クエリした結果を通知
  • ログレベルをエラーにすべきではないところが残存
  • Monitor のクエリで - を使用して随時に除外
• クエリにログファセットが多く使用
  • 使用自体は問題ないが、予約済み属性（e.g. service/env/version）を使用するところも facet になっており保守が大変

@gcp.project_id:hoge-dev -@log.attributes.error.message:"hoge が発生しました" 
-@code:foo ・・・

Log Monitor と運用の課題

重要度の判定と除外

• 開発中はログが発生しても即座に修正まで行えないこともあった
• 重要なエラーも軽微なエラーも同一に通知されチャンネルの流量が増大
• 除外するためのクエリ修正が増加

オーナーシップの明確化

• エラーがどのマイクロサービス起因なのかが分かりにくい
• マイクロサービスのオーナーが確認するまでは放置されがちに…

Log Monitor と運用の課題

重要度の判定と除外

• 開発中はログが発生しても即座に修正まで行えないこともあった
• 重要なエラーも軽微なエラーも同一に通知されチャンネルの流量が増大
• 除外するためのクエリ修正が増加

適切にトリアージができていない

オーナーシップの明確化

• エラーがどのマイクロサービス起因なのかが分かりにくい
• マイクロサービスのオーナーが確認するまでは放置されがちに…

適切にエスカレーションができていない

Error Tracking

• エラーログに含まれている特定の attibutes を元に Datadog がエラーを選別
  • error.message
  • error.stack
  • error.kind

Issue

• エラーは Issue という単位で選別される
• Status という属性を持っている

Issue Status

4種類のステータスを持っている

For Review

• 問題が新規発生 or リグレッションして確認が必要な状態

Reviewed

• トリアージ済、現在修正中の状態

Ignored

• 何かアクションする必要がない状態
• 基本的に Error で表示すべきではないもの

Resolved

• エラーを修正した状態

Monitor の設定

Logs ではなく Error Tracking

New Issue を選択

新規の Issue が
作成 or リグレッションされた時に通知

New Issue の対象

• New Issue の対象は新規発生した or リグレッションした Issue のみ
  • リグレッション：一度 Resolved になった Issue が再発した時

Automatic resolution

Datadog は以下の条件で自動的に Issue の Status を For Review -> Resolved に変更する

• 最後に issue の error が発生したのが14日以上前のバージョンで新しいバージョンで同様のエラーが初めて発生
• もし version tag が存在してないなかった場合、14日以内にその issue にエラーが発生していない場合

Regression Detection

• 一度 Resolved になった Issue が再発した時に自動で For Review に変更
• Regression というタグがつけられる

Case Management

• チケットを作成して、Issue を管理
• Error Tracking と連携して、Error Issue に紐づいた Case を作成可能
• エラー発生理由や紐づくチケットなどを記載可能

余談：Workflow Automation で Linear と Casa Management 連携（構想）

• Casa Management ではデフォルトで Jira, ServiceNow と連携が可能
• Linear を使用しているが、Datadog では公式で対応していない
• しかし Workflow Automation には Case Management のトリガーが存在

Linear 連携を自作可能（なはず）

1. Slack の通知を確認

• Slack の通知を確認
• Error 内容の概要を確認して、Issue ページに飛ぶ

2. Issue を確認

• message や stack trace などから原因を特定
• 状況によって Status を
  変更

• 原因が特定でき、修正が必要そうな場合

  • REVIEWED に変更（14日間は通知が来ません）
  • Actions → Create a case で case を作成して、修正用の Liner のチケットを張るなどして紐づけておく

• 原因が特定できず、かつ発生頻度が非常に少ない場合

  • RESOLVED に変更（再度発生したら即座に regression として通知される）
  • Actions → Create a case で case を作成して、発生条件やなぜ一旦放置としたかなどの理由をメモとして記載しておく

• 原因も特定できているが、基本的に直す予定がない場合

  • IGNORED に変更（今後 error tracking 関係の Monitor の対象外になる）
  • Actions → Create a case で case を作成して、放置理由を記載する

3. Case を作成

• エラーの原因や修正方法などを記載
• チケットを作成して、修正用のチケットを張るなどして紐づけておく

マイクロサービス開発メンバーの
Slack ユーザーグループにメンションをしたい

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

問題

• Datadog の Monitor での Slack ユーザーグループへの通知はグループ ID を指定する必要がある
  • <!subteam^GROUP_ID> という形式で指定する必要がある
  • log.attributes.service でマイクロサービス名が特定できているが、そこに紐づくグループ ID がないので、メンションできない

Reference Tables

• Datdog にすでにある情報に
  メタデータを追加することができる
• csv 形式で指定
• データソースは直接 Upload 以外にも、S3 / GCS / Azure Storage を指定可能

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
.
.
.

Lookup Processor で Reference Tables を指定

• ログの service.name から Slack User Group ID を反映
• ログに Slack User Group ID が含まれるようになる

Monitor の Message で指定

• ログの attributes に group id が追加されているのでそれを指定

動的にメンションする
Slack User Group を変更

• マイクロサービス名によってメンション先を変える

まとめ

エラーの適切なトリアージ

• Error Tracking を使用して適切にエラーを選別
• Status を活用してトリアージ
• Case Management でエラーの現状とチケットを紐付け

エラーのオーナーを明確化

• Reference Tables でマイクロサービス名と Slack User Group ID を紐付け
• エラーによってメンション先を変えることで、オーナーに適切に通知