השילוב עם nginx אוסף מדדי חיבור ויומני גישה. מדדי החיבור מתעדים את המצב הנוכחי של החיבור: פעיל, קריאה או המתנה. יומני הגישה מנותחים כדי לחלץ מהם את פרטי החיבור, כולל שדות שממופים לבקשה, ללקוח, לשרת ולהודעה.
מידע נוסף על nginx זמין במסמכי התיעוד של nginx.
דרישות מוקדמות
כדי לאסוף נתוני טלמטריה של nginx, צריך להתקין את סוכן התפעול:
- למדדים, צריך להתקין גרסה 2.1.0 ומעלה.
- כדי לראות את היומנים, צריך להתקין גרסה 2.1.0 ומעלה.
השילוב הזה תומך בגרסאות 1.18 ו-1.20 של nginx.
הגדרת מופע nginx
כדי להגדיר כתובת URL שאפשר לגשת אליה באופן מקומי, למשל http://www.example.com/nginx_status לדף הסטטוס, צריך להפעיל את המודול stub_status בקובץ התצורה של nginx. כדי להפעיל את המודול stub_status:
עורכים את הקובץ
status.confאו יוצרים אותו אם הוא לא קיים. אפשר למצוא את הקובץ הזה בספריית ההגדרות של nginx, שבדרך כלל נמצאת במיקום/etc/nginx/conf.d.מוסיפים את השורות הבאות לקטע
server:location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; }קובץ התצורה שלך עשוי להיראות כמו בדוגמה הבאה:
server { listen 80; server_name 127.0.0.1; location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } location / { root /dev/null; } }טוענים מחדש את ההגדרה של nginx.
sudo service nginx reload
כדי להפוך את השלבים הקודמים לאוטומטיים, מריצים את הפקודה הבאה. הוא יוצר קובץ status.conf אם הוא לא קיים, או מחליף את הקובץ הקיים אם הוא כן קיים. הפקודה מפעילה את stub_status, טוענת מחדש את nginx ומוודאת שהמידע הצפוי נחשף דרך נקודת הקצה.
sudo tee /etc/nginx/conf.d/status.conf > /dev/null << EOF
server {
listen 80;
server_name 127.0.0.1;
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
location / {
root /dev/null;
}
}
EOF
sudo service nginx reload
curl http://127.0.0.1:80/nginx_status
פלט לדוגמה:
Active connections: 1 server accepts handled requests 23 23 74 Reading: 0 Writing: 1 Waiting: 0
לחלופין, במקום להשתמש בקובץ status.conf נפרד, אפשר גם להטמיע את השורות ישירות בקובץ nginx.conf הראשי, שבדרך כלל נמצא באחת מהספריות הבאות: /etc/nginx, /usr/local/nginx/conf או /usr/local/etc/nginx.
הגדרת סוכן התפעול ל-nginx
פועלים לפי המדריך בנושא הגדרת Ops Agent, מוסיפים את הרכיבים הנדרשים לאיסוף טלמטריה ממופעי nginx ומפעילים מחדש את הסוכן.
הגדרה לדוגמה
הפקודות הבאות יוצרות את ההגדרה לאיסוף ולעיבוד של נתוני טלמטריה עבור nginx:
כדי שהשינויים האלה ייכנסו לתוקף, צריך להפעיל מחדש את Ops Agent:
Linux
- כדי להפעיל מחדש את הסוכן, מריצים את הפקודה הבאה במופע:
sudo systemctl restart google-cloud-ops-agent
- כדי לוודא שהסוכן הופעל מחדש, מריצים את הפקודה הבאה ומוודאים שהרכיבים Metrics Agent ו-Logging Agent הופעלו:
sudo systemctl status "google-cloud-ops-agent*"
Windows
- מתחברים למופע באמצעות RDP או כלי דומה ומתחברים ל-Windows.
- פותחים טרמינל ב-PowerShell עם הרשאות אדמין על ידי לחיצה ימנית על סמל PowerShell ובחירה באפשרות הפעלה כמנהל מערכת.
- כדי להפעיל מחדש את הסוכן, מריצים את פקודת PowerShell הבאה:
Restart-Service google-cloud-ops-agent -Force
- כדי לוודא שהסוכן הופעל מחדש, מריצים את הפקודה הבאה ומוודאים שהרכיבים Metrics Agent ו-Logging Agent הופעלו:
Get-Service google-cloud-ops-agent*
הגדרת איסוף יומנים
כדי להטמיע יומנים מ-nginx, צריך ליצור מקלט ליומנים ש-nginx מייצר, ואז ליצור צינור למקלט החדש.
כדי להגדיר מקלט ליומני nginx_access, מציינים את השדות הבאים:
| שדה | ברירת מחדל | תיאור |
|---|---|---|
exclude_paths |
רשימה של תבניות של נתיבים במערכת הקבצים שצריך להחריג מהקבוצה שתואמת ל-include_paths. |
|
include_paths |
[/var/log/nginx/access.log] |
רשימה של נתיבי מערכת קבצים לקריאה על ידי מעקב אחרי כל קובץ. אפשר להשתמש בתו כללי לחיפוש (*) בנתיבים. |
record_log_file_path |
false |
אם הערך הוא true, הנתיב לקובץ הספציפי שממנו נרשם רשומת היומן מופיע ברשומת היומן של הפלט כערך של התווית agent.googleapis.com/log_file_path. כשמשתמשים בתו כללי, מתועד רק הנתיב של הקובץ שממנו התקבל הרשומה. |
type |
הערך חייב להיות nginx_access. |
|
wildcard_refresh_interval |
60s |
המרווח שבו נתיבי קבצים עם תו כללי ב-include_paths מתרעננים. הערך הוא משך זמן, לדוגמה 30s או 2m. הנכס הזה יכול להיות שימושי כשקצב העברת הנתונים של הרישום ביומן גבוה, והקבצים ביומן מתחלפים מהר יותר מהמרווח שמוגדר כברירת מחדל. |
כדי להגדיר מקלט ליומני nginx_error, מציינים את השדות הבאים:
| שדה | ברירת מחדל | תיאור |
|---|---|---|
exclude_paths |
רשימה של תבניות של נתיבים במערכת הקבצים שצריך להחריג מהקבוצה שתואמת ל-include_paths. |
|
include_paths |
[/var/log/nginx/error.log] |
רשימה של נתיבי מערכת קבצים לקריאה על ידי מעקב אחרי כל קובץ. אפשר להשתמש בתו כללי לחיפוש (*) בנתיבים. |
record_log_file_path |
false |
אם הערך הוא true, הנתיב לקובץ הספציפי שממנו נרשם רשומת היומן מופיע ברשומת היומן של הפלט כערך של התווית agent.googleapis.com/log_file_path. כשמשתמשים בתו כללי, מתועד רק הנתיב של הקובץ שממנו התקבל הרשומה. |
type |
הערך חייב להיות nginx_error. |
|
wildcard_refresh_interval |
60s |
המרווח שבו נתיבי קבצים עם תו כללי ב-include_paths מתרעננים. הערך הוא משך זמן, לדוגמה 30s או 2m. הנכס הזה יכול להיות שימושי כשקצב העברת הנתונים של הרישום ביומן גבוה, והקבצים ביומן מתחלפים מהר יותר מהמרווח שמוגדר כברירת מחדל. |
מה נרשם ביומן
הערך של logName נגזר ממזהי המקלט שצוינו בהגדרה. אלה השדות המפורטים בתוך LogEntry:
יומני nginx_access מכילים את השדות הבאים ב-LogEntry:
| שדה | סוג | תיאור |
|---|---|---|
httpRequest |
אובייקט | ראה HttpRequest |
jsonPayload.host |
מחרוזת | התוכן של כותרת המארח (בדרך כלל לא מדווח על ידי nginx) |
jsonPayload.level |
מחרוזת | רמת רשומת היומן |
jsonPayload.user |
מחרוזת | שם המשתמש המאומת של הבקשה |
severity |
מחרוזת (LogSeverity) |
רמת רשומת היומן (מתורגמת). |
יומני nginx_error מכילים את השדות הבאים ב-LogEntry:
| שדה | סוג | תיאור |
|---|---|---|
jsonPayload.client |
מחרוזת | כתובת ה-IP של הלקוח (אופציונלי) |
jsonPayload.connection |
מספר | מזהה החיבור |
jsonPayload.host |
מחרוזת | כותרת מארח (אופציונלי) |
jsonPayload.level |
מחרוזת | רמת רשומת היומן |
jsonPayload.message |
מחרוזת | הודעה ביומן |
jsonPayload.pid |
מספר | מזהה התהליך שיוצר את היומן |
jsonPayload.referer |
מחרוזת | כותרת Referer (אופציונלי) |
jsonPayload.request |
מחרוזת | בקשת HTTP מקורית (אופציונלי) |
jsonPayload.server |
מחרוזת | שם שרת Nginx (אופציונלי) |
jsonPayload.subrequest |
מחרוזת | בקשת משנה של Nginx (אופציונלי) |
jsonPayload.tid |
מספר | מזהה השרשור שממנו נוצר היומן |
jsonPayload.upstream |
מחרוזת | URI של בקשה במעלה הזרם (אופציונלי) |
severity |
מחרוזת (LogSeverity) |
רמת רשומת היומן (מתורגמת). |
הגדרת איסוף מדדים
כדי להטמיע מדדים מ-nginx, צריך ליצור מקלט למדדים ש-nginx מייצר, ואז ליצור צינור למקלט החדש.
המקלט הזה לא תומך בשימוש בכמה מופעים בהגדרה, למשל כדי לעקוב אחרי כמה נקודות קצה. כל המקרים האלה כותבים לאותה סדרת זמן, ואין ל-Cloud Monitoring דרך להבחין ביניהם.
כדי להגדיר נמען למדדים של nginx, צריך לציין את השדות הבאים:
| שדה | ברירת מחדל | תיאור |
|---|---|---|
collection_interval |
60s |
ערך של משך זמן, כמו 30s או 5m. |
server_status_url |
http://localhost/status |
כתובת ה-URL שנחשפת על ידי מודול הסטטוס של nginx stub. |
type |
הערך חייב להיות nginx. |
מה נבדק
בטבלה הבאה מפורטים המדדים שסוכן התפעול אוסף ממופע nginx.
| סוג המדד | |
|---|---|
| סוג, סוג משאבים במעקב |
תוויות |
workload.googleapis.com/nginx.connections_accepted
|
|
CUMULATIVE, INT64gce_instance |
|
workload.googleapis.com/nginx.connections_current
|
|
GAUGE, INT64gce_instance |
state
|
workload.googleapis.com/nginx.connections_handled
|
|
CUMULATIVE, INT64gce_instance |
|
workload.googleapis.com/nginx.requests
|
|
CUMULATIVE, INT64gce_instance |
|
אימות ההגדרה
בקטע הזה מוסבר איך לוודא שהגדרתם נכון את מקלט nginx. יכול להיות שיעברו דקה או שתיים עד שהסוכן של Ops יתחיל לאסוף נתוני טלמטריה.
כדי לוודא שיומני nginx נשלחים אל Cloud Logging, מבצעים את הפעולות הבאות:
-
במסוף Google Cloud , נכנסים לדף Logs Explorer:
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Logging.
- מזינים את השאילתה הבאה בעורך ולוחצים על Run query:
resource.type="gce_instance" (log_id("nginx_access") OR log_id("nginx_error"))
כדי לוודא שמדדי nginx נשלחים אל Cloud Monitoring, מבצעים את הפעולות הבאות:
-
במסוף Google Cloud , עוברים לדף leaderboard Metrics explorer:
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Monitoring.
- בסרגל הכלים של חלונית הכלי ליצירת שאילתות, לוחצים על הלחצן ששמו הוא code MQL או code PromQL.
- מוודאים שהאפשרות PromQL נבחרה במתג שפה. המתג לשפה נמצא באותו סרגל כלים שבו אפשר לעצב את השאילתה.
- מזינים את השאילתה הבאה בעורך ולוחצים על Run query:
{"workload.googleapis.com/nginx.requests", monitored_resource="gce_instance"}
צפייה בלוח הבקרה
כדי לראות את המדדים של nginx, צריך להגדיר תרשים או לוח בקרה. השילוב של nginx כולל לוח בקרה אחד או יותר. כל לוחות הבקרה מותקנים אוטומטית אחרי שמגדירים את השילוב וסוכן Ops מתחיל לאסוף נתונים של מדדים.
אפשר גם לראות תצוגה מקדימה סטטית של מרכזי בקרה בלי להתקין את האינטגרציה.
כדי לראות מרכז בקרה שהותקן:
-
במסוף Google Cloud , עוברים לדף Dashboards:
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Monitoring.
- לוחצים על הכרטיסייה רשימת לוחות בקרה ואז בוחרים בקטגוריה שילובים.
- לוחצים על השם של מרכז הבקרה שרוצים להציג.
אם הגדרתם שילוב אבל לוח הבקרה לא הותקן, צריך לבדוק שסוכן התפעול פועל. אם אין נתוני מדדים לתרשים במרכז הבקרה, ההתקנה של מרכז הבקרה נכשלת. אחרי שסוכן התפעול מתחיל לאסוף מדדים, לוח הבקרה מותקן בשבילכם.
כדי לראות תצוגה מקדימה סטטית של מרכז הבקרה:
-
נכנסים לדף
Integrations במסוף Google Cloud :
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Monitoring.
- לוחצים על המסנן Compute Engine של פלטפורמת הפריסה.
- מאתרים את הרשומה של nginx ולוחצים על הצגת פרטים.
- לוחצים על הכרטיסייה מרכזי בקרה כדי לראות תצוגה מקדימה סטטית. אם מרכז הבקרה מותקן, אפשר ללחוץ על View dashboard (הצגת מרכז הבקרה) כדי לעבור אליו.
מידע נוסף על מרכזי בקרה ב-Cloud Monitoring זמין במאמר בנושא מרכזי בקרה וטבלאות.
מידע נוסף על השימוש בדף Integrations (שילובים) זמין במאמר ניהול שילובים.
התקנה של כללי מדיניות התראות
מדיניות התראות מורה ל-Cloud Monitoring לשלוח לכם התראה כשמתרחשים תנאים מסוימים. השילוב של nginx כולל מדיניות התראות אחת או יותר שתוכלו להשתמש בהן. אפשר לראות ולהתקין את מדיניות ההתראות הזו בדף שילובים ב-Monitoring.
כדי לראות את התיאורים של כללי מדיניות ההתראות הזמינים ולהתקין אותם:
-
נכנסים לדף
Integrations במסוף Google Cloud :
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Monitoring.
- מאתרים את הרשומה של nginx ולוחצים על הצגת פרטים.
- לוחצים על הכרטיסייה התראות. בכרטיסייה הזו מופיעים תיאורים של מדיניות ההתראות הזמינה וממשק להתקנתן.
- התקנה של כללי מדיניות התראות. כדי שמדיניות ההתראות תדע לאן לשלוח התראות על הפעלה של התראה, היא צריכה לקבל מכם מידע להתקנה.
כדי להתקין מדיניות התראות:
- ברשימת מדיניות ההתראות הזמינה, בוחרים את אלה שרוצים להתקין.
בקטע הגדרת התראות, בוחרים ערוץ התראות אחד או יותר. יש לכם אפשרות להשבית את השימוש בערוצי התראות, אבל אם תעשו את זה, מדיניות ההתראות שלכם תופעל ללא התראות. אפשר לבדוק את הסטטוס שלהם בדף 'מעקב', אבל לא תקבלו התראות.
מידע נוסף על ערוצי התראות זמין במאמר בנושא ניהול ערוצי התראות.
- לוחצים על יצירת מדיניות.
למידע נוסף על מדיניות התראות ב-Cloud Monitoring, אפשר לעיין במאמר מבוא להתראות.
מידע נוסף על השימוש בדף Integrations (שילובים) זמין במאמר ניהול שילובים.
פתרון בעיות
ברוב ההפצות, nginx מגיע עם ngx_http_stub_status_module מופעל.
כדי לבדוק אם המודול מופעל, מריצים את הפקודה הבאה:
sudo nginx -V 2>&1 | grep -o with-http_stub_status_module
הפלט הצפוי הוא with-http_stub_status_module, כלומר המודול מופעל. במקרים נדירים, אם הפקודה לא מחזירה פלט, צריך לקמפל את nginx ממקור עם -with-http_stub_status_module לפי התיעוד הציבורי של nginx.
המאמרים הבאים
בסרטון Install the Ops Agent to troubleshoot third-party applications מוסבר איך להשתמש ב-Ansible כדי להתקין את סוכן התפעול, להגדיר אפליקציית צד שלישי ולהתקין לוח בקרה לדוגמה.