ಕಾಣೆಯಾದ ಸ್ಕೂಟರ್ ಅಥವಾ ಒಂದು IoT ಮಾನಿಟರಿಂಗ್ ಕಥೆಯನ್ನು ಹಿಂತಿರುಗಿಸಿ

ಒಂದು ವರ್ಷದ ಹಿಂದೆ ನಾವು ಪ್ರಚಾರದ ಯೋಜನೆಯ ಪ್ರಾಯೋಗಿಕ ಆವೃತ್ತಿಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಎಲೆಕ್ಟ್ರಿಕ್ ಸ್ಕೂಟರ್‌ಗಳ ವಿಕೇಂದ್ರೀಕೃತ ಬಾಡಿಗೆ.

ಆರಂಭದಲ್ಲಿ, ಯೋಜನೆಯನ್ನು ರೋಡ್-ಟು-ಬಾರ್ಸಿಲೋನಾ ಎಂದು ಕರೆಯಲಾಯಿತು, ನಂತರ ಅದು ರೋಡ್-ಟು-ಬರ್ಲಿನ್ ಆಗಿ ಮಾರ್ಪಟ್ಟಿತು (ಆದ್ದರಿಂದ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳಲ್ಲಿ R2B), ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಇದನ್ನು xRide ಎಂದು ಕರೆಯಲಾಯಿತು.

ಯೋಜನೆಯ ಮುಖ್ಯ ಆಲೋಚನೆ ಹೀಗಿತ್ತು: ಕೇಂದ್ರೀಕೃತ ಕಾರು ಅಥವಾ ಸ್ಕೂಟರ್ ಬಾಡಿಗೆ ಸೇವೆಯನ್ನು ಹೊಂದುವ ಬದಲು (ನಾವು ಸ್ಕೂಟರ್ ಅಥವಾ ಎಲೆಕ್ಟ್ರಿಕ್ ಮೋಟಾರ್‌ಸೈಕಲ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ, ಕಿಕ್ಸ್‌ಕೂಟರ್ / ಸ್ಕೂಟರ್‌ಗಳಲ್ಲ) ನಾವು ವಿಕೇಂದ್ರೀಕೃತ ಬಾಡಿಗೆಗೆ ವೇದಿಕೆಯನ್ನು ಮಾಡಲು ಬಯಸಿದ್ದೇವೆ. ನಾವು ಎದುರಿಸಿದ ತೊಂದರೆಗಳ ಬಗ್ಗೆ ಈಗಾಗಲೇ ಮೊದಲೇ ಬರೆದಿದ್ದಾರೆ.

ಆರಂಭದಲ್ಲಿ, ಯೋಜನೆಯು ಕಾರುಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿದೆ, ಆದರೆ ಗಡುವು, ತಯಾರಕರೊಂದಿಗೆ ಅತ್ಯಂತ ದೀರ್ಘ ಸಂವಹನ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸುರಕ್ಷತಾ ನಿರ್ಬಂಧಗಳ ಕಾರಣ, ಪೈಲಟ್‌ಗಾಗಿ ವಿದ್ಯುತ್ ಸ್ಕೂಟರ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಯಿತು.

ಬಳಕೆದಾರರು ಫೋನ್‌ನಲ್ಲಿ iOS ಅಥವಾ Android ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದರು, ಅವರು ಇಷ್ಟಪಟ್ಟ ಸ್ಕೂಟರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಿದರು, ನಂತರ ಫೋನ್ ಮತ್ತು ಸ್ಕೂಟರ್ ಪೀರ್-ಟು-ಪೀರ್ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಿತು, ETH ಅನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಲಾಯಿತು ಮತ್ತು ಬಳಕೆದಾರರು ಈ ಮೂಲಕ ಸ್ಕೂಟರ್ ಅನ್ನು ಆನ್ ಮಾಡುವ ಮೂಲಕ ಸವಾರಿಯನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು. ದೂರವಾಣಿ. ಪ್ರವಾಸದ ಕೊನೆಯಲ್ಲಿ, ಫೋನ್‌ನಲ್ಲಿ ಬಳಕೆದಾರರ ವ್ಯಾಲೆಟ್‌ನಿಂದ Ethereum ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರವಾಸಕ್ಕೆ ಪಾವತಿಸಲು ಸಹ ಸಾಧ್ಯವಿದೆ.

ಸ್ಕೂಟರ್‌ಗಳ ಜೊತೆಗೆ, ಬಳಕೆದಾರರು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ “ಸ್ಮಾರ್ಟ್ ಚಾರ್ಜರ್‌ಗಳನ್ನು” ನೋಡಿದ್ದಾರೆ, ಅದನ್ನು ಭೇಟಿ ಮಾಡುವ ಮೂಲಕ ಬಳಕೆದಾರರು ಪ್ರಸ್ತುತ ಬ್ಯಾಟರಿ ಕಡಿಮೆಯಿದ್ದರೆ ಅದನ್ನು ಬದಲಾಯಿಸಬಹುದು.

ಇದು ಸಾಮಾನ್ಯವಾಗಿ ನಮ್ಮ ಪೈಲಟ್ ಹೇಗಿತ್ತು, ಕಳೆದ ವರ್ಷ ಸೆಪ್ಟೆಂಬರ್‌ನಲ್ಲಿ ಎರಡು ಜರ್ಮನ್ ನಗರಗಳಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಯಿತು: ಬಾನ್ ಮತ್ತು ಬರ್ಲಿನ್.

ತದನಂತರ, ಒಂದು ದಿನ, ಬಾನ್‌ನಲ್ಲಿ, ಮುಂಜಾನೆ, ನಮ್ಮ ಬೆಂಬಲ ತಂಡವು (ಸ್ಕೂಟರ್‌ಗಳನ್ನು ಕೆಲಸದ ಕ್ರಮದಲ್ಲಿ ನಿರ್ವಹಿಸಲು ಸೈಟ್‌ನಲ್ಲಿದೆ) ಎಚ್ಚರಿಸಲಾಯಿತು: ಸ್ಕೂಟರ್‌ಗಳಲ್ಲಿ ಒಂದು ಜಾಡಿನ ಇಲ್ಲದೆ ಕಣ್ಮರೆಯಾಯಿತು.

ಅದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಮತ್ತು ಹಿಂದಿರುಗಿಸುವುದು ಹೇಗೆ?

ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ಇದರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ, ಆದರೆ ಮೊದಲು - ನಾವು ನಮ್ಮದೇ ಆದ IoT ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಅದನ್ನು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು.

ಏನು ಮತ್ತು ಏಕೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು: ಸ್ಕೂಟರ್‌ಗಳು, ಮೂಲಸೌಕರ್ಯಗಳು, ಚಾರ್ಜಿಂಗ್ ಸ್ಟೇಷನ್‌ಗಳು?

ಆದ್ದರಿಂದ, ನಮ್ಮ ಯೋಜನೆಯಲ್ಲಿ ನಾವು ಏನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಬಯಸಿದ್ದೇವೆ?

ಮೊದಲನೆಯದಾಗಿ, ಇವುಗಳು ಸ್ಕೂಟರ್‌ಗಳು - ಎಲೆಕ್ಟ್ರಿಕ್ ಸ್ಕೂಟರ್‌ಗಳು ಸಾಕಷ್ಟು ದುಬಾರಿಯಾಗಿದೆ, ನೀವು ಸಾಕಷ್ಟು ಸಿದ್ಧಪಡಿಸದೆ ಅಂತಹ ಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ; ಸಾಧ್ಯವಾದರೆ, ನೀವು ಸ್ಕೂಟರ್‌ಗಳ ಬಗ್ಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಯಸುತ್ತೀರಿ: ಅವುಗಳ ಸ್ಥಳ, ಚಾರ್ಜ್ ಮಟ್ಟ , ಇತ್ಯಾದಿ

ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಮ್ಮದೇ ಆದ ಐಟಿ ಮೂಲಸೌಕರ್ಯದ ಸ್ಥಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ನಾನು ಬಯಸುತ್ತೇನೆ - ಡೇಟಾಬೇಸ್‌ಗಳು, ಸೇವೆಗಳು ಮತ್ತು ಅವರು ಕೆಲಸ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ. "ಸ್ಮಾರ್ಟ್ ಚಾರ್ಜರ್‌ಗಳ" ಸ್ಥಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಸಹ ಅಗತ್ಯವಾಗಿತ್ತು, ಅವುಗಳು ಮುರಿದುಹೋದರೆ ಅಥವಾ ಪೂರ್ಣ ಬ್ಯಾಟರಿಗಳು ಖಾಲಿಯಾಗಿದ್ದರೆ.

ಸ್ಕೂಟರ್‌ಗಳು

ನಮ್ಮ ಸ್ಕೂಟರ್‌ಗಳು ಯಾವುವು ಮತ್ತು ಅವುಗಳ ಬಗ್ಗೆ ನಾವು ಏನು ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸಿದ್ದೇವೆ?

ಮೊದಲ ಮತ್ತು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ ಜಿಪಿಎಸ್ ನಿರ್ದೇಶಾಂಕಗಳು, ಏಕೆಂದರೆ ಅವರಿಗೆ ಧನ್ಯವಾದಗಳು ಅವರು ಎಲ್ಲಿದ್ದಾರೆ ಮತ್ತು ಅವರು ಎಲ್ಲಿ ಚಲಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.

ಮುಂದಿನದು ಬ್ಯಾಟರಿ ಚಾರ್ಜ್ ಆಗಿದೆ, ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು ನಾವು ಸ್ಕೂಟರ್‌ಗಳ ಚಾರ್ಜಿಂಗ್ ಅಂತ್ಯಗೊಳ್ಳುತ್ತಿದೆ ಎಂದು ನಿರ್ಧರಿಸಬಹುದು ಮತ್ತು ಜ್ಯೂಸರ್ ಅನ್ನು ಕಳುಹಿಸಬಹುದು ಅಥವಾ ಕನಿಷ್ಠ ಬಳಕೆದಾರರಿಗೆ ಎಚ್ಚರಿಕೆ ನೀಡಬಹುದು.

ಸಹಜವಾಗಿ, ನಮ್ಮ ಹಾರ್ಡ್‌ವೇರ್ ಘಟಕಗಳೊಂದಿಗೆ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಸಹ ಅಗತ್ಯವಾಗಿದೆ:

• ಬ್ಲೂಟೂತ್ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ?
• ಜಿಪಿಎಸ್ ಮಾಡ್ಯೂಲ್ ಸ್ವತಃ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ?
  • GPS ತಪ್ಪಾದ ನಿರ್ದೇಶಾಂಕಗಳನ್ನು ಕಳುಹಿಸಬಹುದು ಮತ್ತು ಸಿಲುಕಿಕೊಳ್ಳಬಹುದು ಎಂಬ ಅಂಶದೊಂದಿಗೆ ನಾವು ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಇದನ್ನು ಸ್ಕೂಟರ್‌ನಲ್ಲಿನ ಹೆಚ್ಚುವರಿ ತಪಾಸಣೆಗಳಿಂದ ಮಾತ್ರ ನಿರ್ಧರಿಸಬಹುದು,
    ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಬೆಂಬಲವನ್ನು ಸೂಚಿಸಿ

ಮತ್ತು ಕೊನೆಯದಾಗಿ: OS ಮತ್ತು ಪ್ರೊಸೆಸರ್, ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು ಡಿಸ್ಕ್ ಲೋಡ್‌ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಸಾಫ್ಟ್‌ವೇರ್‌ನ ಪರಿಶೀಲನೆಗಳು, ನಮಗೆ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿರುವ ನಮ್ಮ ಸ್ವಂತ ಮಾಡ್ಯೂಲ್‌ಗಳ ಚೆಕ್‌ಗಳೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ (ಜೋಲೋಕಾಮ್, ಕೀಕ್ಲಾಕ್).

ಹಾರ್ಡ್ವೇರ್

ನಮ್ಮ "ಕಬ್ಬಿಣದ" ಭಾಗ ಯಾವುದು?

ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಸಮಯದ ಚೌಕಟ್ಟು ಮತ್ತು ಕ್ಷಿಪ್ರ ಮೂಲಮಾದರಿಯ ಅಗತ್ಯವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, ನಾವು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮತ್ತು ಘಟಕಗಳ ಆಯ್ಕೆಗೆ ಸುಲಭವಾದ ಆಯ್ಕೆಯನ್ನು ಆರಿಸಿದ್ದೇವೆ - ರಾಸ್ಪ್ಬೆರಿ ಪೈ.
Rpi ಜೊತೆಗೆ, ನಾವು ಕಸ್ಟಮ್ ಬೋರ್ಡ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ (ಅಂತಿಮ ಪರಿಹಾರದ ಅಸೆಂಬ್ಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವೇಗಗೊಳಿಸಲು ನಾವೇ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಚೀನಾದಿಂದ ಆದೇಶಿಸಿದ್ದೇವೆ) ಮತ್ತು ಘಟಕಗಳ ಒಂದು ಸೆಟ್ - ರಿಲೇ (ಸ್ಕೂಟರ್ ಅನ್ನು ಆನ್ / ಆಫ್ ಮಾಡಲು), ಬ್ಯಾಟರಿ ಚಾರ್ಜ್ ರೀಡರ್, ಮೋಡೆಮ್, ಆಂಟೆನಾಗಳು. ಇದೆಲ್ಲವನ್ನೂ ವಿಶೇಷ "xRide ಬಾಕ್ಸ್" ನಲ್ಲಿ ಸಾಂದ್ರವಾಗಿ ಪ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ.

ಇಡೀ ಬಾಕ್ಸ್ ಹೆಚ್ಚುವರಿ ಪವರ್ ಬ್ಯಾಂಕ್‌ನಿಂದ ಚಾಲಿತವಾಗಿದೆ ಎಂದು ಸಹ ಗಮನಿಸಬೇಕು, ಇದು ಸ್ಕೂಟರ್‌ನ ಮುಖ್ಯ ಬ್ಯಾಟರಿಯಿಂದ ಚಾಲಿತವಾಗಿದೆ.

ಇಗ್ನಿಷನ್ ಕೀಲಿಯನ್ನು "ಆಫ್" ಸ್ಥಾನಕ್ಕೆ ತಿರುಗಿಸಿದ ನಂತರ ಮುಖ್ಯ ಬ್ಯಾಟರಿಯನ್ನು ತಕ್ಷಣವೇ ಆಫ್ ಮಾಡಲಾಗಿರುವುದರಿಂದ ಪ್ರವಾಸದ ಅಂತ್ಯದ ನಂತರವೂ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಬಳಸಲು ಮತ್ತು ಸ್ಕೂಟರ್ ಅನ್ನು ಆನ್ ಮಾಡಲು ಇದು ಸಾಧ್ಯವಾಗಿಸಿತು.

ಡಾಕರ್? ಸರಳ ಲಿನಕ್ಸ್? ಮತ್ತು ನಿಯೋಜನೆ

ನಾವು ಮೇಲ್ವಿಚಾರಣೆಗೆ ಹಿಂತಿರುಗೋಣ, ಆದ್ದರಿಂದ ರಾಸ್ಪ್ಬೆರಿ - ನಾವು ಏನು ಹೊಂದಿದ್ದೇವೆ?

ಭೌತಿಕ ಸಾಧನಗಳಿಗೆ ಘಟಕಗಳನ್ನು ನಿಯೋಜಿಸುವ, ನವೀಕರಿಸುವ ಮತ್ತು ವಿತರಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವೇಗಗೊಳಿಸಲು ನಾವು ಬಳಸಲು ಬಯಸಿದ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಡಾಕರ್.

