Skip to main content

Scaling, logs, and metrics

Operating a running application: how many copies, what they are doing, and what they are saying.

Scaling​

Change the instance count, the memory limit, or both:

cf scale orders-api -i 3        # three instances
cf scale orders-api -m 1G       # 1 GB per instance
cf scale orders-api -i 3 -m 1G  # both

Changing memory restarts the app. Changing instance count alone does not — instances are added or removed around the running ones.

The same controls exist in the console, and the two agree. The platform keeps a single writer for the instance count, so a change made in the console and a change made from the CLI converge rather than fighting each other.

Autoscaling

There is no autoscaling today. The instance count you set is the instance count you get until you change it. Automatic scaling is designed but not built — if it matters for your workload, tell us, because demand is what will prioritise it.

Logs​

Follow a running app:

cf logs orders-api

Recent history, without following:

cf logs orders-api --recent

Logs are streamed from the running instances. Each line is tagged with its source — [APP/0] and [APP/1] are instances 0 and 1 of your application, so you can tell whether a problem affects one instance or all of them.

The console shows the same stream. Neither view is a summarised or delayed copy of the other.

Getting useful logs out of your app​

Write to stdout and stderr. Anything your process prints is captured. You do not need a logging agent, a sidecar, or a platform-specific logging library.

Structured output — JSON lines, say — stays intact through the pipeline, so if you already log structured events they remain machine-readable at the other end.

Metrics​

cf app orders-api

This shows per-instance CPU, memory, and disk alongside each instance's state.

Per-instance is the important part. An app averaging 60% CPU across three instances might have one instance pinned at 100% and two idling — an average hides exactly the condition you need to see. The console shows each instance separately for the same reason.

Restarting​

cf restart orders-api    # restart all instances
cf restage orders-api    # rebuild from source, then restart

Use restart after an environment change. Use restage when you want the buildpack to run again — for example after a platform-level buildpack update, without pushing new source.

Stopping and starting​

cf stop orders-api
cf start orders-api

A stopped app keeps its configuration, environment, and service bindings. It simply has no instances running, and reports stopped rather than crashed — the platform knows the difference between "you turned this off" and "this fell over."