ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਪ੍ਰਾਈਵੇਟ ਕਲਾਉਡ ਨਿਗਰਾਨੀ. ਪਾਵੇਲ ਕੋਲੋਬਾਏਵ

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

ਮੇਰਾ ਨਾਮ ਕੋਲੋਬਾਏਵ ਪਾਵੇਲ ਹੈ। DevOps, SRE, LeroyMerlin, ਸਭ ਕੁਝ ਕੋਡ ਵਾਂਗ ਹੈ - ਇਹ ਸਭ ਸਾਡੇ ਬਾਰੇ ਹੈ: ਮੇਰੇ ਬਾਰੇ ਅਤੇ ਹੋਰ LeroyMerlin ਕਰਮਚਾਰੀਆਂ ਬਾਰੇ।

https://bit.ly/3jf1fIK

ਓਪਨਸਟੈਕ 'ਤੇ ਅਧਾਰਤ ਇੱਕ ਕਲਾਉਡ ਹੈ. ਤਕਨੀਕੀ ਰਾਡਾਰ ਲਈ ਇੱਕ ਛੋਟਾ ਲਿੰਕ ਹੈ.

ਇਹ ਕੁਬਰਨੇਟਸ ਹਾਰਡਵੇਅਰ ਦੇ ਨਾਲ-ਨਾਲ ਓਪਨਸਟੈਕ ਅਤੇ ਲੌਗਿੰਗ ਲਈ ਸਾਰੀਆਂ ਸੰਬੰਧਿਤ ਸੇਵਾਵਾਂ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਹੈ।

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

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

ਪਹਿਲਾ ਹੱਲ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਫੈਡਰੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਤੀਜੀ-ਧਿਰ ਪ੍ਰੋਮੀਥੀਅਸ ਹੁੰਦੀ ਹੈ, ਜਦੋਂ ਅਸੀਂ ਫੈਡਰੇਸ਼ਨ ਵਿਧੀ ਰਾਹੀਂ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਜਾਂਦੇ ਹਾਂ।

ਪਰ ਇੱਥੇ ਕੁਝ ਛੋਟੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ. ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਸਮੱਸਿਆਵਾਂ ਉਦੋਂ ਸ਼ੁਰੂ ਹੋਈਆਂ ਜਦੋਂ ਸਾਡੇ ਕੋਲ 250 ਮੈਟ੍ਰਿਕਸ ਸਨ, ਅਤੇ ਜਦੋਂ 000 ਮੈਟ੍ਰਿਕਸ ਸਨ, ਸਾਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਅਸੀਂ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਅਸੀਂ scrape_timeout ਨੂੰ 400 ਸਕਿੰਟਾਂ ਤੱਕ ਵਧਾ ਦਿੱਤਾ ਹੈ।

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

ਹਰ ਕੋਈ ਉਹਨਾਂ ਗ੍ਰਾਫਾਂ ਤੋਂ ਜਾਣੂ ਹੈ ਜੋ ਸਾਨੂੰ ਪ੍ਰਾਪਤ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਕੁਝ ਡੇਟਾ ਗੁੰਮ ਹੁੰਦਾ ਹੈ। ਸਮਾਂ-ਸਾਰਣੀ ਫਟ ਗਈ ਹੈ ਅਤੇ ਅਸੀਂ ਇਸ ਤੋਂ ਖੁਸ਼ ਨਹੀਂ ਹਾਂ।

ਅਗਲਾ ਵਿਕਲਪ ਇੱਕੋ ਸੰਘੀ ਵਿਧੀ ਰਾਹੀਂ ਦੋ ਵੱਖ-ਵੱਖ ਪ੍ਰੋਮੀਥੀਅਸ 'ਤੇ ਅਧਾਰਤ ਸ਼ਾਰਡਿੰਗ ਹੈ।

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

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

ਪਹਿਲਾ ਵਿਕਲਪ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਫੈਡਰੇਸ਼ਨ ਦੀ ਵਿਧੀ ਨੂੰ ਛੱਡਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿਉਂਕਿ ਇਹ ਬਹੁਤ ਹੌਲੀ ਹੈ।

