ਇੱਕ ਗੁੰਮ ਸਕੂਟਰ ਵਾਪਸ ਕਰੋ, ਜਾਂ ਇੱਕ IoT ਨਿਗਰਾਨੀ ਦੀ ਕਹਾਣੀ

ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ ਅਸੀਂ ਇੱਕ ਪ੍ਰਮੋਸ਼ਨਲ ਪ੍ਰੋਜੈਕਟ ਦਾ ਇੱਕ ਪਾਇਲਟ ਸੰਸਕਰਣ ਲਾਂਚ ਕੀਤਾ ਸੀ ਇਲੈਕਟ੍ਰਿਕ ਸਕੂਟਰਾਂ ਦਾ ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ ਕਿਰਾਇਆ.

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

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

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

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

ਸਕੂਟਰਾਂ ਤੋਂ ਇਲਾਵਾ, ਉਪਯੋਗਕਰਤਾ ਨੇ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ "ਸਮਾਰਟ ਚਾਰਜਰਜ਼" ਦੇਖੇ, ਜਿਸ 'ਤੇ ਜਾ ਕੇ ਉਪਭੋਗਤਾ ਮੌਜੂਦਾ ਬੈਟਰੀ ਘੱਟ ਹੋਣ 'ਤੇ ਖੁਦ ਬਦਲ ਸਕਦਾ ਹੈ।

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

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

ਇਸਨੂੰ ਕਿਵੇਂ ਲੱਭਣਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਵਾਪਸ ਕਰਨਾ ਹੈ?

ਇਸ ਲੇਖ ਵਿਚ ਮੈਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ, ਪਰ ਪਹਿਲਾਂ - ਇਸ ਬਾਰੇ ਕਿ ਅਸੀਂ ਆਪਣਾ IoT ਪਲੇਟਫਾਰਮ ਕਿਵੇਂ ਬਣਾਇਆ ਅਤੇ ਅਸੀਂ ਇਸ ਦੀ ਨਿਗਰਾਨੀ ਕਿਵੇਂ ਕੀਤੀ।

ਕੀ ਅਤੇ ਕਿਉਂ ਨਿਗਰਾਨੀ ਕਰਨੀ ਹੈ: ਸਕੂਟਰ, ਬੁਨਿਆਦੀ ਢਾਂਚਾ, ਚਾਰਜਿੰਗ ਸਟੇਸ਼ਨ?

ਇਸ ਲਈ, ਅਸੀਂ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਕੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ?

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

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

ਸਕੂਟਰ

ਸਾਡੇ ਸਕੂਟਰ ਕੀ ਸਨ ਅਤੇ ਅਸੀਂ ਉਨ੍ਹਾਂ ਬਾਰੇ ਕੀ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਸੀ?

ਪਹਿਲੀ ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ ਹੈ ਜੀਪੀਐਸ ਕੋਆਰਡੀਨੇਟਸ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਦਾ ਧੰਨਵਾਦ ਅਸੀਂ ਸਮਝ ਸਕਦੇ ਹਾਂ ਕਿ ਉਹ ਕਿੱਥੇ ਹਨ ਅਤੇ ਕਿੱਥੇ ਚੱਲ ਰਹੇ ਹਨ।

ਅੱਗੇ ਬੈਟਰੀ ਚਾਰਜ ਹੈ, ਜਿਸਦਾ ਧੰਨਵਾਦ ਅਸੀਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਸਕੂਟਰਾਂ ਦੀ ਚਾਰਜਿੰਗ ਖਤਮ ਹੋ ਰਹੀ ਹੈ ਅਤੇ ਇੱਕ ਜੂਸਰ ਭੇਜੋ ਜਾਂ ਘੱਟੋ ਘੱਟ ਉਪਭੋਗਤਾ ਨੂੰ ਚੇਤਾਵਨੀ ਦਿਓ.

ਬੇਸ਼ੱਕ, ਇਹ ਜਾਂਚ ਕਰਨਾ ਵੀ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਸਾਡੇ ਹਾਰਡਵੇਅਰ ਭਾਗਾਂ ਨਾਲ ਕੀ ਹੋ ਰਿਹਾ ਹੈ:

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

ਅਤੇ ਅੰਤ ਵਿੱਚ: ਸੌਫਟਵੇਅਰ ਦੀ ਜਾਂਚ, OS ਅਤੇ ਪ੍ਰੋਸੈਸਰ, ਨੈਟਵਰਕ ਅਤੇ ਡਿਸਕ ਲੋਡ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਸਾਡੇ ਆਪਣੇ ਮੋਡਿਊਲਾਂ ਦੀ ਜਾਂਚ ਨਾਲ ਖਤਮ ਹੁੰਦੀ ਹੈ ਜੋ ਸਾਡੇ ਲਈ ਵਧੇਰੇ ਖਾਸ ਹਨ (ਜੋਲੋਕੋਮ, ਕੀਕਲੋਕ).

ਹਾਰਡਵੇਅਰ

ਸਾਡਾ "ਲੋਹੇ" ਦਾ ਹਿੱਸਾ ਕੀ ਸੀ?

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

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

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

ਡੌਕਰ? ਪਲੇਨ ਲੀਨਕਸ? ਅਤੇ ਤੈਨਾਤੀ

ਚਲੋ ਮਾਨੀਟਰਿੰਗ 'ਤੇ ਵਾਪਸ ਆਓ, ਇਸ ਲਈ ਰਸਬੇਰੀ - ਸਾਡੇ ਕੋਲ ਕੀ ਹੈ?

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

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਆਰਪੀਆਈ 'ਤੇ ਡੌਕਰ, ਹਾਲਾਂਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਊਰਜਾ ਦੀ ਖਪਤ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਓਵਰਹੈੱਡ ਹੈ।

"ਦੇਸੀ" OS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਅੰਤਰ, ਭਾਵੇਂ ਕਿ ਇੰਨਾ ਮਜ਼ਬੂਤ ​​ਨਹੀਂ ਹੈ, ਫਿਰ ਵੀ ਸਾਡੇ ਲਈ ਚਾਰਜ ਜਲਦੀ ਗੁਆਉਣ ਦੀ ਸੰਭਾਵਨਾ ਤੋਂ ਸੁਚੇਤ ਰਹਿਣ ਲਈ ਕਾਫੀ ਸੀ।

ਦੂਜਾ ਕਾਰਨ Node.js (sic!) 'ਤੇ ਸਾਡੀ ਸਹਿਭਾਗੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ - ਸਿਸਟਮ ਦਾ ਇੱਕੋ ਇੱਕ ਹਿੱਸਾ ਜੋ Go/C/C++ ਵਿੱਚ ਨਹੀਂ ਲਿਖਿਆ ਗਿਆ ਸੀ।

ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਲੇਖਕਾਂ ਕੋਲ ਕਿਸੇ ਵੀ "ਮੂਲ" ਭਾਸ਼ਾ ਵਿੱਚ ਕਾਰਜਸ਼ੀਲ ਸੰਸਕਰਣ ਪ੍ਰਦਾਨ ਕਰਨ ਦਾ ਸਮਾਂ ਨਹੀਂ ਸੀ।

ਨਾ ਸਿਰਫ ਨੋਡ ਆਪਣੇ ਆਪ ਵਿੱਚ ਘੱਟ-ਪ੍ਰਦਰਸ਼ਨ ਵਾਲੇ ਯੰਤਰਾਂ ਲਈ ਸਭ ਤੋਂ ਸ਼ਾਨਦਾਰ ਹੱਲ ਨਹੀਂ ਹੈ, ਪਰ ਲਾਇਬ੍ਰੇਰੀ ਖੁਦ ਬਹੁਤ ਸਰੋਤ-ਭੁੱਖੀ ਸੀ।

ਸਾਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ, ਭਾਵੇਂ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ, ਡੌਕਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸਾਡੇ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਓਵਰਹੈੱਡ ਹੋਵੇਗਾ. ਚੋਣ ਮੂਲ OS ਦੇ ਹੱਕ ਵਿੱਚ ਕੀਤੀ ਗਈ ਸੀ ਅਤੇ ਇਸਦੇ ਅਧੀਨ ਸਿੱਧੇ ਕੰਮ ਕਰ ਰਹੀ ਸੀ।

