2013-06-10 6 views
6

Próbuję wykonać kwerendę danych z Azure WadPerformanceCountersTable.Azure instancje od 0 do 3 niepisywanie danych diagnostycznych w tabeli WadPerformanceCountersTable

Próbuję uzyskać ostatnie 5 minut danych.

Problem polega na tym, że otrzymuję tylko dane z instancji nr. 4,5 i 6, ale nie z 0,1,2 i 3.

Skrypt Używam ciągnąć de dane to:

Microsoft.WindowsAzure.CloudStorageAccount storageAccount = Microsoft.WindowsAzure.CloudStorageAccount.Parse(AppDefs.CloudStorageAccountConnectionString); 
      CloudTableClient cloudTableClient = storageAccount.CreateCloudTableClient(); 
      TableServiceContext serviceContext = cloudTableClient.GetDataServiceContext(); 
      IQueryable<PerformanceCountersEntity> traceLogsTable = serviceContext.CreateQuery<PerformanceCountersEntity>("WADPerformanceCountersTable"); 
      var selection = from row in traceLogsTable 
          where row.PartitionKey.CompareTo("0" + DateTime.UtcNow.AddMinutes(-timespanInMinutes).Ticks) >= 0 
          && row.DeploymentId == deploymentId 
          && row.CounterName == @"\Processor(_Total)\% Processor Time" 

          select row; 
      CloudTableQuery<PerformanceCountersEntity> query = selection.AsTableServiceQuery<PerformanceCountersEntity>(); 
      IEnumerable<PerformanceCountersEntity> result = query.Execute(); 
      return result; 

Mój plik diagnostics.wadcfg to:

<?xml version="1.0" encoding="utf-8" ?> 
<DiagnosticMonitorConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration" configurationChangePollInterval="PT1M" overallQuotaInMB="4096"> 
    <PerformanceCounters bufferQuotaInMB="0" scheduledTransferPeriod="PT5M"> 
    <PerformanceCounterConfiguration counterSpecifier="\Memory\Available Bytes" sampleRate="PT60S" /> 
    <PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT60S" />  
    </PerformanceCounters> 
</DiagnosticMonitorConfiguration> 

EDIT: również mam ten kod wdrożony w środowisku testowym w błękicie, i to działa dobrze.

EDIT 2: Aktualizacja obejmuje serwis Definicje XML:

<ServiceDefinition name="MyApp.Azure" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2012-05.1.7"> 
    <WebRole name="MyApp.Website" vmsize="ExtraSmall"> 
    <Sites> 
     <Site name="Web"> 
     <Bindings> 
      <Binding name="Endpoint1" endpointName="Endpoint1" /> 
     </Bindings> 
     </Site> 
    </Sites> 
    <Endpoints> 
     <InputEndpoint name="Endpoint1" protocol="http" port="80" /> 
    </Endpoints> 
    <Imports> 
     <Import moduleName="Diagnostics" /> 
    </Imports> 
    </WebRole> 
    <WorkerRole name="MyApp.Cache" vmsize="ExtraSmall"> 
    <Imports> 
     <Import moduleName="Diagnostics" /> 
     <Import moduleName="Caching" /> 
    </Imports> 
    <LocalResources> 
     <LocalStorage name="Microsoft.WindowsAzure.Plugins.Caching.FileStore" sizeInMB="1000" cleanOnRoleRecycle="false" /> 
    </LocalResources> 
    </WorkerRole> 
</ServiceDefinition> 

Po Znam odpowiedź użytkownik @Igorek „s mam włączone mój XML konfiguracji ServiceDefinition.csdef. Wciąż nie jestem świadomy, jak skonfigurować część LocalResources> LocalStorage konfiguracji. Konfiguracja musi być ustawiona dla "MyApp.Website".

EDYCJA 3: Dokonałem tych zmian na koncie testowym Lazur.

I ustawić to ServiceDefinitions.csdef

<LocalResources> 
    <LocalStorage name="DiagnosticStore" sizeInMB="4096" cleanOnRoleRecycle="false"/> 
</LocalResources>  

I obniżyły OverallQuota i BufferQuota w diagnostics.wadcfg W końcu, w odbojnika sterujących pojemnika I tej konfiguracji w danym przypadku: http://pastebin.com/aUywLUfE

Będę musiał umieścić to na koncie na żywo, aby zobaczyć wyniki.

EDYCJA KOŃCOWA: Najwyraźniej ogólna kwota stanowiła problem, mimo że nie mogę jej zagwarantować.

W końcu, po nowym publikować zauważyłem to:

  • instancji rola miała XML konfiguracji w wad-control-container ze związkiem overall quota z 1024MB i BufferQuotaInMB z 1024MB -> to było prawidłowe ,
  • kolejne 2 przypadki rola miała całkowitą kwotę 4080MB i BufferQuotaInMB z 500MB -> to było błędne, nie pisali w WADPerfor Tabela manceCounters.
  • oba pliki konfiguracyjne XML (które były w wad-control-container) należące do każdej instancji roli zostały usunięte przed opublikowaniem nowego.
  • plik konfiguracyjny diagnostics.wadcfg został skonfigurowany poprawnie: 1024MB everywere

Więc myślę, że nie ma problemu z ich wydawcy.

dwa rozwiązania zostały próbowałem:

  1. I usunięte 1 nieprawidłowy XML z 'wad-control-kontenera' i ponownym uruchomieniu urządzenia. XML został przepisany i instancja roli zaczęła pisać w WADPerfCountTable.

  2. Użyłem poniższego skryptu na innej niepoprawnej instancji i niepoprawna instancja roli zaczęła pisać w WADPerfCountTable.

     var storageAccount = CloudStorageAccount.Parse(AppDefs.CloudStorageAccountConnectionString); 
    
         DeploymentDiagnosticManager diagManager = new DeploymentDiagnosticManager(storageAccount, deploymentId); 
    
         IEnumerable<RoleInstanceDiagnosticManager> instanceManagers = diagManager.GetRoleInstanceDiagnosticManagersForRole(roleName); 
    
         foreach (var roleInstance in instanceManagers) 
         { 
          DiagnosticMonitorConfiguration currentConfiguration = roleInstance.GetCurrentConfiguration(); 
          TimeSpan configurationChangePollInterval = TimeSpan.FromSeconds(60); 
          if (!IsCurrentConfigurationCorrect(currentConfiguration, overallQuotaInMb, TimeSpan.FromMinutes(1), TimeSpan.FromMinutes(1))) 
          { 
           // Add a performance counter for processor time. 
           PerformanceCounterConfiguration pccCPU = new PerformanceCounterConfiguration(); 
           pccCPU.CounterSpecifier = @"\Processor(_Total)\% Processor Time"; 
           pccCPU.SampleRate = TimeSpan.FromSeconds(60); 
    
           // Add a performance counter for available memory. 
           PerformanceCounterConfiguration pccMemory = new PerformanceCounterConfiguration(); 
           pccMemory.CounterSpecifier = @"\Memory\Available Bytes"; 
           pccMemory.SampleRate = TimeSpan.FromSeconds(60); 
    
           currentConfiguration.ConfigurationChangePollInterval = TimeSpan.FromSeconds(60); 
           currentConfiguration.OverallQuotaInMB = overallQuotaInMb; 
           currentConfiguration.PerformanceCounters.BufferQuotaInMB = overallQuotaInMb; 
           currentConfiguration.PerformanceCounters.DataSources.Add(pccCPU); 
           currentConfiguration.PerformanceCounters.DataSources.Add(pccMemory); 
           roleInstance.SetCurrentConfiguration(currentConfiguration); 
          } 
    
         } 
    

Również trzymam ten błąd od czasu do czasu The configuration file is missing a diagnostic connection string for one or more roles.

Pod koniec wybiorę bieżącą odpowiedź jako odpowiedź, ponieważ znalazłem problem. Niestety, nie znalazłem przyczyny problemu. Przy każdym opublikowaniu ryzykuję uzyskanie zmienionego XML-a.

