Sending Data to Oracle Management Cloud
Updating and reposting to reflect current state as of today for agent install and tenants.
Lately I’ve been busy helping customers deploy the new Oracle Management Cloud (OMC) services and discover what it can do for them. One of the most frequent questions I get when talking with new customers about OMC is how do we collect the data and send it to Oracle’s Cloud? Using Agents installed on-premises or in the Cloud, we can collect various points of data to be used in the many services that make up Oracle Management Cloud. The goal of this blog is to introduce you to our points of communication and explain where we get data and how it’s used.
It’s important to note, all communication is outbound from Agents to Oracle Cloud. There is no inbound communication. All agent communication is over HTTPS. If your systems have direct access to the internet, they can communicate directly. Most enterprise customers will likely configure a proxy or firewall/ACL changes to allow communication over certain servers and ports.
Each tenant will have a unique URL that the agents would access, typically it would look like:
https://<instance>-<tenant>.<datacenter>.oraclecloud.com/*
For example: https://omc-tenant.uscom-east-1.oraclecloud.com
You must be able to reach this URL. Whether it’s via proxy server, or firewall, the agent does not care so much. Just that it can communicate. To test this, you can use curl to see if your particular server can reach the tenant.
curl -I –tlsv1.2 https://omc-tenant.uscom-east-1.oraclecloud.com
The rest of this blog post will discuss the various agent components and how they communicate with each other in a typical Oracle Management Cloud deployment.
Agents
As with any systems monitoring tool, there are agents that help with the collection and processing of data. Each of the agents will be discussed below in regards to what services
Gateway
The Gateway is an optional component and is used to buffer and send all data from Cloud Agents, APM Agents and Data Collectors to the Oracle Cloud. This way, only one server has to have internet access. Due to the amount of activity for buffering data, this may require a standalone machine as the CPU utilization can be up to 20% for large environments depending on the number of agents and volume of data being sent. All communication from Gateway agent to Oracle Cloud is over HTTPS (port 443) and is outbound only.
Cloud Agent
The Cloud Agent is responsible for collecting log, metrics, performance, configuration, orchestration jobs and compliance checks to be used in the various services (Log Analytics, IT Analytics, Infrastructure Monitoring, Configuration & Compliance, etc). It is also responsible for executing remediation actions or instructions per Orchestration service. This agent will sit on the target host, whether on-premises or in a Cloud. The agent can communicate to OMC directly, via a proxy, or the Gateway. The Cloud agent communicates to the Cloud over HTTPS (port 443) directly, or to the Gateway agent over the port the Gateway was installed on (default is 4459).
APM Agent
When using Application Performance Monitoring (APM), you’ll be using the APM agent which is installed on the server where the application runs. Whether the application is Java, .Net or Node.js, the agent collects and sends performance data about the application to OMC. This agent can communicate directly, via a proxy, or through the Gateway (over HTTPS on Gateway port). As APM also collects End User Metric data from the application users browser, that data is sent directly to OMC.
Data Collector
There is also an optional Data Collector component for users who already have Oracle Enterprise Manager (OEM) configured. The Data Collector extracts target properties, associations, metrics, incidents, version and additional configuration data about the targets in OEM and shares this with OMC. The Data Collector talks to OMC directly over HTTPS or via the Gateway (over HTTPS on Gateway port). You can have multiple Data Collectors if you have more than one OEM configured. This is a great opportunity to consolidate data into one place if your OEM is separated by organization, geography or lifecycle status.
Deployment
Each agent has a zip file that can be downloaded from a static link or via the OMC Console. Installation parameters are set in an agent.rsp file and then an install script is called:
$ ./AgentInstall.sh agent.rsp
As each agent has a different purpose, their install parameters are slightly different. Details can be found in the installation docs referenced at the end of this blog.
Maintaining Agents
Since Oracle Management Cloud is an agile product with monthly releases, the agents may be updated monthly as well. This does not mean you have to upgrade your agents monthly, but upgrading quarterly will keep your agents in top shape. For Gateway, Cloud and Data Collector agents, when you’re ready to upgrade simply go to the Agents administration page and select Upgrade. This will instruct your agent to download the latest agent and perform an out-of-place upgrade seamlessly. If the upgrade fails for some reason, your original agent will remain active.
APM agents must be upgraded manually as they’re tightly integrated with the application. These should be built into your application update cycles.
Summary
As you can see, communication to Oracle Management Cloud has a couple of options to meet different needs. All communication will go over https and can communicate directly to the cloud or through a centralized gateway. If you’re looking for additional information, you may find these sources helpful: