Zbieranie i odczytywanie danych OpenTelemetry w usłudze Azure Container Apps

Korzystając z agenta danych OpenTelemetry w środowisku usługi Azure Container Apps, możesz wysłać dane z obserwacji w formacie OpenTelemetry, wykonując następujące czynności:

• Potokowanie danych z agenta do żądanego punktu końcowego. Opcje docelowe obejmują usługę Azure Monitor Application Insights, usługę Datadog i dowolny punkt końcowy zgodny z protokołem OpenTelemetry Protocol (OTLP).

• Łatwe zmienianie docelowych punktów końcowych bez konieczności ponownego konfigurowania sposobu emitowania danych i bez konieczności ręcznego uruchamiania agenta OpenTelemetry.

W tym artykule pokazano, jak skonfigurować i skonfigurować agenta OpenTelemetry dla aplikacji kontenera.

Konfigurowanie agenta OpenTelemetry

Agenci OpenTelemetry działają w środowisku aplikacji kontenera. Ustawienia agenta można skonfigurować za pomocą szablonu usługi ARM lub wywołań Bicep do środowiska albo za pośrednictwem interfejsu wiersza polecenia lub za pośrednictwem narzędzia Terraform (za pośrednictwem dostawcy AzAPI).

Każdy typ punktu końcowego (Azure Monitor Application Insights, DataDog i OTLP) ma określone wymagania dotyczące konfiguracji.

Wymagania wstępne

Włączenie zarządzanego agenta OpenTelemetry dla środowiska nie oznacza automatycznego zbierania danych przez agenta. Agenci wysyłają dane tylko na podstawie ustawień konfiguracji i prawidłowo instrumentując kod.

Konfigurowanie kodu źródłowego

Przygotuj aplikację do zbierania danych, instalując zestaw OpenTelemetry SDK i postępując zgodnie z wytycznymi OpenTelemetry, aby instrumentować metryki, dzienniki lub ślady.

Inicjowanie punktów końcowych

Przed wysłaniem danych do miejsca docelowego kolekcji należy najpierw utworzyć wystąpienie usługi docelowej. Jeśli na przykład chcesz wysłać dane do usługi Azure Monitor Application Insights, musisz utworzyć wystąpienie usługi Application Insights z wyprzedzeniem.

Zarządzany agent OpenTelemetry akceptuje następujące miejsca docelowe:

• Azure Monitor Application Insights (Analiza Aplikacji)
• Usługa Datadog
• Dowolny punkt końcowy OTLP (na przykład: New Relic lub Honeycomb)

W poniższej tabeli przedstawiono typ danych, które można wysyłać do każdego miejsca docelowego:

Azure Monitor Application Insights (Analiza Aplikacji)

Jedynymi szczegółami konfiguracji wymaganymi z usługi Application Insights jest parametry połączenia. Po utworzeniu parametry połączenia możesz skonfigurować agenta za pomocą szablonu arm aplikacji kontenera przy użyciu poleceń interfejsu wiersza polecenia platformy Azure lub narzędzia Terraform.

Parametry połączenia zawiera klucz instrumentacji, który jest unikatowym identyfikatorem używanym do kojarzenia danych telemetrycznych z określonym zasobem usługi Application Insights. Klucze instrumentacji nie są tokenami zabezpieczającymi ani kluczami zabezpieczeń i nie są uznawane za wpisy tajne.

Jeśli chcesz chronić zasób usługi Application Insights przed nieprawidłowym użyciem, zobacz Microsoft Entra authentication for Application Insights (Uwierzytelnianie firmy Microsoft dla usługi Application Insights). Jednak zasób usługi Application Insights musi zezwalać na lokalne uwierzytelnianie na odbieranie danych z agenta danych OpenTelemetry.

{
  ...
  "properties": {
    "appInsightsConfiguration ": {
      "connectionString": "<APP_INSIGHTS_CONNECTION_STRING>"
    }
    "openTelemetryConfiguration": {
      ...
      "tracesConfiguration":{
        "destinations": ["appInsights"]
      },
      "logsConfiguration": {
        "destinations": ["appInsights"]
      }
    }
  }
}

