ਅੱਜ ਕੁਬਰਨੇਟਸ (ਅਤੇ ਨਾ ਸਿਰਫ਼) ਵਿੱਚ ਲੌਗਸ: ਉਮੀਦਾਂ ਅਤੇ ਅਸਲੀਅਤ

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

ਹਾਲਾਂਕਿ, ਪਹਿਲਾਂ, ਮੈਂ ਇੱਕ ਰਿਜ਼ਰਵੇਸ਼ਨ ਕਰਾਂਗਾ ਕਿ ਵੱਖ-ਵੱਖ ਗਾਹਕ ਲੌਗ ਇਕੱਠੇ ਕਰਕੇ ਬਹੁਤ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਸਮਝਦੇ ਹਨ:

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

ਅਸੀਂ ਵੱਖ-ਵੱਖ "ਇੱਛਾ ਸੂਚੀਆਂ" ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਅਤੇ ਸਾਨੂੰ ਕਿਹੜੀਆਂ ਮੁਸ਼ਕਲਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ, ਇਸ ਬਾਰੇ ਹੇਠਾਂ ਕੱਟ ਦਿੱਤਾ ਗਿਆ ਹੈ।

ਥਿਊਰੀ: ਲੌਗਿੰਗ ਟੂਲਸ ਬਾਰੇ

ਲੌਗਿੰਗ ਸਿਸਟਮ ਦੇ ਭਾਗਾਂ ਦਾ ਪਿਛੋਕੜ

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

ਕੰਪਿਊਟਰ ਵਿਗਿਆਨ ਸਥਿਰ ਨਹੀਂ ਹੋਇਆ: ਕੰਪਿਊਟਰ ਨੈਟਵਰਕ ਪ੍ਰਗਟ ਹੋਏ, ਪਹਿਲੇ ਕਲੱਸਟਰ... ਕਈ ਕੰਪਿਊਟਰਾਂ ਵਾਲੇ ਗੁੰਝਲਦਾਰ ਪ੍ਰਣਾਲੀਆਂ ਨੇ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਹੁਣ ਸਿਸਟਮ ਪ੍ਰਬੰਧਕਾਂ ਨੂੰ ਕਈ ਮਸ਼ੀਨਾਂ ਤੋਂ ਲੌਗ ਇਕੱਠੇ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਖਾਸ ਮਾਮਲਿਆਂ ਵਿੱਚ ਉਹ OS ਕਰਨਲ ਸੁਨੇਹੇ ਜੋੜ ਸਕਦੇ ਸਨ ਜੇਕਰ ਉਹਨਾਂ ਨੂੰ ਸਿਸਟਮ ਅਸਫਲਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਕੇਂਦਰੀ ਲੌਗ ਕਲੈਕਸ਼ਨ ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ, 2000 ਦੇ ਦਹਾਕੇ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਸੀ RFC 3164, ਜੋ remote_syslog ਨੂੰ ਮਾਨਕੀਕ੍ਰਿਤ ਕਰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਇਕ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਪ੍ਰਗਟ ਹੋਇਆ: ਲਾਗ ਕੁਲੈਕਟਰ ਅਤੇ ਉਹਨਾਂ ਦੀ ਸਟੋਰੇਜ।

ਲੌਗਸ ਦੀ ਮਾਤਰਾ ਵਿੱਚ ਵਾਧੇ ਅਤੇ ਵੈਬ ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਵਿਆਪਕ ਜਾਣ-ਪਛਾਣ ਦੇ ਨਾਲ, ਇਹ ਸਵਾਲ ਪੈਦਾ ਹੋਇਆ ਕਿ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸੁਵਿਧਾਜਨਕ ਰੂਪ ਵਿੱਚ ਕਿਹੜੇ ਲੌਗਸ ਨੂੰ ਦਿਖਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਸਧਾਰਨ ਕੰਸੋਲ ਟੂਲ (awk/sed/grep) ਨੂੰ ਹੋਰ ਉੱਨਤ ਲੋਕਾਂ ਦੁਆਰਾ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ ਲੌਗ ਦਰਸ਼ਕ - ਤੀਜਾ ਹਿੱਸਾ.

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

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

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

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

ਜੇ ਕਿਸੇ ਸਮੇਂ ਆਮ ਪ੍ਰਿੰਟ "ਲੌਗਿੰਗ ਸਿਸਟਮ" ਲਈ ਕਾਫੀ ਹੋ ਸਕਦੇ ਸਨ, ਤਾਂ ਹੁਣ ਸਥਿਤੀ ਬਹੁਤ ਬਦਲ ਗਈ ਹੈ।