OS

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ, ਦੁਬਾਰਾ, OS ਦੇ ਰੂਪ ਵਿੱਚ ਸਭ ਤੋਂ ਸਰਲ ਵਿਕਲਪ ਚੁਣਿਆ ਅਤੇ Raspbian (Pi ਲਈ ਡੇਬੀਅਨ ਬਿਲਡ) ਦੀ ਵਰਤੋਂ ਕੀਤੀ।

ਅਸੀਂ ਆਪਣੇ ਸਾਰੇ ਸੌਫਟਵੇਅਰ ਨੂੰ Go ਵਿੱਚ ਲਿਖਦੇ ਹਾਂ, ਇਸਲਈ ਅਸੀਂ Go ਵਿੱਚ ਸਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਮੁੱਖ ਹਾਰਡਵੇਅਰ ਏਜੰਟ ਮੋਡੀਊਲ ਵੀ ਲਿਖਿਆ ਹੈ।

ਇਹ ਉਹ ਹੈ ਜੋ GPS, ਬਲੂਟੁੱਥ ਨਾਲ ਕੰਮ ਕਰਨ, ਚਾਰਜ ਪੜ੍ਹਨ, ਸਕੂਟਰ ਨੂੰ ਚਾਲੂ ਕਰਨ ਆਦਿ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।

ਤੈਨਾਤ

ਡਿਵਾਈਸਾਂ (OTA) ਨੂੰ ਅੱਪਡੇਟ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਇੱਕ ਵਿਧੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਬਾਰੇ ਤੁਰੰਤ ਸਵਾਲ ਉੱਠਿਆ - ਸਾਡੇ ਏਜੰਟ/ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਅੱਪਡੇਟ, ਅਤੇ OS/ਫ਼ਰਮਵੇਅਰ ਲਈ ਅੱਪਡੇਟ (ਕਿਉਂਕਿ ਏਜੰਟ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਨੂੰ ਕਰਨਲ ਲਈ ਅੱਪਡੇਟ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਜਾਂ ਸਿਸਟਮ ਦੇ ਹਿੱਸੇ, ਲਾਇਬ੍ਰੇਰੀਆਂ, ਆਦਿ)।

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

ਮੁਕਾਬਲਤਨ ਸਧਾਰਨ ਤੋਂ, ਜ਼ਿਆਦਾਤਰ ਅੱਪਡੇਟ/ਡੁਅਲ-ਬੂਟ ਓਰੀਐਂਟਿਡ ਯੂਟਿਲਿਟੀਜ਼ ਜਿਵੇਂ ਕਿ swupd/SWUpdate/OSTree ਤੋਂ ਲੈ ਕੇ ਮੇਂਡਰ ਅਤੇ ਬਲੇਨਾ ਵਰਗੇ ਪੂਰੇ ਪਲੇਟਫਾਰਮਾਂ ਤੱਕ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਅਸੀਂ ਅੰਤ-ਤੋਂ-ਅੰਤ ਹੱਲਾਂ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਾਂ, ਇਸਲਈ ਚੋਣ ਤੁਰੰਤ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਡਿੱਗ ਗਈ।

ਆਪਣੇ ਆਪ ਬਾਲੇਨਾ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਬਾਹਰ ਰੱਖਿਆ ਗਿਆ ਸੀ ਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਇਸਦੇ ਬੈਲੇਨਾ ਇੰਜਨ ਦੇ ਅੰਦਰ ਉਹੀ ਡੌਕਰ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ.

ਪਰ ਮੈਂ ਨੋਟ ਕਰਦਾ ਹਾਂ ਕਿ ਇਸਦੇ ਬਾਵਜੂਦ, ਅਸੀਂ ਉਹਨਾਂ ਦੇ ਉਤਪਾਦ ਦੀ ਵਰਤੋਂ ਲਗਾਤਾਰ ਕਰਦੇ ਰਹੇ ਬੈਲੇਨਾ ਐਚਰ SD ਕਾਰਡਾਂ 'ਤੇ ਫਲੈਸ਼ ਫਰਮਵੇਅਰ ਲਈ - ਇਸਦੇ ਲਈ ਇੱਕ ਸਧਾਰਨ ਅਤੇ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਉਪਯੋਗਤਾ।

ਇਸ ਲਈ, ਅੰਤ ਵਿੱਚ ਚੋਣ 'ਤੇ ਡਿੱਗ ਗਿਆ ਮੇਂਡਰ. ਮੇਂਡਰ ਫਰਮਵੇਅਰ ਨੂੰ ਅਸੈਂਬਲ ਕਰਨ, ਡਿਲੀਵਰ ਕਰਨ ਅਤੇ ਸਥਾਪਿਤ ਕਰਨ ਲਈ ਇੱਕ ਪੂਰਾ ਪਲੇਟਫਾਰਮ ਹੈ।

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

ਹਾਏ, ਸਾਡੀਆਂ ਤੰਗ ਸਮਾਂ-ਸੀਮਾਵਾਂ ਦਾ ਮਤਲਬ ਸੀ ਕਿ ਸਾਨੂੰ ਮੇਂਡਰ ਦੀ ਵਰਤੋਂ ਛੱਡਣ ਅਤੇ ਇੱਕ ਹੋਰ ਸਧਾਰਨ ਦੀ ਚੋਣ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ ਗਿਆ ਸੀ।

Ansimate

ਸਾਡੀ ਸਥਿਤੀ ਵਿੱਚ ਸਭ ਤੋਂ ਆਸਾਨ ਹੱਲ Ansible ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੀ। ਸ਼ੁਰੂਆਤ ਕਰਨ ਲਈ ਕੁਝ ਪਲੇਬੁੱਕ ਕਾਫ਼ੀ ਸਨ।

ਉਹਨਾਂ ਦਾ ਸਾਰ ਇਹ ਸੀ ਕਿ ਅਸੀਂ ਬਸ ਹੋਸਟ (ਸੀਆਈ ਸਰਵਰ) ਤੋਂ ssh ਦੁਆਰਾ ਸਾਡੇ ਰਸਬੇਰੀ ਨਾਲ ਜੁੜੇ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਅਪਡੇਟਾਂ ਵੰਡੀਆਂ।

ਬਹੁਤ ਸ਼ੁਰੂ ਵਿੱਚ, ਸਭ ਕੁਝ ਸਧਾਰਨ ਸੀ - ਤੁਹਾਨੂੰ ਡਿਵਾਈਸਾਂ ਦੇ ਨਾਲ ਇੱਕੋ ਨੈੱਟਵਰਕ 'ਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ, ਵਾਈ-ਫਾਈ ਦੁਆਰਾ ਡੋਲ੍ਹਿਆ ਗਿਆ ਸੀ.

ਦਫ਼ਤਰ ਵਿੱਚ ਇੱਕੋ ਨੈੱਟਵਰਕ ਨਾਲ ਸਿਰਫ਼ ਇੱਕ ਦਰਜਨ ਟੈਸਟ ਰਸਬੇਰੀਆਂ ਜੁੜੀਆਂ ਹੋਈਆਂ ਸਨ, ਹਰੇਕ ਡਿਵਾਈਸ ਦਾ ਇੱਕ ਸਥਿਰ IP ਐਡਰੈੱਸ ਸੀ ਜੋ ਜਵਾਬਦੇਹ ਵਸਤੂ ਸੂਚੀ ਵਿੱਚ ਵੀ ਦਿੱਤਾ ਗਿਆ ਸੀ।

ਇਹ Ansible ਸੀ ਜਿਸਨੇ ਸਾਡੇ ਨਿਗਰਾਨੀ ਏਜੰਟ ਨੂੰ ਅੰਤਮ ਡਿਵਾਈਸਾਂ ਤੱਕ ਪਹੁੰਚਾਇਆ

3G / LTE

ਬਦਕਿਸਮਤੀ ਨਾਲ, Ansible ਲਈ ਇਹ ਵਰਤੋਂ ਕੇਸ ਸਿਰਫ ਵਿਕਾਸ ਮੋਡ ਵਿੱਚ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਅਸਲ ਸਕੂਟਰ ਸਨ।

ਕਿਉਂਕਿ ਸਕੂਟਰ, ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ, ਇੱਕ ਵਾਈ-ਫਾਈ ਰਾਊਟਰ ਨਾਲ ਕਨੈਕਟ ਨਾ ਬੈਠੋ, ਲਗਾਤਾਰ ਨੈੱਟਵਰਕ 'ਤੇ ਅੱਪਡੇਟ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹੋਏ।

