ਦੋ ਸਾਲ ਪਹਿਲਾਂ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਪੋਸਟ ਕੀਤੀ ਸੀ ਇੱਕ ਵੈਬਸਾਈਟ ਲਈ ਸਧਾਰਨ ਫੇਲਓਵਰ ਬਾਰੇ okerr. ਹੁਣ ਪ੍ਰੋਜੈਕਟ ਦਾ ਕੁਝ ਵਿਕਾਸ ਹੈ, ਅਤੇ ਮੈਂ ਪ੍ਰਕਾਸ਼ਤ ਵੀ ਕੀਤਾ ਹੈ okerr ਸਰਵਰ ਸਾਈਡ ਸਰੋਤ ਕੋਡ ਅਧੀਨ ਖੁੱਲ੍ਹਾ ਲਾਇਸੰਸ, ਇਸ ਲਈ ਮੈਂ ਹਾਬਰ 'ਤੇ ਇਹ ਛੋਟੀ ਸਮੀਖਿਆ ਲਿਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

[ ਪੂਰੇ ਆਕਾਰ ]

ਜਿਸ ਨੂੰ ਇਹ ਦਿਲਚਸਪੀ ਹੋ ਸਕਦੀ ਹੈ

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

ਓਕਰ ਅਸਾਧਾਰਨ ਕਿਉਂ ਹੈ

ਅੱਗੇ ਮੈਂ ਓਕੇਰਾ ਦੀਆਂ ਦਿਲਚਸਪ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਿਖਾਵਾਂਗਾ ਜੋ ਇਸਨੂੰ ਕੁਝ ਹੋਰ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀਆਂ ਤੋਂ ਵੱਖ ਕਰਦੀਆਂ ਹਨ।

Okerr ਇੱਕ ਹਾਈਬ੍ਰਿਡ ਨਿਗਰਾਨੀ ਹੈ

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

okerr ਸਿਰਫ਼ ਸਾਫਟਵੇਅਰ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ਸੇਵਾ ਵੀ ਹੈ

ਕਿਸੇ ਵੀ ਨਿਗਰਾਨੀ ਦਾ ਸਰਵਰ ਹਿੱਸਾ ਵੱਡਾ ਅਤੇ ਗੁੰਝਲਦਾਰ ਹੁੰਦਾ ਹੈ, ਇਸਨੂੰ ਸਥਾਪਤ ਕਰਨਾ ਅਤੇ ਕੌਂਫਿਗਰ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। okerr ਦੇ ਨਾਲ ਤੁਸੀਂ ਆਪਣੇ ਖੁਦ ਦੇ ਨਿਗਰਾਨੀ ਸਰਵਰ ਨੂੰ ਸਥਾਪਿਤ ਕਰ ਸਕਦੇ ਹੋ (ਇਹ ਮੁਫਤ ਅਤੇ ਓਪਨਸੋਰਸ ਹੈ), ਜਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਕਲਾਇੰਟ ਦੇ ਹਿੱਸੇ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਸਾਡੇ ਸਰਵਰ ਦੀ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਵੀ ਮੁਫ਼ਤ.

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

ਬੇਸ਼ੱਕ, ਇੱਕ ਖਤਰਾ ਹੈ ਕਿ ਓਕਰ ਸਰਵਰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਉਪਲਬਧ ਨਹੀਂ ਹੋਵੇਗਾ, ਇਹ ਸੱਚ ਹੈ (ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ, 90% ਭਰੋਸੇਯੋਗਤਾ ਹਮੇਸ਼ਾਂ ਸਧਾਰਨ ਅਤੇ "ਮੁਫ਼ਤ" ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, 99% ਘੱਟੋ ਘੱਟ ਕੋਸ਼ਿਸ਼ਾਂ ਨਾਲ, ਅਤੇ ਹਰੇਕ ਅਗਲੇ ਨੌਂ ਹਨ। ਤੇਜ਼ੀ ਨਾਲ ਵਧੇਰੇ ਮੁਸ਼ਕਲ). ਪਰ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਅਜਿਹਾ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੈ, ਅਤੇ ਦੂਜਾ, ਸਮੱਸਿਆ ਤਾਂ ਹੀ ਅਣਦੇਖੀ ਹੋ ਸਕਦੀ ਹੈ ਜੇਕਰ ਇਹ ਸਾਡੇ ਸਰਵਰਾਂ 'ਤੇ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ। ਜੇਕਰ ਸਾਡੇ ਕੋਲ 99.9% ਭਰੋਸੇਯੋਗਤਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ 99.9% (ਬਹੁਤ ਜ਼ਿਆਦਾ ਨੰਬਰ ਨਹੀਂ) ਹਨ, ਤਾਂ ਇੱਕ ਅਣਪਛਾਤੀ ਅਸਫਲਤਾ ਦੀ ਸੰਭਾਵਨਾ 0.1% = 0.1% ਦਾ 0.0001% ਹੈ। ਬਿਨਾਂ ਕਿਸੇ ਕੋਸ਼ਿਸ਼ ਦੇ ਅਤੇ ਬਿਨਾਂ ਲਾਗਤ ਦੇ ਆਪਣੀ ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ ਤਿੰਨ ਨੌਂ ਜੋੜਨਾ ਬਹੁਤ ਵਧੀਆ ਹੈ!

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

Okerr ਸੂਚਕਾਂ ਬਾਰੇ ਹੈ

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

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

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

ਬੇਸ਼ੱਕ, ਸਿਰਫ਼ "ਜਾਣਕਾਰੀ" ਸੂਚਕਾਂ ਨੂੰ ਰੱਖਣਾ ਸੰਭਵ ਹੈ (ਨਿਗਰਾਨੀ ਤੋਂ ਨੈੱਟਵਰਕ ਦੀ ਤਸਵੀਰ ਦੇਖਣ ਲਈ), ਪਰ ਸਭ ਕੁਝ ਸਿਰਫ਼, ਆਸਾਨੀ ਨਾਲ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸੂਚਕਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਸਵੈਚਲਿਤ ਨਿਗਰਾਨੀ ਅਤੇ ਚੇਤਾਵਨੀਆਂ ਭੇਜਣ ਲਈ.

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

