🥇 איז מאָניטאָרינג טויט? — לאנג לעבן מאָניטאָרינג

זינט 2008, אונדזער פירמע איז בפֿרט פאַרקנאַסט אין ינפראַסטראַקטשער פאַרוואַלטונג און ראָונד-די-זייגער טעכניש שטיצן פֿאַר וועב פּראַדזשעקס: מיר האָבן מער ווי 400 קלייאַנץ, וואָס איז וועגן 15% פון רוסיש E- האַנדל. אַקקאָרדינגלי, אַ זייער דייווערס אַרקאַטעקטשער איז געשטיצט. אויב עפּעס פאלט, מיר זענען אַבליידזשד צו פאַרריכטן עס אין 15 מינוט. אבער צו פֿאַרשטיין אַז אַ צופאַל איז פארגעקומען, איר דאַרפֿן צו מאָניטאָר די פּרויעקט און ריספּאַנד צו ינסאַדאַנץ. ווי צו טאָן דאָס?

איך גלויבן אַז עס איז אַ פּראָבלעם אין אָרגאַנייזינג אַ געהעריק מאָניטאָרינג סיסטעם. אויב עס איז געווען קיין קאָנפליקט, מיין רעדע וואָלט צונויפשטעלנ זיך פון איין טעזיס: "ביטע ינסטאַלירן פּראָמעטהעוס + גראַפאַנאַ און פּלוגינס 1, 2, 3." צום באַדויערן, עס טוט נישט אַרבעטן אַזוי ענימאָר. און דער הויפּט פּראָבלעם איז אַז אַלעמען האלט צו גלויבן אין עפּעס וואָס איז געווען אין 2008, אין טערמינען פון ווייכווארג קאַמפּאָונאַנץ.

וועגן דער אָרגאַניזאַציע פון די מאָניטאָרינג סיסטעם, איך וואָלט ווענטורע צו זאָגן אַז ... פּראַדזשעקס מיט קאָמפּעטענט מאָניטאָרינג טאָן ניט עקסיסטירן. און דער מצב איז אזוי שלעכט, אז אויב עפעס פאלט, איז דא א געפאר אז עס וועט נישט באמערקן - דאך איז יעדער זיכער אז "אלץ ווערט נאכגעקוקט".
טאָמער אַלץ איז מאָניטאָרעד. אבער וויאזוי?

מיר אַלע האָבן געפּלאָנטערט אַ געשיכטע ווי די פאלגענדע: אַ זיכער דעוואָפּס, אַ זיכער אַדמיניסטראַטאָר איז ארבעטן, אַ אַנטוויקלונג מאַנשאַפֿט קומט צו זיי און זאגט - "מיר זענען באפרייט, איצט מאָניטאָר." מאָניטאָר וואָס? וויאזוי עס ארבעט?

אקעי. מיר מאָניטאָר די אַלטמאָדיש וועג. און עס איז שוין טשאַנגינג, און עס טורנס אויס אַז איר מאָניטאָרעד סערוויס א, וואָס איז געווארן דינסט ב, וואָס ינטעראַקץ מיט דינסט C. אָבער די אַנטוויקלונג מאַנשאַפֿט דערציילט איר: "ינסטאַלירן די ווייכווארג, עס זאָל מאָניטאָר אַלץ!"

אַזוי וואָס האט געביטן? - אלעס האט זיך געטוישט!

2008 אלעס איז גוט

עס זענען אַ פּאָר פון דעוועלאָפּערס, איין סערווער, איין דאַטאַבייס סערווער. עס אַלע גייט פון דאָ. מיר האָבן עטלעכע אינפֿאָרמאַציע, מיר ינסטאַלירן זאַבביקס, נאַגיאָס, קאַקטי. און דעמאָלט מיר שטעלן קלאָר אַלערץ אויף די קפּו, אויף דיסק אָפּעראַציע און אויף דיסק פּלאַץ. מיר אויך טאָן אַ פּאָר פון מאַנואַל טשעקס צו ענשור אַז די פּלאַץ ריספּאַנדז און אַז אָרדערס קומען אין די דאַטאַבייס. און אַז ס עס - מיר זענען מער אָדער ווייניקער פּראָטעקטעד.

אויב מיר פאַרגלייַכן די סומע פון אַרבעט וואָס דער אַדמיניסטראַטאָר האט דעמאָלט צו צושטעלן מאָניטאָרינג, 98% פון עס איז געווען אָטאַמאַטיק: דער מענטש וואס טוט די מאָניטאָרינג מוזן פֿאַרשטיין ווי צו ינסטאַלירן Zabbix, ווי צו קאַנפיגיער עס און קאַנפיגיער אַלערץ. און 2% - פֿאַר פונדרויסנדיק טשעקס: אַז די פּלאַץ ריספּאַנדז און מאכט אַ בקשה צו די דאַטאַבייס, אַז נייַ אָרדערס זענען אנגעקומען.

2010 די מאַסע איז גראָוינג

מיר זענען סטאַרטינג צו וואָג די וועב, אַדינג אַ זוכן מאָטאָר. מיר ווילן צו מאַכן זיכער אַז די פּראָדוקט קאַטאַלאָג כּולל אַלע פּראָדוקטן. און אַז פּראָדוקט זוכן אַרבעט. אַז די דאַטאַבייס אַרבעט, אַז די אָרדערס זענען געמאכט, אַז דער פּלאַץ ריספּאַנדז ויסווייניק און ריספּאַנדז פון צוויי סערווערס און דער באַניצער איז נישט קיקט אויס פון די פּלאַץ בשעת עס איז ריבאַלאַנסט צו אן אנדער סערווער, אאז"ו ו. עס זענען מער ענטיטיז.

דערצו, די ענטיטי פֿאַרבונדן מיט ינפראַסטראַקטשער נאָך בלייבט די גרעסטע אין די קאָפּ פון די פאַרוואַלטער. עס איז נאָך אַ געדאַנק אין מיין קאָפּ אַז דער מענטש וואָס טוט די מאָניטאָרינג איז דער מענטש וואָס וועט ינסטאַלירן זאַבביקס און קענען קאַנפיגיער עס.

