Microsoft Azure is an ever-expanding set of cloud computing services to help your organization meet its business challenges. Azure gives you the freedom to build, manage, and deploy applications on a massive, global network using your preferred tools and frameworks.
1.x to 2.x migrating guide
If you are migrating from v1.x to v2.x, you can find a complete guide in this article.
Devo collector features
Features
Details
Features
Details
Allow parallel downloading (multipod)
Partial (supported for event_hubs services using Azure Blob Storage)
The vm_metrics service cannot work in multipod mode. If you want to use the event_hubs service in multipod mode, you must not include a vm_service in the same collector.
Running environments
collector server
on-premise
Populated Devo events
table
Flattening pre-processing
no
Allowed source events obfuscation
yes
Data source description
Data source
Description
API endpoint
Collector service name
Devo table
Data source
Description
API endpoint
Collector service name
Devo table
VM Metrics
With the advantages of the Microsoft Azure API, one can obtain metrics about the deployed Virtual Machines, gathering them on our platform, making it easier to query and analyze in the Devo platform and Activeboards.
Several Microsoft Azure services can generate some type of execution information to be sent to an EventHub service. (see next section)
Azure Event Hubs SDK
event_hubs and event_hubs_autodiscover
<auto_tag_description>
Valid for all cloud.azure tables by setting the output option to stream to Event Hub.
Event hubs: Auto-categorization of Microsoft Azure service messages
Many of the available Microsoft Azure services can generate some type of execution information to be sent to an EventHub service. This type of data can be categorized as events or metrics. The events, in turn, can be from different subtypes: audits, status, logs, etc.
All such data will be gathered by Devo’s Microsoft Azure collector and sent to our platform, where message auto-categorization functionality is enabled for sending the messages to relevant Devo tables in an automatic way.
Although EventHub is the service used for centralizing Azure services' data, it also generates information that can be sent to itself. Learn more in this article.
In case the amount of egress data exceeds Throughput per Unit limits set by Azure (2 MB/s or 4096 events per second), it won’t be possible for Devo to continue reliable ingestion of data. You can monitor ingress/egress throughput in Azure Portal EventHub Namespace, and based on trends/alerts, you can add another EventHub to resolve this. To avoid this from happening in the first place, please follow scalability guidance provided by Microsoft in their technical documentation.
Vendor setup
The Microsoft Azure collector centralizes the data with an Event Hub using the Azure SDK. To use it, you need to configure the resources in the Azure Portal and set the right permissions to access the information.
Virtual Machine metrics
To log in to the Azure subscription, the collector uses a Service Principal object. You need to get the subscription ID, Active Directory ID, Application ID (service principal identification), and the client secret (service principal "password"). To get them, follow these steps:
Log in to your Azure account and search for Azure Active Directory.
Now, click App registrations in the left menu and click the app (or Service Principal) that you are going to use.
In the Overview area, find the Application (client) ID and the Directory (tenant) ID.
Now click Certificates & Secrets on the menu and create a new client secret by clicking the New client secret button.
Get the subscription ID by searching for Subscriptions on the home page.
Find the correct subscription and note down the subscription ID.
After creating the App registration (or Service Principal), go to the desired Resource Group (or subscription if you want to retrieve metrics from all the available virtual machines).
Select Access control (IAM) in the left menu and click Add.
Select at least the Reader role and choose the previously created App registration.
Confirm the changes.
Event Hub events
If you want to use Azure Blob Storage for checkpointing purposes, you need to create a storage account to store the checkpoints. If you do not wish to use Azure Blob storage (i.e. you will use Devo local persistence), you can skip the Blob Storage configuration steps.
Connection string
From the left portal menu, select Storage accounts to display a list of your storage accounts. If the portal menu isn't visible, select the menu button to toggle it on.
On the Storage accounts page, select Create.
After the storage account is created, select it from the list of storage accounts, click on Access keys in the left menu, and copy the connection string.
Role assignment
Alternatively, users can grant the necessary permissions to the registered application to access the Event Hub without using the RootManageSharedAccessKey. Roles can be assigned in a variety of ways (e.g. inherited from the subscription group), but the following steps will show how to assign the necessary roles directly to the Storage Account.
Repeat steps 1-2 from the Connection String section to create the Storage Account.
In the Storage Account, click Access control (IAM) in the left menu, click + Add, and click Add Access Role Assignment.
Search for either the Storage Blob Data Contributor or Storage Blob Data Owner role and select it and then click Next.
Click + Select members and search for the previously created App registration, select it, click Next.
Click Review + Assign.
Connection string
Users can either obtain a connection string or use Role Assignments to allow the collector to access the Event Hub.
In your Azure account, search for the Event Hubs service and click on it.
Create an Event Hub resource per region (repeat the steps below for each region):
Click Add.
Fill the mandatory fields keeping in mind that the Event Hub must be in the same region as the resources that you are going to monitor (and only need one per region). The Throughput Units option refers to the ingress/egress limit in MB/s (each unit is 1 MB/s or 1000 events/second ingress, 2 MB/s, or 4096 events/second egress). You should adjust it according to the data volume (this can be modified later).
The previous steps create an EventHub namespace; now go to Event Hubs, search the created one and click on it.
Now click on the + Event Hub button and create a new resource. You only need to fill the Name and Partition Count fields (the Partition Count field will divide the data into different partitions to make it easier to read large volumes of data). Write down the EventHub name to be used later in the configuration file.
Once the Event Hub is created in the namespace, click it and select Consumer Group in the left menu. Note that a dedicated Consumer Group for Devo needs to be created if the existing consumer groups are already in use.
Here you will see the Event Hub consumer groups. This will be used by the collector (or other applications) for reading data from the Event Hub. Write down the Consumer group name that you will use later in the configuration file.
Now, in the Event Hub Namespace, click on Shared access policies, search the default policy named RootManageSharedAccessKey and click it.
Copy and write down the primary (or secondary) connection string to be used later in the configuration file.
Role assignment
Alternatively, users can grant the necessary permissions to the registered application to access the Event Hub without using the RootManageSharedAccessKey. Roles can be assigned in a variety of ways (e.g. inherited from the subscription group), but the following steps will show how to assign the necessary roles directly to the Event Hub Namespace.
Repeat all steps except the last one from the previous section to create the Event Hub.
In the Event Hub Namespace, click Access control (IAM) in the left menu, click + Add, and click Add Access Role Assignment.
Search for either the Azure Event Hubs Data Receiver or Azure Event Hubs Data Owner role and select it and then click Next.
Click + Select members and search for the previously created App registration, select it, click Next.
Click Review + Assign.
Now, search the Monitor service and click on it.
Click the Diagnostic Settings option in the left area.
A list of the deployed resources will be shown. Search for the resources that you want to monitor, select them, and click Add diagnostic setting.
Type a name for the rule and check the required category details (logs will be sent to the cloud.azure.eh.events table, and metrics will be sent to the cloud.azure.eh.metrics table).
Check Stream to an Event Hub, and select the corresponding Event hub namespace, Event hub name, and Event hub policy name.
Click Save to finish the process.
Event Hub Auto-Discover
Minimum configuration for basic pulling
Although this collector supports advanced configuration, the fields required to retrieve data with basic configuration are defined below.
Setting
Details
Setting
Details
tenant_id
The Azure application tenant ID.
client_id
The Azure application client ID.
client_secret
The Azure application client secret.
subscription_id
The Azure application subscription ID.
Accepted authentication methods
Authentication method
Tenant ID
Client ID
Client secret
Subscription ID
Authentication method
Tenant ID
Client ID
Client secret
Subscription ID
OAuth2
REQUIRED
REQUIRED
REQUIRED
REQUIRED
Run the collector
Once the data source is configured, you can either send us the required information if you want us to host and manage the collector for you (Cloud collector), or deploy and host the collector in your own machine using a Docker image (On-premise collector).
Collector services detail
This section is intended to explain how to proceed with specific actions for services.
Collector operations
This section is intended to explain how to proceed with specific operations of this collector.