One of the items highlighted by the dashboard is where filesystem utilization is greater than 90% on any server where an Oracle instance is found to be running (There are various other servers maintained within the same OEM estate, so this filter was implemented to focus on the relevant hosts for the DBA team)
Here is how the interactive report for this particular item looked.
When building the initial revisions of the various items, I felt it important to get some context for greater insights and built in the historical indicators to compare the current value to the values of 7 and 30 days prior.
What the above image shows is that for some_host_01, there has been a gradual increase in the utilization for the /opt/apps filesystem over the past 30 days, which happens to be the mount point used for the Oracle software binaries.
That called for a logon to the host in question where, after some digging around, the following was discovered.
grid@some_host_01:/opt/apps/oracle/grid/12.2.0/rdbms> du -sh *
grid@some_host_01:/opt/apps/oracle/grid/12.2.0/rdbms/audit> ls -1f | wc -l
Well that wasn't expected! This specific directory filling up with audit files and consuming wads of space is a known issue documented in various MOS notes [Manage Audit File Directory Growth with cron (Doc ID 1298957.1) being the most prominent], to the extent that scripts have been deployed and implemented via cron jobs on all our systems to manage it.
What we missed here was that after a GI upgrade from 126.96.36.199 to 188.8.131.52, the shell script was not updated to reflect the new $GRID_HOME. Admittedly it was a bad idea on our part to hardcode the $GRID_HOME path in the first place and that's another positive that's come out of this, in that we've revised the script to be more flexible going forward. By the way, I'm including the line below as we've found it to be one of the more efficient methods to remove a large number of files on a Linux system.
grid@some_host_01:/opt/apps/oracle/grid/12.2.0/rdbms/audit> find . -name "*.aud" -type f -delete
In closing, it's yet another lesson to not take those "simple" administrative tasks for granted and a great win for the APEX Oracle Database Dashboard!
P.S. For those of you interested, here is the SQL that queries the OEM repository to produce the report as above. As with anything you find on the internet, please take care when executing this within your own environment