ਅਸਲੀਅਤ ਵਿੱਚ, ਸਕੂਟਰਾਂ ਦਾ ਮੋਬਾਈਲ 3G/LTE (ਅਤੇ ਫਿਰ ਵੀ ਹਰ ਸਮੇਂ ਨਹੀਂ) ਤੋਂ ਇਲਾਵਾ ਕੋਈ ਵੀ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ।

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

ਪਰ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇੱਕ 3G/LTE ਨੈੱਟਵਰਕ ਵਿੱਚ ਅਸੀਂ ਨੈੱਟਵਰਕ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤੇ ਸਥਿਰ IP 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ।

ਇਹ ਕੁਝ ਸਿਮ ਕਾਰਡ ਪ੍ਰਦਾਤਾਵਾਂ ਦੁਆਰਾ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ; ਸਥਿਰ IP ਪਤਿਆਂ ਵਾਲੇ IoT ਡਿਵਾਈਸਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਵਿਸ਼ੇਸ਼ ਸਿਮ ਕਾਰਡ ਵੀ ਹਨ। ਪਰ ਸਾਡੇ ਕੋਲ ਅਜਿਹੇ ਸਿਮ ਕਾਰਡਾਂ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਸੀ ਅਤੇ ਅਸੀਂ IP ਪਤਿਆਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਸੀ।

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

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

VPN

ਇਸ ਸਮੱਸਿਆ ਦੇ ਹੱਲ ਵਜੋਂ, ਅਸੀਂ VPN ਨੂੰ ਚੁਣਿਆ - ਖਾਸ ਤੌਰ 'ਤੇ ਵਾਇਰਗਾਰਡ.

ਸਿਸਟਮ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਗਾਹਕ (ਸਕੂਟਰ) VPN ਸਰਵਰ ਨਾਲ ਜੁੜੇ ਹੋਏ ਸਨ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਜੁੜਨ ਦੇ ਯੋਗ ਸਨ। ਇਸ ਸੁਰੰਗ ਦੀ ਵਰਤੋਂ ਅੱਪਡੇਟ ਦੇਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਸੀ।

ਸਿਧਾਂਤ ਵਿੱਚ, ਇੱਕੋ ਸੁਰੰਗ ਦੀ ਨਿਗਰਾਨੀ ਲਈ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਪਰ ਅਜਿਹਾ ਕੁਨੈਕਸ਼ਨ ਸਧਾਰਨ ਪੁਸ਼ ਨਾਲੋਂ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਅਤੇ ਘੱਟ ਭਰੋਸੇਯੋਗ ਸੀ।

ਕਲਾਉਡ ਸਰੋਤ

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

ਦਿੱਤਾ

ਓਹ, ਜਾਪਦਾ ਹੈ ਕਿ ਅਸੀਂ ਵਰਣਨ ਨੂੰ ਕ੍ਰਮਬੱਧ ਕਰ ਲਿਆ ਹੈ, ਆਓ ਅੰਤ ਵਿੱਚ ਸਾਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ ਦੀ ਇੱਕ ਸੂਚੀ ਬਣਾਈਏ:

• ਇੱਕ ਤੇਜ਼ ਹੱਲ, ਕਿਉਂਕਿ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ ਨਿਗਰਾਨੀ ਪਹਿਲਾਂ ਹੀ ਜ਼ਰੂਰੀ ਹੈ
• ਵਾਲੀਅਮ/ਮਾਤਰਾ - ਬਹੁਤ ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ ਦੀ ਲੋੜ ਹੈ
• ਲੌਗ ਕਲੈਕਸ਼ਨ ਦੀ ਲੋੜ ਹੈ
• ਭਰੋਸੇਯੋਗਤਾ - ਸਫਲਤਾ ਨੂੰ ਲਾਂਚ ਕਰਨ ਲਈ ਡੇਟਾ ਮਹੱਤਵਪੂਰਨ ਹੈ
• ਤੁਸੀਂ ਪੁੱਲ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦੇ - ਤੁਹਾਨੂੰ ਪੁਸ਼ ਦੀ ਲੋੜ ਹੈ
• ਸਾਨੂੰ ਨਾ ਸਿਰਫ਼ ਹਾਰਡਵੇਅਰ, ਸਗੋਂ ਕਲਾਊਡ ਦੀ ਵੀ ਏਕੀਕ੍ਰਿਤ ਨਿਗਰਾਨੀ ਦੀ ਲੋੜ ਹੈ

ਅੰਤਿਮ ਚਿੱਤਰ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ

ਸਟੈਕ ਚੋਣ

ਇਸ ਲਈ, ਸਾਨੂੰ ਇੱਕ ਨਿਗਰਾਨੀ ਸਟੈਕ ਦੀ ਚੋਣ ਕਰਨ ਦੇ ਸਵਾਲ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ.

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

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

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

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

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

ਇਸ ਸਭ ਦੇ ਨਾਲ, ਅਸੀਂ ਆਪਣੇ ਆਪ ਇੱਕ ਪੂਰੇ ਨਿਗਰਾਨੀ ਪਲੇਟਫਾਰਮ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕੀਤੀ, ਪਰ ਸਭ ਤੋਂ ਵੱਧ ਕਾਰਜਸ਼ੀਲ "ਰੈਡੀ-ਮੇਡ" ਸਟੈਕ ਦੀ ਭਾਲ ਕਰ ਰਹੇ ਸੀ, ਸਿਰਫ ਉਹਨਾਂ ਨੂੰ ਲਚਕਦਾਰ ਢੰਗ ਨਾਲ ਸੰਰਚਿਤ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੇ ਨਾਲ।

(B)ELK?

ਪਹਿਲਾ ਹੱਲ ਜਿਸਨੂੰ ਅਸਲ ਵਿੱਚ ਮੰਨਿਆ ਗਿਆ ਸੀ ਉਹ ਮਸ਼ਹੂਰ ELK ਸਟੈਕ ਸੀ।
ਵਾਸਤਵ ਵਿੱਚ, ਇਸਨੂੰ BELK ਕਿਹਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਸਭ ਬੀਟਸ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ - https://www.elastic.co/what-is/elk-stack

ਬੇਸ਼ੱਕ, ELK ਨਿਗਰਾਨੀ ਦੇ ਖੇਤਰ ਵਿੱਚ ਸਭ ਤੋਂ ਮਸ਼ਹੂਰ ਅਤੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੱਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਵੀ ਵੱਧ ਲਾਗਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਅਤੇ ਪ੍ਰੋਸੈਸ ਕਰਨ ਵਿੱਚ.

ਸਾਡਾ ਇਰਾਦਾ ਸੀ ਕਿ ELK ਦੀ ਵਰਤੋਂ ਲੌਗਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਅਤੇ ਨਾਲ ਹੀ ਪ੍ਰੋਮੀਥੀਅਸ ਤੋਂ ਪ੍ਰਾਪਤ ਮੈਟ੍ਰਿਕਸ ਦੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਸਟੋਰੇਜ ਲਈ ਕੀਤੀ ਜਾਵੇਗੀ।

ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਲਈ ਤੁਸੀਂ ਗ੍ਰਾਫਾਨ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।

ਵਾਸਤਵ ਵਿੱਚ, ਨਵਾਂ ELK ਸਟੈਕ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਇਕੱਠਾ ਕਰ ਸਕਦਾ ਹੈ (ਮੈਟ੍ਰਿਕਬੀਟ), ਅਤੇ ਕਿਬਾਨਾ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਵੀ ਕਰ ਸਕਦਾ ਹੈ.

ਪਰ ਫਿਰ ਵੀ, ELK ਸ਼ੁਰੂ ਵਿੱਚ ਲੌਗਸ ਤੋਂ ਵਧਿਆ ਸੀ ਅਤੇ ਹੁਣ ਤੱਕ ਮੈਟ੍ਰਿਕਸ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਵਿੱਚ ਕਈ ਗੰਭੀਰ ਕਮੀਆਂ ਹਨ:

• ਪ੍ਰੋਮੀਥੀਅਸ ਨਾਲੋਂ ਕਾਫ਼ੀ ਹੌਲੀ
• ਪ੍ਰੋਮੀਥੀਅਸ ਨਾਲੋਂ ਕਿਤੇ ਘੱਟ ਸਥਾਨਾਂ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦਾ ਹੈ
• ਉਹਨਾਂ ਲਈ ਅਲਰਟ ਸੈਟ ਅਪ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ
• ਮੈਟ੍ਰਿਕਸ ਬਹੁਤ ਸਾਰੀ ਥਾਂ ਲੈਂਦੇ ਹਨ
• ਕਿਬਾਨ ਵਿੱਚ ਮੈਟ੍ਰਿਕਸ ਦੇ ਨਾਲ ਡੈਸ਼ਬੋਰਡ ਸੈਟ ਅਪ ਕਰਨਾ ਗ੍ਰਾਫਾਨ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਹੈ

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

ਅਤੇ ELK ਸਟੈਕ ਵਿੱਚ ਆਪਣੇ ਆਪ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਮੁਸ਼ਕਲ ਪਲ ਹਨ:

• ਇਹ ਭਾਰੀ ਹੁੰਦਾ ਹੈ, ਕਈ ਵਾਰ ਤਾਂ ਬਹੁਤ ਭਾਰੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਕਾਫ਼ੀ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਇਕੱਠਾ ਕਰਦੇ ਹੋ
• ਤੁਹਾਨੂੰ ਇਸਨੂੰ "ਪਕਾਉਣ ਦਾ ਤਰੀਕਾ ਜਾਣਨ" ਦੀ ਜ਼ਰੂਰਤ ਹੈ - ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਸਕੇਲ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਪਰ ਇਹ ਕਰਨਾ ਮਾਮੂਲੀ ਨਹੀਂ ਹੈ
• ਸਟ੍ਰਿਪਡ ਡਾਊਨ ਮੁਫਤ ਸੰਸਕਰਣ - ਮੁਫਤ ਸੰਸਕਰਣ ਵਿੱਚ ਆਮ ਚੇਤਾਵਨੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਚੋਣ ਦੇ ਸਮੇਂ ਕੋਈ ਪ੍ਰਮਾਣਿਕਤਾ ਨਹੀਂ ਸੀ

ਮੈਨੂੰ ਇਹ ਕਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਹਾਲ ਹੀ ਵਿੱਚ ਆਖਰੀ ਬਿੰਦੂ ਬਿਹਤਰ ਹੋ ਗਿਆ ਹੈ ਅਤੇ ਇਸਦੇ ਇਲਾਵਾ ਓਪਨ-ਸੋਰਸ ਐਕਸ-ਪੈਕ ਵਿੱਚ ਆਉਟਪੁੱਟ (ਪ੍ਰਮਾਣਿਕਤਾ ਸਮੇਤ) ਕੀਮਤ ਮਾਡਲ ਆਪਣੇ ਆਪ ਵਿੱਚ ਬਦਲਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ।

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

ਲੋਕੀ - ਗ੍ਰਾਫਾਨਾ - ਪ੍ਰੋਮੀਥੀਅਸ

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

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਪ੍ਰੋਜੈਕਟ (ਸਤੰਬਰ-ਅਕਤੂਬਰ 19) ਦੀ ਵਿਕਰੀ ਪਾਇਲਟ ਦੀ ਸ਼ੁਰੂਆਤ ਦੇ ਸਮੇਂ, ਲੋਕੀ ਅਜੇ ਵੀ ਬੀਟਾ ਸੰਸਕਰਣ 0.3-0.4 ਵਿੱਚ ਸੀ, ਅਤੇ ਵਿਕਾਸ ਦੀ ਸ਼ੁਰੂਆਤ ਦੇ ਸਮੇਂ ਇਸਨੂੰ ਇੱਕ ਉਤਪਾਦਕ ਹੱਲ ਵਜੋਂ ਨਹੀਂ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਸੀ। ਤੇ ਸਾਰੇ.

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

ਟਿੱਕ ਕਰੋ

ਸ਼ਾਇਦ ELK ਸਟੈਕ ਲਈ ਸਭ ਤੋਂ ਯੋਗ (ਇਕਮਾਤਰ?) ਪੂਰੀ-ਵਿਸ਼ੇਸ਼ਤਾ ਵਾਲੇ ਵਿਕਲਪ ਨੂੰ ਹੁਣ ਸਿਰਫ TICK ਸਟੈਕ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ - ਟੈਲੀਗ੍ਰਾਫ, ਇਨਫਲੂਕਸਡੀਬੀ, ਕ੍ਰੋਨੋਗ੍ਰਾਫ, ਕਪੈਸੀਟਰ।

ਮੈਂ ਹੇਠਾਂ ਸਾਰੇ ਭਾਗਾਂ ਦਾ ਵਧੇਰੇ ਵਿਸਥਾਰ ਨਾਲ ਵਰਣਨ ਕਰਾਂਗਾ, ਪਰ ਆਮ ਵਿਚਾਰ ਇਹ ਹੈ:

• ਟੈਲੀਗ੍ਰਾਫ - ਮੈਟ੍ਰਿਕਸ ਇਕੱਠੇ ਕਰਨ ਲਈ ਏਜੰਟ
• InfluxDB - ਮੈਟ੍ਰਿਕਸ ਡੇਟਾਬੇਸ
• Kapacitor - ਚੇਤਾਵਨੀ ਲਈ ਰੀਅਲ-ਟਾਈਮ ਮੈਟ੍ਰਿਕਸ ਪ੍ਰੋਸੈਸਰ
• ਕ੍ਰੋਨੋਗ੍ਰਾਫ - ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਲਈ ਵੈੱਬ ਪੈਨਲ

InfluxDB, Kapacitor ਅਤੇ Chronograf ਲਈ ਅਧਿਕਾਰਤ ਹੈਲਮ ਚਾਰਟ ਹਨ ਜੋ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਲਈ ਵਰਤਦੇ ਹਾਂ।

ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ Influx 2.0 (ਬੀਟਾ) ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਵਿੱਚ, Kapacitor ਅਤੇ Chronograf InfluxDB ਦਾ ਹਿੱਸਾ ਬਣ ਗਏ ਹਨ ਅਤੇ ਹੁਣ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਮੌਜੂਦ ਨਹੀਂ ਹਨ।

ਟੈਲੀਗ੍ਰਾਫ

ਟੈਲੀਗ੍ਰਾਫ ਸਟੇਟ ਮਸ਼ੀਨ 'ਤੇ ਮੈਟ੍ਰਿਕਸ ਇਕੱਠਾ ਕਰਨ ਲਈ ਇੱਕ ਬਹੁਤ ਹਲਕਾ ਏਜੰਟ ਹੈ।

ਉਸ ਨੇ ਹਰ ਚੀਜ਼ ਦੀ ਇੱਕ ਵੱਡੀ ਰਕਮ ਦੀ ਨਿਗਰਾਨੀ ਕਰ ਸਕਦਾ ਹੈ, ਤੱਕ nginx ਨੂੰ
ਸਰਵਰ Minecraft.

ਇਸਦੇ ਬਹੁਤ ਸਾਰੇ ਠੰਡੇ ਫਾਇਦੇ ਹਨ:

• ਤੇਜ਼ ਅਤੇ ਹਲਕਾ (ਗੋ ਵਿੱਚ ਲਿਖਿਆ)
  • ਘੱਟੋ-ਘੱਟ ਵਸੀਲੇ ਖਾਂਦਾ ਹੈ
• ਮੂਲ ਰੂਪ ਵਿੱਚ ਪੁਸ਼ ਮੈਟ੍ਰਿਕਸ
• ਸਾਰੇ ਜ਼ਰੂਰੀ ਮੈਟ੍ਰਿਕਸ ਇਕੱਠੇ ਕਰਦਾ ਹੈ
  • ਬਿਨਾਂ ਕਿਸੇ ਸੈਟਿੰਗ ਦੇ ਸਿਸਟਮ ਮੈਟ੍ਰਿਕਸ
  • ਹਾਰਡਵੇਅਰ ਮੈਟ੍ਰਿਕਸ ਜਿਵੇਂ ਕਿ ਸੈਂਸਰਾਂ ਤੋਂ ਜਾਣਕਾਰੀ
  • ਆਪਣੇ ਖੁਦ ਦੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਜੋੜਨਾ ਬਹੁਤ ਆਸਾਨ ਹੈ
• ਬਾਕਸ ਦੇ ਬਾਹਰ ਬਹੁਤ ਸਾਰੇ ਪਲੱਗਇਨ
• ਲੌਗ ਇਕੱਠੇ ਕਰਦਾ ਹੈ

