Introduction to Orabbix metric indicators

For Oracle monitoring, Orabbix provides a relatively lightweight client to comprehensively monitor multiple database instances. From this point of view, its role is a bit similar to work

For Oracle monitoring, Orabbix provides a relatively lightweight client to comprehensively monitor multiple database instances. From this point of view, its role is a bit similar to work

For Oracle monitoring, Orabbix provides a relatively lightweight client to comprehensively monitor multiple database instances. From this point of view, its role is a bit similar to the SQLDeveloper or toad tools used at work.

In the previous chapter, I spent some time comparing zabbix and grid control. In fact, from the functional point of view, the monitoring function of Orabbix Based on zabbix is much more limited. Of the provided default templates, there are less than 20 monitoring triggers.

I sorted it out. The default monitoring trigger is about 15.

Fault Type alarm item Error Type Error description

Database no data response Oracle: aliveHigh database no data response

Database instance unavailable Oracle: aliveHigh database instance available

The database has a lock. Oracle: lockshweigh the database has a lock.

The session usage is too high (Oracle: session. last (0)} * 100/Oracle: maxsession. last (0)})> too many 80 highsessions, such as over 80% sessions

Excessive Process usage (Oracle: procnum. last (0)} * 100/Oracle: maxprocs. last (0)})> 80 highprocess, for example, process exceeds 80%

General Audit of exception information Oracle: Audit of auditHigh exception information, such as too many password errors

The number of active sessions is too high. Oracle: session_activeHighactive sessions

User exception locking Oracle: users_lockedWarning user password expired or incorrect logon times too many account locking

High tablespace usage Oracle: showtspsWarning tablespace usage exceeds 90%

Too many archived logs Oracle: archiveWarning archived logs

Normal running time Oracle: uptimeAverage normal running

PGA usage too high (Oracle: pga. last (0)} * 100/Oracle: pga_aggregate_target.last (0)})> 90AveragePGA usage too high

Insufficient cache hit rate Oracle: hitratio_table_proc.avg (60)} <50 | Oracle: Snapshot (60)} <50 | Oracle: hitratio_sqlarea.avg (60)} <50 | Oracle: hitratio_body.avg (60 )} <50Information cache hit rate is insufficient

On this basis, some additional supplements are made, such as checking whether the dg is available, checking whether the space utilization rate in the flash back area is reasonable, and monitoring whether the memory usage is too high.

Datagurad unavailable Oracle: dg_error High datagurad unavailable

Less than 2 GB remaining memory Oracle: vm. memory. size [free]. last ()} <2048 m Warning less than 2 GB remaining memory

High flash back area usage Oracle: archive_area_usage Warning high flash back area usage

In fact, there are still many blind spots in combination with actual work.

For example, listener monitoring

Is there a large number of parallel queries?

Monitoring of DB Response Time

ASM basic monitoring

Rac instance monitoring

To solve this problem, we still need to do a lot of work, not just the current monitoring metrics.

Of course, it cannot be so difficult for orabbix. I believe this developer hopes to make some breakthroughs in Oracle monitoring, but it still leaves us a lot of homework to complete.

I downloaded the source code on sourceforge. The implementation of the source code is based on java and relies on the zabbix basic project. The amount of code is actually small. If you can perform in-depth extension on this basis, there may be more surprises.

For example, we currently use orabbix to monitor the Usage Details of tablespaces. For example, if database A has 10 tablespaces and database B has 5 tablespaces ,, SQL is used to monitor the space surplus of a tablespace.

TS1 5%

TS2 9%

TS3 20%

TS4 30%

For example, we need to monitor the remaining proportion within 10%, that is, TS1 and TS2. The current implementation is to treat the result set as a text, and not to process each column in The result set separately. Therefore, the display of mail alarms is not clear enough. The result set must be used for script formatting again, which is not flexible enough. This is what I need to tackle in the next step.

To be honest, compare the monitoring metrics of gc and orabbix. gc has more than 300 metrics, with a granularity. The number of metrics far exceeds orabbix, But if you calm down, it seems that the number of commonly used indicators is less than 10%.

You can choose the one that suits you, just meet your work needs.

This article permanently updates the link address: