ਵਿਤਰਿਤ ਟਰੇਸਿੰਗ: ਅਸੀਂ ਇਹ ਸਭ ਗਲਤ ਕੀਤਾ ਹੈ

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਇਸ ਸਮੱਗਰੀ ਦਾ ਲੇਖਕ ਸਿੰਡੀ ਸ਼੍ਰੀਧਰਨ ਹੈ, imgix ਵਿੱਚ ਇੱਕ ਇੰਜੀਨੀਅਰ ਜੋ API ਵਿਕਾਸ ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਟੈਸਟਿੰਗ ਵਿੱਚ ਮਾਹਰ ਹੈ। ਇਸ ਸਮਗਰੀ ਵਿੱਚ, ਉਹ ਵਿਤਰਿਤ ਟਰੇਸਿੰਗ ਦੇ ਖੇਤਰ ਵਿੱਚ ਮੌਜੂਦਾ ਸਮੱਸਿਆਵਾਂ ਦੇ ਆਪਣੇ ਵਿਸਤ੍ਰਿਤ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਨੂੰ ਸਾਂਝਾ ਕਰਦੀ ਹੈ, ਜਿੱਥੇ, ਉਸਦੀ ਰਾਏ ਵਿੱਚ, ਦਬਾਉਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਅਸਲ ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਾਧਨਾਂ ਦੀ ਘਾਟ ਹੈ।

[ਇਸ ਤੋਂ ਲਿਆ ਗਿਆ ਦ੍ਰਿਸ਼ਟਾਂਤ ਹੋਰ ਸਮੱਗਰੀ ਵਿਤਰਿਤ ਟਰੇਸਿੰਗ ਬਾਰੇ।]

ਇਹ ਵਿਸ਼ਵਾਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਵੰਡਿਆ ਟਰੇਸਿੰਗ ਲਾਗੂ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ, ਅਤੇ ਇਸ 'ਤੇ ਵਾਪਸੀ ਵਧੀਆ 'ਤੇ ਸ਼ੱਕੀ. ਟਰੇਸਿੰਗ ਸਮੱਸਿਆ ਵਾਲੇ ਹੋਣ ਦੇ ਬਹੁਤ ਸਾਰੇ ਕਾਰਨ ਹਨ, ਅਕਸਰ ਹਰੇਕ ਬੇਨਤੀ ਦੇ ਨਾਲ ਢੁਕਵੇਂ ਸਿਰਲੇਖਾਂ ਨੂੰ ਸੰਚਾਰਿਤ ਕਰਨ ਲਈ ਹਰੇਕ ਸਿਸਟਮ ਕੰਪੋਨੈਂਟ ਨੂੰ ਸੰਰਚਿਤ ਕਰਨ ਵਿੱਚ ਸ਼ਾਮਲ ਲੇਬਰ ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹੋਏ। ਹਾਲਾਂਕਿ ਇਹ ਸਮੱਸਿਆ ਮੌਜੂਦ ਹੈ, ਪਰ ਇਹ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਦੂਰ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਤਰੀਕੇ ਨਾਲ, ਇਹ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਡਿਵੈਲਪਰ ਅਸਲ ਵਿੱਚ ਟਰੇਸਿੰਗ ਨੂੰ ਕਿਉਂ ਪਸੰਦ ਨਹੀਂ ਕਰਦੇ (ਭਾਵੇਂ ਇਹ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੋਵੇ)।

ਡਿਸਟਰੀਬਿਊਟਿਡ ਟਰੇਸਿੰਗ ਦੇ ਨਾਲ ਮੁੱਖ ਚੁਣੌਤੀ ਡਾਟਾ ਇਕੱਠਾ ਨਹੀਂ ਕਰਨਾ, ਨਤੀਜਿਆਂ ਨੂੰ ਵੰਡਣ ਅਤੇ ਪੇਸ਼ ਕਰਨ ਲਈ ਫਾਰਮੈਟਾਂ ਨੂੰ ਮਾਨਕੀਕਰਨ ਕਰਨਾ, ਜਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨਾ ਹੈ ਕਿ ਕਦੋਂ, ਕਿੱਥੇ, ਅਤੇ ਕਿਵੇਂ ਨਮੂਨਾ ਲੈਣਾ ਹੈ। ਮੈਂ ਕਲਪਨਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਿਹਾ ਮਾਮੂਲੀ ਇਹ "ਸਮਝਣਯੋਗਤਾ ਸਮੱਸਿਆਵਾਂ" ਅਸਲ ਵਿੱਚ, ਕਾਫ਼ੀ ਮਹੱਤਵਪੂਰਨ ਤਕਨੀਕੀ ਹਨ ਅਤੇ (ਜੇ ਅਸੀਂ ਸੱਚਮੁੱਚ ਓਪਨ ਸੋਰਸ 'ਤੇ ਵਿਚਾਰ ਕਰ ਰਹੇ ਹਾਂ) ਮਿਆਰ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ) ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਵਿਚਾਰ ਕਰਨ ਲਈ ਰਾਜਨੀਤਿਕ ਚੁਣੌਤੀਆਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਦੂਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਹਾਲਾਂਕਿ, ਜੇਕਰ ਅਸੀਂ ਕਲਪਨਾ ਕਰਦੇ ਹਾਂ ਕਿ ਇਹ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਹੋ ਗਈਆਂ ਹਨ, ਤਾਂ ਇੱਕ ਉੱਚ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਕੁਝ ਵੀ ਮਹੱਤਵਪੂਰਨ ਰੂਪ ਵਿੱਚ ਨਹੀਂ ਬਦਲੇਗਾ ਅੰਤਮ ਉਪਭੋਗਤਾ ਅਨੁਭਵ. ਸਭ ਤੋਂ ਆਮ ਡੀਬੱਗਿੰਗ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਟਰੇਸਿੰਗ ਅਜੇ ਵੀ ਵਿਹਾਰਕ ਉਪਯੋਗੀ ਨਹੀਂ ਹੋ ਸਕਦੀ - ਭਾਵੇਂ ਇਹ ਤੈਨਾਤ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਵੀ।

ਅਜਿਹਾ ਵੱਖਰਾ ਟਰੇਸ

ਵਿਤਰਿਤ ਟਰੇਸਿੰਗ ਵਿੱਚ ਕਈ ਵੱਖ-ਵੱਖ ਹਿੱਸੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ:

• ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਮਿਡਲਵੇਅਰ ਨੂੰ ਕੰਟਰੋਲ ਟੂਲਸ ਨਾਲ ਲੈਸ ਕਰਨਾ;
• ਵਿਤਰਿਤ ਸੰਦਰਭ ਟ੍ਰਾਂਸਫਰ;
• ਟਰੇਸ ਦਾ ਸੰਗ੍ਰਹਿ;
• ਟਰੇਸ ਸਟੋਰੇਜ਼;
• ਉਹਨਾਂ ਦੀ ਨਿਕਾਸੀ ਅਤੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ।

ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਟਰੇਸਿੰਗ ਬਾਰੇ ਬਹੁਤ ਸਾਰੀਆਂ ਗੱਲਾਂ ਇਸ ਨੂੰ ਇੱਕ ਕਿਸਮ ਦੇ ਅਪ੍ਰੇਸ਼ਨ ਦੇ ਰੂਪ ਵਿੱਚ ਮੰਨਦੀਆਂ ਹਨ ਜਿਸਦਾ ਇੱਕੋ ਇੱਕ ਉਦੇਸ਼ ਸਿਸਟਮ ਦੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਦਾਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨਾ ਹੈ। ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇਸ ਕਾਰਨ ਹੈ ਕਿ ਕਿਵੇਂ ਵੰਡੇ ਗਏ ਟਰੇਸਿੰਗ ਬਾਰੇ ਵਿਚਾਰ ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ ਬਣਾਏ ਗਏ ਹਨ। IN ਬਲੌਗ ਐਂਟਰੀਆਂ, ਜਦੋਂ ਜ਼ਿਪਕਿਨ ਸਰੋਤਾਂ ਨੂੰ ਖੋਲ੍ਹਿਆ ਗਿਆ ਸੀ, ਤਾਂ ਇਹ ਜ਼ਿਕਰ ਕੀਤਾ ਗਿਆ ਸੀ ਕਿ ਇਹ [ਜ਼ਿਪਕਿਨ] ਟਵਿੱਟਰ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ. ਟਰੇਸਿੰਗ ਲਈ ਪਹਿਲੀ ਵਪਾਰਕ ਪੇਸ਼ਕਸ਼ਾਂ ਨੂੰ ਵੀ ਅੱਗੇ ਵਧਾਇਆ ਗਿਆ ਸੀ APM ਟੂਲ.

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਹੋਰ ਟੈਕਸਟ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਅਸਾਨ ਬਣਾਉਣ ਲਈ, ਆਓ ਅਸੀਂ ਦੋ ਮੂਲ ਸ਼ਬਦਾਂ ਨੂੰ ਇਸਦੇ ਅਨੁਸਾਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੀਏ ਓਪਨਟਰੇਸਿੰਗ ਪ੍ਰੋਜੈਕਟ ਦਸਤਾਵੇਜ਼:

• span - ਵਿਤਰਿਤ ਟਰੇਸਿੰਗ ਦਾ ਮੂਲ ਤੱਤ। ਇਹ ਇੱਕ ਨਾਮ, ਸ਼ੁਰੂਆਤੀ ਅਤੇ ਸਮਾਪਤੀ ਸਮੇਂ, ਟੈਗਸ, ਲੌਗਸ ਅਤੇ ਸੰਦਰਭ ਦੇ ਨਾਲ ਇੱਕ ਖਾਸ ਵਰਕਫਲੋ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਡੇਟਾਬੇਸ ਪੁੱਛਗਿੱਛ) ਦਾ ਵਰਣਨ ਹੈ।
• ਸਪੈਨਾਂ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਦੂਜੇ ਸਪੈਨਾਂ ਦੇ ਲਿੰਕ ਹੁੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਕਈ ਸਪੈਨਾਂ ਨੂੰ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ ਟਰੇਸ - ਇੱਕ ਬੇਨਤੀ ਦੇ ਜੀਵਨ ਦੀ ਕਲਪਨਾ ਜਿਵੇਂ ਕਿ ਇਹ ਇੱਕ ਵਿਤਰਿਤ ਪ੍ਰਣਾਲੀ ਦੁਆਰਾ ਚਲਦੀ ਹੈ।

