| فقط مربوط به نسخه Cloud Firestore Enterprise است. |
این صفحه نحوه استفاده از معیارهای Cloud Monitoring برای Cloud Firestore با سازگاری MongoDB را برای نظارت بر پایگاه داده شما شرح می‌دهد.
معیارهای Cloud Monitoring برای Cloud Firestore با سازگاری MongoDB
بخش‌های زیر مروری بر معیارهای موجود برای Cloud Firestore با سازگاری MongoDB ارائه می‌دهند.
منابع تحت نظارت
یک منبع تحت نظارت در Cloud Monitoring یک موجودیت منطقی یا فیزیکی مانند یک ماشین مجازی، یک پایگاه داده یا یک برنامه را نشان می‌دهد. منابع تحت نظارت شامل مجموعه‌ای منحصر به فرد از معیارها هستند که می‌توانند بررسی شوند، از طریق داشبورد گزارش شوند یا برای ایجاد هشدارها استفاده شوند. هر منبع همچنین مجموعه‌ای از برچسب‌های منبع دارد که جفت‌های کلید-مقدار هستند و اطلاعات اضافی در مورد منبع را در خود جای می‌دهند. برچسب‌های منبع برای همه معیارهای مرتبط با منبع در دسترس هستند.
با استفاده از API Cloud Monitoring ، عملکرد سازگاری Cloud Firestore با MongoDB با منبع زیر رصد می‌شود:
| منابع | توضیحات |
firestore.googleapis.com/Database | نوع منبع تحت نظارت که جزئیات مربوط به project ، location و database_id را ارائه می‌دهد. |
معیارها
برای فهرست کاملی از معیارهای Cloud Firestore ، به معیارهای Cloud Firestore مراجعه کنید. بخش زیر برخی از معیارهای موجود را شرح می‌دهد.
معیارهای زمان اجرای سرویس
معیارهای serviceruntime یک نمای کلی سطح بالا از ترافیک یک پروژه ارائه می‌دهند. این معیارها برای اکثر APIهای Google Cloud در دسترس هستند. نوع منبع نظارت‌شده‌ی consumed_api شامل این معیارهای رایج است. این معیارها هر 30 دقیقه نمونه‌برداری می‌شوند و در نتیجه داده‌ها هموار می‌شوند.
یک برچسب منبع مهم برای معیارهای serviceruntime ، method است. این برچسب نشان دهنده روش RPC زیربنایی است. روش SDK که شما فراخوانی می‌کنید ممکن است لزوماً با روش RPC زیربنایی یکسان نباشد. دلیل این امر این است که SDK انتزاع API سطح بالایی را ارائه می‌دهد. با این حال، هنگام تلاش برای درک نحوه تعامل برنامه شما با Cloud Firestore ، درک معیارها بر اساس نام روش RPC مهم است.
اگر می‌خواهید بدانید که روش RPC زیربنایی برای یک روش SDK مشخص چیست، به مستندات API مراجعه کنید.
api/درخواست_latencies
معیار api/request_latencies توزیع تأخیر را در بین تمام درخواست‌های تکمیل‌شده ارائه می‌دهد.
Cloud Firestore معیارهایی را از مؤلفه سرویس Cloud Firestore ثبت می‌کند. معیارهای تأخیر شامل زمانی است که Cloud Firestore درخواست را دریافت می‌کند تا زمانی که Cloud Firestore ارسال پاسخ را به پایان می‌رساند، از جمله تعاملات با لایه ذخیره‌سازی. به همین دلیل، تأخیر رفت و برگشت (rtt) بین کلاینت و سرویس Cloud Firestore در این معیارها لحاظ نشده است.
معیارهای عملکرد سند
Cloud Firestore تعداد خواندن، نوشتن و حذف را ارائه می‌دهد. معیار نوشتن، تفکیکی بین عملیات «ایجاد» و «به‌روزرسانی» ارائه می‌دهد. این معیارها با عملیات CRUD همسو هستند.
از معیارهای زیر می‌توان برای درک اینکه آیا پایگاه داده شما سنگین خواندنی است یا سنگین نوشتنی، و همچنین نرخ اسناد جدید در مقابل اسناد حذف شده استفاده کرد.
-
document/delete_ops_count: تعداد حذف‌های موفق سند. -
document/read_ops_count: تعداد دفعات موفقیت‌آمیز خواندن سند از کوئری‌ها یا جستجوها. -
document/write_ops_count: تعداد دفعات نوشتن موفق سند.
معیارهای صورتحساب
از این معیارها برای درک میزان استفاده از صورتحساب استفاده کنید. این معیارها شامل صورتحساب‌های حاصل از عملیات مدیر (ایندکس‌گذاری، وارد کردن، صادر کردن و حذف دسته‌ای) نمی‌شوند.
api/billable_read_units: تعداد واحدهای خواندنی قابل پرداخت. میزان استفاده را می‌توان بر اساس نام سرویس و روش API تفکیک کرد.api/billable_write_units: تعداد واحدهای نوشتن قابل پرداخت. میزان استفاده را می‌توان بر اساس نام سرویس و روش API تفکیک کرد.document/billable_managed_delete_write_units: تعداد واحدهای نوشتن قابل پرداخت از سرویس‌های حذف مدیریت‌شده مانند TTL .
معیارهای شاخص
نرخ نوشتن شاخص را می‌توان با معیار document/write_ops_count مقایسه کرد تا میزان خروجی شاخص را درک کرد.
-
index/write_count: تعداد نوشتن‌های اندیس.
معیارهای TTL
معیارهای TTL برای Cloud Firestore با معیارهای سازگاری MongoDB برای نظارت بر تأثیر سیاست TTL اعمال شده استفاده می‌شوند.
-
document/ttl_deletion_count: تعداد کل اسناد حذف شده توسط سرویس‌های TTL. -
document/ttl_expiration_to_deletion_delays: مدت زمان سپری شده بین انقضای یک سند با TTL و حذف واقعی آن.
مشاهده داشبوردهای از پیش تعریف شده و ایجاد داشبوردهای سفارشی
Cloud Firestore با سازگاری با MongoDB از داشبوردهای از پیش تعریف شده‌ای که از معیارهای Cloud Monitoring استفاده می‌کنند، پشتیبانی می‌کند. همچنین می‌توانید داشبوردهای سفارشی ایجاد کنید.
مشاهده معیارهای استفاده از پایگاه داده
برای مشاهده‌ی خواندن، نوشتن و حذف اسناد در طول زمان، داشبوردهای استفاده را در کنسول Google Cloud باز کنید.
کنترل دسترسی
داشبوردهای استفاده به مجوز monitoring.timeSeries.list مدیریت هویت و دسترسی (IAM) نیاز دارند. نقش‌های مالک پروژه، ویرایشگر و بیننده این مجوز را اعطا می‌کنند. شما همچنین می‌توانید این مجوز را از طریق نقش Cloud Monitoring یا یک نقش سفارشی اعطا کنید.
داشبورد استفاده از پایگاه داده
برای مشاهده معیارهای استفاده برای Cloud Firestore با پایگاه داده سازگاری MongoDB، موارد زیر را انجام دهید.
در کنسول گوگل کلود، به صفحه پایگاه‌های داده بروید.
از لیست پایگاه‌های داده، پایگاه داده مورد نظر را انتخاب کنید.
در منوی پیمایش، روی «استفاده» کلیک کنید.
داشبورد استفاده و گزارش‌های صورتحساب
داشبوردهای استفاده از Cloud Firestore در کنسول، تخمینی از میزان استفاده ارائه می‌دهند. آن‌ها می‌توانند به شما در شناسایی افزایش ناگهانی مصرف کمک کنند. با این حال، این داشبورد نمای دقیقی از عملیات صورتحساب‌شده ارائه نمی‌دهد. میزان استفاده از صورتحساب‌شده احتمالاً بیشتر است. برای نظارت بر صورتحساب، به معیارهای صورتحساب مراجعه کنید.
در تمام موارد اختلاف، گزارش صورتحساب بر داشبورد استفاده اولویت دارد.
عملیات واردات و صادرات باعث ایجاد اختلاف بین داشبورد مصرف و میزان مصرف صورتحساب می‌شود. خواندن‌ها و نوشتن‌های انجام شده توسط این عملیات در داشبورد مصرف نمایش داده نمی‌شوند.
مشاهده معیارهای عملکرد پایگاه داده
صفحه نظارت در بخش Cloud Firestore کنسول Google Cloud شامل داشبوردهای نظارتی از پیش تعریف شده مانند تأخیر درخواست (P50 و P99) ، کدهای پاسخ و آمار پرس و جو (P50) است. همچنین می‌توانید تا یک داشبورد سفارشی ایجاد کنید. برای دسترسی به صفحه نظارت برای یک پایگاه داده، این مراحل را دنبال کنید:
در کنسول گوگل کلود، صفحه پایگاه‌های داده Cloud Firestore را باز کنید.
یک پایگاه داده از لیست انتخاب کنید.
در منوی ناوبری، روی «نظارت» کلیک کنید تا داشبورد باز شود.
داشبوردهای Cloud Monitoring سفارشی ایجاد کنید
در Cloud Monitoring ، داشبوردهای سفارشی به شما امکان می‌دهند اطلاعات مرتبط با خود را به صورت سازمان‌یافته نمایش دهید. به عنوان مثال، می‌توانید داشبوردی ایجاد کنید تا معیارهای عملکرد و سیاست‌های هشداردهی را برای پروژه خود در محیط عملیاتی نمایش دهید.
برای اطلاعات بیشتر در مورد تنظیم داشبورد سفارشی، به مدیریت داشبورد سفارشی و افزودن ابزارک‌های داشبورد مراجعه کنید.
ایجاد یک سیاست هشداردهنده
در Cloud Monitoring ، می‌توانید هشدارهایی ایجاد کنید تا هنگام تغییر در شرایط معیار، به شما اطلاع دهند. می‌توانید از این هشدارها برای مطلع شدن از مشکلات احتمالی قبل از تأثیرگذاری بر کاربران خود استفاده کنید.
برای اطلاعات بیشتر در مورد ایجاد هشدارها، به بخش «ایجاد سیاست‌های هشداردهی با آستانه معیار» مراجعه کنید.
مثال زیر را در نظر بگیرید که در آن یک سیاست هشدار تأخیر ایجاد می‌کنیم. سیاست هشدار، تأخیر p99 را در یک پنجره غلتان ۵ دقیقه‌ای بررسی می‌کند. اگر تأخیر p99 به مدت ۵ دقیقه بالاتر از ۲۵۰ میلی‌ثانیه باقی بماند، هشدار فعال می‌شود.
کنسول
در کنسول گوگل کلود، به صفحه Monitoring بروید و سپس notifications Alerting را انتخاب کنید.
ایجاد خط‌مشی را انتخاب کنید.
معیار تأخیر درخواست (Request Latencies) را از منبع API مصرفی (Consumed API) انتخاب کنید.
یک فیلتر سرویس برای
firestore.googleapis.comبرای پایگاه‌های داده استاندارد Cloud Firestore اضافه کنید.برای پیکربندی تریگر، روی «بعدی» کلیک کنید.
نوع شرایط را به عنوان آستانه (Threshold) انتخاب کنید.
یک شرط آستانه روی مقدار آستانه ۲۵۰ میلی‌ثانیه تنظیم شده است. هنگامی که مقدار تأخیر p99 برای کل دوره پنجره غلتان (۵ دقیقه) یکسان باقی بماند، هشدار فعال می‌شود.
مقدار Threshold را روی ۲۵۰ تنظیم کنید.
برای پیکربندی اعلان‌ها، روی «بعدی» کلیک کنید.
نام سیاست هشدار را تنظیم کنید و روی «بعدی» کلیک کنید.
پیکربندی‌های هشدار را بررسی کنید و روی ایجاد سیاست (Create Policy) کلیک کنید.
ام‌کیو‌ال
شما می‌توانید همین سیاست هشدار تأخیر را با استفاده از یک کوئری زبان جستجوی مانیتورینگ (MQL) پیاده‌سازی کنید. برای مثال‌های بیشتر از استفاده از MQL، به نمونه کوئری‌های MQL مراجعه کنید.
fetch consumed_api
| metric 'serviceruntime.googleapis.com/api/request_latencies'
| filter (resource.service == 'firestore.googleapis.com')
| group_by 5m,
[value_request_latencies_percentile:
percentile(value.request_latencies, 99)]
| every 5m
| condition val() > 0.25 's'