تخصيص استخراج مقاييس Prometheus في خدمة Azure Monitor المدارة ل Prometheus

  • مقالة

توفر هذه المقالة إرشادات حول تخصيص المقاييس لاستخراج مجموعة Kubernetes مع ملحق المقاييس في Azure Monitor.

خريطة التكوين

يمكن تكوين أربعة تكوينات مختلفة لتوفير تكوين كشط وإعدادات أخرى للوظيفة الإضافية للمقاييس. يجب تطبيق جميع خرائط التكوين على kube-system مساحة الاسم لأي نظام مجموعة.

إشعار

لا يوجد أي من التكوينات الأربعة بشكل افتراضي في نظام المجموعة عند تمكين Prometheus المدار. اعتمادا على ما يجب تخصيصه، تحتاج إلى نشر أي من هذه التكوينات الأربعة أو كلها بنفس الاسم المحدد، في kube-system مساحة الاسم. سوف تلتقط pods AMA-Metrics هذه التكوينات بعد نشرها في kube-system مساحة الاسم، وستتم إعادة تشغيلها في 2-3 دقائق لتطبيق إعدادات التكوين المحددة في configmap (التكوينات).

  1. ama-metrics-settings-configmap تحتوي خريطة التكوين هذه على إعدادات بسيطة أدناه يمكن تكوينها. يمكنك أخذ configmap من git hub repo أعلاه، وتغيير الإعدادات المطلوبة وتطبيق/توزيع configmap إلى kube-system مساحة الاسم للمجموعة الخاصة بك
    • الاسم المستعار لنظام المجموعة (لتغيير قيمة cluster التسمية في كل سلسلة زمنية/مقياس يتم استيعابه من نظام مجموعة)
    • تمكين/تعطيل أهداف الكشط الافتراضية - تشغيل/إيقاف تشغيل الكشط الافتراضي استنادا إلى الأهداف. تكوين استخراج هذه الأهداف الافتراضية معرفة مسبقا/مضمنة بالفعل
    • تمكين الاستخراج المستند إلى التعليق التوضيحي للجراب لكل مساحة اسم
    • قوائم الاحتفاظ بالمقاييس - يستخدم هذا الإعداد للتحكم في المقاييس المدرجة التي سيتم السماح بها من كل هدف افتراضي وتغيير السلوك الافتراضي
    • فواصل زمنية للتعريفات الافتراضية/المسبقة. 30 secs هو تردد القصاصة الافتراضي ويمكن تغييره لكل هدف افتراضي باستخدام خريطة التكوين هذه
    • وضع التصحيح - يساعد تشغيل هذا على تصحيح مشكلات القياس/الاستيعاب المفقودة - راجع المزيد حول استكشاف الأخطاء وإصلاحها
  2. ama-metrics-prometheus-config يمكن استخدام خريطة التكوين هذه لتوفير تكوين استخراج Prometheus للنسخة المتماثلة الإضافية. يقوم Addon بتشغيل نسخة متماثلة أحادية، ويمكن اكتشاف أي خدمات على مستوى نظام المجموعة واستخراجها من خلال توفير مهام الكشط في هذا التكوين. يمكنك أخذ نموذج configmap من مستودع git hub أعلاه، وإضافة مهام القصاصة التي قد تحتاجها وتطبيق/توزيع خريطة التكوين إلى kube-system مساحة الاسم لنظام المجموعة. على الرغم من أن هذا مدعوم، يرجى ملاحظة أن الطريقة الموصى بها لاستخراج الأهداف المخصصة هي استخدام الموارد المخصصة
  3. ama-metrics-prometheus-config-node (متقدم) يمكن استخدام خريطة التكوين هذه لتوفير تكوين استخراج Prometheus ل addon DaemonSet الذي يعمل على كل عقدة Linux في نظام المجموعة، ويمكن استخراج أي أهداف على مستوى العقدة على كل عقدة عن طريق توفير مهام كشط في هذا التكوين. عند استخدام خريطة التكوين هذه، يمكنك استخدام $NODE_IP متغير في تكوين الكشط، والذي يتم استبداله بعنوان ip الخاص بالعقدة المقابلة في DaemonSet pod الذي يعمل على كل عقدة. بهذه الطريقة يمكنك الوصول إلى استخراج أي شيء يتم تشغيله على تلك العقدة من المقاييس addon DaemonSet. يرجى توخي الحذر عند استخدام الاكتشافات في تكوين الكشط في خريطة التكوين على مستوى العقدة هذه، حيث ستقوم كل عقدة في المجموعة بإعداد واكتشاف الهدف (الأهداف) وستجمع مقاييس زائدة عن الحاجة. يمكنك أخذ نموذج configmap من git hub repo أعلاه، وإضافة مهام القصاصة التي قد تحتاجها وتطبيق/ توزيع خريطة التكوين إلى kube-system مساحة الاسم لنظام المجموعة الخاص بك
  4. ama-metrics-prometheus-config-node-windows (متقدم) يمكن استخدام خريطة التكوين هذه لتوفير تكوين استخراج Prometheus ل addon DaemonSet الذي يعمل على كل عقدة Windows في نظام المجموعة، ويمكن استخراج أهداف مستوى العقدة على كل عقدة عن طريق توفير مهام كشط في هذا التكوين. عند استخدام خريطة التكوين هذه، يمكنك استخدام $NODE_IP متغير في تكوين القصاصة الخاص بك، والذي سيتم استبداله بعنوان ip الخاص بالعقدة المقابلة في DaemonSet pod الذي يعمل على كل عقدة. بهذه الطريقة يمكنك الوصول إلى استخراج أي شيء يتم تشغيله على تلك العقدة من المقاييس addon DaemonSet. يرجى توخي الحذر عند استخدام الاكتشافات في تكوين الكشط في خريطة التكوين على مستوى العقدة هذه، حيث ستقوم كل عقدة في المجموعة بإعداد واكتشاف الهدف (الأهداف) وستجمع مقاييس زائدة عن الحاجة. يمكنك أخذ نموذج configmap من git hub repo أعلاه، وإضافة مهام القصاصة التي قد تحتاجها وتطبيق/ توزيع خريطة التكوين إلى kube-system مساحة الاسم لنظام المجموعة الخاص بك

