مشاركة عبر


نشر قاعدة بيانات PostgreSQL عالية التوفر على خدمة Azure Kubernetes (AKS)

في هذه المقالة، يمكنك نشر قاعدة بيانات PostgreSQL عالية التوفر على AKS.

Important

يتم ذكر البرامج مفتوحة المصدر في جميع وثائق وعينات AKS. يتم استبعاد البرامج التي تنشرها من اتفاقيات مستوى خدمة AKS والضمان المحدود ودعم Azure. أثناء استخدامك للتكنولوجيا مفتوحة المصدر جنبا إلى جنب مع AKS، راجع خيارات الدعم المتوفرة من المجتمعات المحلية المعنية ومشرفي المشاريع لوضع خطة.

تتحمل Microsoft مسؤولية بناء الحزم مفتوحة المصدر التي ننشرها على AKS. تتضمن هذه المسؤولية امتلاك ملكية كاملة لعملية البناء والمسح الضوئي والتوقيع والتحقق من الصحة وإصلاحها، بالإضافة إلى التحكم في الثنائيات في صور الحاوية. لمزيد من المعلومات، راجع إدارة الثغرات الأمنية لتغطية دعم AKS وAKS.

إنشاء سر لمستخدم تطبيق bootstrap

  1. إنشاء سر للتحقق من صحة نشر PostgreSQL عن طريق تسجيل الدخول التفاعلي لمستخدم تطبيق bootstrap باستخدام kubectl create secret الأمر .

Important

توصي Microsoft باستخدام تدفق المصادقة الأكثر أمانا المتوفر. يتطلب تدفق المصادقة الموضح في هذا الإجراء درجة عالية من الثقة في التطبيق وينطوي على مخاطر غير موجودة في التدفقات الأخرى. يجب عليك استخدام هذا التدفق فقط عندما لا تكون التدفقات الأخرى الأكثر أمانا، مثل الهويات المدارة، قابلة للتطبيق.

PG_DATABASE_APPUSER_SECRET=$(echo -n | openssl rand -base64 16)

kubectl create secret generic db-user-pass \
    --from-literal=username=app \
     --from-literal=password="${PG_DATABASE_APPUSER_SECRET}" \
     --namespace $PG_NAMESPACE \
     --context $AKS_PRIMARY_CLUSTER_NAME
  1. تحقق من أن السر تم إنشاؤه بنجاح باستخدام kubectl get الأمر .

    kubectl get secret db-user-pass --namespace $PG_NAMESPACE --context $AKS_PRIMARY_CLUSTER_NAME
    

تعيين متغيرات البيئة لنظام مجموعة PostgreSQL

  • نشر ConfigMap لتكوين عامل تشغيل CNPG باستخدام الأمر التالي kubectl apply . تحل هذه القيم محل التبديل القديم ENABLE_AZURE_PVC_UPDATES ، الذي لم يعد مطلوبا، وتساعد في ترتيب الترقيات وتسريع عمليات إعادة الاتصال بالنسخة المتماثلة. قبل إدخال هذا التكوين في الإنتاج، تحقق من أن أي إعدادات موجودة DRAIN_TAINTS تعتمد عليها تظل متوافقة مع بيئة Azure الخاصة بك.

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -n $PG_NAMESPACE -f -
    apiVersion: v1
    kind: ConfigMap
    metadata:
        name: cnpg-controller-manager-config
    data:
        CLUSTERS_ROLLOUT_DELAY: '120'
        STANDBY_TCP_USER_TIMEOUT: '10'
    EOF
    

تثبيت Prometheus PodMonitors

