yc-360 script is a simple script that captures 16 different artifacts from your application in a pristine manner, which are highly useful to troubleshoot production problems. Here is the list of artifacts captured by the script:
| Artifact | What It Captures |
|---|---|
| Application Log | Logs generated by your application—useful for identifying functional failures |
| GC Log | Garbage collection activity—helps detect memory overuse, frequent GCs, pauses |
| Thread Dump | Snapshot of all threads in the JVM—key to spotting deadlocks, BLOCKED/stuck threads |
| Heap Dump | Memory snapshot of JVM objects—used to identify memory leaks or heavy objects |
| Heap Substitute | Lightweight version of heap dump when full heap dump isn’t available |
top |
Overall CPU/memory usage of system processes |
ps |
Snapshot of currently running processes |
top -H |
Thread-level CPU usage—helps isolate CPU-intensive threads |
Disk Usage (df -h) |
Available/used disk space—useful when app errors stem from full disks |
dmesg |
Kernel logs—catches low-level system issues like hardware errors or OOM kills |
netstat |
Network connections, open ports, and listening sockets |
ping |
Network latency to external or internal endpoints |
vmstat |
Virtual memory, I/O, and CPU scheduling stats |
iostat |
Disk I/O performance metrics |
| Kernel Parameters | System tuning configurations (like swappiness, max open files) |
| Extended Data | Any custom scripts or data you configure yc-360 script to collect |
| Metadata | Basic system/app metadata (JVM version, hostname, uptime, etc.) |
1. Capture Deeper 360° Artifacts for Root Cause Analysis: Monitoring tools like APMs are excellent at reporting problems such as memory spikes, high CPU usage, or degraded response times. However, when it's time to get to the root cause, you need more than charts and alerts. For example, if memory consumption spikes, you will need a heap dump to identify which objects are leaking. If CPU usage increases, a thread dump is required to trace it back to the exact lines of code causing the spike. The yc-360 script complements your APM by collecting these deeper diagnostic artifacts in a single run—making it much easier and faster to isolate the problem.
2. Accelerate Troubleshooting in Customer On-Prem Environments: In many cases, our application runs on a customer’s infrastructure where we don’t have shell access or real-time visibility. Asking them to send screenshots or partial logs rarely provides enough context to troubleshoot effectively. The yc-360 script solves this by giving you a simple script that the customer can run themselves. It gathers all the essential artifacts across Application, JVM, system, and network layers - so you get everything you need to troubleshoot the issue thoroughly, even without direct access.
3. Forecast Production Incidents During Pre-Release Testing: Before every release, we run performance tests to validate CPU, memory, and response times. But these Macro-Metrics alone don’t reveal deeper risks. yc-360 script enables you to analyze Micro-Metrics like GC throughput, object allocation rate, socket usage, and thread pool behaviors. These overlooked Micro-metrics, signals early signs of instability, giving you a chance to identify the performance issues before they hit production.
It’s easy to get started with the yc-360 script. Just follow the simple steps provided in our Getting Started Guide. In a matter of seconds, you’ll be able to trigger the script and collect all the critical artifacts needed for troubleshooting.
Whether you're running on Linux, Windows, Mac, Docker, K8, … the guide walks you through the setup and execution process.
You can analyze the artifacts captured by yc-360-script either manually or through yCrash server. yCrash server analyzes all the captured data and generates a root cause analysis report instantly. You can use the Bundle upload feature in the yCrash server to analyze the captured 360-degree data.
Please refer to any one of the following links if you want to build the yc-360-script in that corresponding operating system:
1. What if I Want to Capture Additional Data that yc-360 Script Doesn’t Collect by Default?
You can extend the functionality using the -edScript argument. This lets you specify a custom script that yc-360 script will execute as the final step, allowing you to capture additional logs, metrics, or custom files specific to your environment.
2. What is the Overhead of Running yc-360 Script?
The yc-360 script is designed to be lightweight and non-intrusive, ensuring minimal impact on your application's performance. It primarily reads existing system and application data without altering configurations or consuming significant resources. In performance tests conducted on a Linux machine running a Java Spring Boot application, the script demonstrated:
- CPU Usage: Averaging around 0.05%, with occasional spikes up to 3% during data collection.
- Memory Usage: Consistently between 0.1% and 0.2%.
These metrics indicate that yc-360 script can safely run in production environments without causing noticeable overhead. For detailed insights, refer to the yCrash Agent Overhead Performance blog post.
3. Is it Safe to Run yc-360 Script in Production Environments?
Absolutely. The yc-360 script is a non-intrusive, read-only script. It doesn’t modify any application or system configuration. It only reads and collects diagnostics and is safe to run even in high-availability production environments.
4. Can yc-360 Script be Executed in Containerized Environments like Docker, Kubernetes, or OpenShift?
Yes. The yc-360 script supports all major environments including bare-metal, virtual machines, Docker containers, Kubernetes pods, and OpenShift clusters. You can run it directly inside containers or as part of sidecar/init containers for collection.
5. What if I don’t have Direct Access to the Production Environment?
That’s exactly what yc-360 script is built for. You can send the script to your customer or operations team and ask them to run it on your behalf. It generates a ZIP file with all the artifacts, which they can send back to you for analysis.
6. How Much Time Does it Take to Run?
In most environments, yc-360 script completes execution in under 30 seconds. However, collecting heap dumps may take longer depending on the heap size and system performance.
7. What Kind of Issues Can yc-360 Script Help Troubleshoot?
The yc-360 script is effective in diagnosing memory leaks, GC pauses, CPU spikes, thread contention, application freezes, disk pressure, network latency, backend slowness, and more. It provides a 360° snapshot of your application and environment at the time of the issue.
8. Where Can I Analyze the Artifacts Generated by yc-360 Script?
You can use tools like GCeasy.io (for GC logs), fastThread.io (for thread dumps), HeapHero.io. Eclipse MAT (for heap dumps), and yCrash.io for unified 360° analysis.
9. How do I Schedule yc-360 Script to Run Periodically?
You can schedule the script using cron (Linux/macOS), Task Scheduler (Windows), or Kubernetes CronJobs (in container environments). Just ensure the appropriate file write permissions are set in the output directory.
10. Is yc-360 Script Customizable?
Yes. The yc-360 script is designed as a modular shell script. You can clone the repository and customize individual collection commands or add/remove specific artifacts based on your organization’s requirements.
11. Is Support Available for yc-360 Script?
For community support, please use the GitHub Issues page. For enterprise-grade support and integration assistance, visit yCrash.io.