Tworzenie zasobów monitorowania przy użyciu Bicep
Platforma Azure oferuje kompleksowy zestaw narzędzi, które mogą monitorować aplikacje i usługi. Możesz programowo utworzyć zasoby monitorowania przy użyciu Bicep, aby zautomatyzować tworzenie reguł, ustawień diagnostycznych i alertów podczas aprowizacji infrastruktury platformy Azure.
Wprowadzenie konfiguracji monitorowania do kodu Bicep może wydawać się nietypowe, biorąc pod uwagę, że w witrynie Azure Portal są dostępne narzędzia do konfigurowania reguł alertów, ustawień diagnostycznych i pulpitów nawigacyjnych.
Jednak alerty i ustawienia diagnostyczne są zasadniczo takie same jak inne zasoby infrastruktury. Uwzględniając je w kodzie Bicep, możesz wdrożyć i przetestować zasoby alertów, tak jak w przypadku innych zasobów platformy Azure.
Jeśli używasz narzędzia Git lub innego narzędzia do kontroli wersji do zarządzania plikami Bicep, możesz również skorzystać z historii konfiguracji monitorowania, aby zobaczyć, jak alerty zostały skonfigurowane i skonfigurowane.
Obszary robocze usługi Log Analytics i Application Insights
Obszary robocze usługi Log Analytics można tworzyć przy użyciu typu zasobu Microsoft.OperationalInsights/workspaces i obszarów roboczych usługi Application Insights z typem Microsoft.Insights/components. Oba te składniki są wdrażane w grupach zasobów.
Ustawienia diagnostyczne
Ustawienia diagnostyczne umożliwiają skonfigurowanie usługi Azure Monitor w celu wyeksportowania dzienników i metryk do wielu miejsc docelowych, w tym usługi Log Analytics i Azure Storage.
Podczas tworzenia ustawień diagnostycznych w aplikacji Bicep pamiętaj, że ten zasób jest zasobem rozszerzenia, co oznacza, że jest stosowany do innego zasobu. Ustawienia diagnostyczne można utworzyć w aplikacji Bicep przy użyciu typu zasobu Microsoft.Insights/diagnosticSettings.
Podczas tworzenia ustawień diagnostycznych w aplikacji Bicep należy zastosować zakres ustawienia diagnostycznego. Ustawienie diagnostyczne można zastosować na poziomie zarządzania, subskrypcji lub grupy zasobów. Użyj właściwości zakresu dla tego zasobu, aby ustawić zakres dla tego zasobu.
Rozważmy następujący przykład:
param location string = resourceGroup().location
param appPlanName string = '${uniqueString(resourceGroup().id)}asp'
param logAnalyticsWorkspace string = '${uniqueString(resourceGroup().id)}la'
var appPlanSkuName = 'S1'
resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2023-09-01' existing = {
name: logAnalyticsWorkspace
}
resource appServicePlan 'Microsoft.Web/serverfarms@2023-12-01' = {
name: appPlanName
location: location
sku: {
name: appPlanSkuName
capacity: 1
}
}
resource diagnosticLogs 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
name: appServicePlan.name
scope: appServicePlan
properties: {
workspaceId: logAnalytics.id
logs: [
{
category: 'AllMetrics'
enabled: true
retentionPolicy: {
days: 30
enabled: true
}
}
]
}
}
W poprzednim przykładzie utworzysz ustawienie diagnostyczne dla planu usługi App Service i wyślesz te dane diagnostyczne do usługi Log Analytics. Za pomocą scope
właściwości można zdefiniować plan usługi App Service jako zakres ustawienia diagnostycznego i użyć workspaceId
właściwości do zdefiniowania obszaru roboczego usługi Log Analytics w celu wysłania dzienników diagnostycznych. Możesz również wyeksportować ustawienia diagnostyczne do usługi Event Hubs i kont usługi Azure Storage.
Typy dzienników różnią się między zasobami, dlatego upewnij się, że dzienniki, które chcesz wyeksportować, mają zastosowanie do używanego zasobu.
Ustawienia diagnostyczne dziennika aktywności
Aby użyć narzędzia Bicep do skonfigurowania ustawień diagnostycznych w celu wyeksportowania dziennika aktywności platformy Azure, wdróż zasób ustawienia diagnostycznego w zakresie subskrypcji.
W poniższym przykładzie pokazano, jak wyeksportować kilka typów dzienników aktywności do obszaru roboczego usługi Log Analytics:
targetScope = 'subscription'
param logAnalyticsWorkspaceId string
var activityLogDiagnosticSettingsName = 'export-activity-log'
resource subscriptionActivityLog 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
name: activityLogDiagnosticSettingsName
properties: {
workspaceId: logAnalyticsWorkspaceId
logs: [
{
category: 'Administrative'
enabled: true
}
{
category: 'Security'
enabled: true
}
{
category: 'ServiceHealth'
enabled: true
}
{
category: 'Alert'
enabled: true
}
{
category: 'Recommendation'
enabled: true
}
{
category: 'Policy'
enabled: true
}
{
category: 'Autoscale'
enabled: true
}
{
category: 'ResourceHealth'
enabled: true
}
]
}
}
Alerty
Alerty proaktywnie powiadamiają o znalezieniu problemów w infrastrukturze i aplikacjach platformy Azure przez monitorowanie danych w usłudze Azure Monitor. Konfigurując konfigurację monitorowania i alertów w kodzie Bicep, możesz zautomatyzować tworzenie tych alertów wraz z infrastrukturą aprowizaną na platformie Azure.
Aby uzyskać więcej informacji o sposobie działania alertów na platformie Azure, zobacz Omówienie alertów na platformie Microsoft Azure.
W poniższych sekcjach pokazano, jak skonfigurować różne typy alertów przy użyciu kodu Bicep.
Grupy akcji
Aby otrzymywać powiadomienia po wyzwoleniu alertów, należy utworzyć grupę akcji. Grupa akcji to kolekcja preferencji powiadomień zdefiniowanych przez właściciela subskrypcji platformy Azure. Grupy akcji służą do powiadamiania użytkowników o wyzwoleniu alertu lub wyzwalaniu automatycznych odpowiedzi na alerty.
Aby utworzyć grupy akcji w aplikacji Bicep, możesz użyć typu Microsoft.Insights/actionGroups. Oto przykład:
param actionGroupName string = 'On-Call Team'
param location string = resourceGroup().location
var actionGroupEmail = 'oncallteam@contoso.com'
resource supportTeamActionGroup 'Microsoft.Insights/actionGroups@2023-01-01' = {
name: actionGroupName
location: location
properties: {
enabled: true
groupShortName: actionGroupName
emailReceivers: [
{
name: actionGroupName
emailAddress: actionGroupEmail
useCommonAlertSchema: true
}
]
}
}
Powyższy przykład tworzy grupę akcji, która wysyła alerty na adres e-mail, ale można również zdefiniować grupy akcji, które wysyłają alerty do usługi Event Hubs, Azure Functions, Logic Apps i nie tylko.
Reguły przetwarzania alertów
Reguły przetwarzania alertów (wcześniej nazywane regułami akcji) umożliwiają stosowanie przetwarzania alertów, które zostały wyzwolone. Reguły przetwarzania alertów można utworzyć w aplikacji Bicep przy użyciu typu Microsoft.AlertsManagement/actionRules.
Każda reguła przetwarzania alertów ma zakres, który może być listą co najmniej jednego określonego zasobu, konkretnej grupy zasobów lub całej subskrypcji platformy Azure. Podczas definiowania reguł przetwarzania alertów w Bicep należy zdefiniować listę identyfikatorów zasobów we właściwości zakresu , która jest przeznaczona dla tych zasobów dla reguły przetwarzania alertów.
param alertRuleName string = 'AlertRuleName'
param actionGroupName string = 'On-Call Team'
param location string = resourceGroup().location
resource actionGroup 'Microsoft.Insights/actionGroups@2023-09-01-preview' existing = {
name: actionGroupName
}
resource alertProcessingRule 'Microsoft.AlertsManagement/actionRules@2023-05-01-preview' = {
name: alertRuleName
location: location
properties: {
actions: [
{
actionType: 'AddActionGroups'
actionGroupIds: [
actionGroup.id
]
}
]
conditions: [
{
field: 'MonitorService'
operator: 'Equals'
values: [
'Azure Backup'
]
}
]
enabled: true
scopes: [
subscription().id
]
}
}
W poprzednim przykładzie zdefiniowano regułę MonitorService
przetwarzania alertów w usłudze Azure Backup Vault, która jest stosowana do istniejącej grupy akcji. Ta reguła wyzwala alerty do grupy akcji.
Reguły alertów dziennika
Alerty dzienników automatycznie uruchamiają zapytanie usługi Log Analytics. Zapytanie, które służy do oceny dzienników zasobów w określonym przedziale czasu, określa, czy wyniki spełniają określone kryteria, a następnie uruchamia alert.
Reguły alertów dziennika można utworzyć w Bicep przy użyciu typu Microsoft.Insights/scheduledQueryRules.
Reguły alertów metryk
Alerty metryk powiadamiają o przekroczeniu zdefiniowanego progu przez jedną z metryk. Regułę alertu dotyczącego metryki można zdefiniować w kodzie Bicep przy użyciu typu Microsoft.Insights/metricAlerts.
Alerty dotyczące dzienników aktywności
Dziennik aktywności platformy Azure to dziennik platformy Azure, który zapewnia wgląd w zdarzenia na poziomie subskrypcji. Obejmuje to informacje, takie jak czas modyfikacji zasobu na platformie Azure.
Alerty dziennika aktywności to alerty aktywowane po wystąpieniu nowego zdarzenia dziennika aktywności zgodnego z warunkami określonymi w alercie.
Możesz użyć scope
właściwości typu Microsoft.Insights/activityLogAlerts , aby utworzyć alerty dziennika aktywności dla określonego zasobu lub listę zasobów przy użyciu identyfikatorów zasobów jako prefiksu.
Należy zdefiniować warunki reguły alertu we condition
właściwości, a następnie skonfigurować grupę alertów, aby wyzwolić te alerty przy użyciu tablicy actionGroup
. W tym miejscu możesz przekazać jedną lub wiele grup akcji, aby wysyłać alerty dziennika aktywności do, w zależności od wymagań.
param activityLogAlertName string = '${uniqueString(resourceGroup().id)}-alert'
param actionGroupName string = 'adminactiongroup'
resource actionGroup 'Microsoft.Insights/actionGroups@2023-09-01-preview' existing = {
name: actionGroupName
}
resource activityLogAlert 'Microsoft.Insights/activityLogAlerts@2023-01-01-preview' = {
name: activityLogAlertName
location: 'Global'
properties: {
condition: {
allOf: [
{
field: 'category'
equals: 'Administrative'
}
{
field: 'operationName'
equals: 'Microsoft.Resources/deployments/write'
}
{
field: 'resourceType'
equals: 'Microsoft.Resources/deployments'
}
]
}
actions: {
actionGroups: [
{
actionGroupId: actionGroup.id
}
]
}
scopes: [
subscription().id
]
}
}
Reguły alertów dotyczących kondycji zasobu
Usługa Azure Resource Health informuje o bieżącym i historycznym stanie kondycji zasobów platformy Azure. Tworząc alerty dotyczące kondycji zasobów przy użyciu aplikacji Bicep, możesz tworzyć i dostosowywać te alerty zbiorczo.
W aplikacji Bicep można tworzyć alerty dotyczące kondycji zasobów z typem Microsoft.Insights/activityLogAlerts.
Alerty dotyczące kondycji zasobów można skonfigurować do monitorowania zdarzeń na poziomie subskrypcji, grupy zasobów lub pojedynczego zasobu.
Rozważmy poniższy przykład, w którym tworzysz alert dotyczący kondycji zasobów, który raportuje alerty dotyczące kondycji usługi. Alert jest stosowany na poziomie subskrypcji (przy użyciu scope
właściwości) i wysyła alerty do istniejącej grupy akcji:
param activityLogAlertName string = uniqueString(resourceGroup().id)
param actionGroupName string = 'oncallactiongroup'
resource actionGroup 'Microsoft.Insights/actionGroups@2023-09-01-preview' existing = {
name: actionGroupName
}
resource resourceHealthAlert 'Microsoft.Insights/activityLogAlerts@2023-01-01-preview' = {
name: activityLogAlertName
location: 'global'
properties: {
condition: {
allOf: [
{
field: 'category'
equals: 'ServiceHealth'
}
]
}
scopes: [
subscription().id
]
actions: {
actionGroups: [
{
actionGroupId: actionGroup.id
}
]
}
}
}
Alerty wykrywania inteligentnego
Alerty wykrywania inteligentnego ostrzegają przed potencjalnymi problemami z wydajnością i anomaliami błędów w aplikacji internetowej. Alerty wykrywania inteligentnego można tworzyć w Bicep przy użyciu typu Microsoft.AlertsManagement/smartDetectorAlertRules.
Pulpity nawigacyjne
W aplikacji Bicep można tworzyć pulpity nawigacyjne portalu przy użyciu typu zasobu Microsoft.Portal/dashboards.
Aby uzyskać więcej informacji na temat tworzenia pulpitów nawigacyjnych za pomocą kodu, zobacz Programowe tworzenie pulpitu nawigacyjnego platformy Azure.
Reguły automatycznego skalowania
Aby utworzyć ustawienie skalowania automatycznego, należy je zdefiniować przy użyciu typu zasobu Microsoft.Insights/autoscaleSettings.
Aby zastosować ustawienie skalowania automatycznego do zasobu docelowego, należy podać docelowy identyfikator zasobu, do którego należy dodać ustawienie.
W tym przykładzie warunek skalowania w poziomie dla planu usługi App Service zależy od średniej wartości procentowej procesora CPU w okresie 10-minutowym. Jeśli plan usługi App Service przekracza 70% średnie użycie procesora CPU w ciągu 10 minut, aparat skalowania automatycznego skaluje plan w poziomie przez dodanie jednego wystąpienia.
param location string = resourceGroup().location
param appPlanName string = '${uniqueString(resourceGroup().id)}asp'
var appPlanSkuName = 'S1'
resource appServicePlan 'Microsoft.Web/serverfarms@2023-12-01' = {
name: appPlanName
location: location
properties: {}
sku: {
name: appPlanSkuName
capacity: 1
}
}
resource scaleOutRule 'Microsoft.Insights/autoscalesettings@2022-10-01' = {
name: appServicePlan.name
location: location
properties: {
enabled: true
profiles: [
{
name: 'Scale out condition'
capacity: {
maximum: '3'
default: '1'
minimum: '1'
}
rules: [
{
scaleAction: {
type: 'ChangeCount'
direction: 'Increase'
cooldown: 'PT5M'
value: '1'
}
metricTrigger: {
metricName: 'CpuPercentage'
operator: 'GreaterThan'
timeAggregation: 'Average'
threshold: 70
metricResourceUri: appServicePlan.id
timeWindow: 'PT10M'
timeGrain: 'PT1M'
statistic: 'Average'
}
}
]
}
]
targetResourceUri: appServicePlan.id
}
}
Uwaga
Podczas definiowania reguł skalowania automatycznego należy pamiętać o najlepszych rozwiązaniach, aby uniknąć problemów podczas próby autoskalowania, takiego jak flapping. Aby uzyskać więcej informacji, zobacz następującą dokumentację dotyczącą najlepszych rozwiązań dotyczących skalowania automatycznego.
Powiązane zasoby
- Dokumentacja zasobu
- Microsoft.OperationalInsights/workspaces
- Microsoft.Insights/components
- Microsoft.Insights/diagnosticSettings
- Microsoft.Insights/actionGroups
- Microsoft.Insights/scheduledQueryRules
- Microsoft.Insights/metricAlerts
- Microsoft.Portal/pulpity nawigacyjne
- Microsoft.Insights/activityLogAlerts
- Microsoft.AlertsManagement/smartDetectorAlertRules.
- Microsoft.Insights/autoscaleSettings