يقوم بروميثيوس بكشط CNPG باستخدام قواعد التسجيل المخزنة في مستودع عينات CNPG GitHub. نظرا لأن PodMonitor المدار من قبل المشغل يتم إهماله، يمكنك إنشاء مورد PodMonitor وإدارته بنفسك حتى تتمكن من تخصيصه وفقا لحزمة المراقبة الخاصة بك.

  1. أضف مستودع Prometheus Community Helm باستخدام helm repo add الأمر .

    helm repo add prometheus-community \
        https://prometheus-community.github.io/helm-charts
    
  2. قم بترقية مستودع Prometheus Community Helm وتثبيته على نظام المجموعة الأساسي باستخدام helm upgrade الأمر مع العلامة --install .

    helm upgrade --install \
        --namespace $PG_NAMESPACE \
        -f https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/main/docs/src/samples/monitoring/kube-stack-config.yaml \
        prometheus-community \
        prometheus-community/kube-prometheus-stack \
        --kube-context=$AKS_PRIMARY_CLUSTER_NAME
    
  3. قم بإنشاء PodMonitor لنظام المجموعة. يقوم فريق CNPG بإهمال PodMonitor الذي يديره المشغل، لذا يمكنك الآن إدارته مباشرة:

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -f -
    apiVersion: monitoring.coreos.com/v1
    kind: PodMonitor
    metadata:
      name: $PG_PRIMARY_CLUSTER_NAME
      namespace: ${PG_NAMESPACE}
      labels:
        cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
    spec:
      selector:
        matchLabels:
          cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
      podMetricsEndpoints:
        - port: metrics
    EOF
    

إنشاء بيانات اعتماد موحدة

في هذا القسم، يمكنك إنشاء بيانات اعتماد هوية موحدة للنسخ الاحتياطي PostgreSQL للسماح ل CNPG باستخدام هوية حمل عمل AKS للمصادقة على وجهة حساب التخزين للنسخ الاحتياطية. ينشئ عامل تشغيل CNPG حساب خدمة Kubernetes بنفس اسم نظام المجموعة المسمى المستخدم في بيان توزيع مجموعة CNPG.

  1. احصل على عنوان URL لمصدر OIDC للمجموعة باستخدام az aks show الأمر .

    export AKS_PRIMARY_CLUSTER_OIDC_ISSUER="$(az aks show \
        --name $AKS_PRIMARY_CLUSTER_NAME \
        --resource-group $RESOURCE_GROUP_NAME \
        --query "oidcIssuerProfile.issuerUrl" \
        --output tsv)"
    
  2. إنشاء بيانات اعتماد هوية موحدة باستخدام az identity federated-credential create الأمر .

    az identity federated-credential create \
        --name $AKS_PRIMARY_CLUSTER_FED_CREDENTIAL_NAME \
        --identity-name $AKS_UAMI_CLUSTER_IDENTITY_NAME \
        --resource-group $RESOURCE_GROUP_NAME \
        --issuer "${AKS_PRIMARY_CLUSTER_OIDC_ISSUER}" \
        --subject system:serviceaccount:"${PG_NAMESPACE}":"${PG_PRIMARY_CLUSTER_NAME}" \
        --audience api://AzureADTokenExchange
    

نشر مجموعة PostgreSQL عالية التوفر

في هذا القسم، يمكنك نشر مجموعة PostgreSQL عالية التوفر باستخدام تعريف المورد المخصص لنظام مجموعة CNPG (CRD).

معلمات CRD لنظام المجموعة

يوضح الجدول التالي خصائص المفتاح التي تم تعيينها في بيان توزيع YAML ل Cluster CRD:

