רישום ביומן של Cloud DNS עוקב אחרי שאילתות ששרתי שמות פותרים בשביל רשתות ה-VPC שלכם.
השאילתות שנרשמות ביומן יכולות להגיע ממכונות וירטואליות (VM) של Compute Engine, מקונטיינרים של Google Kubernetes Engine באותה רשת VPC, מתחומי קישור בין רשתות שכנות או מלקוחות מקומיים שמשתמשים בהעברת DNS נכנסת.
בסופו של דבר, יכול להיות שהשאילתות יטופלו על ידי תחומי DNS פרטיים, תחומי DNS להעברה, שרתי שמות חלופיים, תחומי DNS פנימיים שלGoogle Cloud או תחומי DNS חיצוניים.
רשומות היומן שייכות לפרויקט שבבעלותו הרשת שבהם הועברה הבקשה. במקרה של VPC משותף, רשומות היומן שייכות לפרויקט המארח כי הפרויקט המארח הוא הבעלים של הרשת.
הפעלת רישום ביומן של אזורים מנוהלים פרטיים
אתם יכולים להשתמש בכללי מדיניות DNS כדי להפעיל או להשבית את הרישום ביומן של הרשתות שלכם. כשמפעילים את רישום השאילתות ביומן, כל שאילתת DNS לאזור מנוהל פרטי ב-Cloud DNS נרשמת ביומן.
שם היעד, למשל שם האזור, שם המדיניות, שם האזור הפנימי, שם הדומיין החיצוני
כן
target_type
String
סוג היעד שמפענח את שאילתת ה-DNS: private-zone, forwarding-zone, forwarding-policy, peering-zone, internal, external, response-policy, service-directory-zone, reverse-lookup-zone, zonal-private-zone
כן
unHealthyIps
String
קבוצה של כתובות IP ב-ResourceRecordSet שידועות ל-Cloud DNS בתור UNHEALTHY בזמן השאילתה
לא
vmInstanceId
מספר / מקור
מזהה מכונת VM של Compute Engine, רלוונטי רק לשאילתות שהתחילו על ידי מכונות וירטואליות של Compute Engine
לא
vmInstanceName
מחרוזת / מקור
שם המכונה הווירטואלית של Compute Engine, רלוונטי רק לשאילתות שהתחילו על ידי מכונות וירטואליות של Compute Engine
לא
vmProjectId
מחרוזת / מקור
Google Cloud מזהה הפרויקט של הרשת שממנה נשלחה השאילתה, רלוונטי רק לשאילתות שהתחילו על ידי מכונות וירטואליות של Compute Engine
לא
vmZoneName
מחרוזת / מקור
שם האזור של המכונה הווירטואלית שממנה נשלחה השאילתה, רלוונטי רק לשאילתות שהתחילו על ידי מכונות וירטואליות של Compute Engine
לא
תמחור
כל היומנים של Cloud DNS נכתבים ב-Cloud Logging. אין חיוב נפרד מ-Cloud DNS על השירות הזה. עם זאת, היומנים האלה יכולים לגרום לעלויות אחסון נוספות, בהתאם לגודל היומנים שנכתבים ומאוחסנים.
לצורך החישוב, Cloud DNS כותב כ-5MB של נתוני יומן כדי לעבד 10,000 שאילתות DNS.
אתם יכולים לעקוב אחרי קצב השאילתות והתשובות של DNS שמפנות לאזורים פרטיים, לאזורי העברה, להעברת מדיניות, לאזורים פנימיים של Google Cloud ולאינטרנט. אפשר לעקוב אחרי המדדים בדף Monitoring ב Google Cloud מסוף וב-Cloud Monitoring API.
מערכת Private DNS מייצאת את מדד השינוי dns.googleapis.com/query/response_count שמכיל את התווית response_code כדי לספור את מספר השאילתות לכל קוד תגובה.
התווית response_code היא מסוג string, והערכים האפשריים שלה הם NOERROR, FORMERR, SERVFAIL, NXDOMAIN, NOTIMP ו-UNKNOWN.
ההגדרות של הקודים האלה מפורטות במאמר IANA DNS RCODEs.
המדד מיוצא לסוג המשאב dns_query באמצעות השדות הרלוונטיים של פורמט הרשומה ביומן.
מעקב אחרי הפצת ה-DNS
כשמשתמשים ב-Google Cloud CLI או ב-API בארכיטקטורת REST כדי לבצע שינויים, השינויים מסומנים בהתחלה כ"בהמתנה" עד שהפעולה מסתיימת. אפשר להשתמש ב-CLI של gcloud או ב-API בארכיטקטורת REST כדי לבדוק את סטטוס השינויים או לקבל את היסטוריית השינויים.
פעולה מסתיימת (סטטוס: done) כש-Cloud DNS מעדכן בהצלחה את המערכת ששולטת בשרתים. יכול להיות שעדיין יהיו עיכובים עד שכל שרתי השמות יעודכנו.
כדי לעקוב אחרי השינויים ולוודא שהם נקלטו בשרת השמות של ה-DNS, אתם יכולים להשתמש בפקודות watch ו-dig. בדוגמה הבאה מוסבר איך לחפש את שרת השמות ולבדוק מתי אחד משרתי השמות של האזור המנוהל שלכם זיהה שינוי ברשומת MX.
הפקודה watch מריצה את הפקודה dig כל 2 שניות כברירת מחדל. אפשר להשתמש בפקודה הזו כדי לקבוע מתי שרת השמות המהימן יקלוט את השינוי, וזה אמור לקרות תוך 120 שניות. אחרי שהשינוי יתעדכן בשרת השמות המהימן, מפענחי DNS יוכלו להתחיל לאסוף את הרשומה החדשה.
מפענחים שכבר שמרו במטמון את הרשומה הקודמת ממתינים עד שיפוג התוקף של ערך ה-TTL הקודם של הרשומה.
כדי להריץ את dig בשרת השמות של המערכת, אפשר להסיר את @<address> מהפקודה dig. אם רוצים לעקוב אחרי ההפצה לשרתי שמות אחרים, אפשר לשנות את address כך שיצביע על שרתי שמות אחרים.