Παρακολούθηση και υλοτομία

1) Γιατί έχει σημασία στο iGaming

Χρήματα σε πραγματικό χρόνο: αποδοχή καταθέσεων, άμεσες πληρωμές, υπολογισμός στοιχημάτων και κερδών, τουρνουά - τα πάντα είναι ευαίσθητα σε καθυστερήσεις και αποτυχίες.
Κανονιστική ρύθμιση και έλεγχος: απαιτείται πλήρης ιχνηλασιμότητα των δράσεων (KYC/AML, πληρωμές, όρια υπεύθυνου έργου).
Πολύπλοκη κατανεμημένη αρχιτεκτονική: πύλες API, ενορχήστρωση πληρωμών, EDA/Kafka, υπηρεσίες παροχής υπηρεσιών, πελάτες κινητής τηλεφωνίας, μέτωπα, λεωφορείο BI.
Στόχος: μείωση της MTTD/MTTR, διατήρηση της SLO σε σήματα χρυσού και παροχή ποσοστού περιστατικών.

2) Βασικές έννοιες της παρατηρησιμότητας

Αναλυτικά συμβάντα (δομημένα JSON) κατάλληλα για έρευνες και λογιστικούς ελέγχους.
Μετρήσεις: συγκεντρωτικά στοιχεία στο χρόνο (TSDB), κατάλληλα για SLO/καταχωρίσεις.
Ίχνη: αλυσίδες αιτίων και αποτελεσμάτων των αιτημάτων (ίχνος/εύρος) μέσω υπηρεσιών/μεσιτών/βάσεων δεδομένων.
Εκδηλώσεις: domain events (BetPlaced, DepositionΕγκεκριμένο) - γέφυρα μεταξύ επιχειρηματικών μετρήσεων και τεχνολογίας.

3) «Χρυσά σήματα» και SLI/SLO για iGaming

Καθυστέρηση: P95/P99 σε κρίσιμες ροές (εξουσιοδότηση, κατάθεση, επιτόκιο, έναρξη συνεδρίας, περιστροφή).
Κίνηση: RPS ανά API, TPS ανά πληρωμή, EPS ανά γεγονός.
Σφάλματα: μερίδιο 5xx/4xx, ρυθμός μείωσης, αποτυχία εντός, σφάλματα παρόχου.
Κορεσμός: CPU, μνήμη, IO, Kafka lag, συνδέσεις DB, δεξαμενές νημάτων.

• SLI: '1 - (failed_payments/ total_payments)'
• SLO: 99. 7% των εγκρίσεων επιτυχημένων καρτών σε 30 ημέρες (προϋπολογισμός σφάλματος 0. 3%).

4) Αρχιτεκτονική συλλογής και επεξεργασίας

1. Ένεση: παράγοντες (OTEL Collector/Fluent Bit), SDK στην εφαρμογή, RUM/συνθετικά.
2. Δρομολόγηση: μεσίτης/λεωφορείο τηλεμετρίας (OTLP/HTTP/GRPC), φίλτρα και συγκάλυψη PII.

• Μετρήσεις: TSDB (συγκέντρωση, μείωση της δειγματοληψίας).
• Κούτσουρα: θερμός (ευρετηριασμένος )/θερμός (λιγότερο ευρετηριασμένος )/ψυχρός (αποθήκευση αντικειμένων, WORM).
• Διαδρομές: χρονικά δεικτοποιημένη αποθήκευση με εφεδρείες και δειγματοληψία ουράς.
• 4. Analytics/alerts: κανόνες (PromQL/LogQL/SQL), συσχέτιση με κομμάτια και κυκλοφορίες.
• 5. Ταμπλό: τεχνικά + είδη επιχειρήσεων (πληρωμές, RNG/πάροχοι, μηχανή τουρνουά).

5) Πρότυπο καταγραφής (JSON) και ταξινόμηση γεγονότων