تعريفات الموارد المخصصة

تدعم الوظيفة الإضافية لمقاييس Azure Monitor استخراج مقاييس Prometheus باستخدام Prometheus - Pod Monitors وService Monitors، على غرار عامل تشغيل OSS Prometheus. سيؤدي تمكين الوظيفة الإضافية إلى نشر تعريفات الموارد المخصصة ل Pod وService Monitor للسماح لك بإنشاء مواردك المخصصة. اتبع الإرشادات لإنشاء موارد مخصصة وتطبيقها على نظام المجموعة.

تكوين إعدادات الوظيفة الإضافية للمقاييس

يمكن تنزيل ama-metrics-settings-configmap وتحريره وتطبيقه على نظام المجموعة لتخصيص الميزات الجاهزة للوظيفة الإضافية للمقاييس.

تمكين الأهداف الافتراضية وتعطيلها

يحتوي الجدول التالي على قائمة بجميع الأهداف الافتراضية التي يمكن للوظيفة الإضافية لمقاييس Azure Monitor استخراجها بشكل افتراضي وما إذا كان قد تم تمكينها في البداية. يتم استخراج الأهداف الافتراضية كل 30 ثانية. يتم نشر نسخة متماثلة لاستخراج أهداف على مستوى المجموعة مثل kube-state-metrics. يتم أيضا نشر DaemonSet لاستخراج أهداف على مستوى العقدة مثل kubelet.

