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 done in the same way as for a non-virtual machine. The components in charge of the collection and sending of data are the Snare Agent for Windows and the components of the Devo Agent for Windows:
- Snare - collects the operating system log entries.
- MagicLog - collects the application log files.
- MagicEvent - collects the Windows Event Log.
- MonitorService - recovers the operating system performance counters.
- ProxyServerContainer - responsible for sending events to Devo.
In this case, we would collect the following information:
- Windows Event Log - This is done byMonitorServer.
- Windows performance counters - This is done by MonitorServer.
- Sending log files generated by other applications - This is done by the ProxyServerContainer.
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, log events generated by your proprientary applications can also be sent 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.
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.