yc-360 Script: One Script to Capture 360° Production Artifacts

What is yc-360 Script?

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	Why It’s Important
Application Log	The primary troubleshooting artifact. It helps you identify exceptions, timeouts, performance degradations, and business logic errors that directly explain application malfunctions.
GC Log	Records garbage collection activity and helps you identify frequent collections, long pauses, and memory overuse that degrade application throughput and latency.
Thread Dump	Captures a snapshot of all JVM threads and helps you identify deadlocks, BLOCKED threads, threads stuck on external calls, or runaway CPU-consuming threads.
Heap Dump	Provides a complete memory snapshot of the JVM and helps you identify memory leaks, objects retaining excessive references, and inefficient data structures.
Heap Substitute	Offers a lightweight version of heap details when full heap dumps are restricted or too large. Helps you understand object growth and memory allocation patterns.
top	Displays system-wide CPU and memory utilization and helps you identify whether system resources are saturated. It also reveals if other processes are consuming CPU or memory and whether CPU cycles are stolen by the kernel or hypervisor.
ps	Lists all running processes and helps you identify zombie, orphaned, or unexpected processes that consume resources or interfere with application performance.
top -H	Shows CPU usage at the thread level and helps you pinpoint which thread within the JVM or another process is consuming excessive CPU time.
Disk Usage (df -h)	Displays available and used disk space and helps you identify low-disk or full-disk conditions that can lead to logging failures, crashes, or corrupted writes.
dmesg	Shows kernel-level system messages and helps you identify hardware issues, driver failures, Out-of-Memory (OOM) kills, and kernel panics affecting system stability.
netstat	Lists active network connections, open ports, and listening sockets and helps you identify stuck connections, port conflicts, or network floods.
ping	Measures network reachability and latency to remote endpoints and helps you identify network disconnections, packet loss, or routing delays.
vmstat	Reports virtual memory, I/O, and CPU scheduling metrics and helps you identify paging, swapping, CPU run queue build-up, blocked processes, and I/O waits.
iostat	Displays disk I/O throughput, utilization, and latency statistics and helps you identify slow or overloaded disks that contribute to high response times or bottlenecks.
Kernel Parameters	Lists important OS tuning parameters and helps you identify misconfigurations such as low file descriptor limits, restricted socket buffers, or suboptimal memory settings.
Extended Data	Captures any additional scripts or diagnostic data you configure. Helps you include application-specific, framework-specific, or environment-specific metrics for deeper analysis.
Metadata	Collects system and JVM details such as hostname, OS version, uptime, and JVM version, helping you correlate incidents across environments or reproduce problems accurately.

Why you need yc-360 Script?

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.

Getting Started - How to run the yc-360 Script?

It's easy to get started with the yc-360 script. Just follow the simple steps given below. In a matter of seconds, you’ll be able to trigger the script and collect all the critical artifacts needed for troubleshooting.

Linux

1. Download: Download the latest version of the yc-360 script from here

2. Extract: Unzip the package and navigate to the linux directory:

unzip yc-360-latest.zip
cd linux

3. Execute yc-360 Script: Run the script with your target application's process ID:

When you execute the below command, the yc-360 script will capture all the artifacts/logs from the target JVM & host for analysis. Captured artifacts will be compressed into a zip file and stored in the directory where the above command was executed. The zip file will have the name in the format: 'yc-YYYY-MM-DDTHH-mm-ss.zip'. Example: 'yc-2024-09-23T14-02-42.zip'.

./yc -onlyCapture -p {PID} -j {JAVA_HOME} -a {APPLICATION_NAME}

INFO:

• {PID}: This is the process ID of your Java application. Not sure how to find process Id? Learn here. Alternatively, you can pass Unique Token that will uniquely identify the process in container. What is Unique Token?

• {JAVA_HOME}: The directory path where Java is installed in your environment.

• {APPLICATION_NAME}: Friendly name for the application (displayed in the yCrash dashboard).

IMPORTANT TIP:

• The yc-360 script must be executed with the same user privileges as the Java application. For example, if the application runs under the tomcat-user user, yc-360 script must also be executed by tomcat-user user.

• To detect memory-related issues, GC logging must be enabled for your application. You can enable GC logging by using the JVM arguments listed here.

• The yc-360 script doesn't capture heap dump by default. Pass -hd argument to capture heap dump. For more information, please visit How to Capture Heap Dump?

MacOS

1. Download: Download the latest version of the yc-360 script from here.

2. Extract: Unzip the package and navigate to the mac directory:

unzip yc-360-latest.zip
cd mac

3. Execute yc-360 Script: Run the script with your target application's process ID:

When you execute the below command, the yc-360 script will capture all the artifacts/logs from the target JVM & host for analysis. Captured artifacts will be compressed into a zip file and stored in the directory where the above command was executed. The zip file will have the name in the format: 'yc-YYYY-MM-DDTHH-mm-ss.zip'. Example: 'yc-2024-09-23T14-02-42.zip'.