ਟਰੇਸ ਵਿੱਚ ਬਹੁਤ ਹੀ ਕੀਮਤੀ ਡੇਟਾ ਹੁੰਦਾ ਹੈ ਜੋ ਉਤਪਾਦਨ ਟੈਸਟਿੰਗ, ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਟੈਸਟਿੰਗ, ਗਲਤੀ ਇੰਜੈਕਸ਼ਨ ਟੈਸਟਿੰਗ, ਆਦਿ ਵਰਗੇ ਕੰਮਾਂ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਕੁਝ ਕੰਪਨੀਆਂ ਪਹਿਲਾਂ ਹੀ ਸਮਾਨ ਉਦੇਸ਼ਾਂ ਲਈ ਟਰੇਸਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ. ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ ਯੂਨੀਵਰਸਲ ਪ੍ਰਸੰਗ ਟ੍ਰਾਂਸਫਰ ਸਟੋਰੇਜ਼ ਸਿਸਟਮ ਵਿੱਚ ਸਪੈਨ ਨੂੰ ਤਬਦੀਲ ਕਰਨ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਵਰਤੋਂ ਹਨ:

• ਉਦਾਹਰਨ ਲਈ, Uber ਵਰਤਦਾ ਹੈ ਟੈਸਟ ਟ੍ਰੈਫਿਕ ਅਤੇ ਉਤਪਾਦਨ ਟ੍ਰੈਫਿਕ ਦੇ ਵਿਚਕਾਰ ਫਰਕ ਕਰਨ ਲਈ ਨਤੀਜਿਆਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ।
• ਫੇਸਬੁੱਕ ਵਰਤਦਾ ਹੈ ਨਾਜ਼ੁਕ ਮਾਰਗ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਨਿਯਮਤ ਆਫ਼ਤ ਰਿਕਵਰੀ ਟੈਸਟਾਂ ਦੌਰਾਨ ਟ੍ਰੈਫਿਕ ਬਦਲਣ ਲਈ ਡੇਟਾ ਦਾ ਪਤਾ ਲਗਾਓ।
• ਸੋਸ਼ਲ ਨੈਟਵਰਕ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜੁਪੀਟਰ ਨੋਟਬੁੱਕਾਂ ਜੋ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਟਰੇਸ ਨਤੀਜਿਆਂ 'ਤੇ ਮਨਮਾਨੇ ਸਵਾਲਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ।
• ਅਨੁਯਾਈ ਐੱਲ.ਡੀ.ਐੱਫ.ਆਈ (ਵੰਸ਼ ਸੰਚਾਲਿਤ ਅਸਫਲਤਾ ਇੰਜੈਕਸ਼ਨ) ਵਰਤਣ ਗਲਤੀ ਦੇ ਟੀਕੇ ਨਾਲ ਜਾਂਚ ਲਈ ਟਰੇਸ ਵੰਡੇ ਗਏ।

ਉਪਰੋਕਤ ਸੂਚੀਬੱਧ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਸਥਿਤੀ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ ਡੀਬੱਗਜਿਸ ਦੌਰਾਨ ਇੰਜੀਨੀਅਰ ਟਰੇਸ ਦੇਖ ਕੇ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।

ਜਦੋਂ ਇਹ ਆਉਂਦਾ ਹੈ ਫਿਰ ਵੀ ਡੀਬੱਗਿੰਗ ਸਕ੍ਰਿਪਟ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਪ੍ਰਾਇਮਰੀ ਇੰਟਰਫੇਸ ਡਾਇਗ੍ਰਾਮ ਰਹਿੰਦਾ ਹੈ ਟਰੇਸਵਿਊ (ਹਾਲਾਂਕਿ ਕੁਝ ਇਸਨੂੰ ਕਹਿੰਦੇ ਹਨ "ਗੈਂਟ ਚਾਰਟ" ਜ "ਝਰਨੇ ਦਾ ਚਿੱਤਰ"). ਅਧੀਨ ਟਰੇਸਵਿਊ я ਮੇਰਾ ਮਤਲਬ ਸਾਰੇ ਸਪੈਨ ਅਤੇ ਇਸਦੇ ਨਾਲ ਮੌਜੂਦ ਮੈਟਾਡੇਟਾ ਜੋ ਇਕੱਠੇ ਟਰੇਸ ਬਣਾਉਂਦੇ ਹਨ। ਹਰ ਓਪਨ ਸੋਰਸ ਟਰੇਸਿੰਗ ਸਿਸਟਮ, ਅਤੇ ਨਾਲ ਹੀ ਹਰ ਵਪਾਰਕ ਟਰੇਸਿੰਗ ਹੱਲ, ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ a ਟਰੇਸਵਿਊ ਟਰੇਸ ਦੀ ਕਲਪਨਾ, ਵੇਰਵੇ ਅਤੇ ਫਿਲਟਰਿੰਗ ਲਈ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ।

ਮੈਂ ਹੁਣ ਤੱਕ ਦੇਖੇ ਗਏ ਸਾਰੇ ਟਰੇਸਿੰਗ ਪ੍ਰਣਾਲੀਆਂ ਨਾਲ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਨਤੀਜਾ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ (ਟਰੇਸਵਿਊ) ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਟਰੇਸ ਪੈਦਾ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ. ਇੱਥੋਂ ਤੱਕ ਕਿ ਜਦੋਂ ਵਿਕਲਪਕ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਪ੍ਰਸਤਾਵਿਤ ਹਨ: ਹੀਟਮੈਪ, ਸਰਵਿਸ ਟੋਪੋਲੋਜੀਜ਼, ਲੇਟੈਂਸੀ ਹਿਸਟੋਗ੍ਰਾਮ, ਉਹ ਅਜੇ ਵੀ ਅੰਤ ਵਿੱਚ ਹੇਠਾਂ ਆਉਂਦੇ ਹਨ ਟਰੇਸਵਿਊ.