ਕੁਬਰਨੇਟਸ ਅਤੇ ਲੌਗਸ

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

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

• ਕੋਈ ਸਟੈਕ ਨੂੰ ਅਨਰੋਲ ਕਰਦਾ ਹੈ EFK (Elasticsearch, Fluentd, Kibana);
• ਕੋਈ ਹਾਲ ਹੀ ਵਿੱਚ ਜਾਰੀ ਕੀਤੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ ਲੋਕੀ ਜਾਂ ਵਰਤਦਾ ਹੈ ਲੌਗਿੰਗ ਆਪਰੇਟਰ;
• ਸਾਨੂੰ (ਅਤੇ ਸ਼ਾਇਦ ਸਿਰਫ ਅਸੀਂ ਹੀ ਨਹੀਂ? ..) ਮੈਂ ਆਪਣੇ ਖੁਦ ਦੇ ਵਿਕਾਸ ਤੋਂ ਕਾਫ਼ੀ ਹੱਦ ਤੱਕ ਸੰਤੁਸ਼ਟ ਹਾਂ - ਲਾਗ ਹਾਊਸ...

ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਅਸੀਂ K8s ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ ਬੰਡਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ (ਸਵੈ-ਹੋਸਟ ਕੀਤੇ ਹੱਲਾਂ ਲਈ):

• Fluentd + Elasticsearch + Kibana;
• Fluentd + Clickhouse + loghouse.

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

K8s ਵਿੱਚ ਲੌਗਸ ਨਾਲ ਅਭਿਆਸ ਕਰੋ

"ਰੋਜ਼ਾਨਾ ਲੌਗ", ਤੁਹਾਡੇ ਵਿੱਚੋਂ ਕਿੰਨੇ ਹਨ?...

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

ਆਉ ਕਲਿਕਹਾਊਸ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ

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

ਜਿਵੇਂ ਹੀ ਵੱਧ ਤੋਂ ਵੱਧ ਰੀਅਲਟਾਈਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਕਲਿਕਹਾਊਸ ਵਾਲਾ 4-ਕੋਰ ਸਰਵਰ ਪਹਿਲਾਂ ਹੀ ਡਿਸਕ ਸਬਸਿਸਟਮ 'ਤੇ ਓਵਰਲੋਡ ਹੋ ਜਾਵੇਗਾ:

ਇਸ ਕਿਸਮ ਦੀ ਲੋਡਿੰਗ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਹੈ ਕਿ ਅਸੀਂ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ. ਅਤੇ ਡਾਟਾਬੇਸ ਵਧੇ ਹੋਏ ਡਿਸਕ ਲੋਡ ਨਾਲ ਇਸ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਹੇਠ ਲਿਖੀਆਂ ਗਲਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ:

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

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

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

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

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

Elasticsearch ਬਾਰੇ ਕੀ?

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

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

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

ਫਿਰ ਇੱਕ ਕੁਦਰਤੀ ਸਵਾਲ ਉੱਠਦਾ ਹੈ:

ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਲੌਗਸ ਦੀ ਲੋੜ ਹੈ?

ਆਉ ਆਪਣੇ ਆਪ ਨੂੰ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ: ਲੌਗ ਇੱਕੋ ਸਮੇਂ ਜਾਣਕਾਰੀ ਭਰਪੂਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਕਵਰ ਨਹੀਂ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਰ ਸਿਸਟਮ ਵਿੱਚ ਘਟਨਾ.

ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ ਸਫਲ ਔਨਲਾਈਨ ਸਟੋਰ ਹੈ। ਕਿਹੜੇ ਲੌਗ ਮਹੱਤਵਪੂਰਨ ਹਨ? ਵੱਧ ਤੋਂ ਵੱਧ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨਾ, ਉਦਾਹਰਨ ਲਈ, ਭੁਗਤਾਨ ਗੇਟਵੇ ਤੋਂ, ਇੱਕ ਵਧੀਆ ਵਿਚਾਰ ਹੈ। ਪਰ ਉਤਪਾਦ ਕੈਟਾਲਾਗ ਵਿੱਚ ਚਿੱਤਰ ਕੱਟਣ ਵਾਲੀ ਸੇਵਾ ਦੇ ਸਾਰੇ ਲੌਗ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹਨ: ਸਿਰਫ਼ ਤਰੁਟੀਆਂ ਅਤੇ ਉੱਨਤ ਨਿਗਰਾਨੀ ਹੀ ਕਾਫ਼ੀ ਹਨ (ਉਦਾਹਰਨ ਲਈ, 500 ਗਲਤੀਆਂ ਦੀ ਪ੍ਰਤੀਸ਼ਤਤਾ ਜੋ ਇਹ ਭਾਗ ਤਿਆਰ ਕਰਦਾ ਹੈ)।

