Delete Duplicate Decoder App Rules

[DarenPrevost]

I am in the process of cleaning my Decoders App Rules that have a few App Rules that have the same “Condition” but with slight differences in their rule name and session options. I would like to know if I can remove the rules that have the same duplicate “Conditions” even though they have different names and session flags.

Also, If I can remove the duplicate rules with the same conditions regardless of the session options/flags and names can I remove the rule with the name nw600005, because i would rather keep the rule that has a more readable description of what the rule is?

As an example;

Name                                       Condition                                                                                flag session with rule name in meta key

nw600005                               service = 53 && udp dstport = 1-52,54-u && stream = 2      alert.id

Name                                       Condition                                                                                flag session with rule name in meta key

DNS over non standard port service = 53 && udp dstport = 1-52,54-u && stream = 2      alert

[JohnKisner · Accepted solution]

@DarenPrevost 

The Application Rules that begin with nw are ones that are generally used by content that has been created by NetWitness and is used by other application rules, alerts, and reports. Do you know if the second "DNS over non-standard port" rule was created by your team or if it was installed on the decoder from Live/CCM? 

When it comes to clearing out Application Rules it really depends on what you are using to control the deployment of content. Are you using CCM or Live directly?

[DarenPrevost · Accepted solution]

Sorry for the delay. Good to know about the purpose of the nw application rules. I think that the "DNS over non-standard port" rule was a live rule however may have been modified at some time before me. I was using "DNS over non-standard port" as an example but there are many rules that have the same conditions but have a variation in the original name and have a different "Flag Option". 

We are not using CCM and we download/upload the app rules and packages from live.

The reason i originally post this question was because ever since we upgraded to 12.4.2.0 we have been getting non-stop swap issues and "FileSystem/Mounted Filesystem Disk Usage Percent" errors and and from what i was reading the errors could be caused by app rules. As a result i am trying to clean things up.

[JohnKisner · Accepted solution]

@DarenPrevost 

Thank you for providing the additional information. The swap errors are generally erroneous unless you are seeing performance issues with the servers that are producing the alarm. The OS will allocate swap but does not always release it. This is due to something within the OS trying to be helpful. The idea is that it allocates the swap ahead of time and holds onto it just incase you should need it quickly for processes. As such the OS allocates more swap then may actually be used by any one service on the server just in case it is needed. We have seen this health & wellness alarm a lot over the years and have found that in 98% of the alarm cases this is what is actually happening. That is why I mentioned that you only really need to pay attention to this alarm if there is a performance issue being experienced on that particular server. Most customers make a copy of the alert rule that this alarm is a part of, disable the original rule and in the copied rule, disable the swap alarm and reactivate the rule. 

When it comes to the filesystem /Mounted filesystem disk usage percentage alarm, this depends on the configuration of the database partitions. Generally the partitions should be set at 95% of the space for the partition. This space allocation is visible in the Explorer view of the service that is alarming. If you can provide a df -h from one of the servers that is having this alarm plus what it says under Explore view in the database -> config node where the meta.dir, session.dir, and/or packet.dir are set I might be able to provide more specific direction for how to fix this particular issue.