ਅਤੀਤ ਵਿੱਚ ਆਈ ਸ਼ਿਕਾਇਤ ਕੀਤੀ ਕਿ ਜ਼ਿਆਦਾਤਰ UI/UX ਟਰੇਸਿੰਗ "ਨਵੀਨਤਾਵਾਂ" ਤੱਕ ਸੀਮਿਤ ਜਾਪਦੀਆਂ ਹਨ ਚਾਲੂ ਹੋ ਰਿਹਾ ਹੈ ਟਰੇਸ ਵਿੱਚ ਵਾਧੂ ਮੈਟਾਡੇਟਾ, ਉੱਚ ਮੁੱਖਤਾ ਦੇ ਨਾਲ ਜਾਣਕਾਰੀ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨਾ (ਉੱਚ-ਮੁੱਖਤਾ) ਜਾਂ ਖਾਸ ਸਪੈਨਾਂ ਵਿੱਚ ਡ੍ਰਿਲ ਡਾਊਨ ਕਰਨ ਜਾਂ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਯੋਗਤਾ ਪ੍ਰਦਾਨ ਕਰਨਾ ਅੰਤਰ- ਅਤੇ ਅੰਤਰ-ਟਰੇਸ... ਜਿਸ ਵਿਚ ਟਰੇਸਵਿਊ ਪ੍ਰਾਇਮਰੀ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਟੂਲ ਰਹਿੰਦਾ ਹੈ। ਜਦੋਂ ਤੱਕ ਇਹ ਸਥਿਤੀ ਜਾਰੀ ਰਹਿੰਦੀ ਹੈ, ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਟਰੇਸਿੰਗ (ਵਧੀਆ ਤੌਰ 'ਤੇ) ਮੈਟ੍ਰਿਕਸ, ਲੌਗਸ ਅਤੇ ਸਟੈਕ ਟਰੇਸ ਤੋਂ ਬਾਅਦ, ਡੀਬੱਗਿੰਗ ਟੂਲ ਵਜੋਂ ਚੌਥਾ ਸਥਾਨ ਲੈ ਲਵੇਗੀ, ਅਤੇ ਸਭ ਤੋਂ ਬੁਰੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਪੈਸੇ ਅਤੇ ਸਮੇਂ ਦੀ ਬਰਬਾਦੀ ਹੋਵੇਗੀ।

ਟਰੇਸਵਿਊ ਨਾਲ ਸਮੱਸਿਆ

ਉਦੇਸ਼ ਟਰੇਸਵਿਊ — ਡਿਸਟਰੀਬਿਊਟਡ ਸਿਸਟਮ ਦੇ ਸਾਰੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਇੱਕ ਸਿੰਗਲ ਬੇਨਤੀ ਦੀ ਗਤੀ ਦੀ ਇੱਕ ਪੂਰੀ ਤਸਵੀਰ ਪ੍ਰਦਾਨ ਕਰੋ ਜਿਸ ਨਾਲ ਇਹ ਸੰਬੰਧਿਤ ਹੈ। ਕੁਝ ਹੋਰ ਉੱਨਤ ਟਰੇਸਿੰਗ ਸਿਸਟਮ ਤੁਹਾਨੂੰ ਵਿਅਕਤੀਗਤ ਸਪੈਨਾਂ ਵਿੱਚ ਡ੍ਰਿਲ ਡਾਊਨ ਕਰਨ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਟੁੱਟਣ ਨੂੰ ਦੇਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ ਅੰਦਰ ਇੱਕ ਪ੍ਰਕਿਰਿਆ (ਜਦੋਂ ਸਪੈਨ ਦੀਆਂ ਕਾਰਜਸ਼ੀਲ ਸੀਮਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ)।

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਆਰਕੀਟੈਕਚਰ ਦਾ ਮੂਲ ਆਧਾਰ ਇਹ ਵਿਚਾਰ ਹੈ ਕਿ ਸੰਸਥਾਗਤ ਢਾਂਚਾ ਕੰਪਨੀ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਨਾਲ ਵਧਦਾ ਹੈ। ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੇ ਸਮਰਥਕ ਇਹ ਦਲੀਲ ਦਿੰਦੇ ਹਨ ਕਿ ਵੱਖ-ਵੱਖ ਕਾਰੋਬਾਰੀ ਕੰਮਾਂ ਨੂੰ ਵਿਅਕਤੀਗਤ ਸੇਵਾਵਾਂ ਵਿੱਚ ਵੰਡਣਾ ਛੋਟੀਆਂ, ਖੁਦਮੁਖਤਿਆਰੀ ਵਿਕਾਸ ਟੀਮਾਂ ਨੂੰ ਅਜਿਹੀਆਂ ਸੇਵਾਵਾਂ ਦੇ ਪੂਰੇ ਜੀਵਨ ਚੱਕਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਉਹਨਾਂ ਸੇਵਾਵਾਂ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਬਣਾਉਣ, ਟੈਸਟ ਕਰਨ ਅਤੇ ਤਾਇਨਾਤ ਕਰਨ ਦੀ ਯੋਗਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਸ ਵੰਡ ਦਾ ਨੁਕਸਾਨ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦਾ ਨੁਕਸਾਨ ਹੈ ਕਿ ਹਰੇਕ ਸੇਵਾ ਦੂਜਿਆਂ ਨਾਲ ਕਿਵੇਂ ਗੱਲਬਾਤ ਕਰਦੀ ਹੈ। ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਵਿਤਰਿਤ ਟਰੇਸਿੰਗ ਇੱਕ ਲਾਜ਼ਮੀ ਸਾਧਨ ਹੋਣ ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ ਡੀਬੱਗ ਸੇਵਾਵਾਂ ਵਿਚਕਾਰ ਗੁੰਝਲਦਾਰ ਪਰਸਪਰ ਪ੍ਰਭਾਵ।

ਜੇ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਗੁੰਝਲਦਾਰ ਵੰਡ ਪ੍ਰਣਾਲੀ, ਫਿਰ ਕੋਈ ਵੀ ਵਿਅਕਤੀ ਇਸ ਨੂੰ ਆਪਣੇ ਸਿਰ ਵਿੱਚ ਰੱਖਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੈ ਮੁਕੰਮਲ ਤਸਵੀਰ। ਵਾਸਤਵ ਵਿੱਚ, ਇਸ ਧਾਰਨਾ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਸਾਧਨ ਵਿਕਸਿਤ ਕਰਨਾ ਕਿ ਇਹ ਸੰਭਵ ਵੀ ਹੈ ਇੱਕ ਐਂਟੀ-ਪੈਟਰਨ (ਇੱਕ ਬੇਅਸਰ ਅਤੇ ਗੈਰ-ਉਤਪਾਦਕ ਪਹੁੰਚ) ਹੈ। ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਡੀਬੱਗਿੰਗ ਲਈ ਇੱਕ ਸਾਧਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਮਦਦ ਕਰਦਾ ਹੈ ਆਪਣੇ ਖੋਜ ਖੇਤਰ ਨੂੰ ਛੋਟਾ ਕਰੋ, ਤਾਂ ਜੋ ਇੰਜੀਨੀਅਰ ਵਿਚਾਰੇ ਜਾ ਰਹੇ ਸਮੱਸਿਆ ਦੇ ਦ੍ਰਿਸ਼ ਨਾਲ ਸੰਬੰਧਿਤ ਮਾਪਾਂ (ਸੇਵਾਵਾਂ/ਉਪਭੋਗਤਾ/ਹੋਸਟ, ਆਦਿ) ਦੇ ਸਬਸੈੱਟ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਣ। ਅਸਫਲਤਾ ਦੇ ਕਾਰਨ ਦਾ ਪਤਾ ਲਗਾਉਣ ਵੇਲੇ, ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ ਕਿ ਇਸ ਦੌਰਾਨ ਕੀ ਹੋਇਆ ਸੀ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਇੱਕੋ ਸਮੇਂ, ਕਿਉਂਕਿ ਅਜਿਹੀ ਲੋੜ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਦੇ ਬਹੁਤ ਹੀ ਵਿਚਾਰ ਦਾ ਖੰਡਨ ਕਰੇਗੀ।

ਹਾਲਾਂਕਿ, ਟਰੇਸਵਿਊ ਹੈ ਅਰਥਾਤ ਇਹ. ਹਾਂ, ਕੁਝ ਟਰੇਸਿੰਗ ਸਿਸਟਮ ਕੰਪਰੈੱਸਡ ਟਰੇਸਵਿਯੂਜ਼ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ ਜਦੋਂ ਟਰੇਸ ਵਿੱਚ ਸਪੈਨ ਦੀ ਗਿਣਤੀ ਇੰਨੀ ਵੱਡੀ ਹੁੰਦੀ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਹਾਲਾਂਕਿ, ਅਜਿਹੀ ਸਟ੍ਰਿਪਡ-ਡਾਊਨ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਵਿੱਚ ਵੀ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਜਾਣਕਾਰੀ ਮੌਜੂਦ ਹੋਣ ਕਾਰਨ, ਇੰਜੀਨੀਅਰ ਅਜੇ ਵੀ ਮਜਬੂਰ ਇਸ ਨੂੰ "ਸਿਫਟ" ਕਰੋ, ਚੋਣ ਨੂੰ ਉਹਨਾਂ ਸੇਵਾਵਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਤੱਕ ਦਸਤੀ ਤੌਰ 'ਤੇ ਸੰਕੁਚਿਤ ਕਰੋ ਜੋ ਸਮੱਸਿਆਵਾਂ ਦੇ ਸਰੋਤ ਹਨ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਸ ਖੇਤਰ ਵਿੱਚ, ਮਸ਼ੀਨਾਂ ਮਨੁੱਖਾਂ ਨਾਲੋਂ ਬਹੁਤ ਤੇਜ਼ ਹਨ, ਗਲਤੀਆਂ ਦੀ ਘੱਟ ਸੰਭਾਵਨਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਨਤੀਜੇ ਵਧੇਰੇ ਦੁਹਰਾਉਣ ਯੋਗ ਹਨ।

ਇੱਕ ਹੋਰ ਕਾਰਨ ਜੋ ਮੈਂ ਸੋਚਦਾ ਹਾਂ ਕਿ ਟਰੇਸਵਿਊ ਗਲਤ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਅਨੁਮਾਨ-ਸੰਚਾਲਿਤ ਡੀਬੱਗਿੰਗ ਲਈ ਚੰਗਾ ਨਹੀਂ ਹੈ। ਇਸਦੇ ਮੂਲ ਵਿੱਚ, ਡੀਬੱਗਿੰਗ ਹੈ ਦੁਹਰਾਉਣ ਵਾਲਾ ਇੱਕ ਪਰਿਕਲਪਨਾ ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀ ਇੱਕ ਪ੍ਰਕਿਰਿਆ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਵੱਖ-ਵੱਖ ਵੈਕਟਰਾਂ, ਸਿੱਟੇ/ਆਮੀਕਰਨਾਂ ਦੇ ਨਾਲ ਸਿਸਟਮ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਵੱਖ-ਵੱਖ ਨਿਰੀਖਣਾਂ ਅਤੇ ਤੱਥਾਂ ਦੀ ਪੁਸ਼ਟੀ ਅਤੇ ਪਰਿਕਲਪਨਾ ਦੀ ਸੱਚਾਈ ਦਾ ਹੋਰ ਮੁਲਾਂਕਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਮੌਕਾ ਤੇਜ਼ ਅਤੇ ਸਸਤੇ ਅਨੁਮਾਨਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਅਤੇ ਉਸ ਅਨੁਸਾਰ ਮਾਨਸਿਕ ਮਾਡਲ ਨੂੰ ਸੁਧਾਰਨਾ ਹੈ ਨੀਂਹ ਪੱਥਰ ਡੀਬੱਗਿੰਗ ਕੋਈ ਵੀ ਡੀਬਗਿੰਗ ਟੂਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਇੰਟਰਐਕਟਿਵ ਅਤੇ ਖੋਜ ਸਪੇਸ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰੋ ਜਾਂ, ਇੱਕ ਗਲਤ ਲੀਡ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਉਪਭੋਗਤਾ ਨੂੰ ਵਾਪਸ ਜਾਣ ਅਤੇ ਸਿਸਟਮ ਦੇ ਇੱਕ ਵੱਖਰੇ ਖੇਤਰ 'ਤੇ ਫੋਕਸ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿਓ। ਸੰਪੂਰਣ ਸੰਦ ਇਹ ਕਰੇਗਾ ਸਰਗਰਮੀ ਨਾਲ, ਤੁਰੰਤ ਸੰਭਾਵੀ ਸਮੱਸਿਆ ਵਾਲੇ ਖੇਤਰਾਂ ਵੱਲ ਉਪਭੋਗਤਾ ਦਾ ਧਿਆਨ ਖਿੱਚਣਾ।

ਹਾਏ, ਟਰੇਸਵਿਊ ਇੰਟਰਐਕਟਿਵ ਇੰਟਰਫੇਸ ਵਾਲਾ ਟੂਲ ਨਹੀਂ ਕਿਹਾ ਜਾ ਸਕਦਾ। ਇਸਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਤੁਸੀਂ ਸਭ ਤੋਂ ਵਧੀਆ ਜਿਸਦੀ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹੋ ਉਹ ਹੈ ਵਧੀ ਹੋਈ ਲੇਟੈਂਸੀ ਦਾ ਕੁਝ ਸਰੋਤ ਲੱਭਣਾ ਅਤੇ ਇਸ ਨਾਲ ਜੁੜੇ ਸਾਰੇ ਸੰਭਾਵਿਤ ਟੈਗਾਂ ਅਤੇ ਲੌਗਾਂ ਨੂੰ ਵੇਖਣਾ। ਇਸ ਨਾਲ ਇੰਜੀਨੀਅਰ ਨੂੰ ਪਛਾਣਨ ਵਿਚ ਮਦਦ ਨਹੀਂ ਮਿਲਦੀ ਪੈਟਰਨ ਟ੍ਰੈਫਿਕ ਵਿੱਚ, ਜਿਵੇਂ ਕਿ ਦੇਰੀ ਵੰਡ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਜਾਂ ਵੱਖ-ਵੱਖ ਮਾਪਾਂ ਵਿਚਕਾਰ ਸਬੰਧਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ। ਆਮ ਟਰੇਸ ਵਿਸ਼ਲੇਸ਼ਣ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਸੱਚਮੁੱਚ, ਉਦਾਹਰਣਾਂ ਹਨ ਅਸਧਾਰਨ ਸਪੈਨਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਮਸ਼ੀਨ ਸਿਖਲਾਈ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਫਲ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਟੈਗਸ ਦੇ ਇੱਕ ਸਬਸੈੱਟ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਜੋ ਅਸੰਗਤ ਵਿਵਹਾਰ ਨਾਲ ਸੰਬੰਧਿਤ ਹੋ ਸਕਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਮੈਂ ਅਜੇ ਤੱਕ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਜਾਂ ਡੇਟਾ ਮਾਈਨਿੰਗ ਖੋਜਾਂ ਦੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨਾਂ ਨੂੰ ਵੇਖਣਾ ਹੈ ਜੋ ਸਪੈਨਸ 'ਤੇ ਲਾਗੂ ਕੀਤੇ ਗਏ ਹਨ ਜੋ ਟਰੇਸਵਿਊ ਜਾਂ ਡੀਏਜੀ (ਡਾਇਰੈਕਟਡ ਐਸੀਕਲਿਕ ਗ੍ਰਾਫ) ਤੋਂ ਕਾਫ਼ੀ ਵੱਖਰੇ ਹਨ।

ਸਪੈਨ ਬਹੁਤ ਨੀਵੇਂ ਪੱਧਰ ਦੇ ਹਨ

Traceview ਦੇ ਨਾਲ ਬੁਨਿਆਦੀ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਸਪੈਨ ਲੇਟੈਂਸੀ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਮੂਲ ਕਾਰਨ ਵਿਸ਼ਲੇਸ਼ਣ ਦੋਵਾਂ ਲਈ ਬਹੁਤ ਘੱਟ-ਪੱਧਰ ਦੇ ਮੁੱਢਲੇ ਹਨ। ਇਹ ਇੱਕ ਅਪਵਾਦ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਲਈ ਵਿਅਕਤੀਗਤ ਪ੍ਰੋਸੈਸਰ ਕਮਾਂਡਾਂ ਨੂੰ ਪਾਰਸ ਕਰਨ ਵਰਗਾ ਹੈ, ਇਹ ਜਾਣਦੇ ਹੋਏ ਕਿ ਬੈਕਟਰੇਸ ਵਰਗੇ ਬਹੁਤ ਸਾਰੇ ਉੱਚ-ਪੱਧਰੀ ਟੂਲ ਹਨ ਜੋ ਕੰਮ ਕਰਨ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੁਵਿਧਾਜਨਕ ਹਨ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮੈਂ ਹੇਠ ਲਿਖਿਆਂ ਦਾ ਦਾਅਵਾ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਲਵਾਂਗਾ: ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਸਾਨੂੰ ਲੋੜ ਨਹੀਂ ਹੈ ਪੂਰੀ ਤਸਵੀਰ ਬੇਨਤੀ ਜੀਵਨ-ਚੱਕਰ ਦੌਰਾਨ ਵਾਪਰਿਆ, ਜਿਸ ਨੂੰ ਆਧੁਨਿਕ ਟਰੇਸਿੰਗ ਟੂਲਸ ਦੁਆਰਾ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਇਸਦੀ ਬਜਾਏ, ਉੱਚ-ਪੱਧਰੀ ਐਬਸਟਰੈਕਸ਼ਨ ਦੇ ਕੁਝ ਰੂਪ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਕਿਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ ਗਲਤ ਹੋ ਗਿਆ (ਬੈਕਟਰੇਸ ਦੇ ਸਮਾਨ), ਕੁਝ ਸੰਦਰਭ ਦੇ ਨਾਲ। ਪੂਰੇ ਟਰੇਸ ਨੂੰ ਦੇਖਣ ਦੀ ਬਜਾਏ, ਮੈਂ ਇਸਨੂੰ ਦੇਖਣਾ ਪਸੰਦ ਕਰਦਾ ਹਾਂ ਦਾ ਹਿੱਸਾ, ਜਿੱਥੇ ਕੁਝ ਦਿਲਚਸਪ ਜਾਂ ਅਸਾਧਾਰਨ ਵਾਪਰਦਾ ਹੈ। ਵਰਤਮਾਨ ਵਿੱਚ, ਖੋਜ ਹੱਥੀਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ: ਇੰਜੀਨੀਅਰ ਟਰੇਸ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਦਿਲਚਸਪ ਚੀਜ਼ ਦੀ ਖੋਜ ਵਿੱਚ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਸਪੈਨ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ. ਸ਼ੱਕੀ ਗਤੀਵਿਧੀ ਦਾ ਪਤਾ ਲਗਾਉਣ ਦੀ ਉਮੀਦ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਟ੍ਰੇਸਾਂ ਵਿੱਚ ਸਪੈਨਾਂ ਨੂੰ ਦੇਖਣ ਵਾਲੇ ਲੋਕਾਂ ਦੀ ਪਹੁੰਚ ਬਿਲਕੁਲ ਵੀ ਮਾਪਦੀ ਨਹੀਂ ਹੈ (ਖਾਸ ਤੌਰ 'ਤੇ ਜਦੋਂ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਸਪੈਨਾਂ ਵਿੱਚ ਏਨਕੋਡ ਕੀਤੇ ਸਾਰੇ ਮੈਟਾਡੇਟਾ, ਜਿਵੇਂ ਕਿ ਸਪੈਨ ਆਈਡੀ, ਆਰਪੀਸੀ ਵਿਧੀ ਦਾ ਨਾਮ, ਮਿਆਦ ਦੀ ਮਿਆਦ ਨੂੰ ਸਮਝਣਾ ਪੈਂਦਾ ਹੈ। 'a, ਲੌਗਸ, ਟੈਗਸ, ਆਦਿ)।

ਟਰੇਸਵਿਊ ਲਈ ਵਿਕਲਪ

ਟਰੇਸ ਨਤੀਜੇ ਸਭ ਤੋਂ ਵੱਧ ਲਾਭਦਾਇਕ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਅਜਿਹੇ ਤਰੀਕੇ ਨਾਲ ਕਲਪਨਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਸਿਸਟਮ ਦੇ ਆਪਸ ਵਿੱਚ ਜੁੜੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਬਾਰੇ ਗੈਰ-ਮਾਮੂਲੀ ਸਮਝ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੱਕ ਅਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ, ਡੀਬੱਗਿੰਗ ਪ੍ਰਕਿਰਿਆ ਕਾਫ਼ੀ ਹੱਦ ਤੱਕ ਰਹਿੰਦੀ ਹੈ inert ਅਤੇ ਉਪਭੋਗਤਾ ਦੀ ਸਹੀ ਸਬੰਧਾਂ ਨੂੰ ਧਿਆਨ ਦੇਣ, ਸਿਸਟਮ ਦੇ ਸਹੀ ਹਿੱਸਿਆਂ ਦੀ ਜਾਂਚ ਕਰਨ, ਜਾਂ ਬੁਝਾਰਤ ਦੇ ਟੁਕੜਿਆਂ ਨੂੰ ਇਕੱਠੇ ਰੱਖਣ ਦੀ ਯੋਗਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ - ਇਸਦੇ ਉਲਟ ਸਾਧਨ, ਉਪਭੋਗਤਾ ਨੂੰ ਇਹਨਾਂ ਅਨੁਮਾਨਾਂ ਨੂੰ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਮੈਂ ਇੱਕ ਵਿਜ਼ੂਅਲ ਡਿਜ਼ਾਈਨਰ ਜਾਂ UX ਮਾਹਰ ਨਹੀਂ ਹਾਂ, ਪਰ ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਮੈਂ ਇਸ ਬਾਰੇ ਕੁਝ ਵਿਚਾਰ ਸਾਂਝੇ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਇਹ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਕਿਵੇਂ ਦਿਖਾਈ ਦੇ ਸਕਦੇ ਹਨ।

ਖਾਸ ਸੇਵਾਵਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ

ਅਜਿਹੇ ਸਮੇਂ 'ਤੇ ਜਦੋਂ ਉਦਯੋਗ ਵਿਚਾਰਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਮਜ਼ਬੂਤ ​​ਹੋ ਰਿਹਾ ਹੈ SLO (ਸੇਵਾ ਪੱਧਰ ਦੇ ਉਦੇਸ਼) ਅਤੇ SLI (ਸੇਵਾ ਪੱਧਰ ਦੇ ਸੂਚਕ), ਇਹ ਉਚਿਤ ਜਾਪਦਾ ਹੈ ਕਿ ਵਿਅਕਤੀਗਤ ਟੀਮਾਂ ਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਤਰਜੀਹ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਉਹਨਾਂ ਦੀਆਂ ਸੇਵਾਵਾਂ ਇਹਨਾਂ ਟੀਚਿਆਂ ਨਾਲ ਇਕਸਾਰ ਹਨ। ਇਹ ਇਸ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਸੇਵਾ ਮੁਖੀ ਅਜਿਹੀਆਂ ਟੀਮਾਂ ਲਈ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ।

ਟਰੇਸ, ਖਾਸ ਤੌਰ 'ਤੇ ਨਮੂਨੇ ਦੇ ਬਿਨਾਂ, ਵੰਡੇ ਗਏ ਸਿਸਟਮ ਦੇ ਹਰੇਕ ਹਿੱਸੇ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦਾ ਖਜ਼ਾਨਾ ਹੈ। ਇਹ ਜਾਣਕਾਰੀ ਇੱਕ ਚਲਾਕ ਪ੍ਰੋਸੈਸਰ ਨੂੰ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸਪਲਾਈ ਕਰੇਗਾ ਸੇਵਾ ਮੁਖੀ ਖੋਜਾਂ। ਉਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਪਛਾਣਿਆ ਜਾ ਸਕਦਾ ਹੈ - ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਨਿਸ਼ਾਨਾਂ ਨੂੰ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਵੀ:

1. ਲੇਟੈਂਸੀ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਡਾਇਗ੍ਰਾਮ ਸਿਰਫ਼ ਬਹੁਤ ਹੀ ਪ੍ਰਮੁੱਖ ਬੇਨਤੀਆਂ ਲਈ (ਬਾਹਰੀ ਬੇਨਤੀਆਂ);
2. ਜਦੋਂ ਸੇਵਾ SLO ਟੀਚਿਆਂ ਨੂੰ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੇਸਾਂ ਲਈ ਦੇਰੀ ਵੰਡ ਦੇ ਚਿੱਤਰ;
3. ਸਵਾਲਾਂ ਵਿੱਚ ਸਭ ਤੋਂ "ਆਮ", "ਦਿਲਚਸਪ" ਅਤੇ "ਅਜੀਬ" ਟੈਗਸ ਜੋ ਅਕਸਰ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ;
4. ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਲਈ ਲੇਟੈਂਸੀ ਬ੍ਰੇਕਡਾਊਨ ਜਿੱਥੇ ਨਿਰਭਰਤਾ ਸੇਵਾਵਾਂ ਆਪਣੇ SLO ਟੀਚਿਆਂ ਨੂੰ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰਦੀਆਂ;
5. ਵੱਖ-ਵੱਖ ਡਾਊਨਸਟ੍ਰੀਮ ਸੇਵਾਵਾਂ ਲਈ ਲੇਟੈਂਸੀ ਬ੍ਰੇਕਡਾਊਨ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਬਿਲਟ-ਇਨ ਮੈਟ੍ਰਿਕਸ ਦੁਆਰਾ ਨਹੀਂ ਦਿੱਤਾ ਜਾਂਦਾ, ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸਪੈਨ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਬਹੁਤ ਹੀ ਉਪਭੋਗਤਾ-ਵਿਰੋਧੀ ਵਿਧੀ ਹੈ।

ਇਹ ਸਵਾਲ ਉਠਾਉਂਦਾ ਹੈ: ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਵਿਭਿੰਨ ਸੇਵਾਵਾਂ ਵਿਚਕਾਰ ਗੁੰਝਲਦਾਰ ਪਰਸਪਰ ਕ੍ਰਿਆਵਾਂ ਬਾਰੇ ਕੀ? ਹੈ ਨਾ ਟਰੇਸਵਿਊ ਅਜਿਹੀ ਸਥਿਤੀ ਨੂੰ ਉਜਾਗਰ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਢੁਕਵਾਂ ਸਾਧਨ ਨਹੀਂ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ?

ਮੋਬਾਈਲ ਡਿਵੈਲਪਰ, ਸਟੇਟਲੈਸ ਸੇਵਾਵਾਂ ਦੇ ਮਾਲਕ, ਪ੍ਰਬੰਧਿਤ ਸਟੇਟਫੁੱਲ ਸੇਵਾਵਾਂ ਦੇ ਮਾਲਕ (ਜਿਵੇਂ ਕਿ ਡੇਟਾਬੇਸ) ਅਤੇ ਪਲੇਟਫਾਰਮ ਮਾਲਕਾਂ ਦੀ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਵਿੱਚ ਦਿਲਚਸਪੀ ਹੋ ਸਕਦੀ ਹੈ ਪੇਸ਼ਕਾਰੀ ਵੰਡਿਆ ਸਿਸਟਮ; ਟਰੇਸਵਿਊ ਇਹਨਾਂ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਵੱਖਰੀਆਂ ਲੋੜਾਂ ਲਈ ਬਹੁਤ ਆਮ ਹੱਲ ਹੈ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ ਬਹੁਤ ਹੀ ਗੁੰਝਲਦਾਰ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ, ਸੇਵਾ ਮਾਲਕਾਂ ਨੂੰ ਦੋ ਜਾਂ ਤਿੰਨ ਤੋਂ ਵੱਧ ਅੱਪਸਟਰੀਮ ਅਤੇ ਡਾਊਨਸਟ੍ਰੀਮ ਸੇਵਾਵਾਂ ਦੇ ਡੂੰਘੇ ਗਿਆਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ, ਜ਼ਿਆਦਾਤਰ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸਿਰਫ ਇਸ ਸੰਬੰਧੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਸੇਵਾਵਾਂ ਦਾ ਸੀਮਤ ਸਮੂਹ.

ਇਹ ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਵੱਡਦਰਸ਼ੀ ਸ਼ੀਸ਼ੇ ਦੁਆਰਾ ਸੇਵਾਵਾਂ ਦੇ ਇੱਕ ਛੋਟੇ ਉਪ ਸਮੂਹ ਨੂੰ ਵੇਖਣ ਵਰਗਾ ਹੈ। ਇਹ ਉਪਭੋਗਤਾ ਨੂੰ ਇਹਨਾਂ ਸੇਵਾਵਾਂ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਤਤਕਾਲ ਨਿਰਭਰਤਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਗੁੰਝਲਦਾਰ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਦੇ ਸੰਬੰਧ ਵਿੱਚ ਵਧੇਰੇ ਦਬਾਅ ਵਾਲੇ ਸਵਾਲ ਪੁੱਛਣ ਦੀ ਆਗਿਆ ਦੇਵੇਗਾ। ਇਹ ਸੇਵਾਵਾਂ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਬੈਕਟਰੇਸ ਦੇ ਸਮਾਨ ਹੈ, ਜਿੱਥੇ ਇੰਜੀਨੀਅਰ ਜਾਣਦਾ ਹੈ ਹੈ, ਜੋ ਕਿ ਗਲਤ ਹੈ, ਅਤੇ ਇਹ ਵੀ ਸਮਝਣ ਲਈ ਆਲੇ ਦੁਆਲੇ ਦੀਆਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਬਾਰੇ ਕੁਝ ਸਮਝ ਹੈ ਕਿਉਂ.

ਜਿਸ ਪਹੁੰਚ ਨੂੰ ਮੈਂ ਉਤਸ਼ਾਹਿਤ ਕਰ ਰਿਹਾ ਹਾਂ ਉਹ ਸਿਖਰ-ਡਾਊਨ, ਟਰੇਸਵਿਊ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਦੇ ਬਿਲਕੁਲ ਉਲਟ ਹੈ, ਜਿੱਥੇ ਵਿਸ਼ਲੇਸ਼ਣ ਪੂਰੇ ਟਰੇਸ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਹੌਲੀ-ਹੌਲੀ ਵਿਅਕਤੀਗਤ ਸਪੈਨ ਤੱਕ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਸਦੇ ਉਲਟ, ਇੱਕ ਤਲ-ਅੱਪ ਪਹੁੰਚ ਘਟਨਾ ਦੇ ਸੰਭਾਵੀ ਕਾਰਨ ਦੇ ਨੇੜੇ ਇੱਕ ਛੋਟੇ ਖੇਤਰ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਕੇ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਲੋੜ ਅਨੁਸਾਰ ਖੋਜ ਸਪੇਸ ਦਾ ਵਿਸਤਾਰ ਕਰਦੀ ਹੈ (ਸੇਵਾਵਾਂ ਦੀ ਇੱਕ ਵਿਸ਼ਾਲ ਸ਼੍ਰੇਣੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਦੂਜੀਆਂ ਟੀਮਾਂ ਨੂੰ ਲਿਆਉਣ ਦੀ ਸੰਭਾਵਨਾ ਦੇ ਨਾਲ)। ਦੂਜੀ ਪਹੁੰਚ ਸ਼ੁਰੂਆਤੀ ਅਨੁਮਾਨਾਂ ਦੀ ਜਲਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਬਿਹਤਰ ਹੈ। ਇੱਕ ਵਾਰ ਠੋਸ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਵਧੇਰੇ ਨਿਸ਼ਾਨਾ ਅਤੇ ਵਿਸਤ੍ਰਿਤ ਵਿਸ਼ਲੇਸ਼ਣ ਵੱਲ ਵਧਣਾ ਸੰਭਵ ਹੋਵੇਗਾ।

ਇੱਕ ਟੌਪੌਲੋਜੀ ਬਣਾਉਣਾ

ਸੇਵਾ-ਵਿਸ਼ੇਸ਼ ਦ੍ਰਿਸ਼ ਅਵਿਸ਼ਵਾਸ਼ਯੋਗ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੇ ਹਨ ਜੇਕਰ ਉਪਭੋਗਤਾ ਜਾਣਦਾ ਹੈ ਜੋ ਕਿ ਇੱਕ ਇੱਕ ਸੇਵਾ ਜਾਂ ਸੇਵਾਵਾਂ ਦਾ ਸਮੂਹ ਲੇਟੈਂਸੀ ਵਧਾਉਣ ਜਾਂ ਗਲਤੀਆਂ ਪੈਦਾ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਹਾਲਾਂਕਿ, ਇੱਕ ਗੁੰਝਲਦਾਰ ਪ੍ਰਣਾਲੀ ਵਿੱਚ, ਅਸਫਲਤਾ ਦੇ ਦੌਰਾਨ ਅਪਮਾਨਜਨਕ ਸੇਵਾ ਦੀ ਪਛਾਣ ਕਰਨਾ ਇੱਕ ਗੈਰ-ਮਾਮੂਲੀ ਕੰਮ ਹੋ ਸਕਦਾ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਜੇ ਸੇਵਾਵਾਂ ਤੋਂ ਕੋਈ ਗਲਤੀ ਸੁਨੇਹੇ ਰਿਪੋਰਟ ਨਹੀਂ ਕੀਤੇ ਗਏ ਸਨ।

ਸੇਵਾ ਟੋਪੋਲੋਜੀ ਬਣਾਉਣਾ ਇਹ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਇੱਕ ਵੱਡੀ ਮਦਦ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਸੇਵਾ ਵਿੱਚ ਗਲਤੀ ਦਰਾਂ ਵਿੱਚ ਵਾਧਾ ਹੋ ਰਿਹਾ ਹੈ ਜਾਂ ਲੇਟੈਂਸੀ ਵਿੱਚ ਵਾਧਾ ਹੋ ਰਿਹਾ ਹੈ ਜਿਸ ਕਾਰਨ ਸੇਵਾ ਨੂੰ ਧਿਆਨ ਨਾਲ ਘਟਾਇਆ ਜਾ ਰਿਹਾ ਹੈ। ਜਦੋਂ ਮੈਂ ਟੌਪੌਲੋਜੀ ਬਣਾਉਣ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹਾਂ, ਮੇਰਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਸੇਵਾਵਾਂ ਦਾ ਨਕਸ਼ਾ, ਸਿਸਟਮ ਵਿੱਚ ਉਪਲਬਧ ਹਰ ਸੇਵਾ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨਾ ਅਤੇ ਇਸਦੇ ਲਈ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ ਡੈਥ ਸਟਾਰ ਦੀ ਸ਼ਕਲ ਵਿੱਚ ਆਰਕੀਟੈਕਚਰ ਦੇ ਨਕਸ਼ੇ. ਇਹ ਦ੍ਰਿਸ਼ ਨਿਰਦੇਸ਼ਿਤ ਐਸੀਕਲਿਕ ਗ੍ਰਾਫ ਦੇ ਆਧਾਰ 'ਤੇ ਟਰੇਸਵਿਊ ਨਾਲੋਂ ਬਿਹਤਰ ਨਹੀਂ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ ਮੈਂ ਦੇਖਣਾ ਚਾਹਾਂਗਾ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੀ ਸੇਵਾ ਟੋਪੋਲੋਜੀ, ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਿਵੇਂ ਕਿ ਗਲਤੀ ਦਰ, ਪ੍ਰਤੀਕਿਰਿਆ ਸਮਾਂ, ਜਾਂ ਕੋਈ ਵੀ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਮਾਪਦੰਡ ਜੋ ਖਾਸ ਸ਼ੱਕੀ ਸੇਵਾਵਾਂ ਦੇ ਨਾਲ ਸਥਿਤੀ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਦੇ ਅਧਾਰ ਤੇ।

ਆਓ ਇੱਕ ਉਦਾਹਰਨ ਲਈਏ। ਆਉ ਇੱਕ ਕਾਲਪਨਿਕ ਖਬਰ ਸਾਈਟ ਦੀ ਕਲਪਨਾ ਕਰੀਏ. ਹੋਮ ਪੇਜ ਸੇਵਾ (ਪਹਿਲਾ ਪੰਨਾ) Redis ਦੇ ਨਾਲ, ਇੱਕ ਸਿਫ਼ਾਰਿਸ਼ ਸੇਵਾ ਦੇ ਨਾਲ, ਇੱਕ ਵਿਗਿਆਪਨ ਸੇਵਾ ਅਤੇ ਇੱਕ ਵੀਡੀਓ ਸੇਵਾ ਦੇ ਨਾਲ ਡੇਟਾ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਵੀਡੀਓ ਸੇਵਾ S3 ਤੋਂ ਵੀਡੀਓਜ਼ ਅਤੇ ਡਾਇਨਾਮੋਡੀਬੀ ਤੋਂ ਮੈਟਾਡੇਟਾ ਲੈਂਦੀ ਹੈ। ਸਿਫਾਰਿਸ਼ ਸੇਵਾ ਡਾਇਨਾਮੋਡੀਬੀ ਤੋਂ ਮੈਟਾਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ, ਰੈਡਿਸ ਅਤੇ ਮਾਈਐਸਕਯੂਐਲ ਤੋਂ ਡੇਟਾ ਲੋਡ ਕਰਦੀ ਹੈ, ਅਤੇ ਕਾਫਕਾ ਨੂੰ ਸੰਦੇਸ਼ ਲਿਖਦੀ ਹੈ। ਵਿਗਿਆਪਨ ਸੇਵਾ MySQL ਤੋਂ ਡਾਟਾ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ ਅਤੇ ਕਾਫਕਾ ਨੂੰ ਸੰਦੇਸ਼ ਲਿਖਦੀ ਹੈ।

ਹੇਠਾਂ ਇਸ ਟੌਪੌਲੋਜੀ ਦੀ ਯੋਜਨਾਬੱਧ ਪ੍ਰਤੀਨਿਧਤਾ ਹੈ (ਬਹੁਤ ਸਾਰੇ ਵਪਾਰਕ ਰੂਟਿੰਗ ਪ੍ਰੋਗਰਾਮ ਟੌਪੋਲੋਜੀ ਬਣਾਉਂਦੇ ਹਨ)। ਇਹ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਜੇਕਰ ਤੁਹਾਨੂੰ ਸੇਵਾ ਨਿਰਭਰਤਾ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ। ਹਾਲਾਂਕਿ, ਦੌਰਾਨ ਡੀਬੱਗ, ਜਦੋਂ ਕੋਈ ਖਾਸ ਸੇਵਾ (ਮੰਨੋ, ਇੱਕ ਵੀਡੀਓ ਸੇਵਾ) ਵਧੇ ਹੋਏ ਜਵਾਬ ਸਮੇਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੀ ਹੈ, ਤਾਂ ਅਜਿਹੀ ਟੋਪੋਲੋਜੀ ਬਹੁਤ ਲਾਭਦਾਇਕ ਨਹੀਂ ਹੁੰਦੀ ਹੈ।

ਇੱਕ ਕਾਲਪਨਿਕ ਖਬਰ ਸਾਈਟ ਦਾ ਸੇਵਾ ਚਿੱਤਰ

ਹੇਠਾਂ ਦਿੱਤਾ ਚਿੱਤਰ ਬਿਹਤਰ ਅਨੁਕੂਲ ਹੋਵੇਗਾ। ਸੇਵਾ ਵਿੱਚ ਕੋਈ ਸਮੱਸਿਆ ਹੈ (ਵੀਡੀਓ) ਸੱਜੇ ਕੇਂਦਰ ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਉਪਭੋਗਤਾ ਇਸ ਨੂੰ ਤੁਰੰਤ ਨੋਟਿਸ ਕਰਦਾ ਹੈ. ਇਸ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਤੋਂ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਵੀਡੀਓ ਸੇਵਾ S3 ਜਵਾਬ ਸਮੇਂ ਵਿੱਚ ਵਾਧੇ ਦੇ ਕਾਰਨ ਅਸਧਾਰਨ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰ ਰਹੀ ਹੈ, ਜੋ ਮੁੱਖ ਪੰਨੇ ਦੇ ਹਿੱਸੇ ਦੀ ਲੋਡ ਕਰਨ ਦੀ ਗਤੀ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੀ ਹੈ।

ਡਾਇਨਾਮਿਕ ਟੌਪੋਲੋਜੀ ਸਿਰਫ਼ "ਦਿਲਚਸਪ" ਸੇਵਾਵਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੀ ਹੈ

ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੇ ਟੋਪੋਲੋਜੀ ਸਥਿਰ ਸੇਵਾ ਨਕਸ਼ਿਆਂ ਨਾਲੋਂ ਵਧੇਰੇ ਕੁਸ਼ਲ ਹੋ ਸਕਦੇ ਹਨ, ਖਾਸ ਤੌਰ 'ਤੇ ਲਚਕੀਲੇ, ਆਟੋ-ਸਕੇਲਿੰਗ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ। ਸੇਵਾ ਟੌਪੋਲੋਜੀ ਦੀ ਤੁਲਨਾ ਅਤੇ ਵਿਪਰੀਤ ਕਰਨ ਦੀ ਯੋਗਤਾ ਉਪਭੋਗਤਾ ਨੂੰ ਵਧੇਰੇ ਸੰਬੰਧਿਤ ਪ੍ਰਸ਼ਨ ਪੁੱਛਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਸਿਸਟਮ ਬਾਰੇ ਵਧੇਰੇ ਸਟੀਕ ਸਵਾਲਾਂ ਨਾਲ ਸਿਸਟਮ ਦੇ ਕੰਮ ਕਰਨ ਦੀ ਬਿਹਤਰ ਸਮਝ ਹੋਣ ਦੀ ਜ਼ਿਆਦਾ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਹੈ।

ਤੁਲਨਾਤਮਕ ਡਿਸਪਲੇਅ

ਇੱਕ ਹੋਰ ਉਪਯੋਗੀ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਇੱਕ ਤੁਲਨਾਤਮਕ ਡਿਸਪਲੇ ਹੋਵੇਗੀ। ਵਰਤਮਾਨ ਵਿੱਚ ਟਰੇਸ ਸਾਈਡ-ਬਾਈ-ਸਾਈਡ ਤੁਲਨਾਵਾਂ ਲਈ ਬਹੁਤ ਢੁਕਵੇਂ ਨਹੀਂ ਹਨ, ਇਸਲਈ ਤੁਲਨਾ ਆਮ ਤੌਰ 'ਤੇ ਸਪੈਨ. ਅਤੇ ਇਸ ਲੇਖ ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਬਿਲਕੁਲ ਸਹੀ ਹੈ ਕਿ ਟਰੇਸ ਨਤੀਜਿਆਂ ਤੋਂ ਸਭ ਤੋਂ ਕੀਮਤੀ ਜਾਣਕਾਰੀ ਕੱਢਣ ਲਈ ਸਪੈਨ ਬਹੁਤ ਘੱਟ-ਪੱਧਰ ਹਨ.

ਦੋ ਟਰੇਸ ਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਨਵੇਂ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਇੱਕ ਹਿਸਟੋਗ੍ਰਾਮ ਵਰਗੀ ਕੋਈ ਚੀਜ਼ ਜੋ ਕਿ ਇੱਕ ਟਰੇਸਵਿਊ ਦੇ ਰੂਪ ਵਿੱਚ ਸਮਾਨ ਜਾਣਕਾਰੀ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ. ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਹੈ ਕਿ, ਇਹ ਸਧਾਰਨ ਤਰੀਕਾ ਵੀ ਸਿਰਫ਼ ਦੋ ਨਿਸ਼ਾਨਾਂ ਦਾ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਅਧਿਐਨ ਕਰਨ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਫਲ ਲਿਆ ਸਕਦਾ ਹੈ। ਹੋਰ ਵੀ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸੰਭਾਵਨਾ ਹੋਵੇਗੀ ਕਲਪਨਾ ਕਰੋ ਟਰੇਸ ਦੀ ਤੁਲਨਾ ਕੁੱਲ ਵਿੱਚ. ਇਹ ਦੇਖਣਾ ਬਹੁਤ ਲਾਭਦਾਇਕ ਹੋਵੇਗਾ ਕਿ GC (ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ) ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਲਈ ਹਾਲ ਹੀ ਵਿੱਚ ਤੈਨਾਤ ਡਾਟਾਬੇਸ ਸੰਰਚਨਾ ਤਬਦੀਲੀ ਕਈ ਘੰਟਿਆਂ ਦੇ ਪੈਮਾਨੇ 'ਤੇ ਇੱਕ ਡਾਊਨਸਟ੍ਰੀਮ ਸੇਵਾ ਦੇ ਜਵਾਬ ਸਮੇਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਤ ਕਰਦੀ ਹੈ। ਜੇ ਮੈਂ ਇੱਥੇ ਜੋ ਵਰਣਨ ਕਰ ਰਿਹਾ ਹਾਂ ਉਹ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਬਦਲਾਅ ਦੇ ਪ੍ਰਭਾਵ ਦੇ A/B ਵਿਸ਼ਲੇਸ਼ਣ ਵਰਗਾ ਲੱਗਦਾ ਹੈ ਬਹੁਤ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਟਰੇਸ ਨਤੀਜਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਫਿਰ ਤੁਸੀਂ ਸੱਚਾਈ ਤੋਂ ਬਹੁਤ ਦੂਰ ਨਹੀਂ ਹੋ.

ਸਿੱਟਾ

ਮੈਂ ਖੁਦ ਟਰੇਸਿੰਗ ਦੀ ਉਪਯੋਗਤਾ 'ਤੇ ਸਵਾਲ ਨਹੀਂ ਉਠਾਉਂਦਾ। ਮੈਂ ਇਮਾਨਦਾਰੀ ਨਾਲ ਵਿਸ਼ਵਾਸ ਕਰਦਾ ਹਾਂ ਕਿ ਇੱਕ ਟਰੇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਦੇ ਰੂਪ ਵਿੱਚ ਅਮੀਰ, ਕਾਰਨ ਅਤੇ ਪ੍ਰਸੰਗਿਕ ਡੇਟਾ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦਾ ਕੋਈ ਹੋਰ ਤਰੀਕਾ ਨਹੀਂ ਹੈ। ਹਾਲਾਂਕਿ, ਮੈਂ ਇਹ ਵੀ ਮੰਨਦਾ ਹਾਂ ਕਿ ਸਾਰੇ ਟਰੇਸਿੰਗ ਹੱਲ ਇਸ ਡੇਟਾ ਨੂੰ ਬਹੁਤ ਹੀ ਅਕੁਸ਼ਲਤਾ ਨਾਲ ਵਰਤਦੇ ਹਨ. ਜਿੰਨਾ ਚਿਰ ਟਰੇਸਿੰਗ ਟੂਲ ਟਰੇਸਵਿਊ ਨੁਮਾਇੰਦਗੀ 'ਤੇ ਫਸੇ ਰਹਿੰਦੇ ਹਨ, ਉਹ ਸਭ ਤੋਂ ਵੱਧ ਕੀਮਤੀ ਜਾਣਕਾਰੀ ਬਣਾਉਣ ਦੀ ਸਮਰੱਥਾ ਵਿੱਚ ਸੀਮਤ ਹੋਣਗੇ ਜੋ ਟਰੇਸ ਵਿੱਚ ਮੌਜੂਦ ਡੇਟਾ ਤੋਂ ਕੱਢੀ ਜਾ ਸਕਦੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗੈਰ-ਦੋਸਤਾਨਾ ਅਤੇ ਅਣਜਾਣ ਵਿਜ਼ੂਅਲ ਇੰਟਰਫੇਸ ਨੂੰ ਹੋਰ ਵਿਕਸਤ ਕਰਨ ਦਾ ਜੋਖਮ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਗਲਤੀਆਂ ਦਾ ਨਿਪਟਾਰਾ ਕਰਨ ਦੀ ਉਪਭੋਗਤਾ ਦੀ ਯੋਗਤਾ ਨੂੰ ਬੁਰੀ ਤਰ੍ਹਾਂ ਸੀਮਤ ਕਰ ਦੇਵੇਗਾ।

ਗੁੰਝਲਦਾਰ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਨਵੀਨਤਮ ਸਾਧਨਾਂ ਦੇ ਨਾਲ ਵੀ, ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ। ਟੂਲਸ ਨੂੰ ਡਿਵੈਲਪਰ ਨੂੰ ਇੱਕ ਅਨੁਮਾਨ ਤਿਆਰ ਕਰਨ ਅਤੇ ਟੈਸਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਸਰਗਰਮੀ ਨਾਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਢੁਕਵੀਂ ਜਾਣਕਾਰੀ, ਆਊਟਲੀਅਰਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ ਅਤੇ ਦੇਰੀ ਦੀ ਵੰਡ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਨੋਟ ਕਰਨਾ। ਉਤਪਾਦਨ ਅਸਫਲਤਾਵਾਂ ਦੇ ਨਿਪਟਾਰੇ ਜਾਂ ਕਈ ਸੇਵਾਵਾਂ ਨੂੰ ਫੈਲਾਉਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵੇਲੇ ਡਿਵੈਲਪਰਾਂ ਲਈ ਪਸੰਦ ਦਾ ਸਾਧਨ ਬਣਨ ਲਈ ਟਰੇਸਿੰਗ ਲਈ, ਮੂਲ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ ਅਤੇ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਉਹਨਾਂ ਸੇਵਾਵਾਂ ਨੂੰ ਬਣਾਉਣ ਅਤੇ ਚਲਾਉਣ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਦੇ ਮਾਨਸਿਕ ਮਾਡਲ ਨਾਲ ਵਧੇਰੇ ਅਨੁਕੂਲ ਹੁੰਦੇ ਹਨ।

ਇਹ ਇੱਕ ਸਿਸਟਮ ਨੂੰ ਡਿਜ਼ਾਇਨ ਕਰਨ ਲਈ ਮਹੱਤਵਪੂਰਨ ਮਾਨਸਿਕ ਜਤਨ ਲਵੇਗਾ ਜੋ ਟਰੇਸ ਨਤੀਜਿਆਂ ਵਿੱਚ ਉਪਲਬਧ ਵੱਖ-ਵੱਖ ਸੰਕੇਤਾਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਅਨੁਮਾਨ ਦੀ ਸੌਖ ਲਈ ਅਨੁਕੂਲ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਸੋਚਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਡੀਬੱਗਿੰਗ ਦੇ ਦੌਰਾਨ ਸਿਸਟਮ ਟੋਪੋਲੋਜੀ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਐਬਸਟਰੈਕਟ ਕਰਨਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਨੂੰ ਵਿਅਕਤੀਗਤ ਨਿਸ਼ਾਨਾਂ ਜਾਂ ਸਪੈਨਾਂ ਨੂੰ ਦੇਖੇ ਬਿਨਾਂ ਅੰਨ੍ਹੇ ਧੱਬਿਆਂ ਨੂੰ ਦੂਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਸਾਨੂੰ ਚੰਗੀ ਐਬਸਟਰੈਕਸ਼ਨ ਅਤੇ ਲੇਅਰਿੰਗ ਸਮਰੱਥਾਵਾਂ (ਖਾਸ ਕਰਕੇ UI ਵਿੱਚ) ਦੀ ਲੋੜ ਹੈ। ਉਹ ਜੋ ਇੱਕ ਪਰਿਕਲਪਨਾ ਦੁਆਰਾ ਸੰਚਾਲਿਤ ਡੀਬਗਿੰਗ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਹੋਣਗੇ ਜਿੱਥੇ ਤੁਸੀਂ ਦੁਹਰਾਓ ਸਵਾਲ ਪੁੱਛ ਸਕਦੇ ਹੋ ਅਤੇ ਅਨੁਮਾਨਾਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ। ਉਹ ਆਟੋਮੈਟਿਕ ਹੀ ਸਾਰੀਆਂ ਨਿਰੀਖਣਯੋਗਤਾ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰਨਗੇ, ਪਰ ਉਹ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਅਨੁਭਵ ਨੂੰ ਤਿੱਖਾ ਕਰਨ ਅਤੇ ਚੁਸਤ ਸਵਾਲ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨਗੇ। ਮੈਂ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਲਈ ਵਧੇਰੇ ਵਿਚਾਰਸ਼ੀਲ ਅਤੇ ਨਵੀਨਤਾਕਾਰੀ ਪਹੁੰਚ ਦੀ ਮੰਗ ਕਰਦਾ ਹਾਂ। ਦੂਰੀ ਨੂੰ ਵਧਾਉਣ ਲਈ ਇੱਥੇ ਇੱਕ ਅਸਲ ਸੰਭਾਵਨਾ ਹੈ.

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਕੁਬਰਨੇਟਸ ਪੌਡਸ ਵਿੱਚ ਡੀਬੱਗ ਕਰਨ ਲਈ kubectl-debug ਪਲੱਗਇਨ";
• «ਮਾਈਕਰੋ ਸਰਵਿਸਿਜ਼: ਆਕਾਰ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਭਾਵੇਂ ਤੁਹਾਡੇ ਕੋਲ ਕੁਬਰਨੇਟਸ ਹਨ";
• «ਨਿਗਰਾਨੀ ਅਤੇ ਕੁਬਰਨੇਟਸ (ਸਮੀਖਿਆ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)".

ਸਰੋਤ: www.habr.com