Monitoren achtergrondtaken

[Oon]

Hallo,

Ik heb hier een discussietopic van gemaakt omdat ik niet alleen naar een oplossing zoek, maar ook benieuwd ben hoe anderen hier over denken/wat gangbare bestaande tools zijn. Ik wil dit wel aanvliegen vanaf de developmentkant, ik ben dus niet op zoek naar een stukje kant en klare software voor een bepaald OS, maar naar een basis om op te bouwen of een library/framework om op in te haken.

Huidige opzet

Ik heb een opslagserver met een heleboel bestanden van verschillende types, daarna doe ik nog wel eens aan het binnenhalen van grote hoeveelheden informatie; denk aan bijvoorbeeld alle producten van de GraphQL API van de supermarkt.

Om dit te bewerkstelligen heb ik een hele hoop losse scriptjes, die allemaal gebruik maken van een library om progress bars te laten zien (mpb).

Het nadeel is dat ik nu dus altijd een tmux sessie heb draaien die deze taken uitvoert, per taak het scriptje moet draaien, en weer met SSH moet verbinden om te kijken hoe het er mee staat. Soms crasht een proces of treedt er een timeout op die ik niet afgevangen blij te hebben, en hoewel ik wel weer wat code zou kunnen schrijven om dan via notify.run of Discord oid een notificatie te sturen, blijft het allemaal een beetje in elkaar gehackt.

Mogelijke nieuwe opzet

Ik zie voor me een web-UI waar ik op inlog, een sidebar met alle scripts die beschikbaar zijn, dan als je er een aanklikt in de bovenste helft een scherm met de actieve run (indien die er is), hier per taak een voortgangsbalkje, die je kunt uitklappen om de onderliggende taak te zien. De data van iedere run wordt permanent gelogd, en met een druk op de knop kun je van de actieve run ook de al voltooide taken/subtaken zien. Onderin datzelfde scherm zie je een lijst voltooide taken, met per taak ook of ze gelukt zijn en hoe lang ze gedraaid hebben. Klikken op de taak klapt die uit tot dezelfde weergave als de actieve taak, waar je helemaal door kunt klikken naar iedere subtaak om alle details te zien.

Hierbij zou dan een generieke class zijn (een soort van custom thread class) die een (sub)taak uitvoert en informatie terug naar boven stuurt, waarmee iedere taak alleen zijn eigen code hoeft uit te voeren en evt. onderliggende taken hoeft af te wachten.
In de basis zou het al mooi zijn om alleen de weergave hiervoor te hebben, maar het zou helemaal vet zijn als je daarnaast óók een tmux sessie ofzo aftrapt om de processen daadwerkelijk in uit te voeren.

En toen

Nou had ik dit allemaal uitgedacht, en toen bedacht ik me dat dit wel érg lijkt op bijv. Laravel Horizon. Mijn huidige code is in NodeJS en ik ben niet van plan om dat om te gooien naar PHP, maar ik kan me dus ook niet voorstellen dat er geen bestaande optie is.

Dus voor ik ga knutselen met React oid en een hele hoop code ga schrijven ben ik eigenlijk wel benieuwd of er hier mensen zijn die hier ideeën over hebben, of bestaande tools kennen die hierin kunnen voorzien.

In het kort

Welke tools gebruik of ken jij om achtergrondtaken uit te voeren en realtime te monitoren, of welke oplossing heb je hier zelf voor bedacht?
Welke problemen of ideeën schieten te binnen bij het lezen van dit topic?

[Verwijderd]

Monitoren is leuk maar ik ben meer van de meldingen die dan verstuurd worden naar mijn inbox. Oftewel trigger exception, dan log wegschrijven en eventueel een email versturen. Voor git commit/ system update is de output altijd verschillend. Maar ik tokenise bijvoorbeeld de output en aan de hand van die structuur stuur ik alleen meldingen die nog niet verstuurd zijn die dag en reset ik filter snachts als de log files ook verstuurd worden als email. Zo heb ik helaas geen mooie gui maar wel een interessante email met bijlagen.

Puppet wordt geloof ik gebruikt in de dev ops wereld. Ik zou de procestijden wegschrijven naar een log file en die dan mailen. Je kan dan ook een mail template maken die opmerkelijke tijden, bijvoorbeeld alles dat langer dan 1 minuut duurt zet je als html in de template.

Ik hoor dat je het graag zelf wilt doen en zo heb ik in de frontend met react en node gewerkt, maar toen maakten we gebruik van een symfony php backend. Symfony heeft een mooi package die wellicht ook met laravel werkt, genaamd api platform, wellicht wil je dat gaan gebruiken. Waarom node react ipv php. Ik vond php veel simpeler ipv je beperken tot de react way en eigenlijk inefficiente code hebt met een redux state manager bijvoorbeeld.

