ਅਸੀਂ Prometheus, Clickhouse ਅਤੇ ELK 'ਤੇ ਨਿਗਰਾਨੀ ਕਿਵੇਂ ਬਣਾਈ ਹੈ

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

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

ਪ੍ਰੋਜੈਕਟ ਬਾਰੇ

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

ਇੰਟਰਵਿਊ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ, ਮੈਂ ਵਾਰ-ਵਾਰ ਦੇਖਿਆ ਕਿ ਪ੍ਰਸ਼ਾਸਕ ਹਮੇਸ਼ਾ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਸਹੀ ਢੰਗ ਨਾਲ ਨਹੀਂ ਪਹੁੰਚਦੇ ਹਨ: ਬਹੁਤ ਸਾਰੇ ਅਜੇ ਵੀ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ ਅਤੇ ਕਦੇ-ਕਦਾਈਂ ਸੇਵਾਵਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਨ।

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸਦੇ ਹੋਰ ਵਿਕਾਸ ਦੀ ਵਿਅਰਥਤਾ ਦੀ ਸਪਸ਼ਟ ਸਮਝ ਸੀ. ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਜੋ ਲੋਕ Icinga ਤੋਂ ਜਾਣੂ ਹਨ ਉਹ ਮੈਨੂੰ ਸਮਝਣਗੇ. ਇਸ ਲਈ, ਅਸੀਂ ਪ੍ਰੋਜੈਕਟ ਲਈ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਮੁੜ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

Prometheus

ਅਸੀਂ ਤਿੰਨ ਮੁੱਖ ਸੂਚਕਾਂ ਦੇ ਅਧਾਰ ਤੇ ਪ੍ਰੋਮੀਥੀਅਸ ਨੂੰ ਚੁਣਿਆ:

1. ਉਪਲਬਧ ਮੈਟ੍ਰਿਕਸ ਦੀ ਇੱਕ ਵੱਡੀ ਸੰਖਿਆ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ 60 ਹਜ਼ਾਰ ਹਨ। ਬੇਸ਼ੱਕ, ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਅਸੀਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ (ਸ਼ਾਇਦ ਲਗਭਗ 95%) ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਹਾਂ। ਦੂਜੇ ਪਾਸੇ, ਉਹ ਸਾਰੇ ਮੁਕਾਬਲਤਨ ਸਸਤੇ ਹਨ. ਸਾਡੇ ਲਈ, ਇਹ ਪਹਿਲਾਂ ਵਰਤੇ ਗਏ ਆਈਸਿੰਗਾ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਇੱਕ ਹੋਰ ਅਤਿ ਹੈ। ਇਸ ਵਿੱਚ, ਮੈਟ੍ਰਿਕਸ ਜੋੜਨਾ ਇੱਕ ਖਾਸ ਦਰਦ ਸੀ: ਮੌਜੂਦਾ ਲੋਕ ਮਹਿੰਗੇ ਸਨ (ਕਿਸੇ ਵੀ ਪਲੱਗਇਨ ਦੇ ਸਰੋਤ ਕੋਡ ਨੂੰ ਦੇਖੋ). ਕੋਈ ਵੀ ਪਲੱਗਇਨ Bash ਜਾਂ Python ਵਿੱਚ ਇੱਕ ਸਕ੍ਰਿਪਟ ਸੀ, ਜਿਸਦਾ ਲਾਂਚ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਮਹਿੰਗਾ ਹੈ।
2. ਇਹ ਪ੍ਰਣਾਲੀ ਮੁਕਾਬਲਤਨ ਥੋੜ੍ਹੇ ਜਿਹੇ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਦੀ ਹੈ। 600 MB RAM, ਇੱਕ ਕੋਰ ਦਾ 15% ਅਤੇ ਕੁਝ ਦਰਜਨ IOPS ਸਾਡੇ ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ ਲਈ ਕਾਫੀ ਹਨ। ਬੇਸ਼ੱਕ, ਤੁਹਾਨੂੰ ਮੈਟ੍ਰਿਕਸ ਨਿਰਯਾਤਕਾਂ ਨੂੰ ਚਲਾਉਣਾ ਪਵੇਗਾ, ਪਰ ਉਹ ਸਾਰੇ ਗੋ ਵਿੱਚ ਲਿਖੇ ਗਏ ਹਨ ਅਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪਾਵਰ ਭੁੱਖੇ ਵੀ ਨਹੀਂ ਹਨ. ਮੈਨੂੰ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਆਧੁਨਿਕ ਹਕੀਕਤਾਂ ਵਿੱਚ ਇਹ ਇੱਕ ਸਮੱਸਿਆ ਹੈ।
3. ਕੁਬਰਨੇਟਸ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ. ਗਾਹਕ ਦੀਆਂ ਯੋਜਨਾਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਚੋਣ ਸਪੱਸ਼ਟ ਹੈ।

