Adminadvanced
Monitoring, Alerting & Capacity Planning
Explain how a production OBIEE/OAC deployment is proactively monitored for health and capacity, closing the loop from reactive troubleshooting to preventive operations.
Every other administration topic is reactive. This is the discipline that reduces how often the reactive work is needed.
It's like the difference between a car that only tells you something's wrong when the engine actually stops (purely reactive) versus one with a dashboard tracking oil life, tire wear, and fuel efficiency trends over time, warning you well before a part actually fails and letting you schedule maintenance on your own terms instead of getting stranded on the highway.
Key Concepts
1
System level.
JVM heap and garbage collection pauses
thread pool saturation
BI Server and Presentation Services process health
disk: the catalog, logs, and the cache
CPU and memory per node2
Heap is the leading indicator for the middle tier. A JVM approaching its limit spends increasing time
collecting garbage, so response times degrade gradually before anything fails. Trending heap catches it
while it is still a trend.
3
Application level, from usage tracking.
average and 95th percentile query time
cache hit rate
concurrent users, by hour
queries failing
the slowest analyses by total time4
Cache hit rate is the quiet one. It drops when seeding stops matching what users run — after a
dashboard changes, or when the seeding agent silently fails. Response times worsen across the board and
nothing points at the cause.
5
What to alert on, as opposed to collect.
a component down
heap above 85% sustained
queries failing above a threshold
the nightly ETL or the cache seed did not complete
disk above 85%6
Alert on things that are silently wrong. A system that is plainly down produces its own alert — the
users. The value is in the failures nobody sees: the agent that stopped sending, the seed that stopped
running, the reject count climbing.
7
Capacity planning is the other half. Concurrency by hour, growth in users and in data volume, and the
duration of the nightly batch.
8
the batch finished at 03:00 a year ago
it finishes at 05:30 now9
Nothing has failed. The trend says it will overrun the business day in a few months, and that is a
conversation to have now rather than on the morning it happens.
10
The point of the discipline. Not to have more dashboards about the system. To know, before users do,
which of these is heading the wrong way — and to have the evidence when asking for the hardware or the time
to fix it.
11
What the interviewer is probing.1. "What would you monitor on a BI platform?" Probing: the operational discipline. Stalls:
"Is it up?" Moves up: query response times, concurrent sessions, failed queries, cache hit rate,
JVM heap and the data source queue.
12
2. "Why is cache hit rate worth watching?" Probing: the insight. Stalls: "It is not." *Moves
up:* a sudden drop usually means a purge is firing too aggressively or the data is reloading more
often — and users feel it immediately.
13
3. "How do you plan capacity?" Probing: the method. Stalls: "Buy more." Moves up: from
usage tracking trends — concurrent users at peak and query mix — rather than total licensed users,
which is never the load.
14
4. "What is the leading indicator of trouble?" Probing: the maturity. Stalls: "Errors."
Moves up: response times creeping up at peak while nothing fails — by the time queries error,
users stopped trusting the platform weeks earlier.