ਪ੍ਰੋਮੀਥੀਅਸ ਡਿਵੈਲਪਰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕਹਿ ਰਹੇ ਹਨ, "ਮੁੰਡੇ, ਇੱਕ ਵੱਖਰੇ TimescaleDB ਦੀ ਵਰਤੋਂ ਕਰੋ ਕਿਉਂਕਿ ਅਸੀਂ ਮੈਟ੍ਰਿਕਸ ਦੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਸਟੋਰੇਜ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਾਂਗੇ।" ਇਹ ਉਨ੍ਹਾਂ ਦਾ ਕੰਮ ਨਹੀਂ ਹੈ।

ਅਸੀਂ ਕਾਗਜ਼ ਦੇ ਇੱਕ ਟੁਕੜੇ 'ਤੇ ਲਿਖਦੇ ਹਾਂ ਕਿ ਸਾਨੂੰ ਅਜੇ ਵੀ ਬਾਹਰੋਂ ਅਨਲੋਡ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਜੋ ਹਰ ਚੀਜ਼ ਨੂੰ ਇੱਕ ਥਾਂ 'ਤੇ ਸਟੋਰ ਨਾ ਕੀਤਾ ਜਾ ਸਕੇ।

ਦੂਜੀ ਕਮੀ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਹੈ. ਹਾਂ, ਮੈਂ ਸਮਝਦਾ ਹਾਂ ਕਿ ਬਹੁਤ ਸਾਰੇ ਕਹਿਣਗੇ ਕਿ 2020 ਵਿੱਚ ਕੁਝ ਗੀਗਾਬਾਈਟ ਮੈਮੋਰੀ ਇੱਕ ਪੈਸਾ ਖਰਚ ਕਰਦੀ ਹੈ, ਪਰ ਫਿਰ ਵੀ.

ਹੁਣ ਸਾਡੇ ਕੋਲ ਇੱਕ ਦੇਵ ਅਤੇ ਉਤਪਾਦ ਵਾਤਾਵਰਣ ਹੈ। dev ਵਿੱਚ ਇਹ 9 ਮੀਟ੍ਰਿਕਸ ਲਈ ਲਗਭਗ 350 ਗੀਗਾਬਾਈਟ ਹੈ। ਉਤਪਾਦ ਵਿੱਚ ਇਹ 000 ਗੀਗਾਬਾਈਟ ਅਤੇ 14 ਮੀਟ੍ਰਿਕਸ ਤੋਂ ਥੋੜ੍ਹਾ ਵੱਧ ਹੈ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਸਾਡੀ ਧਾਰਨ ਦਾ ਸਮਾਂ ਸਿਰਫ 780 ਮਿੰਟ ਹੈ। ਇਹ ਬੁਰਾ ਹੈ। ਅਤੇ ਹੁਣ ਮੈਂ ਦੱਸਾਂਗਾ ਕਿ ਕਿਉਂ.

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

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

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

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

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

ਇਹ ਇਕ ਹੋਰ ਕਾਰਨ ਹੈ ਕਿ ਪ੍ਰੋਮੀਥੀਅਸ ਸਾਡੇ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ, ਭਾਵ ਅਸੀਂ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਨੂੰ ਸੀਮਤ ਨਹੀਂ ਕਰ ਸਕਦੇ।

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

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

ਕ੍ਰਮ ਵਿੱਚ ਨੁਕਸਾਨ ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਲਈ ਲਿਖਿਆ ਹੈ:

• ਬਾਹਰੀ ਤੌਰ 'ਤੇ ਮੈਟ੍ਰਿਕਸ ਅੱਪਲੋਡ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
• ਉੱਚ ਸਰੋਤ ਦੀ ਖਪਤ.
• ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ.
• HA ਦਾ ਗੁੰਝਲਦਾਰ ਅਤੇ ਸੰਸਾਧਨ-ਗੰਭੀਰ ਅਮਲ।

ਆਪਣੇ ਲਈ, ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਕਿ ਅਸੀਂ ਸਟੋਰੇਜ ਸਹੂਲਤ ਵਜੋਂ ਪ੍ਰੋਮੀਥੀਅਸ ਤੋਂ ਦੂਰ ਜਾ ਰਹੇ ਹਾਂ।

ਅਸੀਂ ਆਪਣੇ ਲਈ ਵਾਧੂ ਲੋੜਾਂ ਦੀ ਪਛਾਣ ਕੀਤੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਸਾਨੂੰ ਲੋੜ ਹੈ। ਇਹ:

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

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