المفتاح النوع مُمَكّن وحدة ‏‏الوصف
Kubelet منطقي true Linux DaemonSet استخراج kubelet في كل عقدة في مجموعة K8s دون أي تكوين كشط إضافي.
cadvisor منطقي true Linux DaemonSet استخراج cadvisor في كل عقدة في مجموعة K8s دون أي تكوين كشط إضافي.
Linux فقط.
kubestate منطقي true نسخة متماثلة من Linux استخراج kube-state-metrics في مجموعة K8s (المثبتة كجزء من الوظيفة الإضافية) دون أي تكوين كشط إضافي.
nodeexporter منطقي true Linux DaemonSet استخراج مقاييس العقدة دون أي تكوين كشط إضافي.
Linux فقط.
coredns منطقي false نسخة متماثلة من Linux كشط خدمة coredns في مجموعة K8s دون أي تكوين كشط إضافي.
kubeproxy منطقي false Linux DaemonSet استخراج kube-proxy في كل عقدة Linux تم اكتشافها في مجموعة K8s دون أي تكوين كشط إضافي.
Linux فقط.
خادم واجهة برمجة التطبيقات منطقي false نسخة متماثلة من Linux استخراج خادم Kubernetes API في نظام مجموعة K8s دون أي تكوين كشط إضافي.
windowsexporter منطقي false Windows DaemonSet استخراج مصدر النوافذ في كل عقدة في مجموعة K8s دون أي تكوين كشط إضافي.
نظام تشغيل Windows فقط.
windowskubeproxy منطقي false Windows DaemonSet استخراج windows-kube-proxy في كل عقدة في مجموعة K8s دون أي تكوين كشط إضافي.
نظام تشغيل Windows فقط.
prometheuscollectorhealth منطقي false نسخة متماثلة من Linux استخراج معلومات حول حاوية prometheus-collector، مثل مقدار وحجم السلسلة الزمنية التي تم استخراجها.

إذا كنت تريد تشغيل استخراج الأهداف الافتراضية التي لم يتم تمكينها بشكل افتراضي، فقم بتحرير configmapama-metrics-settings-configmap لتحديث الأهداف المدرجة ضمن default-scrape-settings-enabled إلى true. تطبيق configmap على نظام المجموعة الخاص بك.

تمكين الاستخراج المستند إلى التعليق التوضيحي للجراب

لاستخراج جرابات التطبيق دون الحاجة إلى إنشاء تكوين Prometheus مخصص، يمكن إضافة التعليقات التوضيحية إلى pods. مطلوب التعليق التوضيحي prometheus.io/scrape: "true" للجراب ليتم استخراجه. التعليقات التوضيحية prometheus.io/path والإشارة prometheus.io/port إلى المسار والمنفذ الذي تتم استضافة المقاييس فيه على الجراب. ستكون التعليقات التوضيحية للحجيرة التي تستضيف المقاييس في <pod IP>:8080/metrics :

metadata:   
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/path: '/metrics'
    prometheus.io/port: '8080'

يتم تعطيل استخراج هذه القرون مع تعليقات توضيحية محددة بشكل افتراضي. لتمكين، في ، أضف regex لمساحة (مساحات) الاسم الخاصة بالقرون مع التعليقات التوضيحية التي ترغب في ama-metrics-settings-configmapاستخراجها كقيمة للحقل podannotationnamespaceregex.

على سبيل المثال، يتخلص الإعداد التالي من الجرابات مع التعليقات التوضيحية فقط في مساحات kube-system الأسماء و my-namespace:

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = "kube-system|my-namespace"

لتمكين استخراج الجرابات مع التعليقات التوضيحية في جميع مساحات الأسماء، استخدم:

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = ".*"

تحذير

يمكن أن يؤدي استخراج التعليقات التوضيحية للجراب من العديد من مساحات الأسماء إلى إنشاء حجم كبير جدا من المقاييس اعتمادا على عدد القرون التي تحتوي على تعليقات توضيحية.