ਸੁਰੱਖਿਆ ਨੂੰ

ਇਹ ਸ਼ਰਮ ਦੀ ਗੱਲ ਹੋਵੇਗੀ ਜੇਕਰ ਤੁਸੀਂ ਵਧਦੀ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਖ਼ਾਤਰ ਨਿਗਰਾਨੀ ਸਥਾਪਤ ਕਰਦੇ ਹੋ, ਪਰ ਨਤੀਜੇ ਵਜੋਂ, ਤੁਹਾਡੇ ਦੁਆਰਾ ਨੈੱਟਵਰਕ ਉੱਤੇ ਹਮਲਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਵੱਖ-ਵੱਖ ਨਿਗਰਾਨੀ ਸਾਧਨਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਨੈਟਵਰਕ ਕਮਜ਼ੋਰੀਆਂ ਹਨ (ਜ਼ੱਬਿਕਸ, ਨਾਗਜ਼ੀਅਸ).

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

ਪੂਰੀ ਨਿਗਰਾਨੀ ਕਵਰੇਜ

ਹੁਣ ਸਾਡਾ ਨਿਯਮ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਓਕਰ ਤੋਂ ਸਾਰੀਆਂ ਤਕਨੀਕੀ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਸਿੱਖਦੇ ਹਾਂ। ਜੇਕਰ ਅਚਾਨਕ ਨਿਯਮ ਦੀ ਉਲੰਘਣਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਓਕਰ ਨੇ ਇਸਦੀ ਆਉਣ ਵਾਲੀ ਘਟਨਾ ਬਾਰੇ ਚੇਤਾਵਨੀ ਨਹੀਂ ਦਿੱਤੀ ਸੀ (ਜੇਕਰ ਇਹ ਸੰਭਵ ਹੈ) ਜਾਂ ਇਹ ਪਹਿਲਾਂ ਹੀ ਹੋ ਚੁੱਕਾ ਹੈ) - ਅਸੀਂ ਓਕੇਰ ਵਿੱਚ ਚੈੱਕ ਜੋੜਦੇ ਹਾਂ।

ਬਾਹਰੀ ਜਾਂਚਾਂ

ਕਾਫ਼ੀ ਆਮ ਸੈੱਟ:

• ਪਿੰਗ
• http ਸਥਿਤੀ
• SSL ਸਰਟੀਫਿਕੇਟ ਦੀ ਵੈਧਤਾ ਅਤੇ ਤਾਜ਼ਗੀ ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ (ਜੇਕਰ ਇਹ ਮਿਆਦ ਪੁੱਗਣ ਵਾਲੀ ਹੈ ਤਾਂ ਚੇਤਾਵਨੀ ਦੇਵੇਗਾ)
• ਇਸ 'ਤੇ TCP ਪੋਰਟ ਅਤੇ ਬੈਨਰ ਖੋਲ੍ਹੋ
• http grep (ਪੰਨੇ ਵਿੱਚ ਕੁਝ ਟੈਕਸਟ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ)
• ਪੰਨਾ ਤਬਦੀਲੀਆਂ ਨੂੰ ਫੜਨ ਲਈ sha1 ਹੈਸ਼.
• DNS (DNS ਰਿਕਾਰਡ ਦਾ ਇੱਕ ਖਾਸ ਮੁੱਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ)
• WHOIS (ਜੇ ਡੋਮੇਨ ਖਰਾਬ ਹੋਣ ਵਾਲਾ ਹੈ ਤਾਂ ਚੇਤਾਵਨੀ ਦੇਵੇਗਾ)
• ਐਂਟੀਸਪੈਮ ਡੀਐਨਐਸਬੀਐਲ (ਇੱਕ ਵਾਰ ਵਿੱਚ 50+ ਐਂਟੀਸਪੈਮ ਬਲੈਕਲਿਸਟਾਂ ਦੇ ਵਿਰੁੱਧ ਹੋਸਟ ਜਾਂਚ)

ਅੰਦਰੂਨੀ ਜਾਂਚਾਂ

ਨਾਲ ਹੀ, ਇੱਕ ਕਾਫ਼ੀ ਮਿਆਰੀ ਸੈੱਟ (ਪਰ ਆਸਾਨੀ ਨਾਲ ਵਿਸਤਾਰਯੋਗ)।

