I'm trying to set up a rule that will send an email any time an event comes in from a specific tool alias. Do rules specifically have to use Events or can they use Event Groups like [Any Alert]?
I'm not sure why this doesn't work. Logically I would think it would. But I never get the actual email for this rule even after sending some test data that should trigger the rule.
Some background on using Any Alert/Event in rules that you may find interesting... (as you discovered there's no inherent technical limitation to doing it, I'm guessing the restart either cleared up some queued events during the re-mapping of your rules or some other system issue like time that was just a coincidence)
On startup or activation of rules, LEM takes all your rules and maps them, the first layer against the event taxonomy, then the fields, and so on. When a new event comes in, a "copy" (reference) is sent to rules, database, and connected console(s). The rules copy is evaluated against the big map. If there aren't any rules for that event, that event doesn't get held in memory and it's instead immediately recycled. If you do have rules for that event, we pass it on and examine it for the next level. The downside of using Any Alert is that every event has to be checked against the next level down of the map, which can affect performance.
So IF you can use a more specific slice of events it CAN be more performant, think of it like an optimization. We have also made and continue to make performance improvements on the appliance side to account for these scenarios better and try to optimize the engine around them (or in spite of them? depending on your perspective), so that it's fast to evaluate the criteria and doesn't have to stick around for as long in that simple case like you posted (well, simplest is "exists" but that would be nuts because every event would send you an email 
).
The reason you don't see the Source/Destination fields in the available fields also exposes another limitation, which is that the fields presented are least common denominator, so all you see are the fields that all events have in common (which with Any Alert/Event is the basic set).
And there's your "the more you know" of the day.
Some background on using Any Alert/Event in rules that you may find interesting... (as you discovered there's no inherent technical limitation to doing it, I'm guessing the restart either cleared up some queued events during the re-mapping of your rules or some other system issue like time that was just a coincidence)
On startup or activation of rules, LEM takes all your rules and maps them, the first layer against the event taxonomy, then the fields, and so on. When a new event comes in, a "copy" (reference) is sent to rules, database, and connected console(s). The rules copy is evaluated against the big map. If there aren't any rules for that event, that event doesn't get held in memory and it's instead immediately recycled. If you do have rules for that event, we pass it on and examine it for the next level. The downside of using Any Alert is that every event has to be checked against the next level down of the map, which can affect performance.
So IF you can use a more specific slice of events it CAN be more performant, think of it like an optimization. We have also made and continue to make performance improvements on the appliance side to account for these scenarios better and try to optimize the engine around them (or in spite of them? depending on your perspective), so that it's fast to evaluate the criteria and doesn't have to stick around for as long in that simple case like you posted (well, simplest is "exists" but that would be nuts because every event would send you an email ).
The reason you don't see the Source/Destination fields in the available fields also exposes another limitation, which is that the fields presented are least common denominator, so all you see are the fields that all events have in common (which with Any Alert/Event is the basic set).
And there's your "the more you know" of the day.
