モニタリングとロギング

1） iGamingで重要な理由

リアルタイムでのお金：預金の受け取り、即時支払い、ベットと賞金の計算、トーナメント-すべてが遅延や失敗に敏感です。
規制と監査：行動の完全なトレーサビリティが必要です（KYC/AML、支払い、責任あるプレーの制限）。
複雑な分散アーキテクチャ：APIゲートウェイ、決済オーケストレーション、EDA/Kafka、プロバイダサービス、モバイルクライアント、フロント、BIバス。
目標：MTTD/MTTRを削減し、金信号でSLOを維持し、インシデントレートを提供します。

2）観測可能性の基本概念

ログ：調査や監査に適した詳細イベント（構造化JSON）。
メトリクス：時間内の集計（TSDB）、 SLO/アラートに適しています。
トレース：サービス/ブローカー/データベースを介したリクエストの原因と効果チェーン（トレース/スパン）。
イベント：ドメインイベント（BetPlaced、 DepositApproved）-ビジネス指標とテクノロジーの橋渡し。

3）「ゴールデンシグナル」とiGaming用SLI/SLO

レイテンシー：クリティカルフロー（認可、デポジット、レート、セッション開始、スピン）にP95/P99します。
トラフィック：APIによるRPS、支払いによるTPS、イベントによるEPS。
エラー：5xx/4xxシェア、declow-rate、 failed-in、 providerエラー。
彩度：CPU、メモリ、IO、カフカラグ、DB接続、スレッドプール。

• SLI： '1-（failed_payments/ total_payments）'
• SLO： 99。30日間でカード承認が成功した場合の7％（エラー予算0。3%).

4）収集および処理アーキテクチャ

1.注入：代理店（OTelのコレクター/流暢なビット）、適用のSDK、 RUM/synthetics。
2.ルーティング：ブローカー/テレメトリーバス（OTLP/HTTP/GRPC）、フィルタ、PIIマスキング。

• メトリクス：TSDB（集計、ダウンサンプリング）。
• ログ：ホット（インデックス付き）/ウォーム（インデックスなし）/コールド（オブジェクトストレージ、WORM）。
• トレイル：リテンションとテールサンプリングを備えたタイムインデックスストレージ。
• 4.アナリティクス/アラート：ルール（PromQL/LogQL/SQL）、トラックとリリースとの相関。
• 5.ダッシュボード：テクニカル+ビジネスタイプ（支払い、RNG/プロバイダー、トーナメントエンジン）。

5）ログ標準（JSON）とイベントタクソノミ

厳格なJSONロギング、シングルキー、レベルを推奨します。

'DEBUG

その他：'auth。'、 'payment。'、 'gameplay。'、 'risk。'、 'psp。'、 'kyc。'、 'rg。'（責任あるゲーム）、'ops。'。

json
{
"ts": "2025-11-04T19:45:31. 842Z",
"lvl": "AUDIT",
"event_type": "payment. deposit_approved",
"correlation_id": "c-7d2c1f0b",
"trace_id": "2d6a9c0e4c0b1f72",
"span_id": "9f3a81d2a1c3b764",
"request_id": "r-8f12de9e",
"tenant": "brand_eu",
"psp": "acq_xyz",
"user_id_hash": "u:sha256:1e63…",
"device_id": "d-3c8f…",
"ip_trunc": "203. 0. 113. 0/24",
"amount_minor": 5000,
"currency": "EUR",
"result": "approved",
"latency_ms": 312,
"tags": ["pci_safe", "kyc_passed", "low_risk"],
"extra": {
"bin": "411111",
"method": "card",
"region": "EU",
"ab_test": "checkout_v2"
}
}

• PAN/BIN（ポリシーで有効なフィールドのみ保存）、Eメール/電話-ハッシュ/トークンをマスクします。
• /24へのIPのtruncate、 GeoIPは別に貯えます。
• ユーザーの入力のために「余分な」でのフリーテキストを消毒せずに禁止します。

6）相関： trace_id、 correlation_id、 idempotency_key

「trace_id」 （OTelから）、「span_id」、 「correlation_id」（ビジネスプロセスのエンドツーエンド）、「idempotency_key」（支払いリクエストの場合）を各ログとメトリックに追加します。
スライスを構築するための手荷物（テナント/ブランド、マーケット、A/Bオプション）を転送します。

7）指標： 技術およびビジネス

テクニカル：RPS、 p95レイテンシ、エラー率、飽和、GC、プール使用量、Kafka消費者の遅れ。
ビジネス：CR registratsii→depozit、成功した承認、支払いのキャンセル、NGR/GGR、 ARPPU、 RTP異常、KYCステップでのドロップオフ、責任ある限度のシェア。

promql sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

8）トレースとOpenTelemetry

ゲートウェイ、決済オーケストレーター、ゲームコア、通知、KYC/AML、プロバイダとの統合を行います。
トータルフローのヘッドサンプリング+エラー/潜在スパンおよび支払いのテールサンプリング（上昇）。
コンテキスト伝播：'traceparent'/'tracestate'、 Kafkaヘッダ、gRPCメタデータ。
注釈はドメインイベントにまたがる：'BetSpainted'、 'WithinRequested'。

9）騒音のない警報

マルチステージのしきい値（警告/クリティカル）、フラップ抑制、重複除外、タイムスロット。
相関：「5xx growth」+「Kafka lag」+「p95 latency PSP」→1つのインシデントを関連付けます。
SLOベースのアラート：エラー予算を費やす-エスカレート。
Alerts-as-Code （GitOps）、レビューおよびルールテスト。

yaml groups:
- name: payments rules:
- alert: PaymentErrorSpike expr: (sum(rate(payment_errors_total[5m])) / sum(rate(payment_attempts_total[5m]))) > 0. 02 for: 10m labels: { severity: "critical", team: "payments" }
annotations:
summary: "Payment errors> 2% per 10m"
runbook: "runbooks/payments/error-spike. md"

10）ログ検索（LogQL例）

logql
{app="psp-orchestrator", level=~"ERROR    FATAL"}
= "decline"
json amount_minor > 10000 region="EU"

目標は、ノイズを素早く排除し、ターゲット地域の「高価な」障害を強調することです。

11）ダッシュボード： 必須のもの

支払いの健全性：PSPによる成功/失敗、方法によるレイテンシ、地域の地図、SLAプロバイダ。
ゲームコア：プロバイダによるRPS、 p95スピン、エラー比SDK、スロットによるRTP異常。
プレイヤーの旅：registratsiya→KUS→depozit→igra→vyvod。
Infra： Kafka lag、 DB接続、キャッシュヒット率、Kubernetesクラスタ（Pod/ノードのグリッド）。

12）貯蔵、保持および費用（FinOps）

Cardinality under control：非常に変更可能なラベル（user_id)でメトリックを避けます。
Retentions：ホットメトリック30-90日、最大13ヶ月のダウンサンプリング。ログ熱い7-14日、暖かい30-90日、冷たい1-3年（規制を考慮して）。
監査ログのWORM/不変性、オブジェクトロック。
圧縮/パーティショニングおよびILMポリシー;監査/PII-safeの個別のインデックス。
INFO/DEBUGのサンプリングログ；エラー/監査-完了しました。

13）安全性とコンプライアンス

PII/PCI：トークン化、ハッシュ化、マスキング；データの最小化。
RBAC/ABAC：ログ/トラックへのアクセス-役割、日除けの分離。
秘密と鍵：認証情報/トークンをログに記録しないでください。CIの秘密検出器。
監査証跡：管理パネルへのエントリ、制限/支払いの変更、手動残高調整-常に監査インデックスにのみ。
リーガルホールド：調査で凍結保持のためのメカニズム。

14）テレメトリーデータ品質