• df (ਮੁਫ਼ਤ ਡਿਸਕ ਸਪੇਸ)
• ਲੋਡ ਔਸਤ
• opentcp (ਓਪਨ ਟੀਸੀਪੀ ਸੁਣਨ ਵਾਲੇ ਸਾਕਟ - ਸੂਚਿਤ ਕਰੇਗਾ ਕਿ ਕੀ ਕੁਝ ਸ਼ੁਰੂ ਹੋਇਆ ਜਾਂ ਕਰੈਸ਼ ਹੋ ਗਿਆ)
• ਅੱਪਟਾਈਮ - ਸਰਵਰ 'ਤੇ ਸਿਰਫ਼ ਅੱਪਟਾਈਮ। ਸੂਚਿਤ ਕਰੇਗਾ ਜੇ ਇਹ ਬਦਲ ਗਿਆ ਹੈ (ਜਿਵੇਂ ਕਿ ਸਰਵਰ ਓਵਰਲੋਡ ਹੋ ਗਿਆ ਹੈ)
• client_ip
• dirsize - ਅਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਟ੍ਰੈਕ ਕਰਨ ਲਈ ਕਰਦੇ ਹਾਂ ਜਦੋਂ ਸਾਡੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਰੂਟਫਸ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਆਕਾਰ ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਸਖਤ ਪਾਬੰਦੀਆਂ ਨੂੰ ਪੇਸ਼ ਕੀਤੇ ਬਿਨਾਂ, ਅਤੇ ਉਪਭੋਗਤਾ ਹੋਮ ਡਾਇਰੈਕਟਰੀਆਂ ਦਾ ਆਕਾਰ
• ਖਾਲੀ ਅਤੇ ਖਾਲੀ ਨਹੀਂ - ਉਹਨਾਂ ਫਾਈਲਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ ਜੋ ਖਾਲੀ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ (ਜਾਂ ਖਾਲੀ ਨਹੀਂ)। ਉਦਾਹਰਨ ਲਈ, okerr ਸਰਵਰ ਦਾ ਗਲਤੀ ਲੌਗ ਆਪਣੇ ਆਪ ਵਿੱਚ ਖਾਲੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਇਸ ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਵੀ ਹੈ, ਤਾਂ ਮੈਂ ਇੱਕ ਸੂਚਨਾ ਪ੍ਰਾਪਤ ਕਰਾਂਗਾ ਅਤੇ ਇਸਦੀ ਜਾਂਚ ਕਰਾਂਗਾ. ਪਰ ਮੇਲ ਸਰਵਰ 'ਤੇ mail.log ਖਾਲੀ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ (ਰੋਟੇਸ਼ਨ ਤੋਂ ਬਾਅਦ N ਮਿੰਟ)। ਅਤੇ ਕਈ ਵਾਰ ਸਿਸਟਮ ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ ਇਹ ਸਾਡੇ ਲਈ ਖਾਲੀ ਹੁੰਦਾ ਸੀ, ਜਦੋਂ logrotate rsyslog ਨੂੰ ਠੀਕ ਤਰ੍ਹਾਂ ਰੀਸਟਾਰਟ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ।
• linecount - ਫਾਈਲ ਵਿੱਚ ਲਾਈਨਾਂ ਦੀ ਗਿਣਤੀ (ਜਿਵੇਂ ਕਿ wc -l)। ਅਸੀਂ ਇਸਨੂੰ ਖਾਲੀ ਲਈ ਇੱਕ ਨਰਮ ਬਦਲ ਵਜੋਂ ਵਰਤਦੇ ਹਾਂ, ਜਦੋਂ ਗਲਤੀ ਲੌਗ ਅਜੇ ਵੀ ਵਧ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ ਹੌਲੀ ਹੌਲੀ (ਉਦਾਹਰਨ ਲਈ, Googlebot ਕੁਝ ਬੰਦ ਪੰਨਿਆਂ ਨੂੰ ਹਿੱਟ ਕਰਦਾ ਹੈ)। 2 ਮਿੰਟਾਂ ਵਿੱਚ 20 ਲਾਈਨਾਂ ਦੀ ਸੀਮਾ ਹੈ। ਜੇਕਰ ਇਹ ਵੱਧ ਹੈ, ਤਾਂ ਇੱਕ ਚੇਤਾਵਨੀ ਹੋਵੇਗੀ

ਦਿਲਚਸਪ ਅੰਦਰੂਨੀ ਜਾਂਚ

ਜੇ ਤੁਸੀਂ ਇਸ ਬਿੰਦੂ ਤੱਕ "ਤਿਰਛੇ" ਪੜ੍ਹ ਰਹੇ ਹੋ, ਤਾਂ ਹੁਣ ਹੋਰ ਧਿਆਨ ਨਾਲ ਪੜ੍ਹਨਾ ਵਧੇਰੇ ਦਿਲਚਸਪ ਹੋਵੇਗਾ।

ਬੈਕਅੱਪ

ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਬੈਕਅੱਪ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ। ਸਾਡੀਆਂ ਬੈਕਅੱਪ ਫਾਈਲਾਂ ਵਿੱਚ "ServerName-20200530.tar.gz" ਵਰਗੇ ਨਾਮ ਹਨ। okerr ਵਿੱਚ ਹਰੇਕ ਸਰਵਰ ਲਈ, ਸੂਚਕ ServerName-DATE.tar.gz ਬਣਾਇਆ ਗਿਆ ਹੈ (ਅਸਲ ਤਾਰੀਖ ਲਾਈਨ “DATE” ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ)। ਇੱਕ ਤਾਜ਼ਾ ਬੈਕਅੱਪ ਦੀ ਮੌਜੂਦਗੀ ਅਤੇ ਇਸਦੇ ਆਕਾਰ ਦੀ ਵੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਇਹ ਪਿਛਲੇ ਬੈਕਅੱਪ ਦੇ 90% ਤੋਂ ਘੱਟ ਨਹੀਂ ਹੋ ਸਕਦਾ)।

ਜਦੋਂ ਅਸੀਂ ਇਸਨੂੰ ਬਣਾਉਣਾ ਅਤੇ ਇਸ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਪਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਹੈ ਤਾਂ ਇੱਕ ਨਵੇਂ ਬੈਕਅਪ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ? ਕੁਝ ਨਹੀਂ! ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਸੁਵਿਧਾਜਨਕ ਪਹੁੰਚ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ "ਕੁਝ ਨਹੀਂ" ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ:

• "ਕੁਝ ਨਹੀਂ" ਕਰਨਾ ਬਹੁਤ ਤੇਜ਼ ਹੈ, ਇਹ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ
• "ਕੁਝ ਨਹੀਂ" ਕਰਨਾ ਭੁੱਲਣਾ ਔਖਾ ਹੈ
• ਗਲਤੀ ਨਾਲ, "ਕੁਝ ਨਹੀਂ" ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ। ਕੁਝ ਵੀ ਸਭ ਤੋਂ ਭਰੋਸੇਮੰਦ ਤਰੀਕਾ ਨਹੀਂ ਹੈ

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

maxfilesz

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

runstatus/runline

