איתור מבוזר

(סעיף: טכנולוגיה ותשתיות)

תקציר

עקבות מבוזרות מספקות תשובה לשאלה היכן ומדוע הזמן אבד לאורך נתיב הבקשה דרך השער, API, תורים, מסדי נתונים, ספקים חיצוניים (אולפני PSP/game). OpenTelemetry הוא תקן פתוח של SDK/סוכן/פרוטוקול המשלב שבילים, מדטים ויומנים. ב-iGaming, זהו כלי בסיסי לשמור על p95/p99, לאתר במהירות בעיות תשלום ולזהות צווארי בקבוק לפני טורנירי שיא.

1) מושגי אוטל

עקבות - המסלול המלא של המבצע (הפקדה, תעריף, משיכה).
אזור עבודה (HTTP, בקשת SQL, תור/ספקית קריאה).
תכונות - מפתח ערך עם פרטים ('net. עמיתים. שם, 'db. מערכת ',' psp. כביש ').
אירועים - אירועים מיידיים (נסיגה, פסק זמן, מטמון מתגעגע).
קישורים - קישור לעקבות אחרות (חשוב עבור async/תור).
משאב - תהליך metadata: 'שירות. שם, 'שירות. גרסה ”, פריסה”. סביבה ”, ענן”. אזור ".

2) התפשטות הקשר

traceparent: 00-<trace_id>-<span_id>-01 tracestate:...

בנוסף - מטען עבור מפתחות מאובטחים (לדוגמה, "דייר", "מסלול"), אל תשים שם מח "ש.

היכן לנקב את ההקשר: API pateway # internal RPCs # Property to cesture # HTTP חיצוני (PSP/Spects).

3) מוסכמות סמנטיות (מינימום חובה)

HTTP/RPC: "http. שיטה ", http. מסלול ", http. status_code'.
DB/cache: 'db. מערכת ('mysql'/' postgresql'/' redis'), 'db. הצהרה (רעול פנים), 'db. מבצע '.
תורים: "הודעות. מערכת '(' kafka '/' rabbitmq '),' הודעות. יעד ”, הודעות”. מבצע ('שלח '/' תהליך').
תשלומים: "psp. מסלול ”,” psp. ספק ", התשלום. (שם בדוי), ”סכום”, ”מטבע”.
תחום ההימורים: משחק. ספק ”, משחק”. session_id' (חשיש), 'שחקן. id_hash'.

טקסונומיה אחת היא השוואת לוחות מחוונים וחיפוש מהיר אחר סיבות.

4) דגימה: כיצד לא לטבוע בנתונים

מבוסס ראש

פשוט, זול; מתאים לזרימה כללית.
מינוס - אתה יכול לאבד ”מעניין” מסלולים איטיים/שגויים.

מבוסס זנב (אספן)

ההחלטה מתקבלת לאחר סיום התוחלת: אנו שומרים רק שגיאות/קטעים איטיים/חשובים (VIP/תשלומים).
אידיאלי לעומס ייצור: מוריד משמעותית את העלות עם תוכן מידע גבוה.

• ראש: 5-10% עבור כיסוי ”רקע”.
• זנב: 100% שגיאה + p95 + איטי + עקבות תשלום/קנרית משחררת.

5) טופולוגיות אספן OpenTelemetry

Agent-sidecar (בכל צומת/תרמיל): קבלה מקומית, חיץ מינימלי, ייצוא לצביר.
שער (אשכול): דגימת זנב, ניתוב, העשרה, יצוא לטמפו/ייגר/זיפקין/OTLP.

דוגמה: דגימת זנב (רסיס YAML)

yaml processors:
tailsampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code:
status_codes: [ ERROR ]
- name: slow_p95 type: latency latency:
threshold_ms: 250
- name: payments type: string_attribute string_attribute:
key: service. name values: [ "payments-api", "payments-worker" ]

6) קורלציה עם מדדים ויומנים

