Micro-metrics Monitoring (M3) Mode

Micro-metrics Monitoring (M3) Mode (opens new window) is a predictive monitoring feature in the yc-360 script that proactively detects early signs of performance degradation in your application. By continuously collecting lightweight system and runtime metrics, including JVM metrics for Java applications, CLR metrics for .NET applications, and event loop and memory metrics for Node.js applications. It helps forecast problems before they impact end users, such as potential OutOfMemoryErrors in Java, memory pressure issues in .NET, or event loop blocking in Node.js.

Choose your environment to follow step-by-step instructions:

1. Create a directory for yc-360 script

mkdir -p /opt/workspace/yc-360
cd /opt/workspace/yc-360

2. Download the latest yc-360 script

wget https://tier1app.com/dist/ycrash/yc-360-latest.zip

3. Extract the downloaded zip file

unzip yc-360-latest.zip

4. After unzipping, navigate to the linux directory. Inside this directory, select the yc-360 script that matches your server's architecture (amd64 or arm64).

5. Download the YAML Configuration File: Use the following command to download the sample yc-config.yaml configuration template.

wget https://tier1app.com/dist/docs/yc-360-script/m3-mode/yc-config.yaml

Replace the placeholders in the YAML configuration file with your actual values:

• {API_KEY}: Your API key was provided with your license at the time of registration. If you're not sure where to find the API key, click here (opens new window).
• {http://MY_YC_SERVER:PORT}: URL of the yCrash server (e.g., http://localhost:8080/). If you're not sure where to find the Server URL, click here (opens new window).
• {JAVA_HOME}: The directory path where Java is installed in your environment.
• {TOKEN_TO_IDENTIFY_PROCESS}: A unique keyword to identify your Java process. To learn more about this argument, click here.
• {APPLICATION_NAME}: Friendly name for the application (displayed in the yCrash dashboard).

For a full list of arguments, refer to the All yc-360 Script Arguments page.

6. Execute yc-360 Script: Run the script with:

For Java applications:

./yc -c yc-config.yaml -m3

For Node.js applications:

Before running the script, make sure your Node.js application has the yCrash hook loaded. This is a one time setup step on the application side, separate from running yc-360 itself. See Node.js Diagnostic Capture for how to configure it.

./yc -c yc-config.yaml -m3 -appRuntime=nodejs

IMPORTANT TIP:

For Java applications:

• 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?

---

For Node.js applications:

• The yc-360 script must be executed with the same user privileges as the Node.js application.

• The yCrash hook must already be loaded in the target process before the script runs. It can't attach to an application after the fact. See Node.js Diagnostic Capture for setup.

• GC Log auto discovery works out of the box on Linux, as long as the application was started with --trace-gc.

1. Create a directory for yc-360 script

mkdir -p /opt/workspace/yc-360
cd /opt/workspace/yc-360

2. Download the latest yc-360 script

wget https://tier1app.com/dist/ycrash/yc-360-latest.zip

3. Extract the downloaded zip file

unzip yc-360-latest.zip

4. After unzipping, navigate to the mac directory. Inside this directory, select the yc-360 script that matches your server's architecture (amd64 or arm64).

5. Download the YAML Configuration File: Use the following command to download the sample yc-config.yaml configuration template.

wget https://tier1app.com/dist/docs/yc-360-script/m3-mode/yc-config.yaml

Replace the placeholders in the YAML configuration file with your actual values:

• {API_KEY}: Your API key was provided with your license at the time of registration. If you're not sure where to find the API key, click here (opens new window).
• {http://MY_YC_SERVER:PORT}: URL of the yCrash server (e.g., http://localhost:8080/). If you're not sure where to find the Server URL, click here (opens new window).
• {JAVA_HOME}: The directory path where Java is installed in your environment.
• {TOKEN_TO_IDENTIFY_PROCESS}: A unique keyword to identify your Java process. To learn more about this argument, click here.
• {APPLICATION_NAME}: Friendly name for the application (displayed in the yCrash dashboard).

For a full list of arguments, refer to the All yc-360 Script Arguments page.

6. Execute yc-360 Script: Run the script with:

For Java applications:

./yc -c yc-config.yaml -m3

For Node.js applications:

Before running the script, make sure your Node.js application has the yCrash hook loaded. This is a one time setup step on the application side, separate from running yc-360 itself. See Node.js Diagnostic Capture for how to configure it.

./yc -c yc-config.yaml -m3 -appRuntime=nodejs

IMPORTANT TIP:

For Java applications:

• 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?

---

For Node.js applications:

• The yc-360 script must be executed with the same user privileges as the Node.js application.

• The yCrash hook must already be loaded in the target process before the script runs. It can't attach to an application after the fact. See Node.js Diagnostic Capture for setup.

• GC Log auto discovery works out of the box on macOS, as long as the application was started with --trace-gc.

1. Download: Download the latest version of the yc-360 script from here (opens new window).

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

cd windows

3. Create YAML Configuration File: Download sample YAML configuration file: yc-config.yaml (opens new window).

Replace the placeholders in the YAML configuration file with your actual values:

• {API_KEY}: Your API key was provided with your license at the time of registration. If you're not sure where to find the API key, click here (opens new window).
• {http://MY_YC_SERVER:PORT}: URL of the yCrash server (e.g., http://localhost:8080/). If you're not sure where to find the Server URL, click here (opens new window).
• {JAVA_HOME}: The directory path where Java is installed in your environment. The j argument is required for Java applications only. Not applicable for .NET applications.
• {TOKEN_TO_IDENTIFY_PROCESS}: A unique keyword to identify your target application process. To learn more about this argument, click here.
• {APPLICATION_NAME}: Friendly name for the application (displayed in the yCrash dashboard).

For a full list of arguments, refer to the All yc-360 Script Arguments page.

4. Execute yc-360 Script: Run the script with:

For Java applications:

.\yc -c yc-config.yaml -m3

For .NET applications:

.\yc -c yc-config.yaml -m3 -appRuntime=dotnet

For Node.js applications:

Before running the script, make sure your Node.js application has the yCrash hook loaded. This is a one time setup step on the application side, separate from running yc-360 itself. See Node.js Diagnostic Capture for how to configure it.

.\yc -c yc-config.yaml -m3 -appRuntime=nodejs

IMPORTANT TIP:

For Java applications:

• 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?

---

For .NET applications:

• Ensure Event Tracing for Windows (ETW) is enabled in your environment. It is required to capture .NET artifacts. To learn more, visit ETW Privileges and Environment Requirements (opens new window)

• The yc-360 script must be run with administrator permissions to capture .NET artifacts.

• Heap dumps are not captured for .NET applications. Instead, the script captures lightweight heap substitute data for memory analysis.

---

For Node.js applications:

• The yCrash hook must already be loaded in the target process before the script runs. It can't attach to an application after the fact. See Node.js Diagnostic Capture for setup.

• GC Log capture on Windows requires -nodejsGCLogPath pointing at your application's redirected output file. There's no auto discovery on this platform. See nodejsGCLogPath.

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.

For Node.js applications, set NODE_OPTIONS as an environment variable on your application's container before you start it. See Node.js Diagnostic Capture for the full setup, including how to point both sides at a shared runtime directory in a containerized deployment.

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.

For Node.js applications, set NODE_OPTIONS in your pod's container env spec before the pod starts. See Node.js Diagnostic Capture for the full setup.

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.

For Node.js applications, set NODE_OPTIONS in your pod's container env spec before the pod starts. See Node.js Diagnostic Capture for the full setup.

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

1. 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.

2. Fargate on EKS COMING SOON

For Node.js applications, set NODE_OPTIONS on your application's container definition before it starts. See Node.js Diagnostic Capture for the full setup.

Sample YAML Configuration File

version: '1'
options:
  k: mycompany@aeiou-c3eb-4c9a-8254-f000d07245cc
  s: "http://ycrash.mycompany:8080/"
  j: "/usr/lib/jvm/java-XX-openjdk-amd64/"
  processTokens:
    - buggyApp.jar$myApp1
  accessLogs:
    - /var/log/nginx/access.log$myApp1
  accessLogFormats:
    - "%h %l %u %t %r %s %b %D$myApp1"
  accessLogSources:
	- Apache$myApp1

First Incident Report

To help you get familiar with the incident reporting workflow, the yc-360 script is designed to automatically generate a sample incident report the first time it runs. This is known as the first-incident.

If no prior M3 incidents exist in the yCrash dashboard, the yc-360 script will submit this first-incident within the interval defined by m3Frequency (default: 3 minutes) of its initial launch. This feature allows you to explore the dashboard and understand how incident data is displayed and analyzed—even if no real issues have occurred yet.

Note: This sample report is generated only once, tagged as first-incident, and only if no existing M3 incident is present in the dashboard.