ਸਰਵਰ 'ਤੇ ਦੂਜੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਇਹ ਦੋ ਮਹੱਤਵਪੂਰਨ ਪ੍ਰੌਕਸੀ ਮੋਡੀਊਲ ਹਨ। Runstatus ਪ੍ਰੋਗਰਾਮ ਐਗਜ਼ਿਟ ਕੋਡ ਨੂੰ ਸੂਚਕ ਨੂੰ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, okerr ਇਹ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਮੋਡੀਊਲ (ਲੋੜੀਂਦਾ) ਨਹੀਂ ਹੈ ਕਿ systemd ਸੇਵਾਵਾਂ ਚੱਲ ਰਹੀਆਂ ਹਨ। ਇਹ runstatus ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਹੇਠਾਂ ਦੇਖੋ)। ਰਨਲਾਈਨ - ਸਰਵਰ ਨੂੰ ਉਸ ਲਾਈਨ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਜੋ ਪ੍ਰੋਗਰਾਮ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਣ ਲਈ, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" ਸਾਡੇ ਸਰਵਰ 'ਤੇ ਰਨਲਾਈਨ ਸੰਰਚਨਾ ਵਿੱਚ ਪ੍ਰੋਸੈਸਰ ਦੇ ਤਾਪਮਾਨ ਦੇ ਨਾਲ ਇੱਕ ਸੂਚਕ ਸਰਵਰਨਾਮ:temp ਬਣਾਉਂਦਾ ਹੈ।

sql

MySQL ਨੂੰ ਇੱਕ ਸੰਖਿਆਤਮਕ ਪੁੱਛਗਿੱਛ ਚਲਾਉਂਦੀ ਹੈ ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਸੰਕੇਤਕ ਨੂੰ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਮਾਮਲੇ ਵਿੱਚ, ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, "ਚੁਣੋ 1" - ਇਹ ਜਾਂਚ ਕਰੇਗਾ ਕਿ DBMS ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।

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

ਨੋਟ ਕਰੋ ਕਿ ਇਹ ਮਾਇਨੇ ਨਹੀਂ ਰੱਖਦਾ ਕਿ ਇਹ ਕਿਸ ਅਣਪਛਾਤੇ ਕਾਰਨ ਕਰਕੇ ਹੋਇਆ ਹੈ:

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

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

ਲਾਜ਼ੀਕਲ ਸੂਚਕ

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

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

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

ਨਾਲ ਹੀ, ਕੰਮ ਲਈ ਮਨਜ਼ੂਰ ਸਮਾਂ ਨਿਰਧਾਰਤ ਕਰਨਾ ਸੰਭਵ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਸਵੇਰੇ 3 ਤੋਂ 5 ਵਜੇ ਤੱਕ। ਸਾਨੂੰ ਪਰਵਾਹ ਨਹੀਂ ਹੈ ਕਿ ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਸਰਵਰ ਅਤੇ ਸਾਈਟਾਂ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਪਰ 5:00 ਵਜੇ ਉਨ੍ਹਾਂ ਨੂੰ ਕੰਮ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਜੇ ਉਹ ਕਿਸੇ ਹੋਰ ਸਮੇਂ ਕੰਮ ਨਹੀਂ ਕਰਦੇ - ਚੇਤਾਵਨੀ. ਲਾਜ਼ੀਕਲ ਸੂਚਕ ਤੁਹਾਨੂੰ ਸਰਵਰ ਰਿਡੰਡੈਂਸੀ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਵੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ 5 ਵੈੱਬ ਸਰਵਰ ਹਨ, ਤਾਂ ਪ੍ਰਸ਼ਾਸਕ ਕਿਸੇ ਵੀ ਸਮੇਂ 1-2 ਸਰਵਰਾਂ ਨੂੰ ਬੰਦ ਕਰ ਸਕਦੇ ਹਨ। ਪਰ ਜੇ ਲੜਾਈ ਵਿੱਚ 3 ਵਿੱਚੋਂ 5 ਸਰਵਰ ਘੱਟ ਹਨ, ਤਾਂ ਇੱਕ ਚੇਤਾਵਨੀ ਹੋਵੇਗੀ।

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

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

ਆਪਣੇ ਖੁਦ ਦੇ ਚੈਕ ਸ਼ਾਮਲ ਕਰਨਾ

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

ਮਾਡਿਊਲ ਰਾਹੀਂ ਘੱਟੋ-ਘੱਟ ਉਜਰਤਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਰਨ ਸਟੇਟਸ:

ਸੰਰਚਨਾ ਵਿੱਚ ਇਹ ਲਾਈਨ ਰਨ ਸਟੇਟਸ ਤੁਹਾਨੂੰ ਸੂਚਿਤ ਕਰੇਗਾ ਜੇਕਰ /bin/true ਅਚਾਨਕ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ ਜਾਂ 0 ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਵਾਪਸ ਨਹੀਂ ਕਰਦਾ।

true_OK=/bin/true

ਸਿਰਫ਼ ਇੱਕ ਲਾਈਨ - ਅਤੇ ਇੱਥੇ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਥੋੜੇ ਜਿਹੇ ਹਾਂ ਫੈਲਾਇਆ ਕਾਰਜਕੁਸ਼ਲਤਾ okerr.

ਇੱਥੋਂ ਤੱਕ ਕਿ ਅਜਿਹੀ ਜਾਂਚ ਦਾ ਪਹਿਲਾਂ ਹੀ ਇਸਦਾ ਮੁੱਲ ਹੈ: ਜੇ ਅਚਾਨਕ ਤੁਹਾਡਾ ਸਰਵਰ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਓਕਰ ਸਰਵਰ 'ਤੇ ਸੰਬੰਧਿਤ ਸੂਚਕ ਸਮੇਂ ਸਿਰ ਅਪਡੇਟ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ, ਅਤੇ ਸਮਾਂ ਲੰਘਣ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਚੇਤਾਵਨੀ ਦਿਖਾਈ ਦੇਵੇਗੀ.

ਇਹ ਜਾਂਚ ਸੂਚਿਤ ਕਰੇਗੀ ਕਿ apache2 ਸਰਵਰ ਕਰੈਸ਼ ਹੋ ਗਿਆ ਹੈ (ਠੀਕ ਹੈ, ਤੁਸੀਂ ਕਦੇ ਨਹੀਂ ਜਾਣਦੇ...):

apache_OK="systemctl is-active --quiet apache2"

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