ਕਿਉਂ? ਕਿਉਂਕਿ:

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

ਆਓ ਪਹਿਲੀ ਤੁਲਨਾ ਕਰੀਏ। ਅਸੀਂ ਉਸੇ ਪ੍ਰੋਮੀਥੀਅਸ ਨੂੰ ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਲੈਂਦੇ ਹਾਂ, ਬਾਹਰੀ ਪ੍ਰੋਮੀਥੀਅਸ ਇਸ ਵੱਲ ਜਾਂਦਾ ਹੈ। ਰਿਮੋਟ ਰਾਈਟ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਰਾਹੀਂ ਸ਼ਾਮਲ ਕਰੋ।

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

ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਪ੍ਰੋਮੀਥੀਅਸ ਦੀ ਮੈਮੋਰੀ ਖਪਤ, ਜੋ ਕਿ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਸਥਿਤ ਹੈ, ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਵਾਧਾ ਨਹੀਂ ਹੋਇਆ।

ਅਸੀਂ ਇੱਕੋ ਡੇਟਾ ਦੇ ਦੋ ਡੇਟਾ ਸਰੋਤਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹਾਂ। ਪ੍ਰੋਮੀਥੀਅਸ ਵਿੱਚ ਅਸੀਂ ਉਹੀ ਗੁੰਮ ਡੇਟਾ ਦੇਖਦੇ ਹਾਂ। ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਸਭ ਕੁਝ ਠੀਕ ਹੈ।

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

ਅਸੀਂ ਮੈਮੋਰੀ ਸਰੋਤ ਦੀ ਖਪਤ 'ਤੇ ਵੀ ਬਚਤ ਕਰਦੇ ਹਾਂ। ਟੈਸਟਿੰਗ ਦੇ ਸਮੇਂ, ਅਸੀਂ ਪ੍ਰੋਮੀਥੀਅਸ ਨੂੰ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ - 8 ਕੋਰ, 24 ਗੀਗਾਬਾਈਟ 'ਤੇ ਤਾਇਨਾਤ ਕੀਤਾ ਸੀ। ਪ੍ਰੋਮੀਥੀਅਸ ਲਗਭਗ ਹਰ ਚੀਜ਼ ਖਾਂਦਾ ਹੈ। ਉਹ ਓਓਐਮ ਕਿਲਰ 'ਤੇ ਡਿੱਗ ਪਿਆ। ਉਸੇ ਸਮੇਂ, ਇਸ ਵਿੱਚ ਸਿਰਫ 900 ਸਰਗਰਮ ਮੈਟ੍ਰਿਕਸ ਪਾਏ ਗਏ ਸਨ। ਇਹ ਲਗਭਗ 000-25 ਮੀਟ੍ਰਿਕਸ ਪ੍ਰਤੀ ਸਕਿੰਟ ਹੈ।

ਅਸੀਂ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਨੂੰ 8 ਗੀਗਾਬਾਈਟ RAM ਵਾਲੀ ਡਿਊਲ-ਕੋਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨ 'ਤੇ ਚਲਾਇਆ। ਅਸੀਂ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਨੂੰ 8GB ਮਸ਼ੀਨ 'ਤੇ ਕੁਝ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਲਈ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ। ਅੰਤ ਵਿੱਚ, ਅਸੀਂ ਇਸਨੂੰ 7 ਗੀਗਾਬਾਈਟ ਤੱਕ ਰੱਖਿਆ. ਉਸੇ ਸਮੇਂ, ਸਮੱਗਰੀ ਦੀ ਡਿਲਿਵਰੀ ਦੀ ਗਤੀ, ਅਰਥਾਤ ਮੈਟ੍ਰਿਕਸ, ਪ੍ਰੋਮੀਥੀਅਸ ਨਾਲੋਂ ਵੀ ਵੱਧ ਸੀ।

