تخصيص استخراج مقاييس 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"

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

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 في configmap ama-metrics-settings-configmap. يمكنك إنشاء هذا التكوين إذا لم يكن موجودا في نظام المجموعة أو يمكنك تحرير التكوين الموجود إذا كان موجودا بالفعل في نظام المجموعة الخاص بك.

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

إشعار

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

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

تحذير

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

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

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

لتحديث إعدادات الفاصل الزمني للاستخراج لأي هدف، يمكنك تحديث المدة في الإعداد default-targets-scrape-interval-settings لهذا الهدف في configmap ama-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

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

التكوين باستخدام CRD لتكوين كشط مخصص

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

ملف التكوين لتكوين كشط مخصص

تنسيق التكوين هو نفس ملف تكوين Prometheus. حاليا، يتم دعم الأقسام التالية:

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

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

راجع قسم Apply config file لإنشاء configmap من تكوين Prometheus.

إشعار

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

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

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

استخراج التكوينات باستخدام CRD

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

استخراج التكوينات باستخدام ملف التكوين

حاليا، الأساليب المدعومة لاكتشاف الهدف لتكوين كشط إما static_configs أو kubernetes_sd_configs لتحديد الأهداف أو اكتشافها.

تكوين ثابت

يحتوي التكوين الثابت على قائمة بالأهداف الثابتة وأي تسميات إضافية لإضافتها إليها.

scrape_configs:
  - job_name: example
    - targets: [ '10.10.10.1:9090', '10.10.10.2:9090', '10.10.10.3:9090' ... ]
    - labels: [ label1: value1, label1: value2, ... ]

تكوين اكتشاف خدمة Kubernetes

الأهداف المكتشفة باستخدام kubernetes_sd_configs كل منها لها تسميات مختلفة __meta_* اعتمادا على الدور المحدد. يمكنك استخدام التسميات في relabel_configs القسم لتصفية الأهداف أو استبدال التسميات للأهداف.

راجع أمثلة Prometheus لتكوينات الكشط لمجموعة Kubernetes.

تكوينات إعادة تسمية

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

إضافة تسمية

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

relabel_configs:
- source_labels: [__address__]
  target_label: example_label
  replacement: 'example_value'

استخدام تسميات اكتشاف خدمة Kubernetes

إذا كانت الوظيفة تستخدم kubernetes_sd_configs لاكتشاف الأهداف، فإن لكل دور تسميات مرتبطة __meta_* بالمقاييس. __* يتم إسقاط التسميات بعد اكتشاف الأهداف. للتصفية باستخدامها على مستوى المقاييس، احتفظ بها أولا باستخدام relabel_configs عن طريق تعيين اسم تسمية. ثم استخدم metric_relabel_configs للتصفية.

# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
  action: replace
  target_label: kubernetes_namespace

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

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

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

# Replace the job name with the pod label 'k8s app'
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_k8s_app]
  target_label: 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
relabel_configs:
- source_labels: [__meta_kubernetes_node_name]]
  target_label: instance

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

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

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

# Drop the metric named 'example_metric_name'
metric_relabel_configs:
- source_labels: [__name__]
  action: drop
  regex: 'example_metric_name'

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

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

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

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

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

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

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

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

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

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

إشعار

إذا كنت ترغب في إضافة تسميات إلى جميع المهام في التكوين المخصص، أضف تسميات بشكل صريح باستخدام metrics_relabel_configs لكل مهمة. التسميات الخارجية العمومية غير مدعومة عبر تكوين prometheus المستند إلى configmap.

relabel_configs:
- source_labels: [__address__]
  target_label: example_label
  replacement: 'example_value'

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

استخراج التكوينات باستخدام ملف التكوين

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

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

قيمة password1 هي base64encoded.

يمكن أن يكون مفتاح password1 أي شيء، ولكنه يحتاج فقط إلى مطابقة تكوين القصاصة password_file filepath.

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. سيكون المفتاح ( ex - password1) في المثال أعلاه هو اسم الملف والقيمة هي base64 التي تم فك ترميزها وإضافتها إلى محتويات الملف داخل الحاوية ويستخدم قشطة prometheus محتويات هذا الملف للحصول على القيمة المستخدمة ككلمة مرور تستخدم لاستخراج نقطة النهاية.

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

basic_auth:
  username: <username string>
  password_file: /etc/prometheus/certs/password1

من خلال توفير المسار إلى password_file أعلاه، يستخدم كشط prometheus محتويات الملف المسمى password1 في المسار /etc/prometheus/certs كقيمة لكلمة المرور لاستخراج المستندة إلى المصادقة الأساسية.

استخراج التكوينات باستخدام CRD(Pod/Service Monitor)

لا يتم حاليا دعم استخراج الأهداف باستخدام المصادقة الأساسية باستخدام شاشات pod/service. ستتم إضافة دعم هذا في الإصدارات القادمة.

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

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

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

1. إنشاء سر في مساحة اسم نظام kube المسماة ama-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. سيكون المفتاح ( ex - certfile) في المثال أعلاه هو اسم الملف والقيمة هي base64 التي تم فك ترميزها وإضافتها إلى محتويات الملف داخل الحاوية ويستخدم قشطة prometheus محتويات هذا الملف للحصول على القيمة المستخدمة ككلمة مرور تستخدم لاستخراج نقطة النهاية.

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

استخراج التكوين باستخدام ملف التكوين

• لتوفير إعداد تكوين TLS في configmap، يرجى اتباع المثال أدناه.

tls_config:
    ca_file: /etc/prometheus/certs/<certfile> # since it is self-signed
    cert_file: /etc/prometheus/certs/<certfile>
    key_file: /etc/prometheus/certs/<keyfile>
    insecure_skip_verify: false

استخراج التكوين باستخدام CRD(Pod/Service Monitor)

• لتوفير إعداد تكوين TLS في CRD(Pod/Service Monitor)، يرجى اتباع المثال أدناه.

 tlsConfig:
   ca:
     secret:
       key: "<certfile>" # since it is self-signed
       name: "ama-metrics-mtls-secret"
   cert:
     secret:
       key: "<certfile>"
       name: "ama-metrics-mtls-secret"
   keySecret:
       key: "<keyfile>"
       name: "ama-metrics-mtls-secret"
   insecureSkipVerify: false

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

إذا كنت ترغب في استخدام كل من إعدادات المصادقة الأساسية وإعدادات مصادقة Tls في configmap/CRD، فتأكد فقط من أن البيانات السرية ama-metrics-mtls-secret تتضمن جميع الملفات (المفاتيح) ضمن قسم البيانات مع القيم المشفرة الأساسية 64 المقابلة لها، كما هو موضح أدناه.

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 تلقائيا بواسطة جرابات العامل عند تحميل السر كملف.

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

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

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

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

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