ਵਧੇਰੇ ਮੁਸ਼ਕਲ - ਤੁਸੀਂ okerrmod ਲਈ ਆਪਣਾ ਖੁਦ ਦਾ ਮੋਡੀਊਲ (ਕਿਸੇ ਵੀ ਭਾਸ਼ਾ ਵਿੱਚ) ਲਿਖ ਸਕਦੇ ਹੋ। ਸਧਾਰਨ ਮਾਮਲੇ ਵਿੱਚ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ:

#!/usr/bin/python3

print("STATUS: OK")

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

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32

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

ਤਾਰ

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

ਸਥਿਤੀ ਪੰਨੇ

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

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

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

ਇੱਥੇ 10 ਹੋਰ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਜੋ ਤੁਹਾਨੂੰ ਸਥਿਤੀ ਪੰਨੇ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ. ਇੱਥੇ ਉਦਾਹਰਨਾਂ ਹਨ ਕਿ ਇਹ ਪ੍ਰੋਜੈਕਟ ਪੰਨੇ ਕਿਸ ਤਰ੍ਹਾਂ ਦੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ ਪਾਈਥਨ и ਡ੍ਰੌਪਬਾਕਸ. okerr ਸਥਿਤੀ ਪੰਨਾ.

ਫੇਲਓਵਰ

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

ਘੱਟ ਸਿਸਟਮ ਲੋੜਾਂ

okerr ਸਰਵਰਾਂ ਲਈ, ਅਸੀਂ 2Gb ਤੋਂ RAM ਵਾਲੀਆਂ ਮਸ਼ੀਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਨੈੱਟਵਰਕ ਸੈਂਸਰਾਂ ਲਈ, ਇੱਥੋਂ ਤੱਕ ਕਿ 512Mb ਵੀ ਕਾਫ਼ੀ ਹੈ। ਗਾਹਕ ਦਾ ਹਿੱਸਾ ਆਮ ਤੌਰ 'ਤੇ ਲਗਭਗ ਜ਼ੀਰੋ ਹੁੰਦਾ ਹੈ। (ਪਲਾਸਟਿਕ ਬੈਗ okerrupdate ਵਜ਼ਨ 26 Kb, ਪਰ Python3 ਅਤੇ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਲੋੜ ਹੈ)। ਕਲਾਇੰਟ ਇੱਕ ਕ੍ਰੋਨ ਸਕ੍ਰਿਪਟ ਤੋਂ ਚੱਲਦਾ ਹੈ, ਇਸਲਈ ਇਸ ਵਿੱਚ ਜ਼ੀਰੋ ਸਥਾਈ ਮੈਮੋਰੀ ਖਪਤ ਹੈ। ਸਾਡੇ ਦੁਆਰਾ ਨਿਗਰਾਨੀ ਕੀਤੀਆਂ ਮਸ਼ੀਨਾਂ ਵਿੱਚੋਂ, ਸਾਡੇ ਕੋਲ ਸੈਂਸਰ (512Mb RAM ਦੇ ਨਾਲ ਸੁਪਰ-ਸਸਤੇ VPS) ਅਤੇ ਇੱਕ ਰਸਬੇਰੀ Pi ਹੈ। ਇਹ ਗਾਹਕ ਦੇ ਹਿੱਸੇ ਤੋਂ ਬਿਨਾਂ ਵੀ ਸੰਭਵ ਹੈ curl ਰਾਹੀਂ ਅੱਪਡੇਟ ਭੇਜੋ! (ਨੀਚੇ ਦੇਖੋ)

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

API ਅਤੇ ਮਲਕੀਅਤ ਵਾਲੇ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਏਕੀਕਰਣ

ਸਧਾਰਨ ਅਤੇ ਖੁੱਲ੍ਹੀ ਆਰਕੀਟੈਕਚਰ. okerr ਇੱਕ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਹੈ API, ਜਿਸ ਨਾਲ ਕੰਮ ਕਰਨਾ ਆਸਾਨ ਹੈ। 1000 ਸੂਚਕ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ? 3-4 ਲਾਈਨਾਂ ਦੀ ਇੱਕ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟ ਅਜਿਹਾ ਕਰੇਗੀ। 1000 ਸੂਚਕਾਂ ਨੂੰ ਮੁੜ ਸੰਰਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ? ਇਹ ਵੀ ਬਹੁਤ ਆਸਾਨ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਰੂਸੀ ਸੈਂਸਰ ਤੋਂ ਸਾਡੇ ਸਾਰੇ HTTPS ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਦੋ ਵਾਰ ਜਾਂਚ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ:

#!/bin/sh

for indicator in `okerrclient --api-filter sslcert`
do
    echo set location for $indicator
    okerrclient --api-set location=ru retest=1 --name $indicator
done

ਤੁਸੀਂ ਸਾਡੇ ਕਲਾਇੰਟ ਮੋਡੀਊਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੂਚਕ ਨੂੰ ਅੱਪਡੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਭਾਵੇਂ ਇਸ ਤੋਂ ਬਿਨਾਂ, ਸਿਰਫ਼ curl ਰਾਹੀਂ।

# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK

# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/

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

ਇੱਥੇ ਸਾਡੇ ਟੈਲੀਗ੍ਰਾਮ ਬੋਟ ਵਿੱਚ ਕੋਡ (ਸਰਲੀਕ੍ਰਿਤ) ਹੈ:

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

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

ਓਕਰ ਸਾਡੀ ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ ਹੈ

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

ਅਸੀਂ "ਕੇਰਾ ਤੋਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਸਿੱਖੋ" ਦੇ ਸਿਧਾਂਤ ਅਨੁਸਾਰ ਰਹਿਣ ਵਿਚ ਕਾਮਯਾਬ ਰਹੇ। ਜੇਕਰ ਅਚਾਨਕ ਕੋਈ ਸਮੱਸਿਆ ਆ ਜਾਂਦੀ ਹੈ ਜਿਸ ਬਾਰੇ ਅਸੀਂ ਓਕਰ ਤੋਂ ਨਹੀਂ ਸਿੱਖਿਆ, ਤਾਂ ਅਸੀਂ ਓਕਰ ਵਿੱਚ ਇੱਕ ਚੈੱਕ ਜੋੜਦੇ ਹਾਂ। (ਇਸ ਕੇਸ ਵਿੱਚ, "ਅਸੀਂ" ਦੁਆਰਾ ਮੇਰਾ ਮਤਲਬ ਸਿਸਟਮ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਵਜੋਂ ਹੈ, ਨਾ ਕਿ ਸਹਿ-ਵਿਕਾਸਕਰਤਾਵਾਂ)। ਪਹਿਲਾਂ ਤਾਂ ਇਹ ਆਮ ਗੱਲ ਸੀ ਪਰ ਹੁਣ ਇਹ ਬਹੁਤ ਘੱਟ ਹੋ ਗਈ ਹੈ।