resource environment 'Microsoft.App/managedEnvironments@2024-10-02-preview' = {
  ...
  properties: {
    appInsightsConfiguration: {
      connectionString: '<APP_INSIGHTS_CONNECTION_STRING>'
    }
    openTelemetryConfiguration: {
      ...
      tracesConfiguration: {
        destinations: [
          'appInsights'
        ]
      }
      logsConfiguration: {
        destinations: [
          'appInsights'
        ]
      }
    }
  }
}

az containerapp env telemetry app-insights set \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <ENVIRONMENT_NAME> \
  --connection-string <APP_INSIGHTS_CONNECTION_STRING> \
  --enable-open-telemetry-traces true \
  --enable-open-telemetry-logs true

resource "azapi_update_resource" "app_insights_open_telemetry_integration" {
  name      = azurerm_container_app_environment.managed_environment.name
  parent_id = azurerm_resource_group.resource_group.id
  type      = "Microsoft.App/managedEnvironments@2023-11-02-preview"
  body = jsonencode({
    properties = {
      appInsightsConfiguration = {
        connectionString = azurerm_application_insights.applicationinsights.connection_string
      }
      appLogsConfiguration = {
        destination = "log-analytics"
        logAnalyticsConfiguration = {
          customerId = azurerm_log_analytics_workspace.workspace.workspace_id
          sharedKey  = azurerm_log_analytics_workspace.workspace.primary_shared_key
        }
      }
      openTelemetryConfiguration = {
        tracesConfiguration = {
          destinations = ["appInsights"]
        }
        logsConfiguration = {
          destinations = ["appInsights"]
        }
      }
    }
  })
}

Usługa Datadog

Nie musisz uruchamiać agenta usługi Datadog w aplikacji kontenera, jeśli włączysz zarządzanego agenta OpenTelemetry dla danego środowiska.

Konfiguracja agenta OpenTelemetry potrzebuje wartości dla site i key z wystąpienia usługi Datadog. Zbierz te wartości z wystąpienia usługi Datadog zgodnie z tą tabelą:

Jeśli wystąpienie usługi Datadog zostało utworzone w witrynie Azure Portal, zobacz Klucze interfejsu API , aby uzyskać więcej informacji.

Po utworzeniu tych szczegółów konfiguracji możesz skonfigurować agenta za pomocą szablonu ARM lub Bicep aplikacji kontenera albo za pomocą poleceń interfejsu wiersza polecenia platformy Azure.

Unikaj określania wartości wpisu tajnego, takiego jak klucz interfejsu API usługi Datadog, bezpośrednio w środowisku produkcyjnym. Zamiast tego użyj odwołania do wpisu tajnego przechowywanego w usłudze Azure Key Vault.

Musisz włączyć magazyn kluczy na potrzeby wdrażania szablonu. Aby włączyć wdrażanie szablonu, utwórz klucznik z włączoną enabledForTemplateDeployment właściwością lub uruchom następujące polecenie Azure CLI, zastępując element <KEY_VAULT_NAME> swoją wartością:

az keyvault update --name <KEY_VAULT_NAME> --enabled-for-template-deployment true

Aby uzyskać więcej informacji, zobacz:

• Przekazywanie wartości bezpiecznego parametru podczas wdrażania za pomocą usługi Azure Key Vault
• Samouczek: Integracja usługi Azure Key Vault w ramach wdrożenia szablonu ARM

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "datadogapikey": {
      "reference": {
        "keyVault": {
          "id": "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>/providers/Microsoft.KeyVault/vaults/<KEY_VAULT_NAME>"
        },
        "secretName": "<KEY_VAULT_SECRET_NAME>"
      }
    }
  }
}

{
  ...
  "parameters": {
    "datadogapikey": {
      "type": "securestring"
    }
  },
  "properties": {
    ...
    "openTelemetryConfiguration": {
      ...
      "destinationsConfiguration":{
        ...
        "dataDogConfiguration":{
          "site": "<YOUR_DATADOG_SUBDOMAIN>.datadoghq.com",
          "key": "<YOUR_DATADOG_KEY>"
        }
      },
      "tracesConfiguration":{
        "destinations": ["dataDog"]
      },
      "metricsConfiguration": {
        "destinations": ["dataDog"]
      }
    }
  }
}