אָבער אין דער זעלביקער צייט, אַרבעט אויס אויף קאַנדאַקטינג פונדרויסנדיק טשעקס, צו שאַפֿן אַ סכום פון זוכן אינדעקס אָנפֿרעג סקריפּס, אַ סכום פון סקריפּס צו קאָנטראָלירן אַז די זוכן ענדערונגען בעשאַס די ינדעקסינג פּראָצעס, אַ סכום פון סקריפּס וואָס קאָנטראָלירן אַז סכוירע זענען טראַנספערד צו די ינדעקסינג פּראָצעס. עקספּרעס דינסט, אאז"ו ו. און אזוי ווייטער.

באַמערקונג: איך געשריבן "אַ סכום פון סקריפּס" 3 מאל. אַז איז, דער מענטש פאַראַנטוואָרטלעך פֿאַר מאָניטאָרינג איז ניט מער דער איינער וואָס פשוט ינסטאָלז זאַבביקס. דאָס איז אַ מענטש וואָס סטאַרץ קאָדירונג. אבער גאָרנישט האט געביטן אין די מאַנשאַפֿט ס מחשבות נאָך.

אבער די וועלט איז טשאַנגינג, שיין מער און מער קאָמפּליצירט. א ווירטואַליזאַטיאָן שיכטע און עטלעכע נייַע סיסטעמען זענען צוגעגעבן. זיי אָנהייבן צו ינטעראַקט מיט יעדער אנדערע. ווער האט געזאגט "סמעללס ווי מיקראָ סערוויסעס?" אָבער יעדער דינסט נאָך קוקט ווי אַ וועבזייטל ינדיווידזשואַלי. מיר קענען ווענדן צו עס און פֿאַרשטיין אַז עס גיט די נייטיק אינפֿאָרמאַציע און אַרבעט אויף זיך. און אויב איר זענט אַ אַדמיניסטראַטאָר קעסיידער ינוואַלווד אין אַ פּרויעקט וואָס איז דעוועלאָפּינג פֿאַר 5-7-10 יאָר, דעם וויסן אַקיומיאַלייץ: אַ נייַע מדרגה איז ארויס - איר האָט איינגעזען עס, אן אנדער מדרגה - איר האָט איינגעזען עס ...

אָבער ראַרעלי טוט ווער עס יז באַגלייטן אַ פּרויעקט פֿאַר 10 יאר.

מאָניטאָרינגמאַן ס נעמענ זיכ ווידער

רעכן איר געקומען צו אַ נייַע סטאַרטאַפּ וואָס גלייך כייערד 20 דעוועלאָפּערס, געשריבן 15 מיקראָ באַדינונגס, און איר זענט אַ אַדמיניסטראַטאָר וואָס איז געזאָגט: "בויען סי / סי. ביטע." איר האָט געבויט סי / סי און פּלוצלינג איר הערן: "עס איז שווער פֿאַר אונדז צו אַרבעטן מיט פּראָדוקציע אין אַ "קוב", אָן פֿאַרשטיין ווי די אַפּלאַקיישאַן וועט אַרבעטן אין עס. מאַכן אונדז אַ זאַמדקאַסטן אין דער זעלביקער "קוב".
איר מאַכן אַ זאַמדקאַסטן אין דעם קוב. זיי גלייך זאָגן איר: "מיר וועלן אַ בינע דאַטאַבייס וואָס איז דערהייַנטיקט יעדער טאָג פֿון פּראָדוקציע, אַזוי מיר פֿאַרשטיין אַז עס אַרבעט אויף די דאַטאַבייס, אָבער אין דער זעלביקער צייט נישט צעלאָזן די פּראָדוקציע דאַטאַבייס."

איר לעבן אין אַלע דעם. עס זענען 2 וואָכן לינקס איידער די מעלדונג, זיי זאָגן איר: "איצט לאָמיר מאָניטאָר אַלע דעם ..." דאָס איז. מאָניטאָר די קנויל ינפראַסטראַקטשער, מאָניטאָר די מיקראָסערוויס אַרקאַטעקטשער, מאָניטאָר אַרבעט מיט פונדרויסנדיק באַדינונגס ...

און מײַנע חברים נעמען אַרױס פֿון די קעפּ דאָס געװײנלעכע סכעמע און זאָגן: „נו, דאָ איז אַלץ קלאָר! ינסטאַלירן אַ פּראָגראַם וואָס וועט מאָניטאָר אַלע דעם. ” יאָ, יאָ: פּראָמעטהעוס + גראַפאַנאַ + פּלוגינס.
און זיי לייגן: "איר האָט צוויי וואָכן, מאַכן זיכער אַז אַלץ איז זיכער."

אין אַ פּלאַץ פון פּראַדזשעקס וואָס מיר זען, איין מענטש איז אַלאַקייטיד פֿאַר מאָניטאָרינג. ימאַדזשאַן אַז מיר ווילן צו אָנשטעלן אַ מענטש צו טאָן מאָניטאָרינג פֿאַר 2 וואָכן, און מיר שרייַבן אַ נעמענ זיכ ווידער פֿאַר אים. וואָס סקילז זאָל דער מענטש האָבן, געגעבן אַלץ מיר האָבן געזאָגט ביז איצט?

ער מוזן פֿאַרשטיין די מאָניטאָרינג און ספּעסיפיקס פון די אָפּעראַציע פון די פּרעסן ינפראַסטראַקטשער.
ער מוזן פֿאַרשטיין די ספּעסיפיקס פון מאָניטאָרינג קובערנעטעס (און אַלעמען וויל צו גיין צו די "קוב", ווייַל איר קענען אַבסטראַקט פון אַלץ, באַהאַלטן, ווייַל דער אַדמיניסטראַטאָר וועט האַנדלען מיט די מנוחה) - זיך, זייַן ינפראַסטראַקטשער, און פֿאַרשטיין ווי צו מאָניטאָר אַפּלאַקיישאַנז אינעווייניק.
ער מוזן פֿאַרשטיין אַז סערוויסעס יבערגעבן מיט יעדער אנדערער אין ספּעציעל וועגן, און וויסן די ספּעסיפיקס פון ווי סערוויסעס ינטעראַקט מיט יעדער אנדערער. עס איז גאַנץ מעגלעך צו זען אַ פּרויעקט ווו עטלעכע באַדינונגס יבערגעבן סינטשראָנאָוסלי, ווייַל עס איז קיין אנדערע וועג. פֿאַר בייַשפּיל, די באַקענד גייט דורך REST, דורך gRPC צו די קאַטאַלאָג דינסט, נעמט אַ רשימה פון פּראָדוקטן און קערט עס צוריק. איר קענט נישט וואַרטן דאָ. און מיט אנדערע באַדינונגס עס אַרבעט ייסינגקראַנאַסלי. אַריבערפירן די סדר צו די עקספּרעס דינסט, שיקן אַ בריוו, אאז"ו ו.
דו האסט שוין מסתמא שוין געשומען פון דעם אלץ? און דער אַדמיניסטראַטאָר, וואָס דאַרף צו מאָניטאָר דעם, איז געווארן נאָך מער צעמישט.
ער מוז קענען פּלאַנירן און פּלאַנירן ריכטיק - ווי די אַרבעט ווערט מער און מער.
ער מוזן דעריבער מאַכן אַ סטראַטעגיע פון די באשאפן דינסט אין סדר צו פֿאַרשטיין ווי צו ספּאַסיפיקלי מאָניטאָר עס. ער דאַרף אַ פארשטאנד פון די אַרקאַטעקטשער פון די פּרויעקט און זייַן אַנטוויקלונג + אַ פארשטאנד פון די טעקנאַלאַדזשיז געניצט אין אַנטוויקלונג.

לאָמיר געדענקען אַן לעגאַמרע נאָרמאַל פאַל: עטלעכע באַדינונגס זענען אין PHP, עטלעכע באַדינונגס זענען אין Go, עטלעכע באַדינונגס זענען אין JS. זיי עפעס אַרבעט מיט יעדער אנדערע. דאָס איז ווו דער טערמין "מיקראָסערוויס" קומט פון: עס זענען אַזוי פילע יחיד סיסטעמען אַז דעוועלאָפּערס קענען נישט פֿאַרשטיין די פּרויעקט ווי אַ גאַנץ. איין טייל פון די מאַנשאַפֿט שרייבט סערוויסעס אין JS וואָס אַרבעט אויף זייער אייגן און טאָן ניט וויסן ווי די רעשט פון די סיסטעם אַרבעט. די אנדערע טייל שרייבט באַדינונגס אין פּיטהאָן און טוט נישט אַרייַנמישנ זיך מיט ווי אנדערע סערוויסעס אַרבעט; זיי זענען אפגעזונדערט אין זייער אייגענע געגנט. די דריט איינער איז שרייבן באַדינונגס אין PHP אָדער עפּעס אַנדערש.
אַלע די 20 מענטשן זענען צעטיילט אין 15 סערוויסעס, און עס איז בלויז איין אַדמיניסטראַטאָר וואָס מוזן פֿאַרשטיין אַלע דעם. אָפּשטעל! מיר נאָר שפּאַלטן די סיסטעם אין 15 מיקראָ באַדינונגס ווייַל 20 מענטשן קענען נישט פֿאַרשטיין די גאנצע סיסטעם.

אָבער עס דאַרף זיין מאָניטאָרעד עפעס ...

וואָס איז דער רעזולטאַט? דער רעזולטאַט, עס איז איין מענטש וואָס קומט אַרויף מיט אַלץ וואָס די גאנצע מאַנשאַפֿט פון דעוועלאָפּערס קענען נישט פֿאַרשטיין, און אין דער זעלביקער צייַט ער מוזן אויך וויסן און קענען טאָן וואָס מיר אנגעוויזן אויבן - ייַזנוואַרג ינפראַסטראַקטשער, קובערנעטעס ינפראַסטראַקטשער, אאז"ו ו.

וואָס קען איך זאָגן ... האָוסטאָן, מיר האָבן פּראָבלעמס.

מאָניטאָרינג אַ מאָדערן ווייכווארג פּרויעקט איז אַ ווייכווארג פּרויעקט אין זיך

פֿון דעם פאַלש גלויבן אַז מאָניטאָרינג איז ווייכווארג, מיר אַנטוויקלען אַ גלויבן אין מיראַקאַלז. אבער מיראַקאַלז, וויי, טאָן ניט פּאַסירן. איר קענען נישט ינסטאַלירן זאַבביקס און דערוואַרטן אַלץ צו אַרבעטן. עס איז קיין פונט צו ינסטאַלירן Grafana און כאָופּינג אַז אַלץ וועט זיין גוט. רובֿ פון די צייט וועט זיין פארבראכט אויף אָרגאַנייזינג טשעקס פון די אָפּעראַציע פון סערוויסעס און זייער ינטעראַקשאַן מיט יעדער אנדערע, קאָנטראָלירן ווי פונדרויסנדיק סיסטעמען אַרבעט. אין פאַקט, 90% פון די צייט וועט זיין פארבראכט נישט אויף שרייבן סקריפּס, אָבער אויף דעוועלאָפּינג ווייכווארג. און עס זאָל זיין כאַנדאַלד דורך אַ מאַנשאַפֿט וואָס פארשטייט די אַרבעט פון די פּרויעקט.
אויב אין דעם סיטואַציע איין מענטש איז ארלנגעווארפן אין מאָניטאָרינג, די ומגליק וועט פּאַסירן. וואָס איז וואָס כאַפּאַנז אומעטום.

פֿאַר בייַשפּיל, עס זענען עטלעכע באַדינונגען וואָס יבערגעבן מיט יעדער אנדערע דורך Kafka. דער סדר איז אָנגעקומען, מיר האָבן געשיקט אַ אָנזאָג וועגן דעם סדר צו קאַפקאַ. עס איז אַ דינסט וואָס ליסאַנז צו אינפֿאָרמאַציע וועגן די סדר און שיפּס די סכוירע. עס איז דא א סערוויס וואס הערט צו אינפארמאציע איבער דעם באפעל און שיקט א בריוו צום באנוצער. און דעמאָלט אַ בינטל מער באַדינונגס דערשייַנען, און מיר אָנהייבן צו צעמישט.