ELK:

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

ਸਲਿੱਕਹਾਊਸ

ਸ਼ੁਰੂ ਵਿੱਚ, ਚੋਣ InfluxDB 'ਤੇ ਡਿੱਗ ਗਈ। ਅਸੀਂ Nginx ਲੌਗਸ, pg_stat_statements ਤੋਂ ਅੰਕੜੇ ਇਕੱਠੇ ਕਰਨ ਅਤੇ ਪ੍ਰੋਮੀਥੀਅਸ ਇਤਿਹਾਸਕ ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ ਨੂੰ ਮਹਿਸੂਸ ਕੀਤਾ। ਸਾਨੂੰ ਇਨਫਲਕਸ ਪਸੰਦ ਨਹੀਂ ਸੀ ਕਿਉਂਕਿ ਇਹ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਮੈਮੋਰੀ ਵਰਤਣ ਲੱਗ ਪਿਆ ਸੀ ਅਤੇ ਕ੍ਰੈਸ਼ ਹੋ ਗਿਆ ਸੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮੈਂ remote_addr ਦੁਆਰਾ ਸਵਾਲਾਂ ਨੂੰ ਗਰੁੱਪ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ, ਪਰ ਇਸ DBMS ਵਿੱਚ ਗਰੁੱਪਿੰਗ ਸਿਰਫ਼ ਟੈਗਾਂ ਦੁਆਰਾ ਹੈ। ਟੈਗਸ ਮਹਿੰਗੇ ਹਨ (ਮੈਮੋਰੀ), ਉਹਨਾਂ ਦੀ ਗਿਣਤੀ ਸ਼ਰਤ ਅਨੁਸਾਰ ਸੀਮਤ ਹੈ।

ਅਸੀਂ ਦੁਬਾਰਾ ਖੋਜ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ। ਘੱਟੋ-ਘੱਟ ਸਰੋਤ ਦੀ ਖਪਤ ਵਾਲੇ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਡੇਟਾਬੇਸ ਦੀ ਲੋੜ ਸੀ, ਤਰਜੀਹੀ ਤੌਰ 'ਤੇ ਡਿਸਕ 'ਤੇ ਡੇਟਾ ਸੰਕੁਚਨ ਦੇ ਨਾਲ।

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

NewRelic

NewRelic ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ ਸਾਡੇ ਨਾਲ ਰਿਹਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਗਾਹਕ ਦੀ ਪਸੰਦ ਸੀ। ਅਸੀਂ ਇਸਨੂੰ APM ਵਜੋਂ ਵਰਤਦੇ ਹਾਂ।

ਜ਼ੱਬਿਕਸ

ਅਸੀਂ ਵੱਖ-ਵੱਖ APIs ਦੇ ਬਲੈਕ ਬਾਕਸ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ Zabbix ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਇੱਕ ਨਿਗਰਾਨੀ ਪਹੁੰਚ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ

ਅਸੀਂ ਕੰਮ ਨੂੰ ਵਿਗਾੜਨਾ ਚਾਹੁੰਦੇ ਸੀ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਨਿਗਰਾਨੀ ਲਈ ਪਹੁੰਚ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ।

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਮੈਂ ਆਪਣੇ ਸਿਸਟਮ ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਪੱਧਰਾਂ ਵਿੱਚ ਵੰਡਿਆ ਹੈ:

• ਹਾਰਡਵੇਅਰ ਅਤੇ VMS;
• ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ;
• ਸਿਸਟਮ ਸੇਵਾਵਾਂ, ਸੌਫਟਵੇਅਰ ਸਟੈਕ;
• ਐਪਲੀਕੇਸ਼ਨ;
• ਵਪਾਰ ਤਰਕ.

ਇਹ ਪਹੁੰਚ ਸੁਵਿਧਾਜਨਕ ਕਿਉਂ ਹੈ:

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

