Cloud Foundry monitoring for platform and apps
Stream metrics and logs from Loggregator for every app, Diego cell and Gorouter on Cloud Foundry and VMware Tanzu Application Service, and add OpenTelemetry traces from your apps.
Why monitor Cloud Foundry with Obseria
Platform and apps in one stream
One connection to the Loggregator streaming API delivers app container metrics, app logs and platform component metrics.
Org and space context
Telemetry carries org, space and app names, so teams see their own apps and platform operators see everything.
Traces without lock-in
Apps send OpenTelemetry traces over OTLP, using standard environment variables set through cf set-env or the manifest.
Cloud Foundry components Obseria monitors
- Applications and instances. CPU, memory, disk and crash events per app instance, with org, space and app metadata.
- App logs. stdout, stderr and staging logs from Loggregator, enriched with app and instance identity.
- Gorouter. Request rate, latency, 5xx responses and bad gateways at the platform edge.
- Diego cells and BBS. Remaining memory and disk capacity per cell and running versus crashed long-running processes.
- Auctioneer and scheduling. Failed placement of app instances and tasks when capacity runs out.
- Loggregator. Health and throughput of the logging system itself, including dropped envelopes.
The Cloud Foundry signals that matter
Obseria collects these values automatically and shows them in ready-made dashboards and alerts.Traffic and speed
Shows how many requests reach your apps and how quickly they are answered, so slowdowns are noticed immediately.
Errors users see
Tells you how often visitors hit errors or unreachable apps, a direct measure of lost trust and revenue.
Platform capacity
Reveals how much processing power and memory your platform uses and how much room remains for new apps.
App stability
Highlights apps that keep crashing or cannot be started because the platform has no suitable place for them.
Show all 9 metrics in detail
| Metric | Unit | What it tells you |
|---|---|---|
gorouter.total_requests | {request} | Requests routed by the Gorouter, the platform-wide traffic signal. |
gorouter.latency | ms | Time the Gorouter takes to handle a request, including the app response. |
gorouter.responses.5xx | {response} | 5xx responses returned through the router. |
gorouter.bad_gateways | {response} | 502 responses, often caused by unreachable or crashing app instances. |
rep.cpu | % | CPU usage of an app container instance. |
rep.memory | By | Memory used by an app container instance; compare with its quota. |
rep.CapacityRemainingMemory | MiBy | Memory still available for new containers on a Diego cell. |
bbs.CrashedActualLRPs | {lrp} | App instances in crashed state across the platform. |
auctioneer.AuctioneerLRPAuctionsFailed | {auction} | App instances that could not be placed, usually due to missing capacity. |
Set up Cloud Foundry monitoring in minutes
- Step 1
Create a UAA client
Create a UAA client with the logs.admin authority so it can read from the Loggregator reverse log proxy gateway.
- Step 2
Configure the receiver
Point the cloudfoundry receiver of the OpenTelemetry Collector at the RLP gateway and UAA endpoints and export to Obseria over OTLP.
- Step 3
Add app traces
Set OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT and OTEL_EXPORTER_OTLP_HEADERS for apps using 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]Out of the box
Dashboards, alerts and SLOs that are ready the moment data arrives.
- Cloud Foundry platform overview
- Gorouter traffic, latency and 5xx rate
- Diego cell capacity and placement failures
- Crashed app instances by org and space
- App resource usage against quotas
Cloud Foundry monitoring: what matters
Why Cloud Foundry monitoring needs two perspectives
Cloud Foundry, including its commercial distribution VMware Tanzu Application Service, makes deploying apps simple: cf push and the platform takes care of containers, routing, scaling and logs. That simplicity hides a lot of machinery. Diego cells run the containers, the BBS tracks the desired and actual state of every app instance, the Gorouter routes traffic, the Auctioneer places instances and Loggregator collects logs and metrics from all of it.
Cloud Foundry monitoring therefore needs two perspectives. Platform operators care about cell capacity, routing health and the logging system. Application teams care about their app's response time, errors, crashes and memory against quota. Cloud Foundry observability works when both views share the same data and metadata, so a crash in one space can be traced to a capacity problem on the platform or to a bug in the app.
The Cloud Foundry metrics that matter
Loggregator carries all platform and container metrics as envelopes. The most useful ones are:
- Gorouter:
total_requests,latency,responses.5xxandbad_gatewaysgive you rate, errors and duration for every route on the platform. - App containers:
cpu,memoryanddiskper app instance from the rep, compared with the memory and disk quotas set in the manifest. - Diego cells:
CapacityRemainingMemoryandCapacityRemainingDiskshow how much room is left for new instances. - BBS:
LRPsRunningandCrashedActualLRPsreveal how many app instances are healthy and how many are crashing. - Auctioneer:
AuctioneerLRPAuctionsFailedand failed task auctions show that the platform could not place work.
Common Cloud Foundry problems and how to detect them
Crashing apps. An app that exceeds its memory quota or fails health checks is restarted repeatedly. Rising CrashedActualLRPs, crash events in the app log stream and memory close to the quota point to the cause.
Capacity exhaustion. When Diego cells run low on memory or disk, new instances cannot be placed and scaling stops working. Low remaining capacity combined with failed auctions is the signal to add cells or reduce quotas.
502 errors at the router. bad_gateways usually mean the router could not reach an instance, often because it crashed or was being restarted during a rolling deployment. Correlating router errors with app events and deployments shows which app and version is affected.
Dropped logs and metrics. Under heavy load, Loggregator can drop envelopes. Watching its own throughput and drop counters ensures you do not miss data during the incidents that matter most.
Slow apps without platform issues. If router latency rises while platform metrics look healthy, the problem is inside the app or one of its bound services. OpenTelemetry traces show which call is slow.
Cloud Foundry monitoring best practices
- Collect from the Loggregator streaming API once, centrally, rather than per app.
- Keep org, space and app names as attributes so dashboards and alerts can be scoped per team.
- Alert on crashed instances, router 5xx rates and cell capacity, not only on host metrics of the VMs below.
- Set realistic memory quotas and track usage against them to avoid crash loops.
- Instrument apps with OpenTelemetry and configure exporters through environment variables in the manifest.
How Obseria monitors Cloud Foundry
Obseria ingests Cloud Foundry telemetry through the OpenTelemetry Collector's Cloud Foundry receiver, which reads metrics from the Loggregator reverse log proxy gateway with a UAA client. App logs can be routed through Obseria Pipeline to filter noise and mask personal data before storage. Apps send traces with OpenTelemetry SDKs over OTLP. Obseria TopoGraph links routes, apps, instances and bound services, and Obseria Intelligence correlates platform and app signals to find the root cause with a chain of evidence. Because Cloud Foundry often runs on VMware vSphere, the same platform can also show the VMs and hosts below.
Related integrations
Related capabilities
Distributed Tracing
Follow each request across services, queues and databases with OpenTelemetry-native distributed tracing, and find the slow span or failing dependency in seconds.
Learn moreAnomaly Detection
Obseria Intelligence learns the normal rhythm of every service, flags real deviations instead of threshold noise and groups related anomalies into one problem with a probable root cause.
Learn moreDeployment Tracking
Record every deployment and configuration change, see release markers on every chart and let Obseria compare before and after so you know within minutes whether a release improved or broke things.
Learn moreLearn more
What is observability?
What is observability? Learn how metrics, logs, traces and profiles let you understand any system state, how it differs from monitoring, and how to start.
The four golden signals: latency, traffic, errors and saturation
The four golden signals explained: latency, traffic, errors and saturation, how they relate to the RED and USE methods, and how to measure them with OTel.
Cloud Foundry monitoring FAQ
Yes. Tanzu Application Service is based on Cloud Foundry and exposes the same Loggregator APIs, so the same integration applies.
The OpenTelemetry Collector's Cloud Foundry receiver connects to the Loggregator reverse log proxy gateway and authenticates with a UAA client that has the logs.admin authority.
Yes. App and staging logs from Loggregator can be forwarded, for example through a syslog drain, and are enriched with org, space and app metadata.
Add an OpenTelemetry SDK or agent for your language and set OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT and OTEL_EXPORTER_OTLP_HEADERS via cf set-env or the app manifest.
Yes. Org, space and app names are attached to all telemetry, and role-based access control lets you scope dashboards and data per team.
Start monitoring Cloud Foundry today
Connect Cloud Foundry in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.