ದುರದೃಷ್ಟವಶಾತ್, RPi ನಲ್ಲಿನ ಡಾಕರ್, ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೂ, ವಿಶೇಷವಾಗಿ ವಿದ್ಯುತ್ ಬಳಕೆಯ ವಿಷಯದಲ್ಲಿ ಹೆಚ್ಚಿನ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಹೊಂದಿದೆ ಎಂಬುದು ಶೀಘ್ರವಾಗಿ ಸ್ಪಷ್ಟವಾಯಿತು.

"ಸ್ಥಳೀಯ" OS ಅನ್ನು ಬಳಸುವ ವ್ಯತ್ಯಾಸವು ಅಷ್ಟು ಪ್ರಬಲವಾಗಿಲ್ಲದಿದ್ದರೂ, ಚಾರ್ಜ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ಕಳೆದುಕೊಳ್ಳುವ ಸಾಧ್ಯತೆಯ ಬಗ್ಗೆ ಎಚ್ಚರವಾಗಿರಲು ನಮಗೆ ಇನ್ನೂ ಸಾಕಾಗುತ್ತದೆ.

ಎರಡನೆಯ ಕಾರಣವೆಂದರೆ Node.js (sic!) ನಲ್ಲಿನ ನಮ್ಮ ಪಾಲುದಾರ ಲೈಬ್ರರಿಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ - ಇದು Go/C/C++ ನಲ್ಲಿ ಬರೆಯದ ಸಿಸ್ಟಮ್‌ನ ಏಕೈಕ ಘಟಕವಾಗಿದೆ.

ಲೈಬ್ರರಿಯ ಲೇಖಕರು ಯಾವುದೇ "ಸ್ಥಳೀಯ" ಭಾಷೆಗಳಲ್ಲಿ ಕೆಲಸದ ಆವೃತ್ತಿಯನ್ನು ಒದಗಿಸಲು ಸಮಯ ಹೊಂದಿಲ್ಲ.

ಕಡಿಮೆ-ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಾಧನಗಳಿಗೆ ನೋಡ್ ಸ್ವತಃ ಅತ್ಯಂತ ಸೊಗಸಾದ ಪರಿಹಾರವಲ್ಲ, ಆದರೆ ಗ್ರಂಥಾಲಯವು ತುಂಬಾ ಸಂಪನ್ಮೂಲ-ಹಸಿದಾಗಿತ್ತು.

ನಾವು ಬಯಸಿದ್ದರೂ ಸಹ, ಡಾಕರ್ ಅನ್ನು ಬಳಸುವುದು ನಮಗೆ ಹೆಚ್ಚು ಹೊರೆಯಾಗುತ್ತದೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ. ಆಯ್ಕೆಯು ಸ್ಥಳೀಯ ಓಎಸ್ ಪರವಾಗಿ ಮಾಡಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ಅದರ ಅಡಿಯಲ್ಲಿ ನೇರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

OS

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಮತ್ತೊಮ್ಮೆ, ಓಎಸ್ ಆಗಿ ಸರಳವಾದ ಆಯ್ಕೆಯನ್ನು ಆರಿಸಿದ್ದೇವೆ ಮತ್ತು ರಾಸ್ಪಿಯನ್ (ಪೈಗಾಗಿ ಡೆಬಿಯನ್ ಬಿಲ್ಡ್) ಅನ್ನು ಬಳಸಿದ್ದೇವೆ.

ನಾವು ನಮ್ಮ ಎಲ್ಲಾ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು Go ನಲ್ಲಿ ಬರೆಯುತ್ತೇವೆ, ಆದ್ದರಿಂದ ನಾವು ನಮ್ಮ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಮುಖ್ಯ ಹಾರ್ಡ್‌ವೇರ್ ಏಜೆಂಟ್ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಸಹ Go ನಲ್ಲಿ ಬರೆದಿದ್ದೇವೆ.

ಜಿಪಿಎಸ್, ಬ್ಲೂಟೂತ್, ಚಾರ್ಜ್ ಅನ್ನು ಓದುವುದು, ಸ್ಕೂಟರ್ ಆನ್ ಮಾಡುವುದು ಇತ್ಯಾದಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಅವನು ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ.

ನಿಯೋಜಿಸಿ

ಸಾಧನಗಳಿಗೆ (OTA) ನವೀಕರಣಗಳನ್ನು ತಲುಪಿಸುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಅಗತ್ಯತೆಯ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಯು ತಕ್ಷಣವೇ ಉದ್ಭವಿಸಿದೆ - ಎರಡೂ ನಮ್ಮ ಏಜೆಂಟ್/ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ನವೀಕರಣಗಳು ಮತ್ತು OS/ಫರ್ಮ್‌ವೇರ್‌ಗೆ ನವೀಕರಣಗಳು (ಏಜೆಂಟ್‌ನ ಹೊಸ ಆವೃತ್ತಿಗಳಿಗೆ ಕರ್ನಲ್‌ಗೆ ನವೀಕರಣಗಳು ಬೇಕಾಗಬಹುದು. ಅಥವಾ ಸಿಸ್ಟಮ್ ಘಟಕಗಳು, ಗ್ರಂಥಾಲಯಗಳು, ಇತ್ಯಾದಿ) .

ಮಾರುಕಟ್ಟೆಯ ದೀರ್ಘ ವಿಶ್ಲೇಷಣೆಯ ನಂತರ, ಸಾಧನಕ್ಕೆ ನವೀಕರಣಗಳನ್ನು ತಲುಪಿಸಲು ಸಾಕಷ್ಟು ಪರಿಹಾರಗಳಿವೆ ಎಂದು ಅದು ಬದಲಾಯಿತು.

swupd/SWUpdate/OSTree ನಂತಹ ತುಲನಾತ್ಮಕವಾಗಿ ಸರಳವಾದ, ಹೆಚ್ಚಾಗಿ ಅಪ್‌ಡೇಟ್/ಡ್ಯುಯಲ್-ಬೂಟ್ ಆಧಾರಿತ ಉಪಯುಕ್ತತೆಗಳಿಂದ ಮೆಂಡರ್ ಮತ್ತು ಬಲೆನಾದಂತಹ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗೆ.

ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಅಂತ್ಯದಿಂದ ಅಂತ್ಯದ ಪರಿಹಾರಗಳಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಆಯ್ಕೆಯು ತಕ್ಷಣವೇ ವೇದಿಕೆಗಳ ಮೇಲೆ ಬಿದ್ದಿತು.

ಸ್ವತಃ ಬಲೆನಾ ವಾಸ್ತವವಾಗಿ ಅದರ balenaEngine ಒಳಗೆ ಅದೇ ಡಾಕರ್ ಅನ್ನು ಬಳಸುತ್ತದೆ ಎಂಬ ಕಾರಣದಿಂದ ಹೊರಗಿಡಲಾಗಿದೆ.

ಆದರೆ ಇದರ ಹೊರತಾಗಿಯೂ, ನಾವು ಅವರ ಉತ್ಪನ್ನವನ್ನು ನಿರಂತರವಾಗಿ ಬಳಸುವುದನ್ನು ಕೊನೆಗೊಳಿಸಿದ್ದೇವೆ ಎಂದು ನಾನು ಗಮನಿಸುತ್ತೇನೆ ಬಾಲೆನಾ ಎಚರ್ SD ಕಾರ್ಡ್‌ಗಳಲ್ಲಿ ಫ್ಲಾಶ್ ಫರ್ಮ್‌ವೇರ್‌ಗಾಗಿ - ಇದಕ್ಕಾಗಿ ಸರಳ ಮತ್ತು ಅತ್ಯಂತ ಅನುಕೂಲಕರ ಉಪಯುಕ್ತತೆ.

ಆದ್ದರಿಂದ, ಅಂತಿಮವಾಗಿ ಆಯ್ಕೆಯು ಬಿದ್ದಿತು ಮೆಂಡರ್. ಮೆಂಡರ್ ಫರ್ಮ್‌ವೇರ್ ಅನ್ನು ಜೋಡಿಸಲು, ವಿತರಿಸಲು ಮತ್ತು ಸ್ಥಾಪಿಸಲು ಸಂಪೂರ್ಣ ವೇದಿಕೆಯಾಗಿದೆ.

ಒಟ್ಟಾರೆಯಾಗಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಮೆಂಡರ್ ಬಿಲ್ಡರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಮ್ಮ ಫರ್ಮ್‌ವೇರ್‌ನ ಸರಿಯಾದ ಆವೃತ್ತಿಯನ್ನು ನಿರ್ಮಿಸಲು ನಮಗೆ ಸುಮಾರು ಒಂದೂವರೆ ವಾರ ಬೇಕಾಯಿತು.
ಮತ್ತು ಅದರ ಬಳಕೆಯ ಜಟಿಲತೆಗಳಲ್ಲಿ ನಾವು ಹೆಚ್ಚು ಮುಳುಗಿದ್ದೇವೆ, ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಯೋಜಿಸಲು ನಾವು ಹೊಂದಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ಬೇಕಾಗುತ್ತದೆ ಎಂಬುದು ಹೆಚ್ಚು ಸ್ಪಷ್ಟವಾಯಿತು.

ಅಯ್ಯೋ, ನಮ್ಮ ಬಿಗಿಯಾದ ಗಡುವು ಎಂದರೆ ನಾವು ಮೆಂಡರ್ ಬಳಕೆಯನ್ನು ತ್ಯಜಿಸಲು ಮತ್ತು ಇನ್ನೂ ಸರಳವಾದದನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಒತ್ತಾಯಿಸಿದ್ದೇವೆ.

ಅನುಕಂಪ

ನಮ್ಮ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಸರಳವಾದ ಪರಿಹಾರವೆಂದರೆ ಅನ್ಸಿಬಲ್ ಅನ್ನು ಬಳಸುವುದು. ಪ್ರಾರಂಭಿಸಲು ಒಂದೆರಡು ಪ್ಲೇಬುಕ್‌ಗಳು ಸಾಕು.

ಅವರ ಮೂಲತತ್ವವೆಂದರೆ ನಾವು ಹೋಸ್ಟ್ (CI ಸರ್ವರ್) ನಿಂದ ssh ಮೂಲಕ ನಮ್ಮ ರಾಸ್‌ಬೆರ್ರಿಸ್‌ಗೆ ಸರಳವಾಗಿ ಸಂಪರ್ಕಿಸಿದ್ದೇವೆ ಮತ್ತು ಅವರಿಗೆ ನವೀಕರಣಗಳನ್ನು ವಿತರಿಸಿದ್ದೇವೆ.

ಅತ್ಯಂತ ಆರಂಭದಲ್ಲಿ, ಎಲ್ಲವೂ ಸರಳವಾಗಿತ್ತು - ನೀವು ಸಾಧನಗಳೊಂದಿಗೆ ಒಂದೇ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿರಬೇಕು, Wi-Fi ಮೂಲಕ ಸುರಿಯುವುದು ಮಾಡಲಾಯಿತು.

ಕಛೇರಿಯಲ್ಲಿ ಒಂದೇ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸಂಪರ್ಕಗೊಂಡಿರುವ ಒಂದು ಡಜನ್ ಪರೀಕ್ಷಾ ರಾಸ್್ಬೆರ್ರಿಸ್ ಇತ್ತು, ಪ್ರತಿ ಸಾಧನವು ಅನ್ಸಿಬಲ್ ಇನ್ವೆಂಟರಿಯಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸ್ಥಿರ IP ವಿಳಾಸವನ್ನು ಹೊಂದಿದೆ.

ನಮ್ಮ ಮಾನಿಟರಿಂಗ್ ಏಜೆಂಟ್ ಅನ್ನು ಅಂತಿಮ ಸಾಧನಗಳಿಗೆ ತಲುಪಿಸಿದ ಅನ್ಸಿಬಲ್

3G / LTE

ದುರದೃಷ್ಟವಶಾತ್, ನಾವು ನಿಜವಾದ ಸ್ಕೂಟರ್‌ಗಳನ್ನು ಹೊಂದುವ ಮೊದಲು ಅನ್ಸಿಬಲ್‌ನ ಈ ಬಳಕೆಯ ಪ್ರಕರಣವು ಅಭಿವೃದ್ಧಿ ಮೋಡ್‌ನಲ್ಲಿ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಏಕೆಂದರೆ ಸ್ಕೂಟರ್‌ಗಳು, ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಒಂದು Wi-Fi ರೂಟರ್‌ಗೆ ಸಂಪರ್ಕದಲ್ಲಿ ಕುಳಿತುಕೊಳ್ಳುವುದಿಲ್ಲ, ನಿರಂತರವಾಗಿ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ನವೀಕರಣಗಳಿಗಾಗಿ ಕಾಯುತ್ತಿದೆ.

ವಾಸ್ತವದಲ್ಲಿ, ಸ್ಕೂಟರ್‌ಗಳು ಮೊಬೈಲ್ 3G/LTE ಹೊರತುಪಡಿಸಿ ಯಾವುದೇ ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ (ಮತ್ತು ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಅಲ್ಲ).

ಇದು ತಕ್ಷಣವೇ ಕಡಿಮೆ ಸಂಪರ್ಕ ವೇಗ ಮತ್ತು ಅಸ್ಥಿರ ಸಂವಹನದಂತಹ ಅನೇಕ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಮಿತಿಗಳನ್ನು ಹೇರುತ್ತದೆ.

ಆದರೆ ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ 3G/LTE ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ನಾವು ನೆಟ್‌ವರ್ಕ್‌ಗೆ ನಿಯೋಜಿಸಲಾದ ಸ್ಥಿರ IP ಅನ್ನು ಸರಳವಾಗಿ ಅವಲಂಬಿಸಲಾಗುವುದಿಲ್ಲ.

ಇದನ್ನು ಕೆಲವು ಸಿಮ್ ಕಾರ್ಡ್ ಪೂರೈಕೆದಾರರು ಭಾಗಶಃ ಪರಿಹರಿಸುತ್ತಾರೆ; ಸ್ಥಿರ IP ವಿಳಾಸಗಳೊಂದಿಗೆ IoT ಸಾಧನಗಳಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ವಿಶೇಷ ಸಿಮ್ ಕಾರ್ಡ್‌ಗಳು ಸಹ ಇವೆ. ಆದರೆ ನಾವು ಅಂತಹ ಸಿಮ್ ಕಾರ್ಡ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು IP ವಿಳಾಸಗಳನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.

ಸಹಜವಾಗಿ, ಕಾನ್ಸುಲ್‌ನಂತೆ ಎಲ್ಲೋ ಸೇವೆಯ ಅನ್ವೇಷಣೆಯಂತಹ ಐಪಿ ವಿಳಾಸಗಳ ನೋಂದಣಿಯನ್ನು ಮಾಡಲು ಆಲೋಚನೆಗಳು ಇದ್ದವು, ಆದರೆ ನಾವು ಅಂತಹ ಆಲೋಚನೆಗಳನ್ನು ತ್ಯಜಿಸಬೇಕಾಗಿತ್ತು, ಏಕೆಂದರೆ ನಮ್ಮ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಐಪಿ ವಿಳಾಸವು ಆಗಾಗ್ಗೆ ಬದಲಾಗಬಹುದು, ಇದು ದೊಡ್ಡ ಅಸ್ಥಿರತೆಗೆ ಕಾರಣವಾಯಿತು.

ಈ ಕಾರಣಕ್ಕಾಗಿ, ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ತಲುಪಿಸಲು ಅತ್ಯಂತ ಅನುಕೂಲಕರವಾದ ಬಳಕೆಯು ಪುಲ್ ಮಾಡೆಲ್ ಅನ್ನು ಬಳಸುವುದಿಲ್ಲ, ಅಲ್ಲಿ ನಾವು ಅಗತ್ಯವಾದ ಮೆಟ್ರಿಕ್‌ಗಳಿಗಾಗಿ ಸಾಧನಗಳಿಗೆ ಹೋಗುತ್ತೇವೆ, ಆದರೆ ತಳ್ಳುವ, ಸಾಧನದಿಂದ ನೇರವಾಗಿ ಸರ್ವರ್‌ಗೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ತಲುಪಿಸುತ್ತೇವೆ.

