Dela via

Felsöka problem med hanterade DevOps-pooler

Den här artikeln innehåller lösningar på vanliga problem med hanterade DevOps-pooler.

Fel vid skapande av pool

Felkod beskrivning
PoolProvisioningFailed Fel vid skapande av pool på grund av Azure DevOps-organisationsbehörigheter
UnauthorizedAccessToVirtualNetwork Fel vid skapande av pool på grund av VNet-behörigheter

Fel vid skapande av pool på grund av Azure DevOps-organisationsbehörigheter

Det går inte att skapa poolen med ett fel som liknar ett av följande felmeddelanden.

Den inloggade användaren hittades inte i Azure DevOps-organisationen

  • Validation failure "PoolProvisioningFailed": "Failed to provision agent pool. Exception: The logged in user, <your user>, was not found in the Azure DevOps organization provided, <your Azure DevOps organization>."

Så här löser du problemet:

Den inloggade användaren har inte Hantera behörigheter i Azure DevOps-organisationen

  • Validation failure "PoolProvisioningFailed": "Failed to provision agent pool. Exception: The logged in user, <your user>, does not have Manage permissions in the Azure DevOps organization provided, <your Azure DevOps organization>."

Så här löser du problemet:

Fel vid skapande av pool på grund av VNet-behörigheter

Det går inte att skapa poolen med ett UnauthorizedAccessToVirtualNetwork fel som liknar följande fel: Validation failure "UnauthorizedAccessToVirtualNetwork": "DevOpsInfrastructure service principal does not have Read access to virtual network <your VNet> in resource group <your resource group>. Give Reader and Network Contributor access to DevOpsInfrastructure service principal and try again..

Lös problemet så här:

Fördröjningar i pipeline-start

När du använder Hanterade DevOps-pooler kan det uppstå situationer där det är en lång fördröjning innan en pipeline börjar köras efter att den har utlösts. I det här avsnittet i felsökningsguiden beskrivs vanliga objekt som kan påverka poolernas prestanda. Mer information finns i Hantera kostnader och prestanda.

Sök efter otillräckliga parallella jobb

Hanterade agenter i DevOps-pooler betraktas som självhostade agenter av Azure DevOps och kräver självhostade parallelljobb för att köras. Till exempel, om organisationens antal självhostade parallella är 10, kan din organisation bara köra 10 självhostade pipelinejobb samtidigt. Om fler än 10 pipelines står i kö kan endast 10 i taget köra.

Kontrollera antalet självhostade parallella processer för att se till att du har tillräcklig kapacitet för att uppfylla de samtidiga pipelinebehoven för din arbetsbelastning. Mer information finns i Konfigurera och betala för parallella jobb.

Kontrollera konfiguration av maximala agenter

Inställningen Maximalt antal agenter konfigurerar det maximala antalet agenter som körs i din hanterade DevOps-pool. Om inställningen Maximalt antal agenter är 5 kan hanterade DevOps-pooler köra högst fem samtidiga pipelines. Om fler än fem pipelines placeras i kö startar inte de ytterligare pipelines förrän en av de fem tillgängliga agenterna är tillgänglig.

Anmärkning

Maximalt antal agenter konfigurerar det maximala antalet agenter som kan etableras samtidigt, men organisationens egenvärdade parallella jobb anger antalet jobb som kan köras samtidigt. Se till att du har tillräckligt med parallella jobb med egen värd i din organisation för att dina agenter ska kunna köra jobb. Mer information finns i Parallella jobbpriser för Azure DevOps Services.

Överväg att förbereda agenter med hjälp av ett schema för standby-agenter

Om standby-agentläget är inaktiverat startas hanterade DevOps-poolagenter på begäran när en pipeline placeras i kö, och även om det vanligtvis bara tar en stund att starta en ny agent kan det ibland ta upp till 15 minuter.

När läget För väntelägesagent är aktiverat kan du ange ett schema och antalet agenter som ska vara redo att uppfylla arbetsbelastningens krav.