Συνιστάται αυστηρή καταγραφή JSON, μονά κλειδιά και επίπεδα.

: 'DEBUG

: «auth»., «payment»., «gameplay»., «risk»., «psp»., «ky .,» rg «. (υπεύθυνο παιχνίδι),» op .

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 (αποθηκεύουμε μόνο πεδία που ισχύουν με πολιτική), email/τηλέφωνο - hash/token.
• IP transcate to/24, GeoIP store χωριστά.
• Απαγορεύουμε το ελεύθερο κείμενο στο «έξτρα» για εισροή χρηστών χωρίς απολύμανση.

6) Συσχέτιση: trace_id, correlation_id, idempotency_key

Προσθέστε 'trace _ i (από το OTEL),' span _ id ',' relation _ id '(end-to-end for the business process),' idempotency _ key '(για τις αιτήσεις πληρωμής) σε κάθε ημερολόγιο και μετρικό.
Μεταβιβασθείσες αποσκευές (ενοικιαστής/εμπορικό σήμα, αγορά, επιλογή Α/Β) για την κατασκευή φέτες.

7) Μετρήσεις: Τεχνικές και επιχειρηματικές

Τεχνική: RPS, p95 καθυστέρηση, ποσοστό σφάλματος, κορεσμός, GC, κοινή χρήση, καταναλωτική καθυστέρηση Kafka.
Επιχειρήσεις: registratsii→depozit ΣΣ, επιτυχείς άδειες, ακυρώσεις πληρωμών, NGR/GGR, ARPPU, ανωμαλίες RTP, παράδοση στο στάδιο KYC, μερίδιο των υπεύθυνων ορίων.

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

8) Εντοπισμός και ανοικτή τηλεμετρία

Οργανώνουμε την πύλη, τον ενορχηστρωτή πληρωμών, τον πυρήνα παιχνιδιών, τις κοινοποιήσεις, την KYC/AML, την ενσωμάτωση με τους παρόχους.
Δειγματοληψία κεφαλής για ολική ροή + δειγματοληψία ουράς (υπερυψωμένη) για σφάλματα/λανθάνοντα μεγέθη και πληρωμές.
Διάδοση πλαισίου: 'traceparent '/' tracestate', κεφαλίδες Kafka, μεταδεδομένα gRPC.
Σχολιάζοντας τα διαστήματα με τα domain events: 'BetPlaced', 'WithesRequested'.

9) Προειδοποίηση χωρίς θόρυβο

Κατώφλια πολλαπλών σταδίων (προειδοποίηση/κρίσιμη), καταστολή πτερυγίων, αφαίρεση, χρονοθυρίδες.
Συσχέτιση: συσχετίζουμε «5xx ανάπτυξη» + «Kafka lag» + «p95 καθυστέρηση PSP» → ένα περιστατικό.
Ειδοποιήσεις βάσει SLO: δαπάνη προϋπολογισμού για σφάλματα - κλιμάκωση.
Συναγερμός ως κώδικας (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) Ταμπλό: τι είναι υποχρεωτικό

Πληρωμές Υγεία: επιτυχία/αποτυχίες του ΠΥΠ, καθυστέρηση κατά μέθοδο, χάρτης των περιφερειών, πάροχοι ΠΥΠ.
Πυρήνας παιχνιδιού: RPS ανά πάροχο, περιστροφή p95, αναλογία σφάλματος SDK, ανωμαλίες RTP ανά slots.
Ταξίδι παίκτη: registratsiya→KUS→depozit→igra→vyvod.
Infra: Kafka lag, συνδέσεις DB, αναλογία cache hit, σύμπλεγμα Kubernetes (πλέγμα λοβών/κόμβων).

12) Αποθήκευση, διατήρηση και κόστος (FinOps)

