Application analytics and server monitoring
Open an application’s Analytics page for workload history, or a pool’s Monitoring page for server-wide measurements. Crane stores history on the server, so no separate monitoring service is required.
Read the measurements
| View | Measurements |
|---|---|
| Application resources | CPU, memory, received/sent network traffic and disk read/write rates |
| Public HTTP traffic, when available | Request rate, HTTP 5xx percentage, estimated p95 response time and response bandwidth |
| Pool resources | Host CPU, memory, network traffic and disk usage |
CPU and memory summaries show usage against observed limits when available. Allocated capacity describes a limit, not actual utilization. Charts average measurements into intervals; the latest summary uses the latest recorded interval. Missing samples appear as gaps rather than zero usage.
Select a time range from 1 hour through 90 days. A wider range does not create history that was never collected or has already expired. HTTP traffic measurements require compatible deployed routing; an existing application may need redeployment after a Crane monitoring update.
Collection and availability
The current collector samples about every 30 seconds. Allow time for initial samples and rates, which need more than one sample. Check the last-collected timestamp before relying on a chart.
History is unavailable while the server cannot be reached. Collection failures do not by themselves stop the application. A chart is not an external uptime check, and response-time histograms are estimates rather than individual request traces.
Set history retention
Open Resource pools → your pool → Monitoring and find History retention. With project write permission, enter a whole number of days and select Save retention. The current default is 7 days and the supported range is 1–90 days; the form shows the server’s actual settings.
The setting applies to the pool and all its applications. It does not redeploy or restart them.
Reducing retention permanently removes older measurements after confirmation. Increasing it later cannot restore them. Storage safeguards may shorten history before the selected retention period.
Where history lives
History survives Crane restarts and application redeployments on the same disk. Deleting or replacing that disk removes it. The monitoring page displays storage usage and collection warnings. This local history is not centrally backed up by Infralane.
Metrics are unavailable
- Check the pool’s connection and last-contact state.
- Confirm the server runs the current monitoring-capable Crane release.
- Use the page’s retry action and wait for collection.
- If traffic charts alone are empty, verify the app has public HTTP routing and redeploy when a routing update is required.
- Read any disk-space or retention warning before expecting more history.
For a customer-owned server, monitoring uses its existing outbound connection. Do not expose the Crane management port to fix an empty chart. See Server maintenance.