# OEM 24ai Metric Templates and Monitoring Profiles: Stop the Configuration Drift Before It Starts \*EM observability post #5 — the last post covered blackouts and maintenance windows. This one is about why your monitoring thresholds are probably inconsistent across your estate, and how Monitoring Templates fix that permanently.\* \--- Here's what monitoring drift looks like in practice. A DBA tunes the tablespace warning threshold on a production database from 85% to 90% because the application has a regular purge cycle and 85% generates weekly noise. Makes sense. Six months later, that DBA has tuned 12 databases the same way — all done manually through the OEM console, all slightly different because someone had a different idea of the right value on a different day. Meanwhile, 40 other databases still have the OEM default of 85%. And the three databases added last quarter? They have whatever was in the default profile, which nobody reviewed. This is monitoring drift. And it shows up on every large Oracle estate I've worked with that doesn't have Monitoring Templates configured. The problem isn't that people are making bad decisions about these thresholds. The problem is that there's no mechanism to make those decisions once and apply them everywhere. \--- \## What Monitoring Templates Control A Monitoring Template in OEM 24ai is a named collection of monitoring settings for a specific target type. It can define: - **Warning and critical thresholds** — numeric values or pattern matches, depending on the metric type - **Collection schedule** — how frequently the metric is sampled - **Number of occurrences** before an alert triggers — prevents single-sample spikes from generating incidents - **Corrective actions** — automated responses when a threshold is crossed - **Template description** — documentation for the standard and its intended scope When you apply a template, its metric settings are copied to the target. Be deliberate about the apply options: the default preserves thresholds for metrics that are not in the template; using `-replace_metrics=1` clears those thresholds and can stop alerting for them. ## Creating and Applying Templates (EM CLI) OEM 24ai supports template management through the console and EM CLI. For anything at scale — more than a handful of targets, or anything you'll repeat — EM CLI is the right path. \### Create from a tuned target, then export the template To create a baseline from an already tuned target, use the Monitoring Template wizard and choose the option to copy that target's settings. Once the template exists, export it with EM CLI: ```bash emcli export_template \ -name="Prod_DB_Standard" \ -target_type="oracle_database" \ -output_file="/tmp/prod_db_standard.xml" ``` Use `-archive` instead when the template includes a Metric Extension. ### Apply a template to specific targets ```bash emcli apply_template \ -name="Prod_DB_Standard" \ -targets="PRODDB01:oracle_database;PRODDB02:oracle_database;PRODDB03:oracle_database" ``` ### Apply to all members of a group ```bash emcli apply_template \ -name="Prod_DB_Standard" \ -targets="Production_DBs:composite" ``` This is where the leverage kicks in. A single command applies your standard configuration to every database in the group. When you update the template and reapply, every target gets the new values in one operation. ### Validate a target against its standard EM CLI provides `list_templates` to inventory templates, but it does not provide a `get_template_applied` verb. For a target-level check, use the console's **Compare Monitoring Template** workflow or inspect the affected metric settings and template-override flags. That shows whether the target is aligned with the intended standard and whether a documented exception is in effect. ## Administration Groups: Automatic Template Assignment Manual template application works. Administration Groups (AdGroups) make it automatic. An AdGroup is a dynamic group that uses target-property criteria to enroll targets. When a target joins the group, OEM applies the monitoring templates in the group's associated **template collection**; synchronization can run on a schedule or be started on demand. Membership criteria use supported target properties such as Lifecycle Status, Line of Business, Location, Target Type, Target Version, Contact, Cost Center, Department, and Customer Support Identifier. Use the hierarchy to model combinations and exceptions; Administration Group membership is mutually exclusive. **Example AdGroup structure for a typical enterprise:** | AdGroup | Criteria | Template Applied | |---|---|---| | Prod_DBs_AdGroup | Lifecycle = Production | Prod_DB_Standard | | Stage_DBs_AdGroup | Lifecycle = Stage | Stage_DB_Standard | | Dev_DBs_AdGroup | Lifecycle = Development | Dev_DB_Standard | When a new production database is discovered and its Lifecycle Status is set to "Production," it joins the appropriate Administration Group and receives the template collection's monitoring settings at synchronization. The template collection can include a database template plus templates for other target types. ### Setting Up Administration Groups Administration Groups are configured from **Setup -> Add Target -> Administration Groups**. Setup sequence: 1. Create the Administration Group hierarchy and membership criteria 2. Create the monitoring templates 3. Create a template collection and add the required templates (one template per target type) 4. Associate the template collection with the applicable Administration Group 5. Synchronize the group or configure the synchronization schedule A target belongs to at most one Administration Group. Within the hierarchy, settings inherited from a higher level apply to lower levels; for duplicate metric settings, the lower-level template collection takes precedence. ## Exceptions and Precedence OEM does not use a universal four-tier priority stack for monitoring templates. A direct `apply_template` operation writes the selected template settings to its targets. In an Administration Group hierarchy, lower-level template-collection settings override inherited higher-level settings only where the same metric setting is defined. For a documented target-specific exception, set the metric's **Template Override**. A metric marked as a template override is protected from subsequent template applies. Review those overrides regularly, because they are intentional exceptions to the standard. ## Separating Templates by Environment Tier One template for all environments is a common mistake. Dev and production should have meaningfully different configurations: \*\*Production template characteristics:\*\* \- Tighter thresholds — alert sooner because degradation has user impact \- Shorter collection intervals on critical metrics (CPU, active sessions, availability) \- Corrective actions enabled (automated recovery is appropriate in production) \- Number of occurrences = 2-3 for volatile metrics to suppress transient spikes \*\*Development template characteristics:\*\* \- Looser thresholds — developers expect heavy workloads during testing \- Longer collection intervals — less frequent sampling reduces agent overhead on shared dev infrastructure \- No automated corrective actions — a script that restarts a dev database will interrupt someone's active session \- Higher occurrence counts before alerting — less urgency for transient states \*\*Stage template:\*\* closer to production thresholds (you want to catch real issues in staging), but no corrective actions that would interfere with planned test runs. \--- \## Metric Extensions: When Built-in Metrics Aren't Enough OEM 24ai ships with hundreds of built-in metrics for Oracle targets. For cases the built-in set doesn't cover, Metric Extensions let you define custom metrics. Custom metric sources: \- \*\*OS command\*\* — run a shell script on the agent host, parse the output as metric values \- \*\*SQL query\*\* — query the Oracle database directly; the result set becomes the metric data \- \*\*JMX\*\* — pull from Java MBeans (for WebLogic and Java application targets) Once created, a Metric Extension behaves exactly like any built-in metric — it can be included in a Monitoring Template, thresholded, and pushed across your estate. Common use cases: checking for specific initialization parameters your team requires (e.g., \`ARCHIVELOG\` mode, \`ENABLE\_DDL\_LOGGING\`), monitoring application schema objects (queue depths, custom job status tables, application-specific row counts), verifying backup catalog state that OEM doesn't track natively. Create in console: Enterprise -> Monitoring -> Metric Extensions -> Create. \--- \## The Anti-Patterns **Relying on OEM default thresholds in production.** Oracle-supplied defaults are recommended baselines, not a substitute for thresholds calibrated to your workload and service objectives. If normal operation regularly crosses a default threshold, tune it to the environment instead of masking the alerts with suppression rules. **Applying templates manually without AdGroups.** Every new target added to OEM becomes an exception to your standard. The longer you run without AdGroups, the more targets fall outside your standard configuration. Manual application is better than nothing; AdGroups are better than manual. **One template for all environments.** If dev, stage, and production share the same thresholds and collection intervals, you'll either over-alert in dev or under-alert in production. Separate templates per lifecycle tier are non-negotiable on a large estate. **Setting "occurred 1 time" for volatile metrics.** CPU, active sessions, redo generation, and similar metrics can spike transiently during normal operations. If your policy fires on a single sample, you'll generate incidents for events that resolve in the next collection cycle. Set occurrences to 2-3 for performance metrics. **Not documenting threshold rationale.** Six months later, nobody remembers why `Physical Reads` is set to 500K instead of the default. Record the reason in the template description and your operational runbook or change record. "Set to 90% per 2026-03 review — PURGE_JOB runs weekly and fills to 88% before clearing" is useful. "Updated" is not. **Forgetting to synchronize after template updates.** Editing a template changes the repository definition, not the target's active settings. Reapply a directly assigned template with `apply_template`. For Administration Groups, run synchronization on demand or confirm the configured synchronization schedule. ## What Good Looks Like In a well-configured estate, every target type has a template tuned by the team that understands what those metrics mean in that environment. Production, staging, and dev have separate templates. Administration Groups handle enrollment automatically. When a DBA provisions a new database, registers it with OEM, and sets the appropriate target properties, it is enrolled automatically. When application behavior changes, update the template and synchronize the Administration Group—or reapply the template directly—to propagate the new setting. Monitoring drift stops being a problem because there is no easy mechanism for it to accumulate. Individual overrides are documented and intentional. The default state for any target in OEM is "correctly configured," not "whatever the agent shipped with." And when you're asked in an audit or incident review "what is the warning threshold for tablespace usage on production databases?" — the answer is in the template, documented, and consistent across every production database in the relevant Administration Group. ## The Bottom Line Monitoring Templates are the difference between a configuration that was set up once and slowly drifted, and one that's actively managed. The template is the source of truth. AdGroups make application automatic. Metric Extensions handle what the built-in set doesn't cover. The investment is a few hours upfront for a typical estate. The return is years of consistent, trustworthy alerting — and the end of "why is this threshold different on this database" conversations during an incident. Get the templates right, and the monitoring system becomes something the ops team can actually rely on. \--- \*Next in this series: OEM 24ai Compliance Standards and Security Frameworks — how to use OEM's built-in compliance library to continuously assess your Oracle estate against CIS benchmarks, Oracle security baselines, and custom standards, and how to turn compliance scores into actionable remediation workflows.\* \---