Πληθικότητα υπό έλεγχο: αποφυγή μετρήσεων με εξαιρετικά μεταβαλλόμενες ετικέτες (user_id).
κατακράτηση: θερμές μετρήσεις 30-90 ημέρες, μείωση της δειγματοληψίας έως 13 μήνες· κούτσουρα ζεστά 7-14 ημέρες, ζεστό 30-90 ημέρες, κρύο 1-3 έτη (λαμβάνοντας υπόψη τον κανονισμό).
WORM/αμετάβλητο για αρχεία καταγραφής ελέγχου, κλειδαριά αντικειμένων.
πολιτικές συμπίεσης/διαχωρισμού και ILM· χωριστοί δείκτες ελέγχου/ασφαλείας PII.
Αρχεία δειγματοληψίας στο INFO/DEBUG. ΣΦΑΛΜΑ/ΕΛΕΓΧΟΣ - πλήρης.

13) Ασφάλεια και συμμόρφωση

PII/PCI: μαρκινοποίηση, μαστίγωμα, μάσημα. ελαχιστοποίηση των δεδομένων.
RBAC/ABAC: πρόσβαση σε κορμούς/τροχιές - κατά ρόλο, διαχωρισμός των τάσεων.
Μυστικά και κλειδιά: μην καταγράφετε τα διαπιστευτήρια/τις μάρκες. μυστικοί ανιχνευτές στον ΚΚΠ.
Διαδρομή ελέγχου: εγγραφές στο διοικητικό συμβούλιο, αλλαγές στα όρια/πληρωμές, χειροκίνητες προσαρμογές υπολοίπου - μόνο στο δείκτη AUDIT, πάντοτε.
Νομικό καθεστώς: μηχανισμός δέσμευσης των κρατήσεων στις έρευνες.

14) Ποιότητα δεδομένων τηλεμετρίας

Μητρώο αρχείων/συμβάντων (έκδοση, συμβατότητα).
Ενιαία ονοματολογία πεδίων (snake_case, μονάδες μέτρησης).
Επικύρωση κατά την ένεση (σταγόνα βρώμικων γεγονότων, μετρήσεις γάμου).
Backpressure και προστασία από «καταιγίδες καταγραφής».

15) Διαδικασίες SRE, ηλεκτρονικές κλήσεις και φυλλάδια

Μήτρα και κλιμακώσεις ογκομέτρησης. Ήσυχες ώρες και περιστροφές.
Τα runbooks συνδέονται με ειδοποιήσεις (διαγνωστικά βήματα, συνταγές SQL/LogQL, phicheflags για υποβάθμιση).
Μεταθανάτια χωρίς κυρώσεις, στοιχεία δράσης με ιδιοκτήτες και προθεσμίες.
Δείκτες ομάδας: MTTD/MTTR, ποσοστό θορυβωδών προειδοποιήσεων, κάλυψη Runbuk.

16) RUM και συνθετικά

RUM: WebVitals (LCP, CLS, INP), εμπρόσθια σφάλματα, δακτυλικά αποτυπώματα συσκευών, περιφέρειες/πάροχοι.
Συνθετικά: σενάρια «registratsiya→depozit→spin→vyvod» από διάφορες περιοχές. ιδιωτικές τοποθεσίες για εσωτερικές διαδρομές (admin/back office).

17) Πρακτικές εκλύσεων, πειραμάτων και phicheflags

Συνδέουμε κομμάτια με εκδόσεις έκδοσης (commit/artefact).
A/B ετικέτες σε αποσκευές - ταμπλό «επίδραση του πειράματος σε SLI».
Κανάριος/Μπλε-Πράσινο: ξεχωριστές ομάδες για καναρίνια, ποσοστό εγκαυμάτων λάθους-προϋπολογισμού.

18) Ανωμαλία και σήματα καταπολέμησης της απάτης

Στατιστικοί παράγοντες ενεργοποίησης (εποχικότητα-επίγνωση) σχετικά με το ποσοστό μείωσης/φόρτισης-κινδύνου/αύξηση νέων καρτών.
Συσχετισμοί: «αύξηση των ανεπιτυχών καταθέσεων + νέα έκδοση προσαρμογέα ΠΥΠ».
Κανόνες ροής (Kafka → Flink) για αντιδράσεις σχεδόν σε πραγματικό χρόνο.

19) Χάρτης πορείας για την εφαρμογή (ανά φάση)

Στάδιο 0 - Βάση: αρχεία καταγραφής JSON, ενοποιημένα πεδία συσχέτισης, βασικές μετρήσεις υπηρεσιών, κοινά ταμπλό, πρώτες καταχωρίσεις.
Στάδιο 1 - Ιχνηλάτηση: Όργανα Otel, δειγματοληψία κεφαλής + ουράς, που συνδέονται με κορμούς.
Στάδιο 2 - Business SLI/SLO: πληρωμές/εκροές/μετρήσεις παιχνιδιών, προειδοποιήσεις SLO, διαδικασίες προϋπολογισμού σφαλμάτων.
Στάδιο 3 - Διάρκεια: καταχωρίσεις ως κωδικός, ILM, χωριστές κρατήσεις, ανίχνευση ανωμαλίας, runbuki ανά υπηρεσία, πρακτικές SRE σε CI/CD.

20) Κατάλογος ελέγχου

• JSON μόνο κούτσουρα, μονά κλειδιά, PII κάλυψη.
• Σε κάθε περίπτωση: 'trace _ id', 'span _ i ,' relation _ id ',' renant '.
• Οι μετρήσεις καλύπτουν τα σήματα χρυσού και τις επιχειρηματικές ροές.
• Περιγράφονται οι SLO, υπάρχει προϋπολογισμός λάθους και προειδοποιήσεις σχετικά με το ποσοστό καύσης.
• Η δειγματοληψία στην ουρά είναι δυνατή για σφάλματα πληρωμών και υψηλές καθυστερήσεις.
• Οι ILM και WORM είναι διαμορφωμένες για αρχεία καταγραφής ελέγχου.
• RBAC για τηλεμετρία, έλεγχος πρόσβασης.
• Dashboards for Payments/Game Core/Player Journey/Infra.
• Τα runbooks συνδέονται με κάθε κρίσιμο συναγερμό.
• Μεταθανάτια και στοιχεία δράσης - σε εκκρεμότητα με τους ιδιοκτήτες.

Προσάρτημα Α: Χαρακτηριστικά του OpenTelemetry (σύσταση)

"service. ονοματεπώνυμο "," υπηρεσία ". εξάπλωση της έκδοσης ','. περιβάλλον "

"Σύννεφο. περιφέρεια ',' k8s. κάψουλα. όνομα ',' k8s. εμπορευματοκιβώτιο. ονοματεπώνυμο "

'tenant', 'bran ,' market ',' ab _ test ',' user _ split '

"πληρωμή. μέθοδος ',' psp ',' παιχνίδι. Παιχνίδι παρόχου ','. όν "

Προσάρτημα B: Παραδείγματα μετρικών για SLO

'payment _ success _ ratio', 'research _ ttw _ p95' (time-to-wallet), 'psp _ latency _ p99'

'game _ spin _ latency _ p95', 'provider _ erry _ rate', 'kafka _ consumer _ lage'

'auth _ success _ ratio', 'kyc _ step _ dropou ,' cache _ hit _ ratio '

Προσάρτημα Γ: Συνταγές ταχείας έρευνας

Το "growing 'payment _ error _ rate' → συγκρίνεται με το PSP/region/method, check tail-trails, βλέπε έκδοση προσαρμογέα.
«p99 spins ↑» trace →, front→geytvey→provayder check provider/channels, nead pool, network retrays.
«Kafka lag ↑» → καταναλωτές υγείας, παραγωγοί ρετρό, αντίθλιψη, αργές καταβόθρες/DB.