Konfigurasikan metrik dan log lokal untuk gateway yang dihosting sendiri oleh Azure API Management
BERLAKU UNTUK: Pengembang | Premi
Artikel ini menyediakan detail untuk mengonfigurasi metrik dan log lokal untuk gateway yang dihosting sendiri yang diterapkan pada kluster Kubernetes. Untuk mengonfigurasi metrik dan log cloud, lihat artikel ini.
Metrik
Gateway yang dihosting sendiri mendukung StatsD, yang telah menjadi protokol yang menyatukan untuk pengumpulan dan agregasi metrik. Bagian ini menjelaskan langkah-langkah untuk menerapkan StatsD ke Kubernetes, mengonfigurasi gateway untuk memancarkan metrik melalui StatsD, dan menggunakan Prometheus untuk memantau metrik.
Terapkan StatsD dan Prometheus ke cluster
Contoh konfigurasi YAML berikut menyebarkan StatsD dan Prometheus ke kluster Kubernetes tempat gateway yang dihost sendiri disebarkan. Hal ini juga membuat Layanan untuk masing-masing. Gateway yang dihost sendiri kemudian menerbitkan metrik ke Layanan StatsD. Kami akan mengakses dasbor Prometheus melalui Layanannya.
Catatan
Contoh berikut menarik gambar kontainer publik dari Docker Hub. Sebaiknya Anda menyiapkan rahasia penarikan untuk diautentikasi menggunakan akun Docker Hub alih-alih membuat permintaan penarikan anonim. Untuk meningkatkan keandalan saat bekerja dengan konten publik, impor dan kelola gambar di registri kontainer Azure privat. Pelajari lebih lanjut cara menangani citra publik.
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
Simpan konfigurasi ke file bernama metrics.yaml. Gunakan perintah berikut untuk menyebarkan semuanya ke kluster:
kubectl apply -f metrics.yaml
Setelah penyebaran selesai, jalankan perintah berikut untuk memeriksa Pod sedang berjalan. Nama pod Anda akan berbeda.
kubectl get pods
NAME READY STATUS RESTARTS AGE
sputnik-metrics-f6d97548f-4xnb7 2/2 Running 0 1m
Jalankan perintah di bawah ini untuk memeriksa services sedang berjalan. Catat CLUSTER-IP dan PORT Layanan StatsD, yang kami gunakan nanti. Anda dapat mengunjungi dasbor Prometheus menggunakan EXTERNAL-IP dan 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
Konfigurasikan gateway yang dihosting sendiri untuk memancarkan metrik
Sekarang setelah StatsD dan Prometheus disebarkan, kita dapat memperbarui konfigurasi gateway yang dihost sendiri untuk mulai memancarkan metrik melalui StatsD. Fitur ini dapat diaktifkan atau dinonaktifkan menggunakan kunci telemetry.metrics.local di ConfigMap dari Penerapan gateway yang dihosting sendiri dengan opsi tambahan. Berikut ini adalah opsi yang tersedia:
| Bidang | Default | Deskripsi |
|---|---|---|
| telemetri.metrik.lokal | none |
Memungkinkan masuk melalui StatsD. Nilainya bisa none, statsd. |
| telemetri.metrik.lokal.statsd.titik akhir | n/a | Menentukan titik akhir StatsD. |
| telemetri.metrik.lokal.statsd.pengambilan sampel | n/a | Menentukan tingkat pengambilan sampel metrik. Nilainya bisa antara 0 dan 1. Contoh: 0.5 |
| telemetri.metrik.lokal.statsd.format tag | n/a | format pemberian tag eksportir StatsD. Nilainya dapat none, librato, dogStatsD, influxDB. |
Berikut adalah contoh konfigurasi:
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"
Perbarui file YAML dari penerapan gateway yang dihosting sendiri dengan konfigurasi di atas dan terapkan perubahan menggunakan perintah di bawah ini:
kubectl apply -f <file-name>.yaml
Untuk mengambil perubahan konfigurasi terbaru, mulai ulang penerapan gateway menggunakan perintah di bawah ini:
kubectl rollout restart deployment/<deployment-name>
Lihat metrik
Sekarang kami memiliki semuanya yang diterapkan dan dikonfigurasi, gateway yang dihosting sendiri harus melaporkan metrik melalui StatsD. Prometheus kemudian mengambil metrik dari StatsD. Buka dasbor Prometheus menggunakan EXTERNAL-IP dan PORT Layanan Prometheus.
Lakukan beberapa panggilan API melalui gateway yang dihosting sendiri, jika semuanya dikonfigurasi dengan benar, Anda akan dapat melihat metrik di bawah ini:
| Metrik | Deskripsi |
|---|---|
| requests_total | Jumlah permintaan API dalam periode tersebut |
| request_duration_seconds | Jumlah milidetik dari saat gateway menerima permintaan hingga respons saat dikirim secara penuh |
| request_backend_duration_seconds | Jumlah milidetik yang dihabiskan untuk keseluruhan IO backend (menghubungkan, mengirim, dan menerima byte) |
| request_client_duration_seconds | Jumlah milidetik yang dihabiskan untuk keseluruhan IO klien (menghubungkan, mengirim, dan menerima byte) |
Log
Gateway yang dihosting sendiri mengeluarkan log ke stdout dan stderr secara default. Anda dapat dengan mudah melihat log menggunakan perintah berikut:
kubectl logs <pod-name>
Jika gateway yang dihosting sendiri diterapkan di Azure Kubernetes Service, Anda dapat mengaktifkan Azure Monitor untuk penampung untuk mengumpulkan stdout dan stderr dari beban kerja Anda dan melihat log di Analitik Log.
Gateway yang dihost sendiri juga mendukung banyak protokol termasuk localsyslog, , rfc5424dan journal. Tabel berikut ini meringkas semua opsi yang didukung.
| Bidang | Default | Deskripsi |
|---|---|---|
| telemetri.log.std | text |
Memungkinkan logging ke aliran standar. Nilainya dapat none, text, json |
| telemetri.log.lokal | auto |
Mengaktifkan logging lokal. Nilainya dapat berupa none, auto, localsyslog, rfc5424, journal, json |
| telemetri.log.lokal.localsyslog.titik akhir | n/a | Menentukan titik akhir syslog lokal. Untuk detailnya, lihat menggunakan log syslog lokal. |
| telemetri.log.lokal.localsyslog.fasilitas | n/a | Menentukan kode fasilitas syslog lokal. Contoh: 7 |
| telemetri.log.lokal.rfc5424.titik akhir | n/a | Menentukan titik akhir rfc5424. |
| telemetri.log.lokal.rfc5424.fasilitas | n/a | Menentukan kode fasilitas per rfc5424. Contoh: 7 |
| telemetri.log.lokal.jurnal.titik akhir | n/a | telemetri.log.lokal.jurnal.titik akhir. |
| telemetry.logs.local.json.endpoint | 127.0.0.1:8888 | Menentukan titik akhir UDP yang menerima data JSON: jalur file, IP:port, atau hostname:port. |
Berikut adalah contoh konfigurasi pengelogan lokal:
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"
Menggunakan titik akhir JSON lokal
Pembatasan yang diketahui
- Kami hanya mendukung hingga 3072 byte payload permintaan/respons untuk diagnostik lokal. Apa pun di atas, dapat merusak format JSON karena pemotongan.
Menggunakan log syslog lokal
Mengonfigurasi gateway untuk mengalirkan log
Saat menggunakan syslog lokal sebagai tujuan untuk log, runtime perlu mengizinkan log streaming ke tujuan. Untuk Kubernetes, volume perlu dipasang yang cocok dengan tujuan.
Mengingat konfigurasi berikut:
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
Anda dapat dengan mudah memulai log streaming ke titik akhir syslog lokal tersebut:
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
Menggunakan log syslog lokal di Azure Kubernetes Service (AKS)
Saat mengonfigurasi untuk menggunakan syslog lokal di Azure Kubernetes Service, Anda dapat memilih dua cara untuk menjelajahi log:
- Menggunakan koleksi Syslog dengan Container Insights
- Menyambungkan & menjelajahi log pada simpul pekerja
Mengkonsumsi log dari simpul pekerja
Anda dapat dengan mudah menggunakannya dengan mendapatkan akses ke simpul pekerja:
- Membuat koneksi SSH ke simpul (dokumen)
- Log dapat ditemukan di bawah
host/var/log/syslog
Misalnya, Anda dapat memfilter semua syslog hanya untuk yang dari gateway yang dihost sendiri:
$ 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"
Catatan
Jika Anda telah mengubah akar dengan chroot, misalnya chroot /host, maka jalur di atas perlu mencerminkan perubahan tersebut.
Langkah berikutnya
- Pelajari tentang kemampuan pengamatan gateway Azure API Management.
- Pelajari selengkapnya tentang gateway yang dihost sendiri Azure API Management.
- Pelajari tentang mengonfigurasi dan mempertahankan log di cloud.