2

I am looking for general advice from anyone who has experience monitoring Oracle RDS databases in AWS. The system that I am working with will involve several enterprise Oracle RDS databases (on the order of a few dozen) in AWS. My organization is considering two options for monitoring:

  1. Setting up Cloud Control in AWS, by housing the OMS and the repository database on an EC2 instance and enabling the OEM_AGENT on our RDS instances.
  2. Relying entirely on EM Express/CloudWatch and any other third party software that we can use without the overhead of Cloud Control.

The concern with option 1 is that it undermines our reasons for moving to RDS, namely, to remove some of the administrative overhead of maintaining traditional on-premises Oracle databases. The OEM repository database cannot be housed in RDS as the OMS requires SYS-level access to the repository and RDS does not allow for this. As a result, having Cloud Control would require a lot of the kind of maintenance we were hoping to move away from.

The problem with option 2 is mainly the lack of metric alerting. CloudWatch/Enhanced Monitoring provide some basic metrics for alerts, but more specific metrics and alerts, such as those on alert log errors, tablespaces, long-running queries, archive area used, etc are lacking. We do not mind the lack of centralization as we will simply create an internal page with links to all of the different databases, and EM Express gives us what we need from a performance monitoring standpoint. The only concern really is the lack of metrics alerting. If there is not some other way of doing this, we may also simply write our own PL/SQL scripts to trigger the alerts.

However, I am curious to know how others solved this problem or even just generally, what kinds of AWS-based Oracle monitoring systems have been set up and how they work.

amparito
  • 323
  • 2
  • 4
  • 12

1 Answers1

0

A problem almost all the enterprises which moving to cloud are facing today. Companies moving to cloud to get rid of some of their admin tasks and then they are figuring out they can't do all the customization that they had in on-prem.

So, here is how you can make the option 2 better. Especially to address your concern

The only concern really is the lack of metrics alerting

  1. RDS events are a good way for monitoring. You can subscribe to the events and get notified in multiple ways such as group email, slack channels or to a third part monitoring tool like pagerduty.

  2. Using RDS Events integration with Lambda. I strongly suggest to have a look on Lambda. As I mentioned above, apart from subscribing to the events, you can also call/trigger a lambda function to take actions for certain events. We use Lambda for overcoming the slave skip error in mysql.

  3. Another use case of Lambda is an alternative to cron job. Things like checking disk space every day, to make sure incremental backups are taken over night.

Let me know, if you have specific question on "how to implement" these options. I will be glad to add more information.

viggy28
  • 760
  • 1
  • 10
  • 21
  • 1
    Yes, RDS events are very useful for high-level infrastructure monitoring, but the issue is still the internal database monitoring, as RDS events do not provide any of this. – amparito May 09 '17 at 14:17
  • @amparito that's right. RDS events are not fine grained. To overcome this (to an extent) convert your monitoring scripts to lambda functions (yes, not an easy task) or have a manager box (a separate EC2) load your scripts and execute it on all the RDS. – viggy28 May 09 '17 at 14:32