פירוש הסטטוס וקודי היציאה של מוניטור פרוקסי
דווחו בנפרד על הרצת הפקודה, תוצאת HTTP ואימות התעודה בבדיקת אתר דרך פרוקסי.
עטיפה אינה יכולה להפוך קוד יציאה אפס של המוריד ל„HTTP 200 OK” שנצפה. רשמו מה כל שכבה דיווחה בפועל:
| שדה | השאלה שנענית |
|---|---|
| יציאת הכלי או התוסף | האם הבדיקה רצה, ואיזו מחלקת כשל דווחה? |
| משא ומתן הפרוקסי | האם ההעברה או המנהרה המבוקשת אושרו? |
| סטטוס המקור והתוכן הצפוי | האם היישום החזיר את התוצאה המיועדת? |
| אימות TLS | האם בדיקות הזהות שהוגדרו הצליחו? |
curl יכול בדרך כלל להחזיר אפס לאחר תגובת שגיאת HTTP. אפשרויות ה-fail שלו משנות את התנהגות היציאה, אך יציאת כשל עדיין אינה מזהה את הסטטוס באופן ייחודי. גם ערכי היציאה של Wget הם קטגוריות: כשל אימות אינו ערך ייעודי ל-HTTP 401, וקטגוריית שגיאת שרת אינה מזהה כל תגובה שבתוכה. בדיקה שמצפה ל-401 חייבת לצפות בתגובה הזו.
הפרידו בין נקודת הקצה של הפרוקסי לבין שם האתר. עמית ה-TCP של בדיקת פרוקסי HTTP הוא הפרוקסי; CONNECT נוקב ביעד, שסשן ה-TLS שלו רץ לאחר מכן בתוך המנהרה. בפרוקסי HTTPS, האמון בפרוקסי החיצוני הוא בדיקת תעודה נוספת.
בחנו את האחריות של התוסף לפני שאתם מתייחסים לדגל SSL כאימות. Monitoring Plugins מפסיק את התמיכה ב-check_http לטובת check_curl. התיעוד של check_http מזהיר שבחירת SSL בלבד אינה מאמתת את שם המארח או את אמון המנפיק; אפשרות ה-verify-peer המתועדת של check_curl כוללת אימות זה.
השתמשו גם במסלול המאומת המיועד. בדיקת פורט יכולה להישאר ירוקה בעוד החשבון התפעולי מקבל 407. מסרו את הסוד שלו במנגנון המתאים של הפריסה, ודווחו על השלב שנכשל בפועל: מנהרה שנדחתה דורשת תיקון שונה מסטטוס אתר בלתי צפוי.