ਕਿਉਂਕਿ ਪੁਸ਼ ਮੈਟ੍ਰਿਕਸ ਸਾਡੇ ਲਈ ਜ਼ਰੂਰੀ ਸਨ, ਹੋਰ ਸਾਰੇ ਫਾਇਦੇ ਸੁਹਾਵਣੇ ਜੋੜਾਂ ਤੋਂ ਵੱਧ ਸਨ।

ਏਜੰਟ ਦੁਆਰਾ ਲੌਗਸ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਵੀ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਹੈ, ਕਿਉਂਕਿ ਲੌਗਿੰਗ ਲੌਗ ਲਈ ਵਾਧੂ ਉਪਯੋਗਤਾਵਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ ਤਾਂ ਇਨਫਲਕਸ ਲੌਗਸ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਸੁਵਿਧਾਜਨਕ ਅਨੁਭਵ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ syslog.

ਟੈਲੀਗ੍ਰਾਫ ਆਮ ਤੌਰ 'ਤੇ ਮੈਟ੍ਰਿਕਸ ਇਕੱਠਾ ਕਰਨ ਲਈ ਇੱਕ ਵਧੀਆ ਏਜੰਟ ਹੁੰਦਾ ਹੈ, ਭਾਵੇਂ ਤੁਸੀਂ ਬਾਕੀ ਦੇ ICK ਸਟੈਕ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਹੋ।

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

InfluxDB

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

InfluxDB ਗੋ ਵਿੱਚ ਵੀ ਲਿਖਿਆ ਗਿਆ ਹੈ ਅਤੇ ਸਾਡੇ (ਸਭ ਤੋਂ ਸ਼ਕਤੀਸ਼ਾਲੀ ਨਹੀਂ) ਕਲੱਸਟਰ 'ਤੇ ELK ਦੇ ਮੁਕਾਬਲੇ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲਦਾ ਜਾਪਦਾ ਹੈ।

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

ਨੁਕਸਾਨ - $$$ ਜਾਂ ਸਕੇਲਿੰਗ?

TICK ਸਟੈਕ ਵਿੱਚ ਸਿਰਫ ਇੱਕ ਕਮੀ ਹੈ ਜੋ ਅਸੀਂ ਖੋਜੀ ਹੈ - ਇਹ ਪਿਆਰੇ. ਹੋਰ ਵਧ.

ਅਦਾਇਗੀ ਸੰਸਕਰਣ ਵਿੱਚ ਕੀ ਹੈ ਜੋ ਮੁਫਤ ਸੰਸਕਰਣ ਵਿੱਚ ਨਹੀਂ ਹੈ?

ਜਿੱਥੋਂ ਤੱਕ ਅਸੀਂ ਸਮਝਣ ਦੇ ਯੋਗ ਸੀ, TICK ਸਟੈਕ ਦੇ ਭੁਗਤਾਨ ਕੀਤੇ ਸੰਸਕਰਣ ਅਤੇ ਮੁਫਤ ਵਿੱਚ ਸਿਰਫ ਅੰਤਰ ਹੈ ਸਕੇਲਿੰਗ ਸਮਰੱਥਾਵਾਂ।

ਅਰਥਾਤ, ਤੁਸੀਂ ਸਿਰਫ ਉੱਚ ਉਪਲਬਧਤਾ ਦੇ ਨਾਲ ਇੱਕ ਕਲੱਸਟਰ ਬਣਾ ਸਕਦੇ ਹੋ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੰਸਕਰਣ.

ਜੇਕਰ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ HA ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਜਾਂ ਤਾਂ ਭੁਗਤਾਨ ਕਰਨ ਜਾਂ ਕੁਝ ਬੈਸਾਖੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇੱਥੇ ਕੁਝ ਭਾਈਚਾਰਕ ਹੱਲ ਹਨ - ਉਦਾਹਰਨ ਲਈ influxdb-ha ਇੱਕ ਸਮਰੱਥ ਹੱਲ ਦੀ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ, ਪਰ ਇਹ ਲਿਖਿਆ ਗਿਆ ਹੈ ਕਿ ਇਹ ਉਤਪਾਦਨ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ
influx-sout - NATS ਦੁਆਰਾ ਡੇਟਾ ਪੰਪਿੰਗ ਦੇ ਨਾਲ ਇੱਕ ਸਧਾਰਨ ਹੱਲ (ਇਸ ਨੂੰ ਸਕੇਲ ਕਰਨਾ ਵੀ ਹੋਵੇਗਾ, ਪਰ ਇਸ ਨੂੰ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ)।

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

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

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

ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ?

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

ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਸਮਾਂ-ਸੀਰੀਜ਼ ਡੇਟਾਬੇਸ ਹਨ, ਪਰ ਸਭ ਤੋਂ ਵੱਧ ਹੋਨਹਾਰ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਹੈ, ਇਸਦੇ ਬਹੁਤ ਸਾਰੇ ਫਾਇਦੇ ਹਨ:

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

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

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਸੰਭਵ ਨਹੀਂ ਹੈ, ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ InfluxDB ਪ੍ਰੋਟੋਕੋਲ ਸਮਰਥਿਤ ਹੈ, ਇਹ ਸਿਰਫ ਰਿਕਾਰਡਿੰਗ ਮੈਟ੍ਰਿਕਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ - ਸਿਰਫ ਪ੍ਰੋਮੀਥੀਅਸ API "ਬਾਹਰ" ਉਪਲਬਧ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸ 'ਤੇ ਕ੍ਰੋਨੋਗ੍ਰਾਫ ਸੈੱਟ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਹੋਵੇਗਾ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮੈਟ੍ਰਿਕਸ ਲਈ ਸਿਰਫ ਸੰਖਿਆਤਮਕ ਮੁੱਲ ਸਮਰਥਿਤ ਹਨ (ਅਸੀਂ ਕਸਟਮ ਮੈਟ੍ਰਿਕਸ ਲਈ ਸਤਰ ਮੁੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ - ਭਾਗ ਵਿੱਚ ਇਸ ਬਾਰੇ ਹੋਰ ਐਡਮਿਨ ਪੈਨਲ).

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਉਸੇ ਕਾਰਨ ਕਰਕੇ, VM ਲੌਗਸ ਨੂੰ ਸਟੋਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜਿਵੇਂ ਕਿ ਇਨਫਲਕਸ ਕਰਦਾ ਹੈ।

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

ਅਧਾਰ ਚੋਣ

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

ਇਸ ਚੋਣ ਦੇ ਕਈ ਮੁੱਖ ਕਾਰਨ ਸਨ:

• ਸਾਨੂੰ TICK ਸਟੈਕ ਦੀ ਪੂਰੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਸੱਚਮੁੱਚ ਪਸੰਦ ਆਇਆ
• ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇਸ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਰਹੇ ਹਾਂ ਅਤੇ ਇਹ ਬਹੁਤ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ
• ਅੰਤਮ ਤਾਰੀਖਾਂ ਖਤਮ ਹੋ ਰਹੀਆਂ ਸਨ ਅਤੇ ਹੋਰ ਵਿਕਲਪਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਬਹੁਤ ਸਮਾਂ ਨਹੀਂ ਬਚਿਆ ਸੀ।
• ਸਾਨੂੰ ਇੰਨੇ ਭਾਰੀ ਬੋਝ ਦੀ ਉਮੀਦ ਨਹੀਂ ਸੀ

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

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

ਅਸੀਂ ਸਟੈਕ ਅਤੇ ਬੇਸ ਬਾਰੇ ਫੈਸਲਾ ਕਰ ਲਿਆ ਹੈ - ਹੁਣ TICK ਸਟੈਕ ਦੇ ਬਾਕੀ ਬਚੇ ਹਿੱਸਿਆਂ ਬਾਰੇ।

ਕਪੈਸੀਟਰ

Kapacitor TICK ਸਟੈਕ ਦਾ ਹਿੱਸਾ ਹੈ, ਇੱਕ ਸੇਵਾ ਜੋ ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਡੇਟਾਬੇਸ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਵਾਲੇ ਮੈਟ੍ਰਿਕਸ ਦੀ ਨਿਗਰਾਨੀ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਨਿਯਮਾਂ ਦੇ ਅਧਾਰ ਤੇ ਵੱਖ-ਵੱਖ ਕਾਰਵਾਈਆਂ ਕਰ ਸਕਦੀ ਹੈ।

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

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

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

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