VPN

ಈ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವಾಗಿ, ನಾವು VPN ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ - ನಿರ್ದಿಷ್ಟವಾಗಿ ವೈರ್‌ಗಾರ್ಡ್.

VPN ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕಗೊಂಡಿರುವ ಸಿಸ್ಟಮ್‌ನ ಪ್ರಾರಂಭದಲ್ಲಿ ಗ್ರಾಹಕರು (ಸ್ಕೂಟರ್‌ಗಳು) ಮತ್ತು ಅವರಿಗೆ ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ನವೀಕರಣಗಳನ್ನು ನೀಡಲು ಈ ಸುರಂಗವನ್ನು ಬಳಸಲಾಗಿದೆ.

ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಅದೇ ಸುರಂಗವನ್ನು ಮೇಲ್ವಿಚಾರಣೆಗಾಗಿ ಬಳಸಬಹುದು, ಆದರೆ ಅಂತಹ ಸಂಪರ್ಕವು ಸರಳವಾದ ತಳ್ಳುವಿಕೆಗಿಂತ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ ಮತ್ತು ಕಡಿಮೆ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ.

ಮೇಘ ಸಂಪನ್ಮೂಲಗಳು

ಕೊನೆಯದಾಗಿ, ನಮ್ಮ ಕ್ಲೌಡ್ ಸೇವೆಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಅವಶ್ಯಕ, ಏಕೆಂದರೆ ನಾವು ಅವುಗಳಿಗೆ ಕುಬರ್ನೆಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತೇವೆ, ಆದ್ದರಿಂದ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ನಿಯೋಜಿಸುವುದು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳವಾಗಿದೆ. ತಾತ್ತ್ವಿಕವಾಗಿ, ಬಳಸುವುದು ಹೆಲ್ಮ್, ನಿಯೋಜನೆಗಾಗಿ, ನಾವು ಅದನ್ನು ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಬಳಸುತ್ತೇವೆ. ಮತ್ತು, ಸಹಜವಾಗಿ, ಮೋಡವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ನೀವು ಸ್ಕೂಟರ್‌ಗಳಂತೆಯೇ ಅದೇ ಪರಿಹಾರಗಳನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ.

ನೀಡಿದ

ಓಹ್, ನಾವು ವಿವರಣೆಯನ್ನು ವಿಂಗಡಿಸಿರುವಂತೆ ತೋರುತ್ತಿದೆ, ಕೊನೆಯಲ್ಲಿ ನಮಗೆ ಬೇಕಾದುದನ್ನು ಪಟ್ಟಿ ಮಾಡೋಣ:

• ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಈಗಾಗಲೇ ಮೇಲ್ವಿಚಾರಣೆ ಅಗತ್ಯವಾಗಿರುವುದರಿಂದ ತ್ವರಿತ ಪರಿಹಾರ
• ಪರಿಮಾಣ/ಪ್ರಮಾಣ - ಹಲವು ಮೆಟ್ರಿಕ್‌ಗಳ ಅಗತ್ಯವಿದೆ
• ಲಾಗ್ ಸಂಗ್ರಹಣೆ ಅಗತ್ಯವಿದೆ
• ವಿಶ್ವಾಸಾರ್ಹತೆ - ಯಶಸ್ಸನ್ನು ಪ್ರಾರಂಭಿಸಲು ಡೇಟಾ ನಿರ್ಣಾಯಕವಾಗಿದೆ
• ನೀವು ಪುಲ್ ಮಾದರಿಯನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ - ನಿಮಗೆ ಪುಶ್ ಅಗತ್ಯವಿದೆ
• ನಮಗೆ ಹಾರ್ಡ್‌ವೇರ್ ಮಾತ್ರವಲ್ಲದೆ ಕ್ಲೌಡ್‌ನ ಏಕೀಕೃತ ಮೇಲ್ವಿಚಾರಣೆಯ ಅಗತ್ಯವಿದೆ

ಅಂತಿಮ ಚಿತ್ರವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ

ಸ್ಟಾಕ್ ಆಯ್ಕೆ

ಆದ್ದರಿಂದ, ಮಾನಿಟರಿಂಗ್ ಸ್ಟಾಕ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಪ್ರಶ್ನೆಯನ್ನು ನಾವು ಎದುರಿಸಿದ್ದೇವೆ.

ಮೊದಲನೆಯದಾಗಿ, ನಮ್ಮ ಎಲ್ಲಾ ಅವಶ್ಯಕತೆಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಪೂರೈಸುವ ಅತ್ಯಂತ ಸಂಪೂರ್ಣವಾದ ಆಲ್-ಇನ್-ಒನ್ ಪರಿಹಾರವನ್ನು ನಾವು ಹುಡುಕುತ್ತಿದ್ದೇವೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ನಮ್ಮ ಅಗತ್ಯಗಳಿಗೆ ತಕ್ಕಂತೆ ಅದರ ಬಳಕೆಯನ್ನು ಸರಿಹೊಂದಿಸಲು ಸಾಕಷ್ಟು ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ. ಆದರೂ, ನಾವು ಹಾರ್ಡ್‌ವೇರ್, ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಡೆಡ್‌ಲೈನ್‌ಗಳಿಂದ ನಮ್ಮ ಮೇಲೆ ಅನೇಕ ನಿರ್ಬಂಧಗಳನ್ನು ಹೇರಿದ್ದೇವೆ.

ನಂತಹ ಪೂರ್ಣ ಪ್ರಮಾಣದ ವ್ಯವಸ್ಥೆಗಳಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಬೃಹತ್ ವೈವಿಧ್ಯಮಯ ಮೇಲ್ವಿಚಾರಣಾ ಪರಿಹಾರಗಳಿವೆ ನಾಗಯೋಸ್, ಐಸಿಂಗ್ ಅಥವಾ ಝಬ್ಬಿಕ್ಸ್ ಮತ್ತು ಫ್ಲೀಟ್ ನಿರ್ವಹಣೆಗೆ ಸಿದ್ಧ ಪರಿಹಾರಗಳೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ಆರಂಭದಲ್ಲಿ, ಎರಡನೆಯದು ನಮಗೆ ಸೂಕ್ತವಾದ ಪರಿಹಾರವೆಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಕೆಲವರು ಸಂಪೂರ್ಣ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಹೊಂದಿಲ್ಲ, ಇತರರು ಉಚಿತ ಆವೃತ್ತಿಗಳ ತೀವ್ರವಾಗಿ ಸೀಮಿತ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿದ್ದರು, ಮತ್ತು ಇತರರು ನಮ್ಮ "ಬಯಕೆಗಳನ್ನು" ಒಳಗೊಳ್ಳಲಿಲ್ಲ ಅಥವಾ ನಮ್ಮ ಸನ್ನಿವೇಶಗಳಿಗೆ ಹೊಂದಿಕೊಳ್ಳುವಷ್ಟು ಹೊಂದಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಕೆಲವು ಸರಳವಾಗಿ ಹಳೆಯದಾಗಿವೆ.

ಇದೇ ರೀತಿಯ ಹಲವಾರು ಪರಿಹಾರಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿದ ನಂತರ, ಇದೇ ರೀತಿಯ ಸ್ಟಾಕ್ ಅನ್ನು ನಾವೇ ಜೋಡಿಸುವುದು ಸುಲಭ ಮತ್ತು ವೇಗವಾಗಿರುತ್ತದೆ ಎಂಬ ತೀರ್ಮಾನಕ್ಕೆ ನಾವು ಶೀಘ್ರವಾಗಿ ಬಂದಿದ್ದೇವೆ. ಹೌದು, ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಸಿದ್ಧವಾದ ಫ್ಲೀಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ನಿಯೋಜಿಸುವುದಕ್ಕಿಂತ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿರುತ್ತದೆ, ಆದರೆ ನಾವು ರಾಜಿ ಮಾಡಿಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ.

ಬಹುತೇಕ ನಿಸ್ಸಂಶಯವಾಗಿ, ಎಲ್ಲಾ ಅಗಾಧವಾದ ಪರಿಹಾರಗಳಲ್ಲಿ, ನಮಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಸರಿಹೊಂದುವಂತಹ ಸಿದ್ಧವಾದವು ಈಗಾಗಲೇ ಇದೆ, ಆದರೆ ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸ್ಟಾಕ್ ಅನ್ನು ನಮ್ಮದೇ ಆದ ಮೇಲೆ ಜೋಡಿಸುವುದು ಮತ್ತು ಅದನ್ನು "ನಮಗಾಗಿ" ಕಸ್ಟಮೈಸ್ ಮಾಡುವುದು ಹೆಚ್ಚು ವೇಗವಾಗಿದೆ. ಸಿದ್ಧ ಉತ್ಪನ್ನಗಳ ಪರೀಕ್ಷೆ.

ಈ ಎಲ್ಲದರ ಜೊತೆಗೆ, ನಾವು ಸಂಪೂರ್ಣ ಮಾನಿಟರಿಂಗ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ನಾವೇ ಜೋಡಿಸಲು ಪ್ರಯತ್ನಿಸಲಿಲ್ಲ, ಆದರೆ ಹೆಚ್ಚು ಕ್ರಿಯಾತ್ಮಕವಾದ “ಸಿದ್ಧ-ಸಿದ್ಧ” ಸ್ಟ್ಯಾಕ್‌ಗಳನ್ನು ಹುಡುಕುತ್ತಿದ್ದೇವೆ, ಅವುಗಳನ್ನು ಸುಲಭವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಮಾತ್ರ.

(ಬಿ) ELK?

ವಾಸ್ತವವಾಗಿ ಪರಿಗಣಿಸಲಾದ ಮೊದಲ ಪರಿಹಾರವೆಂದರೆ ಪ್ರಸಿದ್ಧ ELK ಸ್ಟಾಕ್.
ವಾಸ್ತವವಾಗಿ, ಇದನ್ನು BELK ಎಂದು ಕರೆಯಬೇಕು, ಏಕೆಂದರೆ ಅದು ಬೀಟ್ಸ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ - https://www.elastic.co/what-is/elk-stack

ಸಹಜವಾಗಿ, ಮೇಲ್ವಿಚಾರಣಾ ಕ್ಷೇತ್ರದಲ್ಲಿ ELK ಅತ್ಯಂತ ಪ್ರಸಿದ್ಧ ಮತ್ತು ಶಕ್ತಿಯುತ ಪರಿಹಾರಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ ಮತ್ತು ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು ಇನ್ನೂ ಹೆಚ್ಚು.

ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ELK ಅನ್ನು ಬಳಸಲಾಗುವುದು ಮತ್ತು ಪ್ರೊಮೆಥಿಯಸ್‌ನಿಂದ ಪಡೆದ ಮೆಟ್ರಿಕ್‌ಗಳ ದೀರ್ಘಾವಧಿಯ ಸಂಗ್ರಹಣೆಯನ್ನು ನಾವು ಉದ್ದೇಶಿಸಿದ್ದೇವೆ.

ದೃಶ್ಯೀಕರಣಕ್ಕಾಗಿ ನೀವು ಗ್ರಾಫನ್ ಅನ್ನು ಬಳಸಬಹುದು.

ವಾಸ್ತವವಾಗಿ, ಹೊಸ ELK ಸ್ಟಾಕ್ ಸ್ವತಂತ್ರವಾಗಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು (ಮೆಟ್ರಿಕ್‌ಬೀಟ್), ಮತ್ತು ಕಿಬಾನಾ ಸಹ ಅವುಗಳನ್ನು ಪ್ರದರ್ಶಿಸಬಹುದು.

ಆದರೆ ಇನ್ನೂ, ELK ಆರಂಭದಲ್ಲಿ ಲಾಗ್‌ಗಳಿಂದ ಬೆಳೆದಿದೆ ಮತ್ತು ಇಲ್ಲಿಯವರೆಗೆ ಮೆಟ್ರಿಕ್‌ಗಳ ಕ್ರಿಯಾತ್ಮಕತೆಯು ಹಲವಾರು ಗಂಭೀರ ನ್ಯೂನತೆಗಳನ್ನು ಹೊಂದಿದೆ:

• ಪ್ರಮೀತಿಯಸ್‌ಗಿಂತ ಗಮನಾರ್ಹವಾಗಿ ನಿಧಾನ
• ಪ್ರಮೀತಿಯಸ್‌ಗಿಂತ ಕಡಿಮೆ ಸ್ಥಳಗಳಲ್ಲಿ ಸಂಯೋಜನೆಗೊಳ್ಳುತ್ತದೆ
• ಅವರಿಗೆ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಹೊಂದಿಸುವುದು ಕಷ್ಟ
• ಮೆಟ್ರಿಕ್ಸ್ ಸಾಕಷ್ಟು ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ
• ಕಿಬಾನ್‌ನಲ್ಲಿ ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ಹೊಂದಿಸುವುದು ಗ್ರಾಫಾನ್‌ಗಿಂತ ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ

ಸಾಮಾನ್ಯವಾಗಿ, ELK ನಲ್ಲಿನ ಮೆಟ್ರಿಕ್‌ಗಳು ಭಾರವಾಗಿರುತ್ತದೆ ಮತ್ತು ಇತರ ಪರಿಹಾರಗಳಂತೆ ಇನ್ನೂ ಅನುಕೂಲಕರವಾಗಿಲ್ಲ, ಅವುಗಳಲ್ಲಿ ಈಗ ಕೇವಲ ಪ್ರಮೀತಿಯಸ್‌ಗಿಂತ ಹೆಚ್ಚಿನವುಗಳಿವೆ: TSDB, ವಿಕ್ಟೋರಿಯಾ ಮೆಟ್ರಿಕ್ಸ್, ಕಾರ್ಟೆಕ್ಸ್, ಇತ್ಯಾದಿ. ಸಹಜವಾಗಿ, ನಾನು ಈಗಿನಿಂದಲೇ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಆಲ್ ಇನ್ ಒನ್ ಪರಿಹಾರವನ್ನು ಹೊಂದಲು ಬಯಸುತ್ತೇನೆ, ಆದರೆ ಮೆಟ್ರಿಕ್‌ಬೀಟ್‌ನ ವಿಷಯದಲ್ಲಿ ಹಲವಾರು ರಾಜಿಗಳಿವೆ.

ಮತ್ತು ELK ಸ್ಟಾಕ್ ಸ್ವತಃ ಹಲವಾರು ಕಷ್ಟಕರ ಕ್ಷಣಗಳನ್ನು ಹೊಂದಿದೆ:

• ನೀವು ಸಾಕಷ್ಟು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ ಅದು ಭಾರವಾಗಿರುತ್ತದೆ, ಕೆಲವೊಮ್ಮೆ ತುಂಬಾ ಭಾರವಾಗಿರುತ್ತದೆ
• ನೀವು ಅದನ್ನು "ಅಡುಗೆ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ತಿಳಿಯಬೇಕು" - ನೀವು ಅದನ್ನು ಅಳೆಯಬೇಕು, ಆದರೆ ಇದನ್ನು ಮಾಡುವುದು ಕ್ಷುಲ್ಲಕವಲ್ಲ
• ಸ್ಟ್ರಿಪ್ಡ್ ಡೌನ್ ಉಚಿತ ಆವೃತ್ತಿ - ಉಚಿತ ಆವೃತ್ತಿಯು ಸಾಮಾನ್ಯ ಎಚ್ಚರಿಕೆಯನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು ಆಯ್ಕೆಯ ಸಮಯದಲ್ಲಿ ಯಾವುದೇ ದೃಢೀಕರಣ ಇರಲಿಲ್ಲ

