مشاركة عبر

تخصيص استخراج مقاييس 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، مثل مقدار وحجم السلسلة الزمنية التي تم استخراجها.

إذا كنت تريد تشغيل استخراج الأهداف الافتراضية التي لم يتم تمكينها بشكل افتراضي، فقم بتحرير configmap ama-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"

تحذير

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

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

بشكل افتراضي، بالنسبة لجميع الأهداف الافتراضية، يتم استيعاب الحد الأدنى فقط من المقاييس المستخدمة في قواعد التسجيل الافتراضية والتنبيهات ولوحات معلومات 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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. انظر هنا لمعرفة المزيد

إشعار

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

الإعدادات العمومية

تنسيق التكوين للإعدادات العمومية هو نفسه الذي يدعمه تكوين OSS prometheus

global:
  scrape_interval: <duration>
  scrape_timeout: <duration>
  external_labels:
    <labelname1>: <labelvalue>
    <labelname2>: <labelvalue>
scrape_configs:
  - <job-x>
  - <job-y>

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

إشعار

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

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

حاليا، الأساليب المدعومة لاكتشاف الهدف للموارد المخصصة هي 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: '.+'

المصادقة الأساسية والرموز المميزة للحامل

لاستخدام basic_auth الإعدادات أو bearer_token في تكوين prometheus، اتبع الخطوات التالية:

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

    يمكن أن يكون اسم المفتاح password1 أي شيء طالما أنه يطابق اسم الملف في password_file مسار الملف في تكوين استخراج Prometheus في الخطوة التالية. يجب أن تكون قيمة المفتاح مرمزة ب base64.

    apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  password1: <base64-encoded-string>

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

  2. ثم، في تكوين القصاصة المخصصة في configmap، قم بتوفير مسار الملف:

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

    username يجب أن يحتوي الحقل على سلسلة اسم المستخدم الفعلية. password_file يجب أن يحتوي الحقل على المسار إلى الملف الذي يحتوي على كلمة المرور.

    # Sets the `Authorization` header on every scrape request with the
# configured username and password.
basic_auth:
  username: <username string>
  password_file: /etc/prometheus/certs/password1

    الرمز المميز للحامل

    bearer_token_file يجب أن يحتوي الحقل على المسار إلى الملف الذي يحتوي على الرمز المميز.

    # Sets the `Authorization` header on every scrape request with the bearer token
# read from the configured file. It is mutually exclusive with `bearer_token`.
bearer_token_file: /etc/prometheus/certs/password1

يمكن العثور على مزيد من المعلومات حول هذه الإعدادات في وثائق scrape_config Prometheus.

إذا كنت تستخدم كل من المصادقة الأساسية ومصادقة TLS، فراجع القسم أدناه. لمزيد من التفاصيل، راجع قسم الملاحظة أدناه.

الكشط المستند إلى TLS

إذا كنت ترغب في استخراج مقاييس Prometheus من نقطة نهاية https، يجب أن يكون تكوين Prometheus أو PodMonitor أو ServiceMonitor معينا scheme إلى https إعدادات TLS إضافية.

  1. إنشاء سر في مساحة الاسم المسماة kube-systemama-metrics-mtls-secret. سيتم تحميل كل زوج من قيم المفاتيح المحددة في قسم البيانات للكائن السري كملف منفصل في موقع /etc/prometheus/certs هذا مع أسماء الملفات التي هي نفسها المفاتيح المحددة في قسم البيانات. يجب أن تكون القيم السرية مرمزة ب base64.

    فيما يلي مثال على YAML للبيانات السرية:

    apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  <certfile>: base64_cert_content    
  <keyfile>: base64_key_content

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

  2. بعد ذلك، في تكوين Prometheus أو PodMonitor أو ServiceMonitor، قم بتوفير مسار الملف:

  • لتوفير إعداد تكوين TLS في configmap، اتبع المثال التالي:
tls_config:
   # CA certificate to validate API server certificate with.
   ca_file: /etc/prometheus/certs/<certfile>

   # Certificate and key files for client cert authentication to the server.
   cert_file: /etc/prometheus/certs/<certfile>
   key_file: /etc/prometheus/certs/<keyfile>

   # Disable validation of the server certificate.
   insecure_skip_verify: false

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

إذا كنت ترغب في استخدام كل من الإعدادات الأساسية وإعدادات مصادقة TLS في configmap/CRD، فتأكد من أن السر ama-metrics-mtls-secret يتضمن جميع المفاتيح ضمن قسم البيانات مع القيم المتطابقة المرمزة base64، كما هو موضح أدناه:

apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  certfile: base64_cert_content    # used for TLS
  keyfile: base64_key_content      # used for TLS
  password1: base64-encoded-string # used for basic auth
  password2: base64-encoded-string # used for basic auth

إشعار

إشعار

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

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

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

يجب إنشاء السر أولا، ثم يجب إنشاء configmap أو PodMonitor أو ServiceMonitor في kube-system مساحة الاسم. ترتيب إنشاء البيانات السرية مهم. عندما لا يكون هناك سر ولكن configmap أو PodMonitor أو ServiceMonitor يشير إلى السر، سيكون الخطأ التالي في سجلات حاوية ama-metrics prometheus-collector: no file found for cert....

لقراءة المزيد حول إعدادات تكوين TLS، يرجى اتباع هذه التكوينات.

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

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