ਕਿਉਂਕਿ ਸਾਡਾ ਕੰਮ ਸਿਸਟਮ ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ ਉਲੰਘਣਾਵਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ ਹੈ, ਸਾਨੂੰ ਹਰੇਕ ਪੱਧਰ 'ਤੇ ਮੈਟ੍ਰਿਕਸ ਦੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੂਹ ਨੂੰ ਉਜਾਗਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਚੇਤਾਵਨੀ ਨਿਯਮਾਂ ਨੂੰ ਲਿਖਣ ਵੇਲੇ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹਨ। ਅੱਗੇ, ਆਓ "VMS", "ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ" ਅਤੇ "ਸਿਸਟਮ ਸੇਵਾਵਾਂ, ਸਾਫਟਵੇਅਰ ਸਟੈਕ" ਪੱਧਰਾਂ 'ਤੇ ਚੱਲੀਏ।

ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ

ਹੋਸਟਿੰਗ ਸਾਨੂੰ ਇੱਕ ਪ੍ਰੋਸੈਸਰ, ਡਿਸਕ, ਮੈਮੋਰੀ ਅਤੇ ਨੈੱਟਵਰਕ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ। ਅਤੇ ਸਾਨੂੰ ਪਹਿਲੇ ਦੋ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਸਨ. ਇਸ ਲਈ, ਮੈਟ੍ਰਿਕਸ:

CPU ਚੋਰੀ ਕਰਨ ਦਾ ਸਮਾਂ - ਜਦੋਂ ਤੁਸੀਂ Amazon (t2.micro, ਉਦਾਹਰਣ ਵਜੋਂ) 'ਤੇ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਖਰੀਦਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇੱਕ ਪੂਰਾ ਪ੍ਰੋਸੈਸਰ ਕੋਰ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਪਰ ਇਸਦੇ ਸਮੇਂ ਦਾ ਸਿਰਫ ਇੱਕ ਕੋਟਾ ਹੈ। ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਪ੍ਰੋਸੈਸਰ ਤੁਹਾਡੇ ਤੋਂ ਖੋਹ ਲਿਆ ਜਾਵੇਗਾ।

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

IOPS + CPU iowait ਸਮਾਂ - ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ, ਬਹੁਤ ਸਾਰੇ ਕਲਾਉਡ ਹੋਸਟਿੰਗ ਕਾਫ਼ੀ IOPS ਪ੍ਰਦਾਨ ਨਾ ਕਰਕੇ ਪਾਪ ਕਰਦੇ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਘੱਟ IOPS ਵਾਲਾ ਅਨੁਸੂਚੀ ਉਹਨਾਂ ਲਈ ਕੋਈ ਦਲੀਲ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ, ਇਹ CPU iowait ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦੇ ਯੋਗ ਹੈ. ਗ੍ਰਾਫਾਂ ਦੀ ਇਸ ਜੋੜੀ ਨਾਲ - ਘੱਟ IOPS ਅਤੇ ਉੱਚ I/O ਉਡੀਕ ਦੇ ਨਾਲ - ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਹੋਸਟਿੰਗ ਨਾਲ ਗੱਲ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰ ਸਕਦੇ ਹੋ।

ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ

ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਮੈਟ੍ਰਿਕਸ:

• % ਵਿੱਚ ਉਪਲਬਧ ਮੈਮੋਰੀ ਦੀ ਮਾਤਰਾ;
• ਸਵੈਪ ਵਰਤੋਂ ਗਤੀਵਿਧੀ: vmstat ਸਵੈਪਿਨ, ਸਵੈਪਆਊਟ;
• % ਵਿੱਚ ਉਪਲਬਧ ਆਈਨੋਡਸ ਅਤੇ ਫਾਇਲ ਸਿਸਟਮ ਉੱਤੇ ਖਾਲੀ ਥਾਂ ਦੀ ਸੰਖਿਆ
• ਔਸਤ ਲੋਡ;
• ਦੋ ਰਾਜ ਵਿੱਚ ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ;
• ਕੰਟਰੈਕ ਟੇਬਲ ਦੀ ਭਰਪੂਰਤਾ;
• ss ਉਪਯੋਗਤਾ, iproute2 ਪੈਕੇਜ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨੈਟਵਰਕ ਦੀ ਗੁਣਵੱਤਾ ਦੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ - ਇਸਦੇ ਆਉਟਪੁੱਟ ਤੋਂ RTT ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਇੱਕ ਸੂਚਕ ਪ੍ਰਾਪਤ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਡੈਸਟ ਪੋਰਟ ਦੁਆਰਾ ਸਮੂਹ ਕਰੋ।

ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਪੱਧਰ 'ਤੇ ਵੀ ਸਾਡੇ ਕੋਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਰਗੀ ਇਕਾਈ ਹੈ। ਸਿਸਟਮ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਦੀ ਪਛਾਣ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜੋ ਇਸਦੇ ਸੰਚਾਲਨ ਵਿੱਚ ਮਹੱਤਵਪੂਰਣ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦੇ ਹਨ. ਜੇਕਰ, ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡੇ ਕੋਲ ਕਈ pgpool ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਲਈ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਮੈਟ੍ਰਿਕਸ ਦਾ ਸੈੱਟ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:

