Datastreamの監視設計
関連issue
JIRA URLs:
目的
事業部には、ほぼリアルタイムという期待値で調整して、実際に当日の診察で利用されるもの。 診察に影響が出るものであり不具合を早期に検知・対応できるようにする。
参考
https://cloud.google.com/datastream/docs/monitor-a-stream?hl=ja
https://cloud.google.com/datastream/docs/best-practices-general?hl=ja
考え方
ベストプラクティスにあった監視項目も踏まえて
データの更新頻度
- メトリクスが見当たらないのと状況によってまちまちで閾値が難しい。
- 正常にデータを更新できているかはログ監視で担保する
ストリームのサポートされていないイベント数
監視する。ただしdatadogのメトリクスに出てこないためGCPのアラートポリシーで対応となる。
メトリクスでも出るはずだが、ログの方が内容がわかりやすくてトラブルシューティングや一次対応しやすいかも。(どちらにせよログを見に行くことになるはず)
ストリームの合計レイテンシ
- ベストプラクティスに則って合計レイテンシを監視する。
- datadogに50pでのメトリクスがあるのでこれを要件の10分以上でアラート。
jsxシステム レイテンシ: Datastream のイベント処理にかかる時間。 この間隔は、Datastream がイベントを読み取ってから 転送先に書き込まれるまでの時間として計算されます。 合計レイテンシ: データがソースに書き込まれるまでの時間と、 対応するイベントが転送先に書き込まれる時間の差。データの鮮度
- 転送が動いているが追いつかずにデータの差分が大きくなった場合に気付けた方が良さそう。
- Datadogのメトリクスにあるため監視する。
送信元と送信先の間の時間差を示します。 DataStream が送信元の新しいデータを最後に確認してから経過した時間として計算されます (新しいデータが検出されたかどうかは関係ありません)。
ここではステータスとレイテンシを取りたいという話をした
監視項目
ステータス
- GCPアラートポリシー(ログ監視)で実装
- フィルタ
severity="ERROR" AND jsonPayload.eventCode="STREAM_STATE_CHANGED" AND resource.labels.stream_id="online-karte-service"- タイムウィンドウ : 5m
- critical : エラー1件以上
合計レイテンシ
- Datadogで実装
- タイムウィンドウ : 5m
- critical : 10分以上
データの鮮度
- Datadogで実装
- タイムウィンドウ : 5m
- critical : 10分以上
サポートされていないイベント数
GCPアラートポリシー(ログ監視)で実装
フィルタ
severity="WARNING" AND jsonPayload.eventcode="UNSUPPORTED_EVENTS_DISCARDED" AND resource.labels.stream_id="online-karte-service"タイムウィンドウ : 5m
critical : 1件以上
TODO
今後検討が必要な項目:
今後の検討課題
Datastreamの監視通知の改善
経緯
- Slackでのフェイルオーバー事象: https://fastdoctor-dev.slack.com/archives/C09PCQR78SY/p1761684024584899
- datastream側のプロキシの参照しているエンドポイントが古くてdatastreamが停止
- Slack議論: https://fastdoctor-dev.slack.com/archives/C07BWK04H53/p1761719760967299?thread_ts=1761719548.867609&cid=C07BWK04H53
- 課題として認識済み: https://github.com/fastdoctor-jp/terraform_for_aws/blob/develop/docs/tasks/sre-1687.md
課題
現状、以下の課題がある:
- 一度通知されてから数時間後に通知されて気づけない
- ステータスがエラー監視が通知されない
- 対応方法がすぐにわからない。手順がわからない
やりたいこと
- 通知が継続してメンションされるようにする
- ステータスがエラー監視が通知される
- 通知内容に手順もわかるようにする
対象サービス
- online-karte
- online-ops
目的 (Objective)
信頼性向上
完了の定義 (Definition of Done)
- datastreamの不具合の通知が継続してメンションされること
- ステータスがエラー監視が通知されること
- 通知内容に手順もわかるようになっている