SRE (ਸਾਈਟ ਭਰੋਸੇਯੋਗਤਾ ਇੰਜੀਨੀਅਰਿੰਗ) ਵੈੱਬ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਣ ਲਈ ਇੱਕ ਪਹੁੰਚ ਹੈ। ਇਸਨੂੰ DevOps ਲਈ ਇੱਕ ਢਾਂਚਾ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ DevOps ਅਭਿਆਸਾਂ ਦੀ ਵਰਤੋਂ ਵਿੱਚ ਕਿਵੇਂ ਸਫ਼ਲ ਹੋਣਾ ਹੈ। ਇਹ ਲੇਖ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ ਚੈਪਟਰ 6 ਡਿਸਟਰੀਬਿਊਟਡ ਸਿਸਟਮਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਿਤਾਬਾਂ ਸਾਈਟ ਭਰੋਸੇਯੋਗਤਾ ਇੰਜੀਨੀਅਰਿੰਗ ਗੂਗਲ ਤੋਂ। ਮੈਂ ਇਹ ਅਨੁਵਾਦ ਖੁਦ ਤਿਆਰ ਕੀਤਾ ਹੈ ਅਤੇ ਨਿਗਰਾਨੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਮਝਣ ਦੇ ਆਪਣੇ ਅਨੁਭਵ 'ਤੇ ਭਰੋਸਾ ਕੀਤਾ ਹੈ। ਟੈਲੀਗ੍ਰਾਮ ਚੈਨਲ ਵਿੱਚ @monitorim_it и ਮੀਡੀਅਮ 'ਤੇ ਬਲੌਗ ਮੈਂ ਸੇਵਾ ਪੱਧਰ ਦੇ ਉਦੇਸ਼ਾਂ 'ਤੇ ਉਸੇ ਕਿਤਾਬ ਦੇ ਅਧਿਆਇ 4 ਦੇ ਅਨੁਵਾਦ ਦਾ ਲਿੰਕ ਵੀ ਪੋਸਟ ਕੀਤਾ ਹੈ।

ਬਿੱਲੀ ਦੁਆਰਾ ਅਨੁਵਾਦ. ਪੜ੍ਹਨ ਦਾ ਆਨੰਦ ਮਾਣੋ!

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

ਪਰਿਭਾਸ਼ਾਵਾਂ

ਨਿਗਰਾਨੀ ਨਾਲ ਸਬੰਧਤ ਵਿਸ਼ਿਆਂ 'ਤੇ ਚਰਚਾ ਕਰਨ ਲਈ ਕੋਈ ਵੀ ਸ਼ਬਦਾਵਲੀ ਨਹੀਂ ਵਰਤੀ ਜਾਂਦੀ। ਗੂਗਲ 'ਤੇ ਵੀ, ਹੇਠਾਂ ਦਿੱਤੇ ਸ਼ਬਦ ਆਮ ਵਰਤੋਂ ਵਿੱਚ ਨਹੀਂ ਹਨ, ਪਰ ਅਸੀਂ ਸਭ ਤੋਂ ਆਮ ਵਿਆਖਿਆਵਾਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਾਂਗੇ।

ਨਿਗਰਾਨੀ

ਸਿਸਟਮ ਬਾਰੇ ਰੀਅਲ-ਟਾਈਮ ਮਾਤਰਾਤਮਕ ਡੇਟਾ ਦਾ ਸੰਗ੍ਰਹਿ, ਪ੍ਰੋਸੈਸਿੰਗ, ਏਕੀਕਰਣ ਅਤੇ ਡਿਸਪਲੇ: ਬੇਨਤੀਆਂ ਦੀ ਸੰਖਿਆ ਅਤੇ ਬੇਨਤੀਆਂ ਦੀਆਂ ਕਿਸਮਾਂ, ਤਰੁਟੀਆਂ ਦੀ ਸੰਖਿਆ ਅਤੇ ਤਰੁੱਟੀਆਂ ਦੀਆਂ ਕਿਸਮਾਂ, ਬੇਨਤੀ ਪ੍ਰਕਿਰਿਆ ਸਮਾਂ ਅਤੇ ਸਰਵਰ ਅਪਟਾਈਮ।

ਵ੍ਹਾਈਟ ਬਾਕਸ ਦੀ ਨਿਗਰਾਨੀ

ਲੌਗਸ, JVM ਜਾਂ HTTP ਹੈਂਡਲਰ ਪ੍ਰੋਫਾਈਲਿੰਗ ਮੈਟ੍ਰਿਕਸ ਜੋ ਅੰਦਰੂਨੀ ਅੰਕੜੇ ਤਿਆਰ ਕਰਦੇ ਹਨ, ਸਮੇਤ ਸਿਸਟਮ ਅੰਦਰੂਨੀ ਦੁਆਰਾ ਪ੍ਰਦਰਸ਼ਿਤ ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਆਧਾਰਿਤ ਨਿਗਰਾਨੀ।

ਬਲੈਕ ਬਾਕਸ ਦੀ ਨਿਗਰਾਨੀ

ਉਪਭੋਗਤਾ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਵਿਵਹਾਰ ਦੀ ਜਾਂਚ ਕਰਨਾ.

ਡੈਸ਼ਬੋਰਡ (ਡੈਸ਼ਬੋਰਡ)

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

ਚੇਤਾਵਨੀ (ਸੂਚਨਾ)

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

ਮੁਖ ਕਾਰਣ

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

ਨੋਡ ਅਤੇ ਮਸ਼ੀਨ (ਨੋਡ ਅਤੇ ਮਸ਼ੀਨ)

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

• ਇੱਕ ਦੂਜੇ ਨਾਲ ਸਬੰਧਤ: ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਕੈਸ਼ ਸਰਵਰ ਅਤੇ ਇੱਕ ਵੈੱਬ ਸਰਵਰ;
• ਸਮਾਨ ਹਾਰਡਵੇਅਰ 'ਤੇ ਗੈਰ-ਸੰਬੰਧਿਤ ਸੇਵਾਵਾਂ: ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਕੋਡ ਰਿਪੋਜ਼ਟਰੀ ਅਤੇ ਇੱਕ ਸੰਰਚਨਾ ਸਿਸਟਮ ਲਈ ਇੱਕ ਵਿਜ਼ਾਰਡ, ਜਿਵੇਂ ਕਿ ਕਠਪੁਤਲੀ ਜ ਸਿਰ '.

ਪੁਸ਼

ਸਾਫਟਵੇਅਰ ਸੰਰਚਨਾ ਵਿੱਚ ਕੋਈ ਵੀ ਬਦਲਾਅ।

ਨਿਗਰਾਨੀ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ

ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੇ ਕਈ ਕਾਰਨ ਹਨ:

ਲੰਬੇ ਸਮੇਂ ਦੇ ਰੁਝਾਨਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ

ਡੇਟਾਬੇਸ ਕਿੰਨਾ ਵੱਡਾ ਹੈ ਅਤੇ ਇਹ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਰਿਹਾ ਹੈ? ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਰੋਜ਼ਾਨਾ ਗਿਣਤੀ ਕਿਵੇਂ ਬਦਲਦੀ ਹੈ?

ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਤੁਲਨਾ

ਕੀ Ajax DB 2.72 ਨਾਲੋਂ ਬਾਈਟਸ 3.14 ਦੀ Acme ਬਕੇਟ 'ਤੇ ਸਵਾਲ ਤੇਜ਼ ਹਨ? ਇੱਕ ਵਾਧੂ ਨੋਡ ਦੀ ਦਿੱਖ ਤੋਂ ਬਾਅਦ ਬੇਨਤੀਆਂ ਨੂੰ ਕੈਸ਼ ਕਰਨਾ ਕਿੰਨਾ ਵਧੀਆ ਹੈ? ਕੀ ਸਾਈਟ ਪਿਛਲੇ ਹਫ਼ਤੇ ਨਾਲੋਂ ਹੌਲੀ ਹੋ ਗਈ ਹੈ?

ਚੇਤਾਵਨੀ (ਸੂਚਨਾਵਾਂ)

ਕੁਝ ਟੁੱਟ ਗਿਆ ਹੈ ਅਤੇ ਕਿਸੇ ਨੇ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨਾ ਹੈ. ਜਾਂ ਕੁਝ ਜਲਦੀ ਟੁੱਟ ਜਾਵੇਗਾ ਅਤੇ ਕਿਸੇ ਨੂੰ ਜਲਦੀ ਹੀ ਇਸਦੀ ਜਾਂਚ ਕਰਨੀ ਪਵੇਗੀ.

ਡੈਸ਼ਬੋਰਡ ਬਣਾਉਣਾ

ਡੈਸ਼ਬੋਰਡਾਂ ਨੂੰ ਬੁਨਿਆਦੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ "4 ਸੁਨਹਿਰੀ ਸੰਕੇਤ" - ਦੇਰੀ (ਲੇਟੈਂਸੀ), ਟ੍ਰੈਫਿਕ (ਟ੍ਰੈਫਿਕ), ਗਲਤੀਆਂ (ਤਰੁੱਟੀਆਂ) ਅਤੇ ਲੋਡ ਮੁੱਲ (ਸੰਤ੍ਰਿਪਤਾ)।

ਪਿਛਾਖੜੀ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ (ਡੀਬੱਗਿੰਗ)

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

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

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

ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਤੋਂ ਵਾਜਬ ਉਮੀਦਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ

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

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

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

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

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

ਲੱਛਣ ਬਨਾਮ ਕਾਰਨ

ਤੁਹਾਡੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਦੋ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ: "ਕੀ ਟੁੱਟਿਆ ਹੈ" ਅਤੇ "ਇਹ ਕਿਉਂ ਟੁੱਟਿਆ ਹੈ"।
"ਕੀ ਟੁੱਟਿਆ" ਲੱਛਣ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ "ਕਿਉਂ ਟੁੱਟਿਆ" ਕਾਰਨ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਅਜਿਹੇ ਲਿੰਕਾਂ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ।

ਲੱਛਣ
ਕਾਰਨ

HTTP ਗਲਤੀ 500 ਜਾਂ 404 ਪ੍ਰਾਪਤ ਕਰ ਰਿਹਾ ਹੈ
ਡਾਟਾਬੇਸ ਸਰਵਰ ਕੁਨੈਕਸ਼ਨਾਂ ਤੋਂ ਇਨਕਾਰ ਕਰ ਰਹੇ ਹਨ

ਹੌਲੀ ਸਰਵਰ ਜਵਾਬ
ਉੱਚ CPU ਉਪਯੋਗਤਾ ਜਾਂ ਖਰਾਬ ਹੋਈ ਈਥਰਨੈੱਟ ਕੇਬਲ

ਅੰਟਾਰਕਟਿਕਾ ਵਿੱਚ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਬਿੱਲੀ ਦੇ GIF ਨਹੀਂ ਮਿਲ ਰਹੇ ਹਨ
ਤੁਹਾਡਾ CDN ਵਿਗਿਆਨੀਆਂ ਅਤੇ ਫੇਲਿਨਾਂ ਨੂੰ ਨਫ਼ਰਤ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਕੁਝ IP ਬਲੈਕਲਿਸਟ ਕੀਤੇ ਗਏ ਹਨ

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

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

ਬਲੈਕ-ਬਾਕਸ ਬਨਾਮ ਵ੍ਹਾਈਟ-ਬਾਕਸ

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

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

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

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

ਚਾਰ ਸੁਨਹਿਰੀ ਸੰਕੇਤ

ਚਾਰ ਸੁਨਹਿਰੀ ਨਿਗਰਾਨੀ ਸਿਗਨਲ ਲੇਟੈਂਸੀ, ਟ੍ਰੈਫਿਕ, ਗਲਤੀਆਂ ਅਤੇ ਸੰਤ੍ਰਿਪਤਾ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਚਾਰ ਉਪਭੋਗਤਾ ਸਿਸਟਮ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਮਾਪ ਸਕਦੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਚਾਰਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰੋ।

ਦੇਰੀ

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

ਆਵਾਜਾਈ

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

ਗਲਤੀਆਂ

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

ਸੰਤ੍ਰਿਪਤਾ

ਮੈਟ੍ਰਿਕ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਸੇਵਾ ਕਿੰਨੀ ਭਾਰੀ ਵਰਤੀ ਜਾ ਰਹੀ ਹੈ। ਇਹ ਇੱਕ ਸਿਸਟਮ ਨਿਗਰਾਨੀ ਮਾਪ ਹੈ ਜੋ ਸਭ ਤੋਂ ਸੀਮਿਤ ਸਰੋਤਾਂ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਸੀਮਤ ਮੈਮੋਰੀ ਵਾਲੇ ਸਿਸਟਮ ਵਿੱਚ, ਮੈਮੋਰੀ ਦਿਖਾਉਂਦਾ ਹੈ, ਸੀਮਤ I/O ਵਾਲੇ ਸਿਸਟਮ ਵਿੱਚ, I/O ਦੀ ਸੰਖਿਆ ਦਿਖਾਉਂਦਾ ਹੈ)। ਨੋਟ ਕਰੋ ਕਿ ਬਹੁਤ ਸਾਰੇ ਸਿਸਟਮ 100% ਵਰਤੋਂ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਖਰਾਬ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਵਰਤੋਂ ਦਾ ਟੀਚਾ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ।

ਗੁੰਝਲਦਾਰ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ, ਸੰਤ੍ਰਿਪਤਾ ਨੂੰ ਉੱਚ-ਪੱਧਰੀ ਲੋਡ ਮਾਪ ਦੁਆਰਾ ਪੂਰਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਕੀ ਤੁਹਾਡੀ ਸੇਵਾ ਡਬਲ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਹੈਂਡਲ ਕਰ ਸਕਦੀ ਹੈ, ਸਿਰਫ 10% ਜ਼ਿਆਦਾ ਟ੍ਰੈਫਿਕ ਨੂੰ ਹੈਂਡਲ ਕਰ ਸਕਦੀ ਹੈ, ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਘੱਟ ਟ੍ਰੈਫਿਕ ਨੂੰ ਵਰਤ ਸਕਦੀ ਹੈ? ਸਧਾਰਨ ਸੇਵਾਵਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਮਾਪਦੰਡ ਨਹੀਂ ਹਨ ਜੋ ਬੇਨਤੀ ਦੀ ਗੁੰਝਲਤਾ ਨੂੰ ਬਦਲਦੇ ਹਨ (ਜਿਵੇਂ ਕਿ "ਮੈਨੂੰ ਕੁਝ ਨਾ ਦਿਓ" ਜਾਂ "ਮੈਨੂੰ ਇੱਕ ਵਿਲੱਖਣ ਇੱਕ ਮੋਨੋਟੋਨਿਕ ਪੂਰਨ ਅੰਕ ਦੀ ਲੋੜ ਹੈ") ਜੋ ਸ਼ਾਇਦ ਹੀ ਸੰਰਚਨਾ ਨੂੰ ਬਦਲਦੀਆਂ ਹਨ, ਇੱਕ ਸਥਿਰ ਲੋਡ ਟੈਸਟ ਮੁੱਲ ਕਾਫ਼ੀ ਹੋ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਪਿਛਲੇ ਪੈਰੇ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਗਈ ਹੈ, ਜ਼ਿਆਦਾਤਰ ਸੇਵਾਵਾਂ ਨੂੰ ਅਸਿੱਧੇ ਸਿਗਨਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜਿਵੇਂ ਕਿ CPU ਉਪਯੋਗਤਾ ਜਾਂ ਨੈੱਟਵਰਕ ਬੈਂਡਵਿਡਥ ਜਿਸਦਾ ਉਪਰਲਾ ਸੀਮਾ ਹੈ। ਵਧ ਰਹੀ ਲੇਟੈਂਸੀ ਅਕਸਰ ਸੰਤ੍ਰਿਪਤਾ ਦਾ ਮੁੱਖ ਸੂਚਕ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ ਵਿੰਡੋ ਵਿੱਚ 99ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ ਜਵਾਬ ਸਮੇਂ ਨੂੰ ਮਾਪਣਾ (ਉਦਾਹਰਨ ਲਈ ਇੱਕ ਮਿੰਟ) ਇੱਕ ਬਹੁਤ ਹੀ ਸ਼ੁਰੂਆਤੀ ਸੰਤ੍ਰਿਪਤ ਸੰਕੇਤ ਦੇ ਸਕਦਾ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਸੰਤ੍ਰਿਪਤਾ ਆਉਣ ਵਾਲੀ ਸੰਤ੍ਰਿਪਤਾ ਦੀਆਂ ਭਵਿੱਖਬਾਣੀਆਂ ਨਾਲ ਵੀ ਜੁੜੀ ਹੋਈ ਹੈ, ਜਿਵੇਂ ਕਿ: "ਇੰਝ ਲੱਗਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਤੁਹਾਡੀ ਹਾਰਡ ਡਰਾਈਵ ਨੂੰ 4 ਘੰਟਿਆਂ ਵਿੱਚ ਭਰ ਦੇਵੇਗਾ।"