• ਸੀਪੀਯੂ;
• ਮੈਮੋਰੀ ਮੁੱਖ ਤੌਰ 'ਤੇ ਨਿਵਾਸੀ ਹੈ;
• IO - ਤਰਜੀਹੀ ਤੌਰ 'ਤੇ IOPS ਵਿੱਚ;
• FileFd - ਖੁੱਲਾ ਅਤੇ ਸੀਮਾ;
• ਮਹੱਤਵਪੂਰਨ ਪੰਨਾ ਅਸਫਲਤਾਵਾਂ - ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਸਮਝ ਸਕਦੇ ਹੋ ਕਿ ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਬਦਲਿਆ ਜਾ ਰਿਹਾ ਹੈ।

ਅਸੀਂ ਡੌਕਰ ਵਿੱਚ ਸਾਰੀ ਨਿਗਰਾਨੀ ਤੈਨਾਤ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਅਸੀਂ ਮੈਟ੍ਰਿਕਸ ਡੇਟਾ ਇਕੱਤਰ ਕਰਨ ਲਈ ਸਲਾਹਕਾਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਹੋਰ ਮਸ਼ੀਨਾਂ 'ਤੇ ਅਸੀਂ ਪ੍ਰੋਸੈਸ-ਐਕਸਪੋਰਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਸਿਸਟਮ ਸੇਵਾਵਾਂ, ਸੌਫਟਵੇਅਰ ਸਟੈਕ

ਹਰੇਕ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਆਪਣੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਦੇ ਇੱਕ ਖਾਸ ਸਮੂਹ ਨੂੰ ਵੱਖ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।

ਯੂਨੀਵਰਸਲ ਸੈੱਟ ਹੈ:

• ਬੇਨਤੀ ਦਰ;
• ਗਲਤੀਆਂ ਦੀ ਗਿਣਤੀ;
• ਲੇਟੈਂਸੀ;
• ਸੰਤ੍ਰਿਪਤਾ.

ਇਸ ਪੱਧਰ 'ਤੇ ਨਿਗਰਾਨੀ ਦੀਆਂ ਸਾਡੀਆਂ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਉਦਾਹਰਣਾਂ Nginx ਅਤੇ PostgreSQL ਹਨ।

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

ਅਸੀਂ ਡਿਸਕਾਂ 'ਤੇ ਇੱਕ ਉੱਚ ਲੋਡ ਦੇਖਿਆ, ਪਰ ਹੌਲੀ ਲੌਗ ਅਸਲ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਦਿਖਾਉਂਦੇ. ਅਸੀਂ pg_stat_statements ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕੀਤਾ, ਇੱਕ ਦ੍ਰਿਸ਼ ਜੋ ਕਿ ਪੁੱਛਗਿੱਛ ਦੇ ਅੰਕੜੇ ਇਕੱਠੇ ਕਰਦਾ ਹੈ।

ਇਹ ਸਭ ਐਡਮਿਨ ਦੀ ਲੋੜ ਹੈ।

ਅਸੀਂ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਗਤੀਵਿਧੀ ਦੇ ਗ੍ਰਾਫ਼ ਬਣਾਉਂਦੇ ਹਾਂ:

ਹਰ ਚੀਜ਼ ਸਧਾਰਨ ਅਤੇ ਸਪਸ਼ਟ ਹੈ, ਹਰੇਕ ਬੇਨਤੀ ਦਾ ਆਪਣਾ ਰੰਗ ਹੈ.

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

ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ, ਮੈਂ request_time, upstream_response_time, body_bytes_sent, request_length, request_id ਸ਼ਾਮਲ ਕੀਤਾ ਹੈ। ਅਸੀਂ ਜਵਾਬ ਸਮਾਂ ਅਤੇ ਤਰੁੱਟੀਆਂ ਦੀ ਸੰਖਿਆ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹਾਂ:

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

ਪਰ ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਰਹਿੰਦੀ ਹੈ - ਘਟਨਾ ਦੇ ਕਾਰਨਾਂ ਦੇ ਤੇਜ਼ੀ ਨਾਲ ਖਾਤਮੇ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ.

ਘਟਨਾ ਦਾ ਹੱਲ

ਸਮੱਸਿਆ ਦੀ ਪਛਾਣ ਕਰਨ ਤੋਂ ਲੈ ਕੇ ਹੱਲ ਕਰਨ ਤੱਕ ਦੀ ਸਮੁੱਚੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕਈ ਪੜਾਵਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ:

• ਸਮੱਸਿਆ ਦੀ ਪਛਾਣ;
• ਡਿਊਟੀ ਪ੍ਰਬੰਧਕ ਨੂੰ ਸੂਚਨਾ;
• ਇੱਕ ਘਟਨਾ ਦਾ ਜਵਾਬ;
• ਕਾਰਨਾਂ ਦਾ ਖਾਤਮਾ.

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

ਚਲੋ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਡਿਊਟੀ ਅਫਸਰ ਦੇ ਫੋਨ ਦੀ ਘੰਟੀ ਵੱਜੀ। ਉਹ ਕੀ ਕਰੇਗਾ? ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਲੱਭੋ - ਕੀ ਟੁੱਟਿਆ, ਕਿੱਥੇ ਟੁੱਟਿਆ, ਕਿਵੇਂ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਨੀ ਹੈ? ਇੱਥੇ ਅਸੀਂ ਇਹਨਾਂ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਕਿਵੇਂ ਦਿੰਦੇ ਹਾਂ:

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

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

ਅੰਕ ਦੇ ਇੱਕ ਜੋੜੇ ਨੂੰ.

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

ਦੂਜਾ, ਗੰਭੀਰਤਾ ਦੇ ਪੱਧਰਾਂ ਦੀ ਸਹੀ ਵਰਤੋਂ ਕਰੋ। ਹਰ ਭਾਸ਼ਾ ਦਾ ਆਪਣਾ ਮਿਆਰ ਹੁੰਦਾ ਹੈ। ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ, ਮੈਂ ਚਾਰ ਪੱਧਰਾਂ ਨੂੰ ਵੱਖਰਾ ਕਰਦਾ ਹਾਂ:

1. ਕੋਈ ਗਲਤੀ ਨਹੀਂ;
2. ਕਲਾਇੰਟ ਸਾਈਡ ਗਲਤੀ;
3. ਗਲਤੀ ਸਾਡੇ ਪਾਸੇ ਹੈ, ਅਸੀਂ ਪੈਸੇ ਨਹੀਂ ਗੁਆਉਂਦੇ, ਅਸੀਂ ਜੋਖਮ ਨਹੀਂ ਝੱਲਦੇ;
4. ਗਲਤੀ ਸਾਡੇ ਪਾਸੇ ਹੈ, ਅਸੀਂ ਪੈਸੇ ਗੁਆਉਂਦੇ ਹਾਂ.

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

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

ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇਹ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਲੌਗਸ, Nginx ਲੌਗਸ, ਅਤੇ ਹੋਰਾਂ ਵਿੱਚ ਫੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਕੀਤਾ ਹੈ। ਤੁਹਾਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਨੇੜੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਮੈਟ੍ਰਿਕਸ ਬੇਸ਼ੱਕ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਪਰ ਵਪਾਰ ਉਹਨਾਂ ਵਿੱਚ ਦਿਲਚਸਪੀ ਨਹੀਂ ਰੱਖਦਾ, ਸਾਨੂੰ ਉਹਨਾਂ ਲਈ ਭੁਗਤਾਨ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ.

ਸਰੋਤ: www.habr.com