Influx 2.0 Kapacitor DB ਦਾ ਹਿੱਸਾ ਬਣ ਗਿਆ

ਕ੍ਰੋਨੋਗ੍ਰਾਫ

ਮੈਂ ਨਿਗਰਾਨੀ ਲਈ ਬਹੁਤ ਸਾਰੇ ਵੱਖ-ਵੱਖ UI ਹੱਲ ਦੇਖੇ ਹਨ, ਪਰ ਮੈਂ ਕਹਿ ਸਕਦਾ ਹਾਂ ਕਿ ਕਾਰਜਸ਼ੀਲਤਾ ਅਤੇ UX ਦੇ ਰੂਪ ਵਿੱਚ, ਕੁਝ ਵੀ ਕ੍ਰੋਨੋਗ੍ਰਾਫ ਨਾਲ ਤੁਲਨਾ ਨਹੀਂ ਕਰਦਾ.

ਅਸੀਂ TICK ਸਟੈਕ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕੀਤੀ, ਅਜੀਬ ਤੌਰ 'ਤੇ, ਇੱਕ ਵੈੱਬ ਇੰਟਰਫੇਸ ਦੇ ਤੌਰ 'ਤੇ Grafan ਦੇ ਨਾਲ।
ਮੈਂ ਇਸਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਾਂਗਾ; ਹਰ ਕੋਈ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਨ ਲਈ ਇਸ ਦੀਆਂ ਵਿਸ਼ਾਲ ਸੰਭਾਵਨਾਵਾਂ ਨੂੰ ਜਾਣਦਾ ਹੈ.

ਹਾਲਾਂਕਿ, ਗ੍ਰਾਫਾਨਾ ਅਜੇ ਵੀ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੂਨੀਵਰਸਲ ਸਾਧਨ ਹੈ, ਜਦੋਂ ਕਿ ਕ੍ਰੋਨੋਗ੍ਰਾਫ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇਨਫਲਕਸ ਨਾਲ ਵਰਤਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ।

ਅਤੇ ਬੇਸ਼ਕ, ਇਸਦਾ ਧੰਨਵਾਦ, ਕ੍ਰੋਨੋਗ੍ਰਾਫ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੁਸ਼ਿਆਰ ਜਾਂ ਸੁਵਿਧਾਜਨਕ ਕਾਰਜਸ਼ੀਲਤਾ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦਾ ਹੈ.

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

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

ਕਿਬਾਨਾ ਕੋਲ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਉਹਨਾਂ ਲਈ ਨਿਯੰਤਰਣ ਬਣਾਉਣ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਰੱਥਾਵਾਂ ਹਨ, ਪਰ ਅਜਿਹੇ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਯੂਐਕਸ ਬਹੁਤ ਗੁੰਝਲਦਾਰ ਹੈ।

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

ਡੈਸ਼ਬੋਰਡ ਆਪਣੇ ਆਪ, ਸੁਹਾਵਣੇ ਵਿਜ਼ੂਅਲ ਸ਼ੈਲੀ ਤੋਂ ਇਲਾਵਾ, ਅਸਲ ਵਿੱਚ ਗ੍ਰਾਫਾਨਾ ਜਾਂ ਕਿਬਾਨਾ ਵਿੱਚ ਡੈਸ਼ਬੋਰਡਾਂ ਤੋਂ ਵੱਖਰੇ ਨਹੀਂ ਹਨ:

ਪੁੱਛਗਿੱਛ ਵਿੰਡੋ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

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

ਅਤੇ ਬੇਸ਼ੱਕ, ਕ੍ਰੋਨੋਗ੍ਰਾਫ ਲੌਗ ਦੇਖਣ ਲਈ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸੁਵਿਧਾਜਨਕ ਹੈ. ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ:

ਮੂਲ ਰੂਪ ਵਿੱਚ, ਇਨਫਲਕਸ ਲੌਗ ਸਿਸਲੌਗ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਇਸਲਈ ਉਹਨਾਂ ਕੋਲ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਮਾਪਦੰਡ ਹੈ - ਗੰਭੀਰਤਾ।

ਸਿਖਰ 'ਤੇ ਗ੍ਰਾਫ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੈ; ਇਸ 'ਤੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਗਲਤੀਆਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ ਜੋ ਵਾਪਰਦੀਆਂ ਹਨ ਅਤੇ ਰੰਗ ਤੁਰੰਤ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਗੰਭੀਰਤਾ ਵੱਧ ਹੈ।

ਕਈ ਵਾਰ ਅਸੀਂ ਇਸ ਤਰੀਕੇ ਨਾਲ ਮਹੱਤਵਪੂਰਨ ਬੱਗ ਫੜੇ ਹਨ, ਪਿਛਲੇ ਹਫਤੇ ਦੇ ਲੌਗਸ ਨੂੰ ਦੇਖਣ ਲਈ ਜਾ ਰਹੇ ਹਾਂ ਅਤੇ ਇੱਕ ਲਾਲ ਸਪਾਈਕ ਵੇਖਦੇ ਹਾਂ।

ਬੇਸ਼ੱਕ, ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਅਜਿਹੀਆਂ ਗਲਤੀਆਂ ਲਈ ਅਲਰਟ ਸਥਾਪਤ ਕਰਨਾ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇਸ ਲਈ ਸਭ ਕੁਝ ਸੀ.

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

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

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

ਪ੍ਰਮਾਣਿਕਤਾ

ਇਹ ਵੀ ਜ਼ਿਕਰਯੋਗ ਹੈ ਕਿ ਕ੍ਰੋਨੋਗ੍ਰਾਫ OAuth ਅਤੇ OIDC ਨੂੰ ਪ੍ਰਮਾਣਿਕਤਾ ਦੇ ਤੌਰ 'ਤੇ ਸਪੋਰਟ ਕਰਦਾ ਹੈ।

ਇਹ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਆਸਾਨੀ ਨਾਲ ਆਪਣੇ ਸਰਵਰ ਨਾਲ ਜੋੜਨ ਅਤੇ ਪੂਰਾ SSO ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

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

"ਐਡਮਿਨ"

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

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

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

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

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

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

ਇਹ ਫੰਕਸ਼ਨ ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਡੈਡਮੈਨ — ਅਸੀਂ ਇਸਨੂੰ ਆਪਣੇ ਬਾਕਸ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਸਮਝਣ ਅਤੇ ਸਲੈਕ ਨੂੰ ਉਹੀ ਅਲਰਟ ਭੇਜਣ ਲਈ ਵਰਤਿਆ ਹੈ।

ਵੈਸੇ, ਅਸੀਂ ਸਕੂਟਰਾਂ ਦਾ ਨਾਮ ਸਿਮਪਸਨ ਦੇ ਪਾਤਰਾਂ ਦੇ ਨਾਮਾਂ 'ਤੇ ਰੱਖਿਆ ਹੈ - ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਤੋਂ ਵੱਖ ਕਰਨਾ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਸੀ

ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਇਸ ਤਰੀਕੇ ਨਾਲ ਵਧੇਰੇ ਮਜ਼ੇਦਾਰ ਸੀ. "ਮੁੰਡੇ, ਸਮਿਥਰਸ ਮਰ ਗਿਆ ਹੈ!" ਵਰਗੇ ਵਾਕਾਂਸ਼ ਲਗਾਤਾਰ ਸੁਣੇ ਜਾਂਦੇ ਸਨ।

ਸਟ੍ਰਿੰਗ ਮੈਟ੍ਰਿਕਸ

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

ਇਹ ਜਾਪਦਾ ਹੈ ਕਿ ਇਹ ਇੰਨਾ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ - ਆਖ਼ਰਕਾਰ, ਲੌਗਸ ਤੋਂ ਇਲਾਵਾ, ਕਿਸੇ ਵੀ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਸੰਖਿਆਵਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਸਿਰਫ਼ ਜਾਣੇ-ਪਛਾਣੇ ਰਾਜਾਂ ਲਈ ਮੈਪਿੰਗ ਜੋੜੋ - ਇੱਕ ਕਿਸਮ ਦਾ ਐਨਮ)?

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

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

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇਨਫਲਕਸ ਬਚਾਅ ਲਈ ਆਇਆ ਸੀ. ਅਸੀਂ ਸਿਰਫ਼ ਸਟ੍ਰਿੰਗ ਸਥਿਤੀ ਲਿਖੀ ਹੈ ਜੋ ਸਾਡੇ ਕੋਲ ਬਿਨਾਂ ਕਿਸੇ ਬਦਲਾਅ ਦੇ InfluxDB ਡੇਟਾਬੇਸ ਖੇਤਰ ਵਿੱਚ ਆਈ ਹੈ।

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

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

