Add more labels to the firewall metrics

[phibos]

To identify the firewall metrics only the name label is used. The name label is a wired combination of different information like chain, the action and the comment. If available also the out_interface and the protocol are appended to the name label.

The name is generated by the following code.

mktxp/mktxp/collector/firewall_collector.py

Lines 84 to 91 in 4ee006a

	name = f"| {firewall_record.get('chain', ' ')} | {firewall_record.get('action', ' ')} | {firewall_record.get('comment', ' ')}"
	bytes = firewall_record.get('bytes', 0)
	out_interface = firewall_record.get('out_interface')
	protocol = firewall_record.get('protocol')
	if out_interface:
	name = f"{name} | {out_interface}"
	if protocol:
	name = f"{name} | {protocol}"

Let's assume we have at least two rules in the input chain with action=accept and you did not provide a comment. The name will look like | input | accept | and at least one metric will be dropped by Prometheus and marked as duplicated as reported in #164 . Also using only one label with a combination of different information makes filtering the required information harder.

Current implementation:

Current metric names:

IPv4

• firewall_filter
• firewall_raw
• firewall_nat
• firewall_mangle

IPv6

• firewall_filter_ipv6
• firewall_raw_ipv6
• firewall_nat_ipv6
• firewall_mangle_ipv6

Labels:

• name - Described above

Idea

The main idea is to add more labels to identify the firewall rules and get additional filter options. But this will also result in a new metric if only one config option changes like the src-port or the comment for more information see the Label sections below.

Metric names

IPv4

• firewall_rule_ipv4_bytes
• firewall_rule_ipv4_packets

IPv6

• firewall_rule_ipv6_bytes
• firewall_rule_ipv6_packets

Lables

Default labels (should be present for most rules)

• module = raw | filter | mangle | nat
• action
• jump-target
• chain
• comment
• disabled
• dynamic

Additional labels (only present if changed in the RouterOS config)

• dst-address
• dst-address-list
• dst-address-type
• dst-port
• in-bridge-port
• in-bridge-port-list
• in-interface
• in-interface-list
• ipsec-policy
• out-bridge-port
• out-bridge-port-list
• out-interface
• out-interface-list
• port
• protocol
• src-address
• src-address-list
• src-address-type
• src-port
• connection-nat-state
• connection-state

Migration

We can add a new config option like firewall_ipv4_next and firewall_ipv6_next and let the user decide which one to use or to combine both. After some month/versions we make the new collector the default one.

@akpw @fortellerq what do you think? Comments are welcome.

[fortellerq]

Hello @phibos, thank you for circling back on this topic,
I think I understand the problem and couldn't see a better solution. If anything, implementing it the way you described could potentially help identify duplicates in routers configuration, if present. I was thinking if numeric value could be used, but if someone would add new entry at the top of filter rules, that would invalidate all previously existing firewall rules and skew the statistics.