Kmom04: Monitoring

Nu när vi har ett system uppe och rullande behöver vi veta när något går fel, vi ska övervaka hela produktionsmiljön och alla dess delar.

#Läsanvisningar

Läsanvisningar hittar ni på sidan bokcirkel.

Kolla i lektionsplanen för att se när vi träffas för bokcirkeln.

#Monitoring

När system ligger utspridda på virtuelle servrar jorden runt är det inte lätt att hålla koll på att alla servrar och system hela tiden är igång. Här kommer infrastruktur monitoring in i bilden men vi kan också ha application monitoring där vi övervakar metrics från system. T.ex. hur många request varje server har fått eller hur många 404 requests.

#Läs och titta

• Microsofts förklaring av Monitoring.

• Monitoring in a DevOps world.

#Log management

Log management är processen av att samla in, lagra, hantera och analysera loggar från infrastruktur, system och applikation. Det är ett väldigt brett ämne då typ allt genererar loggar av något slag och system för att sköta log hantering är väldigt avancerade. För att få en överblick av delarna som ingår i log management och vilken användning olika roller har av log management läs följande:

#Läs och titta

• What is log management.

• Why is log management important.

• en snabb överblick av ELK stack för en överblick av ett av de mest populära systemen för Log management.

#Application performance monitoring (APM)

APM kan även kallas Application Performance Management (också APM), enligt vissa är det skillnad. APM är att övervaka, hantera och diagnosera prestanda, tillgänglighet och användare upplevelse av applikationer. Avancerade program används för att göra om data till “business value”.

#Läs och titta

• What is application performace monitoring.

#Observability

På senare år har det även börjat talas mycket om Observability vilket hänger ihop med monitoring. Vi kan se monitoring som att ha kolla på hälsan av våra system medan observability är att ha djup insikt i hur våra system beter sig. Observability ska hjälpa oss hitta fel och problem.

#Läs och titta

• Observability sv. Monitoring.

• Om ni vill kan ni även kolla på What Does the Future Hold for Observability?.

#Prometheus och Grafana

Vi ska använda oss av Prometheus, ett väldigt populärt verktyg för att lagra tidsserie data och visualisera data. Prometheus har inbyggt stöd för att visa simpla grafer för data men oftast använder man det tillsammans med externa visualiseringsverktyg. Vi ska använda Grafana för att bygga dashboards med grafer och diagram över datan från Prometheus.

#Läs och titta

• Läs Prometheus Monitoring: The Definitive Guide in 2019 för en överblick av vad Prometheus är och vad det innehåller.
• Alertmanager
• Alerting Best practice
• Operatorer i Prometheus

#Att göra

Ni behöver inte skriva konfigurationen för Prometheus, Alertmanager och Grafana själva. Den finns färdig i mappen monitoring/ i Microblog-repot. Er uppgift är att köra den, läsa den och förstå vad varje del gör.

• Kolla på videorna 401-403 och 410-413 i spellistan kursen devops för att se hur de olika delarna hänger ihop. Videorna visar äldre versioner och sätter upp allt för hand, så följ inte kommandona exakt, det ni ska köra står nedan.

Hela övervakningen körs lokalt på er dator, inte på en VM. Den startas genom att lägga till filen monitoring/docker-compose.yml till er egen docker-compose.yml (den kräver att er tjänst för appen heter prod):

docker compose -f docker-compose.yml -f monitoring/docker-compose.yml up -d --build prod prometheus alertmanager grafana

Appen måste själv exponera sina mätvärden. Det gör ni med prometheus-flask-exporter (se Uppgift 1 nedan). Den räknar bland annat alla requests per statuskod i flask_http_request_total.

#Uppgifter

Del 1.

1. Få appen att exponera mätvärden på /metrics med hjälp av prometheus-flask-exporter. Appen använder en application factory, så leta efter det som passar den i dokumentationen. Pinna versionen. Bygg om imagen och kontrollera att /metrics svarar.

2. Starta övervakningen med kommandot ovan. Öppna Prometheus, gå till Status → Targets och kontrollera att microblog är UP. Öppna Grafana och kontrollera att datakällan Prometheus fungerar (menyn Data sources).

3. Läs monitoring/prometheus.yml, monitoring/rules.yml och monitoring/alertmanager.yml samt de nya tjänsterna i docker-compose.yml. Ni ska kunna förklara vad varje del gör i er redovisning.

4. Skapa en egen unik adress på https://webhook.site och lägg in den i monitoring/alertmanager.yml. Starta om Alertmanager (docker compose restart alertmanager).

Del 2.

1. Ta hjälp av AI för att skapa en monitoring strategi för Microblog. Fel som uppstår i appen ska fångas och visualiseras i Grafana. När ett fel uppstår ska ett larm skickas till webhook.site. Basen finns redan (exportören och reglerna i rules.yml), AI:n ska hjälpa er avgöra vad mer som är värt att övervaka och hur ni visar det.

2. Implementera en ny feature i Microblog som genererar ett fel, till exempel en route som kastar ett undantag.

3. Skapa en dashboard i Grafana med minst en panel som visar felen.

4. Trigga felet och ta tre skärmdumpar: felet i appen, samma fel i en panel i Grafana, och larmet när det kommer in på webhook.site. Alla tre skärmdumparna måste visa klockslag och datum så att vi kan se att händelserna hör ihop.

Allt körs lokalt, ni behöver inte öppna några portar eller starta några VM:ar i Azure för den här uppgiften.

#Extrauppgift

Om ni får tid över, testa log management verktyget Loki. Försök få loggar från microbloggen till Grafana med hjälp av Loki.

#Resultat & Redovisning

Se till att följande frågor besvaras i texten:

1. Beskriv vad som menas med Monitoring, olika saker som brukar övervakas och vad det används till.

2. Beskriv Log management och vad det används till.

3. Beskriv APM och vad det används till.

4. Beskriv Observability och försök koppla det till ovanstående frågor.

5. Testade ni Loki? Fick ni ihop det, i så fall tror du att man hade hunnit med det i kursmomentet?

6. Skicka med den korta texten om hur AI hjälpte er med monitoring strategin: vad AI:n föreslog och vad ni ändrade.

7. Skicka med de tre skärmdumparna (felet i appen, felet i Grafana, larmet på webhook.site). Alla ska visa klockslag och datum.

8. Förklara kort vad prometheus.yml, rules.yml och alertmanager.yml gör.

9. Hur var storleken på kursmomentet?

#Revision history