The idea for this article was born from the questions I’ve been asked most during presentations, demos, lectures, and meetings—those that keep echoing in your mind after the call ends.
To avoid turning this text into a “grid” that demands ISOs and ultramarathon-level stamina to read, I decided to focus only on the most provocative questions, the ones that truly deserve discussion.
And, as a naturally curious and skeptical person, I went looking for data to guide the answers. Surprise: in many cases, there’s almost no concrete information. In Brazil… it’s practically a desert of numbers.
In the U.S., which dominates about 60% of the global monitoring and observability market, you can find some information—but even there, not everything is as clear as the dashboards promise.
1. Why do monitoring platforms end up “eating” more resources than the application itself?
Imagine this scenario: you have an application that runs database queries, performs read/write operations, processes data. Then you install an observability/monitoring platform (APM, DB monitoring, tracing, etc.)—all to “see what’s going on.” But… this platform also makes calls, collects metrics, queries statistics, tracks events, extracts logs, etc. This means:
- It generates connections to the database (or to agents capturing on hosts) that can compete with the actual application.
- It repeatedly reads system stats (CPU, memory, I/O, latency) and database stats (active sessions, waits, locks, file stats). Example: monitoring dashboards show that “CPU, memory, disk monitoring” on hosts requires continuous probing.
- For real-time observability, metrics may be collected every second or sub-minute, which adds even more overhead.
- In cloud or highly elastic environments, each query or metric can generate IOPS, network traffic, metric/log storage—and that costs both in resources and money.
In other words, the tool meant to “help” can become part of the problem.
2. Approximate ranking of platforms that “consume the most resources”
I didn’t find a public study measuring exact CPU/memory/IOPS/network traffic for every observability tool on the market (unfortunately). But I found indicators and comparisons that allow me to create an approximate ranking based on cost/complexity and potential resource consumption:
| Class | Platform | Reason for High Consumption |
|---|---|---|
| High complexity / enterprise full-stack | Dynatrace / DataDog / New Relic | Covers infrastructure + app + DB + APM + multi-cloud. More data = more collection. |
| Infra + DB/hybrid observability | SolarWinds Observability SaaS | Monitors CPU/memory of apps, infra, DB, network. More hosts/instances = more probes. |
| Specialized DB admin tools | dbsnOOp | Less overhead than full-stack platforms; agent-controlled consumption. |
| Open-source / lightweight | Prometheus / Zabbix / Grafana | Consume less, but “less” ≠ “zero.” Trade-offs: fewer metrics, less insight. |
So in terms of “most consuming”: Dynatrace → DataDog → SolarWinds → New Relic → dbsnOOp → Prometheus → Zabbix → Grafana.
Important: consumption depends on how many hosts/instances you monitor, how frequently, and at what depth (e.g., capturing query calls vs aggregated stats).
3. The dilemma of database access frequency: per call or per time
Monitoring “per call” vs “per time”
- Per call: each event, query, or transaction is monitored; generates lots of telemetry.
- Per time: periodic probing (e.g., every minute or five minutes) to collect aggregated metrics.
Do we need sub-minute probing?
It depends. If your application or database has quick spikes (e.g., a query that runs in 1 second causing latency), probing every minute might miss it. Aggregated stats might show “normal,” but short events are invisible.
Example: a 1-second query that triggers a deadlock or 500 ms wait. Probing every 60 seconds may or may not capture it, depending on the tool:
- Aggregated stats (average, max per minute) may dilute the impact.
- Event capture (each execution recorded) will show it.
If you want visibility for short events, use higher frequency (e.g., probing every 10–15 seconds or event-based capture).
If you probe every 1 minute over 24 hours: theoretically, you will have 1,440 samples (60/60 × 24h) – that is, one sample per minute. If your 1-second query ran once, it will only be reflected if the system has statistics that capture “maximum,” “peak,” or “event occurred.” But if it’s a 1-minute average, it may go unnoticed.
24-hour sampling example:
If it occurred N times, it depends on the frequency of the query. If it happens once during 24 hours, and you sample every minute, you will have 1,440 sampling points; at one of these points, you might capture the event if it falls within the probing window; if not, it may not appear.
If the query runs, say, 10,000 times a day (high load), then the chance of it being captured increases.
In general environments, I really like to query the database every 1 minute.
4. Online complaints about high resource consumption (including network bandwidth)
Yes, there are mentions:
- “What is the best monitoring tool for low-end server (2-GB RAM, 1-CPU)? … Linux-based monitoring will always have lower system requirement …” → shows concern about resource usage.
- “Tool mis-configuration and over-reliance on a single tool” → “Big TCO” and “closed system” may consume more than expected.
- Cloud concerns: “Usage Metrics Monitoring … interval: minute, hour, day? … network receive/transmit” → shows network traffic concerns.
So yes: complaints exist that monitoring tools can “become villains” in resource-limited or cloud environments, where every IOPS or MB/s costs.
5. Is it hype or actually necessary?
Yes, “observability” has become a buzzword—but it’s not just hype. There is real need:
- The more you depend on data, microservices, and elastic cloud, the more visibility you need.
- But necessity doesn’t justify indiscriminate dependence on a tool without cost-benefit evaluation.
It’s necessary for complex environments, but you don’t need the heaviest solution upfront. A good monitoring MVP can suffice.
6. Annual cost by company size for monitoring/observability tools (TCO)
No robust public data, but indications:
- Enterprise tools claim “high cost for hundreds of instances.”
- Hidden costs: licenses + agents + metric storage + team operation + network/IOPS + “noise” (false alerts, operational time).
- Hypothetical estimate:
- Small (10–20 hosts): SaaS “lite” solutions, tens of thousands of BRL/year.
- Medium (100–500 hosts): hundreds of thousands of BRL/year.
- Large (1,000+ hosts, multi-cloud): millions of BRL/year when considering licenses + infrastructure + team.
TCO includes license, agents, training, operation, and hidden overhead. Some DBAs complain: “the tool consumes more time than it helps.”
7. Before and after platforms: prediction and reduced MTTR
Before
- You were “in the dark”: scattered logs, little causal visibility, DBAs chasing issues manually.
- MTTR (Mean Time to Repair) was higher.
- Incidents lasted longer, relied on guesswork or shift-based coverage.
After
- Good observability platforms provide dashboards, proactive alerts, faster root cause analysis.
- MTTR drops—you identify high CPU, high I/O, or DB waits faster.
- In some cases: prediction of spikes or potential server failure based on trends.
But beware: poor configuration or huge data volumes can make the tool “more problem than solution.”
Worth it?
Yes! Generally, it’s worth it if the ROI is clear: less downtime, less impact on users, less manual effort. But you have to weigh the cost and impact of the tool itself. If the tool starts getting in the way (consuming resources, generating too many alerts, taking up DBAs’ time), then the gain turns into a cost.
8. The future of these platforms
- More automation/AI to filter what matters and reduce “alert fatigue.”
- Lighter/edge/agentless observability to minimize host impact.
- More built-in DB instrumentation (less external probing).
- Focus on resource cost (IOPS, network, memory) as part of KPI.
- Integration with cloud cost/optimization.
- Pay-as-you-go or data/host-based pricing with cost transparency.
9. Incident cases caused by platforms?
Few documented public cases where observability platforms directly caused DB downtime. But complaints exist:
- Misconfigured tools, high TCO, tools consuming more time than they save.
- Community reports (e.g., Reddit) of hesitation to install tools due to resource consumption.
Risk is real and should be highlighted in “before/after” discussions.
If you’re a DBA/data engineer, developer, or responsible for infrastructure, here’s the reality: observability is not a luxury, it’s a necessity (especially if you’re scaling, on the cloud, using microservices, or handling data-intensive workloads). But it’s also not an excuse to use the worst platform, one that will drain your database’s CPU/memory/IOPS/latency, making you chase issues like a maniac.
“Casual expert” tips:
- Start light: define essential metrics (CPU, memory, I/O, query latency) and reasonable frequency (e.g., 60s for starters).
- Check if events capture 1-second spikes; if so, increase frequency or use event capture.
- Measure total cost (license + infra + team + impact) vs. an hour of downtime.
- Regularly review if the tool itself consumes too many resources.
- Use monitoring to reduce MTTR, not just create dashboards nobody sees.
- Monitor the monitoring tool itself—“meta-monitoring.”
Investing in observability is worth it—but only if done correctly and if the tool doesn’t become a “resource vampire.” Nothing worse than the monitoring system causing the problem.
Live Long and Prosper
Talk to a dbsnOOp specialist: AI applied to real database performance, tuning, and administration
Schedule a demo here.
Learn more about Flightdeck!
Learn about database monitoring with advanced tools here.
Visit our YouTube channel to learn about the platform and watch tutorials.
Recommended Reading
- HCI (Human-Computer Interface) and Artificial Intelligence: The Future Gene Roddenberry Predicted Is Already Happening: The main article focuses on the trust that medical teams need to have in AI. This post explores the other side: how the interface between human and machine is crucial. It emphasizes that for an AI diagnosis to be useful and safe, the way the physician interacts with and understands the presented data is just as important as the integrity of the data itself.
- Transformers: The Silent Revolution That Changed AI (and It’s Not Michael Bay’s Robots): To trust AI, technical teams need to understand how it “thinks.” This article dives into Transformer technology, the foundation of many modern diagnostic models. It provides the technical context SRE and DevOps teams need to understand the architecture behind the tools they support, ensuring not only data integrity but also application logic.
- Artificial Intelligence or Cognitive Dumbing-Down?: This reading offers a critical reflection on dependence on AI. In the healthcare context, this is vital. The post questions to what extent we should blindly trust algorithms, emphasizing that AI should be a support tool for diagnosis, not a substitute for clinical judgment—a judgment that relies, as discussed, on complete and reliable data.