Observability: Golden Signals और Tracing

Proxy सब कुछ देखता है

चूँकि हर call proxy से गुज़रती है, gateways और meshes application कोड बदले बिना एकरूप telemetry बनाते हैं: प्रति service और route चार golden signals (latency, traffic, errors, saturation) के metrics, request IDs के साथ access logs, और distributed tracing spans। Proxies स्पर्श-स्वयं spans को एक trace में नहीं जोड़ सकते: आपके application को आने वाली से जाने वाली calls तक trace headers आगे भेजने होंगे (W3C traceparent मानक, या B3)। Metrics के लिए Prometheus/Grafana और traces के लिए OpenTelemetry-संगत backend में export करें। औसत नहीं, percentiles (p50, p95, p99) देखें, और हर आंतरिक metric की जगह उन लक्षणों पर alert लगाएँ जिन्हें users महसूस करते हैं (error दर, latency)।

p50 बनाम p99, चलाकर

मैंने यह सादा-Python मॉडल चलाया। झुके latency वितरण (seeded generator से 1,000 अनुकरणीय calls) का median लगभग 32 ms है पर 99वाँ percentile लगभग 109 ms। औसत वह धीमी पूँछ छिपाता जिसे असली users सौ में एक बार झेलते हैं।

import hashlib, bisect, math, random

random.seed(7); lat = sorted(random.lognormvariate(3.5, 0.5) for _ in range(1000))
print(round(lat[499]), round(lat[989]))

Output:

32 109

Trace context आगे भेजना (उदाहरण)

आने वाले अनुरोध के tracing headers हर जाने वाली call में कॉपी करें ताकि mesh और tracing backend spans को जोड़ सकें। Header सूची W3C Trace Context और आम mesh प्रथा के अनुसार।

TRACE_HEADERS = ["traceparent", "tracestate", "x-request-id", "b3"]

def forward_headers(incoming):
    return {h: incoming[h] for h in TRACE_HEADERS if h in incoming}

# requests.get(payments_url, headers=forward_headers(request.headers))

त्वरित जाँच: Applications को trace headers आगे क्यों भेजने चाहिए?

• Tracing को headers नहीं चाहिए
• Headers अनुरोध तेज़ करते हैं
• यह सिर्फ़ HTTPS के लिए है
• Proxies आने वाली और जाने वाली calls को अपने आप एक trace में नहीं जोड़ सकते