Ik vond ook de applicatie waarin ik werkte, typescript meer code opleveren dan ik gewent was in mijn eigen framework en dus minder snel was in typescript / react.
Symfony (php) heeft ook meer code maar werkt iets sneller. Laravel ben ik nu een 2 maanden mee bezig, gebruikt onder water volgens mij symfony en werkt lekker vlot en goede documentatie. Voor kleine / middelgrootte applicaties is laravel wel geschikt maar als je een grote complexe applicatie gaat bouwen zou ik kiezen voor symfony of mijn eigen framework die daar geen moeite mee hebben.

[Oon]

Verwijderd schreef op woensdag 14 juni 2023 @ 22:00:
Monitoren is leuk maar ik ben meer van de meldingen die dan verstuurd worden naar mijn inbox. Oftewel trigger exception, dan log wegschrijven en eventueel een email versturen. Voor git commit/ system update is de output altijd verschillend. Maar ik tokenise bijvoorbeeld de output en aan de hand van die structuur stuur ik alleen meldingen die nog niet verstuurd zijn die dag en reset ik filter snachts als de log files ook verstuurd worden als email. Zo heb ik helaas geen mooie gui maar wel een interessante email met bijlagen.

Puppet wordt geloof ik gebruikt in de dev ops wereld. Ik zou de procestijden wegschrijven naar een log file en die dan mailen. Je kan dan ook een mail template maken die opmerkelijke tijden, bijvoorbeeld alles dat langer dan 1 minuut duurt zet je als html in de template.

Ik hoor dat je het graag zelf wilt doen en zo heb ik in de frontend met react en node gewerkt, maar toen maakten we gebruik van een symfony php backend. Symfony heeft een mooi package die wellicht ook met laravel werkt, genaamd api platform, wellicht wil je dat gaan gebruiken. Waarom node react ipv php. Ik vond php veel simpeler ipv je beperken tot de react way en eigenlijk inefficiente code hebt met een redux state manager bijvoorbeeld.

Ik vond ook de applicatie waarin ik werkte, typescript meer code opleveren dan ik gewent was in mijn eigen framework en dus minder snel was in typescript / react.
Symfony (php) heeft ook meer code maar werkt iets sneller. Laravel ben ik nu een 2 maanden mee bezig, gebruikt onder water volgens mij symfony en werkt lekker vlot en goede documentatie. Voor kleine / middelgrootte applicaties is laravel wel geschikt maar als je een grote complexe applicatie gaat bouwen zou ik kiezen voor symfony of mijn eigen framework die daar geen moeite mee hebben.

Ik vind juist de combinatie realtime monitoren en meldingen bij een fout wel fijn. Ik heb nu de sessie altijd open staan en een console bell die wordt getriggered bij een fout, maar die moet ik maar net horen. Misschien dat mail dan inderdaad een goede toevoeging is.

Ik noemde puur React omdat mijn code nu al in Node is, en ik zelf een beetje weg aan het gaan ben van PHP. PHP icm server-sent events zou wat mij betreft ook prima zijn om de interface in te bouwen.
Laravel gebruikt inderdaad veel Symfony packages onder water, en zou in de PHP-wereld mijn voorkeur hebben, juist omdat de interface redelijk simpel is en Laravel dan het grootste deel al afhandelt.

Puppet ziet er goed uit, maar lijkt mij weer een beetje overkill? Het gaat echt alleen om het draaien en monitoren van taken. Ik ben dus ook echt niet op zoek naar een grote betaalde enterprise applicatie.

[Kalentum]

Je bent niet de eerste die start met een verzameling al dan niet automatisch gestarte scripts en dat wordt uiteindelijk altijd een rommeltje. Iets als Laravel Horizon is dan een prima optie.

De boel omschrijven voor dit doel lijkt me onwenselijk dus kijk eens naar bv bullmq die dit voor Node doet. Krijg je ook automatische retries cadeau. Er zijn ook een paar dashboards voor te vinden.

Qua balkjes: die progress is leuk maar ga je dan elke dag zitten kijken hoe ze het doen? In de praktijk wil je eigenlijk alleen maar weten dat iets niet goed gaat. Ik ken geen standaardoplossingen dus dan zul je zelf iets moeten maken.

Edit: https://docs.bullmq.io/guide/workers oh er is iets dat een job progress kan hebben. Nou kijk eens aan. Moet je alleen nog een dashboard hebben die die progress visualiseert.

[ Voor 19% gewijzigd door Kalentum op 15-06-2023 07:55 ]

[DaFeliX]

Zou Jenkins een oplossing voor je kunnen zijn? Wij gebruiken deze om al onze 'cronjobs' te draaien, scripts die op bepaalde tijdstippen moeten draaien; maar je kunt zo ook handmatig starten.

De output wordt standaard getoond, en als iets faalt kun je daar een notificatie van krijgen; via een API of bijv per e-mail. Jenkins zelf maakt progressbars voor scripts die je eventueel kunt volgen

