> For the complete documentation index, see [llms.txt](https://docs.nexthink.com/platform/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexthink.com/platform/user-guide/using-finder-classic/monitoring-it-custom-metrics-with-finder-classic/examples-of-metrics-in-finder-classic.md).
# Examples of metrics in Finder (classic)
{% hint style="info" %}
Nexthink Finder is a Windows-only desktop application whose functionality is now available within the Nexthink web interface. Nexthink can now be used directly from a browser and most functions no longer require an additional desktop application.
{% endhint %}
## Overview
Creating a new metric may be a daunting task for beginners because of the many options available. To help you with the creation of metrics, let us walk through a first example that covers the creation of three metrics, each one of a different type: count, quantity, and top. Then let us explore how to create a quantity metric based on the output of a remote action.
The first example gets information on binaries that are considered dangerous. To that end, we propose the creation of three metrics, which the reader can later refine and expand:
* Devices executing dangerous binaries (Count metric)
Count the number of devices that execute dangerous binaries.
* Cumulated execution time of dangerous binaries (Quantity metric)
Measure how long your devices were exposed to the execution of dangerous binaries.
* Top most executed dangerous executables (Top metric)
List the top ten executables associated to dangerous binaries by number of executions.
In this example, we consider a binary to be dangerous when its **Threat level** field is set to *high threat*. Nexthink automatically sets the value of this field via the application library. You may later come up with your own definition of a *dangerous* binary and adapt the conditions in the example metrics accordingly.
The second example of a quantity metric gets information about the battery status of laptop devices. As this is not information that Nexthink retrieves by default, we need a remote action that returns on-demand data:
* Average battery health (Quantity metric) with the help of a remote action, retrieves the average battery health of all devices and compares by manufacturer.
For every step in the process of creating metrics that requires the choice of an option, we explain our decision in detail. We assume however that you know the basics of [creating a metric](/platform/user-guide/using-finder-classic/monitoring-it-custom-metrics-with-finder-classic/creating-a-metric-with-finder-classic.md).
## Count metric
The first metric reflects the number of devices impacted by the execution of dangerous binaries.
Create a count metric in Finder and edit its options:
1. Type in the name of the metric: **Devices executing dangerous binaries**.
2. Optional: Type in a description for the metric.
3. In the **RETRIEVE** section, click **devices**.
4. In the **COMPUTE DAILY** section:
1. Select the option **the total number of all devices** to create a *count* metric.
2. Assuming that we might be interested in the status of the antivirus of those devices executing dangerous binaries, choose **Group by *****antivirus up-to-date***** and *****antivirus RTP*** to classify the devices by the update status of their antivirus and their activation of the real-time protection.
5. In the **MATCHING** section:
1. Add the condition **Binary *****Threat level***** is *****high***.
2. Leave the default option **Count devices that meet conditions on *****at least one day***** in period**. We want to count the devices that have executed a dangerous binary at any time within the observed interval (that is, the period that you set in the navigation tool of the web interface when watching the results of the metric). Thus, we do not select the option *the last active day*, which is intended for metrics that have an inventory function.
6. In the **OPTIONS** section:
1. Tick the box **Include ratio** without including any new condition. In this way, you compare the number of impacted devices with the total number of devices.
2. Tick the box and select the option **Include *****variation indicator only***. We do not need to set any threshold and we keep the default option for the sense of the variation: an increase in the value of the metric is bad (red arrow up) and a decrease of its value is good (green arrow down).
3. Optional: Tick any of the **Additional display fields** that you want to add.
## Quantity metric
### From aggregate values
As a second metric, let us measure how long dangerous binaries have been executing on the devices.
Create a new metric and edit its options:
1. Type in the name of the metric: **Cumulated execution of dangerous binaries**.
2. Optional: Type in a description for the metric.
3. In the **RETRIEVE** section, click **devices**, since quantity metrics can only be selected for devices.
4. In the **COMPUTE DAILY** section:
1. Select the second option to create a *quantity* metric and build the sentence: **the *****cumulated execution duration***** of active devices**.
2. In the **Group by** option, keep the default **- none -** as we do not need to break down the results.
3. In the **Aggregate by** option, select **sum over all devices and the whole timeframe**. We are interested in the total execution time over all devices and not in the average execution time per device, which is the other available option.
5. In the **MATCHING** section:
1. Add the condition **Binary *****Threat level***** is *****high***.
6. In the **OPTIONS** section:
1. Tick the box and select the option **Include *****variation indicator and two thresholds***. We want to set warning and error conditions if the cumulated execution time of dangerous binaries exceeds some values.
2. In the bar to indicate the thresholds, keep the sense of variation (red arrow up, green arrow down) and set the first threshold to **10 min** and the second to **1 hour**.
### From numerical outputs of remote actions
Build a third metric directly based on the [output of a remote action](/platform/user-guide/remote-actions/setting-up-and-managing-remote-actions/creating-remote-actions/writing-scripts-for-remote-actions-on-windows.md) that yields a numerical value. In general, scores let you build quantity metrics for devices based on any kind of output from a remote action, but only numerical outputs are allowed as a direct value in quantity metrics.
To create a quantity metric that measures the average health of the battery on all your devices and compares by manufacturer:
1. Install the required Library pack for the example.
1. Open the Nexthink Library page of the [Battery Status](https://www.nexthink.com/library/battery-status/) pack from your favorite web browser.
2. Click the **Install** button.
2. Log in to Finder as a user with the right to create metrics.
3. Right-click the **Metrics** section and a context menu appears.
4. Select **Create new metric** from the menu.
5. Type in the name of the metric: **Average battery health**.
6. Optional: Type in a description for the metric.
7. In the **RETRIEVE** section, click **devices**, since quantity metrics can only be selected for devices.
8. In the **COMPUTE DAILY** section:
1. Select the second option to create a *quantity* metric and build the sentence: **the *****get Battery Status / Battery1 Health***** of all devices**.
2. In the **Group by** option, select **device manufacturer** as first grouping criterion and **- none -** as the second, to make it possible to break down the results by the manufacturer of the device.
3. In the **Aggregate by** option, select **average value per device**.
9. In the **MATCHING** section:
1. Add the condition **Get Battery Status / Battery1 Health is greater or equal to 0.1** to exclude devices that return zero instead of a valid value.
## Top metric
Finally, let us add a metric that retrieves the top 10 most executed executables whose binary representations are considered dangerous. Remember that an executable in Nexthink groups the different versions (binary images) of a program into a single object. In this case, a metric retrieving executables is probably more convenient than a top metric retrieving the individual binaries. Indeed, having a list of different executables is preferable to seeing different binary versions of the same executable repeated in a list.
Create a new metric and edit its options:
1. Type in the name of the metric: **Top most executed dangerous executables**.
2. Optional: Type in a description for the metric.
3. In the **RETRIEVE** section, click **executables**.
4. In the **COMPUTE DAILY** section:
1. Select the second option to create a *top* metric and build the sentence: **the top *****10***** executables with *****highest number of executions***.
2. In the **Aggregate by** option, select **maximum value per day**. A perfectly valid option would also be **sum over the whole timeframe** to see the total number of executions of each executable. For this example, however, we want to classify the executables by their maximum burst of executions in one day and, in that way, find out the dangerous executables which are run more aggressively. We are also not interested in the other available aggregation option **average value per day**, because we want to detect extreme cases.
5. In the **MATCHING** section:
1. Add the condition **Binary *****Threat level***** is *****high***.
6. In the **OPTIONS** section:
1. Optional: Tick any of the **Additional display fields** that you want to add.
## Conclusion
We hope that these examples have helped you clarify some of the concepts behind the creation of a metric. Keep on reading to know how to create widgets in the web interface to display the values of the metrics in the web interface. For more information on how the web interface computes and presents metric data, [read this article on aggregation and grouping](/platform/references/references-classic/database-information-and-organization-classic/aggregation-and-grouping-classic.md).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.nexthink.com/platform/user-guide/using-finder-classic/monitoring-it-custom-metrics-with-finder-classic/examples-of-metrics-in-finder-classic.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.