הוסף ”trace _ id'/” span _ id' לכל רשומה.
Store latency metrics כהיסטוגרמות וכולל מופת - התייחסות לנציג "trace _ id' עבור" קפיצה "מ-p95-boket לעקבות ספציפיות.
שחרר אנוטציות (Git SHA, גירסת תרשים) - כמו אירועים/תוויות.

7) מכשירים (שפות וסוכנים אוטומטיים)

עבור (ידני + אוטומטי)

go tp:= sdktrace. NewTracerProvider(
sdktrace. WithBatcher(exporter),
sdktrace. WithResource(resource. NewWithAttributes(
semconv. SchemaURL,
semconv. ServiceName("payments-api"),
)),
)
otel. SetTracerProvider(tp)

ctx, span:= tracer. Start(ctx, "Deposit")
defer span. End()
span. SetAttributes(
attribute. String("psp. route","pspX"),
attribute. String("currency","EUR"),
)

Java

סוכן אוטומטי - javaagent: opentelemetry-javaagent. JAR, Config via env ('OTEL _ Service _ Name', 'OTEL _ Exporter _ OTLP _ ENDPOINT').
מדריך - אנוטציות/כלי של מקומות בצל (בריכות JDBC, מטמון).

Node. js/Python

כלי אוטומטי עם תוסף SDK + (Express/FastAPI/סלרי).
לתורים - עטיפות מפיק/צרכן לשים 'הודעות. "וקישורים.

8) תורים ואסינק: נכון מרווחים

מפיק ('שלח'): מרווח לשלוח לנושא/תור.
צרכן (”process'): תוחלת חדשה של עיבוד מסרים מקישור למרחב יצרן (שמור יחסים סיבתיים ללא” trace _ id').
תכונות: 'הודעות. קפקא. מחיצה ',' הודעות. רביטמק. routing_key', הודעות. message_id'.
עם מגשים מחדש - אירוע 'retry', לנסות נגד.

9) DB/Cache ו ־ N + 1

אפשר איתור מנהל מסד הנתונים, שאילתות קבוצתיות מאותו סוג לחבורות.
עבור רדיס/מטמון, התכונות הן מטמון. פגע '/' מטמון. מתגעגע ".
הוצא בקשות ”כבדות” להפריד תוחלת - אתה יכול לראות איפה p99.

10) ספקים חיצוניים: PSP/game studios

עטיפת לקוחות HTTP: "psp. ספק ", psp. מסלול ',' time _ ms', 'ניסיון'.
קוד שגיאת רישום/סוגים, אבל לא PII (מספר כרטיס, אסימונים).
השווה אולפנים/מסלולים לפי ”משך”, ”קצב שגיאה”.

11) פרונטנד ורום

Otel Web SDK: ”page _ view”, ”resource _ load”, ”xhr”.
פירס 'tracepart' לתוך האחוריים כדי לתפור את דרכו של המשתמש דרך מסד הנתונים UI לאפס.
סגמנט על ידי ספקי גאו/רשת - תוויות אופציונליות.

12) בטיחות ומח "ש

מסווה את השדות ('db. הצהרה 'ערוך), חשיש' שחקן _ id'.
אזורי נתונים: ”pii = נכון”, ”אזור = EU/TR/LATAM”.
בקרת גישה למסלולי תשלום (מבוסס תפקידים).
WORM/Resurrection: תקופות שמירה עבור עקבות רגישות, מחיקה על ידי מדיניות.

13) ביצועים ועלות

דגימת זנב לפי מדיניות: ”שגיאות + איטיות + תשלומים + קנריים משחררים”.
הורדת היסטוגרמות של מדדים, שכפול יומן אגרסיבי.
אילוצי קרדינליות: אל תכתוב את "user _ id' כתווית מטרית.
חוצצים/חבורות באספן, דחיסת OTLP.

14) לוחות מחוונים וניתוח