az deployment group create \
  --resource-group <RESOURCE_GROUP> \
  --template-file <ARM_TEMPLATE_FILE> \
  --parameters <PARAMETER_FILE>

using '<BICEP_TEMPLATE_FILE>'

param datadogapikey = az.getSecret('<SUBSCRIPTION_ID>', '<RESOURCE_GROUP_NAME>', '<KEY_VAULT_NAME>', '<SECRET_NAME>', '<SECRET_VERSION_ID>')

@secure()
param datadogapikey string

resource environment 'Microsoft.App/managedEnvironments@2024-10-02-preview' = {
  ...
  properties: {
    openTelemetryConfiguration: {
      destinationsConfiguration: {
        dataDogConfiguration: {
          site: 'datadoghq.com'
          key: datadogapikey
        }
      }
      ...
      metricsConfiguration: {
        destinations: [
          'dataDog'
          'customDashboard'
        ]
      }
    }
  }
}

az deployment group create \
  --resource-group <RESOURCE_GROUP> \
  --template-file <BICEP_TEMPLATE_FILE> \
  --parameters <PARAMETER_FILE>

az containerapp env telemetry data-dog set \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <ENVIRONMENT_NAME> \
  --site "<DATADOG_SUBDOMAIN>.datadoghq.com" \
  --key <DATADOG_KEY> \
  --enable-open-telemetry-traces true \
  --enable-open-telemetry-metrics true

resource "azapi_update_resource" "app_insights_open_telemetry_integration" {
  name      = azurerm_container_app_environment.managed_environment.name
  parent_id = azurerm_resource_group.resource_group.id
  type      = "Microsoft.App/managedEnvironments@2023-11-02-preview"
  body = jsonencode({
    properties = {
      openTelemetryConfiguration = {
        destinationsConfiguration = {
          dataDogConfiguration = {
            site = "<YOUR_DATADOG_SUBDOMAIN>.datadoghq.com"
            key = "<YOUR_DATADOG_KEY>"
          }
        }
        tracesConfiguration = {
          destinations = ["dataDog"]
        }
        metricsConfiguration = {
          destinations = ["dataDog"]
        }
      }
    }
  })
}

Punkt końcowy OTLP

Punkt końcowy protokołu OpenTelemetry (OTLP) to miejsce docelowe danych telemetrycznych, które zużywa dane OpenTelemetry. W konfiguracji aplikacji można dodać wiele punktów końcowych OTLP. Poniższy przykład dodaje dwa punkty końcowe i wysyła następujące dane do tych punktów końcowych.

Chociaż można skonfigurować dowolną liczbę punktów końcowych skonfigurowanych przez protokół OTLP, każdy punkt końcowy musi mieć odrębną nazwę.

{
  "properties": {
    "appInsightsConfiguration": {},
    "openTelemetryConfiguration": {
      "destinationsConfiguration":{
        "otlpConfigurations": [
          {
            "name": "otlp1",
            "endpoint": "ENDPOINT_URL_1",
            "insecure": false,
            "headers": "api-key-1=key"
          },
          {
            "name": "otlp2",
            "endpoint": "ENDPOINT_URL_2",
            "insecure": true
          }
        ]
      },
      "logsConfiguration": { 
        "destinations": ["otlp2"]
      },
      "tracesConfiguration":{
        "destinations": ["otlp1", "otlp2"]
      },
      "metricsConfiguration": {
        "destinations": ["otlp1"]
      }
    }
  }
}

resource environment 'Microsoft.App/managedEnvironments@2024-10-02-preview' = {
  ...
  properties: {
    openTelemetryConfiguration: {
      destinationsConfiguration: {
        otlpConfigurations: [
          {
            name: 'otlp1'
            endpoint: 'ENDPOINT_URL_1'
            insecure: false
            headers: 'api-key-1=key'
          }
          {
            name: 'otlp2'
            endpoint: 'ENDPOINT_URL_2'
            insecure: true
          },
        ]
      }
      logsConfiguration: {
        destinations: [
          'otlp2'
        ]
      }
      tracesConfiguration: {
        destinations: [
          'otlp1'
          'otlp2'
        ]
      }
      metricsConfiguration: {
        destinations: [
          'otlp1'
        ]
      }
    }
  }
}

