Monitor Azure Virtual Network Manager changes with event logging

Today, our customers establish and manage their Azure virtual networks at scale. As their number of network resources grows, the question of how to maintain connectivity and security among their scale of resources arises. This is where Microsoft Azure Virtual Network Manager comes in—your one-stop shop for managing the connectivity and security of your network resources at scale (currently in preview). And when customers use Azure Virtual Network Manager, they also need visibility into what kind of changes were made so that they can audit those events, analyze those changes over time, and debug issues along the way. This capability is now a reality—Azure Virtual Network Manager event logging is now in preview.

Azure Virtual Network Manager (AVNM) uses Azure Monitor for telemetry collection and analysis like many other Azure services. AVNM now provides event logs that you can interact with through Azure Monitor’s Log Analytics tool in the Azure Portal, as well as through a storage account. You can also send these logs to an event hub or partner solution.

With this preview announcement, Azure Virtual Network Manager will provide a log category for network group membership change. In the context of AVNM, network groups are defined by the user to contain virtual networks. The membership of a network group can be manually provided (such as by selecting VNetA, VNetB, and VNetC to be a part of this network group) as well as conditionally set through Azure Policy (such as by defining that any virtual network within a certain subscription that contains some string in its name will be added to this network group). The network group membership change log category tracks when a particular virtual network is added to or removed from a network group. This can be used to track network group membership changes over time, to capture a snapshot of a particular virtual network’s network group membership, and more.

What attributes are part of this event log category?

This network group membership change category emits one log per network group membership change. So, when a virtual network is added to or removed from a network group, a log is emitted correlating to that single addition or removal for that particular virtual network. If you’re looking at one of these logs from your storage account, you’ll see several attributes:

Attribute
Description

time
Datetime when the event was logged.

resourceId
Resource ID of the network manager.

location
Location of the virtual network resource.

operationName
Operation that resulted in the virtual network being added or removed. Always the “Microsoft.Network/virtualNetworks/networkGroupMembership/write” operation.

category
Category of this log. Always “NetworkGroupMembershipChange.”

resultType
Indicates successful or failed operation.

correlationId
GUID that can help relate or debug logs.

level
Always “Info.”

properties
Collection of properties of the log.

Within the properties attribute are several nested attributes:

properties attribute
Description

Message
Basic success or failure message.

MembershipId
Default membership ID of the virtual network.

GroupMemberships
Collection of what network groups the virtual network belongs to. There may be multiple “NetworkGroupId” and “Sources” listed within this property since a virtual network can belong to multiple network groups simultaneously.

MemberResourceId
Resource ID of the virtual network that was added to or removed from a network group.

Within the GroupMemberships attribute are several nested attributes:

GroupMemberships attribute
Description

NetworkGroupId
ID of a network group the virtual network belongs to.

Sources

Collection of how the virtual network is a member of the network group.

Within the Sources attribute are several nested attributes:

Sources attribute
Description

Type
Denotes whether the virtual network was added manually (“StaticMembership”) or conditionally via Azure Policy (“Policy”).

StaticMemberId
If the “Type” value is “StaticMembership,” this property will appear.

PolicyAssignmentId
If the “Type” value is “Policy,” this property will appear. ID of the Azure Policy assignment that associates the Azure Policy definition to the network group.

PolicyDefinitionId
If the “Type” value is “Policy,” this property will appear. ID of the Azure Policy definition that contains the conditions for the network group’s membership.

How do I get started?

The first step you’ll need to take is to set up your Log Analytics workspace or your storage account, depending on how you want to consume these event logs. You should note that if you’re using a storage account or event hub, it will need to be in the same region of the network manager you’re accessing logs from. If you’re using a Log Analytics workspace, it can be in any region. The network manager you’re accessing the logs of won’t need to belong to the same subscription as your Log Analytics workspace or storage account, but permissions may restrict your ability to access logs cross-subscription.

Note that at least one virtual network must be added or removed from a network group in order to generate logs. A log will generate for this event a couple minutes later.

Accessing Azure Virtual Network Manager’s event logs with Log Analytics

The first step is to navigate to your desired network manager and select the Diagnostic settings blade under the Monitoring section. Then you can select Add diagnostic setting and select the option to send the logs to your Log Analytics workspace.

Then you can navigate to your Log Analytics workspace directly through your network manager by selecting the Logs blade under the Monitoring section.

Alternatively, you can also navigate to your Log Analytics workspace in the Azure Portal and select the Logs blade.

From either place, you can run your own queries on your network manager’s emitted logs for network group membership changes, or you can also run our preloaded queries. Our preloaded queries can fetch the most recent network group membership changes and failed network group membership changes.

Accessing Azure Virtual Network Manager’s event logs with a storage account

The first step is to again navigate to your desired network manager and select the Diagnostic settings blade under the Monitoring section. Then you can select Add diagnostic setting and select the option to archive the logs to your storage account.

Then you can navigate to your storage account and select the Storage browser blade.

Select Blob containers. A blob container will be automatically generated once network group membership changes occur.

Navigate down the blob container’s file path until you reach a JSON file for the datetime specified by that file path.

Download the JSON file to view the raw logs for the file path’s datetime.

Learn more about Azure Virtual Network Manager event logging

In just a few clicks, you’ve set up your network manager to route event logs to your Log Analytics workspace or your storage account. Now, you can get visibility into each occurrence of a virtual network entering or leaving a network group. Additional log categories are in the works, and in the meantime, feel free to check out our public documentation for more on Azure Virtual Network Manager.
Quelle: Azure

Amazon RDS für MariaDB unterstützt die neuen Nebenversionen 10.6.12, 10.5.19, 10.4.28 und 10.3.38

Amazon Relational Database Service (Amazon RDS) für MariaDB unterstützt jetzt die MariaDB-Nebenversionen 10.6.12, 10.5.19, 10.4.28 und 10.3.38. Wir empfehlen Ihnen das Upgrade auf die neuesten Nebenversionen, um bekannte Sicherheitslücken in früheren Versionen von MariaDB zu beheben und um von den zahlreichen von der MariaDB Community hinzugefügten Fehlerbehebungen, Leistungsverbesserungen und neuen Funktionen zu profitieren.
Quelle: aws.amazon.com