+2

Jesteśmy przeżywa podobny problem, gdzie dwóch z naszych 5 przypadkach nie pisać liczników wydajności i resztę roboty. Mam nadzieję, że ktoś może na to odpowiedzieć! Myślę, że to problem z diagnostyczną biblioteką DLL. Z jakiej wersji SDK korzystasz? – greg84

+0

Witam, używamy 1.7. –

+0

Interesujące - obecnie używamy 1.6 - Zastanawiam się, jak SDK radzi sobie z błędami napotykanymi podczas pisania diagnostyki i czy "wykonuje próbę", gdy napotka błąd. Czy jesteś w stanie dokonać aktualizacji do najnowszej wersji SDK? – greg84

Odpowiedz

3

Widząc jak twoje pierwsze przypadki nie są w trakcie przesyłania danych do diagnostyki natomiast późniejsze przypadki zrobić, jeden możliwy powód jest następujący:

Miejscowy sklep diagnostyczny na serwerach jest wypełniona danych diagnostycznych i Azure nie może dłużej przenieś dane z lokalnego sklepu do magazynu. Upewnij się, że to miejsce przydzielone do magazynu diagnostycznego w konfiguracji roli (w obszarze Magazyn lokalny) jest większe niż ilość przydziału bufora przydzielona w diagnostyce.wadcfg

Szczegółowe wyjaśnienie: Doświadczyłem tego z pierwszej ręki z wieloma klientami Oto moja własna interpretacja oparta na komentarzach ze strony Microsoft. Interfejs Azure Diagnostics API nie usuwa pamięci lokalnej zgodnie z BufferQuota, dopóki ten limit nie zostanie przekroczony. Projekt DiagnosticStore in cloud domyślnie ma taki sam rozmiar, jak BufferQuota użyty we wszystkich przykładach (4096). Co się dzieje, to że twój BufferQuota dostaje się okropnie blisko 4096 megabajtów, ale nie jest równy limitowi, a Twój diagnostyczny interfejs API nie uruchamia procesu czyszczenia. W tym samym czasie przechwytywanie danych diagnostycznych nie może już działać poprawnie, ponieważ pamięć lokalna jest prawie pełna, a host Azure zatrzymuje zdolność aplikacji do pisania w DiagnosticStore.

Twoje inne serwery powinny zaprzestać zapisywania danych diagnostycznych, gdy tylko zapełni się ich lokalny magazyn.

Mam nadzieję, że to ma sens.

Edycja moją odpowiedź precyzyjnie wskazać zmiany dla każdego, czytanie później:

Najprostszym rozwiązaniem jest stonować potrzebę OverallQuotaInMb określonym w diagnostics.wadcfg być coś jak 4000 (należy upewnić się, że wszystkie inne połączone bufory nie przekraczają tej liczby)

Alternatywnie lub dodatkowo można ręcznie określić przestrzeń przydzieloną do magazynu diagnostycznego na VM przy użyciu ustawienia LocalStorage w pliku .CSDEF.Ten link pokazuje jak: http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.diagnostics.diagnosticmonitorconfiguration.overallquotainmb.aspx

+0

I zostały zaktualizowane moje pytanie włączenia XML ServiceDefinition.csdef. Jaką ** nazwę ** mam umieścić w LocalResources> LocalStorage, aby konfiguracja była w porządku? Nie znalazłem nic istotnego w Internecie, aby skonfigurować XML. –

+0

Rozglądałem się i znalazłem ten link: http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.diagnostics.diagnosticmonitorconfiguration.overallquotainmb.aspx. Czy to właściwe ustawienie muszę ustawić? –

+1

@Dragos, ten ostatni link jest poprawny. Możesz ręcznie skonfigurować lokalną pamięć masową o nazwie "DiagnosticStore", aby była większa niż 4096 lub upuść swój WholeQuotaInMb na około 4000, aby była bezpieczna. – Igorek

Powiązane problemy