ਇਸ ਤਰ੍ਹਾਂ, ਜੇਕਰ ਅਸੀਂ ਸਿਰਫ਼ ਮੁੱਲਾਂ ਦੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਸਹੀ ਸਮੇਂ 'ਤੇ ਫਰਮਵੇਅਰ ਵਿੱਚ ਇਹ ਤਬਦੀਲੀਆਂ ਨਹੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ।

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

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

ਇਹ ਸਾਡੇ ਲਈ ਬਹੁਤ ਲਾਭਦਾਇਕ ਸੀ ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਸਕੂਟਰ ਲੱਭ ਰਹੇ ਸੀ (ਅੰਤ ਵਿੱਚ ਸਿੱਟਾ ਦੇਖੋ)।

ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਨਿਗਰਾਨੀ

ਸਕੂਟਰਾਂ ਤੋਂ ਇਲਾਵਾ, ਸਾਨੂੰ ਆਪਣੇ ਪੂਰੇ (ਨਾ ਕਿ ਵਿਆਪਕ) ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਵੀ ਲੋੜ ਸੀ।

ਇੱਕ ਬਹੁਤ ਹੀ ਆਮ ਆਰਕੀਟੈਕਚਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਸ਼ੁੱਧ ਨਿਗਰਾਨੀ ਸਟੈਕ ਨੂੰ ਉਜਾਗਰ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

ਅਸੀਂ ਕਲਾਉਡ ਵਿੱਚ ਕੀ ਵੇਖਣਾ ਚਾਹੁੰਦੇ ਹਾਂ:

• ਡਾਟਾਬੇਸ
• ਕੀਕਲੋਕ
• ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼

ਕਿਉਂਕਿ ਸਾਡੀਆਂ ਸਾਰੀਆਂ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸਥਿਤ ਹਨ, ਇਸ ਲਈ ਇਸਦੇ ਰਾਜ ਬਾਰੇ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨਾ ਚੰਗਾ ਹੋਵੇਗਾ।

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਟੈਲੀਗ੍ਰਾਫ ਆਊਟ ਆਫ ਦ ਬਾਕਸ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਬਹੁਤ ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ ਇਕੱਠੇ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕ੍ਰੋਨੋਗ੍ਰਾਫ ਤੁਰੰਤ ਇਸਦੇ ਲਈ ਸੁੰਦਰ ਡੈਸ਼ਬੋਰਡ ਪੇਸ਼ ਕਰਦਾ ਹੈ।

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

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

ਅਸੀਂ ਟੈਲੀਗ੍ਰਾਫ ਸਾਈਡਕਾਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਅਤੇ, ਮੈਟ੍ਰਿਕਸ ਤੋਂ ਇਲਾਵਾ, ਪੌਡ ਲੌਗ ਇਕੱਠੇ ਕੀਤੇ।

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

ਨਿਗਰਾਨੀ ਦੀ ਨਿਗਰਾਨੀ???

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

ਹਾਲਾਂਕਿ ਟੈਲੀਗ੍ਰਾਫ ਆਸਾਨੀ ਨਾਲ ਆਪਣੇ ਖੁਦ ਦੇ ਮੈਟ੍ਰਿਕਸ ਭੇਜ ਸਕਦਾ ਹੈ ਜਾਂ ਇਨਫਲੁਕਸਡੀਬੀ ਡੇਟਾਬੇਸ ਤੋਂ ਮੈਟ੍ਰਿਕਸ ਇਕੱਠਾ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਉਸੇ ਇਨਫਲਕਸ ਜਾਂ ਕਿਤੇ ਹੋਰ ਭੇਜਣ ਲਈ।

ਸਿੱਟਾ

ਪਾਇਲਟ ਦੇ ਨਤੀਜਿਆਂ ਤੋਂ ਅਸੀਂ ਕਿਹੜੇ ਸਿੱਟੇ ਕੱਢੇ?

ਤੁਸੀਂ ਨਿਗਰਾਨੀ ਕਿਵੇਂ ਕਰ ਸਕਦੇ ਹੋ?

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

ਸਾਨੂੰ ਲੋੜੀਂਦੀ ਸਾਰੀ ਕਾਰਜਸ਼ੀਲਤਾ ਮੌਜੂਦ ਸੀ। ਅਸੀਂ ਇਸ ਨਾਲ ਜੋ ਵੀ ਕੀਤਾ ਉਹ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਕੰਮ ਕੀਤਾ।

ਉਤਪਾਦਕਤਾ

ਮੁਫਤ ਸੰਸਕਰਣ ਵਿੱਚ TICK ਸਟੈਕ ਦੀ ਮੁੱਖ ਸਮੱਸਿਆ ਸਕੇਲਿੰਗ ਸਮਰੱਥਾਵਾਂ ਦੀ ਘਾਟ ਹੈ। ਇਹ ਸਾਡੇ ਲਈ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ।

ਅਸੀਂ ਸਹੀ ਲੋਡ ਡੇਟਾ/ਅੰਕੜੇ ਇਕੱਠੇ ਨਹੀਂ ਕੀਤੇ, ਪਰ ਅਸੀਂ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਲਗਭਗ 30 ਸਕੂਟਰਾਂ ਤੋਂ ਡੇਟਾ ਇਕੱਤਰ ਕੀਤਾ।

ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨੇ ਤਿੰਨ ਦਰਜਨ ਤੋਂ ਵੱਧ ਮੈਟ੍ਰਿਕਸ ਇਕੱਠੇ ਕੀਤੇ। ਉਸੇ ਸਮੇਂ, ਡਿਵਾਈਸਾਂ ਤੋਂ ਲੌਗ ਇਕੱਠੇ ਕੀਤੇ ਗਏ ਸਨ. ਡਾਟਾ ਇਕੱਠਾ ਕਰਨਾ ਅਤੇ ਭੇਜਣਾ ਹਰ 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।

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

ਟ੍ਰੈਫਿਕ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਲੌਗਸ ਦੁਆਰਾ ਖਪਤ ਕੀਤਾ ਗਿਆ ਸੀ; ਮੈਟ੍ਰਿਕਸ ਖੁਦ, 10-ਸਕਿੰਟ ਦੇ ਅੰਤਰਾਲ ਦੇ ਨਾਲ, ਅਮਲੀ ਤੌਰ 'ਤੇ ਇਸ ਨੂੰ ਬਰਬਾਦ ਨਹੀਂ ਕੀਤਾ.

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

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

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

ਵਿਕਾਸ ਵਾਤਾਵਰਨ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਵੱਖਰੀ InfluxDB ਉਦਾਹਰਨ ਤਿਆਰ ਕੀਤੀ ਹੈ ਜੋ ਹਰ 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੀ ਹੈ ਅਤੇ ਸਾਨੂੰ ਕਿਸੇ ਵੀ ਕਾਰਗੁਜ਼ਾਰੀ ਸੰਬੰਧੀ ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਆਈਆਂ।

TICK - ਛੋਟੇ ਤੋਂ ਦਰਮਿਆਨੇ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਆਦਰਸ਼

ਇਸ ਜਾਣਕਾਰੀ ਦੇ ਆਧਾਰ 'ਤੇ, ਮੈਂ ਇਹ ਸਿੱਟਾ ਕੱਢਾਂਗਾ ਕਿ TICK ਸਟੈਕ ਮੁਕਾਬਲਤਨ ਛੋਟੇ ਪ੍ਰੋਜੈਕਟਾਂ ਜਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਆਦਰਸ਼ ਹੈ ਜੋ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਕਿਸੇ ਹਾਈਲੋਡ ਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰਦੇ ਹਨ।

ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਹਜ਼ਾਰਾਂ ਪੌਡ ਜਾਂ ਸੈਂਕੜੇ ਮਸ਼ੀਨਾਂ ਨਹੀਂ ਹਨ, ਤਾਂ ਇੱਕ InfluxDB ਉਦਾਹਰਨ ਵੀ ਲੋਡ ਨੂੰ ਠੀਕ ਢੰਗ ਨਾਲ ਸੰਭਾਲ ਲਵੇਗੀ।

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

