לפני שנתיים כבר כתבתי פוסט כשל פשוט לאתר про בסדר. עכשיו יש קצת פיתוח של הפרויקט, וגם פרסמתי קוד המקור בצד השרת של okerr תחת רישיון פתוח, זו הסיבה שהחלטתי לכתוב את הביקורת הקצרה הזו על Habr.

[ גודל מלא ]

למי זה יכול לעניין

זה עשוי לעניין אותך אם אתה עובד בצוות קטן או לבד. אין לך ניטור ואתה לא בטוח אם אתה באמת צריך את זה. או שניסית ניטור רציני פופולרי "עבור הבנים הגדולים", אבל זה איכשהו "לא המריא" בשבילך, או שזה עובד בתצורת ברירת מחדל כמעט ולא שינה את חייך הרבה. וגם - אם אתה בהחלט לא מתכנן להקצות עובד שלם (או אפילו מחלקה) לנטר את לוח המחוונים לניטור לפחות כמה שעות ביום או להגדיר אותו.

למה okerr זה יוצא דופן

בשלב הבא אראה תכונות מעניינות של האוקרה שמבדילות אותה מכמה מערכות ניטור אחרות.

Okerr הוא ניטור היברידי

במהלך ניטור פנימי, פועל "סוכן" במכונות המנוטרות, אשר מעביר נתונים לשרת הניטור (לדוגמה, שטח דיסק פנוי). כאשר הוא חיצוני, השרת מבצע בדיקות ברשת (לדוגמה, פינג או זמינות אתר אינטרנט). לכל גישה יש את המגבלות שלה. Okerr משתמש בשתי האפשרויות. בדיקות בתוך שרתים מבוצעות על ידי סוכן קל מאוד (30Kb) או סקריפטים ויישומים משלך, ובדיקות רשת מבוצעות באמצעות חיישני okerr במדינות שונות.

okerr הוא לא רק תוכנה, אלא גם שירות

חלק השרת של כל ניטור הוא גדול ומורכב, קשה להתקנה ולהגדיר, והוא דורש משאבים. עם okerr אתה יכול להתקין שרת ניטור משלך (זה בחינם וקוד פתוח), או שאתה יכול פשוט להשתמש רק בחלק הלקוח ולהשתמש בשירות של השרת שלנו. גם בחינם.

אם הניטור מאפשר לך לפצות ולכסות על חוסר האמינות בשרתים ובאפליקציות, אז עולה שאלה פילוסופית - מי השומר? איך הניטור יספר לנו על בעיה אם היא עצמה "מתה" מסיבה כלשהי, בנפרד או יחד עם המשאבים האחרים שלך (למשל, הערוץ למרכז הנתונים נפל)? בעת שימוש בשירות החיצוני okerr - בעיה זו נפתרה - תקבלו התראה גם אם כל הדאטה סנטר עם השרתים שלכם חסר חשמל או מותקף על ידי זומבים.

כמובן, יש סיכון ששרת okerr עצמו לא יהיה זמין, זה נכון (כפי שאתה יודע, 90% מהאמינות תמיד מתקבלים בפשטות ו"חינם", 99% במינימום מאמץ, וכל תשע שלאחר מכן הוא קשה יותר באופן אקספוננציאלי). אבל, ראשית, הסיכוי שזה יקרה נמוך יותר, ושנית, הבעיה עלולה להיעלם רק אם היא חופפת לבעיות בשרתים שלנו. אם יש לנו 99.9% מהימנות, ויש לך 99.9% (מספרים לא גבוהים מדי), אז הסיכוי לכשל שלא מזוהה הוא 0.1% מ-0.1% = 0.0001%. הוספת שלוש תשיעיות לאמינות שלך כמעט ללא מאמץ וללא עלות היא טובה מאוד!

יתרון נוסף של ניטור כשירות הוא שספק אחסון או סטודיו אינטרנט יכול להתקין שרת okerr ולספק גישה ללקוחות כשירות נוסף בתשלום או בחינם. למתחרים שלך יש רק אירוח ואתרי אינטרנט, אבל יש לך אירוח אמין עם ניטור.

Okerr עוסק באינדיקטורים

המחוון הוא "נורה". יש לו שני מצבים עיקריים - ירוק (בסדר) או אדום (ERR). הפרויקט מכיל אינדיקטורים רבים מקובצים (לדוגמה, לפי שרת). בעמוד הראשי של הפרויקט רואים מיד שאו שהכל ירוק (ואפשר לסגור אותו), או שמשהו מואר באדום וצריך לתקן. בעת מעבר בין מצבים אלה, נשלחת התראה. פעם ביום בזמן שאתם מקימים אותו, נשלח סיכום הפרויקט.