تخصيص المقاييس التي تم جمعها حسب الأهداف الافتراضية

بشكل افتراضي، بالنسبة لجميع الأهداف الافتراضية، يتم استيعاب الحد الأدنى فقط من المقاييس المستخدمة في قواعد التسجيل الافتراضية والتنبيهات ولوحات معلومات Grafana كما هو موضح في الحد الأدنى من ملف تعريف الاستيعاب. لتجميع جميع المقاييس من الأهداف الافتراضية، قم بتحديث قوائم الاحتفاظ في تكوين الإعدادات ضمن default-targets-metrics-keep-list، ثم قم بتعيين minimalingestionprofile إلى false.

للسماح بإدراج المزيد من المقاييس بالإضافة إلى المقاييس الافتراضية المدرجة ليتم السماح بها، لأي أهداف افتراضية، قم بتحرير الإعدادات الموجودة ضمن default-targets-metrics-keep-list للمهمة المقابلة التي تريد تغييرها.

على سبيل المثال، kubelet هو إعداد تصفية المقياس ل kubelet الهدف الافتراضي. استخدم البرنامج النصي التالي للتصفية في المقاييس التي تم جمعها للأهداف الافتراضية باستخدام التصفية المستندة إلى regex.

kubelet = "metricX|metricY"
apiserver = "mymetric.*"

إشعار

إذا كنت تستخدم علامات اقتباس أو علامات مائلة عكسية في regex، فستحتاج إلى الهروب منها باستخدام الخط المائل المائل عكسيا مثل الأمثلة "test\'smetric\"s\"" و testbackslash\\*.

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

الاسم المستعار لنظام المجموعة

تستخدم تسمية نظام المجموعة الملحقة بكل سلسلة زمنية تم استخراجها الجزء الأخير من معرف مورد Azure Resource Manager الكامل لنظام مجموعة AKS. على سبيل المثال، إذا كان معرف المورد هو /subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclustername، فإن تسمية نظام المجموعة هي myclustername.

لتجاوز تسمية نظام المجموعة في السلسلة الزمنية التي تم استخراجها، قم بتحديث الإعداد cluster_alias إلى أي سلسلة ضمن prometheus-collector-settings في configmapama-metrics-settings-configmap. يمكنك إنشاء هذا التكوين إذا لم يكن موجودا في نظام المجموعة أو يمكنك تحرير التكوين الموجود إذا كان موجودا بالفعل في نظام المجموعة الخاص بك.

تظهر التسمية الجديدة أيضا في القائمة المنسدلة لمعلمة نظام المجموعة في لوحات معلومات Grafana بدلا من التسمية الافتراضية.

إشعار

يسمح فقط بالأحرف الأبجدية الرقمية. يتم استبدال أي أحرف أخرى ب _. هذا التغيير هو للتأكد من أن المكونات المختلفة التي تستهلك هذه التسمية تلتزم بالاصطلاح الأبجدي الرقمي الأساسي.

وضع تصحيح الأخطاء

تحذير

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

لعرض كل مقياس يتم استخراجه لأغراض تصحيح الأخطاء، يمكن تكوين عامل المقاييس الإضافي للتشغيل في وضع التصحيح عن طريق تحديث الإعداد إلى ضمن الإعداد في configmapama-metrics-settings-configmap.debug-modetrueenabled يمكنك إما إنشاء خريطة التكوين هذه أو تحرير خريطة موجودة. لمزيد من المعلومات، راجع قسم وضع تتبع الأخطاء في استكشاف أخطاء مجموعة مقاييس Prometheus وإصلاحها.

استخراج إعدادات الفاصل الزمني

