ਯੂਰੀ ਬੁਸ਼ਮੇਲੇਵ "ਲੌਗ ਇਕੱਠੇ ਕਰਨ ਅਤੇ ਡਿਲੀਵਰ ਕਰਨ ਦੇ ਖੇਤਰ ਵਿੱਚ ਇੱਕ ਰੈਕ ਦਾ ਨਕਸ਼ਾ" - ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ

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

• ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਲੌਗ ਕਿਵੇਂ ਲਿਖਣੇ ਹਨ;
• ਲੌਗ ਕਿੱਥੇ ਲਿਖਣੇ ਹਨ;
• ਸਟੋਰੇਜ ਅਤੇ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਲੌਗਸ ਨੂੰ ਕਿਵੇਂ ਡਿਲੀਵਰ ਕਰਨਾ ਹੈ;
• ਲਾਗਾਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰੋਸੈਸ ਕਰਨਾ ਅਤੇ ਸਟੋਰ ਕਰਨਾ ਹੈ।

ਵਰਤਮਾਨ ਵਿੱਚ ਪ੍ਰਸਿੱਧ ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਵਰਤੋਂ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਵਿਕਲਪਾਂ ਦੇ ਖੇਤਰ ਵਿੱਚ ਰੇਕ ਦੇ ਸਿਖਰ 'ਤੇ ਰੇਤ ਨੂੰ ਜੋੜਦੀ ਹੈ।

ਇਸ ਬਾਰੇ ਯੂਰੀ ਬੁਸ਼ਮੇਲੇਵ ਦੁਆਰਾ ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ ਹੈ "ਲੌਗ ਇਕੱਠੇ ਕਰਨ ਅਤੇ ਡਿਲੀਵਰ ਕਰਨ ਦੇ ਖੇਤਰ ਵਿੱਚ ਇੱਕ ਰੇਕ ਦਾ ਨਕਸ਼ਾ"

ਕੌਣ ਪਰਵਾਹ ਕਰਦਾ ਹੈ, ਕਿਰਪਾ ਕਰਕੇ ਬਿੱਲੀ ਦੇ ਹੇਠਾਂ.

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

ਅਸੀਂ ਕਿੱਥੋਂ ਦੇ ਹਾਂ? ਅਸੀਂ ਕੌਣ ਹਾਂ? ਲਾਜ਼ਾਦਾ ਦੱਖਣ-ਪੂਰਬੀ ਏਸ਼ੀਆ ਦੇ ਛੇ ਦੇਸ਼ਾਂ ਵਿੱਚ #1 ਆਨਲਾਈਨ ਰਿਟੇਲਰ ਹੈ। ਇਹ ਸਾਰੇ ਦੇਸ਼ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਵੰਡੇ ਗਏ ਹਨ। ਹੁਣ ਕੁੱਲ 4 ਡਾਟਾ ਸੈਂਟਰ ਹਨ। ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ? ਕਿਉਂਕਿ ਕੁਝ ਫੈਸਲੇ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਸਨ ਕਿ ਕੇਂਦਰਾਂ ਵਿਚਕਾਰ ਬਹੁਤ ਕਮਜ਼ੋਰ ਸਬੰਧ ਹੈ। ਸਾਡੇ ਕੋਲ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਹੈ। ਮੈਨੂੰ ਇਹ ਜਾਣ ਕੇ ਹੈਰਾਨੀ ਹੋਈ ਕਿ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ 80 ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਹਨ। ਜਦੋਂ ਮੈਂ ਲੌਗਸ ਨਾਲ ਕੰਮ ਸ਼ੁਰੂ ਕੀਤਾ, ਤਾਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ 20 ਸਨ। ਨਾਲ ਹੀ, ਇੱਥੇ PHP ਵਿਰਾਸਤ ਦਾ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਹਿੱਸਾ ਹੈ, ਜਿਸ ਨਾਲ ਮੈਨੂੰ ਵੀ ਰਹਿਣਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਸੰਭਾਲਣਾ ਹੈ। ਇਹ ਸਭ ਸਾਡੇ ਲਈ ਇਸ ਸਮੇਂ ਪੂਰੇ ਸਿਸਟਮ ਲਈ ਪ੍ਰਤੀ ਮਿੰਟ 6 ਮਿਲੀਅਨ ਤੋਂ ਵੱਧ ਸੁਨੇਹੇ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਅੱਗੇ ਮੈਂ ਦਿਖਾਵਾਂਗਾ ਕਿ ਅਸੀਂ ਇਸ ਨਾਲ ਕਿਵੇਂ ਜੀਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ, ਅਤੇ ਅਜਿਹਾ ਕਿਉਂ ਹੈ।

ਤੁਹਾਨੂੰ ਇਨ੍ਹਾਂ 6 ਮਿਲੀਅਨ ਸੰਦੇਸ਼ਾਂ ਨਾਲ ਕਿਸੇ ਨਾ ਕਿਸੇ ਤਰ੍ਹਾਂ ਰਹਿਣਾ ਪਏਗਾ। ਸਾਨੂੰ ਉਨ੍ਹਾਂ ਨਾਲ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ? 6 ਮਿਲੀਅਨ ਸੰਦੇਸ਼ਾਂ ਦੀ ਲੋੜ ਹੈ:

• ਐਪ ਤੋਂ ਭੇਜੋ
• ਡਿਲੀਵਰੀ ਲਈ ਸਵੀਕਾਰ ਕਰੋ
• ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਸਟੋਰੇਜ ਲਈ ਪ੍ਰਦਾਨ ਕਰੋ.
• ਵਿਸ਼ਲੇਸ਼ਣ
• ਕਿਸੇ ਤਰ੍ਹਾਂ ਸਟੋਰ ਕਰੋ।

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

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

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

ਲਾਗਾਂ ਦੇ ਸੰਗ੍ਰਹਿ ਦੇ ਨਾਲ, ਸਥਿਤੀ ਲਗਭਗ ਇੱਕੋ ਜਿਹੀ ਹੈ. ਇਸ ਖਾਸ ਹਿੱਸੇ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪ ਨਹੀਂ ਹਨ. ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹੋਰ ਵੀ ਹਨ, ਪਰ ਅਜੇ ਤੱਕ ਇੰਨੇ ਨਹੀਂ ਹਨ।

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

ਮੈਂ ਤੁਹਾਨੂੰ ਦਿਖਾਵਾਂਗਾ ਕਿ ਅਸੀਂ ਇਹ ਲਾਜ਼ਾਦਾ ਵਿਖੇ ਕਿਵੇਂ ਕੀਤਾ ਅਤੇ ਇਹ ਸਭ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੋਇਆ।

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

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

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

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

ਇੱਥੇ (1,2,3) ਅਸੀਂ ਫਾਈਲਾਂ ਲਿਖਦੇ ਹਾਂ ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਇੱਥੇ ਇੱਕ ਵਾਰ ਵਿੱਚ ਤਿੰਨ ਰੈਕ ਹਨ।

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

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

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

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

ਅਸੀਂ ਇਹ ਸਵਾਲ ਪੁੱਛਣੇ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੇ। ਅਸੀਂ ਦੋਸ਼ੀਆਂ ਦੀ ਭਾਲ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ।

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

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

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

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

ਪ੍ਰਵਾਹ. ਪਹਿਲਾਂ, ਮੈਂ ਉਸ ਨੂੰ ਪਿਛਲੀ ਨੌਕਰੀ 'ਤੇ ਮਿਲਿਆ, ਅਤੇ ਉਹ ਵੀ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਉਥੇ ਡਿੱਗ ਪਿਆ. ਦੂਜਾ, ਇਹ ਉਹੀ ਹੈ, ਸਿਰਫ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ.

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

sysadmin ਲਈ ਸਪੱਸ਼ਟ ਹੱਲ ਇਸ ਮਾਤਰਾ ਵਿੱਚ ਸਾਰੇ ਕਿਸਮ ਦੇ syslogs ਹਨ (syslog-ng/rsyslog/nxlog)।

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

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