Property Definition
imageName يشير إلى صورة حاوية عامل CloudNativePG. استخدم ghcr.io/cloudnative-pg/postgresql:18-system-trixie مع تكامل النسخ الاحتياطي الأساسي الموضح في هذا الدليل، أو قم بالتبديل إلى 18-standard-trixie عند اعتماد المكون الإضافي Barman Cloud.
inheritedMetadata خاص بعامل تشغيل CNPG. يطبق عامل التشغيل CNPG بيانات التعريف على كل كائن متعلق بالمجموعة.
annotations يتضمن تسمية DNS المطلوبة عند عرض نقاط نهاية نظام المجموعة وتمكين alpha.cnpg.io/failoverQuorum تجاوز الفشل المستند إلى النصاب القانوني.
labels: azure.workload.identity/use: "true" يشير إلى أنه يجب على AKS إدخال تبعيات هوية حمل العمل في pods التي تستضيف مثيلات نظام مجموعة PostgreSQL.
topologySpreadConstraints تتطلب مناطق مختلفة وعقدا مختلفة مع تسمية "workload=postgres".
resources تكوين فئة جودة الخدمة (QoS) المضمونة. في بيئة الإنتاج، تعد هذه القيم مفتاحا لتعظيم استخدام العقدة الظاهرية الأساسية وتختلف استنادا إلى Azure VM SKU المستخدم.
probes استبدال التكوين القديم startDelay . تساعد فحوصات بدء التشغيل والاستعداد المتدفقة على ضمان صحة النسخ المتماثلة قبل خدمة حركة المرور.
smartShutdownTimeout يسمح للمعاملات طويلة الأمد بالانتهاء بأمان أثناء التحديثات بدلا من استخدام تأخيرات الإيقاف الشديدة.
bootstrap خاص بعامل تشغيل CNPG. يتم التهيئة باستخدام قاعدة بيانات تطبيق فارغة.
storage يحدد إعدادات PersistentVolume لقاعدة البيانات. باستخدام أقراص Azure المدارة، يحتفظ بناء الجملة المبسط بالبيانات وWAL على نفس وحدة التخزين 64 غيغابايت، مما يوفر مستويات معدل نقل أفضل على الأقراص المدارة. اضبط إذا كنت بحاجة إلى وحدات تخزين WAL منفصلة.
postgresql.synchronous يستبدل minSyncReplicas/maxSyncReplicas ويتيح لك تحديد سلوك النسخ المتماثل المتزامن باستخدام المخطط الأحدث.
postgresql.parameters خاص بعامل تشغيل CNPG. تعيين الإعدادات ل postgresql.confو pg_hba.confو.pg_ident.conf يؤكد النموذج على إمكانية الملاحظة وإعدادات الاحتفاظ ب WAL الافتراضية التي تناسب سيناريو هوية حمل عمل AKS ولكن يجب ضبطها لكل حمل عمل.
serviceAccountTemplate يحتوي على القالب المطلوب لإنشاء حسابات الخدمة وتعيين بيانات اعتماد الهوية الموحدة ل AKS إلى UAMI لتمكين مصادقة هوية حمل عمل AKS من القرون التي تستضيف مثيلات PostgreSQL إلى موارد Azure الخارجية.
barmanObjectStore خاص بعامل تشغيل CNPG. تكوين مجموعة أدوات barman-cloud باستخدام هوية حمل عمل AKS للمصادقة على مخزن عناصر Azure Blob Storage.

لعزل أحمال عمل PostgreSQL بشكل أكبر، يمكنك إضافة تلوث (على سبيل المثال، node-role.kubernetes.io/postgres=:NoSchedule) إلى عقد مستوى البيانات واستبدال العينة nodeSelector/tolerations بالقيم الموصى بها بواسطة CloudNativePG. إذا اتبعت هذا النهج، فقم بتسمية العقد وفقا لذلك وتأكد من توافق سياسات التحجيم التلقائي AKS مع المخطط الخاص بك.

معلمات أداء PostgreSQL

يعتمد أداء PostgreSQL بشكل كبير على الموارد الأساسية لنظام المجموعة وحمل العمل. يوفر الجدول التالي إرشادات أساسية لمجموعة ثلاثية العقد تعمل على عقد D4s v3 القياسية (ذاكرة 16 غيغابايت). تعامل مع هذه القيم كنقطة بداية وقم بتعديلها بمجرد فهم ملف تعريف حمل العمل:

Property القيمة الموصى بها Definition
wal_compression lz4 ضغط عمليات الكتابة بالصفحة الكاملة المكتوبة في ملف WAL بطريقة محددة
max_wal_size 6 غيغابايت تعيين حجم WAL الذي يؤدي إلى نقطة تحقق
checkpoint_timeout 15 دقيقة تعيين الحد الأقصى للوقت بين نقاط التحقق التلقائية من WAL
checkpoint_completion_target 0.9 موازنة عمل نقاط التفتيش عبر نافذة نقطة التفتيش
checkpoint_flush_after 2 ميغابايت عدد الصفحات التي يتم بعدها مسح عمليات الكتابة التي تم إجراؤها مسبقا إلى القرص
wal_writer_flush_after 2 ميغابايت مقدار WAL الذي كتبه كاتب WAL الذي يؤدي إلى تدفق
min_wal_size 2 جيجابايت تعيين الحد الأدنى للحجم لتقليص WAL إلى
max_slot_wal_keep_size 10 غيغابايت الحد الأعلى ل WAL المتبقي لفتحات النسخ المتماثل للخدمة
shared_buffers 4 غيغابايت لتعيين عدد المخازن المؤقتة للذاكرة المشتركة التي يستخدمها الخادم (25% من ذاكرة العقدة في هذا المثال)
effective_cache_size ⁧12 غيغابايت تعيين افتراض المخطط حول الحجم الإجمالي لذاكرة التخزين المؤقت للبيانات
work_mem 1/256 من ذاكرة العقدة تعيين الحد الأقصى للذاكرة لاستخدامها في مساحات عمل الاستعلام
maintenance_work_mem 6.25% من ذاكرة العقدة تعيين الحد الأقصى للذاكرة لاستخدامها في عمليات الصيانة
autovacuum_vacuum_cost_limit 2400 مبلغ تكلفة التفريغ المتاح قبل القيلولة، للإخلاء التلقائي
random_page_cost 1.1 تعيين تقدير المخطط لتكلفة صفحة القرص التي تم جلبها بشكل غير متكرر
effective_io_concurrency 64 يحدد عدد الطلبات المتزامنة التي يمكن للنظام الفرعي للقرص التعامل معها بكفاءة
maintenance_io_concurrency 64 متغير من "effective_io_concurrency" يستخدم في أعمال الصيانة

