-
Notifications
You must be signed in to change notification settings - Fork 360
How to Use USR1 Trap for Diagnostics
Utako Ueda edited this page Mar 9, 2016
·
1 revision
If your cloud controller is in a bad state (infinite loop, resource spike, etc.), you may wish to do a diagnostic dump to get more information than is available in the CF logs. This data includes stack traces for running threads and other general metrics.
- SSH into the rogue Cloud Controller’s vm
-
cat /var/vcap/sys/run/cloud_controller_ng/cloud_controller_ng.pid
to get the PID of the process -
kill -USR1 [pid]
You will need root access. This will NOT terminate the CC process. - The diagnostics directory is likely
/var/vcap/data/cloud_controller_ng/diagnostics
, but if it is not, look for the diagnostics key in/var/vcap/jobs/cloud_controller_ng/config/cloud_controller_ng.yml
- In the diagnostics directory, you will find a json file with diagnostic information.
-
Pipelines
-
Contributing
- Tips and Tricks
- Cloud Controller API v3 Style Guide
- Playbooks
- Development configuration
- Testing
-
Architectural Details
-
CC Resources
- Apps
- Audit Events
- Deployments
- Labels
- Services
- Sidecars
-
Dependencies
-
Troubleshooting
- Ruby Console Script to Find Fields that Cannot Be Decrypted
- Logging database queries in unit tests
- Inspecting blobstore cc resources and cc packages(webdav)
- How to Use USR1 Trap for Diagnostics
- How to Perf: Finding and Fixing Bottlenecks
- How to get access to mysql database
- How To Get a Ruby Heap Dumps & GC Stats from CC
- How to curl v4 internal endpoints with mtls
- How to access Bosh Director console and restore an outdated Cloud Config
- Analyzing Cloud Controller's NGINX logs using the toplogs script
-
k8s
-
Archive