ਪ੍ਰੋਮੀਥੀਅਸ ਦੇ ਮੁਕਾਬਲੇ CPU ਬਹੁਤ ਵਧੀਆ ਹੋ ਗਿਆ ਹੈ। ਇੱਥੇ ਪ੍ਰੋਮੀਥੀਅਸ 2,5 ਕੋਰ ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਸਿਰਫ 0,25 ਕੋਰ ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ - 0,5 ਕੋਰ. ਜਿਵੇਂ ਕਿ ਇਹ ਅਭੇਦ ਹੁੰਦਾ ਹੈ, ਇਹ ਇੱਕ ਕੋਰ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਪਰ ਇਹ ਬਹੁਤ ਹੀ, ਬਹੁਤ ਦੁਰਲੱਭ ਹੈ।

ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਚੋਣ ਸਪੱਸ਼ਟ ਕਾਰਨਾਂ ਕਰਕੇ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਡਿੱਗ ਗਈ; ਅਸੀਂ ਪੈਸੇ ਬਚਾਉਣਾ ਚਾਹੁੰਦੇ ਸੀ ਅਤੇ ਅਸੀਂ ਕੀਤਾ।

ਆਓ ਤੁਰੰਤ ਦੋ ਬਿੰਦੂਆਂ ਨੂੰ ਪਾਰ ਕਰੀਏ - ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਅਪਲੋਡ ਕਰਨਾ ਅਤੇ ਸਰੋਤਾਂ ਦੀ ਉੱਚ ਖਪਤ। ਅਤੇ ਸਾਨੂੰ ਸਿਰਫ ਦੋ ਨੁਕਤੇ ਤੈਅ ਕਰਨੇ ਹਨ ਜੋ ਅਸੀਂ ਅਜੇ ਵੀ ਆਪਣੇ ਲਈ ਛੱਡੇ ਹਨ।

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

ਇੱਥੇ ਇੱਕ ਸ਼ਾਨਦਾਰ ਪੈਰਾਮੀਟਰ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਸਮੇਂ ਦੁਆਰਾ, ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਦੁਆਰਾ ਅਤੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮੇਂ ਦੁਆਰਾ ਸੀਮਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

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

ਇੱਕ ਹੋਰ ਬਿੰਦੂ ਘਟਾਓ, ਭਾਵ ਬਿੰਦੂ ਨੂੰ ਪਾਰ ਕਰੋ - ਤੁਸੀਂ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਨੂੰ ਸੀਮਤ ਨਹੀਂ ਕਰ ਸਕਦੇ।

ਪਹਿਲੇ ਦੁਹਰਾਓ ਵਿੱਚ, ਅਸੀਂ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਸਿੰਗਲ ਨੋਡ ਦੀ ਜਾਂਚ ਕੀਤੀ। ਅੱਗੇ ਅਸੀਂ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਕਲੱਸਟਰ ਸੰਸਕਰਣ ਵੱਲ ਵਧਦੇ ਹਾਂ।

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

ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਕਲੱਸਟਰ ਸੰਸਕਰਣ ਦੇ ਮੁੱਖ ਭਾਗ vmstsorage ਹਨ। ਇਹਨਾਂ ਦਾ N ਨੰਬਰ ਹੋ ਸਕਦਾ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹੁਣ ਤੱਕ 2 ਹਨ।

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

Vminsert Prometheus ਤੋਂ OpenTSDB, Graphite, InfluxDB ਅਤੇ ਰਿਮੋਟ ਰਾਈਟ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

vmselect ਵੀ ਹੈ। ਇਸਦਾ ਮੁੱਖ ਕੰਮ vmstorage 'ਤੇ ਜਾਣਾ, ਉਹਨਾਂ ਤੋਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨਾ, ਇਸ ਡੇਟਾ ਨੂੰ ਡੁਪਲੀਕੇਟ ਕਰਨਾ ਅਤੇ ਗਾਹਕ ਨੂੰ ਦੇਣਾ ਹੈ।

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

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

ਇੱਕ wmauth ਕੰਪੋਨੈਂਟ ਹੈ। ਅਸੀਂ ਕਲੱਸਟਰਾਂ ਦੇ ਮਲਟੀਟੇਨੈਂਸੀ ਸੰਸਕਰਣ ਲਈ ਇੱਕ ਅਧਿਕਾਰ ਪ੍ਰਣਾਲੀ ਦੇ ਤੌਰ 'ਤੇ ਇਸਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ ਜਾਂ ਨਹੀਂ (ਅਸੀਂ ਅਜੇ ਇਸ ਬਾਰੇ ਫੈਸਲਾ ਨਹੀਂ ਕੀਤਾ ਹੈ)। ਇਹ ਪ੍ਰੋਮੀਥੀਅਸ ਲਈ ਰਿਮੋਟ ਰਾਈਟ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਅਤੇ ਯੂਆਰਐਲ, ਜਾਂ ਇਸਦੇ ਦੂਜੇ ਹਿੱਸੇ ਦੇ ਅਧਾਰ ਤੇ ਅਧਿਕਾਰਤ ਕਰ ਸਕਦਾ ਹੈ, ਜਿੱਥੇ ਤੁਸੀਂ ਲਿਖ ਸਕਦੇ ਹੋ ਜਾਂ ਨਹੀਂ ਲਿਖ ਸਕਦੇ.

