Governance, Monitoring, and Observability
Governance
What to know
Governance is about organizing and controlling cost and access at scale. Compartments are the primary boundary for policies, quotas, budgets, and cost reporting; design a hierarchy that mirrors the organization and keep the root tenancy clean. Tags come in two kinds: freeform (key/value with no governance) and defined tags created in a tag namespace with a schema. Tag defaults applied to a compartment automatically tag new resources, which is how you get consistent cost allocation. Cost analysis, budgets with alerts (actual or forecast), usage reports, and quotas (per compartment, per resource family) complete the toolkit.
OCI Organizations lets you manage child tenancies under a parent for consolidated billing and governance. Understand that quotas limit resource creation and budgets only notify - neither one blocks spending by itself.
Traps
- Thinking a budget stops spending - it only raises alerts.
- Assuming tags are inherited by existing resources; tag defaults apply only to resources created afterwards.
- Placing quotas on the root when the intent was to cap one team's compartment.
- Forgetting that defined tags require a namespace and can be enforced through policy.
Rule of thumb
Design compartments by environment and team, attach a budget and quota to each leaf compartment, and use defined tags plus tag defaults with keys such as CostCenter and Environment so every resource is attributable without relying on human discipline.
Monitoring and Observability
What to know
Observability in OCI centers on four services: Monitoring (metrics and alarms), Logging (service logs, custom logs, log groups, agent configurations), Notifications (topics and subscriptions), and Events (reactive rules on resource state changes). Service Connector Hub moves data between them - for example logs to Object Storage or to a stream. Logging Analytics adds search and correlation over logs, Application Performance Monitoring traces applications, and Ops Insights covers capacity and SQL insights.
Metrics are emitted per compartment and resource; an alarm evaluates a metric against a threshold over an interval and fires a notification or an action. The Monitoring agent is required for guest OS metrics the hypervisor cannot see, such as memory and disk utilization on a VM.
Traps
- Expecting memory metrics without the agent - they are not available from the hypervisor.
- Confusing Events (react to a state change such as instance termination) with alarms (react to a metric threshold).
- Forgetting that a notification subscription must be confirmed before messages arrive.
- Assuming logs are collected automatically; you must enable a log or an agent configuration.
Worked example
Alert when a production instance's CPU exceeds 80% for five minutes: create an alarm in the production compartment on the CPU metric, set the interval and threshold, attach a notification topic with an email subscription, and confirm the subscription email. Add a separate Events rule to notify on instance termination.