לכל מחוון okerr יש תנאים מובנים שבהם הוא משנה מצב (ב-Zabix זה נקרא טריגר). לדוגמה, ממוצע העומס צריך להיות לא יותר מ-2 (כמובן, זה ניתן להגדרה). ולכל בדיקה פנימית (ממוצע טעינה, דיסק פנוי,...) יש כלב שמירה. אם מסיבה כלשהי לא נקבל אישור מוצלח במועד שנקבע, נרשמת שגיאה ונשלחת התראה.

דפוס העבודה הרגיל שלנו הוא לבדוק מיילים בבוקר, ולהסתכל על הסיכום בין שאר המכתבים (אנחנו מתזמנים אותו בתחילת העבודה). אם הכל בסדר בו, אנחנו עושים דברים חשובים אחרים (אבל ליתר ביטחון, אנחנו יכולים להסתכל במהירות על לוח המחוונים של okerra ולוודא שהכל ירוק ברגע זה). אם מגיעה התראה, אנחנו מגיבים.

כמובן שאפשר פשוט לשמור אינדיקטורים "אינפורמטיביים" (כדי לראות את תמונת הרשת מהניטור), אבל הכל נעשה כדי ליצור בפשטות, בקלות ובמהירות מחוונים במיוחד לניטור אוטומטי ושליחת התראות.

המטרה שלשמה אתה מגדיר את okerr היא בהתראות, כדי שתוכל ליצור אינדיקטור תוך דקה, הוא יכול "לישון" לשנה, רק לקבל עדכונים, וכששנה לאחר מכן משהו נשבר, הוא נדלק ושולח התראה. הדקה שבזבזת פעם ביצירת אינדיקטור השתלמה; למדת על הבעיה מיד, לפני כל אחד אחר. ייתכן שהם תיקנו את זה לפני שמישהו שם לב. משהו שהועלה מהר לא נחשב לנפל!

אבטחה

זה יהיה חבל אם תגדיר ניטור למען הגברת האמינות, אבל כתוצאה מכך, אתה מותקף דרך הרשת דרכה, ויש די הרבה פגיעויות ברשת בכלי ניטור שונים (זאביקס, נאגיוס).

סוכן (okerrmod מהחבילה תקציר) הפועל על המערכת אינו שרת רשת, אלא לקוח. לכן, אין פורטים פתוחים נוספים בשרת המנוטר, הלקוח עובד בקלות מאחורי חומת אש או NAT וקשה מאוד (הייתי אומר "בלתי אפשרי") לפרוץ דרך הרשת, שכן עקרונית הוא לא מקשיב לרשת שֶׁקַע.

כיסוי ניטור מלא

עכשיו הכלל שלנו הוא שאנחנו לומדים על כל הבעיות הטכניות מאוקר. אם פתאום הכלל מופר (okerr לא התריע על התרחשותו הקרובה (אם זה אפשרי) או שזה כבר התרחש) - אנחנו מוסיפים צ'קים ל-okerr.

בדיקות חיצוניות

סט טיפוסי למדי:

• פינג
• סטטוס http
• בדיקת תקפות וטריות תעודת SSL (תזהיר אם הוא עומד לפוג)
• פתח את יציאת TCP והבאנר עליה
• http grep (הדף [לא חייב] להכיל טקסט מסוים)
• sha1 hash כדי לתפוס שינויים בעמוד.
• DNS (רשומת DNS חייבת להיות בעלת ערך ספציפי)
• WHOIS (יתריע אם הדומיין עומד להתקלקל)
• Antispam DNSBL (בדיקת מארח מול 50+ רשימות שחורות נגד דואר זבל בבת אחת)

בדיקות פנימיות

כמו כן, סט סטנדרטי למדי (אך ניתן להרחבה בקלות).

• df (שטח דיסק פנוי)
• טעינה ממוצעת
• opentcp (פתח שקעי האזנה של TCP - יודיע אם משהו התחיל או קרס)
• uptime - רק זמן פעולה בשרת. יודיע אם זה השתנה (כלומר, השרת עמוס יתר על המידה)
• client_ip
• dirsize - אנו משתמשים בו כדי לעקוב מתי ה-rootfs של המחשב הווירטואלי שלנו חורגים מהגודל המותר, מבלי להכניס מגבלות קפדניות, וגודל ספריות הבית של המשתמש
• ריק ולא ריק - עקוב אחר קבצים שצריכים להיות ריקים (או לא ריקים). למשל, יומן השגיאות של שרת okerr עצמו אמור להיות ריק, ואם יש בו אפילו שורה, אקבל הודעה ואבדוק. אבל mail.log בשרת הדואר לא אמור להיות ריק (N דקות לאחר הסיבוב). ולפעמים זה היה ריק עבורנו לאחר עדכון מערכת, כאשר logrotate לא הצליח להפעיל מחדש את rsyslog כראוי.
• linecount - מספר השורות בקובץ (כמו wc -l). אנו משתמשים בו כתחליף רך יותר לריק, כאשר יומן השגיאות עדיין יכול לגדול, אך רק לאט (לדוגמה, Googlebot פוגע בכמה דפים סגורים). יש הגבלה של 2 שורות ב-20 דקות. אם הוא גבוה יותר, תהיה התראה

