قم بتكوين المقاييس والسجلات المحلية للبوابة ذاتية الاستضافة إدارة واجهة برمجة التطبيقات Azure
ينطبق على: المطور | قسط
توفر هذه المقالة تفاصيل لتكوين المقاييس والسجلات المحلية للبوابة المستضافة ذاتيا المنشورة على مجموعة Kubernetes. لتكوين مقاييس السحابة وسجلاتها، راجع هذه المقالة.
المقاييس
تدعم البوابة المستضافة ذاتيا StatsD، والذي أصبح بروتوكولا توحيديا لجمع المقاييس وتجميعها. يستعرض هذا القسم خطوات نشر StatsD إلى Kubernetes، وتكوين البوابة لإرسال المقاييس عبر StatsD، واستخدام Prometheus لمراقبة المقاييس.
انشر StatsD وPrometheus في المجموعة
يقوم نموذج تكوين YAML التالي بنشر StatsD وPrometheus إلى مجموعة Kubernetes حيث يتم نشر بوابة مستضافة ذاتيا. كما أنه ينشئ خدمة لكل منها. ثم تنشر البوابة المستضافة ذاتيا المقاييس إلى خدمة StatsD. سنصل إلى لوحة معلومات Prometheus عبر خدمتها.
إشعار
يسحب المثال التالي صور حاوية عامة من Docker Hub. نوصي بتعيين سحب سري للإثبات باستخدام حساب Docker Hub بدلاً من إجراء طلب سحب مجهول. لتحسين الموثوقية عند العمل مع المحتوى العام، قم باستيراد الصور وإدارتها في سجل حاوية Azure خاص. تعرف على المزيد حول العمل مع الصور العامة.
apiVersion: v1
kind: ConfigMap
metadata:
name: sputnik-metrics-config
data:
statsd.yaml: ""
prometheus.yaml: |
global:
scrape_interval: 3s
evaluation_interval: 3s
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'test_metrics'
static_configs:
- targets: ['localhost:9102']
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: sputnik-metrics
spec:
replicas: 1
selector:
matchLabels:
app: sputnik-metrics
template:
metadata:
labels:
app: sputnik-metrics
spec:
containers:
- name: sputnik-metrics-statsd
image: prom/statsd-exporter
ports:
- name: tcp
containerPort: 9102
- name: udp
containerPort: 8125
protocol: UDP
args:
- --statsd.mapping-config=/tmp/statsd.yaml
- --statsd.listen-udp=:8125
- --web.listen-address=:9102
volumeMounts:
- mountPath: /tmp
name: sputnik-metrics-config-files
- name: sputnik-metrics-prometheus
image: prom/prometheus
ports:
- name: tcp
containerPort: 9090
args:
- --config.file=/tmp/prometheus.yaml
volumeMounts:
- mountPath: /tmp
name: sputnik-metrics-config-files
volumes:
- name: sputnik-metrics-config-files
configMap:
name: sputnik-metrics-config
---
apiVersion: v1
kind: Service
metadata:
name: sputnik-metrics-statsd
spec:
type: NodePort
ports:
- name: udp
port: 8125
targetPort: 8125
protocol: UDP
selector:
app: sputnik-metrics
---
apiVersion: v1
kind: Service
metadata:
name: sputnik-metrics-prometheus
spec:
type: LoadBalancer
ports:
- name: http
port: 9090
targetPort: 9090
selector:
app: sputnik-metrics
احفظ التكوينات إلى ملف يسمى metrics.yaml. استخدم الأمر التالي لنشر كل شيء إلى نظام المجموعة:
kubectl apply -f metrics.yaml
بمجرد انتهاء النشر، قم بتشغيل الأمر التالي للتحقق من تشغيل Pods. سيكون اسم جرابك مختلفًا.
kubectl get pods
NAME READY STATUS RESTARTS AGE
sputnik-metrics-f6d97548f-4xnb7 2/2 Running 0 1m
قم بتشغيل الأمر أدناه للتحقق من services أن قيد التشغيل. دون ملاحظة عن CLUSTER-IP و PORT لخدمة StatsD، التي نستخدمها لاحقا. يمكنك زيارة لوحة معلومات Prometheus باستخدام EXTERNAL-IP و PORT.
kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
sputnik-metrics-prometheus LoadBalancer 10.0.252.72 13.89.141.90 9090:32663/TCP 18h
sputnik-metrics-statsd NodePort 10.0.41.179 <none> 8125:32733/UDP 18h
قم بتكوين البوابة ذاتية الاستضافة لإرسال المقاييس
الآن بعد نشر كل من StatsD وPrometheus، يمكننا تحديث تكوينات البوابة المستضافة ذاتيا لبدء إصدار المقاييس من خلال StatsD. يمكن تمكين الميزة أو تعطيلها باستخدام telemetry.metrics.local المفتاح في ConfigMap لنشر البوابة المستضافة ذاتيا مع خيارات إضافية. فيما يلي الخيارات المتاحة:
| الحقل | Default | الوصف |
|---|---|---|
| القياس عن بعد. metrics.local | none |
تمكن من تسجيل الدخول من خلال StatsD. قد تكون القيمة none، statsd. |
| القياس عن بعد.metrics.local.statsd.endpoint | غير متوفر | تحدد نقطة نهاية StatsD. |
| القياس عن بعد.metrics.local.statsd.sampling | غير متوفر | يحدد مقاييس معدل أخذ العينات. يمكن أن تتراوح القيمة بين 0 و1. مثال: 0.5 |
| القياس عن بعد.metrics.local.statsd.tag-format | غير متوفر | تنسيق وضع العلامات على مصدر StatsD. يمكن أن تكون noneالقيمة ، librato، ، dogStatsD. influxDB |
فيما يلي نموذج التكوين:
apiVersion: v1
kind: ConfigMap
metadata:
name: contoso-gateway-environment
data:
config.service.endpoint: "<self-hosted-gateway-management-endpoint>"
telemetry.metrics.local: "statsd"
telemetry.metrics.local.statsd.endpoint: "10.0.41.179:8125"
telemetry.metrics.local.statsd.sampling: "1"
telemetry.metrics.local.statsd.tag-format: "dogStatsD"
قم بتحديث ملف YAML لنشر البوابة ذاتية الاستضافة بالتكوينات المذكورة أعلاه وقم بتطبيق التغييرات باستخدام الأمر التالي:
kubectl apply -f <file-name>.yaml
لالتقاط أحدث تغييرات التكوين، أعد تشغيل البوابة باستخدام الأمر التالي:
kubectl rollout restart deployment/<deployment-name>
عرض المقاييس
الآن لدينا كل شيء تم نشره وتكوينه، يجب أن تبلغ البوابة ذاتية الاستضافة عن المقاييس عبر StatsD. ثم يلتقط Prometheus المقاييس من StatsD. انتقل إلى لوحة معلومات Prometheus باستخدام EXTERNAL-IP و PORT من خدمة Prometheus.
قم بإجراء بعض استدعاءات واجهة برمجة التطبيقات من خلال البوابة ذاتية الاستضافة، إذا تم تكوين كل شيء بشكل صحيح، فيجب أن تكون قادراً على عرض المقاييس أدناه:
| مقياس | الوصف |
|---|---|
| requests_total | عدد طلبات API في الفترة |
| request_duration_seconds | عدد المللي ثانية من لحظة تلقي البوابة الطلب حتى لحظة إرسال الرد بالكامل |
| request_backend_duration_seconds | عدد المللي ثانية التي تم إنفاقها على المدخلات/ المخرجات الخلفي (الاتصال والإرسال والاستلام) |
| request_client_duration_seconds | عدد المللي ثانية التي تم إنفاقها على إجمالي الإدخال/الإخراج للعميل (الاتصال وإرسال واستقبال وحدات البايت) |
السجلات
تقوم البوابة المستضافة ذاتيا بإخراج السجلات إلى stdout و stderr بشكل افتراضي. يمكنك بسهولة عرض السجلات باستخدام الأمر التالي:
kubectl logs <pod-name>
إذا تم نشر البوابة المستضافة ذاتيا في Azure Kubernetes Service، يمكنك تمكين Azure Monitor للحاويات لجمع stdout أحمال العمل الخاصة stderr بك وإليها وعرض السجلات في Log Analytics.
تدعم البوابة المستضافة ذاتيا أيضا العديد من البروتوكولات بما في ذلك localsyslogو rfc5424و journal. يلخص الجدول التالي جميع الخيارات المعتمدة.
| الحقل | Default | الوصف |
|---|---|---|
| القياس عن بعد .logs.std | text |
تمكن من التسجيل لتيارات القياسية. يمكن أن تكون noneالقيمة ، ، textjson |
| القياس عن بعد .logs.local | auto |
تمكن التسجيل المحلي. يمكن أن تكون noneالقيمة ، auto، localsyslog، rfc5424، ، journal، json |
| telemetry.logs.local.localsyslog.endpoint | غير متوفر | تحديد نقطة نهاية syslog المحلية. للحصول على التفاصيل، راجع استخدام سجلات syslog المحلية. |
| telemetry.logs.local.localsyslog.facility | غير متوفر | يحدد رمز مرفق syslog المحلي. مثال: 7 |
| telemetry.logs.local.rfc5424.endpoint | غير متوفر | يحدد نقطة نهاية rfc5424. |
| telemetry.logs.local.rfc5424.facility | غير متوفر | يحدد رمز المرفق لكل rfc5424. مثال: 7 |
| telemetry.logs.local.journal.endpoint | غير متوفر | يحدد نقطة نهاية دفتر اليومية. |
| telemetry.logs.local.json.endpoint | 127.0.0.1:8888 | يحدد نقطة نهاية UDP التي تقبل بيانات JSON: مسار الملف أو منفذ IP: أو اسم المضيف: المنفذ. |
فيما يلي نموذج لتكوين التسجيل المحلي:
apiVersion: v1
kind: ConfigMap
metadata:
name: contoso-gateway-environment
data:
config.service.endpoint: "<self-hosted-gateway-management-endpoint>"
telemetry.logs.std: "text"
telemetry.logs.local.localsyslog.endpoint: "/dev/log"
telemetry.logs.local.localsyslog.facility: "7"
استخدام نقطة نهاية JSON المحلية
القيود المعروفة
- نحن ندعم فقط ما يصل إلى 3072 بايت من حمولة الطلب/الاستجابة للتشخيصات المحلية. أي شيء أعلاه، قد يكسر تنسيق JSON بسبب التقسيم.
استخدام سجلات syslog المحلية
تكوين البوابة لدفق السجلات
عند استخدام syslog المحلي كوجهة للسجلات، يحتاج وقت التشغيل إلى السماح بسجلات الدفق إلى الوجهة. بالنسبة إلى Kubernetes، يجب تحميل وحدة تخزين تتطابق مع الوجهة.
نظرا للتكوين التالي:
apiVersion: v1
kind: ConfigMap
metadata:
name: contoso-gateway-environment
data:
config.service.endpoint: "<self-hosted-gateway-management-endpoint>"
telemetry.logs.local: localsyslog
telemetry.logs.local.localsyslog.endpoint: /dev/log
يمكنك بسهولة بدء دفق السجلات إلى نقطة نهاية syslog المحلية هذه:
apiVersion: apps/v1
kind: Deployment
metadata:
name: contoso-deployment
labels:
app: contoso
spec:
replicas: 1
selector:
matchLabels:
app: contoso
template:
metadata:
labels:
app: contoso
spec:
containers:
name: azure-api-management-gateway
image: mcr.microsoft.com/azure-api-management/gateway:2.5.0
imagePullPolicy: IfNotPresent
envFrom:
- configMapRef:
name: contoso-gateway-environment
# ... redacted ...
+ volumeMounts:
+ - mountPath: /dev/log
+ name: logs
+ volumes:
+ - hostPath:
+ path: /dev/log
+ type: Socket
+ name: logs
استهلاك سجلات syslog المحلية على خدمة Azure Kubernetes (AKS)
عند التكوين لاستخدام syslog المحلي على خدمة Azure Kubernetes، يمكنك اختيار طريقتين لاستكشاف السجلات:
- استخدام مجموعة Syslog مع Container Insights
- الاتصال واستكشاف السجلات على العقد العاملة
استهلاك السجلات من العقد العاملة
يمكنك استهلاكها بسهولة عن طريق الوصول إلى العقد العاملة:
- إنشاء اتصال SSH بالعقدة (المستندات)
- يمكن العثور على السجلات ضمن
host/var/log/syslog
على سبيل المثال، يمكنك تصفية جميع syslogs إلى تلك فقط من البوابة المستضافة ذاتيا:
$ cat host/var/log/syslog | grep "apimuser"
May 15 05:54:20 aks-agentpool-43853532-vmss000000 apimuser[8]: Timestamp=2023-05-15T05:54:20.0445178Z, isRequestSuccess=True, totalTime=290, category=GatewayLogs, callerIpAddress=141.134.132.243, timeGenerated=2023-05-15T05:54:20.0445178Z, region=Repro, correlationId=b28565ec-73e0-41e6-9312-efcdd6841846, method=GET, url="http://20.126.242.200/echo/resource?param1\=sample", backendResponseCode=200, responseCode=200, responseSize=628, cache=none, backendTime=287, apiId=echo-api, operationId=retrieve-resource, apimSubscriptionId=master, clientProtocol=HTTP/1.1, backendProtocol=HTTP/1.1, apiRevision=1, backendMethod=GET, backendUrl="http://echoapi.cloudapp.net/api/resource?param1\=sample"
May 15 05:54:21 aks-agentpool-43853532-vmss000000 apimuser[8]: Timestamp=2023-05-15T05:54:21.1189171Z, isRequestSuccess=True, totalTime=150, category=GatewayLogs, callerIpAddress=141.134.132.243, timeGenerated=2023-05-15T05:54:21.1189171Z, region=Repro, correlationId=ab4d7464-acee-40ae-af95-a521cc57c759, method=GET, url="http://20.126.242.200/echo/resource?param1\=sample", backendResponseCode=200, responseCode=200, responseSize=628, cache=none, backendTime=148, apiId=echo-api, operationId=retrieve-resource, apimSubscriptionId=master, clientProtocol=HTTP/1.1, backendProtocol=HTTP/1.1, apiRevision=1, backendMethod=GET, backendUrl="http://echoapi.cloudapp.net/api/resource?param1\=sample"
إشعار
إذا قمت بتغيير الجذر باستخدام chroot، على سبيل المثال chroot /host، يجب أن يعكس المسار أعلاه هذا التغيير.
الخطوات التالية
- تعرف على قدرات إمكانية المراقبة لبوابات Azure API Management.
- تعرف على المزيد حول البوابة المستضافة ذاتيا لإدارة واجهة برمجة تطبيقات Azure.
- تعرف على تكوين السجلات واستمرارها في السحابة.