און אויב איר אויך געבן דאָס צו די אַדמיניסטראַטאָר און דעוועלאָפּערס אין דער בינע ווען עס איז אַ קורץ צייט פֿאַר די מעלדונג, דער מענטש וועט דאַרפֿן צו פֿאַרשטיין דעם גאַנץ פּראָטאָקאָל. יענע. א פּרויעקט פון דעם וואָג נעמט אַ באַטייטיק סומע פון צייט, און דאָס זאָל זיין קאַנסידערד אין די סיסטעם אַנטוויקלונג.
אָבער זייער אָפט, ספּעציעל אין סטאַרטאַפּס, מיר זען ווי מאָניטאָרינג איז פּאָוסטפּאָונד ביז שפּעטער. "איצט מיר וועלן מאַכן אַ פּרוף פון באַגריף, מיר וועלן קאַטער מיט אים, לאָזן עס פאַלן - מיר זענען גרייט צו קרבן. און דעמאָלט מיר וועלן מאָניטאָר עס אַלע. ” ווען (אָדער אויב) די פּרויעקט הייבט צו מאַכן געלט, די געשעפט וויל צו לייגן אפילו מער פֿעיִקייטן - ווייַל עס האט אנגעהויבן ארבעטן, אַזוי עס דאַרף זיין ראָולד אויס ווייַטער! און איר זענט אין די פונט ווו איר ערשטער דאַרפֿן צו מאָניטאָר אַלץ פריער, וואָס נעמט נישט 1% פון די צייט, אָבער פיל מער. און דורך דעם וועג, דעוועלאָפּערס וועט זיין דארף פֿאַר מאָניטאָרינג, און עס איז גרינגער צו לאָזן זיי אַרבעטן אויף נייַע פֿעיִקייטן. ווי אַ רעזולטאַט, נייַ פֿעיִקייטן זענען געשריבן, אַלץ ווערט סקרוד און איר זענט אין אַ סאָף דעדלאַק.

אַזוי ווי צו מאָניטאָר אַ פּרויעקט סטאַרטינג פון די אָנהייב, און וואָס צו טאָן אויב איר באַקומען אַ פּרויעקט וואָס דאַרף זיין מאָניטאָרעד, אָבער איר טאָן ניט וויסן ווו צו אָנהייבן?

ערשטער, איר דאַרפֿן צו פּלאַן.

ליריקאַל דיגרעשאַן: זייער אָפט זיי אָנהייבן מיט ינפראַסטראַקטשער מאָניטאָרינג. פֿאַר בייַשפּיל, מיר האָבן Kubernetes. לאָמיר אָנהייבן מיט ינסטאָלינג פּראָמעטהעוס מיט גראַפאַנאַ, ינסטאָלינג פּלוגינס פֿאַר מאָניטאָרינג די "קוב". ניט בלויז דעוועלאָפּערס, אָבער אויך אַדמיניסטראַטאָרס האָבן די נעבעך פיר פון: "מיר וועלן ינסטאַלירן דעם פּלוגין, אָבער דער פּלוגין מיסטאָמע ווייסט ווי צו טאָן דאָס." מענטשן ווי צו אָנהייבן מיט די פּשוט און סטרייטפאָרווערד, אלא ווי מיט די וויכטיק אַקשאַנז. און ינפראַסטראַקטשער מאָניטאָרינג איז גרינג.

ערשטער, באַשליסן וואָס און ווי איר ווילן צו מאָניטאָר, און דעמאָלט אויסקלייַבן אַ געצייַג, ווייַל אנדערע מענטשן קענען נישט טראַכטן פֿאַר איר. און זיי זאָלן? אנדערע מענטשן געדאַנק צו זיך, וועגן אַ וניווערסאַל סיסטעם - אָדער נישט טראַכטן ווען דעם פּלוגין איז געווען געשריבן. און נאָר ווייַל דעם פּלוגין האט 5 טויזנט ניצערס טוט נישט מיינען אַז עס איז פון קיין נוצן. טאָמער איר וועט ווערן דער 5001 פשוט ווייַל עס זענען שוין 5000 מענטשן דאָרט פריער.

אויב איר אָנהייב מאָניטאָרינג די ינפראַסטראַקטשער און די באַקענד פון דיין אַפּלאַקיישאַן סטאַפּס ריספּאַנדינג, אַלע יוזערז וועלן פאַרלירן קשר מיט די רירעוודיק אַפּלאַקיישאַן. א טעות וועט דערשייַנען. זיי וועלן קומען צו איר און זאָגן "די אַפּלאַקיישאַן איז נישט ארבעטן, וואָס טאָן איר טאָן דאָ?" - "מיר זענען מאָניטאָרינג." - "ווי טאָן איר מאָניטאָר אויב איר טאָן ניט זען אַז די אַפּלאַקיישאַן איז נישט ארבעטן?!"

איך גלויבן אַז איר דאַרפֿן צו אָנהייבן מאָניטאָרינג פּונקט פֿון די באַניצער 'ס פּאָזיציע פונט. אויב דער באַניצער קען נישט זען אַז די אַפּלאַקיישאַן אַרבעט, דאָס איז אַ דורכפאַל. און די מאָניטאָרינג סיסטעם זאָל וואָרענען וועגן דעם ערשטער.
און בלויז דעמאָלט מיר קענען מאָניטאָר די ינפראַסטראַקטשער. אָדער טאָן עס פּאַראַלעל. עס איז גרינגער מיט ינפראַסטראַקטשער - דאָ מיר קענען לעסאָף ינסטאַלירן זאַבביקס.
און איצט איר דאַרפֿן צו גיין צו די רוץ פון די אַפּלאַקיישאַן צו פֿאַרשטיין ווו די טינגז זענען נישט ארבעטן.

מייַן הויפּט געדאַנק איז אַז מאָניטאָרינג זאָל גיין אין פּאַראַלעל מיט די אַנטוויקלונג פּראָצעס. אויב איר דיסטראַקט די מאָניטאָרינג מאַנשאַפֿט פֿאַר אנדערע טאַסקס (קריייטינג סי / קאָמפּאַקטדיסק, סאַנדבאָקסינג, ריאָרגאַנאַזיישאַן פון ינפראַסטראַקטשער), מאָניטאָרינג וועט אָנהייבן צו אָפּשטיי און איר קען קיינמאָל כאַפּן זיך מיט אַנטוויקלונג (אָדער גיכער אָדער שפּעטער איר וועט האָבן צו האַלטן עס).

אַלץ לויט לעוועלס

דאָס איז ווי איך זען די אָרגאַניזאַציע פון אַ מאָניטאָרינג סיסטעם.