ಇತ್ತೀಚೆಗೆ ಕೊನೆಯ ಹಂತವು ಉತ್ತಮವಾಗಿದೆ ಮತ್ತು ಹೆಚ್ಚುವರಿಯಾಗಿದೆ ಎಂದು ನಾನು ಹೇಳಲೇಬೇಕು ಓಪನ್ ಸೋರ್ಸ್ ಎಕ್ಸ್-ಪ್ಯಾಕ್‌ನಲ್ಲಿ ಔಟ್‌ಪುಟ್ (ದೃಢೀಕರಣವನ್ನು ಒಳಗೊಂಡಂತೆ) ಬೆಲೆ ಮಾದರಿಯು ಸ್ವತಃ ಬದಲಾಗಲಾರಂಭಿಸಿತು.

ಆದರೆ ನಾವು ಈ ಪರಿಹಾರವನ್ನು ನಿಯೋಜಿಸಲು ಹೋಗುವ ಸಮಯದಲ್ಲಿ, ಯಾವುದೇ ಎಚ್ಚರಿಕೆ ಇರಲಿಲ್ಲ.
ಬಹುಶಃ ನಾವು ElastAlert ಅಥವಾ ಇತರ ಸಮುದಾಯ ಪರಿಹಾರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಏನನ್ನಾದರೂ ನಿರ್ಮಿಸಲು ಪ್ರಯತ್ನಿಸಿರಬಹುದು, ಆದರೆ ನಾವು ಇನ್ನೂ ಇತರ ಪರ್ಯಾಯಗಳನ್ನು ಪರಿಗಣಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

ಲೋಕಿ - ಗ್ರಾಫನಾ - ಪ್ರಮೀತಿಯಸ್

ಈ ಸಮಯದಲ್ಲಿ, ಮಾನಿಟರಿಂಗ್ ಸ್ಟಾಕ್ ಅನ್ನು ಮೆಟ್ರಿಕ್ಸ್ ಪೂರೈಕೆದಾರರಾಗಿ, ಲಾಗ್‌ಗಳಿಗಾಗಿ ಲೋಕಿ, ಮತ್ತು ದೃಶ್ಯೀಕರಣಕ್ಕಾಗಿ ನೀವು ಅದೇ ಗ್ರಾಫಾನಾವನ್ನು ಬಳಸಬಹುದು ಎಂಬುದಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಮಾನಿಟರಿಂಗ್ ಸ್ಟಾಕ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ.

ದುರದೃಷ್ಟವಶಾತ್, ಯೋಜನೆಯ ಮಾರಾಟದ ಪೈಲಟ್ ಪ್ರಾರಂಭವಾಗುವ ಸಮಯದಲ್ಲಿ (ಸೆಪ್ಟೆಂಬರ್-ಅಕ್ಟೋಬರ್ 19), ಲೋಕಿ ಇನ್ನೂ ಬೀಟಾ ಆವೃತ್ತಿ 0.3-0.4 ನಲ್ಲಿದ್ದರು ಮತ್ತು ಅಭಿವೃದ್ಧಿಯ ಪ್ರಾರಂಭದ ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಉತ್ಪಾದನೆಯ ಪರಿಹಾರವೆಂದು ಪರಿಗಣಿಸಲಾಗಲಿಲ್ಲ. ಎಲ್ಲಾ.

ಗಂಭೀರ ಯೋಜನೆಗಳಲ್ಲಿ ಲೋಕಿ ಅನ್ನು ನಿಜವಾಗಿ ಬಳಸುವಲ್ಲಿ ನನಗೆ ಇನ್ನೂ ಅನುಭವವಿಲ್ಲ, ಆದರೆ ಕುಬರ್ನೆಟ್‌ಗಳಲ್ಲಿನ ಬೇರ್-ಮೆಟಲ್ ಮತ್ತು ಪಾಡ್‌ಗಳೆರಡಕ್ಕೂ Promtail (ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಏಜೆಂಟ್) ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾನು ಹೇಳಬಲ್ಲೆ.

ಟಿಕ್

ELK ಸ್ಟಾಕ್‌ಗೆ ಬಹುಶಃ ಅತ್ಯಂತ ಯೋಗ್ಯವಾದ (ಏಕೈಕ?) ಪೂರ್ಣ-ವೈಶಿಷ್ಟ್ಯದ ಪರ್ಯಾಯವನ್ನು ಈಗ TICK ಸ್ಟಾಕ್ ಎಂದು ಕರೆಯಬಹುದು - ಟೆಲಿಗ್ರಾಫ್, ಇನ್‌ಫ್ಲಕ್ಸ್‌ಡಿಬಿ, ಕ್ರೊನೊಗ್ರಾಫ್, ಕಪಾಸಿಟರ್.

ಕೆಳಗಿನ ಎಲ್ಲಾ ಘಟಕಗಳನ್ನು ನಾನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸುತ್ತೇನೆ, ಆದರೆ ಸಾಮಾನ್ಯ ಕಲ್ಪನೆ ಹೀಗಿದೆ:

• ಟೆಲಿಗ್ರಾಫ್ - ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಏಜೆಂಟ್
• InfluxDB - ಮೆಟ್ರಿಕ್ಸ್ ಡೇಟಾಬೇಸ್
• ಕೆಪಾಸಿಟರ್ - ಎಚ್ಚರಿಕೆಗಾಗಿ ನೈಜ-ಸಮಯದ ಮೆಟ್ರಿಕ್ಸ್ ಪ್ರೊಸೆಸರ್
• ಕ್ರೊನೊಗ್ರಾಫ್ - ದೃಶ್ಯೀಕರಣಕ್ಕಾಗಿ ವೆಬ್ ಫಲಕ

InfluxDB, Kapacitor ಮತ್ತು Chronograf ಗಾಗಿ ನಾವು ಅವುಗಳನ್ನು ನಿಯೋಜಿಸಲು ಬಳಸಿದ ಅಧಿಕೃತ ಚುಕ್ಕಾಣಿ ಚಾರ್ಟ್‌ಗಳಿವೆ.

Influx 2.0 (beta) ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯಲ್ಲಿ, Kapacitor ಮತ್ತು Chronograf InfluxDB ಯ ಭಾಗವಾಯಿತು ಮತ್ತು ಇನ್ನು ಮುಂದೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದು ಗಮನಿಸಬೇಕು.

ಟೆಲಿಗ್ರಾಫ್

ಟೆಲಿಗ್ರಾಫ್ ರಾಜ್ಯ ಯಂತ್ರದಲ್ಲಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಅತ್ಯಂತ ಹಗುರವಾದ ಏಜೆಂಟ್.

ಅವರು ಎಲ್ಲವನ್ನೂ ಒಂದು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು nginx ಗೆ
ಸರ್ವರ್ Minecraft.

ಇದು ಹಲವಾರು ತಂಪಾದ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ:

• ವೇಗವಾದ ಮತ್ತು ಹಗುರವಾದ (ಗೋದಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ)
  • ಕನಿಷ್ಠ ಪ್ರಮಾಣದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತಿನ್ನುತ್ತದೆ
• ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಪುಶ್ ಮೆಟ್ರಿಕ್ಸ್
• ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ
  • ಯಾವುದೇ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಲ್ಲದೆ ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳು
  • ಸಂವೇದಕಗಳಿಂದ ಮಾಹಿತಿಯಂತಹ ಹಾರ್ಡ್‌ವೇರ್ ಮೆಟ್ರಿಕ್‌ಗಳು
  • ನಿಮ್ಮ ಸ್ವಂತ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸೇರಿಸುವುದು ತುಂಬಾ ಸುಲಭ
• ಬಾಕ್ಸ್ ಹೊರಗೆ ಸಾಕಷ್ಟು ಪ್ಲಗಿನ್‌ಗಳು
• ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ

ಪುಶ್ ಮೆಟ್ರಿಕ್‌ಗಳು ನಮಗೆ ಅಗತ್ಯವಾಗಿರುವುದರಿಂದ, ಎಲ್ಲಾ ಇತರ ಅನುಕೂಲಗಳು ಆಹ್ಲಾದಕರ ಸೇರ್ಪಡೆಗಳಿಗಿಂತ ಹೆಚ್ಚು.

ಲಾಗ್‌ಗಳನ್ನು ಲಾಗ್ ಮಾಡಲು ಹೆಚ್ಚುವರಿ ಉಪಯುಕ್ತತೆಗಳನ್ನು ಸಂಪರ್ಕಿಸುವ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರಣ ಏಜೆಂಟ್‌ನಿಂದ ಲಾಗ್‌ಗಳ ಸಂಗ್ರಹಣೆಯು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ.

ನೀವು ಬಳಸಿದರೆ ಲಾಗ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಒಳಹರಿವು ಅತ್ಯಂತ ಅನುಕೂಲಕರ ಅನುಭವವನ್ನು ನೀಡುತ್ತದೆ ಸಿಸ್ಲಾಗ್.

ನೀವು ಉಳಿದ ICK ಸ್ಟಾಕ್ ಅನ್ನು ಬಳಸದಿದ್ದರೂ ಸಹ, ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಟೆಲಿಗ್ರಾಫ್ ಸಾಮಾನ್ಯವಾಗಿ ಉತ್ತಮ ಏಜೆಂಟ್.

ಅನೇಕ ಜನರು ಇದನ್ನು ELK ಮತ್ತು ಅನುಕೂಲಕ್ಕಾಗಿ ವಿವಿಧ ಸಮಯ-ಸರಣಿ ಡೇಟಾಬೇಸ್‌ಗಳೊಂದಿಗೆ ದಾಟುತ್ತಾರೆ, ಏಕೆಂದರೆ ಇದು ಎಲ್ಲಿಯಾದರೂ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಬರೆಯಬಹುದು.

InfluxDB

InfluxDB TICK ಸ್ಟಾಕ್‌ನ ಮುಖ್ಯ ಕೋರ್ ಆಗಿದೆ, ಅವುಗಳೆಂದರೆ ಮೆಟ್ರಿಕ್‌ಗಳಿಗಾಗಿ ಸಮಯ-ಸರಣಿ ಡೇಟಾಬೇಸ್.
ಮೆಟ್ರಿಕ್‌ಗಳ ಜೊತೆಗೆ, ಇನ್‌ಫ್ಲಕ್ಸ್ ಲಾಗ್‌ಗಳನ್ನು ಸಹ ಸಂಗ್ರಹಿಸಬಹುದು, ಆದಾಗ್ಯೂ, ಮೂಲಭೂತವಾಗಿ, ಅದರ ಲಾಗ್‌ಗಳು ಕೇವಲ ಒಂದೇ ಮೆಟ್ರಿಕ್‌ಗಳಾಗಿವೆ, ಸಾಮಾನ್ಯ ಸಂಖ್ಯಾತ್ಮಕ ಸೂಚಕಗಳ ಬದಲಿಗೆ, ಮುಖ್ಯ ಕಾರ್ಯವನ್ನು ಲಾಗ್ ಪಠ್ಯದ ಸಾಲಿನಿಂದ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ.

InfluxDB ಅನ್ನು Go ನಲ್ಲಿಯೂ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ನಮ್ಮ (ಅತ್ಯಂತ ಶಕ್ತಿಯುತವಲ್ಲದ) ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ELK ಗೆ ಹೋಲಿಸಿದರೆ ಹೆಚ್ಚು ವೇಗವಾಗಿ ಚಲಿಸುವಂತೆ ತೋರುತ್ತಿದೆ.

ಇನ್‌ಫ್ಲಕ್ಸ್‌ನ ತಂಪಾದ ಪ್ರಯೋಜನಗಳಲ್ಲಿ ಒಂದಾದ ಡೇಟಾ ಪ್ರಶ್ನೆಗಳಿಗಾಗಿ ಅತ್ಯಂತ ಅನುಕೂಲಕರ ಮತ್ತು ಶ್ರೀಮಂತ API ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಅದನ್ನು ನಾವು ತುಂಬಾ ಸಕ್ರಿಯವಾಗಿ ಬಳಸಿದ್ದೇವೆ.

ಅನಾನುಕೂಲಗಳು - $$$ ಅಥವಾ ಸ್ಕೇಲಿಂಗ್?

ಟಿಕ್ ಸ್ಟಾಕ್ ನಾವು ಕಂಡುಹಿಡಿದ ಒಂದೇ ಒಂದು ನ್ಯೂನತೆಯನ್ನು ಹೊಂದಿದೆ - ಅದು ಪ್ರಿಯತಮೆ. ಇನ್ನಷ್ಟು.

ಉಚಿತ ಆವೃತ್ತಿಯಲ್ಲಿ ಇಲ್ಲದಿರುವ ಪಾವತಿಸಿದ ಆವೃತ್ತಿಯು ಏನು ಹೊಂದಿದೆ?

ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುವಂತೆ, TICK ಸ್ಟಾಕ್‌ನ ಪಾವತಿಸಿದ ಆವೃತ್ತಿ ಮತ್ತು ಉಚಿತದ ನಡುವಿನ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಸ್ಕೇಲಿಂಗ್ ಸಾಮರ್ಥ್ಯಗಳು.

ಅವುಗಳೆಂದರೆ, ನೀವು ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯೊಂದಿಗೆ ಮಾತ್ರ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸಬಹುದು ಎಂಟರ್‌ಪ್ರೈಸ್ ಆವೃತ್ತಿಗಳು.

ನೀವು ಪೂರ್ಣ ಪ್ರಮಾಣದ HA ಅನ್ನು ಬಯಸಿದರೆ, ನೀವು ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ ಅಥವಾ ಕೆಲವು ಊರುಗೋಲುಗಳನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ. ಒಂದೆರಡು ಸಮುದಾಯ ಪರಿಹಾರಗಳಿವೆ - ಉದಾಹರಣೆಗೆ influxdb-ha ಸಮರ್ಥ ಪರಿಹಾರದಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಇದು ಉತ್ಪಾದನೆಗೆ ಸೂಕ್ತವಲ್ಲ ಎಂದು ಬರೆಯಲಾಗಿದೆ, ಹಾಗೆಯೇ
ಒಳಹರಿವು-ಸ್ಪೌಟ್ - NATS ಮೂಲಕ ಡೇಟಾ ಪಂಪ್‌ನೊಂದಿಗೆ ಸರಳ ಪರಿಹಾರ (ಇದನ್ನು ಸಹ ಅಳೆಯಬೇಕಾಗುತ್ತದೆ, ಆದರೆ ಇದನ್ನು ಪರಿಹರಿಸಬಹುದು).

ಇದು ಕರುಣೆಯಾಗಿದೆ, ಆದರೆ ಅವೆರಡನ್ನೂ ಕೈಬಿಡಲಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ - ಯಾವುದೇ ತಾಜಾ ಬದ್ಧತೆಗಳಿಲ್ಲ, ಸಮಸ್ಯೆಯು ಹೊಸ ಆವೃತ್ತಿಯ ಒಳಹರಿವು 2.0 ನ ಶೀಘ್ರದಲ್ಲೇ ನಿರೀಕ್ಷಿತ ಬಿಡುಗಡೆಯಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಇದರಲ್ಲಿ ಅನೇಕ ವಿಷಯಗಳು ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ (ಇದರ ಬಗ್ಗೆ ಯಾವುದೇ ಮಾಹಿತಿ ಇಲ್ಲ. ಇನ್ನೂ ಅದರಲ್ಲಿ ಸ್ಕೇಲಿಂಗ್).

