Create an informative issue (See each section, incomplete templates/issues won't be triaged)

Using the current documentation as a model, please complete the issue template. 

Note: Doc team updates the current version and the two previous versions (n-2). For earlier versions, we will address only high-priority, customer-reported issues for releases in support.

Prerequisite: Start with what we have

documentation at https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.9/html/observability/searching-in-the-console-intro#creating-search-configurable-collection

Describe the changes in the doc and link to your dev story

Provide info for the following steps:

1. - [X] Mandatory Add the required version to the Fix version/s field.

(this affects 2.9.2 and previous 2.9)

2. - [X] Mandatory Choose the type of documentation change.

      - [ ] New topic in an existing section or new section
      - [X] Update to an existing topic

3. - [ ] Mandatory for GA content:
            
       - [ ] Add steps and/or other important conceptual information here: 
       
            
       - [ ] Add Required access level for the user to complete the task here:
       

       - [ ] Add verification at the end of the task, how does the user verify success (a command to run or a result to see?)
     
     
       - [ ] Add link to dev story here:

4. - [X] Mandatory for bugs: What is the diff? Clearly define what the problem is, what the change is, and link to the current documentation:

The current documentation does not include an example to filter out argoproject applications :

 DeniedResources: |-
   - apiGroups:
       - argoproj.io
     resources:
       - applications 

another less drastic would remove secret for argoprojects

 DeniedResources: |-
   - apiGroups:
       - argoproj.io
     resources:
       - secrets 

The first example is used for a bug where the search collector excessively logs what should be warnings and should get resolved with 2.9.3 as it stands while the second is maybe more practical.

We could use to extend the documentation with info on how to find which apigroups and ressources can be used in filter rules as it is currently implied that the customer will know what is valid which is not guaranteed at all.