az containerapp env telemetry otlp add \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <ENVIRONMENT_NAME> \
  --otlp-name "otlp1" \
  --endpoint "ENDPOINT_URL_1" \
  --insecure false \
  --headers "api-key-1=key" \
  --enable-open-telemetry-traces true \
  --enable-open-telemetry-metrics true
az containerapp env telemetry otlp add \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <ENVIRONMENT_NAME> \
  --otlp-name "otlp2" \
  --endpoint "ENDPOINT_URL_2" \
  --insecure true \
  --enable-open-telemetry-traces true \
  --enable-open-telemetry-logs true

resource "azapi_update_resource" "app_insights_open_telemetry_integration" {
  name      = azurerm_container_app_environment.managed_environment.name
  parent_id = azurerm_resource_group.resource_group.id
  type      = "Microsoft.App/managedEnvironments@2023-11-02-preview"
  body = jsonencode({
    properties = {
      openTelemetryConfiguration = {
        destinationsConfiguration = {
          otlpConfigurations = [
            {
              name = "otlp1"
              endpoint = "ENDPOINT_URL_1"
              insecure = false
              headers = "api-key-1=key"
            },
            {
              name = "otlp2"
              endpoint = "ENDPOINT_URL_2"
              insecure = true
            }
          ]
        }
        logsConfiguration = { 
          destinations = [
            "otlp2"
          ]
        },
        tracesConfiguration = {
          destinations = [
            "otlp1",
            "otlp2"
          ]
        },
        metricsConfiguration = {
          destinations = [
            "otlp1"
          ]
        }
      }
    }
  })
}

Konfigurowanie miejsc docelowych danych

Aby skonfigurować agenta destinations , użyj tablicy, aby zdefiniować, którzy agenci wysyłają dane przez aplikację. Prawidłowe klucze to appInsights, dataDoglub nazwa niestandardowego punktu końcowego OTLP. Możesz kontrolować zachowanie agenta na podstawie typu danych i opcji związanych z punktem końcowym.

Według typu danych

Według punktu końcowego

• Jednocześnie można skonfigurować tylko jeden punkt końcowy usługi Application Insights i datadog.
• Chociaż można zdefiniować więcej niż jeden punkt końcowy skonfigurowany przez otLP, każdy z nich musi mieć odrębną nazwę.

Poniższy przykładowy szablon usługi ARM pokazuje, jak używać punktu końcowego OTLP o nazwie customDashboard. Wysyła:

• śledzenie do szczegółowych informacji o aplikacji i customDashboard
• dzienniki do szczegółowych informacji o aplikacji i customDashboard
• metryki do usługi DataDog i customDashboard

{
  ...
  "properties": {
    ...
    "openTelemetryConfiguration": {
      ...
      "tracesConfiguration": {
        "destinations": [
          "appInsights",
          "customDashboard"
        ]
      },
      "logsConfiguration": {
        "destinations": [
          "appInsights",
          "customDashboard"
        ]
      },
      "metricsConfiguration": {
        "destinations": [
          "dataDog",
          "customDashboard"
        ]
      }
    }
  }
}

Eksportowanie komponentów systemu i sygnałów OpenTelemetry

W wersji interfejsu API OpenTelemetry 2024-08-02-preview, można skonfigurować środowisko aplikacji kontenerowej, aby eksportować sygnały komponentów systemowych OpenTelemetry do miejsc docelowych danych.

Użyj następującej konfiguracji, aby wyeksportować ślady Dapr i metryki KEDA.

Ślady Dapr

Poniższy przykładowy szablon ARM pokazuje, jak wyeksportować Dapr Traces do odpowiednich miejsc docelowych.

{
  ...
  "properties": {
    ...
    "openTelemetryConfiguration": {
      ...
      "tracesConfiguration": {
        "destinations": [
          "appInsights",
          "customDashboard"
        ]，
        "includeDapr": true
      }
    }
  }
}

Aby dowiedzieć się więcej na temat korzystania z języka Dapr w aplikacjach kontenerów, zobacz Omówienie języka Dapr.

Metryki KEDA

Poniższy przykładowy szablon usługi ARM pokazuje, jak wyeksportować metryki KEDA do miejsc docelowych metryk.