ಅಧಿಕೃತವಾಗಿ ಉಚಿತ ಆವೃತ್ತಿ ಇದೆ ರಿಲೇ - ವಾಸ್ತವವಾಗಿ, ಇದು ಪ್ರಾಚೀನ HA ಆಗಿದೆ, ಆದರೆ ಸಮತೋಲನದ ಮೂಲಕ ಮಾತ್ರ,
ಏಕೆಂದರೆ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಹಿಂದೆ ಎಲ್ಲಾ InfluxDB ನಿದರ್ಶನಗಳಿಗೆ ಬರೆಯಲಾಗುತ್ತದೆ.
ಅವನ ಬಳಿ ಕೆಲವು ಇದೆ ಅನನುಕೂಲಗಳು ಓವರ್‌ರೈಟಿಂಗ್ ಪಾಯಿಂಟ್‌ಗಳೊಂದಿಗೆ ಸಂಭಾವ್ಯ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಮುಂಚಿತವಾಗಿ ಬೇಸ್‌ಗಳನ್ನು ರಚಿಸುವ ಅಗತ್ಯತೆಯಂತೆ
(ಇದು InfluxDB ಯೊಂದಿಗೆ ಸಾಮಾನ್ಯ ಕೆಲಸದ ಸಮಯದಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಂಭವಿಸುತ್ತದೆ).

ಇದಲ್ಲದೆ ಹಂಚಿಕೆಯನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಇದರರ್ಥ ನಿಮಗೆ ಅಗತ್ಯವಿಲ್ಲದಿರುವ ನಕಲಿ ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ (ಸಂಸ್ಕರಣೆ ಮತ್ತು ಸಂಗ್ರಹಣೆ ಎರಡೂ) ಹೆಚ್ಚುವರಿ ಓವರ್‌ಹೆಡ್, ಆದರೆ ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ.

ವಿಕ್ಟೋರಿಯಾ ಮೆಟ್ರಿಕ್ಸ್?

ಪರಿಣಾಮವಾಗಿ, ಪಾವತಿಸಿದ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಹೊರತುಪಡಿಸಿ ಎಲ್ಲದರಲ್ಲೂ ನಾವು TICK ಸ್ಟಾಕ್‌ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ತೃಪ್ತರಾಗಿದ್ದೇವೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಉಳಿದ T_CK ಘಟಕಗಳನ್ನು ಬಿಡುವಾಗ InfluxDB ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬದಲಾಯಿಸಬಹುದಾದ ಯಾವುದೇ ಉಚಿತ ಪರಿಹಾರಗಳಿವೆಯೇ ಎಂದು ನೋಡಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

ಸಾಕಷ್ಟು ಸಮಯ-ಸರಣಿ ಡೇಟಾಬೇಸ್‌ಗಳಿವೆ, ಆದರೆ ಅತ್ಯಂತ ಭರವಸೆಯ ಒಂದು ವಿಕ್ಟೋರಿಯಾ ಮೆಟ್ರಿಕ್ಸ್, ಇದು ಹಲವಾರು ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ:

• ವೇಗವಾಗಿ ಮತ್ತು ಸುಲಭ, ಕನಿಷ್ಠ ಫಲಿತಾಂಶಗಳ ಪ್ರಕಾರ ಮಾನದಂಡಗಳು
• ಕ್ಲಸ್ಟರ್ ಆವೃತ್ತಿ ಇದೆ, ಅದರ ಬಗ್ಗೆ ಈಗ ಉತ್ತಮ ವಿಮರ್ಶೆಗಳಿವೆ
  • ಅವಳು ಚೂರು ಮಾಡಬಹುದು
• InfluxDB ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ

ನಾವು ವಿಕ್ಟೋರಿಯಾವನ್ನು ಆಧರಿಸಿ ಸಂಪೂರ್ಣವಾಗಿ ಕಸ್ಟಮ್ ಸ್ಟಾಕ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಉದ್ದೇಶಿಸಿಲ್ಲ ಮತ್ತು ಮುಖ್ಯ ಆಶಯವೆಂದರೆ ನಾವು ಅದನ್ನು InfluxDB ಗಾಗಿ ಡ್ರಾಪ್-ಇನ್ ಬದಲಿಯಾಗಿ ಬಳಸಬಹುದು.

ದುರದೃಷ್ಟವಶಾತ್, InfluxDB ಪ್ರೋಟೋಕಾಲ್ ಬೆಂಬಲಿತವಾಗಿದೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ ಇದು ಸಾಧ್ಯವಿಲ್ಲ, ಇದು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ರೆಕಾರ್ಡಿಂಗ್ ಮಾಡಲು ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ - Prometheus API ಮಾತ್ರ "ಹೊರಗೆ" ಲಭ್ಯವಿದೆ, ಅಂದರೆ ಅದರಲ್ಲಿ ಕ್ರೊನೊಗ್ರಾಫ್ ಅನ್ನು ಹೊಂದಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಇದಲ್ಲದೆ, ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಸಂಖ್ಯಾ ಮೌಲ್ಯಗಳನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸಲಾಗುತ್ತದೆ (ನಾವು ಕಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳಿಗಾಗಿ ಸ್ಟ್ರಿಂಗ್ ಮೌಲ್ಯಗಳನ್ನು ಬಳಸಿದ್ದೇವೆ - ವಿಭಾಗದಲ್ಲಿ ಹೆಚ್ಚು ನಿರ್ವಾಹಕ ಫಲಕ).

ನಿಸ್ಸಂಶಯವಾಗಿ, ಅದೇ ಕಾರಣಕ್ಕಾಗಿ, VM ಇನ್‌ಫ್ಲಕ್ಸ್‌ನಂತೆ ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಅಲ್ಲದೆ, ಸೂಕ್ತ ಪರಿಹಾರವನ್ನು ಹುಡುಕುವ ಸಮಯದಲ್ಲಿ, ವಿಕ್ಟೋರಿಯಾ ಮೆಟ್ರಿಕ್ಸ್ ಇನ್ನೂ ಹೆಚ್ಚು ಜನಪ್ರಿಯವಾಗಿರಲಿಲ್ಲ, ದಸ್ತಾವೇಜನ್ನು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕತೆಯು ದುರ್ಬಲವಾಗಿತ್ತು ಎಂದು ಗಮನಿಸಬೇಕು.
(ಕ್ಲಸ್ಟರ್ ಆವೃತ್ತಿ ಮತ್ತು ಶೇರ್ಡಿಂಗ್‌ನ ವಿವರವಾದ ವಿವರಣೆ ನನಗೆ ನೆನಪಿಲ್ಲ).

ಮೂಲ ಆಯ್ಕೆ

ಪರಿಣಾಮವಾಗಿ, ಪೈಲಟ್‌ಗಾಗಿ ನಾವು ಇನ್ನೂ ಒಂದೇ ಇನ್‌ಫ್ಲಕ್ಸ್‌ಡಿಬಿ ನೋಡ್‌ಗೆ ನಮ್ಮನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತೇವೆ ಎಂದು ನಿರ್ಧರಿಸಲಾಯಿತು.

ಈ ಆಯ್ಕೆಗೆ ಹಲವಾರು ಮುಖ್ಯ ಕಾರಣಗಳಿವೆ:

• TICK ಸ್ಟಾಕ್‌ನ ಸಂಪೂರ್ಣ ಕಾರ್ಯವನ್ನು ನಾವು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಟ್ಟಿದ್ದೇವೆ
• ನಾವು ಈಗಾಗಲೇ ಅದನ್ನು ನಿಯೋಜಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಅದು ಉತ್ತಮವಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ
• ಗಡುವು ಮುಗಿದಿದೆ ಮತ್ತು ಇತರ ಆಯ್ಕೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಹೆಚ್ಚು ಸಮಯ ಉಳಿದಿಲ್ಲ.
• ಇಷ್ಟು ದೊಡ್ಡ ಹೊರೆಯನ್ನು ನಾವು ನಿರೀಕ್ಷಿಸಿರಲಿಲ್ಲ

ಪೈಲಟ್‌ನ ಮೊದಲ ಹಂತಕ್ಕಾಗಿ ನಮ್ಮಲ್ಲಿ ಹೆಚ್ಚಿನ ಸ್ಕೂಟರ್‌ಗಳು ಇರಲಿಲ್ಲ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ ಪರೀಕ್ಷೆಯು ಯಾವುದೇ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಲಿಲ್ಲ.

ಆದ್ದರಿಂದ, ಈ ಯೋಜನೆಗೆ ಸ್ಕೇಲಿಂಗ್ ಅಗತ್ಯವಿಲ್ಲದೇ ನಮಗೆ ಒಂದು ಒಳಹರಿವಿನ ನೋಡ್ ಸಾಕಾಗುತ್ತದೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ (ಕೊನೆಯಲ್ಲಿ ತೀರ್ಮಾನಗಳನ್ನು ನೋಡಿ).

ನಾವು ಸ್ಟಾಕ್ ಮತ್ತು ಬೇಸ್ ಅನ್ನು ನಿರ್ಧರಿಸಿದ್ದೇವೆ - ಈಗ TICK ಸ್ಟಾಕ್‌ನ ಉಳಿದ ಘಟಕಗಳ ಬಗ್ಗೆ.

ಕೆಪಾಸಿಟರ್

ಕೆಪಾಸಿಟರ್ ಟಿಕ್ ಸ್ಟಾಕ್‌ನ ಭಾಗವಾಗಿದೆ, ಇದು ನೈಜ ಸಮಯದಲ್ಲಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಪ್ರವೇಶಿಸುವ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಮತ್ತು ನಿಯಮಗಳ ಆಧಾರದ ಮೇಲೆ ವಿವಿಧ ಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸೇವೆಯಾಗಿದೆ.

ಸಾಮಾನ್ಯವಾಗಿ, ಇದು ಸಂಭಾವ್ಯ ಅಸಂಗತತೆ ಟ್ರ್ಯಾಕಿಂಗ್ ಮತ್ತು ಯಂತ್ರ ಕಲಿಕೆಯ ಸಾಧನವಾಗಿ ಇರಿಸಲ್ಪಟ್ಟಿದೆ (ಈ ಕಾರ್ಯಗಳು ಬೇಡಿಕೆಯಲ್ಲಿವೆ ಎಂದು ನನಗೆ ಖಚಿತವಿಲ್ಲ), ಆದರೆ ಅದರ ಬಳಕೆಯ ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಪ್ರಕರಣವು ಹೆಚ್ಚು ಸಾಮಾನ್ಯವಾಗಿದೆ - ಎಚ್ಚರಿಕೆ.

ಅಧಿಸೂಚನೆಗಳಿಗಾಗಿ ನಾವು ಅದನ್ನು ಹೇಗೆ ಬಳಸಿದ್ದೇವೆ. ನಿರ್ದಿಷ್ಟ ಸ್ಕೂಟರ್ ಆಫ್‌ಲೈನ್‌ಗೆ ಹೋದಾಗ ನಾವು ಸ್ಲಾಕ್ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ ಮತ್ತು ಸ್ಮಾರ್ಟ್ ಚಾರ್ಜರ್‌ಗಳು ಮತ್ತು ಪ್ರಮುಖ ಮೂಲಸೌಕರ್ಯ ಘಟಕಗಳಿಗೆ ಅದೇ ರೀತಿ ಮಾಡಲಾಗಿದೆ.

ಇದು ಸಮಸ್ಯೆಗಳಿಗೆ ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು, ಜೊತೆಗೆ ಎಲ್ಲವೂ ಸಾಮಾನ್ಯ ಸ್ಥಿತಿಗೆ ಮರಳಿದೆ ಎಂದು ಅಧಿಸೂಚನೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ.

ಒಂದು ಸರಳ ಉದಾಹರಣೆ: ನಮ್ಮ "ಬಾಕ್ಸ್" ಅನ್ನು ಪವರ್ ಮಾಡಲು ಹೆಚ್ಚುವರಿ ಬ್ಯಾಟರಿ ಮುರಿದುಹೋಗಿದೆ ಅಥವಾ ಕೆಲವು ಕಾರಣಗಳಿಂದಾಗಿ ಶಕ್ತಿಯು ಖಾಲಿಯಾಗಿದೆ; ಹೊಸದನ್ನು ಸ್ಥಾಪಿಸುವ ಮೂಲಕ, ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಸ್ಕೂಟರ್ನ ಕಾರ್ಯವನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲಾಗಿದೆ ಎಂದು ನಾವು ಅಧಿಸೂಚನೆಯನ್ನು ಸ್ವೀಕರಿಸಬೇಕು.

ಒಳಹರಿವಿನಲ್ಲಿ 2.0 ಕೆಪಾಸಿಟರ್ DB ಯ ಭಾಗವಾಯಿತು

ಕ್ರೊನೊಗ್ರಾಫ್

ನಾನು ಮೇಲ್ವಿಚಾರಣೆಗಾಗಿ ಹಲವು ವಿಭಿನ್ನ UI ಪರಿಹಾರಗಳನ್ನು ನೋಡಿದ್ದೇನೆ, ಆದರೆ ಕ್ರಿಯಾತ್ಮಕತೆ ಮತ್ತು UX ವಿಷಯದಲ್ಲಿ, ಕ್ರೊನೊಗ್ರಾಫ್‌ಗೆ ಹೋಲಿಸಿದರೆ ಯಾವುದೂ ಇಲ್ಲ ಎಂದು ನಾನು ಹೇಳಬಲ್ಲೆ.

ನಾವು ಟಿಕ್ ಸ್ಟಾಕ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ವಿಚಿತ್ರವೆಂದರೆ, ಗ್ರಾಫನ್ ಅನ್ನು ವೆಬ್ ಇಂಟರ್ಫೇಸ್ ಆಗಿ.
ನಾನು ಅದರ ಕಾರ್ಯವನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ; ಏನನ್ನಾದರೂ ಹೊಂದಿಸಲು ಅದರ ವ್ಯಾಪಕ ಸಾಧ್ಯತೆಗಳು ಎಲ್ಲರಿಗೂ ತಿಳಿದಿದೆ.

ಆದಾಗ್ಯೂ, ಗ್ರಾಫಾನಾ ಇನ್ನೂ ಸಂಪೂರ್ಣವಾಗಿ ಸಾರ್ವತ್ರಿಕ ಸಾಧನವಾಗಿದೆ, ಆದರೆ ಕ್ರೊನೊಗ್ರಾಫ್ ಅನ್ನು ಮುಖ್ಯವಾಗಿ ಒಳಹರಿವಿನೊಂದಿಗೆ ಬಳಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.

ಮತ್ತು ಸಹಜವಾಗಿ, ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಕ್ರೊನೊಗ್ರಾಫ್ ಹೆಚ್ಚು ಬುದ್ಧಿವಂತ ಅಥವಾ ಅನುಕೂಲಕರ ಕಾರ್ಯವನ್ನು ನಿಭಾಯಿಸಬಲ್ಲದು.

ಕ್ರೊನೊಗ್ರಾಫ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಮುಖ್ಯ ಅನುಕೂಲವೆಂದರೆ ಎಕ್ಸ್‌ಪ್ಲೋರ್ ಮೂಲಕ ನಿಮ್ಮ ಇನ್‌ಫ್ಲಕ್ಸ್‌ಡಿಬಿಯ ಒಳಭಾಗವನ್ನು ನೀವು ವೀಕ್ಷಿಸಬಹುದು.