ログ/イベントのスキーマレジストリ（バージョン管理、互換性）。
フィールドの単一の命名法（snake_case、測定単位）。
注射時の検証（汚れたイベントのドロップ、結婚指標）。
背圧と「ログストーム」に対する保護。

15） SREプロセス、オンライン通話、ランブック

オンコールマトリックスとエスカレーション；静かな時間と回転。
Runbookはアラート（診断手順、SQL/LogQLレシピ、劣化のためのphicheflags）に関連付けられています。
ペナルティのない死後、所有者と期限付きのアクション項目。
チームインジケータ：MTTD/MTTR、騒々しいアラートの割合、Runbukカバレッジ。

16）ラム酒と合成

RUM： WebVitals （LCP、 CLS、 INP）、フロントエラー、デバイス指紋、リージョン/プロバイダ。
合成：シナリオ「registratsiya→depozit→spin→vyvod」異なる地域から；内部パス（管理者/バックオフィス）のプライベートロケーション。

17）リリース、実験、フィッシュフラグの実践

トラックとリリースバージョン（コミット/artefact）をリンクします。

手荷物→ダッシュボードのA/Bタグ「SLIに対する実験の効果」

カナリア/ブルーグリーン：カナリア、エラー予算燃焼率のための別のパネル。

18）異常検知と不正防止信号

新しいカードの減少率/チャージバックリスク/サージに関する統計的トリガー（季節意識）。
相関：「失敗した預金の成長+PSPアダプタの新しいリリース」。
ほぼリアルタイムの反応のためのストリーミングルール（Kafka→Flink）。

19）実装ロードマップ（フェーズ別）

ステージ0-基礎：JSONログ、統一された相関フィールド、基本サービスメトリック、共通ダッシュボード、最初のアラート。
ステージ1-トレース：OTel計測、ヘッド+テールサンプリング、ログへのリンク。
ステージ2-ビジネスSLI/SLO：支払/出力/ゲームメトリック、SLOアラート、エラー予算プロセス。
ステージ3-成熟度：Alerts-as-Code、 ILM、個別のリテンション、異常検出、サービスごとのrunbuki、 CI/CDのSREプラクティス。

20）レビューチェックリスト

• JSONのみログ、シングルキー、PIIマスキング。
• 各イベントで：'trace_id'、 'span_id'、 'correlation_id'、 'tenant'。
• 指標は、金の信号と業務フローをカバーしています。
• SLOが記述されており、エラー予算とバーンレートに関するアラートがあります。
• テールサンプリングは、支払いエラーと高遅延のために有効です。
• ILMとWORMは監査ログ用に構成されています。
• テレメトリー、アクセス監査のためのRBAC。
• 支払い/ゲームコア/プレーヤージャーニー/インフラのダッシュボード。
• Runbookはすべてのクリティカルアラートに関連付けられています。
• Postmortemsとアクションアイテム-所有者とのバックログ。

付録A： OpenTelemetry属性（推奨）

「サービス」名前'、'サービス。バージョン'、'deployment。environment'

'cloud。region'、'k8s。ポッド。名前'、'k8s。容器。「名前」

'tenant'、 'brand'、 'market'、 'ab_test'、 'user_segment'

支払いだよ。メソッド'、'psp'、'game。プロバイダ'、'ゲーム。ID'

付録B： SLOのメトリック例

'payment_success_ratio'、'撤退_ttw_p95' （time-to-wallet）、 'psp_latency_p99'

'game_spin_latency_p95'、 'provider_error_rate'、 'kafka_consumer_lag'

'auth_success_ratio'、 'kyc_step_dropout'、 'cache_hit_ratio'

付録C： 迅速な調査レシピ

「成長中の'payment_error_rate'」→PSP/region/methodによる比較、テールトレイルのチェック、アダプターのリリースを参照してください。
"p99 spins' trace→、front→geytvey→provayder check provider/channels、スレッドプール制限、ネットワークリトレイ。
→健康消費者、レトロな生産者、バックプレッシャー、スローシンク/DB。