لتحديث إعدادات الفاصل الزمني للاستخراج لأي هدف، يمكنك تحديث المدة في الإعداد default-targets-scrape-interval-settings لهذا الهدف في configmapama-metrics-settings-configmap. يجب عليك تعيين الفواصل الزمنية للاستخراج بالتنسيق الصحيح المحدد في موقع الويب هذا. وإلا، يتم تطبيق القيمة الافتراضية البالغة 30 ثانية على الأهداف المقابلة. على سبيل المثال - إذا كنت تريد تحديث الفاصل الزمني للاستخراج للمهمة kubelet إلى 60s ثم يمكنك تحديث القسم التالي في YAML:

default-targets-scrape-interval-settings: |-
    kubelet = "60s"
    coredns = "30s"
    cadvisor = "30s"
    kubeproxy = "30s"
    apiserver = "30s"
    kubestate = "30s"
    nodeexporter = "30s"
    windowsexporter = "30s"
    windowskubeproxy = "30s"
    kappiebasic = "30s"
    prometheuscollectorhealth = "30s"
    podannotations = "30s"

وتطبيق YAML باستخدام الأمر التالي: kubectl apply -f .\ama-metrics-settings-configmap.yaml

تكوين مهام استخراج Prometheus المخصصة

يمكنك استخراج مقاييس Prometheus باستخدام Prometheus - Pod Monitors وService Monitors(Recommended)، على غرار عامل تشغيل OSS Prometheus. اتبع الإرشادات لإنشاء موارد مخصصة وتطبيقها على نظام المجموعة.

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

نصائح وأمثلة حول تكوين Prometheus

تعرف على بعض التلميحات من الأمثلة في هذا القسم.

استخدم قوالب Pod وService Monitor واتبع مواصفات واجهة برمجة التطبيقات لإنشاء مواردك المخصصة (PodMonitor وService Monitor). لاحظ أن التغيير الوحيد المطلوب ل OSS CRs الحالي لاستلامه بواسطة Prometheus المدار هو مجموعة واجهة برمجة التطبيقات - azmonitoring.coreos.com/v1. انظر هنا لمعرفة المزيد

إشعار

عند فشل تطبيق تكوين الكشط المخصص بسبب أخطاء التحقق من الصحة، يستمر استخدام تكوين القصاصة الافتراضي.

إذا كنت ترغب في استخدام الإعدادات العمومية التي تنطبق على جميع مهام القصاصات، ولديك موارد مخصصة فقط، فستظل بحاجة إلى إنشاء تكوين مع الإعدادات العمومية فقط (الإعدادات لكل منها في الموارد المخصصة ستتجاوز تلك الموجودة في القسم العمومي)

تكوينات الكشط

حاليا، الأساليب المدعومة لاكتشاف الهدف للموارد المخصصة هي pod ومراقبة الخدمة

Pod وService Monitors

الأهداف المكتشفة باستخدام pod وشاشات الخدمة لها تسميات مختلفة __meta_* اعتمادا على جهاز العرض المستخدم. يمكنك استخدام التسميات في relabelings القسم لتصفية الأهداف أو استبدال التسميات للأهداف.

راجع أمثلة Pod وService Monitor من pod وservice monitors.

إعادة تسمية

relabelings يتم تطبيق القسم في وقت اكتشاف الهدف وينطبق على كل هدف للوظيفة. توضح الأمثلة التالية طرق استخدام relabelings.

إضافة تسمية

أضف تسمية جديدة تسمى example_label بالقيمة example_value إلى كل مقياس للوظيفة. استخدم __address__ كتسمية المصدر فقط لأن هذه التسمية موجودة دائما وتضيف التسمية لكل هدف من أهداف الوظيفة.

relabelings:
- sourceLabels: [__address__]
  targetLabel: example_label
  replacement: 'example_value'

استخدام تسميات Pod أو Service Monitor

الأهداف المكتشفة باستخدام pod وشاشات الخدمة لها تسميات مختلفة __meta_* اعتمادا على جهاز العرض المستخدم. __* يتم إسقاط التسميات بعد اكتشاف الأهداف. للتصفية باستخدامها على مستوى المقاييس، احتفظ بها أولا باستخدام relabelings عن طريق تعيين اسم تسمية. ثم استخدم metricRelabelings للتصفية.

# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabelings:
- sourceLabels: [__meta_kubernetes_namespace]
  action: replace
  targetLabel: kubernetes_namespace

# Keep only metrics with the kubernetes namespace 'default'
metricRelabelings:
- sourceLabels: [kubernetes_namespace]
  action: keep
  regex: 'default'

إعادة تسمية الوظيفة والمثيل

يمكنك تغيير قيم التسمية job و instance استنادا إلى التسمية المصدر، تماما مثل أي تسمية أخرى.

# Replace the job name with the pod label 'k8s app'
relabelings:
- sourceLabels: [__meta_kubernetes_pod_label_k8s_app]
  targetLabel: job

# Replace the instance name with the node name. This is helpful to replace a node IP
# and port with a value that is more readable
relabelings:
- sourceLabels: [__meta_kubernetes_node_name]]
  targetLabel: instance

إعادة تسمية القياس

يتم تطبيق عمليات إعادة تسمية القياس بعد الاستخراج وقبل الاستيعاب. metricRelabelings استخدم القسم لتصفية المقاييس بعد الكشط. توضح الأمثلة التالية كيفية القيام بذلك.

إسقاط المقاييس حسب الاسم

# Drop the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
  action: drop
  regex: 'example_metric_name'

الاحتفاظ بمقاييس معينة فقط حسب الاسم

# Keep only the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
  action: keep
  regex: 'example_metric_name'

# Keep only metrics that start with 'example_'
metricRelabelings:
- sourceLabels: [__name__]
  action: keep
  regex: '(example_.*)'

إعادة تسمية المقاييس

إعادة تسمية القياس غير مدعومة.

تصفية المقاييس حسب التسميات

# Keep metrics only where example_label = 'example'
metricRelabelings:
- sourceLabels: [example_label]
  action: keep
  regex: 'example'

# Keep metrics only if `example_label` equals `value_1` or `value_2`
metricRelabelings:
- sourceLabels: [example_label]
  action: keep
  regex: '(value_1|value_2)'

# Keep metrics only if `example_label_1 = value_1` and `example_label_2 = value_2`
metricRelabelings:
- sourceLabels: [example_label_1, example_label_2]
  separator: ';'
  action: keep
  regex: 'value_1;value_2'

# Keep metrics only if `example_label` exists as a label
metricRelabelings:
- sourceLabels: [example_label_1]
  action: keep
  regex: '.+'

استخراج يستند إلى TLS

إذا كان لديك مثيل Prometheus يتم تقديمه مع TLS وتريد استخراج المقاييس منه، فأنت بحاجة إلى تعيين مخطط إلى https وتعيين إعدادات TLS في configmap أو CRD المعني. يمكنك استخدام tls_config خاصية التكوين داخل مهمة استخراج مخصصة لتكوين إعدادات TLS إما باستخدام CRD أو configmap. تحتاج إلى توفير شهادة CA للتحقق من صحة شهادة خادم API باستخدام. يتم استخدام شهادة المرجع المصدق للتحقق من صحة شهادة الخادم عندما يتصل Prometheus بالهدف عبر TLS. يساعد على التأكد من أن شهادة الخادم موقعة من قبل مرجع موثوق به.

يجب إنشاء السر في مساحة اسم نظام kube ثم يجب إنشاء configmap/CRD في مساحة اسم نظام kube. ترتيب إنشاء البيانات السرية مهم. عندما لا يكون هناك سر ولكن خريطة CRD/config صالحة، ستجد أخطاء في سجل المجمع ->no file found for cert....

فيما يلي تفاصيل حول كيفية توفير إعدادات تكوين TLS من خلال configmap أو CRD.

  • لتوفير إعداد تكوين TLS في configmap، يرجى إنشاء الشهادة الموقعة ذاتيا والمفتاح داخل تطبيق mtls الممكن. يجب أن يبدو مثال tlsConfig داخل خريطة التكوين كما يلي:
tls_config:
    ca_file: /etc/prometheus/certs/client-cert.pem
    cert_file: /etc/prometheus/certs/client-cert.pem
    key_file: /etc/prometheus/certs/client-key.pem
    insecure_skip_verify: false
  • لتوفير إعداد تكوين TLS في CRD، يرجى إنشاء الشهادة الموقعة ذاتيا والمفتاح داخل تطبيق mtls الممكن. يجب أن يبدو مثال tlsConfig داخل Podmonitor كما يلي:
tlsConfig:
    ca:
        secret:
        key: "client-cert.pem" # since it is self-signed
        name: "ama-metrics-mtls-secret"
    cert:
        secret:
        key: "client-cert.pem"
        name: "ama-metrics-mtls-secret"
    keySecret:
        key: "client-key.pem"
        name: "ama-metrics-mtls-secret"
    insecureSkipVerify: false

إشعار

تأكد من أن اسم ملف الشهادة واسم المفتاح داخل تطبيق mtls بالتنسيق التالي في حالة الاستخراج المستند إلى CRD. على سبيل المثال: secret_kube-system_ama-metrics-mtls-secret_cert-name.pem و secret_kube-system_ama-metrics-mtls-secret_key-name.pem. يجب إنشاء CRD في مساحة اسم نظام kube. يجب أن يكون الاسم السري بالضبط ama-metrics-mtls-secret في مساحة اسم نظام kube. مثال على الأمر لإنشاء البيانات السرية: kubectl إنشاء سر عام ama-metrics-mtls-secret --from-file=secret_kube-system_ama-metrics-mtls-secret_client-cert.pem=secret_kube-system_ama-metrics-mtls-secret_client-cert.pem --from-file=secret_kube-system_ama-metrics-mtls-secret_client-key.pem=secret_kube-system_ama-metrics-mtls-secret_client-key.pem -n kube-system

لقراءة المزيد حول مصادقة TLS، قد تكون المستندات التالية مفيدة.

المصادقة الأساسية

إذا كنت تستخدم basic_auth الإعداد في تكوين prometheus الخاص بك، يرجى اتباع الخطوات -

  1. إنشاء سر في مساحة اسم نظام kube المسماة ama-metrics-mtls-secret

قيمة password1 هي base64encoded يمكن أن تكون كلمة المرور الرئيسية 1 أي شيء، ولكنها تحتاج فقط إلى مطابقة password_file مسار الملف الخاص بك.

apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  password1: <base64-encoded-string>
  1. في configmap لتكوين القصاصة المخصصة، استخدم الإعداد التالي -
basic_auth:
  username: admin
  password_file: /etc/prometheus/certs/password1

إشعار

تأكد من أن الاسم هو ama-metrics-mtls-secret وأنه في مساحة اسم نظام kube.

المسار /etc/prometheus/certs/ إلزامي، ولكن password1 يمكن أن يكون أي سلسلة ويحتاج إلى مطابقة مفتاح البيانات في السر الذي تم إنشاؤه أعلاه. وذلك لأن البيانات السرية ama-metrics-mtls-secret مثبتة في المسار /etc/prometheus/certs/ داخل الحاوية.

يتم فك ترميز القيمة المرمزة base64 تلقائيا بواسطة جرابات العامل عند تحميل السر كملف.

يحتاج أي إعداد تكوين آخر للتخويل الذي يعتبر سرا في تكوين prometheus إلى استخدام بديل إعداد الملف بدلا من ذلك كما هو موضح أعلاه.

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

إعداد التنبيهات على مقاييس Prometheus
الاستعلام عن مقاييس Prometheus
تعرف على المزيد حول جمع مقاييس Prometheus