نشر PostgreSQL

  1. انشر نظام مجموعة PostgreSQL مع Cluster CRD باستخدام kubectl apply الأمر .

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -n $PG_NAMESPACE -v 9 -f -
    apiVersion: postgresql.cnpg.io/v1
    kind: Cluster
    metadata:
      name: $PG_PRIMARY_CLUSTER_NAME
      annotations:
        alpha.cnpg.io/failoverQuorum: "true"
    spec:
      imageName: ghcr.io/cloudnative-pg/postgresql:18-system-trixie
      inheritedMetadata:
        annotations:
          service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
        labels:
          azure.workload.identity/use: "true"
    
      instances: 3
      smartShutdownTimeout: 30
    
      probes:
        startup:
          type: streaming
          maximumLag: 32Mi
          periodSeconds: 5
          timeoutSeconds: 3
          failureThreshold: 120
        readiness:
          type: streaming
          maximumLag: 0
          periodSeconds: 10
          failureThreshold: 6
    
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            cnpg.io/cluster: $PG_PRIMARY_CLUSTER_NAME
    
      affinity:
        nodeSelector:
          workload: postgres
    
      resources:
        requests:
          memory: '8Gi'
          cpu: 2
        limits:
          memory: '8Gi'
          cpu: 2
    
      bootstrap:
        initdb:
          database: appdb
          owner: app
          secret:
            name: db-user-pass
          dataChecksums: true
    
      storage:
        storageClass: $POSTGRES_STORAGE_CLASS
        size: 64Gi
    
      postgresql:
        synchronous:
          method: any
          number: 1
        parameters:
          wal_compression: lz4
          max_wal_size: 6GB
          max_slot_wal_keep_size: 10GB
          checkpoint_timeout: 15min
          checkpoint_completion_target: '0.9'
          checkpoint_flush_after: 2MB
          wal_writer_flush_after: 2MB
          min_wal_size: 2GB
          shared_buffers: 4GB
          effective_cache_size: 12GB
          work_mem: 62MB
          maintenance_work_mem: 1GB
          autovacuum_vacuum_cost_limit: "2400"
          random_page_cost: "1.1"
          effective_io_concurrency: "64"
          maintenance_io_concurrency: "64"
          log_checkpoints: 'on'
          log_lock_waits: 'on'
          log_min_duration_statement: '1000'
          log_statement: 'ddl'
          log_temp_files: '1024'
          log_autovacuum_min_duration: '1s'
          pg_stat_statements.max: '10000'
          pg_stat_statements.track: 'all'
          hot_standby_feedback: 'on'
        pg_hba:
          - host all all all scram-sha-256
    
      serviceAccountTemplate:
        metadata:
          annotations:
            azure.workload.identity/client-id: "$AKS_UAMI_WORKLOAD_CLIENTID"
          labels:
            azure.workload.identity/use: "true"
    
      backup:
        barmanObjectStore:
          destinationPath: "https://${PG_PRIMARY_STORAGE_ACCOUNT_NAME}.blob.core.windows.net/backups"
          azureCredentials:
            inheritFromAzureAD: true
        retentionPolicy: '7d'
    EOF
    

إشعار