1) אַפּפּליקאַטיאָן מדרגה:

מאָניטאָרינג אַפּלאַקיישאַן געשעפט לאָגיק;
מאָניטאָרינג געזונט מעטריקס פון סערוויסעס;
ינאַגריישאַן מאָניטאָרינג.

2) ינפראַסטראַקטשער מדרגה:

מאָניטאָרינג פון אָרקעסטראַטיאָן מדרגה;
סיסטעם ווייכווארג מאָניטאָרינג;
אייַזן מדרגה מאָניטאָרינג.

3) ווידער די אַפּלאַקיישאַן מדרגה - אָבער ווי אַ ינזשעניעריע פּראָדוקט:

קאַלעקטינג און מאָניטאָרינג אַפּלאַקיישאַן לאָגס;
APM;
טרייסינג.

4) אַלאַרמינג:

אָרגאַניזאַציע פון אַ ווארענונג סיסטעם;
אָרגאַניזאַציע פון אַ פליכט סיסטעם;
אָרגאַניזאַציע פון אַ "וויסן באַזע" און וואָרקפלאָוו פֿאַר אינצידענט פּראַסעסינג.

עס ס וויכטיק: מיר באַקומען צו די פלינק נישט נאָך, אָבער גלייך! עס איז ניט דאַרפֿן צו קאַטער מאָניטאָרינג און "עפעס שפּעטער" רעכענען אויס ווער וועט באַקומען אַלערץ. נאָך אַלע, וואָס איז די אַרבעט פון מאָניטאָרינג: צו פֿאַרשטיין ווו אין די סיסטעם עפּעס אַרבעט פאַלש, און צו לאָזן די רעכט מענטשן וויסן וועגן אים. אויב איר לאָזן דעם ביז דעם סוף, די רעכט מענטשן וועלן וויסן אַז עפּעס איז פאַלש נאָר דורך רופן "גאָרנישט אַרבעט פֿאַר אונדז."

אַפּפּליקאַטיאָן לייַער - ביזנעס לאָגיק מאָניטאָרינג

דאָ מיר זענען גערעדט וועגן קאָנטראָלירן די פאַקט אַז די אַפּלאַקיישאַן אַרבעט פֿאַר די באַניצער.

דעם מדרגה זאָל זיין דורכגעקאָכט בעשאַס דער אַנטוויקלונג פאַסע. פֿאַר בייַשפּיל, מיר האָבן אַ קאַנדישאַנאַל פּראָמעטהעוס: עס גייט צו די סערווער וואָס טוט די טשעקס, פּולז די ענדפּוינט, און די ענדפּוינט גייט און טשעק די אַפּי.

ווען אָפט געבעטן צו מאָניטאָר די היים בלאַט צו מאַכן זיכער אַז די פּלאַץ אַרבעט, פּראָוגראַמערז געבן אַ שעפּן וואָס קענען זיין פּולד יעדער מאָל זיי דאַרפֿן צו מאַכן זיכער אַז די אַפּי אַרבעט. און פּראָוגראַמערז אין דעם מאָמענט נאָך נעמען און שרייַבן /אַפּי/טעסט/העללאָוואָרלד
דער בלויז וועג צו מאַכן זיכער אַז אַלץ אַרבעט? ― נײן!

שאפן אַזאַ טשעקס איז יסענשאַלי די אַרבעט פון דעוועלאָפּערס. אַפּאַראַט טעסץ זאָל זיין געשריבן דורך די פּראָוגראַמערז וואָס שרייַבן דעם קאָד. ווייַל אויב איר רינען עס צו דער אַדמיניסטראַטאָר, "דוד, דאָ איז אַ רשימה פון אַפּי פּראָטאָקאָלס פֿאַר אַלע 25 פאַנגקשאַנז, ביטע מאָניטאָר אַלץ!" - גאָרנישט וועט אַרבעטן.
אויב איר דרוקן "העלא וועלט", קיינער וועט קיינמאָל וויסן אַז די אַפּי זאָל און אַרבעט. יעדער API ענדערונג מוזן פירן צו אַ ענדערונג אין טשעקס.
אויב איר שוין האָבן אַזאַ אַ פּראָבלעם, האַלטן די פֿעיִקייטן און אַלאַקייט דעוועלאָפּערס וואָס וועלן שרייַבן די טשעקס, אָדער אָננעמען די לאָססעס, אָננעמען אַז גאָרנישט איז אָפּגעשטעלט און וועט פאַרלאָזן.

טעכניש עצות:

זייט זיכער צו אָרגאַניזירן אַ פונדרויסנדיק סערווער צו אָרגאַניזירן טשעקס - איר מוזן זיין זיכער אַז דיין פּרויעקט איז צוטריטלעך פֿאַר די אַרויס וועלט.
אָרגאַניזירן טשעקס איבער די גאנצע אַפּי פּראָטאָקאָל, ניט בלויז יחיד ענדפּאָינץ.
שאַפֿן אַ פּראָמעטהעוס-ענדפּוינט מיט די פּרובירן רעזולטאַטן.

אַפּפּליקאַטיאָן שיכטע - מאָניטאָרינג פון געזונט מעטריקס

איצט מיר זענען גערעדט וועגן פונדרויסנדיק געזונט מעטריקס פון סערוויסעס.

מיר באַשלאָסן אַז מיר מאָניטאָר אַלע די "כאַנדאַלז" פון די אַפּלאַקיישאַן ניצן פונדרויסנדיק טשעקס, וואָס מיר רופן פֿון אַ פונדרויסנדיק מאָניטאָרינג סיסטעם. אָבער דאָס זענען די "כאַנדאַלז" וואָס דער באַניצער "זעט". מיר ווילן צו זיין זיכער אַז אונדזער באַדינונגס זיך אַרבעט. עס איז אַ בעסער געשיכטע דאָ: K8s האט געזונט טשעקס, אַזוי אַז אין מינדסטער די "קוב" זיך קענען זיין קאַנווינסט אַז די סערוויס אַרבעט. אָבער האַלב פון די טשעקס וואָס איך ווע געזען זענען די זעלבע דרוק "העלא וועלט". יענע. אַזוי ער פּולז אַמאָל נאָך דיפּלוימאַנט, ער געענטפערט אַז אַלץ איז גוט - דאָס איז אַלע. און די סערוויס, אויב עס גיט זיין אייגענע API, האט אַ ריזיק נומער פון פּאָזיציע פונקטן פֿאַר דער זעלביקער אַפּי, וואָס אויך דאַרף זיין מאָניטאָרעד, ווייַל מיר ווילן צו וויסן אַז עס אַרבעט. און מיר זענען שוין מאָניטאָרינג עס ין.