ਇਸ ਲਈ ਅਸੀਂ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚੇ ਹਾਂ ਕਿ ਕੇਂਦਰੀਕ੍ਰਿਤ ਲੌਗਿੰਗ ਹਮੇਸ਼ਾ ਜਾਇਜ਼ ਨਹੀਂ ਹੁੰਦੀ ਹੈ. ਅਕਸਰ ਕਲਾਇੰਟ ਸਾਰੇ ਲੌਗਾਂ ਨੂੰ ਇੱਕ ਥਾਂ ਤੇ ਇਕੱਠਾ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਅਸਲ ਵਿੱਚ, ਪੂਰੇ ਲੌਗ ਤੋਂ, ਸਿਰਫ ਇੱਕ ਸ਼ਰਤ 5% ਸੁਨੇਹਿਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਕਾਰੋਬਾਰ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ:

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

ਜੀਵਨ ਤੋਂ ਦ੍ਰਿਸ਼ਟਾਂਤ

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

ਕਾਰਪੋਰੇਟ ਸਮੱਸਿਆ ਦਾ ਪਤਾ ਲਗਾਉਣ ਵਾਲੇ ਸੈਂਸਰ - QRadar ਨਾਲ ਕੇਂਦਰੀਕ੍ਰਿਤ ਲੌਗ ਕਲੈਕਸ਼ਨ ਸਿਸਟਮ ਦੇ "ਦੋਸਤ ਬਣਾਉਣ" ਦੀ ਲੋੜ ਸੀ। ਇਹ ਸਿਸਟਮ syslog ਪ੍ਰੋਟੋਕੋਲ ਰਾਹੀਂ ਲਾਗ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ FTP ਤੋਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਸਨੂੰ fluentd ਲਈ remote_syslog ਪਲੱਗਇਨ ਨਾਲ ਜੋੜਨਾ ਤੁਰੰਤ ਸੰਭਵ ਨਹੀਂ ਸੀ। (ਜਿਵੇਂ ਕਿ ਇਹ ਨਿਕਲਿਆ, ਅਸੀਂ ਇਕੱਲੇ ਨਹੀਂ ਹਾਂ). QRadar ਸੈਟ ਅਪ ਕਰਨ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਗਾਹਕ ਦੀ ਸੁਰੱਖਿਆ ਟੀਮ ਦੇ ਪੱਖ ਵਿੱਚ ਨਿਕਲੀਆਂ।

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

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

ਲੌਗ ਲਈ ਮਾਪਦੰਡ

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

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

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

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

ਗਲਤੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਫੀਲਡ ਭੇਜ ਰਹੇ ਹੋ ਜਿਸਦੀ ਕਿਸਮ ਇੱਕ ਰੈਡੀਮੇਡ ਮੈਪਿੰਗ ਨਾਲ ਸੂਚਕਾਂਕ ਵਿੱਚ ਅਸਥਿਰ ਹੈ। ਸਰਲ ਉਦਾਹਰਨ ਇੱਕ ਵੇਰੀਏਬਲ ਦੇ ਨਾਲ nginx ਲੌਗ ਵਿੱਚ ਇੱਕ ਖੇਤਰ ਹੈ $upstream_status. ਇਸ ਵਿੱਚ ਇੱਕ ਨੰਬਰ ਜਾਂ ਇੱਕ ਸਤਰ ਹੋ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਣ ਲਈ:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

ਲੌਗ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਸਰਵਰ 10.100.0.10 ਨੇ 404 ਗਲਤੀ ਨਾਲ ਜਵਾਬ ਦਿੱਤਾ ਅਤੇ ਬੇਨਤੀ ਨੂੰ ਕਿਸੇ ਹੋਰ ਸਮੱਗਰੀ ਸਟੋਰੇਜ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਸੀ। ਨਤੀਜੇ ਵਜੋਂ, ਲੌਗਸ ਵਿੱਚ ਮੁੱਲ ਇਸ ਤਰ੍ਹਾਂ ਬਣ ਗਿਆ:

"upstream_response_time": "0.001, 0.007"

ਇਹ ਸਥਿਤੀ ਇੰਨੀ ਆਮ ਹੈ ਕਿ ਇਹ ਇੱਕ ਵੱਖਰੇ ਦੇ ਹੱਕਦਾਰ ਵੀ ਹੈ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਹਵਾਲੇ.

ਭਰੋਸੇਯੋਗਤਾ ਬਾਰੇ ਕੀ?

