For a long-running application using Hibernate, which ORM-level metrics would you actually export to a monitoring system, which would you deliberately leave off, and what does the collection itself cost?

## The question behind the question An interviewer asking this wants to know whether you can distinguish a debugging tool from a production signal. Almost everything Hibernate exposes is useful for ten minutes on a laptop; only a subset earns a permanent place in a production system, and one or two items are actively misleading if graphed. ## What to export, and what each one answers **Statement volume per unit of work.** `getPrepareStatementCount()` rated per second, divided by request rate, gives statements-per-request. A step change after a deploy is the single most actionable ORM signal there is: it catches fan-out regressions that latency graphs only show later and less clearly. **Entity and collection activity.** Load, fetch, insert, update, delete counts, plus `getCollectionFetchCount()`. Comparing load count to statement count tells you how much work is being satisfied without a round trip; comparing collection fetch count to parent load count tells you whether associations are being pulled one at a time. **Transaction health.** `getTransactionCount()` versus `getSuccessfulTransactionCount()` yields a rollback rate, which is a decent early warning for contention or validation failures. `getFlushCount()` relative to transaction count exposes code that forces flushes in a loop. **Session leaks.** `getSessionOpenCount()` minus `getSessionCloseCount()` should stay flat. A steadily growing difference means sessions (and their persistence contexts, and possibly connections) are not being released — a memory leak with a slow fuse. **Cache effectiveness per region.** Hits, misses and puts, per region, not just globally. The hit ratio decides whether a region should exist. Global numbers hide the common case where one hot region carries the whole ratio while three others are pure overhead. ## What to leave off **Stateful maxima.** `getQueryExecutionMaxTime()` and `getQueryExecutionMaxTimeQueryString()` are high-water marks since the last `clear()`. Graph them and you get a monotonic staircase that pins to the worst cold-start query forever. If you want latency, take percentiles from a JDBC-level timer or from the database's statement statistics. **Per-statement logs as a standing configuration.** `org.hibernate.SQL` at DEBUG produces one event per statement. At a few thousand statements per second that is a serious share of your CPU, your log pipeline and your storage bill, and it is worst exactly during an incident. **Bound parameter values, ever.** The bind loggers dump raw column values. That is personal data in a log aggregator with different access controls from your database. Debug-only, short-lived, ideally on a non-production copy. **Unbounded per-query maps.** `getQueries()` keys by query string. Parameterised HQL and named queries give a bounded set. String-concatenated SQL with inlined literals gives you a new key per distinct value and a memory leak inside your metrics. ## The cost model Statistics collection is a handful of concurrent counter increments per operation. On a single-threaded benchmark that is unmeasurable; at high concurrency, shared counters are cache-line contention, and 'unmeasurable' becomes 'a percent or two'. That is usually a fine trade for the visibility, but it is a trade — make it consciously, and measure it once on your own workload rather than repeating a folk number. The asymmetric risk is the query map, not the counters. Audit for non-parameterised SQL before turning statistics on permanently. ## The layered baseline I would set 1. **Always on, negligible cost**: `hibernate.use_sql_comments=true` — every statement carries its origin, which makes the database's own statement log self-explanatory and bridges ORM and engine views for free. 2. **Always on, small cost**: the slow-query threshold, so pathological single statements page you without logging the healthy ones. 3. **Always on if queries are parameterised**: `generate_statistics`, with the counters above exported and rated. 4. **On demand only**: full statement logging, bind-value logging, and per-request statement-count capture — enabled on one instance, for a window, with a rollback plan. 5. **Outside the ORM**: database statement statistics ranked by total time. Hibernate can tell you what it asked for; only the engine can tell you what actually cost the most across all clients. ## The judgement to voice ORM metrics are leading indicators of a class of defect (fan-out, leaks, useless caches) that latency and error-rate dashboards detect late. They are not a substitute for database-side truth, and they must never become a channel through which user data leaves the database and lands in a log index.