אָפטע קראַשיז פון Apache2 מיט HestiaCP? מאָניטאָר אויטאָמאַטיש מאָניטאָרינג און טראָובלעשווטינג גייד (מיט פולשטענדיק קאָנפיגוראַציע)

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

די פּיטפאָלז וואָס איך האָב באַגעגנט בשעת איך האָב גענוצט מאָניט צו מאָניטאָרירן אַפּאַטשי2

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

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

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

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

איך. . .

איך מודה, איך האב עס נישט גענומען ערנסט אין אנפאנג. אפאטשי2 מאניטארינג? איר קענט געפינען א סך טעמפלעט קאנפיגוראציעס אויף די אינטערנעץ, נאר קאפירן און איינפאסטן. אבער יענער איינפאסטן פראצעס האט מיך טאקע אויפגעברויזט.

די וואָרצל־אורזאַך פֿון דעם קאָנפליקט צווישן HestiaCP'ס דיפאָלט אַרכיטעקטור און מאָניט פּאָרטן

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

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/usr/sbin/service apache2 start"
    stop program  = "/usr/sbin/service apache2 stop"
    if failed host 127.0.0.1 port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

עס קוקט אויס גוט, נישט אזוי? עס טשעקט פּאָרט 80, און אויב עס קראַשט, ריסטאַרט עס. אויב עס קראַשט נאָך אַלץ נאָך 5 ריסטאַרטס, גייט עס אויס פון צייט.

די פראבלעם איז, אייער Apache2 לויפט ניטאמאל אויף פארט 80.

דאָס איז אַ פאַל פון HestiaCP, און די וואָרצל־אורזאַך פאַרוואָס אַ סך מענטשן פאַלן אַרײַן אין דעם. HestiaCP'ס דיפאָלט אַרכיטעקטור איז אַ ריווערס פּראָקסי פון Nginx + Apache2, מיט Nginx וואָס נעמט פּאָרטן 80 און 443 פֿאָרויס, און Apache2 לויפט אויף דעם לאָקאַלן פּאָרט 8081 הינטן.

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

נאכן ריסטארטן, איז דער פארט נאך אלץ 8081. מאניט פרובירט דאן צו פראבירן פארט 80, וואס אויך פאלט דורך, ממילא ריסטארט עס נאכאמאל. דער ציקל איבערחזרט זיך ביז מאניט באשליסט אז עס איז נישט מער ווי צו פאררעכטן און עס לויפט אויס.

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

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

נאכדעם וואס מען טוישט דעם פארט פון 80 צו 8081, זאל מאניט טעארעטיש קענען עס דעטעקטירן, נישט אזוי?

אבער, אין דער ווירקלעכקייט, באריכטעט עס נאך ​​אלץ מאנchmal "עקסעקוציע דורכגעפאלן ".

נאך א לאנגע צייט זיך אנשטרענגען, האב איך ענדליך אנטדעקט אז די סיבה איז פשוט: די PID טעקע איז געווען פארדארבן.

טראַכט וועגן דעם, מאָניט האָט ווילד ריסטאַרטעד Apache2, יעדעס מאָל געצוואונגען עס צו טייטן און ריסטאַרטן, גייענדיק אַהין און צוריק עטלעכע מאָל. בעת דעם פּראָצעס, קען די טעקע /var/run/apache2/apache2.pid ווערן 0 בייטס.

מיט אנדערע ווערטער, די טעקע איז נאך דא, אבער זי איז ליידיג.

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

ווען איך האָב דאָס געזען, בין איך געווען אָן ווערטער פֿאַר אַ מאָמענט.

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

פראבלעם לייזונג און פארריכטונג טריט פאר Apache2 מאָניטאָרינג אין HestiaCP סביבה

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

דער ערשטער שריט איז צו באַשטימען אויף וועלכן פּאָרט אייער Apache2 הערט. פשוט טיפּ אַ באַפֿעל אין טערמינאַל.

netstat -tulpn | grep apache2

אדער, קענט איר ניצן דעם `ss` באַפֿעל; דער עפֿעקט איז דער זעלביקער.

ss -tulpn | grep apache2

איר וועט זען אַ רעזולטאַט ענלעך צו דעם.

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

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

דער צווייטער שריט איז צו פאררעכטן די פארדארבענע PID טעקע. דאס איז פשוטער.

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

ערשטנס, פּויזירט מאָניט מאָניטאָרינג צו פאַרהיטן עס פון אַריינמישן זיך בשעת איר פאַרריכט זאַכן. דערנאָך, ריסטאַרט Apache2 צו לאָזן עס איבערשרייבן אַ ריינעם PID. צום סוף, ניצט `cat` צו קאָנטראָלירן דעם אינהאַלט פון דער טעקע; עס זאָל אַנטהאַלטן אַ שטריקל פון נומערן, נישט אַ ליידיקן שטריקל.

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

קאָמפּאַראַטיווע אַנאַליז פון מאָניט טראַדיציאָנעלע אַדאַפּטיווע און אַגרעסיווע פּראַטעקטיוו קאָנפיגוראַציעס

אָנליין טוטאָריאַלז וועגן קאָנפיגורירן Apache2 מיט מאָניט פאַלן בכלל אין צוויי קאַטעגאָריעס.

איין טיפ איז דער "טראדיציאנעלער אדאפטאציע טיפ," וואס ניצט דעם `סערוויס` קאמאנד צו פירן סערוויסעס און קאנטראלירן לאקאלע פארטן אן צולייגן צו פיל קאמפליצירטע באגרענעצונגען. די קאנפיגוראציע קען גענוצט ווערן אויף HestiaCP דורך פשוט טוישן דעם פארט, און עס איז רעלאטיוו סטאביל.

נאך א צוגאנג איז די "אגרעסיווע שוץ" מעטאד, וואס ניצט systemctl צו פירן סערוויסעס, לייגט צו קינד פראצעס באגרענעצונגען, און באנוצט שטרענגערע דעטעקציע לאגיק. עס קוקט גוט אויס, אבער עס האט א פאטאלן חסרון: די סטאָפּ קאמאנדע וואס ווערט גענוצט איז `killall -9`.

וואָס מיינט `killall -9`? דאָס מיינט צו געצוואונגען טייטן דעם דעווייס, נישט קוקנדיק אויף וואָס עס טוט. די ברוט-פאָרס אָפּעראַציע קען לייכט איבערלאָזן קאָרומפּירטע PID טעקעס, וואָס איז די פּראָבלעם וואָס איך האָב נאָר דערמאָנט.

מיין פערזענלעכע ערפארונג איז אז באגרענעצן די צאל קינד פראסעסן אין אן אגרעסיווער קאנפיגוראציע איז טאקע נוצלעך. ווען אייער Apache2 ווערט איבערוועלטיגט דורך א CC אטאקע, קען באגרענעצן די צאל קינד פראסעסן פארמיידן אז דער סערווער זאל אויסלאפן פון זכרון. אבער, דער `killall -9` צוגאנג איז באמת נישט ניצלעך.

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

העסטיאַCP אַפּאַטשי2 מאָניט בעסטע פּראַקטיק קאָנפיגוראַציע

מאָדיפֿיצירט די טעקע /etc/monit/conf.d/apache2 מיטן פֿאָלגנדיקן אינהאַלט.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/bin/systemctl start apache2"
    stop program  = "/bin/systemctl stop apache2"
    if children > 120 for 2 cycles then restart
    if failed host 127.0.0.1 port 8081 protocol http for 2 cycles then restart
    if 5 restarts within 10 cycles then timeout

לאָמיר איך קורץ דערקלערן די לאָגיק הינטער די עטלעכע שורות קאָנפיגוראַציע.

שרייב פּאָרט 8081 צו פּינקטלעך פּאַסן צו HestiaCP'ס ריווערס פּראָקסי אַרכיטעקטור; הער אויף צו נאַריש שרייבן פּאָרט 80.

ניצט דעם `systemctl stop` באַפֿעל אַנשטאָט `killall -9` צו האַלטן די PID טעקע, כּדי זי נישט צו קאָרומפּירן.

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

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

דער לעצטער טיימאַוט שוועל ווערט רילאַקסט צו 5 ריסטאַרטס אין 10 ציקלען, וואָס לאָזט גענוג שולד טאָלעראַנץ.

HestiaCP מאָניטאָר מאָניטאָרינגקאָנפיגוראַציע טראָובלעשווטינג קיצער און דערפאַרונג ייַנטיילונג

נאכדעם וואס איך האב געמאכט די קאנפיגוראציע ענדערונגען, האב איך מאניטארירט apache2, און די פאנעל האט ענדליך געוויזן א גרינע "OK" אינדיקאטאר.

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

מאָניט איז אַ גוטע זאַך אין זיך, און מאָניטאָרירן דעמאָנען איז עפּעס וואָס יעדער סערווער זאָל טאָן. אָבער די פּראָבלעם איז אַז פילע אָנליין טוטאָריאַלז זענען באַזירט אויף דער הנחה אַז "אַפּאַטשי2 ניצט אויסשליסלעך פּאָרט 80," בשעת העסטיאַקפּי ניצט אַ ריווערס פּראָקסי, וואָס מיינט אַז די הנחה איז נישט אמת.

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

אַזוי אויב איר ניצט אויך HestiaCP און שפּילט זיך אַרום מיט Monit צו מאָניטאָרירן Apache2, געדענקט נאָר צוויי זאַכן: טוישט דעם פּאָרט צו 8081, און ניצט דעם `systemctl` באַפֿעל צו עס אָפּשטעלן, נישט `killall -9`. אויב איר טוט די צוויי זאַכן, זאָלט איר קענען פֿאַרמייַדן נאָך פּראָבלעמען.

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

א דאנק פארן לייענען מיין ארטיקל. זעהט אייך דאס נעקסטע מאל.