ਅਜਿਹੇ ਸਮੇਂ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਬਿਨਾਂ ਕਿਸੇ ਅਪਵਾਦ ਦੇ ਸਾਰੇ ਲੌਗ ਜ਼ਰੂਰੀ ਹੁੰਦੇ ਹਨ। ਅਤੇ ਇਸਦੇ ਨਾਲ, ਉੱਪਰ ਪ੍ਰਸਤਾਵਿਤ/ਵਿਚਾਰੇ K8s ਲਈ ਆਮ ਲੌਗ ਕਲੈਕਸ਼ਨ ਸਕੀਮਾਂ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਹਨ।

ਉਦਾਹਰਨ ਲਈ, fluentd ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਕੰਟੇਨਰਾਂ ਤੋਂ ਲੌਗ ਇਕੱਠੇ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਸਾਡੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ, ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕੰਟੇਨਰ 4 ਸਕਿੰਟਾਂ ਤੋਂ ਘੱਟ ਸਮੇਂ ਲਈ ਰਹਿੰਦਾ ਸੀ ਅਤੇ ਫਿਰ ਮਿਟਾ ਦਿੱਤਾ ਗਿਆ ਸੀ - ਸੰਬੰਧਿਤ ਐਨੋਟੇਸ਼ਨ ਦੇ ਅਨੁਸਾਰ:

"helm.sh/hook-delete-policy": hook-succeeded

ਇਸ ਕਰਕੇ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਲੌਗ ਸਟੋਰੇਜ਼ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਰਾਜਨੀਤੀ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ। before-hook-creation.

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

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

ਅੰਤ ਵਿੱਚ, ਸਾਨੂੰ ਇਹ ਨਹੀਂ ਭੁੱਲਣਾ ਚਾਹੀਦਾ ਕਿਸੇ ਵੀ ਉਪ-ਪ੍ਰਣਾਲੀ ਦੀ ਸਹੀ ਢੰਗ ਨਾਲ ਨਿਗਰਾਨੀ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ. ਨਹੀਂ ਤਾਂ, ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਚੱਲਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਪ੍ਰਵਾਹ ਇੱਕ ਰਾਜ ਵਿੱਚ ਹੁੰਦਾ ਹੈ CrashLoopBackOff ਅਤੇ ਕੁਝ ਵੀ ਨਹੀਂ ਭੇਜਦਾ, ਅਤੇ ਇਹ ਮਹੱਤਵਪੂਰਣ ਜਾਣਕਾਰੀ ਦੇ ਨੁਕਸਾਨ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੈ।

ਸਿੱਟਾ

ਇਸ ਲੇਖ ਵਿੱਚ, ਅਸੀਂ Datadog ਵਰਗੇ SaaS ਹੱਲਾਂ ਨੂੰ ਨਹੀਂ ਦੇਖ ਰਹੇ ਹਾਂ। ਇੱਥੇ ਦੱਸੀਆਂ ਗਈਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਲੌਗ ਇਕੱਠੇ ਕਰਨ ਵਿੱਚ ਮਾਹਰ ਵਪਾਰਕ ਕੰਪਨੀਆਂ ਦੁਆਰਾ ਕਿਸੇ ਨਾ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ ਹਰ ਕੋਈ ਵੱਖ-ਵੱਖ ਕਾਰਨਾਂ ਕਰਕੇ SaaS ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। (ਮੁੱਖ ਕੀਮਤ ਹਨ ਅਤੇ 152-FZ ਦੀ ਪਾਲਣਾ).

ਕੇਂਦਰੀਕ੍ਰਿਤ ਲੌਗ ਸੰਗ੍ਰਹਿ ਪਹਿਲਾਂ ਇੱਕ ਸਧਾਰਨ ਕੰਮ ਵਾਂਗ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਬਿਲਕੁਲ ਨਹੀਂ ਹੈ। ਇਹ ਯਾਦ ਰੱਖਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ:

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

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

PS

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

• «ਲੌਗਹਾਊਸ ਪੇਸ਼ ਕਰ ਰਿਹਾ ਹਾਂ - ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਲੌਗਸ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਇੱਕ ਓਪਨ ਸੋਰਸ ਸਿਸਟਮ";
• «KubeCon'19 ਤੋਂ ਕੁਬਰਨੇਟਸ ਈਕੋਸਿਸਟਮ ਲਈ ਰਿਲੀਜ਼: JFrog ਕੰਟੇਨਰ ਰਜਿਸਟਰੀ, IBM ਤੋਂ Kui, Loki 1.0.0…";
• «ਨਿਗਰਾਨੀ ਅਤੇ ਕੁਬਰਨੇਟਸ (ਸਮੀਖਿਆ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)".

ਸਰੋਤ: www.habr.com