ווי צו ינסטרומענט דעם ריכטיק טעקניקלי: יעדער דינסט יקספּאָוזיז אַן ענדפּוינט וועגן זייַן קראַנט פאָרשטעלונג, און אין די גראַפס פון Grafana (אָדער קיין אנדערע אַפּלאַקיישאַן) מיר זען די סטאַטוס פון אַלע סערוויסעס.

יעדער API ענדערונג מוזן פירן צו אַ ענדערונג אין טשעקס.
שאַפֿן אַ נייַע סערוויס גלייך מיט געזונט מעטריקס.
אַ אַדמיניסטראַטאָר קענען קומען צו די דעוועלאָפּערס און פרעגן "לייג מיר אַ פּאָר פון פֿעיִקייטן אַזוי אַז איך פֿאַרשטיין אַלץ און לייגן אינפֿאָרמאַציע וועגן דעם צו מיין מאָניטאָרינג סיסטעם." אָבער דעוועלאָפּערס יוזשאַוואַלי ענטפֿערן, "מיר וועלן נישט לייגן עפּעס צוויי וואָכן איידער די מעלדונג."
לאָזן די אַנטוויקלונג מאַנאַדזשערז וויסן אַז עס וועט זיין אַזאַ לאָססעס, לאָזן די פאַרוואַלטונג פון די אַנטוויקלונג מאַנאַדזשערז וויסן אויך. ווייַל ווען אַלץ פאלס, עמעצער וועט נאָך רופן און פאָדערן צו מאָניטאָר די "שטענדיק פאַלינג דינסט" (C)
דורך דעם וועג, אַלאַקייט דעוועלאָפּערס צו שרייַבן פּלוגינס פֿאַר Grafana - דאָס וועט זיין אַ גוטע הילף פֿאַר אַדמין.

אַפּפּליקאַטיאָן לייַער - ינטעגראַטיאָן מאָניטאָרינג

ינאַגריישאַן מאָניטאָרינג פאָוקיסיז אויף מאָניטאָרינג קאָמוניקאַציע צווישן געשעפט-קריטיש סיסטעמען.

פֿאַר בייַשפּיל, עס זענען 15 באַדינונגס וואָס יבערגעבן מיט יעדער אנדערער. דאס זענען ניט מער באַזונדער זייטלעך. יענע. מיר קענען נישט ציען די סערוויס אַליין, באַקומען / העללאָוואָרלד און פֿאַרשטיין אַז די סערוויס איז פליסנדיק. ווייַל די אָרדערינג וועב דינסט מוזן שיקן אינפֿאָרמאַציע וועגן די סדר צו די ויטאָבוס - פון די ויטאָבוס, די ווערכאַוס דינסט מוזן באַקומען דעם אָנזאָג און אַרבעטן מיט אים ווייַטער. און די E- בריוו פאַרשפּרייטונג דינסט מוזן פּראָצעס דעם עפעס ווייַטער, עטק.

אַקקאָרדינגלי, מיר קענען נישט פֿאַרשטיין, פּאָקינג אין יעדער יחיד דינסט, אַז עס אַלע אַרבעט. ווייַל מיר האָבן אַ זיכער ויטאָבוס דורך וואָס אַלץ קאַמיונאַקייץ און ינטעראַקץ.
דעריבער, דער בינע זאָל צייכן די בינע פון טעסטינג באַדינונגס פֿאַר ינטעראַקשאַן מיט אנדערע באַדינונגס. עס איז אוממעגלעך צו אָרגאַניזירן קאָמוניקאַציע מאָניטאָרינג דורך מאָניטאָרינג די אָנזאָג מעקלער. אויב עס איז אַ דינסט וואָס אַרויסגעבן דאַטן און אַ דינסט וואָס נעמט עס, ווען מאָניטאָרינג די מעקלער מיר וועלן בלויז זען דאַטן וואָס פליען פון זייַט צו זייַט. אפילו אויב מיר עפעס געראטן צו מאָניטאָר די ינטעראַקשאַן פון די דאַטן ינעווייניק - אַז אַ זיכער פּראָדוצירער פּאָסטן די דאַטן, עמעצער לייענט עס, די לויפן האלט צו גיין צו Kafka - דאָס נאָך וועט נישט געבן אונדז אינפֿאָרמאַציע אויב איין סערוויס געשיקט דעם אָנזאָג אין איין ווערסיע , אָבער די אנדערע דינסט האט נישט דערוואַרטן דעם ווערסיע און סקיפּט עס. מיר וועלן נישט וויסן וועגן דעם, ווייַל די סערוויסעס וועט זאָגן אונדז אַז אַלץ אַרבעט.

וואָס איך רעקאָמענדירן צו טאָן:

פֿאַר סינטשראָנאָוס קאָמוניקאַציע: די ענדפּוינט מאכט ריקוועס צו פֿאַרבונדענע באַדינונגס. יענע. מיר נעמען דעם ענדפּוינט, ציען אַ שריפט ין דער דינסט, וואָס גייט צו אַלע די פונקטן און זאגט "איך קענען ציען דאָרט, און ציען דאָרט, איך קענען ציען דאָרט ..."
פֿאַר ייסינגקראַנאַס קאָמוניקאַציע: ינקאַמינג אַרטיקלען - די ענדפּוינט טשעק די ויטאָבוס פֿאַר פּרובירן אַרטיקלען און דיספּלייז די פּראַסעסינג סטאַטוס.
פֿאַר ייסינגקראַנאַס קאָמוניקאַציע: אַוטגאָוינג אַרטיקלען - די ענדפּוינט סענדז פּרובירן אַרטיקלען צו די ויטאָבוס.

