Simpele soort flowchart in HTML

[Chris_147]

Ons systeem bestaat uit heel wat applicaties die berichten naar mekaar doorsturen.
Het is vaak ook een flow van de ene naar de andere:
app1 ontvangt eerst het bericht, dan gaat het naar app2, die verwerkt wat en stuurt door naar app3 en app4, etc.
Bij mijn (automatische) tests heb ik het probleem dat ik heel wat log files moet openen.
Iedere test raakt andere applicaties en moet ik dus andere log files voor openen.

Allemaal niet moeilijk, maar:
- 3 maanden later weet je niet meer direct welke applicaties in welke volgorde betrokken zijn
- de webserver waarop de lijst van log files staat, reageert traag, ik ga dus liever direct naar de juiste log file
- alle log files oplijsten wordt ook onoverzichtelijk
- ik wil dit niet opslaag als browser bookmarks, maar op een manier dat iedereen dit kan zien, liefst vanuit GIT
Kwestie dat de tests zo toegankelijk mogelijk zijn voor personen die ze niet gemaakt hebben, maar wel betrokken zijn.

Mijn idee was dus om een soort HTML pagina (of iets anders) te maken met een soort flowchart per test of groep van tests. Heel simpel, gewoon een blokje met test APP1 en dan een pijl naar andere blok met APP2.
De blokken linken door naar de juist log file.

Ik zoek dus geen uitgebreide flowchart webapplicatie, maar eigenlijk een 1-page HTML file waarin ik gemakkelijk deze blokken kan maken.
Iemand een idee?

[armageddon_2k1]

Is dit niet gewoon iets wat je met draw.io kan doen?

[AapBart]

En misschien gebruik gaan maken van centrale logging vanuit je applicaties? Dan hoef je niet door heel veel logfiles om de status te bekijken, maar met een query.

[Haan]

Ik denk dat je zelfs met Paint nog een heel eind komt ook

[iBasch]

Eens met hierboven, ik zou gaan voor een simpele statische architectuur-plaat, in combinatie met centrale logging. Bijvoorbeeld Elasticsearch, Logstash, Kibana. Applicatienaam meegeven aan de logapplicatie, alle berichten een sessie-id laten delen zodat je hiermee kunt zoeken op de bij elkaar horende berichten in Kibana vanuit alle applicaties.

[killercow]

je kunt dit prima als webapp bouwen. Svg zou hier prima als laag gebruikt kunnen worden voor de weergave van je objecten, en daar zijn allerlei mooie converters voor. Je kunt zo je onderlinge relaties in DOT files opschrijven, en die dan naar svg converteren in een website plaatsen.

[Chris_147]

Hey,
centrale logging is iets wat we al een hele tijd willen hebben, maar groot bedrijf, dus:
- is heel wat werk om op te zetten
- voldoende krachtige servers krijgen om dit op te zetten
- niet alleen op QA, maar ook op PROD omgeving
- ...
Dit is al een item dat gedaan moet worden van voor ik begon (oktober) en is nog steeds gaande. Dus dat gaat het hem voorlopig niet worden.

Goede tip van draw.io, maar als ik het bewaar als een html file:
- heb ik geen link in de file
- inhoud lijkt niet lokaal te staan, maar te verwijzen naar een file op draw.io

Ik had zelf met ASCII flow geprobeerd om dat in mijn .md file te zetten, maar links zijn lastiger in een code block om de ASCII diagrammen te tonen.

SVG webapp: het moet simpel zijn. ik weet niet of dat kan.

Ik wil eigenlijk gewoon een losstaande file (html of md of whatever) die gemakkelijk geopend kan worden zonder poespas

[Kupauw]

Chris_147 schreef op vrijdag 4 juni 2021 @ 09:58:
Hey,
centrale logging is iets wat we al een hele tijd willen hebben, maar groot bedrijf, dus:
- is heel wat werk om op te zetten
- voldoende krachtige servers krijgen om dit op te zetten
- niet alleen op QA, maar ook op PROD omgeving

Over hoeveel logging praten we Mb/Gb/Tb...? Een Elastic stack hoeft niet veel nodig te hebben.

[thaicecube]

Maar voor je simpele html interface kan je toch desnoods zoiets erin zetten?