ਅਤੇ rsyslog ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ. ਪਹਿਲਾਂ, ਇਹ ਠੰਡਾ ਹੈ ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਮੋਡੀਊਲ ਹਨ। ਇਸ ਵਿੱਚ ਮਨੁੱਖੀ-ਪੜ੍ਹਨਯੋਗ ਰੇਨਰ ਸਕ੍ਰਿਪਟ (ਆਧੁਨਿਕ ਸੰਰਚਨਾ ਭਾਸ਼ਾ) ਹੈ। ਇੱਕ ਸ਼ਾਨਦਾਰ ਬੋਨਸ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਟੀਡੀ-ਏਜੰਟ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਇਸਦੇ ਮਿਆਰੀ ਸਾਧਨਾਂ ਨਾਲ ਨਕਲ ਕਰ ਸਕਦੇ ਹਾਂ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਕੁਝ ਵੀ ਨਹੀਂ ਬਦਲਿਆ ਹੈ। ਭਾਵ, ਅਸੀਂ td-agent ਨੂੰ rsyslog ਵਿੱਚ ਬਦਲਦੇ ਹਾਂ, ਅਤੇ ਬਾਕੀ ਸਭ ਕੁਝ ਅਜੇ ਤੱਕ ਨਹੀਂ ਛੂਹਦੇ ਹਾਂ। ਅਤੇ ਤੁਰੰਤ ਸਾਨੂੰ ਇੱਕ ਕਾਰਜਕਾਰੀ ਡਿਲੀਵਰੀ ਮਿਲਦੀ ਹੈ. ਅੱਗੇ, mmnormalize rsyslog ਬਾਰੇ ਵਧੀਆ ਚੀਜ਼ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਲੌਗ ਪਾਰਸ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਪਰ Grok ਅਤੇ regexp ਨਾਲ ਨਹੀਂ। ਇਹ ਇੱਕ ਐਬਸਟਰੈਕਟ ਸਿੰਟੈਕਸ ਟ੍ਰੀ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਲੌਗਸ ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਪਾਰਸ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਇੱਕ ਕੰਪਾਈਲਰ ਸਰੋਤ ਕੋਡ ਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ, ਥੋੜਾ ਜਿਹਾ CPU ਖਾਣ, ਅਤੇ, ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਬਹੁਤ ਵਧੀਆ ਚੀਜ਼ ਹੈ. ਹੋਰ ਬੋਨਸ ਦਾ ਇੱਕ ਝੁੰਡ ਹਨ. ਮੈਂ ਉਨ੍ਹਾਂ ਉੱਤੇ ਨਹੀਂ ਵਸਾਂਗਾ।

rsyslog ਦੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਹਨ। ਉਹ ਬੋਨਸ ਦੇ ਸਮਾਨ ਹਨ. ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਇਹ ਹਨ ਕਿ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਪਕਾਉਣ ਦੇ ਯੋਗ ਹੋਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਸੰਸਕਰਣ ਚੁਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.

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

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

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

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

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

ਸਮੱਸਿਆਵਾਂ ਕੀ ਹਨ? ਸਮੱਸਿਆ ਇਸ ਤੱਥ ਦੇ ਨਾਲ ਪੈਦਾ ਹੋਈ ਕਿ ਸਾਨੂੰ ਪਤਾ ਲੱਗਾ (ਅਚਾਨਕ!) ਕਿ ਸਾਡੇ ਲਾਈਵ API ਪ੍ਰਤੀ ਸਕਿੰਟ 50k ਸੁਨੇਹੇ ਲਿਖਦੇ ਹਨ। ਇਹ ਸਟੇਜਿੰਗ ਤੋਂ ਬਿਨਾਂ ਸਿਰਫ਼ ਲਾਈਵ API ਹੈ। ਅਤੇ ਗ੍ਰੇਲੌਗ ਸਾਨੂੰ ਸਿਰਫ 12 ਹਜ਼ਾਰ ਸੰਦੇਸ਼ ਪ੍ਰਤੀ ਸਕਿੰਟ ਦਿਖਾਉਂਦਾ ਹੈ। ਅਤੇ ਇੱਕ ਵਾਜਬ ਸਵਾਲ ਉੱਠਿਆ, ਬਚੇ ਹੋਏ ਕਿੱਥੇ ਹਨ? ਜਿਸ ਤੋਂ ਅਸੀਂ ਇਹ ਸਿੱਟਾ ਕੱਢਿਆ ਹੈ ਕਿ ਗ੍ਰੇਲੌਗ ਬਸ ਇਸਦਾ ਮੁਕਾਬਲਾ ਨਹੀਂ ਕਰ ਸਕਦਾ. ਅਸੀਂ ਦੇਖਿਆ, ਅਤੇ, ਅਸਲ ਵਿੱਚ, Elasticsearch ਨਾਲ ਗ੍ਰੇਲੌਗ ਨੇ ਇਸ ਪ੍ਰਵਾਹ ਵਿੱਚ ਮੁਹਾਰਤ ਹਾਸਲ ਨਹੀਂ ਕੀਤੀ।

