rule evaluation and alert clearing in Robinhood v3

[garadar]

Hello,

I am trying to better understand how rule evaluation works in Robinhood v3 alert policies.

Context

My goal is simple:

• Raise an alert when a file matches a condition (e.g. last_access > X)
• Clear the alert when the file no longer matches this condition

All files belong to the same fileclass (e.g. user_file).

---

Observed behavior

From my understanding and testing:

• Rules are evaluated in order
• A rule is selected based on target_fileclass
• When a file matches a rule’s target_fileclass, evaluation stops, even if the condition is false
• The default rule is not applied if the file already matches a previous rule’s fileclass ( cf. Policy rule default)

This makes it difficult to express a simple transition such as:

IF condition → alert
ELSE → clear

within a single policy and fileclass.

---

Questions

• Is this behavior expected, or am I misunderstanding how rules are intended to be used?
• What is the recommended best practice to implement clearing of alerts when a file no longer matches a condition?
• Is it acceptable to define fileclasses based on attributes like last_access, or is this discouraged?

As WorkArround, I tried the third question and defined a class based on last_access and apply a rule on it:

### Alers rules
alert_rules {

    rule Old_Files {
        target_fileclass = old_file;
        action = cmd("/etc/robinhood.d/scripts/unige_alert.sh -d /srv/beegfs/scratch/log/robinhood/report/ -f {fullpath} -r OldFiles ");
        condition = true;
    }


  # clear alert status
rule default {
    action = none;
    action_params { alert = clear; }
    # apply to all entries that don't match 'raise_alert'
    condition { alert.status == alert }
    }

}

But i get this expected warning message:

2026/05/25 17:16:03 [2698682/1] PolicyCheck | WARNING: in FileClass 'old_file', line 180: time-based conditions should be specified in policy condition instead of file class definition

So what the best practice here ?

Thank you for your clarification.

[mickaelsv]

Hello !

Is this behavior expected, or am I misunderstanding how rules are intended to be used?

This behavior is expected. As an example, if you use the hsm module, you are more likely to want to do something like :
"Is this kind of file matching my conditions ? If yes, do this specific action, if no, do nothing".
You want more to have a default rule for the "kind of files" you may have forgotten, but you don't want to apply a default rule to a "well defined" file.

What is the recommended best practice to implement clearing of alerts when a file no longer matches a condition?

You can define these two fileclasses for example :

FileClass f1 {                                                                                                                                                                            
    definition { type == file and name == "file.1" and alert.status != "alert" }
}

FileClass f1_alert {                                                                                                                                                                      
    definition { type == file and name == "file.1" and alert.status == "alert" }
}

You are matching on the alert.status directly, which is what you would like to have in your case. It may not be the best implementation if you have a lot of fileclasses, but this at least seems to work.

In that case, depending on the usage you want:
If you want to send an alert for already "alert" files when running the policy, you can use :

    rule raise_alert {
        target_fileclass = f1;                                                                                                                                                    
        action_params { title = "entry matches '{fileclass}' ({rule})"; }                                                                                                                         
        condition { alert.last_check > 20s }                                                                                                                                                  
    }                                                                                                                                                                                         
                                                                                                                                                                                              
    rule clear_alert {                                                                                                                                                                        
        target_fileclass = f1_alert;                                                                                                                                                          
        action = none;                                                                                                                                                                        
        action_params { alert = clear; }                                                                                                                     
        condition { alert.last_alert > 10s }                                                                                                                                                  
    } 

last_check is the last time you checked via a policy the alert status.
last_alert is the last time you raised an alert
In that case, after 20 seconds, if a file is still matching your other alert conditions, the alert status will become "clear" and then "alert" in the same policy run. Which can be what you want if you want to send multiple alerts while the user does not fix the problem, for example.

example :

• file.1 matches the conditions to raise an alert
• policy is ran and file.1 is set to alert
• alert is sent
• "time between the two policy runs"
• file.1 still matches the conditions to be in an alert
• policy is ran again, and file.1 is set as cleared and directly after, re set to alert
• alert is re-sent for file.1

If you want to send an alert only once, remove the conditions on the alerts. It will have the following behavior :

• file.1 matches the conditions to raise an alert
• policy is ran and file.1 is set to alert
• alert is sent
• "time between the two policy runs"
• file.1 still matches the conditions to be in an alert
• policy is ran again, and file.1 is not changed
• alert is not re-sent for file.1

Is it acceptable to define fileclasses based on attributes like last_access, or is this discouraged?

You prefer to avoid this behavior for performance and coherence reasons. Basically, the access time is re calculated in robinhood when it is asked by a condition, but it is not clear that it is done when mapping a file to a fileclass. And if you enable the update on every access for example, each ls will send a request to robinhood, which is something you want to avoid for performances reasons.

[garadar]

Hello @mickaelsv

Thank you for your detailed answer.
I would like to raise an alert for files that have not been accessed for XX days, in order to get better visibility via the diagram in webui.
I have already tried to define an alerted_files fileclass based on alert.status, but I am getting a flood of log messages like this:

robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/12] Policy | D8E7E870/15583194231045764730: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/10] Policy | D8E7E870/6920680967527924198: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/17] Policy | D8E7E870/46427217058806297: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/23] Policy | D8E7E870/10522294402646305998: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/14] Policy | D8E7E870/674786584693917765: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/7] Policy | D8E7E870/5666857667413389038: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/6] Policy | D8E7E870/677712411878170321: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/25] Policy | D8E7E870/13631888042290973112: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/7] Policy | D8E7E870/4527718453021834115: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/18] Policy | D8E7E870/5328166839695068516: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/14] Policy | D8E7E870/15936964708780432556: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/11] Policy | D8E7E870/7876880523401404413: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/6] Policy | D8E7E870/14578347078430856704: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/24] Policy | D8E7E870/6306988721152450623: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/7] Policy | D8E7E870/6549835168453900735: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/14] Policy | D8E7E870/2404392539069784606: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/7] Policy | D8E7E870/10677190844331623882: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/24] Policy | D8E7E870/7453991262933660542: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/20] Policy | D8E7E870/7008738873718697959: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/7] Policy | D8E7E870/4262373529628149464: attribute is missing for checking fileset 'alerted_files'

This happens for each file that does not already have the alert attribute defined.
I then defined a similar policy to yours. It works, but the logs become unreadable.
Do you have a solution for this?

[mickaelsv]

Hello,
Can you describe what do you mean when you say "the logs become unreadable" (if you can share them) ?

From my understanding, the attribute is missing is there because, by default, the alert status is set to ' "" ' by default, not 'clear'. Something that can maybe erase these errors would be to set the alert status of each file as "clear" by default, if defining the file with alert.status != "alert does not work.

You also need to run a command that alters the database when you first define the alert status, but I believe you already did it.

Do you also get the error "attribute is missing" when you define the fileclass as following ?

    definition { type == file and name == "file.1" and alert.status != "alert" }

I will try to reproduce it on my side, sorry for the delay for the answer.

[garadar]

Hello @mickaelsv

Thank for the answer;

Can you describe what do you mean when you say "the logs become unreadable" (if you can share them) ?

I give you the logs in the previous message:

robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/12] Policy | D8E7E870/15583194231045764730: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/10] Policy | D8E7E870/6920680967527924198: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/17] Policy | D8E7E870/46427217058806297: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/23] Policy | D8E7E870/10522294402646305998: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/14] Policy | D8E7E870/674786584693917765: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/7] Policy | D8E7E870/5666857667413389038: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/6] Policy | D8E7E870/677712411878170321: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/25] Policy | D8E7E870/13631888042290973112: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/7] Policy | D8E7E870/4527718453021834115: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/18] Policy | D8E7E870/5328166839695068516: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/14] Policy | D8E7E870/15936964708780432556: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/11] Policy | D8E7E870/7876880523401404413: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/6] Policy | D8E7E870/14578347078430856704: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/24] Policy | D8E7E870/6306988721152450623: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/7] Policy | D8E7E870/6549835168453900735: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/14] Policy | D8E7E870/2404392539069784606: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/7] Policy | D8E7E870/10677190844331623882: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/24] Policy | D8E7E870/7453991262933660542: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/20] Policy | D8E7E870/7008738873718697959: attribute is missing for checking fileset 'alerted_files'
robinhood_scratch.log-20260523.gz:2026/05/21 15:59:43 [1826394/7] Policy | D8E7E870/4262373529628149464: attribute is missing for checking fileset 'alerted_files'

(And i get thousand/Millions lines likes this, logs can not be "readable" for human)

From my understanding, the attribute is missing is there because, by default, the alert status is set to ' "" ' by default, not 'clear'.
I got the same understanding.

Something that can maybe erase these errors would be to set the alert status of each file as "clear" by default, if defining the file with alert.status != "alert does not work.

I go it but I would like to keep alert.clear for file that have been in alerted status but coming back to clear and alert status undifiened for "immaculate" files . But I have to admin it's just a confort. I can handle the fact I need to clear the alertfirst

You also need to run a command that alters the database when you first define the alert status, but I believe you already did it.

Maybe I do not remember correctly if it was for this specific case, but the log ask me to run rbh-config alter_db once.

Do you also get the error "attribute is missing" when you define the fileclass as following ?

definition { type == file and name == "file.1" and alert.status != "alert" }

I didn't test this case. I will after my holidays; coming back at begening of July