ਨਿਗਰਾਨੀ

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

SSL ਸਰਟੀਫਿਕੇਟ। ਲਾਂਚ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਆਓ ਐਨਕ੍ਰਿਪਟ ਕਰੋ ਸਾਡੇ ਗਾਹਕ ਨੇ ਆਪਣੇ ਗਾਹਕਾਂ ਨੂੰ ਮੁਫਤ SSL ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਦਾਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ (ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਜ਼ਾਰ)। ਅਤੇ ਇਹ ਪ੍ਰਸ਼ਾਸਨ ਲਈ ਸਿਰਫ ਨਰਕ ਬਣ ਗਿਆ! ਤੱਥ ਇਹ ਹੈ ਕਿ ਸਾਈਟਾਂ "ਲਾਈਵ" ਹਨ, ਗਾਹਕ ਸਮੇਂ-ਸਮੇਂ ਤੇ ਉਹਨਾਂ ਨੂੰ ਕੁਝ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹਨ, ਪ੍ਰੋਗਰਾਮਰ ਇਹ ਕਰਦੇ ਹਨ. ਉਹ ਸਾਈਟ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਕਿਸੇ ਹੋਰ DocumentRooਟ 'ਤੇ ਟ੍ਰਾਂਸਫਰ ਕਰ ਸਕਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ. ਜਾਂ ਵਰਚੁਅਲਹੋਸਟ ਸੰਰਚਨਾ ਵਿੱਚ ਇੱਕ ਬਿਨਾਂ ਸ਼ਰਤ ਰੀਰਾਈਟ ਸ਼ਾਮਲ ਕਰੋ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਇਸ ਤੋਂ ਬਾਅਦ, ਸਰਟੀਫਿਕੇਟਾਂ ਦਾ ਆਟੋਮੈਟਿਕ ਨਵੀਨੀਕਰਨ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਹੁਣ ਸਾਡੇ ਕੋਲ ਸਾਰੇ SSL ਹੋਸਟਾਂ ਨੂੰ ਪੈਕੇਜ ਤੋਂ ਸਾਡੀਆਂ ਕਿਸੇ ਹੋਰ ਉਪਯੋਗੀ ਉਪਯੋਗਤਾਵਾਂ ਦੁਆਰਾ ਆਪਣੇ ਆਪ ਹੀ okerr ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ। a2conf. ਚਲੋ ਹੁਣੇ ਲਾਂਚ ਕਰੀਏ a2okerr.py — ਅਤੇ ਜੇਕਰ ਸਰਵਰ 'ਤੇ ਕਈ ਨਵੀਆਂ ਸਾਈਟਾਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ, ਤਾਂ ਉਹ ਆਪਣੇ ਆਪ ਹੀ okerr ਵਿੱਚ ਦਿਖਾਈ ਦੇਣਗੀਆਂ। ਜੇਕਰ ਅਚਾਨਕ ਕਿਸੇ ਕਾਰਨ ਸਰਟੀਫਿਕੇਟ ਰੀਨਿਊ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਰਟੀਫਿਕੇਟ ਦੀ ਮਿਆਦ ਖਤਮ ਹੋਣ ਤੋਂ ਤਿੰਨ ਹਫਤੇ ਪਹਿਲਾਂ, ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ, ਅਤੇ ਅਸੀਂ ਇਹ ਪਤਾ ਲਗਾਵਾਂਗੇ ਕਿ ਇਹ ਅਪਡੇਟ ਕਿਉਂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ, ਅਜਿਹਾ ਕੁੱਤਾ। a2certbot.py ਉਸੇ ਪੈਕੇਜ ਤੋਂ - ਇਹ ਇਸਦੇ ਨਾਲ ਬਹੁਤ ਮਦਦ ਕਰਦਾ ਹੈ (ਇਹ ਤੁਰੰਤ ਸਭ ਤੋਂ ਵੱਧ ਸੰਭਾਵਿਤ ਸਮੱਸਿਆਵਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ - ਅਤੇ ਲਿਖਦਾ ਹੈ ਕਿ ਕੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਂਚਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਜਿੱਥੇ ਸਭ ਤੋਂ ਵੱਧ ਸਮੱਸਿਆ ਹੈ)।

ਅਸੀਂ ਸਾਡੇ ਸਾਰੇ ਡੋਮੇਨਾਂ ਦੀ ਮਿਆਦ ਪੁੱਗਣ ਦੀ ਮਿਤੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ। ਅਤੇ ਸਾਡੇ ਸਾਰੇ ਮੇਲ ਸਰਵਰ ਜੋ ਮੇਲ ਭੇਜਦੇ ਹਨ, 50+ ਵੱਖ-ਵੱਖ ਬਲੈਕਲਿਸਟਾਂ ਦੇ ਵਿਰੁੱਧ ਵੀ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। (ਅਤੇ ਕਦੇ-ਕਦੇ ਉਹ ਉਹਨਾਂ ਵਿਚ ਫਸ ਜਾਂਦੇ ਹਨ). ਤਰੀਕੇ ਨਾਲ, ਕੀ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਗੂਗਲ ਮੇਲ ਸਰਵਰ ਵੀ ਬਲੈਕਲਿਸਟ ਕੀਤੇ ਗਏ ਹਨ? ਸਿਰਫ਼ ਸਵੈ-ਜਾਂਚ ਲਈ, ਅਸੀਂ ਨਿਗਰਾਨੀ ਕੀਤੇ ਸਰਵਰਾਂ ਵਿੱਚ mail-wr1-f54.google.com ਨੂੰ ਜੋੜਿਆ ਹੈ, ਅਤੇ ਇਹ ਅਜੇ ਵੀ SORBS ਬਲੈਕਲਿਸਟ ਵਿੱਚ ਹੈ! (ਇਹ "ਐਂਟੀ-ਸਪੈਮਰ" ਦੇ ਮੁੱਲ ਬਾਰੇ ਹੈ)