ਅੱਗੇ, ਹੋਰ ਖੋਜਾਂ ਜੋ ਅਸੀਂ ਰਸਤੇ ਵਿੱਚ ਕੀਤੀਆਂ ਹਨ।

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

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

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

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

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

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

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

ਨਵੇਂ ਗ੍ਰੇਲੌਗ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਕੀ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ। ਅਸੀਂ ਸਿਰਫ ਡੌਕਰ ਵਿੱਚ ਸਭ ਕੁਝ ਲਿਖਿਆ ਹੈ। ਅਸੀਂ ਸਰਵਰਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਲਿਆ, ਤਿੰਨ ਕਾਫਕਾ ਉਦਾਹਰਨਾਂ, 7 ਗ੍ਰੇਲੌਗ ਸਰਵਰ ਸੰਸਕਰਣ 2.3 (ਕਿਉਂਕਿ ਮੈਂ Elasticsearch ਸੰਸਕਰਣ 5 ਚਾਹੁੰਦਾ ਸੀ) ਨੂੰ ਰੋਲ ਆਊਟ ਕੀਤਾ। ਇਹ ਸਭ ਕੁਝ ਐਚਡੀਡੀ ਤੋਂ ਛਾਪੇਮਾਰੀ 'ਤੇ ਉਠਾਇਆ ਗਿਆ ਸੀ. ਅਸੀਂ ਪ੍ਰਤੀ ਸਕਿੰਟ 100 ਹਜ਼ਾਰ ਸੰਦੇਸ਼ਾਂ ਦੀ ਇੰਡੈਕਸਿੰਗ ਦਰ ਦੇਖੀ। ਅਸੀਂ ਇਹ ਅੰਕੜਾ ਦੇਖਿਆ ਕਿ ਪ੍ਰਤੀ ਹਫ਼ਤੇ 140 ਟੈਰਾਬਾਈਟ ਡਾਟਾ।

ਅਤੇ ਦੁਬਾਰਾ ਇੱਕ ਰੈਕ! ਸਾਡੇ ਕੋਲ ਦੋ ਵਿਕਰੀਆਂ ਆ ਰਹੀਆਂ ਹਨ। ਅਸੀਂ 6 ਮਿਲੀਅਨ ਪੋਸਟਾਂ ਤੋਂ ਅੱਗੇ ਚਲੇ ਗਏ ਹਾਂ। ਸਾਡੇ ਕੋਲ ਗ੍ਰੇਲੋਗ ਨੂੰ ਚਬਾਉਣ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੈ। ਕਿਸੇ ਤਰ੍ਹਾਂ ਤੁਹਾਨੂੰ ਦੁਬਾਰਾ ਬਚਣਾ ਪਏਗਾ.

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

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

ਗ੍ਰੇਲੌਗ ਤੋਂ ਮੈਟ੍ਰਿਕਸ ਇਕੱਠੇ ਕਰੋ।

ਇੱਕ ਦਰ ਸੀਮਾ ਬਣਾਓ ਤਾਂ ਜੋ ਸਾਡੇ ਕੋਲ ਇੱਕ ਪਾਗਲ API ਹੈ ਜੋ ਸਾਨੂੰ ਬੈਂਡਵਿਡਥ ਅਤੇ ਹੋਰ ਸਭ ਕੁਝ ਨਹੀਂ ਮਾਰਦਾ.

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

ਅਤੇ ਦਸਤਾਵੇਜ਼ ਲਿਖੋ.

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

ਤੁਹਾਡੇ ਸਵਾਲ.

ਸਵਾਲ: ਉਨ੍ਹਾਂ ਨੇ ਨਾ ਲੈਣ ਦਾ ਫੈਸਲਾ ਕਿਉਂ ਕੀਤਾ ... (ਫਾਈਲਬੀਟ?)

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

ਸਵਾਲ: ਤੁਸੀਂ ਸਿਰਫ਼ HDFS ਨੂੰ ਲੌਗ ਕਿਉਂ ਨਹੀਂ ਲਿਖਦੇ?

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

ਸਵਾਲ: ਇੱਕ ਕਾਲਮ ਫਾਰਮੈਟ ਵਧੇਰੇ ਉਚਿਤ ਹੋਵੇਗਾ।

