Cloud Foundry Monitoring für Plattform und Apps
Streamen Sie Metriken und Logs aus Loggregator für jede App, jede Diego Cell und den Gorouter auf Cloud Foundry und VMware Tanzu Application Service und ergänzen Sie OpenTelemetry-Traces.
Warum Cloud Foundry mit Obseria überwachen
Plattform und Apps in einem Stream
Eine Verbindung zur Loggregator-Streaming-API liefert Container-Metriken der Apps, App-Logs und Metriken der Plattformkomponenten.
Kontext aus Org und Space
Die Telemetrie trägt Org-, Space- und App-Namen. Teams sehen ihre eigenen Apps, Plattformbetreiber sehen alles.
Traces ohne Lock-in
Apps senden OpenTelemetry-Traces per OTLP, konfiguriert über Standard-Umgebungsvariablen per cf set-env oder im Manifest.
Cloud-Foundry-Komponenten, die Obseria überwacht
- Anwendungen und Instanzen. CPU, Speicher, Disk und Crash-Ereignisse pro App-Instanz, mit Org-, Space- und App-Metadaten.
- App-Logs. stdout-, stderr- und Staging-Logs aus Loggregator, angereichert mit App- und Instanz-Identität.
- Gorouter. Request-Rate, Latenz, 5xx-Antworten und Bad Gateways am Rand der Plattform.
- Diego Cells und BBS. Verbleibende Speicher- und Disk-Kapazität pro Cell sowie laufende und abgestürzte Long-Running Processes.
- Auctioneer und Scheduling. Fehlgeschlagene Platzierung von App-Instanzen und Tasks bei fehlender Kapazität.
- Loggregator. Zustand und Durchsatz des Logging-Systems selbst, einschließlich verworfener Envelopes.
Die Cloud Foundry-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Verkehr und Tempo
Zeigt, wie viele Anfragen Ihre Apps erreichen und wie schnell sie beantwortet werden, damit Verzögerungen sofort auffallen.
Fehler bei Nutzern
Zeigt, wie oft Besucher auf Fehler oder nicht erreichbare Apps stoßen, ein direktes Maß für verlorenes Vertrauen und Umsatz.
Kapazität der Plattform
Macht sichtbar, wie viel Rechenleistung und Speicher Ihre Plattform nutzt und wie viel Platz für neue Apps bleibt.
Stabilität der Apps
Hebt Apps hervor, die immer wieder abstürzen oder nicht starten können, weil die Plattform keinen passenden Platz findet.
Alle 9 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
gorouter.total_requests | {request} | Vom Gorouter weitergeleitete Requests, das plattformweite Traffic-Signal. |
gorouter.latency | ms | Zeit, die der Gorouter für einen Request braucht, einschließlich der App-Antwort. |
gorouter.responses.5xx | {response} | Über den Router zurückgegebene 5xx-Antworten. |
gorouter.bad_gateways | {response} | 502-Antworten, oft verursacht durch nicht erreichbare oder abstürzende App-Instanzen. |
rep.cpu | % | CPU-Nutzung einer App-Container-Instanz. |
rep.memory | By | Speichernutzung einer App-Container-Instanz; vergleichen Sie sie mit der Quota. |
rep.CapacityRemainingMemory | MiBy | Auf einer Diego Cell noch verfügbarer Speicher für neue Container. |
bbs.CrashedActualLRPs | {lrp} | Abgestürzte App-Instanzen auf der gesamten Plattform. |
auctioneer.AuctioneerLRPAuctionsFailed | {auction} | App-Instanzen, die nicht platziert werden konnten, meist wegen fehlender Kapazität. |
Cloud Foundry-Monitoring in wenigen Minuten einrichten
- Schritt 1
UAA-Client anlegen
Legen Sie einen UAA-Client mit der Authority logs.admin an, damit er vom Reverse Log Proxy Gateway des Loggregator lesen darf.
- Schritt 2
Receiver konfigurieren
Richten Sie den cloudfoundry Receiver des OpenTelemetry Collector auf RLP-Gateway- und UAA-Endpunkt aus und exportieren Sie per OTLP an Obseria.
- Schritt 3
App-Traces ergänzen
Setzen Sie OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT und OTEL_EXPORTER_OTLP_HEADERS für Apps mit OpenTelemetry SDKs.
receivers:
cloudfoundry:
rlp_gateway:
endpoint: "https://log-stream.sys.example.com"
shard_id: "obseria"
uaa:
endpoint: "https://uaa.sys.example.com"
username: "obseria-nozzle"
password: ${env:UAA_CLIENT_SECRET}
processors:
batch: {}
exporters:
otlphttp:
endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
headers:
Authorization: "Bearer ${env:OBSERIA_TOKEN}"
service:
pipelines:
metrics:
receivers: [cloudfoundry]
processors: [batch]
exporters: [otlphttp]Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- Cloud-Foundry-Plattformübersicht
- Gorouter: Traffic, Latenz und 5xx-Rate
- Kapazität der Diego Cells und Platzierungsfehler
- Abgestürzte App-Instanzen nach Org und Space
- Ressourcennutzung der Apps gegenüber Quotas
Cloud Foundry-Monitoring: Darauf kommt es an
Warum Cloud Foundry Monitoring zwei Perspektiven braucht
Cloud Foundry, einschließlich der kommerziellen Distribution VMware Tanzu Application Service, macht das Deployment von Apps einfach: cf push, und die Plattform kümmert sich um Container, Routing, Skalierung und Logs. Diese Einfachheit verbirgt viel Maschinerie. Diego Cells betreiben die Container, das BBS verfolgt Soll- und Ist-Zustand jeder App-Instanz, der Gorouter leitet Traffic, der Auctioneer platziert Instanzen, und Loggregator sammelt Logs und Metriken aus allem.
Cloud Foundry Monitoring braucht deshalb zwei Perspektiven. Plattformbetreiber achten auf Cell-Kapazität, Routing-Zustand und das Logging-System. Anwendungsteams interessieren sich für Antwortzeit, Fehler, Abstürze und Speicher im Verhältnis zur Quota ihrer App. Cloud Foundry Observability funktioniert, wenn beide Sichten dieselben Daten und Metadaten teilen. Dann lässt sich ein Absturz in einem Space entweder auf ein Kapazitätsproblem der Plattform oder auf einen Fehler in der App zurückführen.
Die Cloud-Foundry-Metriken, auf die es ankommt
Loggregator transportiert alle Plattform- und Container-Metriken als Envelopes. Die nützlichsten:
- Gorouter:
total_requests,latency,responses.5xxundbad_gatewaysliefern Rate, Fehler und Dauer für jede Route der Plattform. - App-Container:
cpu,memoryunddiskpro App-Instanz vom Rep, verglichen mit den im Manifest gesetzten Speicher- und Disk-Quotas. - Diego Cells:
CapacityRemainingMemoryundCapacityRemainingDiskzeigen, wie viel Platz für neue Instanzen bleibt. - BBS:
LRPsRunningundCrashedActualLRPszeigen, wie viele App-Instanzen gesund sind und wie viele abstürzen. - Auctioneer:
AuctioneerLRPAuctionsFailedund fehlgeschlagene Task-Auktionen zeigen, dass die Plattform Arbeit nicht platzieren konnte.
Typische Cloud-Foundry-Probleme und wie Sie sie erkennen
Abstürzende Apps. Eine App, die ihre Speicher-Quota überschreitet oder Health Checks nicht besteht, wird wiederholt neu gestartet. Steigende CrashedActualLRPs, Crash-Ereignisse im Log-Stream der App und Speicher nahe der Quota weisen auf die Ursache hin.
Erschöpfte Kapazität. Fehlt den Diego Cells Speicher oder Disk, lassen sich keine neuen Instanzen platzieren, und die Skalierung funktioniert nicht mehr. Geringe Restkapazität zusammen mit fehlgeschlagenen Auktionen ist das Signal, Cells hinzuzufügen oder Quotas zu reduzieren.
502-Fehler am Router. bad_gateways bedeuten meist, dass der Router eine Instanz nicht erreichen konnte, oft weil sie abgestürzt ist oder während eines Rolling Deployments neu startete. Die Korrelation von Router-Fehlern mit App-Ereignissen und Deployments zeigt, welche App und Version betroffen ist.
Verworfene Logs und Metriken. Unter hoher Last kann Loggregator Envelopes verwerfen. Wenn Sie seinen Durchsatz und seine Drop-Zähler überwachen, verpassen Sie keine Daten in genau den Incidents, auf die es ankommt.
Langsame Apps ohne Plattformproblem. Steigt die Router-Latenz, während die Plattformmetriken gesund aussehen, liegt das Problem in der App oder einem gebundenen Service. OpenTelemetry-Traces zeigen, welcher Aufruf langsam ist.
Best Practices für Cloud Foundry Monitoring
- Erfassen Sie Daten einmal zentral über die Loggregator-Streaming-API statt pro App.
- Behalten Sie Org-, Space- und App-Namen als Attribute, damit sich Dashboards und Alerts pro Team eingrenzen lassen.
- Alarmieren Sie auf abgestürzte Instanzen, 5xx-Raten am Router und Cell-Kapazität, nicht nur auf Host-Metriken der VMs darunter.
- Setzen Sie realistische Speicher-Quotas und verfolgen Sie die Nutzung dagegen, um Crash Loops zu vermeiden.
- Instrumentieren Sie Apps mit OpenTelemetry und konfigurieren Sie die Exporter über Umgebungsvariablen im Manifest.
So überwacht Obseria Cloud Foundry
Obseria übernimmt Cloud-Foundry-Telemetrie über den Cloud Foundry Receiver des OpenTelemetry Collector, der Metriken mit einem UAA-Client aus dem Reverse Log Proxy Gateway des Loggregator liest. App-Logs lassen sich durch Obseria Pipeline leiten, um Rauschen zu filtern und personenbezogene Daten vor der Speicherung zu maskieren. Apps senden Traces mit OpenTelemetry SDKs per OTLP. Obseria TopoGraph verknüpft Routes, Apps, Instanzen und gebundene Services, und Obseria Intelligence korreliert Plattform- und App-Signale, um die Ursache mit einer nachvollziehbaren Beweiskette zu finden. Da Cloud Foundry häufig auf VMware vSphere läuft, zeigt dieselbe Plattform auch die VMs und Hosts darunter.
Für Plattformteams bedeutet das: ein Ort für Kapazitätsplanung, Incident-Analyse und Alerting über alle Foundations hinweg, mit Dashboards, Alerts und SLOs ohne Aufpreis.
Verwandte Integrationen
Passende Funktionen
Distributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenAnomalie-Erkennung
Obseria Intelligence lernt den normalen Rhythmus jedes Service, meldet echte Abweichungen statt Schwellenwert-Rauschen und fasst zusammenhängende Anomalien zu einem Problem mit wahrscheinlicher Ursache zusammen.
Mehr erfahrenDeployment Tracking
Erfassen Sie jedes Deployment und jede Konfigurationsänderung, sehen Sie Release-Marker in jedem Chart und lassen Sie Obseria vorher und nachher vergleichen – in Minuten wissen Sie, ob ein Release hilft oder schadet.
Mehr erfahrenMehr erfahren
Was ist Observability?
Was ist Observability? Wie Metriken, Logs, Traces und Profile Ihre Systeme verständlich machen und was Observability vom Monitoring unterscheidet.
Die vier Golden Signals: Latenz, Traffic, Fehler und Sättigung
Die vier Golden Signals erklärt: Latenz, Traffic, Fehler und Sättigung, der Bezug zu RED- und USE-Methode und die Messung mit OpenTelemetry.
Häufige Fragen zum Cloud Foundry-Monitoring
Ja. Tanzu Application Service basiert auf Cloud Foundry und stellt dieselben Loggregator-APIs bereit, daher gilt dieselbe Integration.
Der Cloud Foundry Receiver des OpenTelemetry Collector verbindet sich mit dem Reverse Log Proxy Gateway des Loggregator und authentifiziert sich mit einem UAA-Client mit der Authority logs.admin.
Ja. App- und Staging-Logs aus Loggregator lassen sich weiterleiten, zum Beispiel über einen Syslog Drain, und werden mit Org-, Space- und App-Metadaten angereichert.
Binden Sie ein OpenTelemetry SDK oder einen Agent für Ihre Sprache ein und setzen Sie OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT und OTEL_EXPORTER_OTLP_HEADERS per cf set-env oder im App-Manifest.
Ja. Org-, Space- und App-Namen hängen an der gesamten Telemetrie, und mit rollenbasierter Zugriffskontrolle grenzen Sie Dashboards und Daten pro Team ein.
Starten Sie heute mit dem Cloud Foundry-Monitoring
Binden Sie Cloud Foundry in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.