מפת שירות: תלות שירות, שגיאה/צביעה.
השוואה: שינוי יציב נגד הקנרית (p95, שיעור שגיאה, תשלומים conv).
עקבות איטיות למעלה: לאורך המסלול '/הפקדה ', קטע לאורך אזור PSP/.
פסי עיכוב לצריכה עמוקה.

15) דוגמאות לתצורות אספנים

צינורות (מדדים/שבילים/רישומים, מקטע)

yaml receivers:
otlp: { protocols: { http: {}, grpc: {} } }

processors:
batch:
memory_limiter:
limit_mib: 1024 spike_limit_mib: 256 attributes/payments:
actions:
- key: "psp. provider"
action: insert value: "pspX"

exporters:
otlp/traces: { endpoint: tempo:4317, tls: { insecure: true } }
otlp/metrics:{ endpoint: prometheus-otlp:4317, tls: { insecure: true } }
otlp/logs:  { endpoint: loki-otlp:4317, tls: { insecure: true } }

service:
pipelines:
traces:
receivers: [ otlp ]
processors: [ memory_limiter, batch, tailsampling ]
exporters: [ otlp/traces ]
metrics:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/metrics ]
logs:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/logs ]

16) ספרי ריצה (תרחישים טיפוסיים)

A) גידול p99 ב "תשלומים-api&fost

1. פתח ”עקבות איטיים עליונים” = ליפול לתוך מסד נתונים/מרווחי PSP.
2. אם בעיית PSP היא לתרגם את המסלול, אפשר מגשים/פסקי זמן.
3. בדוק את התור 'withrawals' (לג), להגדיל את הצרכנים.

B) לאחר שחרור 5xx באגים

1. מסנן על ידי 'service. גרסה ".
2. השווה יציבה/קנרית; מצא קוצים ב 'psp. מסלול ".
3. להקפיא את הקידום, להתגלגל לאחור (ראה אסטרטגיות שחרור/רולבקס).

C) חשד N + 1

1. שבילים עם מספר רב של מרווחי DB קצרים.
2. אפשר צבירה/שמחות, הוסף שכבת מטמון.

17) רשימת מימושים

1. אפשר OTel SDK ותכונות משאב אחידות ('service. שם, 'env', 'אזור').
2. הפצת הקשר W3C דרך כל השכבות והתורים.
3. סט מינימלי של תכונות סמנטיות (HTTP/DB/תור/PSP).
4. דגימת זנב: שגיאות, p95 +, תשלומים, קנרית.
5. Logs עם 'trace _ id'/' span _ id', metrics עם מופת.
6. לוחות מחוונים: מפת שירות, השוואה שחרור, זרימת תשלומים.
7. מדיניות מח "ש: מיסוך, אזורים, תפקידים, שימור.
8. בדיקות/טעינה: בדוק מתאם ושלמות של התחקות לפני פסגות.
9. דור אוטומטי של קישורי ריצה בהתראות.
10. דו "ח עלויות טלמטריה וקרדינליות.

18) תרופות אנטי ־ פטריות

עקבות ”רק בכניסה” ללא מסדי נתונים/תורים * אין שימוש.
חוסר התפשטות ב async = גורם ושרשראות השפעה לשבור.
דגימה אקראית של 1% ללא היגיון זנב * אין לתפוס איטי/שגוי.
אין מתאם מקצה לקצה.
PIIS RAW במאפיינים/יומנים = סיכוני ציות.
קרדינליות ”לתקרה” (משתמש/סשן כתוויות מטריות) = פיצוץ של ערך.

תקציר

OpenTelemetry הופך את יכולת התצפית מאוסף של כלים שונים לשפת ביצועים מקצה לקצה. עם התפשטות ההקשר הנכון, סמנטיקה מסודרת, דגימת זנב ושילוב של ”מדדים ↔ עקבות ↔ יומנים”, צוות iGaming שומר p95/p99 תחת שליטה, מבודד במהירות את צווארי הבקבוק (DB, תורים, PSP) ומשחרר בביטחון אפילו בפסגות תנועה.