ווי יוזשאַוואַלי כאַפּאַנז: מיר האָבן אַ דינסט וואָס ווארפט ער דאַטן אין די ויטאָבוס. מיר קומען צו דעם דינסט און בעטן איר צו דערציילן אונדז וועגן זייַן ינאַגריישאַן געזונט. און אויב די דינסט דאַרף צו פּראָדוצירן אַ אָנזאָג ערגעץ ווייַטער (וועבאַפּפּ), עס וועט פּראָדוצירן דעם פּראָבע אָנזאָג. און אויב מיר לויפן אַ סערוויס אויף די אָרדערפּראָסעססינג זייַט, עס ערשטער פּאָסטן וואָס עס קענען פּאָסטן פרייַ, און אויב עס זענען עטלעכע אָפענגיק טינגז, עס לייענט אַ גאַנג פון פּראָבע אַרטיקלען פון די ויטאָבוס, פארשטייט אַז עס קענען פּראַסעסינג זיי, באַריכט עס און , אויב נייטיק, פּאָסטן זיי ווייַטער, און וועגן דעם ער זאגט - אַלץ איז גוט, איך בין לעבעדיק.

זייער אָפט מיר הערן די קשיא "ווי קענען מיר פּרובירן דאָס אויף קאַמבאַט דאַטן?" פֿאַר בייַשפּיל, מיר זענען גערעדט וועגן דער זעלביקער אָרדערינג דינסט. דער סדר סענדז אַרטיקלען צו די ווערכאַוס ווו די סכוירע זענען אַוועקגענומען: מיר קענען נישט פּרובירן דאָס אויף קאַמבאַט דאַטן, ווייַל "מיין סכוירע וועט זיין אפגעשריבן!" לייזונג: פּלאַן די גאנצע פּראָבע אין די אָנהייב. איר אויך האָבן אַפּאַראַט טעסץ וואָס מאַכן מאַקס. אַזוי, טאָן דאָס אין אַ דיפּער מדרגה ווו איר האָבן אַ קאָמוניקאַציע קאַנאַל וואָס טוט נישט שאַטן די אָפּעראַציע פון די געשעפט.

ינפראַסטראַקטשער מדרגה

ינפראַסטראַקטשער מאָניטאָרינג איז עפּעס וואָס איז לאַנג שוין געהאלטן מאָניטאָרינג זיך.

ינפראַסטראַקטשער מאָניטאָרינג קענען און זאָל זיין לאָנטשט ווי אַ באַזונדער פּראָצעס.
איר זאָל נישט אָנהייבן מיט ינפראַסטראַקטשער מאָניטאָרינג אויף אַ פליסנדיק פּרויעקט, אפילו אויב איר טאַקע ווילן. דאָס איז אַ ווייטיק פֿאַר אַלע דעוואָפּס. "ערשטער איך וועט מאָניטאָר די קנויל, איך וועט מאָניטאָר די ינפראַסטראַקטשער" - ד.ה. ערשטער, עס וועט מאָניטאָר וואָס ליגט אונטן, אָבער וועט נישט גיין אין די אַפּלאַקיישאַן. ווייַל די אַפּלאַקיישאַן איז אַ ינגקאַמפּראַכענסיבאַל זאַך פֿאַר דעוואָפּס. עס איז געווען ליקט צו אים, און ער טוט נישט פֿאַרשטיין ווי עס אַרבעט. און ער פארשטייט די אינפראסטרוקטור און הייבט אן דערמיט. אָבער ניט - איר שטענדיק דאַרפֿן צו מאָניטאָר די אַפּלאַקיישאַן ערשטער.
דו זאלסט נישט גיין אָוווערבאָרד מיט די נומער פון אַלערץ. קאַנסידערינג די קאַמפּלעקסיטי פון מאָדערן סיסטעמען, אַלערץ זענען קעסיידער פליענדיק, און איר מוזן עפעס לעבן מיט דעם בינטל פון אַלערץ. און דער אָנרופן מענטש, נאָך געקוקט אויף אַ הונדערט פון די ווייַטער אַלערץ, וועט באַשליסן "איך טאָן נישט וועלן צו טראַכטן וועגן אים." אַלערץ זאָל נאָר געבנ צו וויסן וועגן קריטיש טינגז.

אַפּפּליקאַטיאָן מדרגה ווי אַ געשעפט אַפּאַראַט

שליסל ווייזט:

ELK. דאָס איז די ינדאַסטרי נאָרמאַל. אויב פֿאַר עטלעכע סיבה איר זענט נישט אַגגרעגייטינג לאָגס, אָנהייב טאן אַזוי מיד.
APM. פונדרויסנדיק אַפּמס ווי אַ וועג צו געשווינד פאַרמאַכן אַפּלאַקיישאַן מאָניטאָרינג (NewRelic, BlackFire, Datadog). איר קענען ינסטאַלירן דעם זאַך טעמפּערעראַלי צו בייַ מינדסטער עפעס פֿאַרשטיין וואָס איז געשעעניש מיט איר.
טרייסינג. אין דאַזאַנז פון מיקראָסערוויסעס, איר האָבן צו שפּור אַלץ, ווייַל די בקשה ניט מער לעבן אויף זיך. עס איז זייער שווער צו לייגן שפּעטער, אַזוי עס איז בעסער צו מיד פּלאַן טרייסינג אין אַנטוויקלונג - דאָס איז די אַרבעט און נוצן פון די דעוועלאָפּערס. אויב איר האָט נישט ימפּלאַמענאַד עס נאָך, ינסטרומענט עס! זען יעגער / זיפּקין

אַלערטינג

אָרגאַניזאַציע פון אַ אָנזאָג סיסטעם: אין טערמינען פון מאָניטאָרינג אַ פּלאַץ פון טינגז, עס זאָל זיין אַ יונאַפייד סיסטעם פֿאַר שיקן נאָוטאַפאַקיישאַנז. איר קענט אין גראַפאַנאַ. אין די מערב, אַלעמען ניצט PagerDuty. אַלערץ זאָל זיין קלאָר (למשל ווו זיי געקומען פון ...). און עס איז קעדייַיק צו קאָנטראָלירן אַז נאָוטאַפאַקיישאַנז זענען באקומען אין אַלע
אָרגאַניזאַציע פון אַ פליכט סיסטעם: אַלערץ זאָל ניט זיין געשיקט צו אַלעמען (אָדער אַלעמען וועט רעאַגירן אין אַ מאַסע, אָדער קיין איינער וועט רעאַגירן). דעוועלאפערס דארפן אויך זיין אנרופן: זייט זיכער צו דעפינירן פאראנטווארטליכקייטן, מאכן קלארע אינסטרוקציעס און שרייבן אין דעם ווער מען דארף רופן אויף מאנטאג און מיטוואך, און וועמען צו רופן דינסטאג און פרייטאג (אנדערע וועלן זיי נישט רופן קיינעם אפילו אין די געשעעניש פון אַ גרויס פּראָבלעם - זיי וועלן זיין דערשראָקן צו וועקן איר אָדער שטערן: מענטשן בכלל טאָן ניט ווי צו רופן און וועקן אנדערע מענטשן, ספּעציעל בייַ נאַכט). און דערקלערן אַז אַסקינג פֿאַר הילף איז נישט אַ גראדן פון ינקאַמפּאַטאַנס ("איך בעט פֿאַר הילף, אַז מיטל איך בין אַ שלעכט אַרבעטער"), מוטיקן ריקוועס פֿאַר הילף.
אָרגאַניזאַציע פון אַ "וויסן באַזע" און וואָרקפלאָוו פֿאַר אינצידענט פּראַסעסינג: פֿאַר יעדער ערנסט אינצידענט, אַ פּאָסט-מאָרטעם זאָל זיין פּלאַננעד, און ווי אַ צייַטווייַליק מאָס, אַקשאַנז וואָס וועט האַלטן דעם אינצידענט זאָל זיין רעקאָרדעד. און מאַכן עס אַ פיר אַז ריפּיטיד אַלערץ זענען אַ זינד; זיי דאַרפֿן צו זיין פאַרפעסטיקט אין קאָד אָדער ינפראַסטראַקטשער אַרבעט.

טעכנאָלאָגיע אָנלייגן

לאָמיר ימאַדזשאַן אַז אונדזער סטאַק איז ווי גייט:

דאַטן זאַמלונג - פּראָמעטהעוס + גראַפאַנאַ;
קלאָץ אַנאַליסיס - ELK;
פֿאַר APM אָדער טרייסינג - Jaeger (Zipkin).

די ברירה פון אָפּציעס איז נישט קריטיש. ווייַל אויב אין די אָנהייב איר פארשטאנען ווי צו מאָניטאָר די סיסטעם און געשריבן אַ פּלאַן, איר אָנהייבן צו קלייַבן מכשירים צו פּאַסן דיין באדערפענישן. די קשיא איז וואָס איר האָט אויסדערוויילט צו מאָניטאָר אין דער ערשטער אָרט. ווייַל טאָמער די געצייַג וואָס איר האָט אויסדערוויילט אין די אָנהייב איז נישט פּאַסיק פֿאַר דיין באדערפענישן.

עטלעכע טעכניש פונקטן וואָס איך זען אומעטום לעצטנס:

מען שטופּט פּראָמעטהעוס אינעווייניק אין קובערנעטעס – ווער איז דאָס געקומען?! אויב דיין קנויל קראַשיז, וואָס וועט איר טאָן? אויב איר האָבן אַ קאָמפּלעקס קנויל ין, עס זאָל זיין אַ סאָרט פון מאָניטאָרינג סיסטעם ין דער קנויל, און עטלעכע אַרויס, וואָס וועט קלייַבן דאַטן פֿון ין דער קנויל.

ין דער קנויל מיר קלייַבן לאָגס און אַלץ אַנדערש. אָבער די מאָניטאָרינג סיסטעם מוזן זיין אַרויס. זייער אָפט, אין אַ קנויל ווו פּראָמטהעוס איז אינסטאַלירן ינעווייניק, עס זענען אויך סיסטעמען וואָס דורכפירן פונדרויסנדיק טשעקס פון די אָפּעראַציע פון די פּלאַץ. וואָס אויב דיין קאַנעקשאַנז צו די אַרויס וועלט האָבן דראַפּט און די אַפּלאַקיישאַן טוט נישט אַרבעטן? עס טורנס אויס אַז אַלץ איז גוט ין, אָבער עס טוט נישט מאַכן די טינגז גרינגער פֿאַר יוזערז.

פיינדינגז

מאָניטאָרינג אַנטוויקלונג איז נישט די ינסטאַלירונג פון יוטילאַטיז, אָבער די אַנטוויקלונג פון אַ ווייכווארג פּראָדוקט. 98% פון הייַנט ס מאָניטאָרינג איז קאָדירונג. קאָדירונג אין באַדינונגס, קאָדירונג פונדרויסנדיק טשעקס, קאָנטראָלירן פונדרויסנדיק באַדינונגס, און דאָס איז אַלע.
דו זאלסט נישט וויסט די צייט פון דיין דעוועלאָפּערס אויף מאָניטאָרינג: עס קען נעמען אַרויף צו 30% פון זייער אַרבעט, אָבער עס איז ווערט עס.
דעוואָפּס, טאָן ניט זאָרג אַז איר קענען נישט מאָניטאָר עפּעס, ווייַל עטלעכע זאכן זענען אַ גאָר אַנדערש וועג פון טראכטן. איר געווען ניט אַ פּראָגראַמיסט, און מאָניטאָרינג אַרבעט איז פּונקט זייער אַרבעט.
אויב די פּרויעקט איז שוין פליסנדיק און ניט מאָניטאָרעד (און איר זענט אַ פאַרוואַלטער), אַלאַקייט רעסורסן פֿאַר מאָניטאָרינג.
אויב די פּראָדוקט איז שוין אין פּראָדוקציע, און איר זענט אַ דעוואָפּס וואָס איז געווען געזאָגט צו "שטעלן מאָניטאָרינג" - פּרוּווט צו דערקלערן די פאַרוואַלטונג וואָס איך געשריבן אַלע דעם וועגן.

דאָס איז אַן עקסטענדעד ווערסיע פון דעם באַריכט ביי די סיינט היגהלאָאַד ++ זיצונג.

אויב איר זענט אינטערעסירט אין מיין געדאנקען און געדאנקען אויף עס און פֿאַרבונדענע טעמעס, דאָ איר קענען לייענען דעם קאַנאַל ????

מקור: www.habr.com

איז מאָניטאָרינג טויט? - לאַנג לעבן מאָניטאָרינג