ਅਤੇ, ਬੇਸ਼ੱਕ, ਕੋਈ ਵੀ ਤੁਹਾਨੂੰ "ਵਰਟੀਕਲ" ਸਕੇਲਿੰਗ ਸਥਾਪਤ ਕਰਨ ਅਤੇ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਮੈਟ੍ਰਿਕਸ ਲਈ ਵੱਖ-ਵੱਖ ਸਰਵਰਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਤੋਂ ਨਹੀਂ ਰੋਕ ਰਿਹਾ ਹੈ.

ਜੇ ਤੁਸੀਂ ਨਿਗਰਾਨੀ ਸੇਵਾਵਾਂ 'ਤੇ ਸੰਭਾਵਿਤ ਲੋਡ ਬਾਰੇ ਯਕੀਨੀ ਨਹੀਂ ਹੋ, ਜਾਂ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ "ਭਾਰੀ" ਆਰਕੀਟੈਕਚਰ ਹੋਣ ਦੀ ਗਾਰੰਟੀ ਹੈ, ਤਾਂ ਮੈਂ TICK ਸਟੈਕ ਦੇ ਮੁਫਤ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਕਰਾਂਗਾ।

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

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

ਇਹ ਸੱਚ ਹੈ, ਮੈਂ ਦੁਬਾਰਾ ਇੱਕ ਰਿਜ਼ਰਵੇਸ਼ਨ ਕਰਾਂਗਾ ਕਿ ਲੋਕੀ/ਗਰਾਫਨਾ ਤਿਆਰ-ਕੀਤੀ TICK ਨਾਲੋਂ ਬਹੁਤ ਘੱਟ ਸੁਵਿਧਾਜਨਕ (ਉਨ੍ਹਾਂ ਦੀ ਵਧੇਰੇ ਬਹੁਪੱਖੀਤਾ ਦੇ ਕਾਰਨ) ਹਨ, ਪਰ ਉਹ ਮੁਫਤ ਹਨ।

ਮਹੱਤਵਪੂਰਣ: ਇੱਥੇ ਦੱਸੀ ਗਈ ਸਾਰੀ ਜਾਣਕਾਰੀ ਸੰਸਕਰਣ ਇਨਫਲਕਸ 1.8 ਲਈ ਢੁਕਵੀਂ ਹੈ, ਇਸ ਸਮੇਂ ਇਨਫਲਕਸ 2.0 ਰਿਲੀਜ਼ ਹੋਣ ਵਾਲਾ ਹੈ।

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

ਇਹ ਕਾਰਜਸ਼ੀਲਤਾ ਇਨਫਲਕਸ 2.0 ਵਿੱਚ ਵੀ ਦਿਖਾਈ ਦੇਵੇਗੀ, ਪਰ ਅਸੀਂ ਕੋਈ ਸਮਾਂ-ਸੀਮਾ ਨਹੀਂ ਲੱਭ ਸਕੇ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਅੰਦਾਜ਼ਨ ਵੀ।

IoT ਪਲੇਟਫਾਰਮ ਕਿਵੇਂ ਨਹੀਂ ਬਣਾਉਣਾ ਹੈ (ਹੁਣ)

ਅੰਤ ਵਿੱਚ, ਪਾਇਲਟ ਨੂੰ ਲਾਂਚ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਆਪਣੇ ਮਾਪਦੰਡਾਂ ਅਨੁਸਾਰ ਢੁਕਵੇਂ ਵਿਕਲਪ ਦੀ ਅਣਹੋਂਦ ਵਿੱਚ, ਆਪਣੇ ਖੁਦ ਦੇ ਪੂਰੇ IoT ਸਟੈਕ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ।

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

ਅਸੀਂ ਅੰਤਮ ਨਤੀਜੇ ਅਤੇ Ansible + TICK + WireGuard 'ਤੇ ਆਧਾਰਿਤ ਪਲੇਟਫਾਰਮ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੰਤੁਸ਼ਟ ਹਾਂ ਜੋ ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ ਹੈ। ਪਰ ਅੱਜ, ਮੈਂ ਆਪਣੇ ਖੁਦ ਦੇ IoT ਪਲੇਟਫਾਰਮ ਨੂੰ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬਲੇਨਾ 'ਤੇ ਇੱਕ ਡੂੰਘਾਈ ਨਾਲ ਵਿਚਾਰ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਾਂਗਾ.

ਕਿਉਂਕਿ ਆਖਰਕਾਰ ਇਹ ਜ਼ਿਆਦਾਤਰ ਉਹ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਅਸੀਂ ਕੀਤਾ ਹੈ, ਅਤੇ ਓਪਨਬਲੇਨਾ ਮੁਫਤ ਅਤੇ ਖੁੱਲਾ ਸਰੋਤ ਹੈ।

ਇਹ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦਾ ਹੈ ਕਿ ਨਾ ਸਿਰਫ਼ ਅੱਪਡੇਟ ਕਿਵੇਂ ਭੇਜਣੇ ਹਨ, ਸਗੋਂ ਇੱਕ VPN ਵੀ ਪਹਿਲਾਂ ਹੀ ਬਣਾਇਆ ਗਿਆ ਹੈ ਅਤੇ ਇੱਕ IoT ਵਾਤਾਵਰਨ ਵਿੱਚ ਵਰਤੋਂ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ।

ਅਤੇ ਹੁਣੇ ਹੁਣੇ, ਉਨ੍ਹਾਂ ਨੇ ਆਪਣੀ ਰਿਲੀਜ਼ ਵੀ ਕੀਤੀ ਹਾਰਡਵੇਅਰ, ਜੋ ਉਹਨਾਂ ਦੇ ਈਕੋਸਿਸਟਮ ਨਾਲ ਆਸਾਨੀ ਨਾਲ ਜੁੜਦਾ ਹੈ।

ਹੇ, ਗੁੰਮ ਹੋਏ ਸਕੂਟਰ ਬਾਰੇ ਕੀ?

ਇਸ ਲਈ ਸਕੂਟਰ, "ਰਾਲਫ਼", ਬਿਨਾਂ ਕਿਸੇ ਟਰੇਸ ਦੇ ਗਾਇਬ ਹੋ ਗਿਆ.

ਅਸੀਂ ਤੁਰੰਤ ਆਪਣੇ "ਐਡਮਿਨ ਪੈਨਲ" ਵਿੱਚ ਨਕਸ਼ੇ ਨੂੰ ਵੇਖਣ ਲਈ ਭੱਜੇ, ਜਿਸ ਵਿੱਚ ਇਨਫਲੂਕਸਡੀਬੀ ਤੋਂ GPS ਮੈਟ੍ਰਿਕਸ ਡੇਟਾ ਸੀ।

ਮਾਨੀਟਰਿੰਗ ਡੇਟਾ ਲਈ ਧੰਨਵਾਦ, ਅਸੀਂ ਆਸਾਨੀ ਨਾਲ ਇਹ ਨਿਰਧਾਰਿਤ ਕੀਤਾ ਕਿ ਸਕੂਟਰ ਪਿਛਲੇ ਦਿਨ 21:00 ਵਜੇ ਦੇ ਆਸਪਾਸ ਪਾਰਕਿੰਗ ਸਥਾਨ ਤੋਂ ਬਾਹਰ ਨਿਕਲਿਆ, ਕਿਸੇ ਖੇਤਰ ਵਿੱਚ ਅੱਧਾ ਘੰਟਾ ਚਲਾਇਆ ਅਤੇ ਕੁਝ ਜਰਮਨ ਘਰ ਦੇ ਕੋਲ ਸਵੇਰੇ 5 ਵਜੇ ਤੱਕ ਪਾਰਕ ਕੀਤਾ ਗਿਆ।

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

ਹਾਲਾਂਕਿ, ਘਰ ਦਾ ਮਾਲਕ ਵੀ ਇਸ ਗੱਲ ਤੋਂ ਹੈਰਾਨ ਸੀ, ਕਿਉਂਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਇਸ ਸਕੂਟਰ 'ਤੇ ਬੀਤੀ ਰਾਤ ਦਫਤਰ ਤੋਂ ਘਰ ਆਇਆ ਸੀ।

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

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

ਸਰੋਤ: www.habr.com