Metodtips för resursövervakning assets-monitoring-best-practices
Från Adobe Experience Manager Assets-synpunkt bör övervakningen omfatta övervakning och rapportering av följande processer och tekniker:
-
Systemprocessor
-
Systemminnesanvändning
-
Väntetid för systemdisk-I/O och IO
-
Systemets nätverks-I
-
JMX MBeans for:
- Heap-användning
- Asynkrona processer, t.ex. arbetsflöden
-
OSGi-konsolens hälsokontroller
Vanligtvis Assets kan övervakas på två sätt: live-övervakning och långtidsövervakning.
Live-övervakning live-monitoring
Du bör utföra direktövervakning under prestandatestningsfasen av din utveckling eller under situationer med hög belastning för att förstå prestandaegenskaperna i din miljö. Vanligtvis bör direktövervakning utföras med en uppsättning verktyg. Här är några rekommendationer:
-
Visual VM: Med Visual VM kan du visa detaljerad Java VM-information, inklusive processoranvändning och Java-minnesanvändning. Dessutom kan du sampla och utvärdera kod som körs på en instans.
-
Överkant: Det övre är ett Linux-kommando som öppnar en kontrollpanel som visar användningsstatistik, inklusive processor-, minnes- och IO-användning. Den ger en översikt på hög nivå över vad som händer i en instans.
-
Hopp: Htop är ett interaktivt processvisningsprogram. Den ger detaljerad processor- och minnesanvändning utöver vad Top kan tillhandahålla. Htop kan installeras på de flesta Linux-system med
yum install htop
ellerapt-get install htop
. -
Itop: IOtop är en detaljerad kontrollpanel för diskanvändning. Här visas staplar och mätare som avbildar de processer som använder disk-I/O och hur mycket de använder. Jotop kan installeras på de flesta Linux-system med
yum install iotop
ellerapt-get install iotop
. -
Iftop: Iftop visar detaljerad information om Ethernet-/nätverksanvändning. Om Iftop visar statistik per kommunikationskanal för de enheter som använder Ethernet och den bandbredd de använder. Iftop kan installeras på de flesta Linux-system med
yum install iftop
ellerapt-get install iftop
. -
Java Flight Recorder (JFR): Ett kommersiellt verktyg från Oracle som du kan använda fritt i icke-produktionsmiljöer. Mer information finns i Så här använder du Java Flight Recorder för att diagnostisera CQ-körningsproblem.
-
Experience Manager error.log-fil: Du kan undersöka Experience Manager error.log-fil för information om fel som loggats i systemet. Använda kommandot
tail -F quickstart/logs/error.log
för att identifiera fel som du bör undersöka. -
Arbetsflödeskonsol: Utnyttja arbetsflödeskonsolen för att övervaka arbetsflöden som släpar efter eller fastnar.
Oftast använder du dessa verktyg tillsammans för att få en heltäckande bild av hur ditt Experience Manager -instans.
Övervakning på lång sikt long-term-monitoring
Långsiktig övervakning av en Experience Manager -instans innebär övervakning under en längre tid av samma delar som övervakas live. Det innehåller även definitioner av varningar som är specifika för din miljö.
Loggaggning och rapportering log-aggregation-and-reporting
Det finns flera verktyg tillgängliga för att samla loggar, till exempel Splunk™ och Elastic Search/Logstash/Kabana (ELK). För att utvärdera drifttiden för dina Experience Manager Det är till exempel viktigt för dig att förstå logghändelser som är specifika för ditt system och skapa varningar baserade på dem. En god kunskap om dina utvecklings- och operationsrutiner kan hjälpa dig att bättre förstå hur du kan trimma loggsammanställningsprocessen för att generera kritiska varningar.
Miljöövervakning environment-monitoring
Miljöövervakning omfattar övervakning av följande:
- Nätverksgenomströmning
- Skiva-I
- Minne
- CPU-användning
- JMX MBeans
- Externa webbplatser
Du behöver externa verktyg, som NewRelic™ och AppDynamics™, för att kunna övervaka varje objekt. Med de här verktygen kan du definiera varningar som är specifika för ditt system, till exempel hög systemanvändning, säkerhetskopiering av arbetsflöde, misslyckade hälsokontroller eller oautentiserad åtkomst till din webbplats. Adobe rekommenderar inga särskilda verktyg framför andra. Hitta det verktyg som passar dig och använd det för att övervaka de objekt som diskuteras.
Intern programövervakning internal-application-monitoring
Intern programövervakning inkluderar övervakning av programkomponenter som utgör Experience Manager -stacken, inklusive JVM, innehållsdatabasen och övervakning via anpassad programkod som är byggd på plattformen. I allmänhet genomförs det via JMX Mbeans, som kan övervakas direkt av många populära övervakningslösningar, till exempel SolarWinds ™, HP OpenView™, Hyperic™, Zabbix™ och andra. För system som inte har stöd för en direkt anslutning till JMX kan du skriva gränssnittsskript för att extrahera JMX-data och exponera dem för dessa system i ett format som de själva förstår.
Fjärråtkomst till JMX Mbeans är inte aktiverat som standard. Mer information om övervakning via JMX finns i Övervakning och hantering med JMX-teknik.
I många fall krävs en baslinje för att effektivt kunna övervaka en statistik. Om du vill skapa en baslinje bör du observera systemet under normala arbetsförhållanden under en förutbestämd period och sedan identifiera det normala måttet.
JVM-övervakning
Precis som med alla Java-baserade programstackar, Experience Manager är beroende av vilka resurser som tillhandahålls via den underliggande virtuella Java-datorn. Du kan övervaka status för många av dessa resurser via plattforms-MXBeans som exponeras av JVM. Mer information om MXBeans finns i Använda Platform MBean Server och Platform MXBeans.
Här följer några baslinjeparametrar som du kan övervaka för JVM:
Minne
MBean: lava.lang:type=Memory
- URL: /system/console/jmx/java.lang:type=Memory
- Instanser: Alla servrar
- Larm threshold: När minnesanvändningen för heap eller icke-heap överstiger 75 % av motsvarande maximala minne.
- Larm-definition: Antingen är systemminnet otillräckligt eller så finns det en minnesläcka i koden. Analysera en tråddump för att komma fram till en definition.
Anteckning: Information från denna böna uttrycks i byte.
Trådar
- MBean:
java.lang:type=Threading
- URL: /system/console/jmx/java.lang:type=Threading
- Instanser: Alla servrar
- Larm threshold: När antalet trådar är större än 150 % av baslinjen.
- Larm-definition: Antingen finns det en aktiv runaway-process, eller så använder en ineffektiv åtgärd en stor mängd resurser. Analysera en tråddump för att komma fram till en definition.
Experience Managerövervakning
Experience Manager visar också en uppsättning statistik och åtgärder via JMX. Dessa kan hjälpa till att utvärdera systemets hälsa och identifiera potentiella problem innan de påverkar användarna. Mer information finns i dokumentation på Experience Manager JMX MBeans.
Här är några baslinjeparametrar som du kan övervaka Experience Manager:
Replikeringsagenter
-
MBean:
com.adobe.granite.replication:type=agent,id=”<AGENT_NAME>”
-
URL: /system/console/jmx/com.adobe.granite.replication:type=agent,id="<agent_name>"
-
Instanser: En författare och alla publiceringsinstanser (för rensningsagenter)
-
Larm threshold: När värdet för
QueueBlocked
är true eller värdet förQueueNumEntries
är större än 150% av baslinjen. -
Larm-definition: Det finns en blockerad kö i systemet som anger att replikeringsmålet är nere eller inte kan nås. Nätverks- eller infrastrukturproblem leder ofta till att för många poster köas, vilket kan påverka systemets prestanda negativt.
Anteckning: Ersätt för parametrarna MBean och URL <AGENT_NAME>
med namnet på den replikeringsagent som du vill övervaka.
Sessionsräknare
- MBean:
org.apache.jackrabbit.oak:id=7,name="OakRepository Statistics",type="RepositoryStats"
- URL: /system/console/jmx/org.apache.jackrabbit.oak:id=7,name="OakRepository Statistics",type="RepositoryStats"
- Instanser: Alla servrar
- Larm threshold: När öppna sessioner överskrider baslinjen med mer än 50 %.
- Larm-definition: Sessionerna kan öppnas med kod och aldrig stängas. Detta kan hända långsamt över tid och så småningom orsaka minnesläckor i systemet. Även om antalet sessioner bör variera i ett system, bör de inte öka kontinuerligt.
Hälsokontroller
Hälsokontroller som är tillgängliga i kontrollpanel för åtgärder har motsvarande JMX MBeans för övervakning. Du kan dock skriva anpassade hälsokontroller för att visa ytterligare systemstatistik.
Här följer några färdiga hälsokontroller som är bra att övervaka:
-
Systemkontroller
- MBean:
org.apache.sling.healthcheck:name=systemchecks,type=HealthCheck
- URL: /system/console/jmx/org.apache.sling.healthCheck:name=systemchecks,type=HealthCheck
- Instanser: En författare, alla publiceringsservrar
- Larm threshold: När statusen inte är OK
- Larm-definition: Statusen för ett av mätvärdena är antingen WARN eller CRITICAL. Mer information om orsaken till problemet finns i loggattributet.
- MBean:
-
Replikeringskö
- MBean:
org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck
- URL: /system/console/jmx/org.apache.sling.healthCheck:name=replicationQueue,type=HealthCheck
- Instanser: En författare, alla publiceringsservrar
- Larm threshold: När statusen inte är OK
- Larm-definition: Statusen för ett av mätvärdena är antingen WARN eller CRITICAL. Mer information om kön som orsakade problemet finns i loggattributet.
- MBean:
-
Svarsprestanda
- MBean:
org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck
- URL: /system/console/jmx/org.apache.sling.healthCheck:name=requestsStatus,type=HealthCheck
- Instanser: Alla servrar
- Varaktighet för larm: När statusen inte är OK
- Larm-definition: Status för ett av måtten är antingen WARN eller CRITICAL. Mer information om kön som orsakade problemet finns i loggattributet.
- MBean:
-
Frågeprestanda
- MBean:
org.apache.sling.healthcheck:name=queriesStatus,type=HealthCheck
- URL: /system/console/jmx/org.apache.sling.healthCheck:name= queriesStatus,type=HealthCheck
- Instanser: En författare, alla publiceringsservrar
- Larm threshold: När statusen inte är OK
- Larm-definition: En eller flera frågor körs långsamt i systemet. Mer information om de frågor som orsakade problemet finns i loggattributet.
- MBean:
-
Aktiva paket
- MBean: org.apache.sling.hälsokontroll:name=inactiveBundles,type=HealthCheck
- URL: /system/console/jmx/org.apache.sling.healthCheck:name=inactiveBundles,type=HealthCheck
- Instanser: Alla servrar
- Larm threshold: När statusen inte är OK
- Larm-definition: Förekomst av inaktiva eller olösta OSGi-paket i systemet. Mer information om de paket som orsakade problemet finns i loggattributet.
-
Loggfel
- MBean:
org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck
- URL: /system/console/jmx/org.apache.sling.healthCheck:name=logErrorHealthCheck,type=HealthCheck
- Instanser: Alla servrar
- Larm threshold: När statusen inte är OK
- Larm-definition: Det finns fel i loggfilerna. Mer information om orsaken till problemet finns i loggattributet.
- MBean:
Vanliga problem och lösningar common-issues-and-resolutions
Om du råkar ut för problem i samband med övervakning finns det några felsökningsuppgifter som du kan utföra för att lösa vanliga problem med Experience Manager instanser:
- Om du använder tarMK ska du köra Tjärkomprimering ofta. Mer information finns i Underhålla databasen.
- Kontrollera
OutOfMemoryError
loggar. Mer information finns i Analysera minnesproblem. - Kontrollera loggarna om det finns referenser till oindexerade frågor, trädgenomgångar eller indexgenomgångar. Dessa indikerar oindexerade frågor eller otillräckligt indexerade frågor. Mer information om hur du optimerar fråga- och indexeringsprestanda finns i Metodtips för frågor och indexering.
- Använd arbetsflödeskonsolen för att verifiera att arbetsflödena fungerar som förväntat. Om det är möjligt kan du komprimera flera arbetsflöden till ett enda arbetsflöde.
- Läs om live-övervakning och leta efter fler flaskhalsar eller konsumenter av specifika resurser.
- Undersök utgångspunkterna från klientnätverket och ingångspunkterna till Experience Manager instansnätverk, inklusive dispatchern. Det är ofta flaskhalsar. Mer information finns i Resurser för nätverksaspekter.
- Ändra storlek på dina Experience Manager server. Du kan ha en otillräckligt stor Experience Manager -instans. Adobe kundsupport kan hjälpa dig att identifiera om din server är för liten.
- Undersök
access.log
ocherror.log
filer för poster runt tiden som något gick fel. Leta efter mönster som kan indikera anpassade kodavvikelser. Lägg till dem i listan med händelser som du övervakar.