يستخدم نموذج البيان الصورة ghcr.io/cloudnative-pg/postgresql:18-system-trixie لأنه يعمل مع تكامل Barman Cloud المدمج الموضح لاحقا. عندما تكون جاهزا للتبديل إلى المكون الإضافي Barman Cloud، قم بالتحديث spec.imageName إلى ghcr.io/cloudnative-pg/postgresql:18-standard-trixieإرشادات تكوين المكون الإضافي واتبعها قبل إعادة توزيع نظام المجموعة.

Important

يسمح إدخال المثال pg_hba بالوصول إلى غير TLS. إذا احتفظت بهذا التكوين، فقم بتوثيق الآثار الأمنية لفريقك وفضل الاتصالات المشفرة حيثما أمكن ذلك.

  1. تحقق من أن مجموعة PostgreSQL الأساسية تم إنشاؤها بنجاح باستخدام kubectl get الأمر . حدد CNPG Cluster CRD ثلاثة مثيلات، والتي يمكن التحقق من صحتها عن طريق عرض وحدات الجراب قيد التشغيل بمجرد إحضار كل مثيل والانضمام إليه للنسخ المتماثل. كن صبورا لأنه قد يستغرق بعض الوقت لجميع المثيلات الثلاثة لتأتي عبر الإنترنت وتنضم إلى المجموعة.

    kubectl get pods --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME
    

    مثال على الإخراج

    NAME                         READY   STATUS    RESTARTS   AGE
    pg-primary-cnpg-r8c7unrw-1   1/1     Running   0          4m25s
    pg-primary-cnpg-r8c7unrw-2   1/1     Running   0          3m33s
    pg-primary-cnpg-r8c7unrw-3   1/1     Running   0          2m49s
    

Important

إذا كنت تستخدم NVMe المحلي مع Azure Container Storage وظل الجراب في حالة init مع خطأ متعدد الإرفاق، فلا يزال الجراب يبحث عن وحدة التخزين على عقدة مفقودة. بعد بدء تشغيل الجراب ، يدخل في CrashLoopBackOff حالة لأن CNPG ينشئ نسخة متماثلة جديدة على عقدة جديدة بدون بيانات ولا يمكنه العثور على الدليل pgdata . لحل هذه المشكلة، قم بإتلاف المثيل المتأثر وإظهار مثيل جديد. قم بتشغيل الأمر التالي:

kubectl cnpg destroy [cnpg-cluster-name] [instance-number]  

التحقق من صحة Prometheus PodMonitor قيد التشغيل

يربط PodMonitor الذي تم إنشاؤه يدويا تكوين كشط kube-prometheus-stack بجرون CNPG التي قمت بنشرها سابقا.

تحقق من أن PodMonitor قيد التشغيل باستخدام kubectl get الأمر .

kubectl --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    get podmonitors.monitoring.coreos.com \
    $PG_PRIMARY_CLUSTER_NAME \
    --output yaml

مثال على الإخراج

kind: PodMonitor
metadata:
  labels:
    cnpg.io/cluster: pg-primary-cnpg-r8c7unrw
  name: pg-primary-cnpg-r8c7unrw
  namespace: cnpg-database
spec:
  podMetricsEndpoints:
  - port: metrics
  selector:
    matchLabels:
      cnpg.io/cluster: pg-primary-cnpg-r8c7unrw

إذا كنت تستخدم Azure Monitor ل Prometheus المدار، فستحتاج إلى إضافة جهاز عرض جراب آخر باستخدام اسم المجموعة المخصص. لا يلتقط Prometheus المدار تعريفات الموارد المخصصة (CRDs) من مجتمع Prometheus. وبصرف النظر عن اسم المجموعة، فإن CRDs هي نفسها. يتيح هذا التصميم لشاشات الكبسولات الخاصة ب Prometheus المدارة العمل جنبا إلى جنب مع شاشات الكبسولات التي تستخدم CRD المجتمعي. إذا كنت لا تستخدم Prometheus المدار، فيمكنك تخطي هذا القسم. إنشاء جهاز عرض جراب جديد:

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -f -
apiVersion: azmonitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: cnpg-cluster-metrics-managed-prometheus
  namespace: ${PG_NAMESPACE}
  labels:
    azure.workload.identity/use: "true"
    cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
