Lokale metrische gegevens en logboeken configureren voor azure API Management zelf-hostende gateway
VAN TOEPASSING OP: Ontwikkelaar | Premie
Dit artikel bevat informatie over het configureren van lokale metrische gegevens en logboeken voor de zelf-hostende gateway die is geïmplementeerd in een Kubernetes-cluster. Zie dit artikel voor het configureren van metrische gegevens en logboeken van de cloud.
Metrische gegevens
De zelf-hostende gateway ondersteunt StatsD, dat een samenvoegingsprotocol is geworden voor verzameling en aggregatie van metrische gegevens. In deze sectie worden de stappen beschreven voor het implementeren van StatsD in Kubernetes, het configureren van de gateway voor het verzenden van metrische gegevens via StatsD en het gebruik van Prometheus om de metrische gegevens te bewaken.
StatsD en Prometheus implementeren in het cluster
Met de volgende YAML-voorbeeldconfiguratie worden StatsD en Prometheus geïmplementeerd in het Kubernetes-cluster waar een zelf-hostende gateway wordt geïmplementeerd. Er wordt ook een service voor elke service gemaakt. De zelf-hostende gateway publiceert vervolgens metrische gegevens naar de StatsD-service. We hebben toegang tot het Prometheus-dashboard via de service.
Notitie
In het volgende voorbeeld worden openbare containerinstallatiekopieën opgehaald uit Docker Hub. U wordt aangeraden een pull-geheim in te stellen voor verificatie met behulp van een Docker Hub-account in plaats van een anonieme pull-aanvraag te maken. Als u de betrouwbaarheid wilt verbeteren bij het werken met openbare inhoud, importeert en beheert u de installatiekopieën in een privé-Azure-containerregister. Meer informatie over het werken met openbare afbeeldingen.
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
Sla de configuraties op in een bestand met de naam metrics.yaml. Gebruik de volgende opdracht om alles in het cluster te implementeren:
kubectl apply -f metrics.yaml
Zodra de implementatie is voltooid, voert u de volgende opdracht uit om te controleren of de pods worden uitgevoerd. De podnaam is anders.
kubectl get pods
NAME READY STATUS RESTARTS AGE
sputnik-metrics-f6d97548f-4xnb7 2/2 Running 0 1m
Voer de onderstaande opdracht uit om te controleren of de services uitvoering wordt uitgevoerd. Noteer de CLUSTER-IP en PORT van de StatsD-service, die we later gebruiken. U kunt het Prometheus-dashboard bezoeken met behulp van EXTERNAL-IP het en 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
De zelf-hostende gateway configureren om metrische gegevens te verzenden
Nu zowel StatsD als Prometheus zijn geïmplementeerd, kunnen we de configuraties van de zelf-hostende gateway bijwerken om metrische gegevens via StatsD te verzenden. De functie kan worden ingeschakeld of uitgeschakeld met behulp van de telemetry.metrics.local sleutel in de ConfigMap van de zelf-hostende gatewayimplementatie met extra opties. Hier volgen de beschikbare opties:
| Veld | Default | Beschrijving |
|---|---|---|
| telemetry.metrics.local | none |
Hiermee schakelt u logboekregistratie via StatsD in. Waarde kan zijn none, statsd. |
| telemetry.metrics.local.statsd.endpoint | n.v.t. | Hiermee geeft u het statsd-eindpunt op. |
| telemetry.metrics.local.statsd.sampling | n.v.t. | Hiermee geeft u de steekproeffrequentie van metrische gegevens op. De waarde kan tussen 0 en 1 zijn. Voorbeeld: 0.5 |
| telemetry.metrics.local.statsd.tag-format | n.v.t. | De tagindeling statsD-exporteur. Waarde kan zijnnone, librato, dogStatsD, . influxDB |
Hier volgt een voorbeeldconfiguratie:
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"
Werk het YAML-bestand van de zelf-hostende gatewayimplementatie bij met de bovenstaande configuraties en pas de wijzigingen toe met behulp van de onderstaande opdracht:
kubectl apply -f <file-name>.yaml
Als u de meest recente configuratiewijzigingen wilt ophalen, start u de gatewayimplementatie opnieuw met behulp van de onderstaande opdracht:
kubectl rollout restart deployment/<deployment-name>
De metrische gegevens weergeven
Nu alles is geïmplementeerd en geconfigureerd, moet de zelf-hostende gateway metrische gegevens rapporteren via StatsD. Prometheus haalt vervolgens de metrische gegevens op uit StatsD. Ga naar het Prometheus-dashboard met behulp van de EXTERNAL-IP prometheus-service PORT .
Voer enkele API-aanroepen uit via de zelf-hostende gateway, als alles correct is geconfigureerd, kunt u de onderstaande metrische gegevens bekijken:
| Metrisch | Beschrijving |
|---|---|
| requests_total | Aantal API-aanvragen in de periode |
| request_duration_seconds | Aantal milliseconden vanaf het moment dat de gateway de aanvraag ontving tot het moment dat het antwoord volledig werd verzonden |
| request_backend_duration_seconds | Aantal milliseconden dat in totaal is besteed aan IO van de back-end (verbinding maken, bytes verzenden en ontvangen) |
| request_client_duration_seconds | Aantal milliseconden dat is besteed aan de totale io van de client (verbinding maken, verzenden en ontvangen van bytes) |
Logboeken
De zelf-hostende gateway voert logboeken uit naar stdout en stderr standaard. U kunt de logboeken eenvoudig weergeven met behulp van de volgende opdracht:
kubectl logs <pod-name>
Als uw zelf-hostende gateway is geïmplementeerd in Azure Kubernetes Service, kunt u Azure Monitor inschakelen voor containers voor het verzamelen stdout en stderr ophalen van uw workloads en het weergeven van de logboeken in Log Analytics.
De zelf-hostende gateway ondersteunt ook veel protocollen, waaronder localsyslog, rfc5424en journal. De volgende tabel bevat een overzicht van alle ondersteunde opties.
| Veld | Default | Beschrijving |
|---|---|---|
| telemetry.logs.std | text |
Hiermee kunt u logboekregistratie naar standaardstreams inschakelen. Waarde kan zijnnone, textjson |
| telemetry.logs.local | auto |
Hiermee schakelt u lokale logboekregistratie in. Waarde kan zijnnone, auto, localsyslog, rfc5424, , journaljson |
| telemetry.logs.local.localsyslog.endpoint | n.v.t. | Hiermee geeft u het lokale syslog-eindpunt. Zie voor meer informatie het gebruik van lokale Syslog-logboeken. |
| telemetry.logs.local.localsyslog.facility | n.v.t. | Hiermee geeft u lokale syslog faciliteit code. Voorbeeld: 7 |
| telemetry.logs.local.rfc5424.endpoint | n.v.t. | Hiermee geeft u rfc5424-eindpunt. |
| telemetry.logs.local.rfc5424.facility | n.v.t. | Hiermee geeft u faciliteitcode per rfc5424. Voorbeeld: 7 |
| telemetry.logs.local.journal.endpoint | n.v.t. | Hiermee geeft u het logboekeindpunt op. |
| telemetry.logs.local.json.endpoint | 127.0.0.1:8888 | Hiermee geeft u UDP-eindpunt dat JSON-gegevens accepteert: bestandspad, IP:poort of hostnaam:poort. |
Hier volgt een voorbeeldconfiguratie van lokale logboekregistratie:
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"
Lokaal JSON-eindpunt gebruiken
Bekende beperkingen
- We ondersteunen alleen maximaal 3072 bytes aan nettolading van aanvragen/antwoorden voor lokale diagnostische gegevens. Alles hierboven kan de JSON-indeling verbreken vanwege segmentering.
Lokale Syslog-logboeken gebruiken
Gateway configureren voor het streamen van logboeken
Wanneer u lokale syslog gebruikt als bestemming voor logboeken, moet de runtime streaminglogboeken naar de bestemming toestaan. Voor Kubernetes moet een volume worden gekoppeld dat overeenkomt met het doel.
Gegeven de volgende configuratie:
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
U kunt eenvoudig streaminglogboeken naar dat lokale Syslog-eindpunt starten:
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
Lokale Syslog-logboeken gebruiken in Azure Kubernetes Service (AKS)
Wanneer u configureert voor het gebruik van lokale syslog in Azure Kubernetes Service, kunt u twee manieren kiezen om de logboeken te verkennen:
- Syslog-verzameling gebruiken met Container Insights
- Logboeken verbinden en verkennen op de werkknooppunten
Logboeken van werkknooppunten gebruiken
U kunt ze eenvoudig gebruiken door toegang te krijgen tot de werkknooppunten:
- Een SSH-verbinding met het knooppunt maken (docs)
- Logboeken vindt u onder
host/var/log/syslog
U kunt bijvoorbeeld alle syslogs filteren op alleen syslogs van de zelf-hostende gateway:
$ 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=aaaa0000-bb11-2222-33cc-444444dddddd, 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=bbbb1111-cc22-3333-44dd-555555eeeeee, 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"
Notitie
Als u bijvoorbeeld de hoofdmap hebt gewijzigd, chrootchroot /hostmoet het bovenstaande pad die wijziging weerspiegelen.
Volgende stappen
- Meer informatie over de waarneembaarheidsmogelijkheden van de Azure API Management-gateways.
- Meer informatie over de zelf-hostende gateway van Azure API Management.
- Meer informatie over het configureren en behouden van logboeken in de cloud.