Integration between Windows Azure monitoring and Devo
This article describes the ways that data can be sent from Microsoft Azure environments to Devo. There are two primary scenarios that determine how to establish the connection between the environments: virtual machines and cloud services. No matter how the two environments are connected, the communication channels are secured with SSL/TLS and certificate-based authentication.
Virtual machine instances within a Microsoft Azure environment can either send log data directly to Devo or they can send log data through Azure Storage, then to Devo.
1. Virtual machine that sends logs directly to Devo
The integration is made in the same way as a non-virtual machine. The components in charge of the collection and sending the information are the following Windows services:
- Snare - collects the operating system log entries.
- MagicLog - sends the log files generated by applications.
- MonitorService - recovers the operating system performance counters.
- ProxyServerContainer - responsible for the final sending of events to Devo.
In this case, we would collect the following information:
- Windows Event Log
- Windows performance counters (CPU usage, memory usage, processes running, etc.)
- Sending log files generated by other applications
The components that collect and send the data are deployed in a virtual machine image. This is the image that will be used to create new virtual machine instances in the Microsoft Azure environment. Thus, all new instances will immediately be configured to send information to Devo.
Please note that within the virtual machine, we can run applications developed by you and we can directly integrate the logs generated by these applications to send it to Devo. In this case, the integration should be done in the development phase of the application, and Microsoft Enterprise Library should be used in the standard form. This applies to any application you would like to integrate directly with Devo (regardless of whether it is running in a virtual machine or not).
2. Virtual machine that collects logs in Azure Storage before sending to Devo
In this scenario, Azure Diagnostics collects the data in the virtual machine instead of the Devo Agents. Therefore, this requires that an additional windows service called LogtrustServiceAdapter also be installed in the virtual machine. It collects the data to later be sent to Devo and transfers it to a container within Azure Storage. The configuration of Windows Azure Diagnostics will include, among other things, the information to be transferred to Windows Azure and the transfer timing.
The data in the Azure Storage container is sent to Devo by the LogtrustAgent Worker Role. Click here for more information about this agent.
As in the first scenario, the components that collect and send the data are deployed in a virtual machine image. This is the image that will be used to create new virtual machine instances in the Microsoft Azure environment. Thus, all new instances will immediately be configured to send information to Devo.
In this scenario, web roles and worker roles are using Azure Diagnostics to collect data and transfer it to a container in Azure Storage. The data in the Azure Storage container is sent to Devo by the LogtrustAgent Worker Role. Click here for more information about this agent.
- In Windows Azure Diagnostics, we would configure the information transfer and the frequency. By default, the information will be stored in tables or blobs.
About the LogtrustAgent Worker Role
When events are stored in a Windows Azure Storage container a worker role called LogtrustAgent is used to send the data to Devo. The worker role polls the container periodically for new events that it forwards to Devo over a secure channel.