./yc -onlyCapture -p {PID} -j {JAVA_HOME} -a {APPLICATION_NAME}

INFO:

• {PID}: This is the process ID of your Java application. Not sure how to find process Id? Learn here. Alternatively, you can pass Unique Token that will uniquely identify the process in container. What is Unique Token?

• {JAVA_HOME}: The directory path where Java is installed in your environment.

• {APPLICATION_NAME}: Friendly name for the application (displayed in the yCrash dashboard).

IMPORTANT TIP:

• The yc-360 script must be executed with the same user privileges as the Java application. For example, if the application runs under the tomcat-user user, yc-360 script must also be executed by tomcat-user user.

• To detect memory-related issues, GC logging must be enabled for your application. You can enable GC logging by using the JVM arguments listed here.

• The yc-360 script doesn't capture heap dump by default. Pass -hd argument to capture heap dump. For more information, please visit How to Capture Heap Dump?

Windows

1. Download: Download the latest version of the yc-360 script from here.

2. Extract: Unzip the package and navigate to the windows directory:

cd windows

3. Execute yc-360 Script: Run the script with your target application's process ID:

When you execute the below command, the yc-360 script will capture all the artifacts/logs from the target JVM & host for analysis. Captured artifacts will be compressed into a zip file and stored in the directory where the above command was executed. The zip file will have the name in the format: 'yc-YYYY-MM-DDTHH-mm-ss.zip'. Example: 'yc-2024-09-23T14-02-42.zip'.

.\yc -onlyCapture -p {PID} -j {JAVA_HOME} -a {APPLICATION_NAME}

INFO:

• {PID}: This is the process ID of your Java application. Not sure how to find process Id? Learn here. Alternatively, you can pass Unique Token that will uniquely identify the process in container. What is Unique Token?

• {JAVA_HOME}: The directory path where Java is installed in your environment.

• {APPLICATION_NAME}: Friendly name for the application (displayed in the yCrash dashboard).

IMPORTANT TIP:

• The yc-360 script must be executed with the same user privileges as the Java application. For example, if the application runs under the tomcat-user user, yc-360 script must also be executed by tomcat-user user.

• To detect memory-related issues, GC logging must be enabled for your application. You can enable GC logging by using the JVM arguments listed here.

• The yc-360 script doesn't capture heap dump by default. Pass -hd argument to capture heap dump. For more information, please visit How to Capture Heap Dump?

Docker

You can run the yc-360 script in a Docker environment using one of the following approaches, depending on your deployment setup and monitoring preferences:

1. Run yc-360 Script in Sidecar Container – Run the script in a separate container alongside your application container.

2. Run yc-360 Script in Same Container – Embed the yc-360 script directly inside the application container.

3. Run yc-360 Script on Host – Run the script on the host that is running your Docker containers.

Kubernetes

You can run the yc-360 script in a Kubernetes environment using one of the following approaches, depending on your deployment setup and monitoring preferences:

1. Run yc-360 Script in Sidecar Container – Add yc-360 as a separate container in your pod spec.

2. Run yc-360 Script in Same Container – Install and run the script directly inside your application container.

OpenShift

To monitor applications running in OpenShift, deploy the yc-360 script using:

Run yc-360 Script in Sidecar Container– Add yc-360 alongside your application within the pod template.

AWS Fargate

You can run the yc-360 script in an AWS Fargate environment using one of the following approaches, depending on your orchestration platform:

Fargate on ECS:

Run yc-360 Script in Sidecar Container for ECS Fargate – Add yc-360 as a sidecar container in your ECS task definition to automatically capture metrics and logs from your application container.

How to Analyze the Artifacts Generated by the yc-360-script?

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.

FAQ

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 yc-360 Script 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, 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, yc-360 script is designed to work seamlessly across all major environments — including bare-metal servers, virtual machines, Docker containers, Kubernetes, and OpenShift. You can execute the script directly inside your containers or use it as part of a sidecar or init container to collect diagnostic data. For detailed guidance on each supported environments, visit https://docs.ycrash.io/yc-360/environment/introduction.html

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 the yc-360 script?

You have two options:

• Manual Analysis: You can analyze individual artifacts using specialized tools like gceasy.io for GC logs, fastThread.io for thread dumps, heaphero.io for heap dumps, or Eclipse MAT.

• Automated Unified Analysis: You can upload the entire artifact bundle to yCrash.io using the Bundle Upload feature for a comprehensive 360° root cause analysis. For more details, refer to the Bundle Upload documentation.

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 execution permission is set for the yc-360 script and Read/Write permissions for 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.

12. How to Build the yc-360-script?

Please refer to any one of the following links if you want to build the yc-360-script in that corresponding operating system:

1. Build yc-360-script in Linux
2. Build yc-360-script in MacOS
3. Build yc-360-script in Windows