ਜੇ ਤੁਸੀਂ ਸਾਰੇ ਚਾਰ ਸੁਨਹਿਰੀ ਸਿਗਨਲਾਂ ਨੂੰ ਮਾਪਦੇ ਹੋ ਅਤੇ ਜਦੋਂ ਇੱਕ ਮੈਟ੍ਰਿਕਸ (ਜਾਂ, ਸੰਤ੍ਰਿਪਤਾ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਲਗਭਗ ਇੱਕ ਸਮੱਸਿਆ) ਵਿੱਚ ਕੋਈ ਸਮੱਸਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਵਿਅਕਤੀ ਨੂੰ ਸੂਚਿਤ ਕਰਦੇ ਹੋ, ਤੁਹਾਡੀ ਸੇਵਾ ਘੱਟ ਜਾਂ ਘੱਟ ਨਿਗਰਾਨੀ ਦੁਆਰਾ ਕਵਰ ਕੀਤੀ ਜਾਵੇਗੀ।

ਪੂਛ (ਜਾਂ ਯੰਤਰ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ) ਬਾਰੇ ਚਿੰਤਾ

ਜਦੋਂ ਸਕ੍ਰੈਚ ਤੋਂ ਇੱਕ ਨਿਗਰਾਨੀ ਸਿਸਟਮ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਔਸਤ ਦੇ ਅਧਾਰ 'ਤੇ ਇੱਕ ਸਿਸਟਮ ਵਿਕਸਿਤ ਕਰਨ ਲਈ ਲੁਭਾਉਂਦਾ ਹੈ: ਔਸਤ ਲੇਟੈਂਸੀ, ਔਸਤ ਨੋਡ CPU ਉਪਯੋਗਤਾ, ਜਾਂ ਔਸਤ ਡਾਟਾਬੇਸ ਆਕੂਪੈਂਸੀ। ਆਖਰੀ ਦੋ ਉਦਾਹਰਣਾਂ ਦਾ ਖ਼ਤਰਾ ਸਪੱਸ਼ਟ ਹੈ: ਪ੍ਰੋਸੈਸਰਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਦਾ ਨਿਪਟਾਰਾ ਬਹੁਤ ਹੀ ਅਣਹੋਣੀ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹੀ ਦੇਰੀ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ. ਜੇਕਰ ਤੁਸੀਂ ਪ੍ਰਤੀ ਸਕਿੰਟ 100 ਬੇਨਤੀਆਂ 'ਤੇ 1000ms ਦੀ ਔਸਤ ਲੇਟੈਂਸੀ ਵਾਲੀ ਵੈੱਬ ਸੇਵਾ ਚਲਾ ਰਹੇ ਹੋ, ਤਾਂ 1% ਬੇਨਤੀਆਂ 5 ਸਕਿੰਟ ਲੈ ਸਕਦੀਆਂ ਹਨ। ਜੇਕਰ ਉਪਭੋਗਤਾ ਅਜਿਹੀਆਂ ਕਈ ਵੈਬ ਸੇਵਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਸਿੰਗਲ ਬੈਕਐਂਡ ਦਾ 99ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ ਆਸਾਨੀ ਨਾਲ ਇੰਟਰਫੇਸ ਦਾ ਮੱਧਮ ਜਵਾਬ ਸਮਾਂ ਬਣ ਸਕਦਾ ਹੈ।

ਧੀਮੀ ਔਸਤ ਅਤੇ ਬੇਨਤੀਆਂ ਦੀ ਇੱਕ ਬਹੁਤ ਹੀ ਹੌਲੀ ਪੂਛ ਵਿੱਚ ਫਰਕ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਸਰਲ ਤਰੀਕਾ ਹੈ ਅਸਲ ਦੇਰੀ ਦੀ ਬਜਾਏ ਅੰਕੜਿਆਂ ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਬੇਨਤੀਆਂ ਦੇ ਮਾਪਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ (ਹਿਸਟੋਗ੍ਰਾਮ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ ਇੱਕ ਢੁਕਵਾਂ ਸਾਧਨ ਹਨ): ਸੇਵਾ ਦੁਆਰਾ ਕਿੰਨੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਸੇਵਾ ਕੀਤੀ ਗਈ ਸੀ 0 ms ਅਤੇ 10ms ਦੇ ਵਿਚਕਾਰ, 10ms ਅਤੇ 30ms ਦੇ ਵਿਚਕਾਰ, 30ms ਅਤੇ 100ms ਦੇ ਵਿਚਕਾਰ, 100ms ਅਤੇ 300ms ਦੇ ਵਿਚਕਾਰ, ਆਦਿ। ਹਿਸਟੋਗ੍ਰਾਮ ਸੀਮਾਵਾਂ ਨੂੰ ਲਗਭਗ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਾਉਣਾ (ਲਗਭਗ 3 ਦੇ ਕਾਰਕ ਦੁਆਰਾ) ਅਕਸਰ ਬੇਨਤੀਆਂ ਦੀ ਵੰਡ ਦੀ ਕਲਪਨਾ ਕਰਨ ਦਾ ਇੱਕ ਆਸਾਨ ਤਰੀਕਾ ਹੁੰਦਾ ਹੈ।

