When it comes to monitoring Oracle, Orabbix provides a relatively lightweight client for comprehensive monitoring of multiple database instances. From this perspective, its role is somewhat similar to tools like SQLDeveloper or Toad used in daily work.
In previous chapters, I spent some time comparing Zabbix and Grid Control. Functionally speaking, the monitoring capabilities of Zabbix-based Orabbix are far more limited. The default template provides fewer than 20 monitoring triggers.
After reviewing, there are about 15 default monitoring triggers.
| Fault Type | Alert Item | Error Type | Brief Description |
| Database Not Responding | Oracle:alive | High | Database not responding |
| Database Instance Unavailable | Oracle:alive | High | Whether the database instance is available |
| Database Locks Exist | Oracle:locks | High | Locks exist in the database |
| High Session Usage | (Oracle:session.last(0)}*100/Oracle:maxsession.last(0)})>80 | High | Too many sessions, e.g., sessions exceed 80% |
| High Process Usage | (Oracle:procnum.last(0)}*100/Oracle:maxprocs.last(0)})>80 | High | Too many processes, e.g., processes exceed 80% |
| General Audit for Anomalies | Oracle:audit | High | Audit of abnormal information, e.g., too many wrong password attempts |
| High Active Session Count | Oracle:session_active | High | Active session count |
| User Account Locked | Oracle:users_locked | Warning | Password expired or too many failed login attempts causing account lock |
| High Tablespace Usage | Oracle:showtsps | Warning | Tablespace usage exceeds 90% |
| High Archive Log Volume | Oracle:archive | Warning | Archive log volume |
| Uptime | Oracle:uptime | Average | Normal operation status |
| High PGA Usage | (Oracle:pga.last(0)}*100/Oracle:pga_aggregate_target.last(0)})>90 | Average | PGA usage is too high |
| Low Cache Hit Ratio | Oracle:hitratio_table_proc.avg(60)}<50|Oracle:hitratio_trigger.avg(60)}<50|Oracle:hitratio_sqlarea.avg(60)}<50|Oracle:hitratio_body.avg(60)}<50 | Information | Insufficient cache hit ratio |
On top of this, I added some supplementary checks, such as detecting whether DG is available, checking if the flash recovery area space usage is reasonable, and monitoring whether memory usage is too high, etc.
| DataGuard Unavailable | Oracle:dg_error | High | DataGuard is unavailable |
| Remaining Memory Less Than 2G | Oracle:vm.memory.size[free].last()}<2048m | Warning | Remaining memory less than 2G |
| High Flash Recovery Area Usage | Oracle:archive_area_usage | Warning | Flash recovery area usage is too high |
In fact, combined with actual work, there are still many blind spots.
For example, monitoring the listener
Whether there are a large number of parallel queries
Monitoring DB response time
Some basic ASM monitoring
Monitoring RAC instances
So, looking at the broader picture, there is still a lot of work to do, not just limited to the current monitoring metrics.
Of course, we shouldn’t be too hard on Orabbix. I believe the developer wanted to make breakthroughs in Oracle monitoring, but it still leaves us with quite a bit of homework to complete.
I downloaded the source code from SourceForge myself. The implementation is based on Java and relies on the Zabbix base project. The amount of code is actually not large. If we can extend it deeply on this foundation, there might be more surprises.
For instance, currently using Orabbix to monitor tablespace usage details: suppose Database A has 10 tablespaces and Database B has 5 tablespaces. Monitoring the remaining space of tablespaces via SQL would look like the following format.
TS1 5%
TS2 9%
TS3 20%
TS4 30%
For example, if we need to monitor those with a remaining percentage within 10%, that would mean TS1 and TS2. The current implementation treats the result set as a single text block, unable to process each column of the result set individually, so the email alert display is still not clear enough. It still relies on the result set, followed by another script for formatted display, making the implementation not flexible enough. This is also a point I need to tackle next.
If we get serious and compare the monitoring metrics of GC and Orabbix, GC has over 300 metrics, far surpassing Orabbix in granularity and quantity. But if you calm down and think about it, it seems the metrics you commonly use are actually less than 10%.
Just choose what suits you and meets the job requirements.
http://blog.itpub.net/23718752/viewspace-1770782/