Azure API Management şirket içinde barındırılan ağ geçidi için yerel ölçümleri ve günlükleri yapılandırma
ŞUNLAR IÇIN GEÇERLIDIR: Geliştirici | Premium
Bu makalede, Kubernetes kümesinde dağıtılan şirket içinde barındırılan ağ geçidi için yerel ölçümleri ve günlükleri yapılandırmaya yönelik ayrıntılar sağlanır. Bulut ölçümlerini ve günlüklerini yapılandırmak için bu makaleye bakın.
Ölçümler
Şirket içinde barındırılan ağ geçidi, ölçüm toplama ve toplama için birleştirici bir protokol haline gelen StatsD'yi destekler. Bu bölümde StatsD'yi Kubernetes'e dağıtma, ağ geçidini statsD aracılığıyla ölçümleri yayacak şekilde yapılandırma ve ölçümleri izlemek için Prometheus kullanma adımları adım adım izlenmektedir.
StatsD ve Prometheus'ı kümeye dağıtma
Aşağıdaki örnek YAML yapılandırması, StatsD ve Prometheus'u şirket içinde barındırılan bir ağ geçidinin dağıtıldığı Kubernetes kümesine dağıtır. Ayrıca her bir hizmet için bir Hizmet oluşturur. Şirket içinde barındırılan ağ geçidi daha sonra ölçümleri statsD Hizmetinde yayımlar. Prometheus panosuna Hizmeti aracılığıyla erişeceğiz.
Not
Aşağıdaki örnek, Docker Hub'dan genel kapsayıcı görüntülerini çeker. Anonim çekme isteğinde bulunmak yerine Docker Hub hesabı kullanarak kimlik doğrulaması yapmak için bir çekme gizli dizisi ayarlamanızı öneririz. Genel içerikle çalışırken güvenilirliği artırmak için özel bir Azure kapsayıcı kayıt defterindeki görüntüleri içeri aktarın ve yönetin. Genel görüntülerle çalışma hakkında daha fazla bilgi edinin.
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
Yapılandırmaları adlı metrics.yaml
bir dosyaya kaydedin. Kümeye her şeyi dağıtmak için aşağıdaki komutu kullanın:
kubectl apply -f metrics.yaml
Dağıtım tamamlandıktan sonra podların çalışıp çalışmadığını denetlemek için aşağıdaki komutu çalıştırın. Pod adınız farklı olacaktır.
kubectl get pods
NAME READY STATUS RESTARTS AGE
sputnik-metrics-f6d97548f-4xnb7 2/2 Running 0 1m
Aşağıdaki komutu çalıştırarak çalışıp çalışmadığını denetleyin services
. Daha sonra kullandığımız statsD Hizmetinin ve PORT
değerlerini not CLUSTER-IP
alın. ve PORT
kullanarak Prometheus panosunu EXTERNAL-IP
ziyaret edebilirsiniz.
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
Ölçümleri yaymak için şirket içinde barındırılan ağ geçidini yapılandırma
Artık hem statsD hem de Prometheus dağıtıldığına göre, statsD aracılığıyla ölçümleri yaymaya başlamak için şirket içinde barındırılan ağ geçidinin yapılandırmalarını güncelleştirebiliriz. Özellik, şirket içinde barındırılan ağ geçidi dağıtımının telemetry.metrics.local
ConfigMap'indeki anahtar kullanılarak etkinleştirilebilir veya devre dışı bırakılabilir. Kullanılabilir seçenekler şunlardır:
Alan | Varsayılan | Açıklama |
---|---|---|
telemetry.metrics.local | none |
statsD aracılığıyla günlüğe kaydetmeyi etkinleştirir. Değer , statsd olabilirnone . |
telemetry.metrics.local.statsd.endpoint | yok | İstatistikler uç noktasını belirtir. |
telemetry.metrics.local.statsd.sampling | yok | Ölçüm örnekleme oranını belirtir. Değer 0 ile 1 arasında olabilir. Örnek: 0.5 |
telemetry.metrics.local.statsd.tag-format | yok | statsD exporter etiketleme biçimi. none Değer , , librato , dogStatsD . influxDB |
Aşağıda örnek bir yapılandırma verilmişti:
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"
Şirket içinde barındırılan ağ geçidi dağıtımının YAML dosyasını yukarıdaki yapılandırmalarla güncelleştirin ve aşağıdaki komutu kullanarak değişiklikleri uygulayın:
kubectl apply -f <file-name>.yaml
En son yapılandırma değişikliklerini almak için aşağıdaki komutu kullanarak ağ geçidi dağıtımını yeniden başlatın:
kubectl rollout restart deployment/<deployment-name>
Ölçümleri görüntüleme
Artık her şeyi dağıtıp yapılandırdık. Şirket içinde barındırılan ağ geçidinin istatistikleri statsD aracılığıyla raporlaması gerekir. Prometheus daha sonra statsD'den ölçümleri alır. Prometheus Hizmeti'nin ve PORT
öğesini kullanarak EXTERNAL-IP
Prometheus panosuna gidin.
Şirket içinde barındırılan ağ geçidi üzerinden bazı API çağrıları yapın. Her şey doğru yapılandırıldıysa aşağıdaki ölçümleri görüntüleyebilirsiniz:
Metrik Sistem | Açıklama |
---|---|
requests_total | Dönemdeki API isteklerinin sayısı |
request_duration_seconds | Ağ geçidinin isteği aldığı andan, yanıtın tamamen gönderildiği ana kadar geçen milisaniye cinsinden süre |
request_backend_duration_seconds | Genel arka uç GÇ için harcanan milisaniye sayısı (bağlanma, gönderme ve alma baytları) |
request_client_duration_seconds | Genel istemci GÇ için harcanan milisaniye sayısı (bağlanma, gönderme ve alma baytları) |
Günlükler
Şirket içinde barındırılan ağ geçidi, varsayılan olarak ve stderr
için stdout
günlük çıkışı oluşturur. Aşağıdaki komutu kullanarak günlükleri kolayca görüntüleyebilirsiniz:
kubectl logs <pod-name>
Şirket içinde barındırılan ağ geçidiniz Azure Kubernetes Service'te dağıtıldıysa, iş yüklerinizden kapsayıcılar stderr
stdout
için Azure İzleyici'yi etkinleştirebilir ve günlükleri Log Analytics'te görüntüleyebilirsiniz.
Şirket içinde barındırılan ağ geçidi, , rfc5424
ve journal
gibi localsyslog
birçok protokolü de destekler. Aşağıdaki tabloda desteklenen tüm seçenekler özetlenmiştir.
Alan | Varsayılan | Açıklama |
---|---|---|
telemetry.logs.std | text |
Standart akışlarda günlüğe kaydetmeyi etkinleştirir. Değer , , text olabilir none json |
telemetry.logs.local | auto |
Yerel günlüğe kaydetmeyi etkinleştirir. Değer , , auto , localsyslog , rfc5424 , journal , olabilir none json |
telemetry.logs.local.localsyslog.endpoint | yok | Yerel syslog uç noktasını belirtir. Ayrıntılar için bkz . yerel syslog günlüklerini kullanma. |
telemetry.logs.local.localsyslog.facility | yok | Yerel syslog tesis kodunu belirtir. Örnek: 7 |
telemetry.logs.local.rfc5424.endpoint | yok | rfc5424 uç noktasını belirtir. |
telemetry.logs.local.rfc5424.facility | yok | Rfc5424 başına tesis kodunu belirtir. Örnek: 7 |
telemetry.logs.local.journal.endpoint | yok | Günlük uç noktasını belirtir. |
telemetry.logs.local.json.endpoint | 127.0.0.1:8888 | JSON verilerini kabul eden UDP uç noktasını belirtir: dosya yolu, IP:bağlantı noktası veya ana bilgisayar adı:bağlantı noktası. |
Aşağıda yerel günlüğün örnek bir yapılandırması verilmişti:
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"
Yerel JSON uç noktasını kullanma
Bilinen sınırlamalar
- Yerel tanılama için yalnızca 3072 bayt istek/yanıt yükünü destekliyoruz. Yukarıdaki herhangi bir şey, öbekleme nedeniyle JSON biçimini bozabilir.
Yerel syslog günlüklerini kullanma
Ağ geçidini akış günlükleri için yapılandırma
Günlükler için hedef olarak yerel syslog kullanılırken çalışma zamanının hedefe akış günlüklerine izin vermesi gerekir. Kubernetes için hedefle eşleşen bir birimin bağlanması gerekir.
Aşağıdaki yapılandırma göz önünde bulundurulduğunda:
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
Günlük akışını bu yerel syslog uç noktasına kolayca başlatabilirsiniz:
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
Azure Kubernetes Service'te (AKS) yerel syslog günlüklerini kullanma
Azure Kubernetes Service'te yerel syslog kullanacak şekilde yapılandırırken, günlükleri keşfetmenin iki yolunu seçebilirsiniz:
- Container Insights ile Syslog koleksiyonunu kullanma
- Çalışan düğümlerine bağlanma ve günlükleri keşfetme
Çalışan düğümlerinden günlükleri kullanma
Çalışan düğümlerine erişim elde ederek bunları kolayca kullanabilirsiniz:
- Düğüme SSH bağlantısı oluşturma (belgeler)
- Günlükler
host/var/log/syslog
Örneğin, tüm syslog'ları yalnızca şirket içinde barındırılan ağ geçidinden gelenlerle filtreleyebilirsiniz:
$ 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"
Not
Örneğinchroot /host
, ile chroot
kökünü değiştirdiyseniz, yukarıdaki yolun bu değişikliği yansıtması gerekir.
Sonraki adımlar
- Azure API Management ağ geçitlerinin gözlemlenebilirlik özellikleri hakkında bilgi edinin.
- Azure API Management şirket içinde barındırılan ağ geçidi hakkında daha fazla bilgi edinin.
- Günlükleri bulutta yapılandırma ve kalıcı hale ekleme hakkında bilgi edinin.
Geri Bildirim
https://aka.ms/ContentUserFeedback.
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz.Gönderin ve geri bildirimi görüntüleyin