בדיקות פנימיות מעניינות

אם קראתם "באלכסון" עד לנקודה זו, כעת יהיה מעניין יותר לקרוא בעיון רב יותר.

גיבויים

עוקב אחר גיבויים בספרייה. לקבצי הגיבוי שלנו יש שמות כמו "ServerName-20200530.tar.gz". עבור כל שרת ב- okerr, נוצר המחוון ServerName-DATE.tar.gz (התאריך בפועל משתנה לשורה "DATE"). גם עצם נוכחותו של גיבוי טרי וגודלו מנוטרים (לדוגמה, זה לא יכול להיות פחות מ-90% מהגיבוי הקודם).

מה צריך לעשות כדי שגיבוי חדש יתחיל להיות במעקב אחרי שהתחלנו ליצור אותו ולשים אותו בספרייה הזו? שום דבר! זוהי גישה נוחה מאוד כאשר אתה צריך לעשות "כלום" כי:

• לעשות "כלום" זה די מהיר, זה חוסך זמן
• קשה לשכוח לעשות "כלום"
• קשה לעשות "שום דבר" לא בסדר, עם שגיאה. שום דבר אינו השיטה האמינה ביותר

אם פתאום קבצי גיבוי טריים יפסיקו להופיע, תהיה התראה. אם, למשל, השבתת את אחד השרתים, ולא אמורים להיות גיבויים נוספים, תצטרך למחוק את המחוון (דרך ממשק האינטרנט או מהמעטפת דרך ה-API).

maxfilesz