ਮਾਪ ਲਈ ਸਹੀ ਗ੍ਰੈਨਿਊਲੈਰਿਟੀ ਦੀ ਚੋਣ ਕਰਨਾ

ਸਿਸਟਮ ਦੇ ਵੱਖ-ਵੱਖ ਤੱਤਾਂ ਨੂੰ ਵੇਰਵੇ ਦੇ ਵੱਖ-ਵੱਖ ਪੱਧਰਾਂ ਨਾਲ ਮਾਪਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਣ ਲਈ:

• ਸਮੇਂ ਦੀ ਇੱਕ ਮਿਆਦ ਵਿੱਚ CPU ਵਰਤੋਂ ਉਪਯੋਗਤਾ ਨੂੰ ਦੇਖਣਾ ਲੰਬੇ ਸਪਾਈਕਸ ਨਹੀਂ ਦਿਖਾਏਗਾ ਜਿਸਦੇ ਨਤੀਜੇ ਵਜੋਂ ਉੱਚ ਲੇਟੈਂਸੀ ਹੁੰਦੀ ਹੈ।
• ਦੂਜੇ ਪਾਸੇ, ਪ੍ਰਤੀ ਸਾਲ 9 ਘੰਟੇ ਤੋਂ ਵੱਧ ਡਾਊਨਟਾਈਮ (99,9% ਸਲਾਨਾ ਅਪਟਾਈਮ) ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣ ਵਾਲੀ ਇੱਕ ਵੈਬ ਸੇਵਾ ਲਈ, ਇੱਕ HTTP 200 ਜਵਾਬ ਲਈ ਪ੍ਰਤੀ ਮਿੰਟ ਇੱਕ ਜਾਂ ਦੋ ਵਾਰ ਤੋਂ ਵੱਧ ਦੀ ਜਾਂਚ ਕਰਨਾ ਸੰਭਵ ਤੌਰ 'ਤੇ ਬੇਲੋੜਾ ਅਕਸਰ ਹੁੰਦਾ ਹੈ।
• ਇਸੇ ਤਰ੍ਹਾਂ, ਹਰ 99,9-1 ਮਿੰਟਾਂ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ 2% ਉਪਲਬਧਤਾ ਲਈ ਹਾਰਡ ਡਰਾਈਵ 'ਤੇ ਖਾਲੀ ਥਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਸ਼ਾਇਦ ਬੇਲੋੜਾ ਹੈ।

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

1. ਹਰ ਸਕਿੰਟ CPU ਵਰਤੋਂ ਨੂੰ ਮਾਪੋ।
2. ਵੇਰਵੇ ਨੂੰ 5% ਤੱਕ ਘਟਾਓ।
3. ਹਰ ਮਿੰਟ ਵਿੱਚ ਕੁੱਲ ਮੈਟ੍ਰਿਕਸ।

ਇਹ ਰਣਨੀਤੀ ਤੁਹਾਨੂੰ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਸਟੋਰੇਜ ਲਈ ਉੱਚ ਓਵਰਹੈੱਡਾਂ ਦਾ ਅਨੁਭਵ ਕੀਤੇ ਬਿਨਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਦਾਣੇਦਾਰ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗੀ।

ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸਧਾਰਨ, ਪਰ ਸੌਖਾ ਨਹੀਂ

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

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

