ਪੇਜਰਡਿਊਟੀ, ਜਾਂ ਓਪਰੇਸ਼ਨ ਵਿਭਾਗ ਰਾਤ ਨੂੰ ਕਿਉਂ ਨਹੀਂ ਸੌਂ ਸਕਦਾ

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

ਜਿਸ ਹੱਲ 'ਤੇ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ ਉਹ ਸਭ ਤੋਂ ਅਚਾਨਕ ਨਹੀਂ ਹੈ, ਪਰ ਖੋਜ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਇੱਕ ਪੂਰਾ ਲੇਖ ਵਾਪਸ ਨਹੀਂ ਕਰਦੀ.

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

PagerDuty ਕੀ ਹੈ?

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

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

ਡਿਊਟੀ ਅਫਸਰ ਕੌਣ ਹੈ?

ਪੀਡੀ ਨੂੰ ਸਥਾਪਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਇਹ ਸ਼ਾਇਦ ਪਹਿਲਾ ਸਥਾਨ ਹੈ।

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

ਜੇ ਦੂਜਾ ਡਿਊਟੀ ਅਫਸਰ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ, ਤਾਂ ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ ਮੁੱਖ ਡਿਊਟੀ ਅਫਸਰ ਨੂੰ.

ਇਸ ਤਰ੍ਹਾਂ, ਕੋਈ ਵੀ ਆਉਣ ਵਾਲੀ ਉੱਚ ਤਰਜੀਹ ਚੇਤਾਵਨੀ ਅਣਪ੍ਰੋਸੈਸਡ ਨਹੀਂ ਰਹਿ ਸਕਦੀ। 

ਹੁਣ ਦੇਖਦੇ ਹਾਂ ਕਿ ਘਟਨਾਵਾਂ ਕਿੱਥੋਂ ਆ ਸਕਦੀਆਂ ਹਨ।

ਅਸੀਂ ਕਿਹੜੇ ਏਕੀਕਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ?

PD ਨੂੰ ਵੱਖ-ਵੱਖ ਸੇਵਾਵਾਂ ਤੋਂ ਕਈ ਵੱਖ-ਵੱਖ ਘਟਨਾਵਾਂ ਮਿਲਦੀਆਂ ਹਨ। ਸਾਡੇ ਕੋਲ ਵਰਤਮਾਨ ਵਿੱਚ ਲਗਭਗ 25 ਅਜਿਹੀਆਂ ਸੇਵਾਵਾਂ ਹਨ, ਅਤੇ ਉਹਨਾਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰਨ ਲਈ ਅਸੀਂ ਕੁਝ ਤਿਆਰ-ਕੀਤੀ ਏਕੀਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

• Prometheus

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

• ਈਮੇਲ

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

• ਢਿੱਲ

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

ਅਸੀਂ ਕਰਦੇ ਹਾਂ:

ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ:

• API

HTTP ਏਕੀਕਰਣ। ਵਾਸਤਵ ਵਿੱਚ, ਇੱਥੇ ਕੁਝ ਵੀ ਖਾਸ ਤੌਰ 'ਤੇ ਦਿਲਚਸਪ ਨਹੀਂ ਹੈ, ਸਿਰਫ਼ JSON ਫਾਰਮੈਟ ਵਿੱਚ ਇੱਕ ਸਰੀਰ ਦੇ ਨਾਲ ਇੱਕ ਪੋਸਟ ਬੇਨਤੀ. ਉਦਾਹਰਨ ਲਈ, ਕੁਝ ਦਿਲਚਸਪ: ਅਸੀਂ ਇਸਨੂੰ ਵਰਤਦੇ ਹੋਏ ਬਾਹਰੀ ਨਿਗਰਾਨੀ ਲਈ ਵਰਤਦੇ ਹਾਂ https://www.statuscake.com/. ਇਹ ਸੇਵਾ ਦੁਨੀਆ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਤੋਂ ਸਾਡੀਆਂ ਸਾਈਟਾਂ ਦੀ ਪਹੁੰਚਯੋਗਤਾ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਅਸਵੀਕਾਰਨਯੋਗ ਜਵਾਬ ਕੋਡ (ਉਦਾਹਰਨ ਲਈ, 502) ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ, ਇੱਕ ਘਟਨਾ ਬਣ ਜਾਂਦੀ ਹੈ ਅਤੇ ਫਿਰ ਸਭ ਕੁਝ ਉੱਪਰ ਦੱਸੇ ਗਏ ਲੜੀ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। StatusCake ਆਪਣੇ ਆਪ ਵਿੱਚ ਅੰਦਰੂਨੀ URL, SSL ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਡੋਮੇਨ ਦੀ ਮਿਆਦ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਰੱਖਦਾ ਹੈ.

• LibreNMS

ਇਹ ਇੱਕ ਹੋਰ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਹੈ, ਤੁਸੀਂ ਉਹਨਾਂ ਦੀ ਵੈਬਸਾਈਟ 'ਤੇ ਇਸ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ https://www.librenms.org/. ਇਸਦੀ ਮਦਦ ਨਾਲ, ਅਸੀਂ ਸਰਵਰਾਂ ਤੋਂ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ਅਤੇ iDRAC ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ।

ਡੈਟਾਡੌਗ, ਕਲਾਉਡਵਾਚ ਵਰਗੇ ਏਕੀਕਰਣ ਵੀ ਸਨ। ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨਾਲ ਕੀ ਹੋਇਆ ਇਸ ਬਾਰੇ ਹੋਰ ਦੇਖ ਸਕਦੇ ਹੋ ਇੱਥੇ ਹੀ.

ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ

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

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

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

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

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

ਇੱਥੇ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਸਰੋਤ ਵੇਖੋ.

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

ਸਰੋਤ: www.habr.com