{
  ...
  "properties": {
    ...
    "openTelemetryConfiguration": {
      ...
      "metricsConfiguration": {
        "destinations": [
          "dataDog",
          "customDashboard"
        ]，
        "includeKeda": true
      }
    }
  }
}

Aby dowiedzieć się więcej na temat obsługi KEDA w usłudze Container Apps, zobacz Ustawianie reguł skalowania.

Przykładowa konfiguracja openTelemetry

Poniższy przykładowy szablon przedstawia sposób konfigurowania aplikacji kontenera w celu zbierania danych telemetrycznych przy użyciu usługi Azure Monitor Application Insights, Datadog i niestandardowego agenta OTLP o nazwie customDashboard.

Ten przykład działa z plikiem parametrów używanym do pobierania klucza interfejsu API usługi Datadog z usługi Azure Key Vault.

Przed wdrożeniem tego szablonu zastąp element <PLACEHOLDERS> swoimi wartościami.

{
  "location": "eastus",
  "properties": {
    "appInsightsConfiguration": {
      "connectionString": "<APP_INSIGHTS_CONNECTION_STRING>"
    },
    "openTelemetryConfiguration": {
      "destinationsConfiguration": {
        "dataDogConfiguration": {
          "site": "datadoghq.com",
          "key": "parameters('datadogapikey')]"
        },
        "otlpConfigurations": [
          {
            "name": "customDashboard",
            "endpoint": "<OTLP_ENDPOINT_URL>",
            "insecure": true
          }
        ]
      },
      "tracesConfiguration": {
        "destinations": [
          "appInsights",
          "customDashboard"
        ]
      },
      "logsConfiguration": {
        "destinations": [
          "appInsights",
          "customDashboard"
        ]
      },
      "metricsConfiguration": {
        "destinations": [
          "dataDog",
          "customDashboard"
        ]
      }
    }
  }
}

@secure()
param datadogapikey string

resource environment 'Microsoft.App/managedEnvironments@2024-10-02-preview' = {
  name: '<ENVIRONMENT_NAME>'
  location: '<LOCATION>'
  properties: {
    appInsightsConfiguration: {
      connectionString: '<APP_INSIGHTS_CONNECTION_STRING>'
    }
    openTelemetryConfiguration: {
      destinationsConfiguration: {
        dataDogConfiguration: {
          site: 'datadoghq.com'
          key: datadogapikey
        }
        otlpConfigurations: [
          {
            name: 'customDashboard'
            endpoint: '<OTLP_ENDPOINT_URL>'
            insecure: true
          }
        ]
      }
      tracesConfiguration: {
        destinations: [
          'appInsights'
          'customDashboard'
        ]
      }
      logsConfiguration: {
        destinations: [
          'appInsights'
          'customDashboard'
        ]
      }
      metricsConfiguration: {
        destinations: [
          'dataDog'
          'customDashboard'
        ]
      }
    }
  }
}

Aby uzyskać więcej informacji, zobacz Microsoft.App/managedEnvironments.

Odporność danych

W przypadku przerwania wiadomości na punkt końcowy agent OpenTelemetry używa następującej procedury do obsługi odporności danych:

• Buforowanie i ponawianie prób w pamięci: agent przechowuje dane w pamięci i ponawia próbę (z wycofywaniem) przez maksymalnie pięć minut.
• Porzucanie danych: jeśli buforowana kolejka zostanie wypełniona lub punkt końcowy nadal nie działa po wielokrotnych próbach ponowienia, agent odrzuca najstarsze pakiety, aby uniknąć zużycia pamięci.

Zmienne środowiskowe

Agent OpenTelemetry automatycznie wprowadza zestaw zmiennych środowiskowych do aplikacji w czasie wykonywania.

Pierwsze dwie zmienne środowiskowe są zgodne ze standardową konfiguracją eksportera OpenTelemetry i są używane w standardowych zestawach programistycznych OTLP. Jeśli jawnie ustawisz zmienną środowiskową w specyfikacji aplikacji kontenera, wartość zastępuje automatycznie wstrzykniętą wartość.

Dowiedz się więcej o konfiguracji eksportera OTLP, zobacz Konfiguracja eksportera OTLP.

Pozostałe trzy zmienne środowiskowe są specyficzne dla usługi Azure Container Apps i są zawsze wstrzykiwane. Te zmienne przechowują adresy URL punktów końcowych agenta dla każdego określonego typu danych (dzienniki, metryki, ślady).

Te zmienne są konieczne tylko wtedy, gdy używasz zarówno zarządzanego agenta OpenTelemetry, jak i innego agenta OpenTelemetry. Użycie tych zmiennych pozwala kontrolować sposób kierowania danych między różnymi agentami OpenTelemetry.

Koszty agenta OpenTelemetry

Zarządzany agent OpenTelemetry działa bez dodatkowych kosztów obliczeniowych. Microsoft dostarcza i zarządza infrastrukturą agentów w środowisku Twojej aplikacji Container Apps.

Jednak ponosisz odpowiedzialność za opłaty stosowane przez usługi docelowe, w których wysyłasz dane telemetryczne. Zobacz usługę docelową, aby zapoznać się ze strukturą rozliczeń i warunkami. Jeśli na przykład wysyłasz dane do usług Azure Monitor Application Insights i Datadog, odpowiadasz za opłaty stosowane przez obie usługi.

Alokacja zasobów agenta

Zarządzany agent OpenTelemetry jest wyposażony w następujące stałe zasoby:

• Procesor CPU: 0,5 rdzeni procesorów wirtualnych
• Pamięć: 1,5 GB pamięci RAM
• Repliki: pojedyncza replika (nie można skonfigurować)

Te zasoby są zarządzane przez firmę Microsoft i nie są wyświetlane w metrykach rozliczeń ani zużycia zasobów.

Znane ograniczenia

• Dane systemowe, takie jak dzienniki systemowe lub metryki standardowe usługi Container Apps, nie są dostępne do wysłania do agenta OpenTelemetry.
• Punkt końcowy usługi Application Insights nie akceptuje metryk.
• Ustawienia konfiguracji działają na poziomie środowiska. Możesz wysyłać różne typy danych do różnych miejsc docelowych, ale nie można podzielić danych według aplikacji. Na przykład w tej samej aplikacji można wysyłać metryki do usługi Datadog i ślady do usługi App Insights.
• Agent zarządzany obsługuje tylko protokół transportu gRPC dla danych telemetrycznych.
• Zarządzany agent OpenTelemetry działa jako pojedyncza replika i nie można go skalować ani konfigurować pod kątem wysokiej dostępności.
• Metryki stanu agenta i kondycji nie są obecnie widoczne w witrynie Azure Portal ani za pośrednictwem interfejsów API monitorowania.
• Wpisy tajne (takie jak klucze interfejsu API) muszą być określone bezpośrednio w szablonach — integracja usługi Azure Key Vault dla konfiguracji agenta nie jest obecnie obsługiwana.

Najczęściej zadawane pytania

• Czy muszę odwołać się do zestawu OPENTelemetry SDK w kodzie?

  Tak. Zestaw SDK tworzy dane telemetryczne, a zarządzany agent jest odpowiedzialny tylko za kierowanie danych.

• list Dlaczego polecenie zwraca wartość null?

  Po uruchomieniu az containerapp env telemetry otlp list, otrzymujesz odpowiedź null, gdy wartość jest poufnym tokenem, który wymaga ochrony.

• Czy są naliczane opłaty za zasoby obliczeniowe agenta OpenTelemetry?

  Nie. Firma Microsoft aprowizuje infrastrukturę agentów i zarządza nią bez dodatkowych kosztów obliczeniowych. Opłaty są naliczane tylko za usługi docelowe, które odbierają dane telemetryczne.

• Czy mogę skalować agenta OpenTelemetry lub uruchamiać wiele replik?

  Nie. Agent zarządzany działa obecnie jako pojedyncza replika z alokacją zasobów stałych (0,5 procesora CPU, 1,5 GB pamięci RAM). Konfiguracje wysokiej dostępności nie są obecnie obsługiwane.

• Jak mogę monitorować kondycję i stan agenta OpenTelemetry?

  Metryki stanu agenta i kondycji nie są obecnie widoczne. Ta możliwość jest planowana na przyszłe wydanie.

Następne kroki