code:

  <style type="text/css">
    .blocks {
      display: flex;
    }

    .block {
      border: 1px solid black;
    }

    .block::after {
      content: '->';
    }
  </style>
  <div class="blocks">
    <?php
    for ($i = 0; $i <= 4; $i++) {
      ?>
      <div class="block">
        <a href="#log-<?php echo $i; ?>">Log <?php echo $i; ?></a>
      </div>
      <?php
    }
    ?>
  </div>

[Johnny]

Chris_147 schreef op vrijdag 4 juni 2021 @ 09:58:
Hey,
centrale logging is iets wat we al een hele tijd willen hebben, maar groot bedrijf, dus:
- is heel wat werk om op te zetten
- voldoende krachtige servers krijgen om dit op te zetten
- niet alleen op QA, maar ook op PROD omgeving
- ...
Dit is al een item dat gedaan moet worden van voor ik begon (oktober) en is nog steeds gaande. Dus dat gaat het hem voorlopig niet worden.

Dit klinkt meer als een organisatorisch probleem dan een technisch probleem. Als iemand hoog genoeg in de boom hier even prioriteit an geeft kan je dit binnen een week geregeld hebben.

Mijn ervaring met cloud based logging oplossingen is dat nadat een oplossing is gekozen het een kwestie van registreren is en dan binnen een uurtje alles hebt ingeregeld en een testomgeving er aan hebt gekoppeld waarna het al waarde toevoegt. Vervolgens kun je stapsgewijs meer omgevingen toevoegen.

[Chris_147]

Ja jongens, andere logging oplossing gaat er niet snel genoeg komen.
En dan nog moet het duidelijk zijn in welke volgorde de verschillende log files gecontroleerd moeten worden.
Als je dagelijks met die dingen bezig bent, weet je dat nog, maar na een week ben ik dat vergeten.
Nieuwe mensen weten dat ook niet direct.

Even verduidelijken hoe ik het zou gebruiken:
we gebruiken Cucumber om de tests te definiëren. Naast de .feature heb ik ook een .md die verdere uitleg geeft over de test, schermen die geraakt of gesimuleerd worden, tabellen die gebruikt worden etc.
Ofwel in die .md ofwel in een aparte file in dezelfde folder wil ik dit hebben.
Zodat het vanuit Intellij/Eclipse, maar ook vanuit Azure DevOps te bekijken is.

@thaicecube Dat lijkt wel wat op wat ik wil, maar ik zie dat de "->" binnenin de box zit, niet tussen boxes.
En het zou leuk zijn als het algemeen wat mooier was.

[thaicecube]

Chris_147 schreef op vrijdag 4 juni 2021 @ 11:48:
@thaicecube Dat lijkt wel wat op wat ik wil, maar ik zie dat de "->" binnenin de box zit, niet tussen boxes.
En het zou leuk zijn als het algemeen wat mooier was.

Dat is dan weer het mooie van het html, bestand die kan je zo mooi maken als je zelf wilt/kan.
Dit was even een hele rudimentair opzet als voorbeeld.

[Chris_147]

Moet bekennen dat ik een totale noob ben in het mooier maken van HTML..

[Chris_147]

Tja, dit ziet er wel netjes uit in de gegenereerde MarkDown file:

code:

<pre>
┌─────────┐      ┌──────────┐
│         │      │          │
│ <a href="http://xxx.log" target="_blank">AppXXX</a>  ├─────►│  <a href="http://xxx.log" target="_blank">AppYYY</a>  │
│         │      │          │
└─────────┘      └──────────┘
</pre>

maar niet in de .md als tekstbestand bekeken.
Gaat ook wat lastig zijn om te onderhouden vrees ik.

[Creepy]

Kijk anders eens naar PlantUML, dan beschrijf je je diagrammen e.d. met een paar regels tekst. Die wil ik nog wel eens gebruiken om wat documentatie e.d. ook makkelijk in versiebeheer te hebben.

[remyz]

https://www.diagram.codes/ is ook de moeite van het bekijken waard.

[Jboy1991]

Het bedrijf waarbij ik werk gebruikt visio hiervoor en bluedolphin

Visio voor minder grote uitwerkingen (kleine test changes). Bluedolphin voor Definitieve versie

[decipherer]

Je hebt het over automatische testen. En vervolgens over log files die gecontroleerd moeten worden en een volgorde die je moet onthouden. Het klinkt alsof je die met de hand controleert. Dat begrijp ik niet goed, als de testen geautomatiseerd zijn worden de log files ook automatisch gecontroleerd mag ik aannemen? Waarna je ergens op een dashboard de resultaten van je testen in kan zien? Waarbij dat soort integratie testen slechts een klein deel van het totaal aantal testen beslaat, naast de unit testen e.d. die je ook hebt draaien?

[ Voor 4% gewijzigd door decipherer op 06-06-2021 08:56 ]

[Chris_147]

@decipherer : er zijn automatische unit tests per applicatie.
Mijn tests gaan over verschillende applicaties heen.
Controles tijdens de test zijn allemaal automatisch: controles via API's, services of rechtstreeks DB. Soms ook via GUI bij applicaties die veel business logica in de GUI hebben.
Om te controleren of een verwerking klaar is, lees ik automatisch de log files in een Awaitility lus voor ik de verificaties doe.

De vraag hier gaat echter om het analyseren van een gefaalde test. Redenen dat de test gefaald kan zijn, zijn uitgebreid en die ga ik echt niet allemaal in mijn automatische test opnemen. Dat maakt de test nodeloos ingewikkeld om te lezen en moeilijker om op te stellen en te onderhouden.
Zie mijn vraag meer als interactieve documentatie: dit is de volgorde van verwerking van een bericht en hier heb je ook ineens de link naar de relevante log files. Alle applicaties hangen aan mekaar via berichten, geen 'fancy' stuff zoals API's of services. Onze stack stamt nog rechtstreeks af van mainframes.Men begint API's in te voeren, maar +30 jaar functionaliteit herschrijf je niet in 1-2-3 terwijl productie moet blijven draaien en uitgebreid worden.

Aan de anderen: bedankt voor de links, veel interessante programma's. Maar ik zoek liefst iets wat standaard markdown is, of HTML. Extra programma's gaan niet aanslaan vrees ik.

[xobdorp]

Kupauw schreef op vrijdag 4 juni 2021 @ 10:03:
[...]


Over hoeveel logging praten we Mb/Gb/Tb...? Een Elastic stack hoeft niet veel nodig te hebben.

Ter illustratie, wij gebruiken voor een klein landschap twee ES nodes op ieder 2GB geheugen (uit mijn hoofd, 6GB in totaal met een Kibana en een Logstash erbij), loggen ongeveer 25GB per dag en ruimen logging na een week op. Dus qua resources en opslag valt de investering reuze mee en ik denk dat deze 'nadelen' al gauw opwegen tegen de voordelen die je eruit haalt mbt nieuwe inzichten en continue monitoring.

[Chris_147]

Ok, uiteindelijk gebaseerd op dit (https://codepen.io/gmkhussain/pen/jqgRGV) iets kunnen maken.

code:

 <!DOCTYPE html>
<html>
  <head>
    <title>Page Title</title>
    <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css">
  </head>
  <body>
    <div class="container">
      <h2 class="page-header">Logging order tracing</h2>
        <div>
          <span class="btn btn-warning btn-lg">
            <a href="url" target="_blank">LogAAA</a></span>
          <span class="glyphicon glyphicon-arrow-right"></span>
          <span class="btn btn-warning btn-lg">
            <a href="url" target="_blank">LogBBB</a></span>
          <span class="glyphicon glyphicon-arrow-right"></span>
          <span class="btn btn-warning btn-lg">
            <a href="url" target="_blank">LogCCC</a></span>
          <span class="glyphicon glyphicon-arrow-right"></span>
          <span class="btn btn-warning btn-lg">
            <a href="url" target="_blank">LogDDD</a></span>
        </div>     
    </div>
  </body>
</html>

is redelijk leesbaar als HTML (SVG maakt de HTML veel te ingewikkeld) en ook netjes in de browser.

Het werkt zelfs ook netjes in de markdown in Intellij.
Azure DevOps toont de knoppen natuurlijk niet netjes in de preview, maar gelukkig werken de links wel.

[ Voor 6% gewijzigd door Chris_147 op 07-06-2021 10:32 ]