it's okay if you leave the Group By.. in the reset condition; it will work but the meaning is slightly different, which may or may not be your intent, and you might be causing the database to do additional work.
In my example the alert manager builds a set of nodes that have had more than 5 SFP-RX-HIGH alerts in the past hour; then it removes alerts from nodes that have not had ANY in the past hour. for the second query it only has to build a set of nodeids that have had SFP-RX-HIGH whereas if you leave the group by it has to maintain a running total of the count and then throw out any with a higher count.
For many sites with small installs (<1000 nodes) this probably doesn't make a difference, but when your syslog table is 13 million rows [1] and you have 10,000 nodes it does.
Note, if your intent is for the alert to reset sooner, e.g. when there are less than three SFP-RX-HIGH per hour then you could write the reset condition like this:
INNERJOIN(SELECTnodeid,Count(*)CS
FROM syslog
WHERE acknowledged=0
ANDmessagetype='SFP-RX-HIGH'
ANDdatetime>Dateadd(hour,-1,Getdate())
GROUP BYnodeid
HAVINGCount(*)< 3 )SM
ONSM.nodeid=nodes.nodeid
[1]caused by a runaway node logging millions of messages an hour for example...