spec:
  selector:
    matchLabels:
      azure.workload.identity/use: "true"
      cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
  podMetricsEndpoints:
    - port: metrics
EOF

تحقق من إنشاء جهاز عرض pod (لاحظ الفرق في اسم المجموعة).

kubectl --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    get podmonitors.azmonitoring.coreos.com \
    -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME \
    -o yaml

الخيار أ - مساحة عمل Azure Monitor

بعد نشر مجموعة Postgres وجهاز مراقبة الجراب، يمكنك عرض المقاييس باستخدام مدخل Microsoft Azure في مساحة عمل Azure Monitor.

لقطة شاشة تعرض مقاييس نظام مجموعة Postgres في مساحة عمل Azure Monitor في مدخل Microsoft Azure.

الخيار ب - Grafana المدارة

بدلا من ذلك، بعد نشر نظام مجموعة Postgres وشاشات الجراب، يمكنك إنشاء لوحة معلومات مقاييس على مثيل Grafana المدار الذي تم إنشاؤه بواسطة البرنامج النصي للتوزيع لتصور المقاييس التي تم تصديرها إلى مساحة عمل Azure Monitor. يمكنك الوصول إلى Managed Grafana عبر مدخل Microsoft Azure. انتقل إلى مثيل Grafana المدار الذي تم إنشاؤه بواسطة البرنامج النصي للتوزيع وحدد ارتباط نقطة النهاية كما هو موضح هنا:

لقطة شاشة لمقاييس نظام مجموعة Postgres في مثيل Azure Managed Grafana في مدخل Microsoft Azure.

يؤدي تحديد ارتباط نقطة النهاية إلى فتح نافذة مستعرض جديدة حيث يمكنك إنشاء لوحات معلومات على مثيل Grafana المدار. باتباع الإرشادات لتكوين مصدر بيانات Azure Monitor، يمكنك بعد ذلك إضافة مرئيات لإنشاء لوحة معلومات من المقاييس من مجموعة Postgres. بعد إعداد اتصال مصدر البيانات، من القائمة الرئيسية، حدد الخيار مصادر البيانات. يجب أن تشاهد مجموعة من خيارات مصدر البيانات لاتصال مصدر البيانات كما هو موضح هنا:

لقطة شاشة تعرض خيارات مصدر بيانات Azure Monitor في مدخل Microsoft Azure.

في الخيار Managed Prometheus، حدد خيار إنشاء لوحة معلومات لفتح محرر لوحة المعلومات. بعد فتح نافذة المحرر، حدد خيار إضافة تصور ثم حدد خيار بروميثيوس المدار لاستعراض المقاييس من مجموعة Postgres. بعد تحديد المقياس الذي تريد تصوره، حدد الزر تشغيل الاستعلامات لجلب البيانات للمرئيات كما هو موضح هنا:

لقطة شاشة تعرض لوحة معلومات Prometheus المدارة مع مقاييس نظام مجموعة Postgres.

حدد أيقونة حفظ لإضافة اللوحة إلى لوحة المعلومات. يمكنك إضافة لوحات أخرى عن طريق تحديد الزر Add في محرر لوحة المعلومات وتكرار هذه العملية لتصور المقاييس الأخرى. إضافة مرئيات المقاييس، يجب أن يكون لديك شيء يبدو كما يلي:

لقطة شاشة تعرض لوحة معلومات Prometheus المدارة المحفوظة في مدخل Microsoft Azure.

حدد الأيقونة حفظ لحفظ لوحة المعلومات.


الخطوات التالية

Contributors

تحتفظ Microsoft بهذه المقالة. كتبه المساهمون التاليون في الأصل:

  • كين كيلتي | الوحدة النمطية للنظام الأساسي الموثوق به
  • راسل دي بينا | الوحدة النمطية للنظام الأساسي الموثوق به
  • أدريان جويان | مهندس عملاء أول
  • جيني هايز | مطور محتوى أول
  • كارول سميث | مطور محتوى أول
  • إيرين شيفر | مطور المحتوى 2
  • آدم شريف | مهندس عميل 2

اعتراف

تم تطوير هذه الوثائق بالاشتراك مع EnterpriseDB، المشرفين على مشغل CloudNativePG. نشكر غابرييل بارتوليني على مراجعة المسودات السابقة لهذه الوثيقة وتقديم التحسينات التقنية.