פתרון בעיות בסוכנים מרוחקים
במסמך הזה ריכזנו טיפים ונהלים שיעזרו לכם לאבחן ולפתור בעיות נפוצות שמתרחשות במהלך הפריסה והתפעול של Google Security Operations Remote Agent.
בעיה של חוסר התאמה בין מפתחות
הבעיה הזו מתרחשת כשהמפתחות הפרטיים ב-Google Security Operations ובסוכן המרוחק לא תואמים. כדי לפתור את הבעיה, מוודאים שהמפתח במשאבי הסוכן תואם למפתח ב-Siemplify agent_db.
כשל במחבר מרוחק
אם מחבר מרוחק נכשל, פועלים לפי השלבים הבאים:
- מוודאים שמופע של שילוב הותקן בהצלחה בסוכן.
- בודקים את יומני הסוכן ברמת השגיאה כדי למצוא כשלים בתהליך החיבור.
- בודקים את אותה הגדרת מחבר באופן מקומי כדי לראות אם יש שגיאות.
פריסת סוכן Docker נכשלה
אם הפריסה של Docker נכשלת, צריך לפעול לפי השלבים הבאים:
- מסירים את קונטיינר Docker:
מריצים את הפקודה הבאה כדי להציג את רשימת הקונטיינרים הפועלים:
docker psמריצים את הפקודה הבאה כדי להסיר את הקונטיינרים שנכשלו:
docker rm -f container_id_or_name
- הסרת תמונות:
מריצים את הפקודה הבאה כדי להציג את רשימת התמונות:
docker imagesמריצים את הפקודה הבאה כדי להסיר את התמונה:
docker rmi image_id_or_name
- הסרת אמצעי אחסון:
מריצים את הפקודה הבאה כדי להציג את עוצמות הקול:
docker volume lsמריצים את הפקודה הבאה כדי להסיר את אמצעי האחסון:
docker volume rm volume_name
- פורסים מחדש את הסוכן. מידע נוסף זמין במאמר בנושא יצירת סוכן באמצעות Docker.
הסוכן תקוע בסטטוס 'בהמתנה לנציג'
אם הסוכן נפרס בהצלחה אבל הסטטוס שלו נשאר 'בהמתנה לסוכן', צריך לפעול לפי השלבים הבאים כדי לפתור את הבעיה:
- בודקים את הקישוריות של המארח: בודקים את הקישוריות של מכונת המארח של הסוכן לאינטרנט (לדוגמה,
curl www.google.comאוping 8.8.8.8). אם הבדיקה נכשלת, הבעיה היא בחיבור לאינטרנט של המארח. בדיקת הקישוריות של הקונטיינר: אם הבדיקה של המארח עוברת, מזינים את מעטפת הקונטיינר באמצעות
docker exec -it container_ID bashובודקים מחדש את הקישוריות. אם אין קישוריות לקונטיינר, מפעילים מחדש את שירות Docker במחשב המארח (service docker restart).מריצים את הפקודה הבאה:
docker exec -itbash - בודקים שוב את החיבור כמו שעשיתם קודם.
- אם אין קישוריות, מריצים את הפקודה הבאה כדי להפעיל מחדש את שירות Docker ממחשב המארח (לא מהקונטיינר):
service docker restart מריצים את הפקודה הבאה כדי להפעיל מחדש את הקונטיינר:
docker start
בדיקת יומני מאגרי תגים לאיתור שגיאות
אם השלב הקודם לא עזר, והסטטוס של הסוכן הוא עדיין 'בהמתנה לסוכן' אחרי רענון הדף Remote agent ב-Google SecOps, צריך להתחבר מחדש לקונטיינר ולשלוף את היומנים.
- מחפשים את היומנים בספרייה
/var/log/SiemplifyAgent/. - מחפשים שגיאות בקובצי היומן כדי לזהות את הסיבה הבסיסית.
- מחפשים את היומנים בספרייה
טעינת קובץ אימג' של Docker נכשלת (העברת נתונים ב-IP4 מושבתת)
אם מוצגת שגיאה ב-CLI כשמנסים לטעון קובץ אימג' של Docker (מערכת) או סוכן של Google SecOps, יכול להיות שהעברת IP4 מושבתת. כדי להפעיל את התכונה הזו ולהפעיל מחדש את הסוכן:
מוסיפים את השורה הבאה לקובץ
/etc/sysctl.conf:net.ipv4.ip_forward=1שימו לב שתצטרכו להשתמש בכלי לעריכת קבצים (לדוגמה, nano). כך משתמשים בו:yum install nano -yמריצים את הפקודה הבאה כדי להפעיל מחדש את שירות הרשת:
systemctl restart networkמריצים את הפקודה הבאה כדי להפעיל מחדש את שירות Docker:
sudo systemctl restart dockerמריצים את הפקודה הבאה כדי לבדוק אם הקונטיינר פועל:
docker psאם מאגר התגים לא פועל, מריצים את הפקודה הבאה כדי להציג רשימה של כל מאגרי התגים (כולל אלה שהופסקו):
docker ps -aאם הקונטיינר מופיע ברשימה אבל הוא במצב עצירה, מריצים את הפקודה הבאה כדי להפעיל אותו:
docker start container_id_or_name- אם הסוכן או המערכת עדיין לא פועלים אחרי הפעלה מחדש של Docker והקונטיינר:
מריצים את הפקודה הבאה כדי לעצור את הקונטיינר:
docker stop container_id_or_nameמריצים את הפקודה הבאה כדי למחוק את מאגר התגים:
docker rm container_id_or_nameמריצים את הפקודה הבאה כדי למחוק את התמונה:
docker rmi image_name- טוענים את התמונה שוב.
שגיאה אחרי כיבוי או אתחול מחדש של הסוכן
מריצים את הפקודה הבאה כדי להפעיל בכוח את סוכן ההתקנה:
systemctl start supervisord
מריצים את הפקודה הבאה כדי להפעיל בכוח את סוכן Docker:
docker start
השדרוג של הסוכן המרוחק לא הצליח
אם שדרוג קודם הופעל אבל לא הושלם בהצלחה, והגרסה של הסוכן המרוחק לא השתנתה, צריך לחכות 15 דקות ולרענן את הדף סוכן מרוחק ב-Google Security Operations. אחר כך אפשר להפעיל מחדש את השדרוג.
הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.