Deploy to GitHub pages

Author: github-actions[bot]

Developing/os/Health-Information/index.html

@@ -12,7 +12,34 @@
 <span class=w>                    </span><span class=nt>num_oid</span><span class=p>:</span><span class=w> </span><span class=s>&#39;.1.3.6.1.4.1.5528.100.4.1.5.1.2.{{</span><span class=nv> </span><span class=s>$index</span><span class=nv> </span><span class=s>}}&#39;</span>
 <span class=w>                    </span><span class=nt>descr</span><span class=p>:</span><span class=w> </span><span class=s>&#39;{{</span><span class=nv> </span><span class=s>$airFlowSensorLabel</span><span class=nv> </span><span class=s>}}&#39;</span>
 <span class=w>                    </span><span class=nt>index</span><span class=p>:</span><span class=w> </span><span class=s>&#39;airFlowSensorValue.{{</span><span class=nv> </span><span class=s>$index</span><span class=nv> </span><span class=s>}}&#39;</span>
-</code></pre></div> <p>At the top you can define one or more mibs to be used in the lookup of data:</p> <p><code>mib: NETBOTZV2-MIB</code> For use of multiple MIB files separate them with a colon: <code>mib: NETBOTZV2-MIB:SECOND-MIB</code></p> <p>For <code>data:</code> you have the following options:</p> <p>The only sensor we have defined here is airflow. The available options are as follows:</p> <ul> <li><code>oid</code> (required): This is the name of the table you want to snmp walk for data.</li> <li><code>value</code> (optional): This is the key within the table that contains the value. If not provided will use <code>oid</code></li> <li><code>num_oid</code> (required for PullRequests): If not provided, this parameter should be computed automatically by discovery process. This parameter is still required to submit a pull request. This is the numerical OID that contains <code>value</code>. This should usually include <code>{{ $index }}</code>. the string to the equivalent OID representation.</li> <li><code>divisor</code> (optional): This is the divisor to use against the returned <code>value</code>.</li> <li><code>multiplier</code> (optional): This is the multiplier to use against the returned <code>value</code>.</li> <li><code>low_limit</code> (optional): This is the critical low threshold that <code>value</code> should be (used in alerting). If an OID is specified then divisor / multiplier are used.</li> <li><code>low_warn_limit</code> (optional): This is the warning low threshold that <code>value</code> should be (used in alerting). If an OID is specified then divisor / multiplier are used.</li> <li><code>warn_limit</code> (optional): This is the warning high threshold that <code>value</code> should be (used in alerting). If an OID is specified then divisor / multiplier are used.</li> <li><code>high_limit</code> (optional): This is the critical high threshold that <code>value</code> should be (used in alerting). If an OID is specified then divisor / multiplier are used.</li> <li><code>descr</code> (required): The visible label for this sensor. It can be a key with in the table or a static string, optionally using <code>{{ index }}</code>.</li> <li><code>group</code> (optional): Groups sensors together under in the webui, displaying this text. Not specifying this will put the sensors in the default group. If group is set to <code>transceiver</code> it will be shown with the port instead of in with all the generic sensors (You must also set <code>entPhysicalIndex</code> to ifIndex)</li> <li><code>index</code> (optional): This is the index value we use to uniquely identify this sensor. <code>{{ $index }}</code> will be replaced by the numeric <code>index</code> of this row in the table the snmp walk.</li> <li><code>skip_values</code> (optional): This is an array of values we should skip over (see note below).</li> <li><code>skip_value_lt</code> (optional): If sensor value is less than this, skip the discovery.</li> <li><code>skip_value_gt</code> (optional): If sensor value is greater than this, skip the discovery.</li> <li><code>entPhysicalIndex</code> and <code>entPhysicalIndex_measured</code> (optional) : If the sensor belongs to a physical entity then you can link them here. The currently supported variants are :<ul> <li><code>entPhysicalIndex</code> contains the entPhysicalIndex from entPhysical table, and <code>entPhysicalIndex_measured</code> is NULL</li> <li><code>entPhysicalIndex</code> contains "ifIndex" value of the linked port and <code>entPhysicalIndex_measured</code> contains "ports"</li> </ul> </li> <li><code>user_func</code> (optional): You can provide a function name for the sensors value to be processed through (i.e. Convert fahrenheit to celsius use <code>fahrenheit_to_celsius</code>)</li> <li><code>snmp_flags</code> (optional): this sets the flags to be sent to snmpwalk, it overrides flags set on the sensor type and os. The default is <code>'-OQUb'</code>. A common issue is dealing with string indexes, setting <code>'-OQUsbe'</code> will change them to numeric oids. Setting <code>['-OQUsbe', '-Pu']</code> will also allow _ in oid names. You can find more in the <a href=https://linux.die.net/man/1/snmpcmd>Man Page</a></li> <li><code>rrd_type</code> (optional): You can change the type of the RRD file that will be created to store the data. By default, type GAUGE is used. More details can be found here: https://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html</li> </ul> <p>For <code>options:</code> you have the following available:</p> <ul> <li><code>divisor</code>: This is the divisor to use against the returned <code>value</code>.</li> <li><code>multiplier</code>: This is the multiplier to use against the returned <code>value</code>.</li> <li><code>skip_values</code>: This is an array of values we should skip over (see note below).</li> <li><code>skip_value_lt</code>: If sensor value is less than this, skip the discovery.</li> <li><code>skip_value_gt</code>: If sensor value is greater than this, skip the discovery.</li> </ul> <p>Multiple variables can be used in the sensor's definition. The syntax is <code>{{ $variable }}</code>. Any oid in the current table can be used, as well as pre-fetched data. The index ($index) and the sub_indexes (in case the oid is indexed multiple times) are also available: if $index="1.20", then $subindex0="1" and $subindex1="20".</p> <p>If you want access a string in an index, <code>{{ $index_string }}</code> can be used, optionally suffixed with a format string to specify how to extract the string. <code>{{ $index_string:nns }}</code> will skip two numeric indexes and return the string after. <code>{{ $index_string:nss }}</code> will skip one numeric index and one string index and return next string after.</p> <h4 id=fetching-values-from-other-tablesoids>Fetching values from other tables/oids</h4> <p>When referencing an oid in another table the full index will be used to match the other table. If the indexes of the two tables don't match, you will need to specify which indexes to use by their index position starting with 0. The data for the other table must be fetched already.</p> <p><code>{{ IF-MIB::ifName:2 }}</code></p> <p>This simple example shows using the 3rd (0 is the first) index value from the current table to fetch the IF-MIB::ifName value from the data.</p> <p>Additionally, you may specify multiple index values with either a range or list of index positions.</p> <p>Range: <code>{{ IP-MIB::ipAddressPrefixOrigin:0-3 }}</code> List: <code>{{ IP-MIB::ipAddressPrefixOrigin:2.3.1.4 }}</code></p> <h4 id=skipping-rows-of-the-returned-data>Skipping rows of the returned data</h4> <p>You can filter rows of the data returned to only discover valid sensors. This is often useful when devices always return all sensors possible or mix sensor types in a single table.</p> <blockquote> <p><code>skip_values</code> can also compare items within the OID table against values. The index of the sensor is used to retrieve the value from the OID, unless a target index is appended to the OID. Additionally, you may check fields from the device. Comparisons behave on a logical OR basis when chained, so only one of them needs to be matched for that particular sensor to be skipped during discovery. An example of this is below:</p> </blockquote> <div class=highlight><pre><span></span><code><span class=w>                    </span><span class=nt>skip_values</span><span class=p>:</span>
+</code></pre></div> <p>At the top you can define one or more mibs to be used in the lookup of data:</p> <p><code>mib: NETBOTZV2-MIB</code> For use of multiple MIB files separate them with a colon: <code>mib: NETBOTZV2-MIB:SECOND-MIB</code></p> <p>For <code>data:</code> you have the following options:</p> <p>The only sensor we have defined here is airflow. The available options are as follows:</p> <ul> <li><code>oid</code> (required): This is the name of the table you want to snmp walk for data.</li> <li><code>value</code> (optional): This is the key within the table that contains the value. If not provided will use <code>oid</code></li> <li><code>num_oid</code> (required for PullRequests): If not provided, this parameter should be computed automatically by discovery process. This parameter is still required to submit a pull request. This is the numerical OID that contains <code>value</code>. This should usually include <code>{{ $index }}</code>. the string to the equivalent OID representation.</li> <li><code>divisor</code> (optional): This is the divisor to use against the returned <code>value</code>.</li> <li><code>multiplier</code> (optional): This is the multiplier to use against the returned <code>value</code>.</li> <li><code>low_limit</code> (optional): This is the critical low threshold that <code>value</code> should be (used in alerting). If an OID is specified then divisor / multiplier are used.</li> <li><code>low_warn_limit</code> (optional): This is the warning low threshold that <code>value</code> should be (used in alerting). If an OID is specified then divisor / multiplier are used.</li> <li><code>warn_limit</code> (optional): This is the warning high threshold that <code>value</code> should be (used in alerting). If an OID is specified then divisor / multiplier are used.</li> <li><code>high_limit</code> (optional): This is the critical high threshold that <code>value</code> should be (used in alerting). If an OID is specified then divisor / multiplier are used.</li> <li><code>descr</code> (required): The visible label for this sensor. It can be a key with in the table or a static string, optionally using <code>{{ index }}</code>.</li> <li><code>group</code> (optional): Groups sensors together under in the webui, displaying this text. Not specifying this will put the sensors in the default group. If group is set to <code>transceiver</code> it will be shown with the port instead of in with all the generic sensors (You must also set <code>entPhysicalIndex</code> to ifIndex)</li> <li><code>index</code> (optional): This is the index value we use to uniquely identify this sensor. <code>{{ $index }}</code> will be replaced by the numeric <code>index</code> of this row in the table the snmp walk.</li> <li><code>skip_values</code> (optional): This is an array of values we should skip over (see note below).</li> <li><code>skip_value_lt</code> (optional): If sensor value is less than this, skip the discovery.</li> <li><code>skip_value_gt</code> (optional): If sensor value is greater than this, skip the discovery.</li> <li><code>entPhysicalIndex</code> and <code>entPhysicalIndex_measured</code> (optional) : If the sensor belongs to a physical entity then you can link them here. The currently supported variants are :<ul> <li><code>entPhysicalIndex</code> contains the entPhysicalIndex from entPhysical table, and <code>entPhysicalIndex_measured</code> is NULL</li> <li><code>entPhysicalIndex</code> contains "ifIndex" value of the linked port and <code>entPhysicalIndex_measured</code> contains "ports"</li> </ul> </li> <li><code>user_func</code> (optional): You can provide a function name for the sensors value to be processed through (i.e. Convert fahrenheit to celsius use <code>fahrenheit_to_celsius</code>)</li> <li><code>snmp_flags</code> (optional): this sets the flags to be sent to snmpwalk, it overrides flags set on the sensor type and os. The default is <code>'-OQUb'</code>. A common issue is dealing with string indexes, setting <code>'-OQUsbe'</code> will change them to numeric oids. Setting <code>['-OQUsbe', '-Pu']</code> will also allow _ in oid names. You can find more in the <a href=https://linux.die.net/man/1/snmpcmd>Man Page</a></li> <li><code>rrd_type</code> (optional): You can change the type of the RRD file that will be created to store the data. By default, type GAUGE is used. More details can be found here: https://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html</li> </ul> <p>For <code>options:</code> you have the following available:</p> <ul> <li><code>divisor</code>: This is the divisor to use against the returned <code>value</code>.</li> <li><code>multiplier</code>: This is the multiplier to use against the returned <code>value</code>.</li> <li><code>skip_values</code>: This is an array of values we should skip over (see note below).</li> <li><code>skip_value_lt</code>: If sensor value is less than this, skip the discovery.</li> <li><code>skip_value_gt</code>: If sensor value is greater than this, skip the discovery.</li> </ul> <p>Multiple variables can be used in the sensor's definition. The syntax is <code>{{ $variable }}</code>. Any oid in the current table can be used, as well as pre-fetched data. The index ($index) and the sub_indexes (in case the oid is indexed multiple times) are also available: if $index="1.20", then $subindex0="1" and $subindex1="20".</p> <p>To fetch data not available to your sensor you can use <code>additional_oids</code>.</p> <div class="admonition note"> <p class=admonition-title>Note</p> <p><code>additional_oids</code> should only be used when data is not fetched by your sensor.</p> </div> <p><code>additional_oids</code> can also be used within a class. This is the preferred way if the <code>additional_oids</code> are only used inside the class. See <code>additional_oids</code> in the <code>temperature</code> class below aswell as <code>additional_oids</code> on the <code>sensors</code> level.</p> <div class="admonition note"> <p class=admonition-title>Note</p> <p>Only one <code>additional_oids</code> statements should be used for the same oid and this is only an example showing both cases.</p> </div> <div class=highlight><pre><span></span><code>sensors:
+    additional_oids:
+        data:
+            -
+                oid:
+                    - Stulz-WIB8000-MIB::unitsettingName
+    temperature:
+        additional_oids:
+            data:
+                -
+                    oid:
+                        - Stulz-WIB8000-MIB::unitsettingName
+        data:
+            -
+                oid: unitTemperature
+                value: unitTemperature
+                num_oid: &#39;.1.3.6.1.4.1.29462.10.2.1.1.1.1.1.1.1.1170.{{ $index }}&#39;
+                index: &#39;unitTemperature.{{ $index }}&#39;
+                descr: &#39;Unit {{ Stulz-WIB8000-MIB::unitsettingName:0-1 }} temp&#39;
+                divisor: 10
+            -
+                oid: unitSupplyAirTemperature
+                value: unitSupplyAirTemperature
+                num_oid: &#39;.1.3.6.1.4.1.29462.10.2.1.1.1.1.1.1.1.1193.{{ $index }}&#39;
+                index: &#39;unitSupplyAirTemperature.{{ $index }}&#39;
+                descr: &#39;Unit {{ Stulz-WIB8000-MIB::unitsettingName:0-1 }} supply temp&#39;
+                divisor: 10
+</code></pre></div> <p>If you want access a string in an index, <code>{{ $index_string }}</code> can be used, optionally suffixed with a format string to specify how to extract the string. <code>{{ $index_string:nns }}</code> will skip two numeric indexes and return the string after. <code>{{ $index_string:nss }}</code> will skip one numeric index and one string index and return next string after.</p> <h4 id=fetching-values-from-other-tablesoids>Fetching values from other tables/oids</h4> <p>When referencing an oid in another table the full index will be used to match the other table. If the indexes of the two tables don't match, you will need to specify which indexes to use by their index position starting with 0. The data for the other table must be fetched already.</p> <p><code>{{ IF-MIB::ifName:2 }}</code></p> <p>This simple example shows using the 3rd (0 is the first) index value from the current table to fetch the IF-MIB::ifName value from the data.</p> <p>Additionally, you may specify multiple index values with either a range or list of index positions.</p> <p>Range: <code>{{ IP-MIB::ipAddressPrefixOrigin:0-3 }}</code> List: <code>{{ IP-MIB::ipAddressPrefixOrigin:2.3.1.4 }}</code></p> <h4 id=skipping-rows-of-the-returned-data>Skipping rows of the returned data</h4> <p>You can filter rows of the data returned to only discover valid sensors. This is often useful when devices always return all sensors possible or mix sensor types in a single table.</p> <blockquote> <p><code>skip_values</code> can also compare items within the OID table against values. The index of the sensor is used to retrieve the value from the OID, unless a target index is appended to the OID. Additionally, you may check fields from the device. Comparisons behave on a logical OR basis when chained, so only one of them needs to be matched for that particular sensor to be skipped during discovery. An example of this is below:</p> </blockquote> <div class=highlight><pre><span></span><code><span class=w>                    </span><span class=nt>skip_values</span><span class=p>:</span>
 <span class=w>                    </span><span class="p p-Indicator">-</span>
 <span class=w>                      </span><span class=nt>oid</span><span class=p>:</span><span class=w> </span><span class="l l-Scalar l-Scalar-Plain">sensUnit</span>
 <span class=w>                      </span><span class=nt>op</span><span class=p>:</span><span class=w> </span><span class=s>&#39;!=&#39;</span>