ਬੈਕਅੱਪ - ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਉੱਪਰ ਲਿਖਿਆ ਹੈ ਕਿ ਓਕੇਰ ਨਾਲ ਉਹਨਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਕਿੰਨਾ ਆਸਾਨ ਹੈ. ਪਰ ਅਸੀਂ ਆਪਣੇ ਸਰਵਰ 'ਤੇ ਨਵੀਨਤਮ ਬੈਕਅਪ ਅਤੇ (ਇੱਕ ਵੱਖਰੀ ਉਪਯੋਗਤਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਜੋ okerr ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ) ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ ਜੋ ਅਸੀਂ ਐਮਾਜ਼ਾਨ ਗਲੇਸ਼ੀਅਰ 'ਤੇ ਅਪਲੋਡ ਕਰਦੇ ਹਾਂ। ਅਤੇ, ਹਾਂ, ਸਮੱਸਿਆਵਾਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਹੁੰਦੀਆਂ ਹਨ। ਕੋਈ ਹੈਰਾਨੀ ਨਹੀਂ ਕਿ ਉਹ ਦੇਖ ਰਹੇ ਸਨ.

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

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

ਪਰ ਇੱਕ ਹੋਰ ਮਾਮਲਾ ਸੀ ...

ਕੀ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਪ੍ਰਸਿੱਧ ਡੇਬੀਅਨ 9 (ਸਟਰੈਚ) ਵਿੱਚ phpmyadmin ਵਰਗੇ ਪ੍ਰਸਿੱਧ ਪੈਕੇਜ ਅਜੇ ਵੀ (ਕਈ ਮਹੀਨਿਆਂ ਤੋਂ!) ਕਮਜ਼ੋਰ ਸਥਿਤੀ ਵਿੱਚ ਹੈ? (CVE-2019-6798). ਜਦੋਂ ਕਮਜ਼ੋਰੀ ਸਾਹਮਣੇ ਆਈ, ਅਸੀਂ ਇਸ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਜਲਦੀ ਕਵਰ ਕੀਤਾ। ਪਰ ਮੈਂ ਇਹ ਜਾਣਨ ਲਈ ਓਕੇਰ ਵਿੱਚ ਸੁਰੱਖਿਆ-ਟਰੈਕਰ ਪੰਨੇ ਦੀ ਨਿਗਰਾਨੀ ਸਥਾਪਤ ਕੀਤੀ ਹੈ ਕਿ ਇੱਕ "ਸੁੰਦਰ" ਹੱਲ ਕਦੋਂ ਆਵੇਗਾ (ਸਮੱਗਰੀ ਦੇ SHA1 ਜੋੜ ਦੁਆਰਾ)। ਸੂਚਕ ਨੇ ਮੈਨੂੰ ਕਈ ਵਾਰ ਮਰੋੜਿਆ, ਪੰਨਾ ਬਦਲ ਗਿਆ, ਪਰ ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਇਹ ਅਜੇ ਵੀ (ਜਨਵਰੀ 2019 ਤੋਂ!) ਇਹ ਨਹੀਂ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆ ਹੱਲ ਹੋ ਗਈ ਹੈ. ਹੋ ਸਕਦਾ ਹੈ, ਤਰੀਕੇ ਨਾਲ, ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆ ਕੀ ਹੈ ਕਿ ਅਜਿਹਾ ਮਹੱਤਵਪੂਰਨ ਪੈਕੇਜ ਅਜੇ ਵੀ ਇੱਕ ਸਾਲ ਤੋਂ ਵੱਧ ਸਮੇਂ ਲਈ ਕਮਜ਼ੋਰ ਹੈ?

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

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

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

Okerr ਸੈਂਸਰਾਂ ਲਈ, ਅਸੀਂ ਸਭ ਤੋਂ ਸਸਤੀ ਸੰਭਵ ਹੋਸਟਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ (ਜਿੱਥੇ ਗੁਣਵੱਤਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹਨ, ਉਹ ਇੱਕ ਦੂਜੇ ਦਾ ਬੀਮਾ ਕਰਦੇ ਹਨ)। ਇਸ ਲਈ, ਸਾਨੂੰ ਹਾਲ ਹੀ ਵਿੱਚ ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਹੋਸਟਿੰਗ ਅਤੇ ਸੁਪਰ ਸਸਤੀ ਮਿਲੀ ਹੈ, ਬੈਂਚਮਾਰਕ ਸ਼ਾਨਦਾਰ ਹਨ. ਪਰ... ਕਈ ਵਾਰ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਤੋਂ ਆਊਟਗੋਇੰਗ ਕਨੈਕਸ਼ਨ ਕਿਸੇ ਹੋਰ (ਗੁਆਂਢੀ) IP ਤੋਂ ਬਣਾਏ ਗਏ ਹਨ। ਚਮਤਕਾਰ। ਗਾਹਕ_ਆਈਪੀ ਮੋਡੀਊਲ ਨਾਲ https://diagnostic.opendns.com/myip ਗਲਤ IP ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ. ਅਤੇ ਸੂਚਕ ਦੇ ਸਰਵਰ ਲੌਗਸ ਤੋਂ ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਅਪਡੇਟ ਵੀ ਇਸ ਗੁਆਂਢੀ IP ਤੋਂ ਆਇਆ ਹੈ। ਆਓ ਹੁਣ ਸਹਾਰੇ ਨਾਲ ਨਜਿੱਠੀਏ। ਇਹ ਚੰਗਾ ਹੈ ਕਿ ਅਸੀਂ ਸ਼ਾਂਤੀ ਦੇ ਸਮੇਂ ਵਿੱਚ ਇਸ ਨੂੰ ਦੇਖਿਆ। ਪਰ, ਉਦਾਹਰਨ ਲਈ, ਇਹ ਅਕਸਰ ਹੁੰਦਾ ਹੈ ਕਿ ਪਹੁੰਚ ਆਈਪੀ ਸਫੈਦ ਸੂਚੀ ਦੇ ਅਨੁਸਾਰ ਰਜਿਸਟਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ - ਅਤੇ ਜੇ ਸਰਵਰ ਕਈ ਵਾਰ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਇਸ ਤਰ੍ਹਾਂ ਝਪਕਦਾ ਹੈ - ਤੁਸੀਂ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਬਹੁਤ ਲੰਬੇ ਸਮੇਂ ਲਈ ਫੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ.