ಗ್ರಾಫಾನಾವು ಬಹುತೇಕ ಒಂದೇ ರೀತಿಯ ಕಾರ್ಯವನ್ನು ಹೊಂದಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ, ಕ್ರೊನೊಗ್ರಾಫ್‌ನಲ್ಲಿ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಅನ್ನು ಹೊಂದಿಸುವುದನ್ನು ಕೆಲವು ಮೌಸ್ ಕ್ಲಿಕ್‌ಗಳೊಂದಿಗೆ ಮಾಡಬಹುದು (ಅದೇ ಸಮಯದಲ್ಲಿ ಅಲ್ಲಿ ದೃಶ್ಯೀಕರಣವನ್ನು ನೋಡುವುದು), ಗ್ರಾಫಾನಾದಲ್ಲಿ ನೀವು ಇನ್ನೂ ಬೇಗ ಅಥವಾ ನಂತರ ಹೊಂದಿರುತ್ತೀರಿ JSON ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸಂಪಾದಿಸಲು (ಖಂಡಿತವಾಗಿಯೂ ಕ್ರೊನೊಗ್ರಾಫ್ ನಿಮ್ಮ ಕೈಯಿಂದ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ದಶಾಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ ಅವುಗಳನ್ನು JSON ಎಂದು ಸಂಪಾದಿಸಿ - ಆದರೆ ಅವುಗಳನ್ನು UI ನಲ್ಲಿ ರಚಿಸಿದ ನಂತರ ನಾನು ಎಂದಿಗೂ ಸ್ಪರ್ಶಿಸಬೇಕಾಗಿಲ್ಲ).

ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು ಮತ್ತು ನಿಯಂತ್ರಣಗಳನ್ನು ರಚಿಸಲು ಕಿಬಾನಾ ಹೆಚ್ಚು ಉತ್ಕೃಷ್ಟ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಅಂತಹ ಕಾರ್ಯಾಚರಣೆಗಳಿಗಾಗಿ UX ತುಂಬಾ ಸಂಕೀರ್ಣವಾಗಿದೆ.

ಅನುಕೂಲಕರ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ರಚಿಸಲು ಕೆಲವು ಉತ್ತಮ ತಿಳುವಳಿಕೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮತ್ತು ಕ್ರೊನೊಗ್ರಾಫ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳ ಕ್ರಿಯಾತ್ಮಕತೆಯು ಕಡಿಮೆಯಿದ್ದರೂ, ಅವುಗಳನ್ನು ತಯಾರಿಸುವುದು ಮತ್ತು ಕಸ್ಟಮೈಸ್ ಮಾಡುವುದು ಹೆಚ್ಚು ಸರಳವಾಗಿದೆ.

ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು, ಆಹ್ಲಾದಕರ ದೃಶ್ಯ ಶೈಲಿಯ ಹೊರತಾಗಿ, ವಾಸ್ತವವಾಗಿ ಗ್ರಾಫಾನಾ ಅಥವಾ ಕಿಬಾನಾದಲ್ಲಿನ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿರುವುದಿಲ್ಲ:

ಪ್ರಶ್ನೆ ವಿಂಡೋ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, InfluxDB ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿನ ಕ್ಷೇತ್ರಗಳ ಪ್ರಕಾರಗಳನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು, ಕ್ರೋನೋಗ್ರಾಫ್ ಸ್ವತಃ ಪ್ರಶ್ನೆಯನ್ನು ಬರೆಯಲು ಅಥವಾ ಸರಾಸರಿ ರೀತಿಯ ಸರಿಯಾದ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯ ಕಾರ್ಯವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಕೆಲವೊಮ್ಮೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ.

ಮತ್ತು ಸಹಜವಾಗಿ, ಲಾಗ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸಲು ಕ್ರೊನೊಗ್ರಾಫ್ ಸಾಧ್ಯವಾದಷ್ಟು ಅನುಕೂಲಕರವಾಗಿದೆ. ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಇನ್‌ಫ್ಲಕ್ಸ್ ಲಾಗ್‌ಗಳು ಸಿಸ್ಲಾಗ್ ಅನ್ನು ಬಳಸಲು ಅನುಗುಣವಾಗಿರುತ್ತವೆ ಮತ್ತು ಆದ್ದರಿಂದ ಅವುಗಳು ಪ್ರಮುಖ ನಿಯತಾಂಕವನ್ನು ಹೊಂದಿವೆ - ತೀವ್ರತೆ.

ಮೇಲ್ಭಾಗದಲ್ಲಿರುವ ಗ್ರಾಫ್ ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ; ಅದರ ಮೇಲೆ ನೀವು ಸಂಭವಿಸುವ ದೋಷಗಳನ್ನು ನೋಡಬಹುದು ಮತ್ತು ತೀವ್ರತೆ ಹೆಚ್ಚಿದ್ದರೆ ಬಣ್ಣವು ತಕ್ಷಣವೇ ಸ್ಪಷ್ಟವಾಗಿ ತೋರಿಸುತ್ತದೆ.

ಒಂದೆರಡು ಬಾರಿ ನಾವು ಪ್ರಮುಖ ದೋಷಗಳನ್ನು ಈ ರೀತಿಯಲ್ಲಿ ಹಿಡಿದಿದ್ದೇವೆ, ಕಳೆದ ವಾರದ ಲಾಗ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸಲು ಹೋಗುತ್ತೇವೆ ಮತ್ತು ಕೆಂಪು ಸ್ಪೈಕ್ ಅನ್ನು ನೋಡಿದ್ದೇವೆ.

ಸಹಜವಾಗಿ, ಅಂತಹ ದೋಷಗಳಿಗೆ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಹೊಂದಿಸುವುದು ಆದರ್ಶಪ್ರಾಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದಕ್ಕಾಗಿ ನಾವು ಈಗಾಗಲೇ ಎಲ್ಲವನ್ನೂ ಹೊಂದಿದ್ದೇವೆ.

ನಾವು ಇದನ್ನು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಆನ್ ಮಾಡಿದ್ದೇವೆ, ಆದರೆ ಪೈಲಟ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಾವು ಸಾಕಷ್ಟು ದೋಷಗಳನ್ನು ಪಡೆಯುತ್ತಿದ್ದೇವೆ (ಎಲ್‌ಟಿಇ ನೆಟ್‌ವರ್ಕ್‌ನ ಅಲಭ್ಯತೆಯಂತಹ ಸಿಸ್ಟಮ್ ದೋಷಗಳು ಸೇರಿದಂತೆ), ಇದು ಸ್ಲಾಕ್ ಚಾನಲ್ ಅನ್ನು "ಸ್ಪ್ಯಾಮ್" ಮಾಡಿದೆ. ಹೆಚ್ಚು, ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡದೆ.

ಈ ರೀತಿಯ ಹೆಚ್ಚಿನ ದೋಷಗಳನ್ನು ನಿಭಾಯಿಸುವುದು, ಅವುಗಳ ತೀವ್ರತೆಯನ್ನು ಸರಿಹೊಂದಿಸುವುದು ಮತ್ತು ನಂತರ ಎಚ್ಚರಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಸರಿಯಾದ ಪರಿಹಾರವಾಗಿದೆ.

ಈ ರೀತಿಯಾಗಿ, ಹೊಸ ಅಥವಾ ಪ್ರಮುಖ ದೋಷಗಳನ್ನು ಮಾತ್ರ ಸ್ಲಾಕ್‌ಗೆ ಪೋಸ್ಟ್ ಮಾಡಲಾಗುತ್ತದೆ. ಬಿಗಿಯಾದ ಗಡುವನ್ನು ನೀಡಿದ ಅಂತಹ ಸೆಟಪ್‌ಗೆ ಸಾಕಷ್ಟು ಸಮಯವಿಲ್ಲ.

ದೃ ation ೀಕರಣ

ಕ್ರೊನೊಗ್ರಾಫ್ OAuth ಮತ್ತು OIDC ಅನ್ನು ದೃಢೀಕರಣವಾಗಿ ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ನಮೂದಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ.

ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ನಿಮ್ಮ ಸರ್ವರ್‌ಗೆ ಸುಲಭವಾಗಿ ಲಗತ್ತಿಸಲು ಮತ್ತು ಪೂರ್ಣ ಪ್ರಮಾಣದ SSO ಅನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಸರ್ವರ್ ಆಗಿತ್ತು ಕೀಕ್ಲಾಕ್ — ಇದನ್ನು ಮಾನಿಟರಿಂಗ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು ಬಳಸಲಾಗುತ್ತಿತ್ತು, ಆದರೆ ಅದೇ ಸರ್ವರ್ ಅನ್ನು ಸ್ಕೂಟರ್‌ಗಳನ್ನು ದೃಢೀಕರಿಸಲು ಮತ್ತು ಬ್ಯಾಕ್-ಎಂಡ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ಸಹ ಬಳಸಲಾಗುತ್ತದೆ.

"ನಿರ್ವಾಹಕ"

ನಾನು ವಿವರಿಸುವ ಕೊನೆಯ ಅಂಶವೆಂದರೆ Vue ನಲ್ಲಿ ನಮ್ಮ ಸ್ವಯಂ-ಬರಹದ "ನಿರ್ವಾಹಕ ಫಲಕ".
ಮೂಲಭೂತವಾಗಿ ಇದು ಕೇವಲ ಒಂದು ಸ್ವತಂತ್ರ ಸೇವೆಯಾಗಿದ್ದು ಅದು ನಮ್ಮದೇ ಡೇಟಾಬೇಸ್‌ಗಳು, ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳು ಮತ್ತು ಇನ್‌ಫ್ಲಕ್ಸ್‌ಡಿಬಿಯಿಂದ ಮೆಟ್ರಿಕ್ಸ್ ಡೇಟಾದಿಂದ ಏಕಕಾಲದಲ್ಲಿ ಸ್ಕೂಟರ್ ಮಾಹಿತಿಯನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ತುರ್ತು ರೀಬೂಟ್ ಅಥವಾ ಬೆಂಬಲ ತಂಡಕ್ಕಾಗಿ ರಿಮೋಟ್ ಲಾಕ್ ಅನ್ನು ತೆರೆಯುವಂತಹ ಅನೇಕ ಆಡಳಿತಾತ್ಮಕ ಕಾರ್ಯಗಳನ್ನು ಅಲ್ಲಿಗೆ ಸರಿಸಲಾಗಿದೆ.

ನಕ್ಷೆಗಳೂ ಇದ್ದವು. ನಾವು ಕ್ರೊನೊಗ್ರಾಫ್ ಬದಲಿಗೆ ಗ್ರಾಫಾನಾದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಎಂದು ನಾನು ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಿದ್ದೇನೆ - ಏಕೆಂದರೆ ಗ್ರಾಫಾನಾ ನಕ್ಷೆಗಳು ಪ್ಲಗಿನ್‌ಗಳ ರೂಪದಲ್ಲಿ ಲಭ್ಯವಿದೆ, ಅದರ ಮೇಲೆ ನಾವು ಸ್ಕೂಟರ್‌ಗಳ ನಿರ್ದೇಶಾಂಕಗಳನ್ನು ವೀಕ್ಷಿಸಬಹುದು. ದುರದೃಷ್ಟವಶಾತ್, ಗ್ರಾಫಾನಾಗಾಗಿ ಮ್ಯಾಪ್ ವಿಜೆಟ್‌ಗಳ ಸಾಮರ್ಥ್ಯಗಳು ಬಹಳ ಸೀಮಿತವಾಗಿವೆ ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ, ಈ ಸಮಯದಲ್ಲಿ ನಿರ್ದೇಶಾಂಕಗಳನ್ನು ನೋಡುವುದಲ್ಲದೆ, ಪ್ರದರ್ಶಿಸಲು ಕೆಲವು ದಿನಗಳಲ್ಲಿ ನಕ್ಷೆಗಳೊಂದಿಗೆ ನಿಮ್ಮ ಸ್ವಂತ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬರೆಯುವುದು ತುಂಬಾ ಸುಲಭವಾಗಿದೆ. ಸ್ಕೂಟರ್ ತೆಗೆದುಕೊಂಡ ಮಾರ್ಗ, ನಕ್ಷೆಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಇತ್ಯಾದಿ. (ನಾವು ಸರಳ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗದ ಎಲ್ಲಾ ಕಾರ್ಯಗಳು).

ನಿಮ್ಮ ಸ್ವಂತ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸುಲಭವಾಗಿ ರಚಿಸುವ ಸಾಮರ್ಥ್ಯವು ಒಳಹರಿವಿನ ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಲಾದ ಪ್ರಯೋಜನಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.
ಇದು ಬೃಹತ್ ವೈವಿಧ್ಯಮಯ ಸನ್ನಿವೇಶಗಳಿಗೆ ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ.

ನಾವು ಅಲ್ಲಿ ಎಲ್ಲಾ ಉಪಯುಕ್ತ ಮಾಹಿತಿಯನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ: ಬ್ಯಾಟರಿ ಚಾರ್ಜ್, ಲಾಕ್ ಸ್ಥಿತಿ, ಸಂವೇದಕ ಕಾರ್ಯಕ್ಷಮತೆ, ಬ್ಲೂಟೂತ್, GPS ಮತ್ತು ಇತರ ಹಲವು ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳು.
ನಾವು ನಿರ್ವಾಹಕ ಫಲಕದಲ್ಲಿ ಇದೆಲ್ಲವನ್ನೂ ಪ್ರದರ್ಶಿಸಿದ್ದೇವೆ.

ಸಹಜವಾಗಿ, ನಮಗೆ ಪ್ರಮುಖ ಮಾನದಂಡವೆಂದರೆ ಸ್ಕೂಟರ್‌ನ ಕಾರ್ಯಾಚರಣೆಯ ಸ್ಥಿತಿ - ವಾಸ್ತವವಾಗಿ, ಒಳಹರಿವು ಇದನ್ನು ಸ್ವತಃ ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ನೋಡ್‌ಗಳ ವಿಭಾಗದಲ್ಲಿ “ಹಸಿರು ದೀಪಗಳು” ನೊಂದಿಗೆ ತೋರಿಸುತ್ತದೆ.

ಇದನ್ನು ಕಾರ್ಯದಿಂದ ಮಾಡಲಾಗುತ್ತದೆ ಸತ್ತ ವ್ಯಕ್ತಿ - ನಮ್ಮ ಬಾಕ್ಸ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಅದೇ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಸ್ಲಾಕ್‌ಗೆ ಕಳುಹಿಸಲು ನಾವು ಇದನ್ನು ಬಳಸಿದ್ದೇವೆ.

ಅಂದಹಾಗೆ, ನಾವು ಸ್ಕೂಟರ್‌ಗಳಿಗೆ ದಿ ಸಿಂಪ್ಸನ್ಸ್‌ನ ಪಾತ್ರಗಳ ಹೆಸರಿನಿಂದ ಹೆಸರಿಸಿದ್ದೇವೆ - ಅವುಗಳನ್ನು ಪರಸ್ಪರ ಪ್ರತ್ಯೇಕಿಸಲು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ

ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಈ ರೀತಿಯಲ್ಲಿ ಹೆಚ್ಚು ವಿನೋದಮಯವಾಗಿತ್ತು. "ಗೈಸ್, ಸ್ಮಿಥರ್ಸ್ ಈಸ್ ಡೆಡ್!" ನಂತಹ ನುಡಿಗಟ್ಟುಗಳು ನಿರಂತರವಾಗಿ ಕೇಳಿಬರುತ್ತಿವೆ.

ಸ್ಟ್ರಿಂಗ್ ಮೆಟ್ರಿಕ್ಸ್

ವಿಕ್ಟೋರಿಯಾ ಮೆಟ್ರಿಕ್ಸ್‌ನಂತೆಯೇ ಸಂಖ್ಯಾ ಮೌಲ್ಯಗಳನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸಲು InfluxDB ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಇದು ಅಷ್ಟು ಮುಖ್ಯವಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ - ಎಲ್ಲಾ ನಂತರ, ಲಾಗ್‌ಗಳನ್ನು ಹೊರತುಪಡಿಸಿ, ಯಾವುದೇ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಖ್ಯೆಗಳ ರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು (ತಿಳಿದಿರುವ ರಾಜ್ಯಗಳಿಗೆ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಸೇರಿಸಿ - ಒಂದು ರೀತಿಯ ಎನಮ್)?

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಸ್ಟ್ರಿಂಗ್ ಮೆಟ್ರಿಕ್‌ಗಳು ತುಂಬಾ ಉಪಯುಕ್ತವಾಗಿರುವ ಕನಿಷ್ಠ ಒಂದು ಸನ್ನಿವೇಶವಿತ್ತು.
ನಮ್ಮ "ಸ್ಮಾರ್ಟ್ ಚಾರ್ಜರ್‌ಗಳ" ಪೂರೈಕೆದಾರರು ಮೂರನೇ ವ್ಯಕ್ತಿಯಾಗಿದ್ದರು, ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಈ ಚಾರ್ಜರ್‌ಗಳು ಪೂರೈಸಬಹುದಾದ ಮಾಹಿತಿಯ ಮೇಲೆ ನಮಗೆ ಯಾವುದೇ ನಿಯಂತ್ರಣವಿರಲಿಲ್ಲ.