ਜਵਾਬ ਦਿਉ: ਮੈਂ ਸੱਮਝਦਾ ਹਾਂ. ਅਸੀਂ ਦੋਵੇਂ ਹੱਥਾਂ ਨਾਲ "ਲਈ" ਹਾਂ।

ਸਵਾਲ: ਤੁਸੀਂ rsyslog ਨੂੰ ਲਿਖਦੇ ਹੋ। TCP ਅਤੇ UDP ਦੋਵੇਂ ਉੱਥੇ ਉਪਲਬਧ ਹਨ। ਪਰ ਜੇਕਰ UDP, ਤਾਂ ਤੁਸੀਂ ਡਿਲੀਵਰੀ ਦੀ ਗਾਰੰਟੀ ਕਿਵੇਂ ਦਿੰਦੇ ਹੋ?

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

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

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

ਸਵਾਲ: ਟਾਈਮਸਟੈਂਪ ਮਿਲੀਸਕਿੰਟ ਦੁਆਰਾ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦਾ ਹੈ।

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

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

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

ਸਵਾਲ: ਕੀ ਤੁਹਾਨੂੰ ਅਸਧਾਰਨ ਸਥਿਤੀਆਂ ਦੌਰਾਨ ਉਥੋਂ ਲੌਗ ਪ੍ਰਾਪਤ ਹੁੰਦੇ ਹਨ?

ਜਵਾਬ ਦਿਉ: ਤੁਸੀਂ ਉੱਥੇ ਜਾ ਸਕਦੇ ਹੋ (ਫਾਈਲ ਸਟੋਰੇਜ ਵਿੱਚ) ਅਤੇ ਦੇਖ ਸਕਦੇ ਹੋ।

ਸਵਾਲ: ਤੁਸੀਂ ਕਿਵੇਂ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਲੌਗ ਨਹੀਂ ਗੁਆਉਂਦੇ?

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

ਸਵਾਲ: elasticsearch ਵਿੱਚ, ਤੁਸੀਂ ਰਿਡੰਡੈਂਸੀ ਨਾਲ ਲੌਗ ਸਟੋਰ ਕਰਦੇ ਹੋ। ਤੁਹਾਡੇ ਕੋਲ ਕਿੰਨੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਹਨ?

ਜਵਾਬ ਦਿਉ: ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ।

ਸਵਾਲ: ਕੀ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਲਾਈਨ ਹੈ?

ਜਵਾਬ ਦਿਉ: ਇਹ ਮਾਸਟਰ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੈ. ਡੇਟਾ ਡੁਪਲੀਕੇਟ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ.

ਸਵਾਲ: ਕੀ ਤੁਸੀਂ ਕਿਸੇ ਤਰ੍ਹਾਂ rsyslog ਬਫਰ ਦੇ ਆਕਾਰ ਨੂੰ ਬਦਲਿਆ ਹੈ?

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

ਸਵਾਲ: ਕੀ ਤੁਸੀਂ ਟੁੱਟੇ ਹੋਏ JSON ਲਿਖਦੇ ਹੋ?

ਜਵਾਬ ਦਿਉ: ਟੁੱਟੇ ਹੋਏ JSON ਨੂੰ ਜਾਂ ਤਾਂ ਰੀਲੇਅ ਦੌਰਾਨ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ ਕਿਉਂਕਿ ਪੈਕੇਟ ਬਹੁਤ ਵੱਡਾ ਹੈ। ਜਾਂ ਗ੍ਰੇਲੌਗ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਜਾਵੇਗਾ, ਕਿਉਂਕਿ ਇਹ JSON ਨੂੰ ਪਾਰਸ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ। ਪਰ ਇੱਥੇ ਕੁਝ ਸੂਖਮਤਾਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਉਹ ਜ਼ਿਆਦਾਤਰ rsyslog ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ। ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਉੱਥੇ ਕੁਝ ਅੰਕ ਭਰ ਦਿੱਤੇ ਹਨ, ਜਿਨ੍ਹਾਂ 'ਤੇ ਅਜੇ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਸਵਾਲ: ਕਾਫਕਾ ਕਿਉਂ? ਕੀ ਤੁਸੀਂ RabbitMQ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੈ? ਗ੍ਰੇਲੌਗ ਅਜਿਹੇ ਲੋਡਾਂ ਦੇ ਹੇਠਾਂ ਨਹੀਂ ਜੋੜਦਾ ਹੈ?

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

