Update content/devops-blog/nextcloud-incident.da.md

content/devops-blog/nextcloud-incident.da.md

@@ -1,63 +1,72 @@
 ---
-title: Performance problemer grundet bug i Nextcloud
+title: Performance-problemer grundet bug i Nextcloud 🐞 🔍
-summary: En fejl i synkronisering af Nextcloud servere resulterede i dårlig performance af data.coops server.
+summary: En fejl i synkronisering af Nextcloud-servere resulterede i dårlig ydeevne på data.coops server.
 date: 2025-02-22
 params:
   author: Reynir (admin team)
 ---
 
-**Den korte version:** der er tilsyneladende en bug i synkronisering mellem Nextcloud-servere samt i log vieweren i admin-panelet. Medlemmer bør derfor indtil videre ikke sætte synkronisering op mellem cloud.data.coop og andre Nextcloud servere uden nærmere aftale med administratorholdet.
+**Den korte version:** der er tilsyneladende en bug i synkronisering mellem Nextcloud-servere samt i log vieweren i Nexclouds adminpanel. Medlemmer bør derfor indtil videre ikke sætte synkronisering op mellem cloud.data.coop og andre Nextcloud-servere uden nærmere aftale med administratorholdet.
 
-I mindst en måned har data.coop haft udfordringer på performance og disk plads.
+I mindst en måned har data.coop haft udfordringer med CPU, hukommelse og disk plads.
 Det har vi i [admin-teamet](/rights/#-7-administratorer) haft kig på når vi har kunne finde tid.
 Vi fandt nogle årsager:
 
 - [Mastodon remote profilbilleder, der aldrig bliver ryddet op i](https://git.data.coop/data.coop/ansible/pulls/228)
-- [bots der scraper dyre forgejo endpoints,](https://git.data.coop/data.coop/ansible/pulls/233)
+- [bots scraper dyre forgejo endpoints,](https://git.data.coop/data.coop/ansible/pulls/233)
-- [nginx-proxy logs der aldrig bliver roteret eller ryddet op i,](https://git.data.coop/data.coop/ansible/pulls/234)
+- [nginx-proxy logs blev aldrig roteret eller ryddet op i,](https://git.data.coop/data.coop/ansible/pulls/234)
-- [Synapse (matrix server) database der vokser sig gevaldigt stor,](https://element-hq.github.io/synapse/latest/usage/administration/state_groups.html)
+- [Synapse (matrix server) database vokser sig gevaldigt stor](https://element-hq.github.io/synapse/latest/usage/administration/state_groups.html)
-- og Nextcloud bruger meget CPU tid i cron.php.
+- og Nextcloud bruger for meget CPU-tid i cron.php.
 
-Problemet med Synapse har er endnu uløst. Der findes et værktøj til at komprimere den problematiske tabel, men vi har endnu ikke undersøgt om det virker for os.
+Problemet med Synapse er endnu uløst. Der findes et værktøj til at komprimere den problematiske tabel, men vi har endnu ikke undersøgt, om det virker for os.
 Vi står over for at migrere vores services over til vores anden server, der har langt større diskkapacitet.
 
 Denne artikel kommer dog til at handle om problemet i Nextcloud:
-hvordan vi identificerede det og hvad vi gjorde for at løse det.
+Hvordan vi identificerede det og hvad vi gjorde for at løse det.
 
 ## Nextcloud
 
-På [cloud.data.coop](https://cloud.data.coop/) kører vi en filsynkroniserings- og delingssoftware Nextcloud til vores medlemmer.
+På [cloud.data.coop](https://cloud.data.coop/) kører vi en filsynkroniserings- og delingssoftware [Nextcloud]({{ ref "/services/nextcloud" }}) til vores medlemmer.
-Det er et stykke software der kan utroligt meget[^for-meget] udover at gemme og synkronisere filer.
+Det er et stykke software, der kan utroligt meget[^for-meget] udover at gemme og synkronisere filer.
 Det er en service vi har kørt længe.
+
 Indtil for nylig har det kørt relativt godt.
+
 Men så begyndte vi at se en process `php -f /var/www/nextcloud/cron.php` bruge meget CPU-tid.
 Navnet `cron.php` leder tankerne hen på UNIX-programmet `cron` som er et program til at planlægge og køre programmer på faste tidspunkter.
 Det bliver typisk brugt til eks. at køre oprydningsjobs om natten.
 Ved at køre `lsof -p $pid_for_cron.php` kunne jeg få indsigt i hvilke filer processen har åben.
 Der bed jeg mærke i `nextcloud.log`.
 
-Da jeg begyndte at undersøge det nærmere kiggede jeg i admin-interfacet i Nextcloud.
+Da jeg begyndte at undersøge det nærmere, kiggede jeg i admin-interfacet i Nextcloud.
-Det er ikke et stykke software jeg personligt har meget erfaring med at køre, så jeg måtte kigge rundt og opdage hvad der var muligt at lære om hvad `cron.php` har gang i.
+Det er ikke et stykke software, jeg personligt har meget erfaring med at køre, så jeg måtte kigge rundt og opdage, hvad der var muligt at lære om `cron.php`.
-Jeg fandt desværre ikke meget andet en generel information om systemet og en side med logs som ikke virkede.
+Jeg fandt desværre ikke meget andet en generel information om systemet og en side med logs (som ikke virkede!).
 
 ![Screenshot der viser information og tal om systemet, eks. grafer for CPU-belastning og hukommelsesforbrug.](/static/img/devops-blog/nextcloud-screenshot.png)
 
 Log-siden gav en fejlbesked.
-Noget i retning af at det gik for langsomt at få fat i logs.
+Noget i retning af, at det gik for langsomt at få fat i logs.
+
 Det fik mig til at lede efter logfilerne via ssh.
 Logfilerne viste sig at være flere GB store, og programmer som `less` havde svært ved at håndtere at læse og vise de store filer.
-Nextcloud skriver [json][json]-objekter i sine logs, og det viste sig at flere af linjerne var over 100 MB store.
+Nextcloud skriver [json][json]-objekter i sine logs, og det viste sig, at flere af linjerne var over 100 MB store ‼️.
-Altimens oplevede jeg at serveren blev langsommere og langsommere, og der kom flere og flere apache processer fra Nextcloud-containeren som brugte 100% CPU-tid (dvs. en hel CPU-kerne).
+Altimens oplevede jeg at serveren blev langsommere og langsommere, og der kom flere og flere apache processer fra Nextcloud-containeren som brugte 100% CPU-tid (dvs. en hel CPU-kerne ‼️).
+
 Det blev nødvendigt at lukke Nextcloud ned, så vores andre services kunne køre videre.
 Jeg åbnede et maintenance window i [status.data.coop](https://status.data.coop/) og meldte ud på vores Matrix-kanal.
 
 Ved hjælp af [`jq`][jq] kunne jeg få *pretty printet* logfilen så linjerne ikke blev så lange, og `less` kunne følge med.
 Det viste sig at `cron.php` kørte synkronisering mod et medlems egen Nextcloud-server.
-Det i sig selv er fint, men der var tilsyneladende en bug som gjorde at når vores Nextcloud skannede medlemets Nextcloud for filer i en bestemt mappe blev der sat en ekstra skråstreg på og scannet rekursivt igen.
+
-Sådan blev det ved indtil der var næsten 9000 skråstreger(!!), hvor programmet så kunne finde en videofil (lad os kalde den `foo.mkv`).
+Det er der ingenting galt med; men der var tilsyneladende en bug som gjorde, at når vores Nextcloud scannede medlemmets Nextcloud for filer i en bestemt mappe, så blev der sat en ekstra skråstreg på og scannet rekursivt igen.
+
+Sådan blev det ved, indtil der var næsten 9000 skråstreger ‼️, hvor programmet så kunne finde en videofil (lad os kalde den `foo.mkv`).
 Så var programmet glad, og prøvede at tilføje metadata om filen til databasen.
+
 Her blev databasen så utilfreds!
+
 For i tabellen må filnavne højest være 4000 tegn langt!
+
 Det resulterede i en fejl (exception) som blev logget inklusive de næsten 9000 rekursive kald inklusive argumenter!
 Det var altså årsagen til den problematiske logfil.
 
@@ -197,32 +206,36 @@ Det skaber selvfølgelig problemer at vise så lange linjer i en web browser, s
 
 </details>
 
-I logfilen stod der et brugernavn på medlemmet som gjorde at vi kunne komme i kontakt med vedkommende.
+I logfilen stod der et brugernavn på medlemmet, som gjorde at vi kunne komme i kontakt med vedkommende.
 Medlemmet slog så synkronisering fra på sin Nextcloud-server, og vi kunne starte vores service op dagen efter uden problemer.
 
 ### Den egentlige performance-killer
 
-Det blev først _*rigtigt*_ et problem med performance efter jeg begyndte at undersøge hvad Nextcloud havde gange i.
+Det blev først _*rigtigt*_ et problem med performance, efter jeg begyndte at undersøge hvad Nextcloud havde gange i.
-Min teori er at Nextcloud forsøgte at læse den enormt store logfil og præsentere den for min browser.
+Min teori er, at Nextcloud forsøgte at læse den enormt store logfil og præsentere den for min browser.
 Det tager selvsagt lidt tid at læse så store filer, og min browser har tænkt at det tog for lang tid.
 Der hvor jeg tror det gik galt er at min browser måske forsøgte dernæst at få nextcloud til at læse logfilen igen!
 Og så videre.
 Resulterende i efterhånden mange processer der forsøgte at læse og forstå de gigantiske logfiler.
 
-Ideelt set bør vi undersøge problemet nærmere, evt. prøve at reproducere og skrive en god bug report til Nextcloud.
+Ideelt set bør vi undersøge problemet nærmere, evt. prøve at reproducere og skrive en god bug-report til Nextcloud.
 Desværre er Nextcloud-kodebasen meget stor, med rigtig mange plugins, og det hele er skrevet i et sprog jeg ikke har erfaring med (PHP).
-Derfor bliver det ikke til andet end at vi prøver at opgradere Nextcloud og håber det er et kendt problem de har løst.
+Derfor bliver det ikke til andet, end at vi prøver at opgradere Nextcloud og håber det er et kendt problem de har løst.
 
-## Afsluttende noter
+## Afsluttende eftertanker
 
 Som administratorer hviler der et stort ansvar på os.
-Vi sørger efter bedste evne, og den tid vi har til det frivillige arbejde, at sørge for at data.coops services fungerer i et acceptabelt niveau.
+
+Vi forsøger efter bedste evne (f.eks. den tid vi har til det frivillige arbejde) at sørge for, at data.coops services fungerer på et acceptabelt niveau.
+
 Til det har vi nogle gange brug for at kigge i logs og undersøge systemet.
-Det kan nogle gange gå lidt på tværs med vores mål om privatlivsbeskyttelse og zero-knowledge.
+
+Det kan nogle gange gå lidt på tværs med vores mål om privatlivsbeskyttelse og zero-knowledge 🤔
 
 I denne omgang har jeg lært et medlems mappenavn og filnavn på en af deres filer via logfilerne.
 I forsøg på at lokalisere problemet har jeg kigget i mine **egne** Nextcloud filer i filsystemet og derefter søgt filsystemet for den problematiske fil (uden held).
-Det er noget vi for så vidt muligt prøver at minimere.
+
+Det er noget, vi for så vidt muligt prøver at minimere; men det er også noget, vi skal diskutere løbende og aftale faste rammer omkring.
 
 [json]: https://www.json.org/json-en.html