vmbackup, vmrestore ਵੀ ਹੈ। ਇਹ, ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ, ਸਾਰੇ ਡੇਟਾ ਦੀ ਬਹਾਲੀ ਅਤੇ ਬੈਕਅੱਪ ਹੈ। S3, GCS, ਫਾਈਲ ਕਰ ਸਕਦਾ ਹੈ.

ਸਾਡੇ ਕਲੱਸਟਰ ਦੀ ਪਹਿਲੀ ਦੁਹਰਾਓ ਕੁਆਰੰਟੀਨ ਦੌਰਾਨ ਕੀਤੀ ਗਈ ਸੀ। ਉਸ ਸਮੇਂ, ਇੱਥੇ ਕੋਈ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨਹੀਂ ਸੀ, ਇਸਲਈ ਸਾਡੇ ਦੁਹਰਾਓ ਵਿੱਚ ਦੋ ਵੱਖ-ਵੱਖ ਅਤੇ ਸੁਤੰਤਰ ਕਲੱਸਟਰ ਸਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਅਸੀਂ ਰਿਮੋਟ ਰਾਈਟ ਦੁਆਰਾ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਸੀ।

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

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

ਪੂਰੇ ਕਲੱਸਟਰ ਵਿੱਚ N ਐਂਟਰੀ ਪੁਆਇੰਟ ਹਨ, ਜਿਵੇਂ ਕਿ ਪ੍ਰੋਮੀਥੀਅਸ HAPROXY ਰਾਹੀਂ ਡਾਟਾ ਜੋੜ ਸਕਦਾ ਹੈ। ਇੱਥੇ ਸਾਡੇ ਕੋਲ ਇਹ ਐਂਟਰੀ ਪੁਆਇੰਟ ਹੈ। ਅਤੇ ਇਸ ਐਂਟਰੀ ਪੁਆਇੰਟ ਰਾਹੀਂ ਤੁਸੀਂ ਗ੍ਰਾਫਾਨਾ ਤੋਂ ਲੌਗਇਨ ਕਰ ਸਕਦੇ ਹੋ।

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

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

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

ਅਸੀਂ ਆਪਣੀ ਸੂਚੀ ਨੂੰ HA ਲਾਗੂ ਕਰਨ ਨਾਲ ਖਤਮ ਕਰਦੇ ਹਾਂ।

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

ਮੈਂ GitHub 'ਤੇ ਮੁੱਦੇ ਸ਼ੁਰੂ ਕੀਤੇ. ਉਹ ਬਹੁਤ ਜਲਦੀ ਹੱਲ ਹੋ ਗਏ ਸਨ. ਇੱਥੇ ਕੁਝ ਹੋਰ ਮੁੱਦੇ ਹਨ ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਨਹੀਂ ਹੋਏ ਹਨ, ਪਰ ਮੈਂ ਕੋਡ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਦੇਖ ਸਕਦਾ ਹਾਂ ਕਿ ਇਸ ਦਿਸ਼ਾ ਵਿੱਚ ਕੰਮ ਚੱਲ ਰਿਹਾ ਹੈ.

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

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

ਕਲੱਸਟਰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਦੀਆਂ ਤਜਵੀਜ਼ਾਂ ਹਨ। ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਉੱਪਰ ਦੱਸਿਆ ਹੈ.

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

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

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

https://t.me/VictoriaMetrics_ru1

VictoriaMetrics ਚੈਟ, ਮੇਰੇ ਸੰਪਰਕ, LeroyMerlin ਤਕਨੀਕੀ ਰਾਡਾਰ ਲਈ ਕੁਝ QR ਕੋਡ।

ਸਰੋਤ: www.habr.com