ਕਾਫਕਾ ਬਾਰੇ ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ ਅਜਿਹਾ ਹੀ ਹੋਇਆ ਹੈ। ਜਦੋਂ ਮੈਂ ਪਹੁੰਚਿਆ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਉੱਥੇ ਸੀ, ਅਤੇ ਇਸ ਉੱਤੇ ਪਹਿਲਾਂ ਹੀ ਲੌਗ ਲਿਖੇ ਜਾ ਰਹੇ ਸਨ। ਅਸੀਂ ਹੁਣੇ ਆਪਣੇ ਕਲੱਸਟਰ ਨੂੰ ਵਧਾਇਆ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਲੌਗਸ ਨੂੰ ਮੂਵ ਕੀਤਾ ਹੈ। ਅਸੀਂ ਉਸਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਉਹ ਕਿਵੇਂ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ. RabbitMQ ਲਈ... ਸਾਨੂੰ RabbitMQ ਨਾਲ ਸਮੱਸਿਆ ਆ ਰਹੀ ਹੈ। ਅਤੇ RabbitMQ ਸਾਡੇ ਲਈ ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ। ਸਾਡੇ ਕੋਲ ਇਹ ਉਤਪਾਦਨ ਵਿੱਚ ਹੈ, ਅਤੇ ਇਸਦੇ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਸਨ. ਹੁਣ, ਵਿਕਰੀ ਤੋਂ ਪਹਿਲਾਂ, ਉਸ ਨੂੰ ਸ਼ਰਮਨਾਕ ਕੀਤਾ ਜਾਵੇਗਾ, ਅਤੇ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦੇਵੇਗਾ. ਪਰ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਮੈਂ ਇਸਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਰਿਲੀਜ਼ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਸੀ। ਇੱਕ ਗੱਲ ਹੋਰ ਹੈ। ਗ੍ਰੇਲੌਗ AMQP 0.9 ਸੰਸਕਰਣ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਅਤੇ rsyslog AMQP 1.0 ਸੰਸਕਰਣ ਲਿਖ ਸਕਦਾ ਹੈ। ਅਤੇ ਇੱਥੇ ਇੱਕ ਵੀ ਹੱਲ ਨਹੀਂ ਹੈ ਜੋ ਮੱਧ ਵਿੱਚ ਦੋਵਾਂ ਨੂੰ ਕਰ ਸਕਦਾ ਹੈ. ਕੋਈ ਇੱਕ ਜਾਂ ਦੂਜਾ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ ਹੁਣ ਲਈ ਸਿਰਫ ਕਾਫਕਾ। ਪਰ ਸੂਖਮਤਾ ਵੀ ਹਨ. ਕਿਉਂਕਿ rsyslog ਦੇ ਸੰਸਕਰਣ ਦਾ omkafka ਜੋ ਅਸੀਂ ਵਰਤਦੇ ਹਾਂ ਉਹ ਸਾਰਾ ਸੁਨੇਹਾ ਬਫਰ ਗੁਆ ਸਕਦਾ ਹੈ ਜੋ ਇਹ rsyslog ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਜਿੰਨਾ ਚਿਰ ਅਸੀਂ ਇਸ ਨੂੰ ਸਹਿਣ ਕਰਦੇ ਹਾਂ.

ਸਵਾਲ: ਕੀ ਤੁਸੀਂ ਕਾਫਕਾ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕੋਲ ਸੀ? ਕਿਸੇ ਹੋਰ ਮਕਸਦ ਲਈ ਨਹੀਂ ਵਰਤਿਆ ਜਾਂਦਾ?

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

ਸਵਾਲ: ਸਾਨੂੰ ਸਾਕਟਾਂ ਨਾਲ ਇਸ ਸ਼ਮਨਵਾਦ ਦੀ ਕਿਉਂ ਲੋੜ ਹੈ? ਕੀ ਤੁਸੀਂ ਕੰਟੇਨਰਾਂ ਲਈ syslog ਲੌਗ ਡਰਾਈਵਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੈ।

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

ਸਵਾਲ: ਤੁਸੀਂ rsyslog ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿਚਕਾਰ ਡਿਲੀਵਰ ਕਰਦੇ ਹੋ। ਕਾਫਕਾ 'ਤੇ ਕਿਉਂ ਨਹੀਂ?

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

ਸਰੋਤ: www.habr.com