ਖੈਰ, ਇੱਕ ਹੋਰ ਚੀਜ਼ - ਕਿਉਂਕਿ ਅਸੀਂ VPS ਹੋਸਟਿੰਗ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ - ਅਸੀਂ ਹਮੇਸ਼ਾ ਸਸਤੇ (hetzner, ovh, ਸਕੇਲਵੇ) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ. ਮੈਂ ਇਸਨੂੰ ਬੈਂਚਮਾਰਕ ਅਤੇ ਸਥਿਰਤਾ ਦੋਵਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਸੱਚਮੁੱਚ ਪਸੰਦ ਕਰਦਾ ਹਾਂ. ਅਸੀਂ ਹੋਰ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਮਹਿੰਗੇ ਐਮਾਜ਼ਾਨ EC2 ਦੀ ਵਰਤੋਂ ਵੀ ਕਰਦੇ ਹਾਂ। ਇਸ ਲਈ, okerr ਦਾ ਧੰਨਵਾਦ, ਸਾਡੇ ਕੋਲ ਸਾਡੀ ਆਪਣੀ ਸੂਚਿਤ ਰਾਏ ਹੈ. ਉਹ ਦੋਵੇਂ ਡਿੱਗ ਪੈਂਦੇ ਹਨ। ਅਤੇ ਮੈਂ ਇਹ ਨਹੀਂ ਕਹਾਂਗਾ ਕਿ ਸਾਡੇ ਨਿਰੀਖਣਾਂ ਦੀ ਲੰਮੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ, ਹੇਟਜ਼ਨਰ ਵਰਗੀਆਂ ਸਸਤੇ ਹੋਸਟਿੰਗਾਂ EC2 ਨਾਲੋਂ ਕਾਫ਼ੀ ਘੱਟ ਸਥਿਰ ਸਾਬਤ ਹੋਈਆਂ. ਇਸ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ ਹੋਰ ਐਮਾਜ਼ਾਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ ਜੁੜੇ ਨਹੀਂ ਹੋ, ਤਾਂ ਹੋਰ ਭੁਗਤਾਨ ਕਿਉਂ ਕਰੋ? 🙂

ਅੱਗੇ ਕੀ ਹੈ?

ਜੇ ਇਸ ਪੜਾਅ 'ਤੇ ਮੈਂ ਤੁਹਾਨੂੰ ਅਜੇ ਤੱਕ ਓਕਰ ਤੋਂ ਦੂਰ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਅਜ਼ਮਾਓ! ਤੁਸੀਂ ਸਿੱਧੇ ਇਸ ਲਿੰਕ 'ਤੇ ਜਾ ਸਕਦੇ ਹੋ okerr ਡੈਮੋ ਖਾਤਾ (ਹੁਣ ਕਲਿੱਕ ਕਰੋ!) ਪਰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ ਕਿ ਹਰ ਇੱਕ ਲਈ ਇੱਕ ਹੀ ਡੈਮੋ ਖਾਤਾ ਹੈ, ਇਸ ਲਈ ਜੇਕਰ ਤੁਸੀਂ ਕੁਝ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਸੇ ਖਾਤੇ ਵਿੱਚ ਕੋਈ ਹੋਰ ਵਿਅਕਤੀ ਉਸੇ ਸਮੇਂ ਤੁਹਾਡੇ ਨਾਲ ਦਖਲ ਦੇ ਸਕਦਾ ਹੈ। ਜਾਂ (ਬਿਹਤਰ) ਲਿੰਕ ਰਾਹੀਂ ਰਜਿਸਟਰ ਕਰੋ offsite okerr - ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ, ਬਿਨਾ SMS. ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਅਸਲੀ ਈਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਪਸੰਦ ਨਹੀਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਡਿਸਪੋਸੇਬਲ ਈਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ ਕਿ ਮੇਲਿਨੇਟਰ (ਮੈਂ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ getnada.com). ਅਜਿਹੇ ਖਾਤਿਆਂ ਨੂੰ ਸਮੇਂ ਦੇ ਨਾਲ ਮਿਟਾ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਉਹ ਜਾਂਚ ਲਈ ਠੀਕ ਹੋਣਗੇ।

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

ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ - ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਵਿਕੀ ਸਰਵਰ ਪਾਸੇ ਅਤੇ ਕਲਾਇੰਟ 'ਤੇ (okerrupdate wiki). ਪਰ ਜੇ ਕੁਝ ਅਸਪਸ਼ਟ ਹੈ, ਤਾਂ okerr.com ਨੂੰ ਸਮਰਥਨ ('ਤੇ) ਲਿਖੋ ਜਾਂ ਟਿਕਟ ਛੱਡੋ - ਅਸੀਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਜਲਦੀ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗੇ।

ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਵਰਤਦੇ ਹੋ ਅਤੇ ਇਹ ਵਧੀਆਂ ਹੋਈਆਂ ਸੀਮਾਵਾਂ ਕਾਫ਼ੀ ਨਹੀਂ ਹਨ, ਤਾਂ ਸਮਰਥਨ ਲਈ ਲਿਖੋ ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਵਧਾਵਾਂਗੇ (ਮੁਫ਼ਤ ਵਿੱਚ)।

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

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

ਸਰੋਤ: www.habr.com