مفاتيح API
يتطلب استخدام ClickHouse OpenAPI المصادقة؛ راجع [مفاتيح API] لمعرفة كيفية إنشائها. ثم استخدمها كبيانات اعتماد Basic Auth على النحو التالي:معرّف المؤسسة
بعد ذلك، ستحتاج إلى معرّف مؤسستك.- حدِّد اسم مؤسستك في الزاوية السفلية اليسرى من الواجهة.
- حدِّد تفاصيل المؤسسة.
- اضغط على أيقونة النسخ إلى يمين معرّف المؤسسة لنسخه مباشرةً إلى الحافظة.
CRUD
لنلقِ نظرة على دورة حياة خدمة Postgres.إنشاء
أولًا، أنشئ خدمة جديدة باستخدام [واجهة برمجة تطبيقات create]. وتتطلب الخصائص التالية في نص JSON للطلب:name: اسم خدمة Postgres الجديدةprovider: اسم موفّر السحابة:aws(أوgcpفي المعاينة الخاصة)region: المنطقة ضمن شبكة الموفّر التي ستُنشر فيها الخدمةsize: حجم الآلة الافتراضية
قراءة
استخدم القيمةid من الاستجابة لاسترجاع الخدمة مرة أخرى:
state؛ فعندما تتغير إلى running، يكون الخادم جاهزًا:
connectionString المحفوظة من استجابة الإنشاء
للاتصال، على سبيل المثال عبر psql:
\q للخروج من psql.
تحديث
تدعم [واجهة برمجة تطبيقات patch] تحديث مجموعة فرعية من خصائص خدمة Managed Postgres باستخدام RFC 7396 JSON Merge Patch. وقد تكتسب الوسوم أهمية خاصة في عمليات النشر المعقدة؛ ما عليك سوى إرسالها وحدها ضمن الطلب:حذف
استخدم [واجهة برمجة تطبيقات الحذف] لحذف خدمة Postgres.المراقبة
توفّر نقطتا نهاية متوافقتان مع Prometheus مقاييس CPU والذاكرة والإدخال/الإخراج والاتصالات والمعاملات لخدمات ClickHouse Managed Postgres: تُرجع إحداهما المقاييس لكل خدمة في المؤسسة، بينما تُرجع الأخرى المقاييس لخدمة واحدة. راجع صفحة [نقطة نهاية Prometheus] لمعرفة كيفية الإعداد، و[مرجع المقاييس] للاطلاع على القائمة الكاملة للمقاييس.Query insights
إن بيانات القياس عن بُعد الخاصة بكل عبارة، والتي تستند إليها علامة التبويب Query Insights في الكونسول السحابي، متاحة أيضًا برمجيًا. توفّر نقطتا نهاية أبطأ أنماط الاستعلامات في خدمة: تسرد إحداهما جميع الأنماط مرتبةً حسب التأثير، بينما تُرجع الأخرى نمطًا واحدًا مع أحدث عمليات تنفيذه.إدراج أنماط الاستعلامات البطيئة
تعيد [واجهة برمجة تطبيقات الأنماط البطيئة] مقاييس مجمّعة لأبطأ أنماط الاستعلامات التي تم رصدها خلال نافذة زمنية. هذه النافذة مطلوبة — مرّرfrom_date وto_date كطوابع زمنية بتنسيق RFC 3339:
total_duration
ترتيبًا تنازليًا. فرّز حسب عدّاد مختلف باستخدام sort_by (على سبيل المثال
p99_duration أو call_count أو total_wal_bytes) واعكس الاتجاه
باستخدام sort_order. ضيّق مجموعة النتائج باستخدام عوامل التصفية db_name وdb_user
وdb_operation وapp، وتصفّح صفحاتها باستخدام limit و
offset.
يمثّل كلّ ناتج نمطًا مُطبَّعًا واحدًا، مع إزالة القيم الحرفية منه
والإبلاغ عن المدد بوحدة الميكروثانية:
queryId هو قيمة hash موقَّعة بطول 64 بت للعبارة المُطبَّعة، لذلك
يكون سالبًا في كثير من الأحيان. أعد تمريره كما هو تمامًا — بما في ذلك الشرطة - في
البداية — لاسترجاع نمط استعلام واحد.
الحصول على نمط استعلام بطيء
مرّرqueryId من استجابة القائمة إلى [واجهة برمجة تطبيقات نمط الاستعلامات البطيئة] للحصول على
المقاييس المجمّعة لهذا النمط إلى جانب أحدث عمليات التنفيذ الفردية له.
القيم db_name وdb_user وdb_operation التي تُعرّف هذا النمط
مطلوبة:
aggregate، بالإضافة إلى مصفوفة recentExecutions. ويتضمن كل تنفيذ
العدادات الكاملة الخاصة به — إدخال/إخراج الكتل المشتركة والمؤقتة، ووقت
CPU للمستخدم والنظام، والعمّال المتوازيون، وJIT، وWAL — وهي العدادات نفسها التي
تفصّلها [اللوحة الجانبية للتفاصيل] في الكونسول:
سجلات الخادم
تتوفر سجلات خادم PostgreSQL المعروضة في عارض السجلات ضمن الكونسول السحابي أيضًا برمجيًا. تُرجع [واجهة برمجة تطبيقات السجلات] إدخالات سجل فردية لخدمة خلال نافذة زمنية. وكما هو الحال مع Query Insights، يلزم تحديد النافذة، لذا مرّرfrom_date وto_date كطوابع زمنية بتنسيق RFC 3339. يجب ألا يتجاوز النطاق
30 يومًا، ويجب أن يكون to_date بعد from_date:
sort_order (asc أو
desc). رشّح حسب مستوى خطورة واحد باستخدام severity (مثل ERROR أو
WARNING أو LOG)، وطابِق سلسلة فرعية حساسة لحالة الأحرف في متن السجل باستخدام
body_contains، وتصفّح النتائج باستخدام limit وoffset.
يتضمن كل إدخال timestamp وseverity وbody الخام. ويكون المتن
دائمًا سلسلة نصية: تُعاد أسطر السجل المهيكلة بتنسيق JSON، بينما تُعاد الأسطر العادية
كما هي:
limit وoffset بدلاً من إرجاع
عدد إجمالي؛ زِد offset حتى تُرجع الصفحة عددًا من الإدخالات أقل من limit.