System för övervakning och aviseringar

Även om de ofta används som synonymer är "observability" ett bredare begrepp än "monitoring".

• Monitoring: Att veta vad ni ska leta efter (fördefinierade mätvärden och dashboards).
• Observability: Att kunna ställa vilken fråga som helst om systemets tillstånd och få svar från dess utdata (loggar, traces, mätvärden).

Ett system med verkligt god observability gör det möjligt att förstå komplexa och okända problem.

Flera typer av verktyg hjälper er att övervaka er SaaS:

• Infrastrukturövervakning: Övervakar servrar, virtuella maskiner och containrar (till exempel Prometheus och Datadog).
• Application Performance Monitoring (APM): Ger en djupgående analys av applikationskod, beroenden och transaktioner (till exempel New Relic och Dynatrace).
• Logghantering: Samlar in och analyserar applikations- och systemloggar (till exempel ELK Stack och Splunk).

Vilka verktyg ni bör välja beror på era specifika behov och er arkitektur.

Hur tar sig övervakningsdata från applikationen till era dashboards?

Vanligtvis körs små programvaruagenter eller "exporters" tillsammans med applikationerna eller på servrarna. Dessa agenter samlar in specifika mätvärden (som CPU-belastning eller antal förfrågningar) och skickar dem till ett centralt övervakningssystem för lagring och analys.

Dessa data samlas ofta in med regelbundna intervall, till exempel var 15:e sekund.

Övervakning visar vad som händer. Alerting meddelar er när något viktigt förändras eller slutar fungera.

En alert är en avisering som utlöses när ett övervakat mätvärde passerar ett fördefinierat tröskelvärde. Om CPU-användningen till exempel överstiger 90 procent i fem minuter kan en alert skickas till teamet.

Alerts är avgörande för proaktiv incidenthantering.

Alla alerts är inte lika bra. Effektiva alerts är:

• Handlingsbara: Anger tydligt vad som är fel och vad som behöver åtgärdas.
• Snabba: Meddelar snabbt, men inte så snabbt att de blir falsklarm.
• Specifika: Pekar ut problemet i stället för att bara beskriva ett vagt fel.
• Prioriterade: Återspeglar problemets allvarlighetsgrad.

Undvik "alert fatigue" genom att minimera brusiga alerts som inte leder till någon åtgärd.

Att ställa in rätt tröskelvärden är avgörande för smart alerting. Om de är för låga får ni för många falska positiva ("alert fatigue"). Om de är för höga kan ni missa kritiska problem.

Ta hänsyn till följande faktorer:

• Baslinjer: Vad är normalt för systemet?
• Trender: Ökar ett mätvärde stadigt, även om det ännu inte har passerat tröskelvärdet?
• Påverkan: Hur påverkar mätvärdet användarupplevelsen eller verksamheten?

Alerts måste nå rätt personer snabbt. Vanliga kanaler för alerts är:

• E-post: För mindre brådskande informationsmeddelanden.
• Slack/Teams: För synlighet inom hela teamet och samarbete.
• Paging-tjänster (till exempel PagerDuty): För kritiska, brådskande incidenter som kräver omedelbara manuella åtgärder.

Eskaleringprinciper säkerställer att alerten går vidare till nästa person i kedjan om någon inte svarar.

I den här lektionen utforskade vi de viktiga rollerna för övervakning och alerting när det gäller att upprätthålla en välfungerande SaaS-applikation.

• Övervakning ger insyn i systemets prestanda och beteende.
• Alerting meddelar er omedelbart när fördefinierade tröskelvärden passeras, vilket kan tyda på problem.
• Effektiva system använder rätt verktyg, genomtänkt insamling av mätvärden och smarta alert-konfigurationer för att säkerställa att teamet proaktivt kan upptäcka och hantera problem, minimera driftstopp och ge användarna en bra upplevelse.