監視・アラート──Lagだけでは不十分、体感遅延を主語にする

TL;DR

KafkaやKinesisの Lag（遅れ）や IteratorAge だけを見ても、ユーザー体験は守れません。
本当に大事なのは エンドツーエンド遅延（E2E Latency）──「イベントが発生してから処理されるまでに何秒かかったか」です。

アラートは「秒数 × パーセンタイル（p95/p99） × 継続時間」で設定するのがコツ。
監視は次の3本柱をバランスよく：

• 遅延（E2E）
• 基盤の健康状態
• エラー率

内部指標 vs ユーザー体感

• Kafka: consumer_group_lag
• Kinesis: GetRecords.IteratorAgeMilliseconds
  これらは「処理がどれくらい溜まっているか」を表す内部指標です。

でもユーザーにとっては「自分のデータが何秒で処理されたか」が全て。
そのため Producerが event_time を必ず付けることが重要です。

• E2E遅延 = now() – event_time
• ダッシュボードで p95/p99 をグラフ化し、アラート設定する

Kafkaで見るべきポイント

• Lag（グループ単位）：処理が追いついているか
• UnderReplicatedPartitions：ブローカーの健全性
• E2E遅延 (p95/p99)：ユーザー体感の実態
• DLQ流入率：不良イベントの割合

Kinesisで見るべきポイント

• IteratorAgeMilliseconds：基本の遅延指標
• ProvisionedThroughputExceeded：シャード不足を検知
• E2E遅延：アプリ側で必須
• DLQストリーム／S3件数：エラー発生率の把握

Flink / Kinesis Data Analytics

• Watermarkの遅延：処理の“時間の歪み”を確認
• BackPressure ratio：処理オペレーターごとの詰まり具合
• Checkpoint duration & size：堅牢性と遅延のバランスを見る

Djangoでの実装Tips

• DBに保存する時、**ingest_time（受信時刻）**も記録する
• ダッシュボードで process_time – event_time を計算し可視化
• Grafana / Datadogで p95/p99遅延を折れ線グラフ化すると直感的にわかりやすい

アラート設計の具体例

• E2E遅延 p95 > 2秒（リアルタイム系）or >10秒（バッチ系）を5分継続
• Lag > 10,000 を3分継続
• DLQ流入率 > 0.5% を5分継続
• Kafka: UnderReplicatedPartitions > 0 を即アラート

よくある落とし穴（アンチパターン）

まとめ

LagやIteratorAgeは“内部の様子”を見るのに役立ちますが、ユーザー体感の遅延は別物です。