Tasks for managing rules include managing the rules, as well as the actions, event types, and attributes that make up the rules. See How Events Works for more information on rules.
Action resources: You must have resources already set up to specify as an action. The Events service invokes the action specified in the rule by delivering the event message to action resources, which can include topics , streams, or functions. Every rule must have at least one action. The Events service can invoke any of the following services by delivering an event message for processing:
IAM policies: To manage or list rules, you must be given the required type of access in a policy written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform a task and get a message that you don't have permission or are unauthorized, confirm with your administrator the type of access you have been granted and which compartment you should work in. For more information, see Events and IAM Policies.
Event messages: To create rules, the resources you want to monitor with the rule must emit events. For more information, see Services that Produce Events.
Working with Rules 🔗
Note
Each rule can have a maximum of 10 actions.
A typical workflow for setting up rule might follow this pattern:
Identify action resources
Set up or identify whatever action resources you intend to use with the rule. For
example, you might set up a Notifications topic
and create subscriptions for the DevOps team so that they are notified when
backups complete. If a topic already exists, you can use it instead of creating
a topic. The resources you specify for actions do not have to be in the same
compartment as the rule.
Plan filtering
Ensure the resources that you want to monitor emit events to the Events service and plan your pattern matching
strategy. For example, you might want to monitor backups on Autonomous Database for Analytics and Data Warehousing instances in the
ABC compartment. Ensure Autonomous Database for Analytics and Data Warehousing instances emit an event type you can use to create the automation you
require. Review the example JSON event to determine the best way to identify
those resources in filters. See Matching Events with Filters and
Services that Produce Events.
Create the rule
Rules apply to events in the compartment in which you create them and any child
compartments. Create a rule in the compartment with the resource you want to
monitor and specify where to deliver matching events. For example, in the ABC
compartment, you might create a rule that filters for Autonomous Database for Analytics and Data Warehousing backup events. Since
Events has no requirement about the location
of action resources, you could specify a topic in the XYZ compartment as the
resource to deliver any matching events.
Managing Tags for Rules 🔗
You can apply tags to your resources to help you organize them according to your business needs. You can apply tags at the time you create a resource, or you can update the resource later with tags. For general information about applying tags, see Resource Tags.
Tags and Event Filtering 🔗
With Events, you can also use tags to target resources in your tenancy. You target resources by adding the tag to a filter in a rule. A filter tag helps you hone automation by targeting only resources that contain a particular tag. For example, let's say you have dozens of Database instances in your tenancy, but only a few of the most critical of these instances have the tag "Operations." You could create a rule that triggers a particular action for resources that only contain the "Operations" tag.
Policy for working with filter tags is no different from policy for working with tags.
You can move rules from one compartment to another. When you move a rule to a new compartment, you stop monitoring events from resources in the current compartment and begin monitoring events in the new compartment (and any child compartments). After you move the rule to the new compartment, inherent policies apply immediately and affect access to the rules through the Console. Moving rules doesn't affect access by the Events service to actions defined in rules. For more information, see Managing Compartments.
Monitoring Rules 🔗
You can monitor the health, capacity, and performance of Oracle Cloud Infrastructure resources by using metrics, alarms, and notifications. For more information, see Monitoring and Notifications.
For more information about monitoring the rules you create, see Events Metrics.
Object Events and the Events Service 🔗
Events for objects are handled differently than other resources. Objects do not emit events by default. Use the Console, CLI, or API to enable a bucket to emit events for object state changes. You can enable events for object state changes during or after bucket creation. See Enabling or Disabling Emitting Events for Object State Changes for more information.