ಪರಿಣಾಮವಾಗಿ, ಚಾರ್ಜಿಂಗ್ API ಆದರ್ಶದಿಂದ ದೂರವಿತ್ತು, ಆದರೆ ಮುಖ್ಯ ಸಮಸ್ಯೆಯೆಂದರೆ ನಾವು ಯಾವಾಗಲೂ ಅವರ ಸ್ಥಿತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಇಲ್ಲಿಯೇ ಒಳಹರಿವು ರಕ್ಷಣೆಗೆ ಬಂದಿತು. ಇನ್‌ಫ್ಲಕ್ಸ್‌ಡಿಬಿ ಡೇಟಾಬೇಸ್ ಕ್ಷೇತ್ರಕ್ಕೆ ನಮಗೆ ಬಂದ ಸ್ಟ್ರಿಂಗ್ ಸ್ಥಿತಿಯನ್ನು ನಾವು ಬದಲಾವಣೆಗಳಿಲ್ಲದೆ ಸರಳವಾಗಿ ಬರೆದಿದ್ದೇವೆ.

ಕೆಲವು ಸಮಯದವರೆಗೆ, "ಆನ್‌ಲೈನ್" ಮತ್ತು "ಆಫ್‌ಲೈನ್" ನಂತಹ ಮೌಲ್ಯಗಳು ಮಾತ್ರ ಅಲ್ಲಿಗೆ ಬಂದವು, ಅದರ ಆಧಾರದ ಮೇಲೆ ನಮ್ಮ ನಿರ್ವಾಹಕ ಫಲಕದಲ್ಲಿ ಮಾಹಿತಿಯನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅಧಿಸೂಚನೆಗಳನ್ನು ಸ್ಲಾಕ್‌ಗೆ ಕಳುಹಿಸಲಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಕೆಲವು ಹಂತದಲ್ಲಿ, "ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಲಾಗಿದೆ" ನಂತಹ ಮೌಲ್ಯಗಳು ಸಹ ಅಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದವು.

ನಂತರ ಅದು ಬದಲಾದಂತೆ, ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಪ್ರಯತ್ನಗಳ ನಂತರ ಚಾರ್ಜರ್ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಸಂಪರ್ಕದ ನಷ್ಟದ ನಂತರ ಈ ಸ್ಥಿತಿಯನ್ನು ಒಮ್ಮೆ ಕಳುಹಿಸಲಾಗಿದೆ.

ಹೀಗಾಗಿ, ನಾವು ಸ್ಥಿರವಾದ ಮೌಲ್ಯಗಳನ್ನು ಮಾತ್ರ ಬಳಸಿದರೆ, ಸರಿಯಾದ ಸಮಯದಲ್ಲಿ ಫರ್ಮ್‌ವೇರ್‌ನಲ್ಲಿ ಈ ಬದಲಾವಣೆಗಳನ್ನು ನಾವು ನೋಡದೇ ಇರಬಹುದು.

ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಸ್ಟ್ರಿಂಗ್ ಮೆಟ್ರಿಕ್ಸ್ ಬಳಕೆಗೆ ಹೆಚ್ಚಿನ ಸಾಧ್ಯತೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ; ನೀವು ಅವುಗಳಲ್ಲಿ ಯಾವುದೇ ಮಾಹಿತಿಯನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಬಹುದು. ಆದಾಗ್ಯೂ, ನೀವು ಈ ಉಪಕರಣವನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಬಳಸಬೇಕಾಗುತ್ತದೆ.

ಸಾಮಾನ್ಯ ಮೆಟ್ರಿಕ್‌ಗಳ ಜೊತೆಗೆ, ನಾವು InfluxDB ಯಲ್ಲಿ GPS ಸ್ಥಳ ಮಾಹಿತಿಯನ್ನು ದಾಖಲಿಸಿದ್ದೇವೆ. ನಮ್ಮ ನಿರ್ವಾಹಕ ಫಲಕದಲ್ಲಿ ಸ್ಕೂಟರ್‌ಗಳ ಸ್ಥಳವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಇದು ನಂಬಲಾಗದಷ್ಟು ಉಪಯುಕ್ತವಾಗಿದೆ.
ವಾಸ್ತವವಾಗಿ, ನಮಗೆ ಅಗತ್ಯವಿರುವ ಕ್ಷಣದಲ್ಲಿ ಎಲ್ಲಿ ಮತ್ತು ಯಾವ ಸ್ಕೂಟರ್ ಇದೆ ಎಂದು ನಮಗೆ ಯಾವಾಗಲೂ ತಿಳಿದಿತ್ತು.

ನಾವು ಸ್ಕೂಟರ್‌ಗಾಗಿ ಹುಡುಕುತ್ತಿರುವಾಗ ಇದು ನಮಗೆ ತುಂಬಾ ಉಪಯುಕ್ತವಾಗಿದೆ (ಕೊನೆಯಲ್ಲಿ ತೀರ್ಮಾನಗಳನ್ನು ನೋಡಿ).

ಮೂಲಸೌಕರ್ಯ ಮೇಲ್ವಿಚಾರಣೆ

ಸ್ಕೂಟರ್‌ಗಳ ಜೊತೆಗೆ, ನಾವು ನಮ್ಮ ಸಂಪೂರ್ಣ (ಬದಲಿಗೆ ವ್ಯಾಪಕವಾದ) ಮೂಲಸೌಕರ್ಯವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗಿದೆ.

ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ವಾಸ್ತುಶಿಲ್ಪವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ನಾವು ಶುದ್ಧ ಮಾನಿಟರಿಂಗ್ ಸ್ಟಾಕ್ ಅನ್ನು ಹೈಲೈಟ್ ಮಾಡಿದರೆ, ಅದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ನಾವು ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಪರಿಶೀಲಿಸಲು ಬಯಸುವುದು:

• ಡೇಟಾಬೇಸ್ಗಳು
• ಕೀಕ್ಲಾಕ್
• ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು

ನಮ್ಮ ಎಲ್ಲಾ ಕ್ಲೌಡ್ ಸೇವೆಗಳು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನೆಲೆಗೊಂಡಿರುವುದರಿಂದ, ಅದರ ರಾಜ್ಯದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಒಳ್ಳೆಯದು.

ಅದೃಷ್ಟವಶಾತ್, ಟೆಲಿಗ್ರಾಫ್ ಔಟ್ ಆಫ್ ದಿ ಬಾಕ್ಸ್ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು ಮತ್ತು ಕ್ರೊನೊಗ್ರಾಫ್ ತಕ್ಷಣವೇ ಇದಕ್ಕಾಗಿ ಸುಂದರವಾದ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ.

ನಾವು ಮುಖ್ಯವಾಗಿ ಪಾಡ್‌ಗಳ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿದ್ದೇವೆ. ಪತನದ ಸಂದರ್ಭದಲ್ಲಿ, ಸ್ಲಾಕ್‌ನಲ್ಲಿ ಎಚ್ಚರಿಕೆಗಳು.

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಪಾಡ್‌ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಎರಡು ಮಾರ್ಗಗಳಿವೆ: ಡೇಮನ್‌ಸೆಟ್ ಮತ್ತು ಸೈಡ್‌ಕಾರ್.
ಎರಡೂ ವಿಧಾನಗಳನ್ನು ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ ಈ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್‌ನಲ್ಲಿ.

ನಾವು ಟೆಲಿಗ್ರಾಫ್ ಸೈಡ್‌ಕಾರ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳ ಜೊತೆಗೆ, ಪಾಡ್ ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ.

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಲಾಗ್ಗಳೊಂದಿಗೆ ಟಿಂಕರ್ ಮಾಡಬೇಕಾಗಿತ್ತು. ಟೆಲಿಗ್ರಾಫ್ ಡಾಕರ್ API ನಿಂದ ಲಾಗ್‌ಗಳನ್ನು ಎಳೆಯಬಹುದು ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ನಮ್ಮ ಅಂತಿಮ ಸಾಧನಗಳೊಂದಿಗೆ ಲಾಗ್‌ಗಳ ಏಕರೂಪದ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಲು ನಾವು ಬಯಸಿದ್ದೇವೆ ಮತ್ತು ಇದಕ್ಕಾಗಿ ಕಂಟೈನರ್‌ಗಳಿಗಾಗಿ ಸಿಸ್ಲಾಗ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೇವೆ. ಬಹುಶಃ ಈ ಪರಿಹಾರವು ಸುಂದರವಾಗಿಲ್ಲ, ಆದರೆ ಅದರ ಕೆಲಸದ ಬಗ್ಗೆ ಯಾವುದೇ ದೂರುಗಳಿಲ್ಲ ಮತ್ತು ಕ್ರೊನೊಗ್ರಾಫ್ನಲ್ಲಿ ಲಾಗ್ಗಳನ್ನು ಉತ್ತಮವಾಗಿ ಪ್ರದರ್ಶಿಸಲಾಗಿದೆ.

ಮಾನಿಟರ್ ಮಾನಿಟರಿಂಗ್ ???

ಕೊನೆಯಲ್ಲಿ, ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗಳ ಹಳೆಯ-ಹಳೆಯ ಪ್ರಶ್ನೆಯು ಹುಟ್ಟಿಕೊಂಡಿತು, ಆದರೆ ಅದೃಷ್ಟವಶಾತ್, ಅಥವಾ ದುರದೃಷ್ಟವಶಾತ್, ನಾವು ಇದಕ್ಕಾಗಿ ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಹೊಂದಿರಲಿಲ್ಲ.

ಟೆಲಿಗ್ರಾಫ್ ತನ್ನ ಸ್ವಂತ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸುಲಭವಾಗಿ ಕಳುಹಿಸಬಹುದು ಅಥವಾ ಇನ್‌ಫ್ಲಕ್ಸ್‌ಡಿಬಿ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಅದೇ ಇನ್‌ಫ್ಲಕ್ಸ್‌ಗೆ ಅಥವಾ ಬೇರೆಡೆಗೆ ಕಳುಹಿಸಲು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು.

ಸಂಶೋಧನೆಗಳು

ಪೈಲಟ್‌ನ ಫಲಿತಾಂಶಗಳಿಂದ ನಾವು ಯಾವ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ?

ನೀವು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಹೇಗೆ ಮಾಡಬಹುದು?

ಮೊದಲನೆಯದಾಗಿ, TICK ಸ್ಟಾಕ್ ನಮ್ಮ ನಿರೀಕ್ಷೆಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪೂರೈಸಿದೆ ಮತ್ತು ನಾವು ಆರಂಭದಲ್ಲಿ ನಿರೀಕ್ಷಿಸಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಅವಕಾಶಗಳನ್ನು ನಮಗೆ ನೀಡಿತು.

ನಮಗೆ ಬೇಕಾದ ಎಲ್ಲಾ ಕಾರ್ಯಚಟುವಟಿಕೆಗಳು ಇದ್ದವು. ನಾವು ಅದರೊಂದಿಗೆ ಮಾಡಿದ ಪ್ರತಿಯೊಂದೂ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡಿದೆ.

ಉತ್ಪಾದಕತೆ

ಉಚಿತ ಆವೃತ್ತಿಯಲ್ಲಿ ಟಿಕ್ ಸ್ಟಾಕ್‌ನ ಮುಖ್ಯ ಸಮಸ್ಯೆ ಸ್ಕೇಲಿಂಗ್ ಸಾಮರ್ಥ್ಯಗಳ ಕೊರತೆಯಾಗಿದೆ. ಇದು ನಮಗೆ ಸಮಸ್ಯೆಯಾಗಿರಲಿಲ್ಲ.

ನಾವು ನಿಖರವಾದ ಲೋಡ್ ಡೇಟಾ/ಅಂಕಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಿಲ್ಲ, ಆದರೆ ನಾವು ಒಂದೇ ಬಾರಿಗೆ ಸುಮಾರು 30 ಸ್ಕೂಟರ್‌ಗಳಿಂದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ.

ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಮೂರು ಡಜನ್‌ಗಿಂತ ಹೆಚ್ಚು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಸಾಧನಗಳಿಂದ ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಕಳುಹಿಸುವಿಕೆಯು ಪ್ರತಿ 10 ಸೆಕೆಂಡಿಗೆ ಸಂಭವಿಸಿದೆ.

ಪೈಲಟ್‌ನ ಒಂದೂವರೆ ವಾರದ ನಂತರ, "ಬಾಲ್ಯದ ಹುಣ್ಣುಗಳ" ಹೆಚ್ಚಿನ ಭಾಗವನ್ನು ಸರಿಪಡಿಸಿದಾಗ ಮತ್ತು ಪ್ರಮುಖ ಸಮಸ್ಯೆಗಳನ್ನು ಈಗಾಗಲೇ ಪರಿಹರಿಸಿದಾಗ, ನಾವು ಸರ್ವರ್‌ಗೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವ ಆವರ್ತನವನ್ನು ಕಡಿಮೆ ಮಾಡಬೇಕಾಗಿತ್ತು ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಮುಖ್ಯ. 30 ಸೆಕೆಂಡುಗಳು. ನಮ್ಮ LTE ಸಿಮ್ ಕಾರ್ಡ್‌ಗಳಲ್ಲಿನ ದಟ್ಟಣೆಯು ತ್ವರಿತವಾಗಿ ಕಣ್ಮರೆಯಾಗಲು ಪ್ರಾರಂಭಿಸಿದ ಕಾರಣ ಇದು ಅಗತ್ಯವಾಯಿತು.

ದಟ್ಟಣೆಯ ಬಹುಪಾಲು ಲಾಗ್‌ಗಳಿಂದ ಸೇವಿಸಲ್ಪಟ್ಟಿದೆ; ಮೆಟ್ರಿಕ್‌ಗಳು ಸ್ವತಃ, 10-ಸೆಕೆಂಡ್ ಮಧ್ಯಂತರದೊಂದಿಗೆ, ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅದನ್ನು ವ್ಯರ್ಥ ಮಾಡಲಿಲ್ಲ.

ಪರಿಣಾಮವಾಗಿ, ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ನಾವು ಸಾಧನಗಳಲ್ಲಿ ಲಾಗ್‌ಗಳ ಸಂಗ್ರಹವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ನಿರಂತರ ಸಂಗ್ರಹಣೆಯಿಲ್ಲದೆ ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಗಳು ಈಗಾಗಲೇ ಸ್ಪಷ್ಟವಾಗಿವೆ.

ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಲಾಗ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸುವುದು ಇನ್ನೂ ಅಗತ್ಯವಾಗಿದ್ದರೆ, ನಾವು VPN ಮೂಲಕ WireGuard ಮೂಲಕ ಸರಳವಾಗಿ ಸಂಪರ್ಕಿಸುತ್ತೇವೆ.

ನಾವು ಹೊಂದಿದ್ದ ಪ್ರತಿಯೊಂದು ಪ್ರತ್ಯೇಕ ಪರಿಸರವನ್ನು ಪರಸ್ಪರ ಬೇರ್ಪಡಿಸಲಾಗಿದೆ ಎಂದು ನಾನು ಸೇರಿಸುತ್ತೇನೆ ಮತ್ತು ಮೇಲೆ ವಿವರಿಸಿದ ಹೊರೆಯು ಉತ್ಪಾದನಾ ಪರಿಸರಕ್ಕೆ ಮಾತ್ರ ಸೂಕ್ತವಾಗಿದೆ.

ಅಭಿವೃದ್ಧಿ ಪರಿಸರದಲ್ಲಿ, ನಾವು ಪ್ರತ್ಯೇಕ InfluxDB ನಿದರ್ಶನವನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ ಅದು ಪ್ರತಿ 10 ಸೆಕೆಂಡಿಗೆ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದನ್ನು ಮುಂದುವರೆಸಿದೆ ಮತ್ತು ನಾವು ಯಾವುದೇ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳಿಗೆ ಸಿಲುಕಲಿಲ್ಲ.

ಟಿಕ್ - ಸಣ್ಣ ಮತ್ತು ಮಧ್ಯಮ ಯೋಜನೆಗಳಿಗೆ ಸೂಕ್ತವಾಗಿದೆ

ಈ ಮಾಹಿತಿಯ ಆಧಾರದ ಮೇಲೆ, ತುಲನಾತ್ಮಕವಾಗಿ ಸಣ್ಣ ಯೋಜನೆಗಳು ಅಥವಾ ಯಾವುದೇ ಹೈಲೋಡ್ ಅನ್ನು ಖಂಡಿತವಾಗಿ ನಿರೀಕ್ಷಿಸದ ಯೋಜನೆಗಳಿಗೆ TICK ಸ್ಟಾಕ್ ಸೂಕ್ತವಾಗಿದೆ ಎಂದು ನಾನು ತೀರ್ಮಾನಿಸುತ್ತೇನೆ.

ನೀವು ಸಾವಿರಾರು ಪಾಡ್‌ಗಳು ಅಥವಾ ನೂರಾರು ಯಂತ್ರಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಒಂದು InfluxDB ನಿದರ್ಶನವು ಲೋಡ್ ಅನ್ನು ಉತ್ತಮವಾಗಿ ನಿಭಾಯಿಸುತ್ತದೆ.

ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ನೀವು ಇನ್‌ಫ್ಲಕ್ಸ್ ರಿಲೇ ಒಂದು ಪ್ರಾಚೀನ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯ ಪರಿಹಾರವಾಗಿ ತೃಪ್ತರಾಗಬಹುದು.

ಮತ್ತು, ಸಹಜವಾಗಿ, "ಲಂಬ" ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಹೊಂದಿಸಲು ಮತ್ತು ವಿವಿಧ ರೀತಿಯ ಮೆಟ್ರಿಕ್‌ಗಳಿಗಾಗಿ ವಿಭಿನ್ನ ಸರ್ವರ್‌ಗಳನ್ನು ಸರಳವಾಗಿ ನಿಯೋಜಿಸುವುದನ್ನು ಯಾರೂ ತಡೆಯುವುದಿಲ್ಲ.

ಮಾನಿಟರಿಂಗ್ ಸೇವೆಗಳಲ್ಲಿ ನಿರೀಕ್ಷಿತ ಲೋಡ್ ಬಗ್ಗೆ ನಿಮಗೆ ಖಚಿತವಿಲ್ಲದಿದ್ದರೆ, ಅಥವಾ ನೀವು ತುಂಬಾ "ಭಾರೀ" ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಹೊಂದಲು / ಹೊಂದಲು ಖಾತ್ರಿಯಾಗಿದ್ದರೆ, TICK ಸ್ಟಾಕ್ನ ಉಚಿತ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ.

ಸಹಜವಾಗಿ, ಸರಳ ಪರಿಹಾರವನ್ನು ಖರೀದಿಸುವುದು InfluxDB ಎಂಟರ್‌ಪ್ರೈಸ್ - ಆದರೆ ಇಲ್ಲಿ ನಾನು ಹೇಗಾದರೂ ಕಾಮೆಂಟ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ನನಗೆ ಸೂಕ್ಷ್ಮತೆಗಳ ಪರಿಚಯವಿಲ್ಲ. ಇದು ತುಂಬಾ ದುಬಾರಿಯಾಗಿದೆ ಮತ್ತು ಸಣ್ಣ ಕಂಪನಿಗಳಿಗೆ ಖಂಡಿತವಾಗಿಯೂ ಸೂಕ್ತವಲ್ಲ ಎಂಬ ಅಂಶವನ್ನು ಹೊರತುಪಡಿಸಿ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಇಂದು, ಲೋಕಿ ಬಳಸಿ ವಿಕ್ಟೋರಿಯಾ ಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಲಾಗ್‌ಗಳ ಮೂಲಕ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.

ನಿಜ, ಲೋಕಿ/ಗ್ರಾಫನಾವು ಸಿದ್ಧವಾಗಿರುವ TICK ಗಿಂತ ಕಡಿಮೆ ಅನುಕೂಲಕರವಾಗಿದೆ (ಅವುಗಳ ಹೆಚ್ಚಿನ ಬಹುಮುಖತೆಯಿಂದಾಗಿ) ಎಂದು ನಾನು ಮತ್ತೊಮ್ಮೆ ಕಾಯ್ದಿರಿಸುತ್ತೇನೆ, ಆದರೆ ಅವು ಉಚಿತ.

ಪ್ರಮುಖ: ಇಲ್ಲಿ ವಿವರಿಸಿದ ಎಲ್ಲಾ ಮಾಹಿತಿಯು ಆವೃತ್ತಿಯ ಒಳಹರಿವು 1.8 ಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ, ಈ ಸಮಯದಲ್ಲಿ ಇನ್‌ಫ್ಲಕ್ಸ್ 2.0 ಬಿಡುಗಡೆಯಾಗಲಿದೆ.

ಯುದ್ಧ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಇದನ್ನು ಪ್ರಯತ್ನಿಸಲು ನನಗೆ ಅವಕಾಶವಿಲ್ಲದಿದ್ದರೂ ಮತ್ತು ಸುಧಾರಣೆಗಳ ಬಗ್ಗೆ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಕಷ್ಟ, ಇಂಟರ್ಫೇಸ್ ಖಂಡಿತವಾಗಿಯೂ ಉತ್ತಮವಾಗಿದೆ, ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಸರಳೀಕರಿಸಲಾಗಿದೆ (ಕೆಪಾಸಿಟರ್ ಮತ್ತು ಕ್ರೊನೊಗ್ರಾಫ್ ಇಲ್ಲದೆ),
ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಕಾಣಿಸಿಕೊಂಡವು ("ಕೊಲೆಗಾರ ವೈಶಿಷ್ಟ್ಯ" - ನೀವು ಫೋರ್ಟ್‌ನೈಟ್‌ನಲ್ಲಿ ಆಟಗಾರರನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು ಮತ್ತು ನಿಮ್ಮ ನೆಚ್ಚಿನ ಆಟಗಾರ ಆಟವನ್ನು ಗೆದ್ದಾಗ ಅಧಿಸೂಚನೆಗಳನ್ನು ಸ್ವೀಕರಿಸಬಹುದು) ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಈ ಸಮಯದಲ್ಲಿ, ನಾವು ಮೊದಲ ಆವೃತ್ತಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ ಪ್ರಮುಖ ವಿಷಯವನ್ನು ಆವೃತ್ತಿ 2 ಹೊಂದಿಲ್ಲ - ಯಾವುದೇ ಲಾಗ್ ಸಂಗ್ರಹವಿಲ್ಲ.

ಈ ಕಾರ್ಯಚಟುವಟಿಕೆಯು ಒಳಹರಿವು 2.0 ನಲ್ಲಿ ಸಹ ಗೋಚರಿಸುತ್ತದೆ, ಆದರೆ ನಮಗೆ ಯಾವುದೇ ಡೆಡ್‌ಲೈನ್‌ಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲಾಗಲಿಲ್ಲ, ಅಂದಾಜು ಸಹ.

IoT ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳನ್ನು ಹೇಗೆ ಮಾಡಬಾರದು (ಈಗ)

ಕೊನೆಯಲ್ಲಿ, ಪೈಲಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ, ನಮ್ಮ ಮಾನದಂಡಗಳಿಗೆ ಸೂಕ್ತವಾದ ಪರ್ಯಾಯದ ಅನುಪಸ್ಥಿತಿಯಲ್ಲಿ ನಾವು ನಮ್ಮದೇ ಆದ ಪೂರ್ಣ ಪ್ರಮಾಣದ IoT ಸ್ಟಾಕ್ ಅನ್ನು ಜೋಡಿಸಿದ್ದೇವೆ.

ಆದಾಗ್ಯೂ, ಇತ್ತೀಚೆಗೆ ಇದು ಬೀಟಾ ಆವೃತ್ತಿಯಲ್ಲಿ ಲಭ್ಯವಿದೆ ಓಪನ್ ಬಲೆನಾ - ನಾವು ಯೋಜನೆಯನ್ನು ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಅವಳು ಇರಲಿಲ್ಲ ಎಂಬುದು ವಿಷಾದದ ಸಂಗತಿ.

ನಾವೇ ಜೋಡಿಸಿದ Ansible + TICK + WireGuard ಅನ್ನು ಆಧರಿಸಿದ ಅಂತಿಮ ಫಲಿತಾಂಶ ಮತ್ತು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನೊಂದಿಗೆ ನಾವು ಸಂಪೂರ್ಣವಾಗಿ ತೃಪ್ತರಾಗಿದ್ದೇವೆ. ಆದರೆ ಇಂದು, ನಿಮ್ಮ ಸ್ವಂತ IoT ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ನೀವೇ ನಿರ್ಮಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಮೊದಲು ಬಲೆನಾವನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.

ಏಕೆಂದರೆ ಅಂತಿಮವಾಗಿ ನಾವು ಮಾಡಿದ ಹೆಚ್ಚಿನದನ್ನು ಅದು ಮಾಡಬಹುದು, ಮತ್ತು OpenBalena ಉಚಿತ ಮತ್ತು ಮುಕ್ತ ಮೂಲವಾಗಿದೆ.

ನವೀಕರಣಗಳನ್ನು ಕಳುಹಿಸುವುದು ಹೇಗೆ ಎಂದು ಅದು ಈಗಾಗಲೇ ತಿಳಿದಿದೆ, ಆದರೆ VPN ಅನ್ನು ಈಗಾಗಲೇ ನಿರ್ಮಿಸಲಾಗಿದೆ ಮತ್ತು IoT ಪರಿಸರದಲ್ಲಿ ಬಳಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.

ಮತ್ತು ಇತ್ತೀಚೆಗೆ, ಅವರು ತಮ್ಮ ಬಿಡುಗಡೆಯನ್ನು ಸಹ ಬಿಡುಗಡೆ ಮಾಡಿದರು ಹಾರ್ಡ್ವೇರ್, ಇದು ಅವರ ಪರಿಸರ ವ್ಯವಸ್ಥೆಗೆ ಸುಲಭವಾಗಿ ಸಂಪರ್ಕಿಸುತ್ತದೆ.

ಹೇ, ಕಾಣೆಯಾದ ಸ್ಕೂಟರ್ ಬಗ್ಗೆ ಏನು?

ಆದ್ದರಿಂದ "ರಾಲ್ಫ್" ಎಂಬ ಸ್ಕೂಟರ್ ಯಾವುದೇ ಕುರುಹು ಇಲ್ಲದೆ ಕಣ್ಮರೆಯಾಯಿತು.

InfluxDB ಯಿಂದ GPS ಮೆಟ್ರಿಕ್ಸ್ ಡೇಟಾದೊಂದಿಗೆ ನಾವು ತಕ್ಷಣವೇ ನಮ್ಮ "ನಿರ್ವಾಹಕ ಫಲಕ" ದಲ್ಲಿ ನಕ್ಷೆಯನ್ನು ನೋಡಲು ಓಡಿದೆವು.

ಮಾನಿಟರಿಂಗ್ ಡೇಟಾಗೆ ಧನ್ಯವಾದಗಳು, ಕಳೆದ ದಿನ 21:00 ರ ಸುಮಾರಿಗೆ ಸ್ಕೂಟರ್ ಪಾರ್ಕಿಂಗ್ ಸ್ಥಳದಿಂದ ಹೊರಟಿದೆ ಎಂದು ನಾವು ಸುಲಭವಾಗಿ ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಕೆಲವು ಪ್ರದೇಶಕ್ಕೆ ಸುಮಾರು ಅರ್ಧ ಗಂಟೆ ಓಡಿಸಿದೆ ಮತ್ತು ಕೆಲವು ಜರ್ಮನ್ ಮನೆಯ ಪಕ್ಕದಲ್ಲಿ 5 ಗಂಟೆಯವರೆಗೆ ನಿಲ್ಲಿಸಲಾಗಿದೆ.

ಬೆಳಿಗ್ಗೆ 5 ಗಂಟೆಯ ನಂತರ, ಯಾವುದೇ ಮಾನಿಟರಿಂಗ್ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿಲ್ಲ - ಇದರರ್ಥ ಹೆಚ್ಚುವರಿ ಬ್ಯಾಟರಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಡಿಸ್ಚಾರ್ಜ್ ಮಾಡಲಾಗಿದೆ ಅಥವಾ ಆಕ್ರಮಣಕಾರರು ಅಂತಿಮವಾಗಿ ಸ್ಕೂಟರ್‌ನಿಂದ ಸ್ಮಾರ್ಟ್ ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಹೇಗೆ ತೆಗೆದುಹಾಕಬೇಕು ಎಂದು ಕಂಡುಕೊಂಡರು.
ಇದರ ಹೊರತಾಗಿಯೂ, ಸ್ಕೂಟರ್ ಇರುವ ವಿಳಾಸಕ್ಕೆ ಪೊಲೀಸರನ್ನು ಇನ್ನೂ ಕರೆಯಲಾಯಿತು. ಸ್ಕೂಟರ್ ಇರಲಿಲ್ಲ.

ಆದರೆ, ಮನೆಯ ಮಾಲೀಕರೂ ಇದರಿಂದ ಆಶ್ಚರ್ಯಚಕಿತರಾದರು, ಏಕೆಂದರೆ ಅವರು ನಿನ್ನೆ ರಾತ್ರಿ ಈ ಸ್ಕೂಟರ್ ಅನ್ನು ಕಚೇರಿಯಿಂದ ಮನೆಗೆ ಹೋಗಿದ್ದಾರೆ.

ಅದು ಬದಲಾದಂತೆ, ಬೆಂಬಲಿಗ ಉದ್ಯೋಗಿಯೊಬ್ಬರು ಬೆಳಿಗ್ಗೆ ಬೇಗನೆ ಬಂದು ಸ್ಕೂಟರ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡರು, ಅದರ ಹೆಚ್ಚುವರಿ ಬ್ಯಾಟರಿ ಸಂಪೂರ್ಣವಾಗಿ ಡಿಸ್ಚಾರ್ಜ್ ಆಗಿರುವುದನ್ನು ನೋಡಿ ಅದನ್ನು (ಕಾಲ್ನಡಿಗೆಯಲ್ಲಿ) ಪಾರ್ಕಿಂಗ್ ಸ್ಥಳಕ್ಕೆ ಕೊಂಡೊಯ್ದರು. ಮತ್ತು ಹೆಚ್ಚುವರಿ ಬ್ಯಾಟರಿ ತೇವಾಂಶದ ಕಾರಣ ವಿಫಲವಾಗಿದೆ.

ನಾವೇ ಸ್ಕೂಟರ್ ಕದ್ದಿದ್ದೇವೆ. ಅಂದಹಾಗೆ, ಪೊಲೀಸ್ ಪ್ರಕರಣದ ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಮತ್ತು ಯಾರು ಪರಿಹರಿಸಿದರು ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ, ಆದರೆ ಮೇಲ್ವಿಚಾರಣೆಯು ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ ...

ಮೂಲ: www.habr.com