𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮 𝗠𝘂𝗹𝘁𝗶-𝗥𝗲𝗴𝗶𝗼𝗻 𝗛𝗲𝗮𝗹𝘁𝗵-𝗖𝗵𝗲𝗰𝗸 𝗔𝗴𝗴𝗿𝗲𝗴𝗮𝘁𝗼𝗿
ਸਾਂ ਪਾਉਲੋ (São Paulo) ਵਿੱਚ ਇੱਕ ਯੂਜ਼ਰ ਇੱਕ ਡੈੱਡ ਐਜ ਨੋਡ (dead edge node) ਨਾਲ ਟਕਰਾਉਂਦਾ ਹੈ। ਉਹ ਬੱਗ ਰਿਪੋਰਟ (bug report) ਨਹੀਂ ਦਿੰਦਾ। ਉਹ ਟੈਬ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕੁਝ ਹੋਰ ਦੇਖਣ ਲੱਗ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਆਮ ਅਪਟਾਈਮ ਮੋਨੀਟਰ (uptime monitor) ਇਸ ਨੂੰ ਮਿਸ ਕਰ ਦਿੰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਮੋਨੀਟਰ ਇੱਕੋ ਇੱਕ ਸਥਾਨ ਤੋਂ ਪ੍ਰੋਬ (probe) ਕਰਦੇ ਹਨ। ਉਸ ਇੱਕ ਜਗ੍ਹਾ ਤੋਂ, ਸਭ ਕੁਝ ਸਹੀ (green) ਲੱਗਦਾ ਹੈ।
ਸਾਡਾ ਸਟੇਟਸ ਪੇਜ 100% ਅਪਟਾਈਮ ਦੱਸਦਾ ਸੀ ਜਦੋਂ ਕਿ ਅਸਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਟਾਈਮ-ਆਊਟ (timeouts) ਮਿਲ ਰਹੇ ਸਨ। ਇੱਕ ਗਲੋਬਲ ਹੈਲਥ ਚੈੱਕ ਸਾਨੂੰ ਝੂਠ ਬੋਲ ਰਿਹਾ ਸੀ।
ਇੱਥੇ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਅਸੀਂ ਅਜਿਹਾ ਸਿਸਟਮ ਕਿਵੇਂ ਬਣਾਇਆ ਜੋ ਸੱਚ ਦੱਸਦਾ ਹੈ।
ਸਮੱਸਿਆ: ਸੈਂਪਲਿੰਗ ਬਾਇਸ (Sampling Bias) ਜੇਕਰ ਤੁਹਾਡਾ ਮੋਨੀਟਰ ਇੱਕ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਹੈ, ਤਾਂ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਹਕੀਕਤ ਦੇਖਦਾ ਹੈ। ਭਾਵੇਂ ਤੁਹਾਡੇ ਸਿੰਗਾਪੁਰ ਅਤੇ ਸਾਂ ਪਾਉਲੋ ਐਜ (edges) ਕਨੈਕਸ਼ਨ ਡ੍ਰੌਪ ਕਰ ਰਹੇ ਹੋਣ, ਫਿਰ ਵੀ ਤੁਸੀਂ ਸਭ ਕੁਝ ਸਹੀ (green) ਰਿਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ।
ਵੀਡੀਓ ਟ੍ਰੈਫਿਕ ਇਸ ਨੂੰ ਹੋਰ ਵੀ ਮਾੜਾ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਆਮ ਖੇਤਰੀ ਅਸਫਲਤਾਵਾਂ (regional failures) ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
- ਇੱਕ ਮਹਾਂਦੀਪ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੇ ਮਾੜੇ BGP ਰੂਟਸ।
- ਕੈਸ਼ ਇਵਿਕਸ਼ਨ (Cache evictions) ਜੋ ਹੌਲੀ ਓਰੀਜਨ ਫਾਲਬੈਕ (origin fallbacks) ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ।
- ਡਿਸਕ ਗਲਤੀਆਂ ਕਾਰਨ ਹੋਣ ਵਾਲੇ TLS ਹੈਂਡਸ਼ੇਕ ਟਾਈਮ-ਆਊਟ।
- ਖਾਸ ਲੋਕਲ ਰੈਜ਼ੋਲਵਰਾਂ (local resolvers) 'ਤੇ DNS ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ।
ਇੱਕ ਇਕੱਲਾ "200 OK" ਰਿਸਪਾਂਸ ਤੁਹਾਨੂੰ ਲਗਭਗ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।
ਸਾਡੇ ਤਿੰਨ ਨਿਯਮ ਹੈਲਥ ਲਈ: ਅਸੀਂ ਸਟੇਟਸ ਕੋਡਾਂ ਤੋਂ ਅੱਗੇ ਵਧੇ ਹਾਂ। ਅਸੀਂ ਤਿੰਨ ਮੈਟ੍ਰਿਕਸ (metrics) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੈਲਥ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਾਂ:
- ਪਹੁੰਚਯੋਗਤਾ (Reachability): TCP ਅਤੇ TLS ਹੈਂਡਸ਼ੇਕ 800ms ਦੇ ਅੰਦਰ ਖਤਮ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
- ਲੇਟੈਂਸੀ (Latency): ਅਸੀਂ p95 Time-to-First-Byte (TTFB) ਨੂੰ ਟ੍ਰੈਕ ਕਰਦੇ ਹਾਂ। ਔਸਤ (Averages) ਉਸ ਹੌਲੀ ਟੇਲ (slow tail) ਨੂੰ ਛੁਪਾ ਦਿੰਦੀ ਹੈ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਪਰੇਸ਼ਾਨ ਕਰਦੀ ਹੈ।
- ਸਹੀਪਨ (Correctness): ਰਿਸਪਾਂਸ ਬਾਡੀ ਵਿੱਚ ਇੱਕ ਉਮੀਦ ਕੀਤੀ ਗਈ ਮਾਰਕਰ (marker) ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇੱਕ 200 OK ਜੋ ਐਰਰ ਪੇਜ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਉਹ ਇੱਕ ਅਸਫਲਤਾ ਹੈ।
ਹੱਲ: ਮਲਟੀ-ਰੀਜਨ ਪ੍ਰੋਬਿੰਗ (Multi-Region Probing) ਅਸੀਂ ਇੱਕ ਵੱਡੇ ਮੋਨੀਟਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਇਸ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਸਸਤੇ ਖੇਤਰੀ VPS ਇੰਸਟੈਂਸਾਂ (instances) 'ਤੇ ਛੋਟੇ Go ਬਾਈਨਰੀਜ਼ (binaries) ਤੈਨਾਤ ਕਰਦੇ ਹਾਂ।
ਹਰੇਕ ਪ੍ਰੋਬਰ (prober):
- ਇੱਕ ਸਥਾਨਕ ਨਜ਼ਰੀਏ ਤੋਂ ਐਜਾਂ (edges) ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ।
- ਅਸਲ TTFB ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ httptrace ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।
- ਨਤੀਜਿਆਂ ਨੂੰ ਇੱਕ ਕੇਂਦਰੀ ਐਗਰੀਗੇਟਰ (aggregator) 'ਤੇ ਪੋਸਟ ਕਰਦਾ ਹੈ।
ਅਸੀਂ ਸਟੋਰੇਜ ਲਈ SQLite ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਇਹ ਸਰਲ ਹੈ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਵਾਧੂ ਬੋਝ (zero overhead) ਦੇ ਸਾਡੇ ਵਰਕਲੋਡ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। ਅਸੀਂ ਪ੍ਰੀ-ਐਗਰੀਗੇਟਡ ਡੇਟਾ ਦੀ ਬਜਾਏ ਰਅਅ (raw) ਸੈਂਪਲ ਸਟੋਰ ਕਰਦੇ ਹਾਂ। ਇਹ ਸਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਇਤਿਹਾਸ ਨੂੰ ਦੁਬਾਰਾ ਸਕੋਰ ਕਰਨ ਜਾਂ ਖਾਸ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
ਭੇਦ: ਕੁਓਰਮ (Quorum) ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ ਸ਼ੋਰ (noise) ਹੁੰਦਾ ਹੈ। ਇੱਕ ਡ੍ਰੌਪ ਕੀਤਾ ਹੋਇਆ ਪੈਕੇਟ ਕੋਈ ਆਊਟੇਜ (outage) ਨਹੀਂ ਹੈ।
ਅਸੀਂ ਗਲਤ ਅਲਾਰਮਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਕੁਓਰਮ ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਕਿਸੇ ਐਜ ਨੂੰ "ਡਾਊਨ" (down) ਉਦੋਂ ਹੀ ਘੋਸ਼ਿਤ ਕਰਦੇ ਹਾਂ ਜਦੋਂ ਕਈ ਖੇਤਰ ਸਹਿਮਤ ਹੁੰਦੇ ਹਨ। ਜੇਕਰ ਇੱਕ ਖੇਤਰ ਅਸਫਲਤਾ ਦੇਖਦਾ ਹੈ ਪਰ ਦੂਜੇ ਨਹੀਂ, ਤਾਂ ਅਸੀਂ ਟੀਮ ਨੂੰ ਪੇਜ (page) ਨਹੀਂ ਕਰਦੇ। ਇਸ ਡਿਜ਼ਾਈਨ ਚੋਣ ਨੇ ਸਾਡੇ 90% ਗਲਤ ਅਲਰਟਾਂ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ।
ਮੁੱਖ ਸਬਕ:
- ਉਸ ਚੀਜ਼ ਦਾ ਪ੍ਰੋਬ ਕਰੋ ਜਿਸ ਨਾਲ ਯੂਜ਼ਰ ਟਕਰਾਉਂਦੇ ਹਨ, ਨਾ ਕਿ ਇੱਕ ਸਿੰਥੈਟਿਕ ਪਾਥ (synthetic path) ਦਾ।
- ਟੇਲ ਲੇਟੈਂਸੀ (tail latency) (p95) ਨੂੰ ਟ੍ਰੈਕ ਕਰੋ, ਨਾ ਕਿ ਔਸਤ ਨੂੰ।
- ਕਈ ਖੇਤਰਾਂ ਵਿੱਚ ਡਿਸਪੋਜ਼ੇਬਲ (disposable), ਸਸਤੇ ਪ੍ਰੋਬਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ।
- ਪੇਜਰ ਫੈਟੀਗ (pager fatigue) ਤੋਂ ਬਚਣ ਲਈ ਕੁਓਰਮ ਦੀ ਵਰਤੋਂ ਕਰੋ।
- ਆਪਣੇ ਸਟੋਰੇਜ ਸਟੈਕ ਨੂੰ ਸਰਲ ਰੱਖੋ।
ਤੁਹਾਨੂੰ ਕਿਸੇ ਭਾਰੀ observability ਪਲੇਟਫਾਰਮ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਸਥਾਨਕ ਪ੍ਰੋਬਸ, ਕੱਚੇ ਡੇਟਾ, ਅਤੇ ਇੱਕ ਅਜਿਹੇ ਨਿਯਮ ਦੀ ਲੋੜ ਹੈ ਜੋ ਫਾਲਤੂ ਸ਼ੋਰ ਕਰਕੇ ਘਬਰਾਉਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੋਵੇ।