Kontrollera och felsök efter uppgradering post-upgrade-checks-and-troubleshooting

Bokför uppgraderingskontroller post-upgrade-checks

Efter Lokal uppgradering följande aktiviteter ska utföras för att slutföra uppgraderingen. Det antas att AEM har startats med 6.4-behållaren och att den uppgraderade kodbasen har distribuerats.

Verifiera loggar för lyckad uppgradering verify-logs-for-upgrade-success

upgrade.log

Tidigare krävdes noggrann kontroll av olika loggfiler, delar av databasen och startplattan för att kontrollera status efter uppgraderingen av instansen. Genom att generera en rapport efter uppgraderingen kan du upptäcka defekta uppgraderingar innan du publicerar den.

Huvudsyftet med den här funktionen är att minska behovet av manuell tolkning eller komplex parsningslogik för flera slutpunkter som krävs för att en uppgradering ska lyckas. Lösningen syftar till att tillhandahålla entydig information för externa automatiseringssystem som kan reagera på om en uppdatering lyckas eller inte.

Mer specifikt säkerställer det att

För att hantera detta har ändringar gjorts i hur loggarna genereras i upgrade.log -fil.

Här följer ett exempel på en rapport som inte visar några fel under uppgraderingen:

Här följer ett exempel på en rapport som visar ett paket som inte installerades under uppgraderingsprocessen:

error.log

error.log bör granskas noggrant under och efter det att AEM startas med målversionen jar. Alla varningar och fel bör granskas. I allmänhet är det bäst att söka efter problem i början av loggen. Fel som inträffar senare i loggen kan i själva verket vara biverkningar av en rotorsak som anropas tidigt i filen. Om upprepade fel och varningar inträffar, se nedan för Analysera problem med uppgraderingen.

Verifiera OSGi Bundles verify-osgi-bundles

Navigera till OSGi-konsolen /system/console/bundles och kontrollera om några paket inte har startats. Om något paket är installerat läser du error.log för att fastställa rotproblem.

Verifiera Oak-version verify-oak-version

Efter uppgraderingen bör du se att Oak-versionen har uppdaterats till 1.8.2. Verifiera Oak-versionen genom att navigera till OSGi-konsolen och titta på den version som är associerad med Oak bundles: Oak Core, Oak Commons, Oak Segment tar.

Inspect PreUpgradeBackup, mapp inspect-preupgradebackup-folder

Under uppgraderingen försöker AEM säkerhetskopiera anpassningar och lagra dem under /var/upgrade/PreUpgradeBackup/<time-stamp-of-upgrade>. Om du vill visa den här mappen i CRXDE Lite måste du kanske temporärt aktivera CRXDE Lite.

Mappen med tidsstämpeln ska ha en egenskap med namnet mergeStatus med värdet COMPLETED. The att bearbeta mappen ska vara tom och överskriven noden anger vilka noder som skrevs över under uppgraderingen. Innehåll under leftovers noden anger innehåll som inte kan sammanfogas på ett säkert sätt under uppgraderingen. Om implementeringen är beroende av någon av de underordnade noderna (och inte redan har installerats av det uppgraderade kodpaketet) måste de sammanfogas manuellt.

Inaktivera CRXDE Lite efter den här övningen om det finns på en scen- eller produktionsmiljö.

Inledande validering av sidor initial-validation-of-pages

Utför en inledande validering mot flera sidor i AEM. Om du uppgraderar en redigeringsmiljö öppnar du Start-sidan och välkomstsidan ( /aem/start.html, /libs/cq/core/content/welcome.html). I både redigerings- och publiceringsmiljöer öppnas några programsidor och röktester som återges korrekt. Om det uppstår problem kan du läsa error.log för att felsöka.

Använd AEM apply-aem-service-packs

Använd eventuella relevanta AEM 6.4 Service Pack om de har släppts.

Migrera AEM migrate-aem-features

Flera funktioner i AEM kräver ytterligare steg efter uppgraderingen. En fullständig lista över dessa funktioner och steg för att migrera dem i AEM 6.4 finns på Uppgradera kod och anpassningar sida.

Verifiera schemalagda underhållskonfigurationer verify-scheduled-maintenance-configurations

Aktivera skräpinsamling för datalager enable-data-store-garbage-collection

Om du använder ett fildatalager måste du se till att skräpinsamlingsaktiviteten för datalagret är aktiverad och läggs till i listan Veckounderhåll. Instruktioner beskrivs här.

Aktivera rensning av onlineändringar enable-online-revision-cleanup

Om du använder MongoMK eller det nya StjärmMK-segmentformatet ser du till att aktiviteten Revision Clean Up (Revision Clean Up) är aktiverad och läggs till i listan Daily Maintenance (Dagligt underhåll). Instruktioner här.

Kör testplan execute-test-plan

Kör detaljerad testplan mot definierad Uppgradera kod och anpassningar under Provningsförfarande -avsnitt.

Aktivera replikeringsagenter enable-replication-agents

När publiceringsmiljön har uppgraderats och validerats aktiverar du replikeringsagenter i redigeringsmiljön. Kontrollera att agenter kan ansluta till respektive publiceringsinstanser. Se Uppgraderingsprocedur om du vill ha mer information om ordningen för händelser.

Aktivera anpassade schemalagda jobb enable-custom-scheduled-jobs

Alla schemalagda jobb som en del av kodbasen kan nu aktiveras.

Analysera problem med uppgraderingen analyzing-issues-with-upgrade

I det här avsnittet finns några felscenarier som man kan ställas inför under uppgraderingsproceduren till AEM 6.4.

Dessa scenarier bör hjälpa till att hitta orsaken till uppgraderingsrelaterade problem och bör hjälpa till att identifiera projekt- eller produktspecifika problem.

Återskapa Dynamic Media Cloud-konfigurationen efter uppgradering dynamic-media-cloud-configuration

När du har uppgraderat till AEM 6.4 från en tidigare version kan Dynamic Media Cloud-konfigurationen från tidigare inställningar bli otillgänglig från TouchUI AEM 6.4. Du löser det här problemet genom att använda CRXDE Lite för att ta bort de tidigare inställningarna och sedan skapa en ny Dynamic Media Cloud-konfiguration. Se även Omstrukturering av Dynamic Media-arkiv i AEM 6.4.

Databasmigreringen misslyckades repository-migration-failing-

Datamigrering från CRX2 till Oak bör vara möjlig för alla scenarier som börjar med källinstanser baserade på CQ 5.4. Se till att du följer uppgraderingsinstruktionerna i det här dokumentet som innehåller förberedelsen av repository.xmlkontrollerar du att ingen anpassad autentiserare har startats via JAAS och att instansen har kontrollerats för inkonsekvenser innan migreringen påbörjas.

Om migreringen fortfarande misslyckas kan du ta reda på vad som är grundorsaken genom att granska upgrade.log. Om problemet inte är känt ännu, rapportera det till kundsupport.

Uppgraderingen kördes inte the-upgrade-did-not-run

Innan du startar förberedelsestegen bör du kontrollera att du kör källa först genom att köra den med kommandot java -jar aem-quickstart.jar. Detta krävs för att filen quickstart.properties ska kunna genereras korrekt. Om den saknas fungerar inte uppgraderingen. Du kan också kontrollera om filen finns genom att titta under crx-quickstart/conf i källinstansens installationsmapp. När du startar AEM för att starta uppgraderingen måste den dessutom köras med kommandot java -jar aem-quickstart.jar. Att starta från ett startskript startar inte AEM i uppgraderingsläge.

Paket och paket kunde inte uppdateras packages-and-bundles-fail-to-update-

Om paketen inte installeras under uppgraderingen kommer de paket de innehåller inte heller att uppdateras. Den här kategorin av problem orsakas vanligtvis av felkonfigurering av datalagret. De ser också ut som FEL och VARNING meddelanden i error.log. Eftersom standardinloggningen i de flesta fall kanske inte fungerar kan du använda CRXDE direkt för att undersöka och hitta konfigurationsproblemen.

Vissa AEM byter inte till aktivt läge some-aem-bundles-are-not-switching-to-the-active-state

Om paketen inte startar bör du kontrollera om du inte är nöjd med beroendet.

Om det här problemet uppstår men baseras på en misslyckad paketinstallation som ledde till att paket inte uppgraderas, kommer de att anses vara inkompatibla för den nya versionen. Mer information om hur du felsöker detta finns i Paket och paket kunde inte uppdateras ovan.

Vi rekommenderar också att du jämför paketlistan för en ny instans av AEM 6.4 med den uppgraderade instansen för att identifiera de paket som inte uppgraderats. Detta ger en närmare beskrivning av vad du ska söka efter i error.log.

Anpassade paket växlar inte till aktivt läge custom-bundles-not-switching-to-the-active-state

Om dina anpassade paket inte växlar till det aktiva läget är det mest troligt att det finns kod som inte importerar ändrings-API. Detta leder ofta till missnöjda beroenden.

API som har tagits bort ska markeras som borttaget i en av de tidigare versionerna. Instruktioner om direktmigrering av koden finns i det här meddelandet om borttagning. Adobe planerar semantisk versionshantering där det är möjligt, så att versionerna kan visa på förändringar som går förlorade.

Det är också bäst att kontrollera om den ändring som har orsakat problemet var absolut nödvändig och återställa den om den inte är det. Kontrollera också om versionsökningen av paketexporten ökade mer än nödvändigt efter strikt semantisk versionshantering.

Felaktigt gränssnitt för plattformen malfunctioning-platform-ui

Om det finns vissa gränssnittsfunktioner som inte fungerar som de ska efter uppgraderingen bör du först kontrollera om gränssnittet är anpassat. Vissa strukturer kan ha ändrats och övertäckningen kan behöva uppdateras eller vara föråldrad.

Kontrollera sedan om det finns JavaScript-fel som kan spåras till anpassade tillagda tillägg som är kopplade till klientbibliotek. Samma sak kan gälla för anpassad CSS som kan orsaka problem med den AEM layouten.

Slutligen kontrollerar du om Javascript inte kan hantera en felkonfiguration. Detta är vanligtvis fallet med felaktigt inaktiverade tillägg.

Felfungerande anpassade komponenter, mallar eller gränssnittstillägg malfunctioning-custom-components-templates-or-ui-extensions

I de flesta fall är orsaken till de här problemen densamma som för paket som inte har startats eller paket som inte installeras med den enda skillnaden att problemen börjar inträffa när komponenterna används för första gången.

Ett sätt att hantera felaktig egen kod är att först utföra röktester för att identifiera orsaken. När du har hittat det kan du titta på rekommendationerna i det här [link] i artikeln om hur du åtgärdar dem.

Anpassningar saknas under etc missing-customizations-under-etc

/apps och /libs hanteras väl av uppgraderingen, men ändringar i /etc kan behöva återställas manuellt från /var/upgrade/PreUpgradeBackup efter uppgradering. Kontrollera den här platsen för allt innehåll som behöver sammanfogas manuellt.

Analyserar error.log och upgrade.log analyzing-the-error-log-and-upgrade-log

I de flesta fall måste loggarna sökas efter fel för att hitta orsaken till ett problem. Vid uppgraderingar är det dock också nödvändigt att övervaka beroendeproblem eftersom gamla paket kanske inte uppgraderas korrekt.

Det bästa sättet att göra detta är att ta bort error.log genom att ta bort alla meddelanden som inte har med problemet att göra. Du kan göra detta med ett verktyg som grep genom att använda:

grep -v UnrelatedErrorString

Vissa felmeddelanden kanske inte är omedelbart förklarande. I det här fallet kan det vara lättare att förstå var felet uppstod om man tittar i sammanhanget. Du kan avgränsa felet med:

eller

I ett fåtal fall kan fel också hittas i WARN-meddelanden eftersom det kan finnas giltiga fall som leder till det här läget och programmet inte alltid kan avgöra om det här är ett faktiskt fel. Se till att du också läser dessa meddelanden.

Kontakta supporten för Adobe contacting-adobe-support

Om du har gått igenom råden på den här sidan och fortfarande ser problem kan du kontakta Adobe Support. Om du vill ge så mycket information som möjligt till den supporttekniker som arbetar med ditt ärende måste du inkludera filen upgrade.log från uppgraderingen.