För mer information, se Hantera kostnader och prestanda – Förberedelse med standby-agenter.

Automatiskt vänteläge för nya pooler

Hantera DevOps-pooler använder historiska poolanvändningsdata för att göra sina automatiska skalningsförutsägelser i vänteläge . Nya pooler har inga historiska data, så agenter kan skapas på begäran. För att förbättra prestandan kan du växla till manuellt vänteläge för den första månaden och växla till automatiskt vänteläge när hanterade DevOps-pooler har haft tid att observera poolens användning.

Kontrollera standby-agentens procentandel om du använder väntelägesagenter med flera bilder

Om du använder väntelägesagenter med flera bilder, kontrollera användningshistoriken per bild och jämför med inställningen procent för väntelägesagenter för att säkerställa att ditt väntelägesförhållande matchar din användning. Om du till exempel har en Windows-avbildning och en Ubuntu-avbildning, och din arbetsbelastning använder Windows 75% av tiden, kontrollerar du att Din Windows-avbildning har konfigurerats med en standby-agentprocent på 75.

Överväg att använda tillståndskänsliga pooler med en respitperiod för att hålla agenter online

Ett alternativ för att förbättra agentprestanda utan att använda väntelägesagenter är att använda tillståndskänsliga agenter med en kort respitperiod. När en tillståndskänslig agent med en respitperiod slutför ett jobb förblir den online under den tid som anges av respitperioden och väntar på ytterligare jobb. Om din arbetsbelastning kommer i stötar kan du konfigurera en respitperiod som håller agenter online när jobben är stabila och startar dem från början under långsammare perioder.

Mer information finns i Standby-agenter och Tillståndskänsliga pooler.

Kontrollera felkoder för timeout

Om tidsgränsen för agenttilldelningen överskrids kan du kontrollera felkoden i avsnittet Felkoder på sidan Översikt .

Pipelinen misslyckas med att slutföras

Kontrollera om det har gjorts en avbildningsuppdatering

Om dina pipelines börjar misslyckas efter en avbildningsuppdatering kan du tillfälligt konfigurera dina pipelines så att de använder den tidigare avbildningsversionen. Du kan konfigurera dina misslyckade pipelines så att de använder den tidigare avbildningsversionen per pipeline, eller så kan du konfigurera den tidigare avbildningsversionen för alla pipelines i din hanterade DevOps-pool som använder den avbildningen.

Om du vill se om dina pipelines misslyckas på grund av en ändring av avbildningsversionen jämför du avbildningsversionen på en misslyckad pipelinekörning med avbildningsversionen från den senaste lyckade pipelinekörningen.

  1. Gå till din pipeline och granska pipeline-körningshistoriken för din pipeline.

    Skärmbild av pipelinekörningar.

  2. Visa körningsinformationen för de två pipelinekörningar som du vill jämföra och välj pipelinejobbet för att visa diagnostikinformation om det jobbet. Om din pipeline har flera jobb väljer du det jobb som körs med hjälp av din hanterade DevOps-pool.

    En skärmbild av detaljinformation om en pipelinekörning.

  3. Välj Initiera jobb och hämta avbildningsversionen från avsnittet Aktuell avbildningsversion .

    Skärmbild av pipelinekörningens avbildningsversion.

Om avbildningsversionerna skiljer sig från den senaste misslyckade pipelinekörningen och den tidigare lyckade körningen kan felet orsakas av en avbildningsuppdatering. Du har två alternativ för att tillfälligt återgå till den tidigare bildversionen medan du felsöker orsaken.

Hanterade DevOps-pooler håller de senaste 20 avbildningarna tillgängliga för valda marketplace-avbildningar och de senaste 10 för Azure Pipelines-avbildningar. Tidigare versioner av Azure Compute Gallery-avbildningar underhålls av ägarna till dessa Azure Compute Galleries.

Se även