Omdat het een build-tool is, heeft 't ondersteuning voor verschillende version control systemen. Zo zou je een repo automatisch kunnen laten uitchecken op een bepaalde branch en zo "een script vanaf een repo" draaien.

[Oon]

DaFeliX schreef op donderdag 15 juni 2023 @ 11:29:
Zou Jenkins een oplossing voor je kunnen zijn? Wij gebruiken deze om al onze 'cronjobs' te draaien, scripts die op bepaalde tijdstippen moeten draaien; maar je kunt zo ook handmatig starten.

De output wordt standaard getoond, en als iets faalt kun je daar een notificatie van krijgen; via een API of bijv per e-mail. Jenkins zelf maakt progressbars voor scripts die je eventueel kunt volgen

Omdat het een build-tool is, heeft 't ondersteuning voor verschillende version control systemen. Zo zou je een repo automatisch kunnen laten uitchecken op een bepaalde branch en zo "een script vanaf een repo" draaien.

Iets als Jenkins of Drone is inderdaad ook een oplossing, daar had ik nog niet over nagedacht..

Dan zou ik alleen moeten kijken of het ook mogelijk is om daarbij voortgang en ETA inzichtelijk te krijgen per taak en subtaak, want dat is wel een redelijk harde eis. Het gaat om processen die tussen de 20 minuten en een week duren, dus dat detail wil ik niet kwijtraken.

[Merethil]

Oon schreef op donderdag 15 juni 2023 @ 13:07:
[...]

Iets als Jenkins of Drone is inderdaad ook een oplossing, daar had ik nog niet over nagedacht..

Dan zou ik alleen moeten kijken of het ook mogelijk is om daarbij voortgang en ETA inzichtelijk te krijgen per taak en subtaak, want dat is wel een redelijk harde eis. Het gaat om processen die tussen de 20 minuten en een week duren, dus dat detail wil ik niet kwijtraken.

Jenkins laat de voortgang op verschillende manieren zien - een timer die oploopt om aan te geven hoe lang hij al bezig is, en als je je taken in steps verdeelt dan kan hij ook laten zien in welke step hij op dat moment is.
Helaas werkt de ETA op basis van (een gemiddelde van?) de gebruikte tijd per step van alle voorgaande taken waardoor je niet exact kan zien waar hij is, maar het is op zich een prima handvat als je taken niet vaak uitschieters qua doorlooptijd hebben.

[Oon]

Merethil schreef op donderdag 15 juni 2023 @ 13:22:
[...]


Jenkins laat de voortgang op verschillende manieren zien - een timer die oploopt om aan te geven hoe lang hij al bezig is, en als je je taken in steps verdeelt dan kan hij ook laten zien in welke step hij op dat moment is.
Helaas werkt de ETA op basis van (een gemiddelde van?) de gebruikte tijd per step van alle voorgaande taken waardoor je niet exact kan zien waar hij is, maar het is op zich een prima handvat als je taken niet vaak uitschieters qua doorlooptijd hebben.

Precies dat is ook mijn doel, het is niet zo dat ik na 2 dagen wachten voor mijn scherm zit te kijken op de exacte minuut die mijn ETA nu aangeeft Ik pak nu de gemiddelde tijd per item en vermenigvuldig die met het aantal dat er nog over is, maar dat aantal kan ook dynamisch omhoog gaan. In sommige gevallen pak ik daar ook weer een gemiddelde (bijv. gemiddelde aantal posts per gebruiker, ik weet het aantal gebruikers en bereken dan een verwacht totaal aantal posts, en die posts gebruik ik dan voor mijn ETA).

Ik lees nu dat Jenkins ook overweg kan met loops enzo, dus het zou wel haalbaar moeten zijn om daar iets mee te doen.

[Verwijderd]

Ik heb ook nog een opmerking. Per mail is leuk, maar kwam er gister achter bij een import dat hij bij foutieve validatie een event triggered en een mail stuurt per error. Dit resulteerde in 25.000 mails, ik kreeg er al 1000 voordat ik dit door had. Toch blij dat ik een mail queue gebruik en dit niet tot spam heeft geleid. Liever dus een trigger per import ipv per record

[Oon]

Verwijderd schreef op vrijdag 16 juni 2023 @ 12:21:
Ik heb ook nog een opmerking. Per mail is leuk, maar kwam er gister achter bij een import dat hij bij foutieve validatie een event triggered en een mail stuurt per error. Dit resulteerde in 25.000 mails, ik kreeg er al 1000 voordat ik dit door had. Toch blij dat ik een mail queue gebruik en dit niet tot spam heeft geleid. Liever dus een trigger per import ipv per record

Het nadeel daarbij is dan weer dat als het proces uren duurt je pas aan het einde een mailtje krijgt, en dat is ook niet altijd handig.

Daarom heb ik toch graag realtime inzicht in de status en evt. fouten