ਸੰਭਾਵੀ ਪੇਚੀਦਗੀਆਂ ਦੇ ਸਰੋਤ ਕਦੇ ਖਤਮ ਨਹੀਂ ਹੁੰਦੇ। ਸਾਰੇ ਸਾਫਟਵੇਅਰ ਸਿਸਟਮਾਂ ਵਾਂਗ, ਨਿਗਰਾਨੀ ਇੰਨੀ ਗੁੰਝਲਦਾਰ ਬਣ ਸਕਦੀ ਹੈ ਕਿ ਇਹ ਨਾਜ਼ੁਕ, ਬਦਲਣਾ ਅਤੇ ਸੰਭਾਲਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।

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

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

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

ਸਿਧਾਂਤਾਂ ਨੂੰ ਆਪਸ ਵਿੱਚ ਜੋੜਨਾ

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

ਨਿਗਰਾਨੀ ਅਤੇ ਚੇਤਾਵਨੀ ਨਿਯਮ ਬਣਾਉਂਦੇ ਸਮੇਂ, ਹੇਠਾਂ ਦਿੱਤੇ ਸਵਾਲ ਪੁੱਛਣ ਨਾਲ ਤੁਹਾਨੂੰ ਗਲਤ ਸਕਾਰਾਤਮਕ ਅਤੇ ਬੇਲੋੜੀਆਂ ਚੇਤਾਵਨੀਆਂ ਤੋਂ ਬਚਣ ਵਿੱਚ ਮਦਦ ਮਿਲ ਸਕਦੀ ਹੈ:

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

ਇਹ ਸਵਾਲ ਚੇਤਾਵਨੀਆਂ ਅਤੇ ਚੇਤਾਵਨੀ ਪ੍ਰਣਾਲੀਆਂ 'ਤੇ ਬੁਨਿਆਦੀ ਫ਼ਲਸਫ਼ੇ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ:

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

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

ਲੰਬੀ ਮਿਆਦ ਦੀ ਨਿਗਰਾਨੀ

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

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

ਬਿਗਟੇਬਲ SRE: ਓਵਰ-ਅਲਰਟ ਬਾਰੇ ਇੱਕ ਕਹਾਣੀ

Google ਦਾ ਅੰਦਰੂਨੀ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸੇਵਾ ਪੱਧਰ (SLO) ਦੇ ਰੂਪ ਵਿੱਚ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ। ਕਈ ਸਾਲ ਪਹਿਲਾਂ, ਬਿਗਟੇਬਲ ਸੇਵਾ ਦਾ SLO ਇੱਕ ਚੱਲ ਰਹੇ ਕਲਾਇੰਟ ਦੀ ਨਕਲ ਕਰਨ ਵਾਲੇ ਇੱਕ ਸਿੰਥੈਟਿਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੀ ਔਸਤ ਕਾਰਗੁਜ਼ਾਰੀ 'ਤੇ ਅਧਾਰਤ ਸੀ। ਬਿਗਟੇਬਲ ਅਤੇ ਸਟੋਰੇਜ ਸਟੈਕ ਦੇ ਹੇਠਲੇ ਪੱਧਰਾਂ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਦੇ ਕਾਰਨ, ਔਸਤ ਪ੍ਰਦਰਸ਼ਨ ਇੱਕ "ਵੱਡੀ" ਪੂਛ ਦੁਆਰਾ ਚਲਾਇਆ ਗਿਆ ਸੀ: ਸਭ ਤੋਂ ਭੈੜੇ 5% ਸਵਾਲ ਅਕਸਰ ਬਾਕੀ ਦੇ ਮੁਕਾਬਲੇ ਕਾਫ਼ੀ ਹੌਲੀ ਸਨ।

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

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

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

ਜੀਮੇਲ: ਅਨੁਮਾਨਯੋਗ, ਐਲਗੋਰਿਦਮਿਕ ਮਨੁੱਖੀ ਜਵਾਬ

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

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

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

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

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

ਲੰਮਾ ਸਮਾਂ

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

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

ਸਿੱਟਾ

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

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

ਅੰਤ ਤੱਕ ਅਨੁਵਾਦ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਧੰਨਵਾਦ। ਨਿਗਰਾਨੀ ਬਾਰੇ ਮੇਰੇ ਟੈਲੀਗ੍ਰਾਮ ਚੈਨਲ ਦੀ ਗਾਹਕੀ ਲਓ @monitorim_it и ਮੀਡੀਅਮ 'ਤੇ ਬਲੌਗ.

ਸਰੋਤ: www.habr.com