ਸਿੱਖੋ ਕਿ observability ਅਤੇ slow query logs ਕਿਵੇਂ ਪ੍ਰੋਡਕਸ਼ਨ ਆਊਟੇਜ ਨੂੰ ਪਛਾਣਨ, ਨਿਰਧਾਰਤ ਕਰਨ ਅਤੇ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ—ਤੇ ਕਿਵੇਂ ਨਿਰਮਾਣ, ਅਲਰਟ ਅਤੇ ਕੁਐਰੀਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਟਿਊਨ ਕਰਨਾ ਹੈ।
ਪਰੋਡਕਸ਼ਨ ਅਕਸਰ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਪਲ 'ਤੇ “ਟੁੱਟਦਾ” ਨਹੀਂ। ਜ਼ਿਆਦਾਤਰ ਵਾਰ ਇਹ ਚੁੱਪਚਾਪ ਡਿਗਦਾ ਹੈ: ਕੁਝ ਰਿਕਵੇਸਟ ਲੰਮੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਇੱਕ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਪਿੱਛੇ ਰਹਿ ਜਾਂਦਾ ਹੈ, CPU ਹੌਲੀ-ਹੌਲੀ ਵਧਦਾ ਹੈ, ਤੇ ਗਾਹਕ ਪਹਿਲਾਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ—ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਮੋਨੀਟਰਿੰਗ ਪੈਨਲ ਅਜੇ ਵੀ “ਗ੍ਰੀਨ” ਦਿਖਾ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।
ਯੂਜ਼ਰ ਦੀ ਰਿਪੋਰਟ ਆਮ ਤੌਰ 'ਤੇ ਥੋੜ੍ਹੀ ਅਸਪਸ਼ਟ ਹੁੰਦੀ ਹੈ: “ਇਹ ਧੀਮਾ ਲੱਗਦਾ ਹੈ।” ਇਹ ਕਈ ਵੱਖ-ਵੱਖ ਮੂਲ ਕਾਰਨਾਂ ਦਾ ਲੱਛਣ ਹੋ ਸਕਦਾ ਹੈ—ਡਾਟਾਬੇਸ ਲੌਕ ਕਨਟੈਂਸ਼ਨ, ਨਵਾਂ ਕੁਐਰੀ ਪਲੈਨ, ਮਿਸਿੰਗ ਇੰਡੈਕਸ, noisy neighbor, ਰੀਟ੍ਰਾਈ ਸਟੌਰਮ, ਜਾਂ ਬਾਹਰੀ ਡਿਪੈਂਡੇਸੀ ਜੋ ਬੇਬਾਕੀ ਨਾਲ ਫੇਲ ਹੋ ਰਹੀ ਹੋਵੇ।
ਚੰਗੀ ਵਿਜ਼ੀਬਿਲਟੀ ਨ ਹੋਣ 'ਤੇ ਟੀਮ ਅਟਕਦੇ ਹਨ:
ਕਈ ਟੀਮ ਸਿਰਫ਼ ਔਸਤਾਂ (average latency, average CPU) ਟਰੈਕ ਕਰਦੀਆਂ ਹਨ। ਔਸਤ ਦਰਦ ਨੂੰ ਛੁਪਾ ਦਿੰਦੇ ਹਨ। ਬਹੁਤ ਘੱਟ ਪ੍ਰਤੀਸ਼ਤ ਬਹੁਤ ਧੀਮੀ ਰਿਕਵੇਸਟਾਂ ਅਨੁਭਵ ਨੂੰ ਖ਼ਰਾਬ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜਦਕਿ ਕੁੱਲ ਮੈਟਰਿਕ ਠੀਕ ਲੱਗਦੇ ਹਨ। ਅਤੇ ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ “up/down” ਮਾਨੀਟਰ ਕਰੋਗੇ ਤਾਂ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸਿਸਟਮ ਚਾਲੂ ਹੋਣ ਵਾਲੀ ਲੰਮੀ ਮਿਆਦ ਨੂੰ ਮੁਸਲਸਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿਓਗੇ—ਜਦਕਿ ਉਹ ਵਰਤੋਂਯੋਗ ਨਹੀਂ ਰਹਿੰਦਾ।
Observability ਤੁਹਾਡੀ ਮਦਦ ਕਰਦੀ ਹੈ ਇਸ ਗੱਲ ਦਾ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਕਿ ਸਿਸਟਮ ਕਿਥੇ ਡਿਗ ਰਿਹਾ ਹੈ (ਕਿਹੜੀ service, endpoint ਜਾਂ ਡਿਪੈਂਡੇਸੀ)। ਸਲੋ ਕੁਐਰੀ ਲੌਗ ਤੁਹਾਨੂੰ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਡਾਟਾਬੇਸ ਕਿਸ ਕੰਮ ਵਿੱਚ ਲੱਗਾ ਸੀ ਜਦ ਰਿਕਵੇਸਟ ਰੁਕ ਗਈ (ਕਿਹੜੀ ਕੁਐਰੀ, ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਿਆ, ਅਤੇ ਅਕਸਰ ਕਿਸ ਤਰ੍ਹਾਂ ਦੀ ਕੰਮਇੰਗ)।
ਇਹ ਗਾਈਡ ਕਾਰਗੁਜ਼ਾਰ ਹੈ: ਜਲਦੀ ਚੇਤਾਵਨੀ ਪਾਉਣ ਦੇ ਤਰੀਕੇ, ਯੂਜ਼ਰ-ਮੁਖੀ ਲੈਟੈਂਸੀ ਨੂੰ ਖਾਸ ਡਾਟਾਬੇਸ ਕੰਮ ਨਾਲ ਜੋੜਨਾ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨਾ—ਬਿਨਾਂ ਕਿਸੇ vendor-ਵਿਸ਼ੇਸ਼ ਵਾਅਦੇ 'ਤੇ ਨਿਰਭਰ ਹੋਏ।
Observability ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸਿਸਟਮ ਤੋਂ ਨਿਕਲਣ ਵਾਲੇ ਸੰਕੇਤਾਂ ਨੂੰ ਦੇਖ ਕੇ ਸਮਝਣਾ—ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਉਣ ਜਾਂ "ਲੋ컬 ਵਿੱਚ ਦੁਹਰਾਉਣ" ਦੀ ਲੋੜ ਦੇ। ਇਹ ਫਰਕ ਹੈ ਜਾਣਨ ਦਾ ਕਿ ਯੂਜ਼ਰ ਢੀਲਾਪਨ ਮਹਿਸੂਸ ਕਰ ਰਹੇ ਹਨ ਅਤੇ ਪੁષ્ટ ਕਰਨ ਦਾ ਕਿ ਢੀਲਾਪਨ ਕਿੱਥੇ ਹੋ ਰਿਹਾ ਹੈ ਅਤੇ ਕਿਉਂ ਇਹ ਸ਼ੁਰੂ ਹੋਇਆ।
ਮੈਟਰਿਕਸ ਸਮੇਂ-ਸਿਰ ਨੰਬਰ ਹਨ (CPU %, request rate, error rate, database latency)। ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਪੁੱਛੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਰੁਝਾਨ ਅਤੇ ਅਚਾਨਕ spike ਵੇਖਣ ਲਈ ਉਤਮ ਹਨ।
ਲੌਗ ਉਹ ਇਵੈਂਟ ਰਿਕਾਰਡ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਵਿਸਥਾਰ ਹੁੰਦਾ ਹੈ (ਇੱਕ error message, SQL ਟੈਕਸਟ, user ID, timeout)। ਇਹ ਮਨੁੱਖ-ਪੜਨ ਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕੀ ਹੋਇਆ ਦੀ ਵਿਆਖਿਆ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਹਨ।
ਟ੍ਰੇਸ ਇੱਕ ਹੀ ਰਿਕਵੇਸਟ ਨੂੰ ਸੇਵਾਵਾਂ ਅਤੇ ਡਿਪੈਂਡੇਸੀਆਂ ਵਿੱਚ ਫਰੰਮ ਕਰਦੇ ਹਨ (API → app → database → cache)। ਇਹ ਇਸ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਉਤਮ ਹਨ ਕਿ ਕਿੱਥੇ ਸਮਾਂ ਲੱਗਿਆ ਅਤੇ ਕਿਹੜਾ ਕਦਮ slowdown ਦਾ ਕਾਰਨ ਸੀ।
ਇੱਕ ਮਾਨਸਿਕ ਮਾਡਲ: ਮੈਟਰਿਕਸ ਦੱਸਦੇ ਹਨ ਕੁਝ ਗਲਤ ਹੈ, ਟ੍ਰੇਸ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿੱਥੇ, ਅਤੇ ਲੌਗ ਦੱਸਦੇ ਹਨ ઠੀਕ-ਠਾਕ ਕੀ।
ਇੱਕ ਸਿਹਤਮੰਦ ਸੈੱਟਅੱਪ ਤੁਹਾਨੂੰ ਘਟਨਾ 'ਤੇ ਸਾੱਫ਼ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ:
ਮਾਨੀਟਰਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਚੈਕਸ ਅਤੇ ਅਲਰਟਾਂ ('CPU > 90%') ਬਾਰੇ ਹੁੰਦੀ ਹੈ। Observability ਅੱਗੇ ਵਧਦੀ ਹੈ: ਇਹ ਤੁਹਾਨੂੰ ਘਟਨਾ ਦੌਰਾਨ ਨਵੀਆਂ ਗੈਰ-ਉਮੀਦਵਾਰ ਫੇਲ ਮੋਡਾਂ ਨੂੰ ਪੁੱਛ ਕੇ ਜਾਂਚ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀ (ਉਦਾਹਰਣ ਲਈ, ਕੇਵਲ ਇੱਕ ਗਾਹਕ ਸੈਕਸ਼ਨ ਕਾ checkout ਸਲੋ ਹੋ ਰਿਹਾ ਹੈ ਜੋ ਇੱਕ ਖਾਸ ਡਾਟਾਬੇਸ ਕਾਲ ਨਾਲ ਜੁੜਿਆ ਹੈ)।
ਇਸ ਸਮਰੱਥਾ ਨਾਲ ਤੁਸੀਂ ਘਟਨਾ ਦੌਰਾਨ ਨਵੇਂ ਸਵਾਲ ਪੁੱਛ ਸਕਦੇ ਹੋ ਅਤੇ ਕੱਚੇ ਟੈਲੀਮੇਟਰੀ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਾਂਤ-ਰੂਪ ਸਥਿਤੀ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ।
ਸਲੋ ਕੁਐਰੀ ਲੌਗ ਇੱਕ ਕੇਂਦਰਿਤ ਰਿਕਾਰਡ ਹੁੰਦਾ ਹੈ ਉਹਨਾਂ ਡਾਟਾਬੇਸ ਓਪਰੇਸ਼ਨਾਂ ਦਾ ਜੋ ਇੱਕ "ਸਲੋ" ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਵੱਧ ਗਏ। ਆਮ ਕੁਐਰੀ ਲੌਗਿੰਗ ਦੇ ਬਜਾਏ (ਜੋ ਬਹੁਤ ਬਹੁਤ ਹੋ ਸਕਦਾ ਹੈ), ਇਹ ਉਹ ਬਿਆਨ ਉਭਾਰਦੇ ਹਨ ਜੋ ਯੂਜ਼ਰ-ਦਿੱਖੀ ਲੈਟੈਂਸੀ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਘਟਨਾਵਾਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੇ ਹਨ।
ਜਿਆਦਾਤਰ ਡਾਟਾਬੇਸ ਇੱਕੋ ਜਿਹੇ ਕੋਰ ਫੀਲਡ ਕੈਪਚਰ ਕਰ ਸਕਦੇ ਹਨ:
ਇਹ ਸੰਦਰਭ ਇਹ ਬਣਾਉਂਦਾ ਹੈ ਕਿ "ਇਹ ਕੁਐਰੀ ਸਲੋ ਸੀ" ਤੋਂ "ਇਹ ਕੁਐਰੀ ਇਸ ਸੇਵਾ ਲਈ, ਇਸ ਕਨੈਸ਼ਨ ਪੂਲ ਤੋਂ, ਇਸ ਬਿਲਕੁਲ ਸਮੇਂ 'ਤੇ ਸਲੋ ਸੀ" ਤੱਕ ਦਾ ਨਿਸ਼ਚੇਤ ਤੱਥ ਮਿਲ ਸਕੇ—ਜੋ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ ਜਦ ਕਈ ਐਪ ਇੱਕੋ ਹੀ ਡਾਟਾਬੇਸ ਸਾਂਝਾ ਕਰ ਰਹੇ ਹੋਣ।
ਸਲੋ ਕੁਐਰੀ ਲੌਗ ਹੁੰਦੇ ਹੀ ਆਮ ਤੌਰ 'ਤੇ "ਖ਼ਰਾਬ SQL" ਦੇ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੇ। ਇਹ ਸੰਕੇਤ ਹੁੰਦੇ ਹਨ ਕਿ ਡਾਟਾਬੇਸ ਨੂੰ ਵਧੇਰੇ ਕੰਮ ਕਰਨਾ ਪਿਆ ਜਾਂ ਉਹ ਕੁਝ ਦੇਣ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਸੀ। ਆਮ ਕਾਰਨ:
ਇਕ ਸਹਾਇਕ ਮਾਨਸਿਕ ਮਾਡਲ: ਸਲੋ ਕੁਐਰੀ ਲੌਗ ਦੋਹਾਂ ਨੂੰ ਕੈਪਚਰ ਕਰਦੇ ਹਨ—ਕੰਮ (CPU/I/O ਭਾਰੀ ਕੁਐਰੀਆਂ) ਅਤੇ ਉਡੀਕ (ਲੌਕ, ਸੈਚੁਰੇਸ਼ਨ)।
ਇੱਕ ਸਿੰਗਲ ਥ੍ਰੈਸ਼ਹੋਲਡ (ਉਦਾਹਰਨ ਲਈ, "500ms ਤੋਂ ਵੱਧ ਕੁਝ ਵੀ ਲੌਗ ਕਰੋ") ਸਧਾਰਨ ਹੈ, ਪਰ ਇਹ ਉਦਾਹਰਣ ਵਾਪਸ ਨਾ ਦੇਖੇ ਜਾ ਸਕਦੇ ਜਦ ਟਾਇਪਿਕਲ ਲੈਟੈਂਸੀ ਕਾਫ਼ੀ ਘੱਟ ਹੋਵੇ। ਵਿਚਾਰ ਕਰੋ:
ਇਸ ਨਾਲ ਸਲੋ ਕੁਐਰੀ ਲੌਗ actionable ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਮੈਟਰਿਕ ਰੁਝਾਨਾਂ ਨੂੰ ਉਭਾਰਦਾ ਹੈ।
ਜੇ ਪੈਰਾਮੀਟਰ inline ਹੋਣ ਤਾਂ ਸਲੋ ਕੁਐਰੀ ਲੌਗਾਂ ਅਕਸਰ ਨਿੱਜੀ ਡੇਟਾ ਫੜ ਸਕਦੀਆਂ ਹਨ (ਈਮੇਲ, ਟੋਕਨ, IDs)। ਪੈਰਾਮੀਟਰਾਈਜ਼ਡ ਕੁਐਰੀਆਂ ਅਤੇ ਉਹ ਸੈਟਿੰਗਾਂ ਵਰਤੋ ਜੋ ਕੁਐਰੀ ਸ਼ੇਪ ਲੌਗ ਕਰਦੀਆਂ ਹਨ ਨਾ ਕਿ ਰੋ-ਵੈਲਿਊਜ਼। ਜੇ ਬਚਣਾ ਨਾਹੀੰ ਹੋਵੇ ਤਾਂ ਲੌਗ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਮਾਸਕਿੰਗ/ਰੈਡੈਕਸ਼ਨ ਜੋੜੋ ਪਹਿਲਾਂ ਕਿ ਲੰਬੇ ਸਮੇਂ ਲਈ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇ ਜਾਂ ਘਟਨਾ-ਵਾਰ ਸਾਂਝਾ ਕੀਤਾ ਜਾਵੇ।
ਇਕ ਸਲੋ ਕੁਐਰੀ ਅਕਸਰ "ਕੇਵਲ ਸਲੋ" ਹੀ ਨਹੀਂ ਰਹਿੰਦੀ। ਆਮ ਚੇਨ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦੀ ਹੈ: ਯੂਜ਼ਰ ਲੈਟੈਂਸੀ → API ਲੈਟੈਂਸੀ → ਡਾਟਾਬੇਸ ਦਬਾਅ → ਟਾਈਮਆਊਟ। ਯੂਜ਼ਰ ਪਹਿਲਾਂ ਇਸਨੂੰ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ—ਪੇਜ ਅਟਕ ਜਾਂ ਸਕ੍ਰੀਨ ਘੁੰਮਣ। ਫਿਰ API ਮੈਟਰਿਕਸ ਵਿੱਚ ਉੱਚੇ ਰਿਸਪਾਂਸ ਟਾਈਮ ਆਉਂਦੇ ਹਨ, ਹਾਲਾਂਕਿ ਐਪ ਕੋਡ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ।
ਬਾਹਰੋਂ ਵੇਖਣ 'ਤੇ, ਇੱਕ ਸਲੋ ਡਾਟਾਬੇਸ ਅਕਸਰ “ਐਪ ਸਲੋ ਹੈ” ਵਾਂਗ ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ API ਥ੍ਰੈਡ ਕੁਐਰੀ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀ ਹੁੰਦੀ ਹੈ। ਐਪ ਸਰਵਰਾਂ ਉੱਤੇ CPU ਅਤੇ ਮੈਮੋਰੀ ਆਮ ਤੌਰ 'ਤੇ ਨਾਰਮਲ ਨਜ਼ਰ ਆ ਸਕਦੇ ਹਨ, ਫਿਰ ਵੀ p95 ਅਤੇ p99 ਲੈਟੈਂਸੀ ਵਧ ਸਕਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਐਪ-ਲੈਵਲ ਮੈਟਰਿਕ ਦੇਖਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਇਨ੍ਹੇਰੈਂਟ ਸ਼ੱਕ ਦੀ ਪਿੱਛੇ ਲੱਗ ਸਕਦੇ ਹੋ—HTTP ਹੈਂਡਲਰ, cache, ਜਾਂ ਡਿਪਲੌਇ—ਜਦਕਿ ਅਸਲ ਬੋਤਲ-ਨੇਕ ਇੱਕ ਇਕੱਲਾ ਕੁਐਰੀ ਪਲੈਨ ਰਿਗਰੈਸ ਹੋ ਸਕਦਾ ਹੈ।
ਜਿਵੇਂ ਹੀ ਇੱਕ ਕੁਐਰੀ ਧੀਮੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਸਿਸਟਮ ਨਿਪਟਾਰਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ—ਅਤੇ ਉਹ coping mechanisms ਫੇਲ ਨੂੰ ਵਧਾ ਸਕਦੇ ਹਨ:
ਇੱਕ checkout endpoint ਕਲਪਨਾ ਕਰੋ ਜੋ SELECT ... FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT 1 ਚਲਾਉਂਦਾ ਹੈ। ਡੇਟਾ ਵਾਧੇ ਤੋਂ ਬਾਅਦ ਇੰਡੈਕਸ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਹਾਇਤਾ ਨਹੀਂ ਕਰ ਰਿਹਾ ਅਤੇ ਕੁਐਰੀ ਸਮਾਂ 20ms ਤੋਂ 800ms ਹੋ ਜਾਂਦਾ ਹੈ। ਆਮ ਟ੍ਰੈਫਿਕ ਹੇਠਾਂ ਇਹ ਨਿਰਾਸ਼ਜਨਕ ਹੋ ਸਕਦਾ ਹੈ। ਪੀਕ ਟ੍ਰੈਫਿਕ ਹੇਠਾਂ, API ਰਿਕਵੇਸਟ DB ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਉਡੀਕ ਵਿੱਚ ਇਕਠੇ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, 2 ਸੈਕੰਡ 'ਤੇ timeout ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਕਲਾਇੰਟ ਰੀਟ੍ਰਾਈ ਕਰਦੇ ਹਨ। ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ, ਇੱਕ "ਛੋਟੀ" ਸਲੋ ਕੁਐਰੀ ਯੂਜ਼ਰ-ਦਿੱਖੀ errors ਅਤੇ ਪੂਰਾ ਪ੍ਰੋਡਕਸ਼ਨ ਘਟਨਾ ਬਣ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਡਾਟਾਬੇਸ ਸੰਘਰਸ਼ ਕੀਤਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਪਹਿਲੇ ਤਰ੍ਹਾਂ ਦੇ ਸੁਝਾਅ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਮੈਟਰਿਕਸ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਲਕਸ਼ ਮੰਨੋ ਸਭ ਕੁਝ ਟਰੈਕ ਨਾ ਕਰਨਾ—ਉਦੇਸ਼ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਬਦਲਾਵ ਪਕੜਨਾ ਅਤੇ ਫਿਰ ਇਸਦਾ ਸਰੋਤ ਨਿਰਧਾਰਤ ਕਰਨਾ ਹੈ।
ਇਹ ਚਾਰ ਸੰਕੇਤ ਤੁਹਾਨੂੰ ਦੱਸਣਗੇ ਕਿ ਕੀ ਤੁਸੀਂ ਡਾਟਾਬੇਸ ਸਮੱਸਿਆ ਦੇਖ ਰਹੇ ਹੋ, ਐਪ ਸਮੱਸਿਆ, ਜਾਂ ਦੋਹਾਂ:
ਕੁਝ DB-ਨਿਰਧਾਰਤ ਚਾਰਟ ਤੁਹਾਨੂੰ ਦੱਸ ਸਕਦੇ ਹਨ ਕਿ ਬੋਤਲ-ਨੈਕ execution, concurrency, ਜਾਂ storage ਨਾਲ ਸਬੰਧਤ ਹੈ:
DB ਮੈਟਰਿਕਸ ਨੂੰ ਸੇਵਾ ਦੇ ਅਨੁਭਵ ਨਾਲ ਜੋੜੋ:
ਡੈਸ਼ਬੋਰਡ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਤੇਜ਼ੀ ਨਾਲ ਇਹ ਪੁੱਛ ਸਕਣ:
ਜਦ ਇਹ ਮੈਟਰਿਕਸ ਮਿਲਦੇ ਹਨ—ਟੇਲ ਲੈਟੈਂਸੀ ਵਧ ਰਹੀ, ਟਾਈਮਆਊਟ ਵੱਧ ਰਹੇ, ਸੈਚੁਰੇਸ਼ਨ ਚੜ੍ਹ ਰਿਹਾ—ਤੁਹਾਡੇ ਕੋਲ ਮਜ਼ਬੂਤ ਸੰਕੇਤ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ slow query logs ਅਤੇ tracing ਵੱਲ ਮੋੜੋ ਅਤੇ ਅਸਲ ਓਪਰੇਸ਼ਨ ਦੀ ਪਛਾਣ ਕਰੋ।
ਸਲੋ ਕੁਐਰੀ ਲੌਗ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਡਾਟਾਬੇਸ ਵਿੱਚ ਕੀ ਸਲੋ ਸੀ। ਡਿਸਟ੍ਰਿਬਿਊਟਡ ਟਰੇਸਿੰਗ ਦੱਸਦੀ ਹੈ ਕਿਸਨੇ ਇਸ ਨੂੰ ਮੰਗਿਆ, ਕਿੱਥੋਂ, ਅਤੇ ਕਿਉਂ ਇਹ ਮਹੱਤਵਪੂਰਨ ਸੀ।
ਟ੍ਰੇਸਿੰਗ ਹੋਣ 'ਤੇ, "ਡਾਟਾਬੇਸ ਸਲੋ ਹੈ" ਦੀ alert ਇੱਕ ਸਪਸ਼ਟ ਕਹਾਣੀ ਬਣ ਜਾਂਦੀ ਹੈ: ਇੱਕ ਖਾਸ endpoint (ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ) ਨੇ ਕਾਲ ਕੀਤੀ, ਜਿਸ ਵਿੱਚੋਂ ਇੱਕ ਡਾਟਾਬੇਸ ਓਪਰੇਸ਼ਨ ਨੇ ਜ਼ਿਆਦਾਤਰ ਸਮਾਂ ਲਿਆ।
ਆਪਣੀ APM UI ਵਿੱਚ, ਉੱਚ-ਲੈਟੈਂਸੀ trace ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਲੱਭੋ:
GET /checkout ਜਾਂ billing_reconcile_worker)।ਟ੍ਰੇਸਾਂ ਵਿੱਚ ਪੂਰਾ SQL ਰਿਸ਼ਕ (PII, secrets, ਵੱਡਾ payload) ਹੋ ਸਕਦਾ ਹੈ। ਇਕ ਕਾਰਗੁਜ਼ਾਰ ਤਰੀਕਾ ਹੈ span ਨੂੰ ਕੁਐਰੀ ਨਾਮ/ਓਪਰੇਸ਼ਨ ਨਾਲ ਟੈਗ ਕਰਨਾ ਨਾ ਕਿ ਪੂਰੇ ਬਿਆਨ ਨਾਲ:
db.operation=SELECT ਅਤੇ db.table=ordersapp.query_name=orders_by_customer_v2feature_flag=checkout_upsellਇਸ ਨਾਲ ਟਰੇਸ ਖੋਜਯੋਗ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਫਿਰ ਵੀ ਤੁਹਾਨੂੰ ਕੋਡ ਪਾਥ ਵੱਲ ਇਸ਼ਾਰਾ ਮਿਲਦਾ ਹੈ।
"trace → app logs → slow query entry" ਨੂੰ ਜਲਦੀ ਜੋੜਨ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਇੱਕ ਸਾਂਝਾ ਆਈਡੀ ਹੈ:
ਹੁਣ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਉੱਚ-ਮੁੱਲ ਦੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ:
ਸਲੋ ਕੁਐਰੀ ਲੌਗ ਉਪਯੋਗੀ ਉਹ ਹੁੰਦੇ ਹਨ ਜਦ ਉਹ ਪੜ੍ਹਨਯੋਗ ਅਤੇ actionable ਰਹਿੰਦੇ ਹਨ। ਟੀਚਾ ਇਹ ਨਹੀਂ ਕਿ "ਸਭ ਕੁਝ ਹਮੇਸ਼ਾਂ ਲਾਗ ਹੋਵੇ"—ਇਹ ਹੈ ਕਾਫੀ ਵਿਸਥਾਰ ਕੈਪਚਰ ਕਰਨਾ ਤਾਂ ਜੋ ਪਤਾ ਚੱਲੇ ਕਿਉਂ ਕੁਐਰੀਆਂ ਸਲੋ ਹਨ, ਬਿਨਾਂ ਮਹੱਤਵਪੂਰਨ ਓਵਰਹੈੱਡ ਜਾਂ ਖ਼ਰਚ ਵਿਧਾਨ ਬਣੇ।
ਇੱਕ ਅਬਸੋਲੂਟ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਯੂਜ਼ਰ ਉਮੀਦਾਂ ਅਤੇ ਤੁਹਾਡੇ ਡਾਟਾਬੇਸ ਦੀ ਭੂਮਿਕਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੋਵੇ:
>200ms, ਮਿਲੇ-ਜੁле ਵਰਕਲੋਡ ਲਈ >500msਫਿਰ ਇੱਕ ਨਿਸ਼ਪੱਖ ਦ੍ਰਿਸ਼ ਜੋ ਤੁਸੀਂ ਸਿਸਟਮ ਜਦ੍ਹੋਂ ਹੌਲਾ ਹੋ ਜਾਵੇ ਤਾਂ ਵੀ ਰੈਗਰੈਸ਼ਨ ਦੇਖ ਸਕੋ:
ਦੋਹਾਂ ਵਰਤਣ ਨਾਲ ਅੰਧੇ ਧੱਫੇ ਰੋਕੇ ਜਾਂਦੇ ਹਨ: ਅਬਸੋਲੂਟ ਥ੍ਰੈਸ਼ਹੋਲਡ ਹਮੇਸ਼ਾਂ-ਗੰਭੀਰ ਕੁਐਰੀਆਂ ਨੂੰ ਪਕੜਦਾ ਹੈ, ਜਦਕਿ ਸਬੰਧਤ ਥ੍ਰੈਸ਼ਹੋਲਡ ਵੀੜ੍ਹੇ ਵੇਲੇ ਰੈਗਰੈਸ਼ਨ ਦਿਖਾਉਂਦਾ ਹੈ।
ਚੋਟੀ ਦੇ ਟ੍ਰੈਫਿਕ 'ਤੇ ਹਰ ਸਲੋ ਬਿਆਨ ਲਾਗ ਕਰਨ ਨਾਲ ਕਾਰਗੁਜ਼ਾਰੀ 'ਤੇ ਅਸਰ ਪੈ ਸਕਦਾ ਹੈ ਅਤੇ ਸ਼ੋਰ ਬਣ ਸਕਦਾ ਹੈ। ਸੈਂਪਲਿੰਗ ਵਰਤੋ (ਉਦਾਹਰਨ ਲਈ, 10–20% slow events ਲਾਗ ਕਰੋ) ਅਤੇ ਅਨੁਸਥਿਤੀ ਦੌਰਾਨ ਜਾਂ ਘਟਨਾ 'ਤੇ ਐਕਟਿਵਲੀਟੀ ਵਧਾਓ।
ਹਰ ਇਵੈਂਟ ਵਿੱਚ ਉਹ ਸੰਦਰਭ ਹੋਵੇ ਜੋ ਤੁਸੀਂ ਕਰਨ ਅਨੁਕੂਲ ਕਾਰਵਾਈ ਲਈ ਵਰਤੋਗੇ: duration, rows examined/returned, database/user, application name, ਅਤੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ request ਜਾਂ trace ID।
ਕੱਚੇ SQL ਸਟ੍ਰਿੰਗਾਂ ਵਿੱਚ ਵਧੀਆ ਮੀਆਂ-ਮਸਲੇ ਹੁੰਦੇ ਹਨ: ਵੱਖ-ਵੱਖ IDs ਅਤੇ timestamps ਇਕੋ ਕੁਐਰੀ ਨੂੰ ਵੱਖਰਾ ਦਿਖਾਉਂਦੇ ਹਨ। ਕੁਐਰੀ ਫਿੰਗਰਪ੍ਰਿੰਟਿੰਗ ਵਰਤੋ ਤਾਂ ਜੋ ਇੱਕੋ ਜਿਹੀ ਸ਼ਕਲ ਗਰੁੱਪ ਹੋ ਜਾਵੇ, ਉਦਾਹਰਨ WHERE user_id = ?।
ਇਸ ਨਾਲ ਤੁਸੀਂ ਪੁੱਛ ਸਕਦੇ ਹੋ: "ਕਿਹੜੀ ਕੁਐਰੀ ਸ਼ੇਪ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਲੈਟੈਂਸੀ ਪੈਦਾ ਕਰਦੀ ਹੈ?" ਨਾਂ ਕਿ ਇੱਕ-ਇੱਕ ਉਦਾਹਰਣ ਦਾ ਪਿਛਾ ਕਰੋ।
ਘਟਨਾ ਦੌਰਾਨਾ ਤੁਲਨਾ ਕਰਨ ਲਈ ਕਾਫੀ ਸਮੇਂ ਲਈ ਵਿਸਥਾਰ ਰੱਖੋ—ਅਮੂਮਨ 7–30 ਦਿਨ ਇੱਕ ਕਾਰਗੁਜ਼ਾਰ ਸ਼ੁਰੂਆਤੀ ਦਾਇਰਾ ਹੈ।
ਜੇ ਸਟੋਰੇਜ਼ ਚਿੰਤਾ ਹੈ, ਤਾਂ ਪਰਾਣੇ ਡੇਟਾ ਨੂੰ ਡਾਊਨਸੈਂਪ ਕਰੋ (ਅਗਰੀਗੇਟ ਅਤੇ top fingerprints ਰੱਖੋ) ਅਤੇ ਨਵੀਨਤਮ ਵਿੰਡੋ ਲਈ ਪੂਰੀ fidelity ਲੌਗ ਰੱਖੋ।
ਅਲਰਟ ਉਹਨਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਦੱਸਣ ਕਿ "ਯੂਜ਼ਰ ਇਸਨੂੰ ਮਹਿਸੂਸ ਕਰਨ ਵਾਲਾ ਹੈ" ਅਤੇ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ। ਸੌਖਾ ਤਰੀਕਾ ਹੈ ਲੱਛਣ (ਗਾਹਕ ਪ੍ਰਭਾਵ) ਅਤੇ ਕਾਰਨ (ਜੋ ਇਹ ਚਲਾ ਰਿਹਾ) 'ਤੇ ਅਲਰਟ ਰੱਖਣਾ, ਨਾਲੇ noise ਕੰਟਰੋਲ ਤਾਂ ਕਿ on-call ਨੂੰ ਪੇਜ਼ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨ ਦੀ ਆਦਤ ਨਾ ਪਏ।
ਛੋਟਾ ਸੈਟ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਗਾਹਕ ਦਰਦ ਨਾਲ ਮਿਲਦਾ ਹੈ:
ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਅਲਰਟਾਂ ਨੂੰ "ਸੋਨੇ ਦੇ ਰਸਤਿਆਂ" (checkout, login, search) 'ਤੇ ਸੀਮਿਤ ਕਰੋ ਤਾਂ ਕਿ ਘੱਟ-ਮਹੱਤਵਪੂਰਨ ਰੂਟਾਂ 'ਤੇ ਪੇਜ਼ ਨਾ ਆਵਣ।
ਲੱਛਣ ਅਲਰਟਾਂ ਨੂੰ ਕਾਰਨ-ਕੇਂਦਰਤ ਅਲਰਟਾਂ ਨਾਲ ਜੋੜੋ ਤਾਂ ਜੋ ਪਛਾਣ ਤੇਜ਼ ਹੋਵੇ:
ਇਹ ਕਾਰਨ ਅਲਰਟ ideal ਤੌਰ 'ਤੇ ਕਵਲ query fingerprint, sanitized example parameters, ਅਤੇ ਸਰਕਾਰੀ ਡੈਸ਼ਬੋਰਡ ਜਾਂ trace view ਵਿੱਚ ਜਾਣ ਦਾ ਸੰਦ ਮਦਦ ਨਾਲ ਆਉਣ।
ਵਰਤੋਂ ਕਰੋ:
ਹਰ ਪੇਜ਼ 'ਤੇ "ਮੈਂ ਅਗਲੇ ਕੀ ਕਰਾਂ?" ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ—ਇੱਕ ਰਨਬੁੱਕ ਦੇ ਪਹਿਲੇ ਤਿੰਨ ਜਾਂਚ-ਕਦਮ (ਲੈਟੈਂਸੀ ਪੈਨਲ, ਸਲੋ ਕੁਐਰੀ ਸੂਚੀ, ਲੌਕ/ਕਨੈਕਸ਼ਨ ਗ੍ਰਾਫ) ਦਰਸਾਓ। (ਉਦਾਹਰਣ: incident runbook)
ਜਦ ਲੈਟੈਂਸੀ spike ਹੁੰਦੀ ਹੈ, ਤੇਜ਼ੀ ਨਾਲ ਬਹੁਤ ਸੁਧਾਰ ਅਤੇ ਲੰਮਾ ਓਟੇਜ ਦੇ ਵਿਚਕਾਰ ਫ਼ਰਕ ਹੁੰਦਾ ਹੈ ਇੱਕ ਦੋਹਰਾਉਣਯੋਗ ਵਰਕਫਲੋ ਹੋਣਾ। ਉਦਦੇਸ਼ ਹੈ "ਕੁਝ ਸਲੋ ਹੈ" ਤੋਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕੁਐਰੀ, endpoint, ਅਤੇ ਬਦਲਾਅ ਤੱਕ ਜਾਣਾ ਜੋ ਇਸਨੂੰ ਸ਼ੁਰੂ ਕੀਤਾ।
ਯੂਜ਼ਰ ਲੱਛਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਉੱਚੀ ਰਿਕਵੇਸਟ ਲੈਟੈਂਸੀ, ਟਾਈਮਆਊਟ, ਜਾਂ ਐਰਰ ਦਰ।
ਛੋਟੇ ਸੈੱਟ ਉੱਤੇ ਪੁਸ਼ਟੀ ਕਰੋ: p95/p99 ਲੈਟੈਂਸੀ, throughput, ਅਤੇ ਡਾਟਾਬੇਸ ਸਿਹਤ (CPU, connections, queue/wait time)। ਇੱਕ-ਹੋਸਟ ਅਨੋਮਲੀਜ਼ ਦਾ ਪਿਛਾ ਨਾ ਕਰੋ—ਸੇਵਾ ਪੱਧਰ 'ਤੇ ਪੈਟਰਨ ਤਲਾਸ਼ੋ।
ਬਲਾਸਟ ਰੇਡੀਅਸ ਘਟਾਓ:
ਇਹ ਸਟੈਪ ਤੁਹਾਨੂੰ ਗਲਤ ਚੀਜ਼ ਤੇ optimize ਕਰਨ ਤੋਂ ਰੋਕਦੀ ਹੈ।
ਉੱਚ-ਲੈਟੈਂਸੀ trace ਖੋਲ੍ਹੋ ਅਤੇ ਸਭ ਤੋਂ ਲੰਬੀ ਦਰੂਟਿਨ ਨੂੰ ਛਾਂਟੋ।
ਉਹ span ਲੱਭੋ ਜੋ ਰਿਕਵੇਸਟ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਘੇਰ ਰਿਹਾ ਹੈ: ਇੱਕ ਡਾਟਾਬੇਸ ਕਾਲ, ਲੌਕ ਵੇਟ, ਜਾਂ ਦਹਰਾਈਆਂ ਕੁਐਰੀਆਂ (N+1)। trace ਦੇ context tags (release version, tenant ID, endpoint name) ਨਾਲ ਇਹ ਦੇਖੋ ਕਿ ਕੀ slowdown ਕਿਸ ਡਿਪਲੌਇ ਜਾਂ ਖਾਸ ਗਾਹਕ ਵਰਕਲੋਡ ਨਾਲ ਮਿਲਦਾ ਹੈ।
ਹੁਣ ਸੰਦੇਹੀ ਕੁਐਰੀ ਨੂੰ slow query logs ਵਿੱਚ ਵੈਰੀਫਾਈ ਕਰੋ।
"ਫਿੰਗਰਪ੍ਰਿੰਟ" (ਨਾਰਮਲਾਈਜ਼ਡ ਕੁਐਰੀਆਂ) 'ਤੇ ਧਿਆਨ ਦਿਓ ਤਾਂ ਜੋ ਕੁੱਲ ਸਮੇਂ ਅਤੇ ਗਿਣਤੀ ਦੇ ਆਧਾਰ 'ਤੇ ਸਭ ਤੋਂ ਵੱਡੇ offenders ਮਿਲ ਸਕਣ। ਫਿਰ ਪ੍ਰਭਾਵਿਤ ਟੇਬਲਾਂ ਅਤੇ ਪ੍ਰੇਡੀਕੇਟ (filters ਅਤੇ joins) ਨੋਟ ਕਰੋ। ਇੱਥੇ ਤੁਸੀਂ ਅਕਸਰ ਮਿਸਿੰਗ ਇੰਡੈਕਸ, ਨਵਾਂ JOIN, ਜਾਂ ਕੁਐਰੀ ਪਲੈਨ ਬਦਲਾਅ ਲੱਭਦੇ ਹੋ।
ਸਭ ਤੋਂ ਘੱਟ ਖਤਰਨਾਕ mitigation ਪਹਿਲਾਂ ਚੁਣੋ: ਰੋਲਬੈਕ ਰਿਲੀਜ਼, ਫੀਚਰ ਫਲੈਗ disable, ਲੋਡ shed, ਜਾਂ connection pool ਸੀਮਾਵਾਂ ਵਧਾਓ ਸਿਰਫ਼ ਜਦ ਤੁਸੀਂ ਯਕੀਨ ਕਰੋ ਕਿ ਇਹ contention ਨੂ ਵਧਾਏਗਾ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ ਕੁਐਰੀ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਛੋਟਾ ਅਤੇ ਮਾਪਯੋਗ ਬਦਲਾਅ ਕਰੋ।
ਇੱਕ ਕਾਰਗੁਜ਼ਾਰ ਸੁਝਾਅ: ਜੇ ਤੁਹਾਡੀ delivery pipeline ਇਸਨੂੰ ਸਹਾਇਤਾ ਕਰਦੀ ਹੈ ਤਾਂ "rollback" ਨੂੰ ਪਹਿਲ-ਸ਼੍ਰੇਣੀ ਬਟਨ ਸਮਝੋ, ਨਾ ਕਿ ਨਿਰਭਰਤਾ ਵਾਲਾ ਕਦਮ। ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਇਹਨੂੰ snapshots ਅਤੇ rollback workflows ਨਾਲ ਸਹੁਲਤ ਦਿੰਦੀਆਂ ਹਨ, ਜੋ ਰਿਲੀਜ਼ ਦੇ ਕਾਰਨ ਆਏ slow query patterns ਮੌਕੇ ਤੇ mitigate ਕਰਨ ਦੇ ਸਮੇਂ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਨ।
ਦਰਜ ਕਰੋ: ਕੀ ਬਦਲਿਆ, ਤੁਸੀਂ ਇਹ ਕਿਵੇਂ ਪਾਇਆ, ਠੀਕ ਕੀਤੀ ਗਈ ਫਿੰਗਰਪ੍ਰਿੰਟ, ਪ੍ਰਭਾਵਿਤ endpoints/tenants, ਅਤੇ ਕੀ ਇਸਨੂੰ ਠੀਕ ਕੀਤਾ। ਇਸਨੂੰ follow-up ਵਿੱਚ ਬਦਲੋ: ਇਕ ਅਲਰਟ ਜੋੜੋ, ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਪੈਨਲ, ਅਤੇ ਇੱਕ ਪਰਫਾਰਮੈਂਸ ਗਾਰਡਰੇਲ (ਉਦਾਹਰਨ: "ਕੋਈ ਵੀ query fingerprint X ms ਤੋਂ ਵੱਧ p95 'ਤੇ ਨਹੀਂ ਹੋਵੇ").
ਜਦ ਇੱਕ ਸਲੋ ਕੁਐਰੀ ਯੂਜ਼ਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਰਹੀ ਹੋਵੇ, ਟੀਚਾ ਪਹਿਲਾਂ ਪ੍ਰਭਾਵ ਘਟਾਉਣਾ ਅਤੇ ਫਿਰ ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰਨਾ—ਉਦੋ ਵੀ ਕਿ ਘਟਨਾ ਨੂੰ ਹੋਰ ਖਰਾਬ ਨਾ ਕੀਤਾ ਜਾਵੇ। Observability ਡੇਟਾ (ਸਲੋ ਕੁਐਰੀ ਨਮੂਨੇ, ਟ੍ਰੇਸ, ਅਤੇ ਮੁੱਖ DB ਮੈਟਰਿਕਸ) ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਲਿਵਰ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਖਿੱਚਣਾ ਹੈ।
ਉਸ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਡੇਟਾ ਵਿਹਵਾਰ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਲੋਡ ਘਟਾਉਂਦੇ ਹਨ:
ਇਹ mitigations ਵਕਤ ਖਰੀਦਦੇ ਹਨ ਅਤੇ p95 ਲੈਟੈਂਸੀ ਅਤੇ DB CPU/IO ਮੈਟਰਿਕਸ ਵਿੱਚ ਤੁਰੰਤ ਸੁਧਾਰ ਦਿਖਾਉਣੇ ਚਾਹੀਦੇ ਹਨ।
ਜਦ ਸਥਿਰ ਹੋ ਜਾਵੇ, ਅਸਲ ਕੁਐਰੀ ਪੈਟਰਨ ਨੂੰ ਠੀਕ ਕਰੋ:
EXPLAIN ਨਾਲ ਸੱਚਮੁਚ rows scanned ਘਟਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।SELECT * ਤੋਂ ਬਚੋ, ਚੁਣਿੰਦ਼ਾ predicates ਜੋੜੋ, correlated subqueries ਨੂੰ ਤਬਦੀਲ ਕਰੋ)।ਬਦਲਾਅ ਨੂੰ تدريجي ਤੌਰ 'ਤੇ ਲਗਾਓ ਅਤੇ ਉਹੀ trace/span ਅਤੇ slow query ਸਿਗਨੇਚਰ ਨਾਲ ਸੁਧਾਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਜਦ ਬਦਲਾਅ errors, ਲੌਕ ਕਨਟੈਂਸ਼ਨ, ਜਾਂ ਲੋਡ ਨੂੰ ਅਣਪੇਛਾਣੇ ਤਰੀਕੇ ਨਾਲ ਵਧਾਵੇ ਤਾਂ ਰੋਲਬੈਕ ਕਰੋ। ਜਦ ਤੁਸੀਂ ਇੱਕੋ ਕੁਐਰੀ ਜਾਂ ਇੱਕੋ endpoint ਨੂੰ ਅਲੱਗ ਕਰਕੇ ਨਿਰਧਾਰਿਤ ਕਰ ਲਓ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ/ਬਾਅਦ ਟੈਲੀਮੇਟਰੀ ਹੋਵੇ ਤਾਂ hotfix ਕਰੋ।
ਜਦ ਤੁਸੀਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਸਲੋ ਕੁਐਰੀ ਠੀਕ ਕਰ ਲੈਂਦੇ ਹੋ, ਅਸਲ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਇਕੋ ਪੈਟਰਨ ਮੁੜ ਨਾ ਆਵੇ। ਸਪੱਸ਼ਟ SLOs ਅਤੇ ਕੁਝ ਲਘੂ ਗਾਰਡਰੇਲ ਇਕ ਘਟਨਾ ਨੂੰ ਲੰਬੀ ਮਿਆਦ ਦੀ ਭਰੋਸੇਮੰਦਤਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।
ਉਨ੍ਹਾਂ SLIs ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਸੀਧੇ ਗਾਹਕ ਅਨੁਭਵ ਨਾਲ ਮਿਲਦੇ ਹਨ:
ਇੱਕ SLO ਐਸਾ ਰੱਖੋ ਜੋ ਮਨੁੱਖੀ ਢੰਗ 'ਤੇ ਅੰਗੀਕਾਰਯੋਗ ਹੋਵੇ, ਪੂਰਨ ਨਹੀਂ। ਉਦਾਹਰਣ: “p95 checkout ਲੈਟੈਂਸੀ 600ms ਤੋਂ ਘੱਟ 99.9% ਮਿੰਟਾਂ।” ਜਦ SLO ਖਤਰੇ ਵਿੱਚ ਹੋਵੇ, ਤੁਹਾਡੇ ਕੋਲ ਨਿਸ਼ਚਿਤ ਕਾਰਨ ਹੁੰਦਾ ਹੈ deploy ਰੋਕਣ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨ ਦਾ।
ਜ਼ਿਆਦਾਤਰ ਦੁਹਰਾਉਂਦੀਆਂ ਘਟਨਾਵਾਂ regressions ਹੁੰਦੀਆਂ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਅਸਾਨ ਬਣਾਓ:
ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਵਰਤੋਂ ਦਿਸ਼ਾ (p95/p99) 'ਚ ਬਦਲਾਅ ਵੇਖੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਔਸਤ।
ਇੱਕ ਛੋਟਾ ਸੈਟ ਚੁਣੋ "ਜੋ ਦੇਰ ਨਾ ਹੋਣ" ਵਾਲੇ endpoints ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਕੁੰਜੀ ਕੁਐਰੀਆਂ। CI ਵਿੱਚ performance checks ਸ਼ਾਮਲ ਕਰੋ ਜੋ latency ਜਾਂ query cost ਇੱਕ ਸੀਮਾ ਤੋਂ ਉੱਤੇ ਜਾਣ 'ਤੇ fail ਹੋ ਜਾਣ। ਇਹ N+1 ਬੱਗ, ਬੇ-ਹੱਦ ਫੁੱਲ ਟੇਬਲ ਸਕੈਨ, ਅਤੇ uncontrolled pagination ਨੂੰ ship ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਪਕੜ ਲੈਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸਰਵਿਸ ਬਣਾ ਰਹੇ ਹੋ (ਉਦਾਹਰਣ: Koder.ai ਵਰਗੀ chat-driven app builder ਜਿਸ ਨਾਲ React frontends, Go backends, ਅਤੇ PostgreSQL schemas ਤੇਜ਼ੀ ਨਾਲ ਬਣਦੇ ਹਨ), ਇਹ guardrails ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦੇ ਹਨ: ਰਫਤਾਰ ਇੱਕ ਫੀਚਰ ਹੈ, ਪਰ ਜੇ ਤੁਸੀਂ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਟੈਲੀਮੇਟਰੀ (trace IDs, query fingerprinting, ਅਤੇ ਸੁਰੱਖਿਅਤ ਲੌਗਿੰਗ) ਨਹੀਂ ਜੋੜਦੇ ਤਾਂ ਉਹ ਖਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ।
slowdown-ਕੁਐਰੀ ਸਮੀਖਿਆ ਕਿਸੇ ਇਕ ਦਾ ਕੰਮ ਬਣਾਓ, ਨਾ ਕਿ ਬਾਅਦ ਦੇ ਖਿਆਲ:
SLOs "ਕੀ ਚੰਗਾ ਦਿੱਸਦਾ ਹੈ" ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਕੇ ਅਤੇ guardrails drift ਨੂੰ ਫੜਕੇ, ਪਰਫਾਰਮੈਂਸ ਇੱਕ ਇਮਰਜੈਂਸੀ ਨਾ ਰਹਿ ਕੇ ਡਿਲਿਵਰੀ ਦਾ ਇੱਕ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਡਾਟਾਬੇ스-ਕੇਂਦਰਤ observability ਸੈੱਟਅੱਪ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਦੋ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿਨਾ ਚਾਹੀਦਾ ਹੈ: "ਕੀ ਡਾਟਾਬੇਸ ਬੋਤਲ-ਨੈਕ ਹੈ?" ਅਤੇ "ਕਿਹੜੀ ਕੁਐਰੀ (ਅਤੇ ਕਿਹੜਾ ਪੁਕਾਰਨਹਾਰ) ਇਸਦਾ ਕਾਰਨ ਹੈ?" ਸਭ ਤੋਂ ਵਧੀਆ ਸੈਟਅੱਪ ਇਹ ਸਪਸ਼ਟ ਬਣਾ ਦੇਂਦੇ ਹਨ ਬਿਨਾਂ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਇੱਕ ਘੰਟਾ ਰਾਹ ਖੋਜਣ ਲਈ ਕੱਚੇ ਲੌਗਾਂ ਵਿੱਚ grep ਕਰਨ ਲੈ।
ਲਾਜ਼ਮੀ ਮੈਟਰਿਕਸ (ਉੱਤੇ ਕੋਠੇ, ਕਲਸਟਰ, ਅਤੇ role/replica ਦੁਆਰਾ ਟੁੱਟੇ ਹੋਏ ideally):
ਸਲੋ ਕੁਐਰੀ ਲੌਗਾਂ ਲਈ ਲਾਜ਼ਮੀ ਲੌਗ ਫੀਲਡ:
ਟ੍ਰੇਸ ਟੈਗਸ ਜੋ ਬਿਨੈਤੀਆਂ ਨੂੰ ਕੁਐਰੀਆਂ ਨਾਲ ਜੋੜਦੇ ਹਨ:
ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਅਲਰਟਸ ਜੋ ਤੁਸੀਂ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹੋ:
ਕੀ ਇਹ endpoint latency spike ਨੂੰ ਇਕ ਨਿਰਧਾਰਿਤ query fingerprint ਅਤੇ release version ਨਾਲ correlate ਕਰ ਸਕਦਾ ਹੈ? ਇਹ ਸੈਂਪਲਿੰਗ ਨੂੰ ਕਿਵੇਂ ਹੈਂਡਲ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ rare, ਮਹਿੰਗੀਆਂ ਕੁਐਰੀਆਂ ਨੂੰ ਰੱਖ ਸਕੋ? ਕੀ ਇਹ noisy statements ਨੂੰ deduplicate (fingerprinting) ਕਰਦਾ ਹੈ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ regressions ਨੂੰ ਹਾਈਲਾਈਟ ਕਰਦਾ ਹੈ?
Built-in redaction (PII ਅਤੇ literals), RBAC, ਅਤੇ ਸਪੱਸ਼ਟ retention limits ਲੱਭੋ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ data warehouse/SIEM 'ਤੇ export ਇਸਨੂੰ ਬਾਈਪਾਸ ਨਾ ਕਰੇ।
ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਵਿਕਲਪਾਂ ਮੁਲਾਂਕਣ ਕਰ ਰਹੀ ਹੈ, ਤਾਂ ਜਲਦੀ ਤੋਂ ਜਲਦੀ ਮੰਗਾਂ ਨੂੰ ਏਲਾਈਨ ਕਰੋ—ਅੰਦਰੂਨੀ ਤਾਲਿਕਾ ਸਾਂਝਾ ਕਰੋ, ਫਿਰ ਵੇਂਡਰਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਚਾਹੋਗੇ ਤਾਂ ਇਕ ਛੋਟੀ ਤੁਲਨਾ ਜਾਂ ਰਹਿਨੁਮਾ ਲਈ ਸਹਾਇਤਾ ਕਰ ਸਕਦਾ ਹਾਂ—pricing ਜਾਂ contact ਨਾਲ ਸੰਪਰਕ ਕਰੋ।
ਪਹਿਲਾਂ endpoint ਪ੍ਰਤੀ ਟੇਲ ਲੈਟੈਂਸੀ (p95/p99) ਦੇਖੋ — ਕੇਵਲ ਐਵਰੇਜ ਨਹੀਂ। ਫਿਰ ਇਸ ਨੂੰ ਟਾਈਮਆਊਟ, ਰੀਟ੍ਰਾਈ ਦਰ, ਅਤੇ ਡਾਟਾਬੇਸ ਸੈਚੁਰੇਸ਼ਨ ਸੰਕੇਤਾਂ (ਕਨੈਕਸ਼ਨ ਵੇਟ, ਲੌਕ ਵੇਟ, CPU/I/O) ਨਾਲ ਸਾਂਝਾ ਕਰੋ.
ਜੇ ਇਹ ਸਭ ਇੱਕੋ ਸਮੇਂ ਉੱਠਦੇ ਹਨ ਤਾਂ ਟ੍ਰੇਸਿੰਗ ਵੱਲ ਮੁੜੋ ਤਾਂ ਜੋ slow span ਮਿਲ ਸਕੇ, ਤੇ ਫਿਰ slow query logs ਵਿੱਚ ਜਾ ਕੇ ਉਸ ਖਾਸ ਕੁਐਰੀ ਫਿੰਗਰਪ੍ਰਿੰਟ ਦੀ ਪਛਾਣ ਕਰੋ।
ਐਵਰੇਜ ਆਉਟਲਾਈਅਰਾਂ ਨੂੰ ਛੁਪਾ ਦਿੰਦੇ ਹਨ। ਥੋੜ੍ਹੇ ਜਿਹੇ ਬਹੁਤ ਸਲੋ ਰਿਕਵੇਸਟ ਵੀ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਨੂੰ ਖ਼ਰਾਬ ਕਰ ਸਕਦੇ ਹਨ ਜਦਕਿ mean ਉਦੋਂ ਠੀਕ ਹੀ ਲੱਗਦਾ ਹੈ।
ਲਖੋ:
ਇਹ ਨਿਸ਼ਾਨੇ ਡੂੰਘੇ ਲੰਬੇ-ਟੇਲ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ ਜੋ ਯੂਜ਼ਰ ਅਸਲ ਵਿੱਚ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ।
ਉਨ੍ਹਾਂ ਨੂੰ ਇਕੱਠੇ "ਕਿੱਥੇ" + "ਕੀ" ਵਜੋਂ ਵਰਤੋ।
ਇਹ ਮਿਲਕੇ root-cause ਤੱਕ ਪਹੁੰਚ ਦਾ ਸਮਾਂ ਘਟਾ ਦਿੰਦੇ ਹਨ।
ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ:
ਪਹਿਲਕਦਮ ਉਨ੍ਹਾਂ ਖੇਤਰਾਂ 'ਤੇ ਫੋਕਸ ਕਰੋ ਜੋ ਜਵਾਬ ਦੇ ਸਕਣ: ਕਿਹੜੀ ਸਰਵਿਸ ਨੇ ਕਿਹਾ, ਕਦੋਂ, ਅਤੇ ਕੀ ਇਹ ਵਾਪਰਦਾ ਰਹਿੰਦਾ ਹੈ?
ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਅਤੇ ਤੁਹਾਡੇ ਵਰਕਲੋਡ ਦੇ ਆਧਾਰ 'ਤੇ ਥ੍ਰੈਸ਼ਹੋਲਡ ਚੁਣੋ.
ਇੱਕ ਪ੍ਰਾਇਗਠਿਕ ਤਰੀਕਾ:
>200–500ms) ਤਾਂ ਜੋ ਸਚਮੁਚ ਦੀਆਂ ਬੁਰੀਆਂ ਕਵਾਇਰੀਆਂ ਪਕੜੀਆਂ ਜਾਣ।ਲਕਸ਼ ਇਹ ਹੈ ਕਿ ਲਾਗ ਕਾਰਜਕ ਹੋਵੇ; ਸਭ ਕੁਝ ਲੋਗ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ।
ਹੁਣੇ-ਹੁਣੇ ਹਰ ਘੱਟੋ-ਘੱਟ ਖਾਸ SQL ਸਟੇਟਮੈਂਟ ਵਿੱਚ ਭਿੰਨਤਾ ਕਾਰਨਲੇ ਇਕੱਠੀ ਹੋ ਸਕਦੀ ਹੈ। ਇਸ ਲਈ ਕੁਐਰੀ ਫਿੰਗਰਪ੍ਰਿੰਟਿੰਗ (ਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ) ਵਰਤੋ ਤਾਂ ਜੋ ਇੱਕੋ ਹੀ ਸ਼ਕਲ ਇਕੱਠੀ ਹੋ ਜਾਵੇ, ਭਾਵੇਂ ਆਈ.ਡੀ. ਜਾਂ ਟਾਈਮਸਟੈਂਪ ਵੱਖ-ਵੱਖ ਹੋਣ।
ਉਦਾਹਰਨ: WHERE user_id = ? ਦੀ ਤਰ੍ਹਾਂ ਗਰੁੱਪ ਕਰੋ ਨਾ ਕਿ WHERE user_id = 12345।
ਫਿਰ ਫਿੰਗਰਪ੍ਰਿੰਟਾਂ ਨੂੰ ਰੈਂਕ ਕਰੋ:
ਕੱਚੇ ਸੰਵੇਦਨਸ਼ੀਲ ਲਿਟਰਲ ਸਟੋਰ ਨਾ ਕਰੋ.
ਵਧੀਆ ਅਭਿਆਸ:
ਇੱਕ ਆਮ ਕੈਸਕੇਡ:
ਚੱਕਰ ਨੂੰ ਤੋੜਨ ਲਈ ਅਕਸਰ ਰੀਟ੍ਰਾਈ ਘਟਾਉਣ, ਪੂਲ ਉਪਲਬਧਤਾ بحال ਕਰਨ ਅਤੇ ਟੀਚਾ ਕੀਤੀ ਸਲੋ ਕੁਐਰੀ ਦੀ ਮੁਰੰਮਤ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।
ਦੋਹਾਂ ਲੱਛਣਾਂ ਅਤੇ ਮੁਲ ਕਾਰਨਾਂ 'ਤੇ ਅਲਰਟ ਕਰੋ।
ਲੱਛਣ (ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ):
ਕਾਰਨ (ਤਲਾਸ਼ੀ ਸ਼ੁਰੂਆਤ):
ਤੇਜ਼-ਗਤੀ ਰਾਹਤਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਕੁਐਰੀ ਨੂੰ ਠੀਕ ਕਰੋ।
ਤੁਰੰਤ ਰਾਹਤ ਲਈ:
ਫਿਰ ਕੁਐਰੀ ਦੀ ਮੁਰੰਮਤ:
ਇਸ ਨਾਲ ਘਟਨਾ-ਸਮੇਂ ਡੇਟਾ ਇਕਸਪੋਜ਼ਰ ਦਾ ਖਤਰਾ ਘਟਦਾ ਹੈ।
ਮਲਟੀ-ਵਿੰਡੋ / ਬਰਨ-ਰੇਟ ਪੈਟਰਨਜ਼ ਨਾਲ ਸ਼ੋਰ ਘਟਾਓ।
EXPLAIN ਨਾਲ ਢੰਗ ਦੀ ਪੜਤਾਲ ਕਰੋਸਦੀਕ ਇਪਲਾਈ ਕਰਨ ਅਤੇ ਉਹੀ trace/span ਅਤੇ ਫਿੰਗਰਪ੍ਰਿੰਟ ਦੇ ਨਾਲ ਸੁਧਾਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।