עוקב אחר גודל הקבצים הגדולים ביותר (בדרך כלל: /var/log/*). זה מאפשר לך לתפוס בעיות בלתי צפויות, למשל, סיסמאות בכוח גס או שליחת דואר זבל דרך השרת.

runstatus/runline

אלו שני מודולי פרוקסי חשובים להפעלת תוכניות אחרות בשרת. Runstatus מדווח על קוד היציאה של התוכנית למחוון. לדוגמה, okerr אינו (דורש) מודול כדי לבדוק ששירותי systemd פועלים. זה נעשה באמצעות runstatus (ראה להלן). Runline - מדווח לשרת על הקו שהתוכנית מייצרת. לדוגמה, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" בתצורת Runline בשרת שלנו יוצרת מחוון servername:temp עם טמפרטורת המעבד.

SQL

מבצע שאילתה מספרית ל-MySQL ומדווח על התוצאה למחוון. במקרה פשוט, אתה יכול לעשות, למשל, "SELECT 1" - זה יבדוק שה-DBMS בכללותו עובד.

אבל אפליקציה הרבה יותר מעניינת היא, למשל, מעקב אחר מספר ההזמנות בחנות מקוונת. אם אתה יודע שיש לך 100 הזמנות או יותר לשעה, אתה יכול להגדיר את המגבלה המינימלית ל-100 או 80. ואז אם המכירות שלך ירדו פתאום, תקבל התראה ותוכל להבין את זה.

שימו לב שזה לא משנה מאיזו סיבה בלתי צפויה זה קרה:

• השרת פשוט לא זמין (חסר אנרגיה או בלי רשת), וההתראה הגיעה מהעובדה שהמחוון היה "רקוב".
• השרת עמוס במשהו, הוא עובד לאט או מנות אבודות, זה לא נוח למשתמשים והם עוזבים בלי לבצע רכישות
• השרת כלול ברשימות הספאם ודואר ממנו לא מתקבל, משתמשים לא יכולים להירשם
• תקציב קמפיין הפרסום אזל, הבאנרים לא מסתובבים.

יכולות להיות כל מספר סיבות, ואת כולן לא ניתן לצפות מראש, וקשה טכנית לעקוב אחריה. אך ניתן לעקוב בנוחות אחר הפרמטר הסופי (הזמנות) ולקבוע מהם שהמצב חשוד וראוי לטפל בו.

אינדיקטורים לוגיים

מאפשר שימוש בביטויים בוליאניים (תחביר Python) באמצעות מודול לאמת(מאמר על Habré). נתונים מהפרויקט ומהאינדיקטורים שלו זמינים לביטוי. לדוגמה, בפרק על בדיקת SQL למעלה, אולי שמתם לב לנקודת תורפה - במהלך היום אנחנו יכולים לקבל 100 מכירות בשעה, אבל בלילה - 20, וזה נפוץ, לא בעיה. מה עלי לעשות? המחוון ייכנס לפאניקה כל הזמן בלילה.

אתה יכול ליצור שני אינדיקטורים, יום ולילה. הפוך את שניהם ל"שקטים" (הם לא ישלחו התראות). וליצור אינדיקטור לוגי שמחייב שמחוון היום יהיה תקין לפני 20:00, ואחרי 20:00 מספיק שמחוון הלילה יהיה תקין.

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

כמו כן, ניתן לקבוע את השעה המותרת לעבודה, למשל, מ-3 עד 5 לפנות בוקר. לא אכפת לנו אם שרתים ואתרים יקרסו במהלך הזמן הזה. אבל ב-5:00 הם צריכים לעבוד. אם הם לא עובדים בזמן אחר - התראה. המחוון הלוגי גם מאפשר לך לקחת בחשבון יתירות שרת. אם יש לך 5 שרתי אינטרנט, מנהלי מערכת יכולים לכבות 1-2 שרתים בכל עת. אבל אם יש פחות מ-3 מתוך 5 שרתים בקרב, תהיה התראה.

הדוגמאות שלמעלה אינן פונקציות טובות, לא תכונות מסוימות שצריך להפעיל ולהגדיר. ל-Okerra אין את כל הפונקציות הללו, אבל יש מודול לוגי שמאפשר ליישם את הפונקציונליות הזו (בערך כמו בשפת תכנות - אם יש לנו אופרטורים אריתמטיים, אז אנחנו לא צריכים פונקציה מיוחדת לחישוב 20% מע"מ מהשפה, אתה תמיד יכול לעשות זאת בעצמך כדי שיתאים לצרכים שלך).

Logic Indicator הוא כנראה אחד הנושאים המורכבים יחסית ב- okerr, אבל החדשות הטובות הן שאתה לא צריך לשלוט בו עד שאתה צריך. אך יחד עם זאת, הם מרחיבים מאוד את היכולות, תוך שמירה על המערכת עצמה די פשוטה.

הוספת צ'קים משלך

אני מאוד רוצה להעביר את הרעיון ש- okerr הוא לא סט של אלפי צ'קים מוכנים לכל אירוע, אלא להיפך - קודם כל - מנוע פשוט עם יכולת פשוטה ליצור צ'קים משלך. יצירת צ'קים משלך ב-okerr אינה משימה עבור האקרים, מפתחי שותפים או לפחות משתמשי okerr מתקדמים, אלא משימה אפשרית עבור כל מנהל שהתקין לינוקס בפעם הראשונה לפני חודש.

בדיקות שכר מינימום נעשות באמצעות המודול מצב ריצה:

השורה הזו בתצורה מצב ריצה יודיע לך אם /bin/true פתאום לא מתחיל או יחזיר משהו אחר מלבד 0.

true_OK=/bin/true

רק שורה אחת - והנה אנחנו כבר קצת מוּרחָב פונקציונליות בסדר.

אפילו לבדיקה כזו יש כבר ערך: אם פתאום השרת שלך קורס, המחוון המתאים בשרת okerr לא יתעדכן בזמן, ולאחר שהזמן יעבור תופיע התראה.

בדיקה זו תודיע ששרת apache2 קרס (טוב, אי אפשר לדעת...):

apache_OK="systemctl is-active --quiet apache2"

אז אם אתה דובר שפת תכנות כלשהי, ולפחות יכול לכתוב סקריפטים של מעטפת, אז אתה כבר יכול להוסיף צ'קים משלך.

קשה יותר - אתה יכול לכתוב (בכל שפה) מודול משלך עבור okerrmod. במקרה הפשוט ביותר זה נראה כך:

#!/usr/bin/python3

print("STATUS: OK")

זה לא מאוד קשה? המודול חייב לבצע את הבדיקה בעצמו ולהוציא את התוצאות ל-STDOUT. מודול מורכב יותר נותן, למשל, את זה:

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32

הוא מעדכן מספר אינדיקטורים בבת אחת (מופרדים בשורה ריקה), יוצר אותם במידת הצורך, מציין פרטי אימות ותג שבאמצעותו קל למצוא את האינדיקטורים הדרושים בלוח המחוונים.

מברק

יש בוט של טלגרם @OkerrBot. אתה לא צריך להעמיס את הטלפון שלך באפליקציות נפרדות (אני לא אוהב את זה עבור Pyaterochka אתה צריך יישום אחד עם מפה, עבור Lenta אחר, עבור MTS שלישי, וכן הלאה עבור כולם, כולם, כולם). מספיק מברק אחד. באמצעות טלגרם תוכלו לקבל התראות מיד, לבדוק את מצב הפרויקט ולתת פקודה לבדוק מחדש את כל האינדיקטורים הבעייתיים. יצאנו מהתיאטרון/מטוס, לא היינו עם האצבע על הדופק במשך שעתיים, הדלקנו את הטלפון, לחצנו על כפתור אחד בצ'אט בוט, וידאנו שהכל בסדר.

דפי סטטוס

כיום, דפי סטטוס הם כמעט חובה לכל עסק שיש לו IT, גישה אחראית לאמינות ומתייחס ללקוחות/משתמשים שלו בכבוד.

תארו לעצמכם מצב - משתמש רוצה לעשות משהו, לראות מידע או לבצע הזמנה, ומשהו לא עובד. הוא לא יודע מה קורה, מהצד של מי הבעיה ומתי היא תיפתר. אולי לחברה שלך פשוט יש אתר אינטרנט לא מתפקד? או שזה נשבר לפני חצי שנה וזה יתוקן בעוד שנתיים? אבל צריך לקנות עכשיו מקרר, זה כבר בעגלה... וזה כבר עניין אחר כשאדם רואה שמשהו אצלך לא בסדר (לפחות ברור שהבעיה לא בצד שלו), שה התגלתה בעיה, שאתה כבר עובד עליה, ואולי אפילו רשמת את הזמן המשוער לתיקון. המשתמש יכול להירשם ולקבל הודעה במייל כשהבעיה נפתרה והוא יכול לעשות מה שהוא רוצה (לקנות מקרר).

בעיות וזמני השבתה קורות לכולם. אבל משתמשים ושותפים סומכים יותר על אלה שהם שקופים ואחראים יותר בגישתם לכך.

כאן סקירה של 10 פרויקטים אחרים המאפשרים לך ליצור דפי סטטוס. להלן דוגמאות כיצד נראים דפי הפרויקט הללו פיתון и Dropbox. דף סטטוס okerr.

Failover

כדי לא להאריך עוד יותר את המאמר, אתייחס שוב למאמר הקודם שלי - כשל פשוט לאתר . אם אתה יכול ליצור שרת כפול, אז באמצעות failover, בעצם לא תהיה לך זמן השבתה ארוך - ברגע שמתגלה בעיה, המשתמשים יופנו אוטומטית לשרת גיבוי עובד. ונראה לי שמדובר בתכונה מאוד מעניינת ומוארת, שרק לעתים נדירות זמינה בשום מקום.

דרישות מערכת נמוכות

עבור שרתי okerr, אנו משתמשים במכונות עם זיכרון RAM מ-2Gb. עבור חיישני רשת, אפילו 512Mb מספיקים. חלק הלקוח הוא בדרך כלל כמעט אפס. (שקית פלסטיק תקציר שוקל 26 Kb, אך דורש Python3 וספריות סטנדרטיות). הלקוח פועל מסקריפט cron, כך שיש לו אפס צריכת זיכרון מתמשכת. בין המכונות שעליהן ניטרנו, יש לנו חיישנים (VPS סופר זול עם 512Mb RAM) ו-Raspberry Pi. זה אפשרי גם בלי חלק הלקוח שלח עדכונים באמצעות curl! (ראה למטה)

אם לוקחים את זה בחשבון - אוקיי, כנראה הכי בחינם מערכת ניטור מהזמינות, כי אפילו כדי להשתמש במערכת קוד פתוח חינמית אחרת כמו Zabbix או Nagios, צריך להקצות לה משאבים (שרת), וזה כבר כסף. בנוסף, עדיין נדרשת תחזוקה מסוימת של השרת. עם okerr, ניתן להסיר את החלק הזה. או שאתה לא צריך להסיר אותו ולהשתמש בשרת משלך, תלוי מה אתה הכי אוהב.

API ושילוב בתוכנה קניינית

ארכיטקטורה פשוטה ופתוחה. ל-okerr יש אחד די פשוט API, שקל לעבוד איתו. צריך ליצור 1000 אינדיקטורים? סקריפט מעטפת אחד של 3-4 שורות יעשה זאת. צריך להגדיר מחדש 1000 מחוונים? זה גם מאוד קל. לדוגמה, אנו רוצים לבדוק שוב את כל אישורי ה-HTTPS שלנו מחישן רוסי:

#!/bin/sh

for indicator in `okerrclient --api-filter sslcert`
do
    echo set location for $indicator
    okerrclient --api-set location=ru retest=1 --name $indicator
done

אתה יכול לעדכן את המחוון באמצעות מודול הלקוח שלנו, גם בלעדיו, רק באמצעות סלסול.

# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK

# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/

אתה יכול לעדכן אינדיקטורים ישירות מהתוכנית שלך. למשל, שליחת אותות דופק כדי ש-okerr יודע שהוא פועל ומפעיל אזעקה אם הוא קורס או קופא. אגב, רכיבי okerr עושים בדיוק את זה - okerr מנטר את עצמו, ובעיות כמעט בכל מודול יתגלו וייצרו התראה על הבעיה. (ובמקרה של זה "כמעט" - הם מוצלבים משרת אחר)

הנה הקוד (בפשטות) בבוט הטלגרם שלנו:

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

יש ספריה לעדכון אינדיקטורים מתוכניות Python תקציר, עבור כל שפות אחרות אין ספריות, אבל אתה יכול להתקשר לסקריפט okerrupdate או לשלוח בקשת HTTP לשרת okerr.

איך אוקר עוזר לנו

אוקר שינה את חיינו. אכן. אולי מערכת ניטור אחרת יכולה לעשות את אותו הדבר, אבל העבודה עם okerr היא קלה ופשוטה עבורנו ויש לה את כל הפונקציות שהיינו צריכים (הוספנו את מה שלא היה לה). אגב, אם חסרים כמה פיצ'רים, שאל ואני אוסיף אותם (אני לא מבטיח, אבל אני רוצה ש-okerr תהיה מערכת הניטור הטובה ביותר עבור פרויקטים קטנים-בינוניים). או יותר טוב, הוסף את זה בעצמך - זה קל.

הצלחנו לחיות לפי העיקרון "למד על כל הבעיות מהקרה". אם פתאום מתרחשת בעיה שלא למדנו עליה מ- okerr, נוסיף צ'ק ל- okerr. (במקרה הזה, ב"אנחנו" אני מתכוון אלינו כמשתמשי המערכת, לא כמפתחים משותפים). בהתחלה זה היה נפוץ, אבל עכשיו זה הפך נדיר מאוד.

ניטור

דרך okerr אנו עוקבים אחר גדלי היומן בכל השרתים. כמובן שאי אפשר לקרוא במחשבה כל שורה ביומן בעיניים, אבל מעקב אחר קצב הצמיחה כבר נותן הרבה. באמצעות זה, זיהינו דיוור דואר זבל וניחוש סיסמאות בכוח גס, וכאשר חלק מהיישומים "משגעים", משהו לא מסתדר להם והם חוזרים על זה שוב ושוב (בכל פעם מוסיפים כמה שורות ליומן ).

תעודות SSL. כמעט מיד לאחר ההשקה LetsEncrypt הלקוח שלנו החל לספק אישורי SSL בחינם ללקוחותיו (כאלף מהם). והתברר שזה פשוט גיהנום לניהול! העובדה היא שאתרים הם "חיים", לקוחות מבקשים מהם מדי פעם לעשות משהו, מתכנתים עושים זאת. הם יכולים להעביר את האתר באופן חופשי לחלוטין ל-DocumentRoot אחר, למשל. או הוסף שכתוב ללא תנאי לתצורת ה-virtualhost. מטבע הדברים, לאחר מכן, מתקלקל החידוש האוטומטי של התעודות. עכשיו יש לנו את כל מארחי ה-SSL שנוספו ל-okerr באופן אוטומטי דרך אחר מכלי השירות השימושיים שלנו מהחבילה a2conf. בואו פשוט נשיק a2okerr.py - ואם יופיעו כמה אתרים חדשים בשרת, הם יופיעו אוטומטית ב- okerr. אם פתאום מסיבה כלשהי התעודה לא תתחדש, שלושה שבועות לפני תום התעודה, אנחנו בידע, ונבין למה זה לא מתעדכן, כלב כזה. a2certbot.py מאותה חבילה - זה עוזר מאוד עם זה (הוא בודק מיד את הבעיות הכי סבירות - וכותב מה נבדק טוב, והיכן סביר להניח שיש בעיה).

אנו עוקבים אחר תאריך התפוגה של כל הדומיינים שלנו. וכל שרתי הדואר שלנו ששולחים דואר נבדקים גם מול 50+ רשימות שחורות שונות. (ולפעמים הם נופלים לתוכם). אגב, האם ידעת שגם שרתי הדואר של גוגל נמצאים ברשימה השחורה? רק לבדיקה עצמית, הוספנו mail-wr1-f54.google.com לשרתים המנוטרים, והוא עדיין ברשימה השחורה של SORBS! (זה בערך הערך של "אנטי ספאמרים")

גיבויים - כבר כתבתי למעלה כמה קל לנטר אותם עם okerr. אבל אנחנו עוקבים גם אחר הגיבויים האחרונים בשרת שלנו וגם (באמצעות כלי עזר נפרד שמשתמש ב-okerr) הגיבויים שאנחנו מעלים לאמזון קרחון. וכן, בעיות קורות מעת לעת. לא פלא שהם צפו.

אנו משתמשים במחוון ההסלמה. זה מראה אם ​​בעיה כלשהי לא תוקנה במשך זמן רב. ואני עצמי, כשאני פותר כמה בעיות, לפעמים אני יכול לשכוח מהן. הסלמה היא תזכורת טובה, גם אם אתה עוקב אחר עצמך.

בסך הכל, אני מאמין שאיכות העבודה שלנו עלתה בסדר גודל. אין כמעט זמן השבתה (או ללקוח אין זמן להבחין בכך. פשוט ששש!), בעוד שכמות העבודה הצטמצמה ותנאי העבודה נעשו רגועים יותר. עברנו מעבודות חירום עם תיקון חורים עם סרט לעבודה רגועה ומדודה, כאשר בעיות רבות נחזות מראש ויש זמן למנוע אותן. אפילו בעיות שקרו גם הפכו קלות יותר לתיקון: ראשית, אנחנו מגלים אותן לפני שהלקוחות נכנסים לפאניקה, ושנית, קורה לעתים קרובות שהבעיה קשורה לעבודה האחרונה (בזמן שעשיתי דבר אחד, שברתי דבר אחר) - אז זה חם קל יותר לעקבות להתמודד עם זה.

אבל היה מקרה אחר...

האם ידעת שב-Debian 9 הפופולרי (Stretch) חבילה כה פופולרית כמו phpmyadmin נמצאת עדיין (למשך חודשים רבים!) במצב פגיע? (CVE-2019-6798). כשהפגיעות צצה, כיסינו אותה במהירות בדרכים שונות. אבל הגדרתי ניטור של דף המעקב אחר האבטחה ב- okerr כדי לדעת מתי ייצא פתרון "יפה" (דרך סכום SHA1 של התוכן). המחוון ריגש אותי מספר פעמים, הדף השתנה, אבל כפי שאתה יכול לראות, זה עדיין (מאז ינואר 2019!) לא מעיד על פתרון הבעיה. אולי, אגב, מישהו יודע מה הבעיה שחבילה כל כך חשובה עדיין פגיעה יותר משנה?

פעם נוספת במצב דומה: לאחר פגיעות ב-SSH, היה צורך לעדכן את כל השרתים. וכאשר אתה מגדיר משימה, אתה צריך לשלוט בביצוע. (כפופים נוטים לטעות, לשכוח, להתבלבל ולעשות טעויות). לכן, תחילה הוספנו בדיקת גרסת SSH ל-okerr בכל השרתים, ובאמצעות okerr דאגנו שהעדכונים יצאו בכל השרתים. (נוח! בחרתי באינדיקטור מסוג זה, ומיד ניתן לראות לאיזה שרת יש איזו גרסה). כשהיינו בטוחים שהמשימה הושלמה בכל השרתים, הסרנו את האינדיקטורים.

כמה פעמים היה מצב שמתעוררת בעיה מסוימת, ואז חולפת מעצמה. (כנראה מוכר לכולם?). עד שתשימו לב, עד שתבדקו - ואין מה לבדוק - הכל כבר עובד טוב. אבל אז זה שוב נשבר. זה קרה לנו, למשל, עם מוצרים שהעלינו לאמזון מרקטפלייס (MWS). בשלב מסוים, המלאי שנטען לא היה נכון (כמויות שגויות של סחורה ומחירים שגויים). הבנו את זה. אבל כדי להבין את זה, היה חשוב לברר את הבעיה מיד. למרבה הצער, MWS, כמו כל שירותי אמזון, קצת איטי, אז תמיד היה פיגור, אבל בכל זאת, הצלחנו לפחות להבין בערך את הקשר בין הבעיה לסקריפטים שגורמים לה (עשינו בדיקה, נתקענו זה לאוקר, ובדק אותו מיד מקבל התראה).

לאחרונה התווסף לאוסף מארז מעניין מארח אירופי גדול ויקר, בו משתמש הלקוח שלנו. פתאום כל השרתים שלנו נעלמו מהרדאר! ראשית, הלקוח עצמו (מהיר יותר מאשר אוקרה!) שם לב שהאתר איתו עבד לא נפתח ועשה על כך כרטיס. אבל לא רק אתר אחד ירד, אלא כולם! (נטשה, הורדנו הכל!). כאן אוקר התחיל לשלוח עטיפות רגל ארוכות עם כל האינדיקטורים שנדלקו לו. פאניקה, פאניקה, אנחנו רצים במעגלים (מה עוד אפשר לעשות?). ואז הכל עלה. מסתבר שהייתה תחזוקה שוטפת במרכז הנתונים (אחת להרבה שנים) וכמובן שהיה צריך להזהיר אותנו. אבל קרתה להם איזושהי בעיה והם לא הזהירו אותנו. ובכן, יותר התקפי לב, פחות התקפי לב. אבל אחרי שהכל משוחזר, אתה צריך לבדוק הכל! אני לא יכול לדמיין איך הייתי עושה את זה עם הידיים שלי. Okerr בדק הכל תוך כמה דקות. התברר שרוב השרתים פשוט לא היו זמינים זמנית, אבל הם עבדו. חלקם היו עמוסים יתר על המידה, אבל גם עמדו כמו שצריך. מכל ההפסדים, איבדנו שני גיבויים, שלפי הכתר היו צריכים להיווצר ולהיטען בזמן שהבננה המלאה הזו מתנהלת. אפילו לא טרחתי ליצור אותם, רק יום לאחר מכן הגיעו התראות שהכל בסדר, הופיעו גיבויים. אני מאוד אוהב את הדוגמה הזו כי okerr התגלה כמועיל מאוד במצב שאפילו לא חשבנו עליו מראש, אבל זו מטרת הניטור - להתנגד לבלתי צפוי.

עבור חיישני Okerr, אנו משתמשים באירוח הזול ביותר האפשרי (כאשר האיכות והאמינות אינן חשובות, הן מבטחות זו את זו). אז לאחרונה מצאנו אירוח טוב מאוד וסופר זול, המדדים מדהימים. אבל... לפעמים מתברר שחיבורים יוצאים מהמכונה הוירטואלית נעשים מ-IP אחר (שכן). ניסים. מודול Client_ip עם https://diagnostic.opendns.com/myip מקבל את ה-IP הלא נכון. ומיומני השרת של המחוון ברור שהעדכון הגיע גם מה-IP השכן הזה. בוא נתמודד עם התמיכה עכשיו. טוב ששמנו לב לזה בימי שלום. אבל, למשל, קורה לא פעם שהגישה רשומה לפי רשימת הלבנים של ה-IP - ואם השרת לפעמים מהבהב ככה לזמן קצר - אפשר לנסות לתפוס את הבעיה הזו במשך זמן רב מאוד.

ובכן, עוד דבר - מכיוון שאנו מדברים על אירוח VPS - אנו תמיד משתמשים באלה זולים (הצנר, ovh, scaleway). אני מאוד אוהב את זה גם מבחינת אמות מידה וגם מבחינת יציבות. אנו משתמשים גם ב-Amazon EC2 היקר הרבה יותר עבור פרויקטים אחרים. אז, בזכות okerr, יש לנו דעה מושכלת משלנו. שניהם נופלים. ולא הייתי אומר שבמשך התקופה הארוכה של התצפיות שלנו, אירוח זול כמו hetzner התברר כפחות יציב באופן ניכר מ-EC2. לכן, אם אתה לא קשור לתכונות אחרות של אמזון, למה לשלם יותר? 🙂

מה הלאה?

אם בשלב זה עדיין לא הפחדתי אותך מאוקר, אז נסה זאת! אתה יכול להיכנס ישירות לקישור הזה חשבון הדגמה של okerr (לחץ עכשיו!) אבל זכור שיש רק חשבון הדגמה אחד לכולם, כך שאם תעשה משהו, מישהו אחר באותו חשבון עלול להפריע לך באותו הזמן. או (עדיף) להירשם דרך הקישור אל offsite okerr - הכל פשוט, ללא SMS. אם אתה לא אוהב להשתמש באימייל האמיתי שלך, אתה יכול להשתמש במייל חד פעמי, כמו mailinator (אני ממליץ getnada.com). חשבונות כאלה עשויים להימחק עם הזמן, אבל הם יהיו בסדר לבדיקה.

לאחר ההרשמה תתבקשו לעבור הכשרה (ביצוע מספר משימות הדרכה לא קשות במיוחד). המגבלות הראשוניות קטנות מאוד, אבל להדרכה או שרת אחד הן מספיקות. לאחר סיום ההכשרה יוגדלו המגבלות (למשל, מספר האינדיקטורים המרבי).

מהתיעוד - קודם כל WIKI בצד השרת ובלקוח (okerrupdate wiki). אבל אם משהו לא ברור, כתבו ל-support (בכתובת) okerr.com או השאירו כרטיס - ננסה לפתור הכל במהירות.

אם אתה משתמש בו ברצינות והמגבלות המוגברות הללו אינן מספיקות, כתוב לתמיכה ונגדיל אותה (בחינם).

האם תרצה להתקין את שרת okerr בשרת שלך? כאן מאגר okerr-dev. אנו ממליצים להתקין על מחשב וירטואלי נקי, ואז אתה יכול פשוט לעשות את זה עם סקריפט התקנה. במכונה הוירטואלית שלך - ללא הגבלות :-). ובכן, שוב, אם משהו יקרה, תמיד ננסה לעזור.

אנחנו רוצים שהפרויקט הזה ימריא, כדי שהעולם יהפוך לאמין יותר בזכותנו. הודות לתוכנות ושירותים חינמיים, העולם נעשה ידידותי יותר ומתפתח בצורה דינמית יותר. ניתן לאחסן את המקורות ב-github החינמי, ולמייל ניתן להשתמש ב-gmail החינמי. אנחנו משתמשים בחינם עבודות טרי לתמיכה. עבור כל זה, אתה לא צריך לשלם עבור שרתים, אתה לא צריך להוריד ולהגדיר, ואתה לא צריך לפתור בעיות תפעוליות שונות. לכל פרויקט חדש, לכל צוות יש מיד דואר, מאגרים ו-CRM. וכל זה מאוד איכותי וחינמי ומיד. אנחנו רוצים שזה יהיה אותו הדבר לגבי ניטור - חברות קטנות ופרויקטים יכולים להשתמש ב- okerr בחינם ואפילו בשלב הלידה והצמיחה יש את האמינות של פרויקטים רציניים למבוגרים.

מקור: www.habr.com