Monitoraggio sintetico con Robotmk

Diversi componenti lavorano insieme per creare questo end-to-end monitoring, quindi ecco una breve panoramica.

Puoi trovare il Robotmk scheduler all'indirizzo Setup > Agent rules > Robotmk scheduler (Windows). Dato che la regola è piuttosto estesa, ecco una panoramica della configurazione vuota:

Innanzitutto, lo scheduler richiede la directory di base in cui si trovano tutte le tue test suite. Inserisci questo percorso file arbitrario ed esplicito in Base directory of suites, ad esempio C:\robots.

Le Parallel plan groups che vengono mostrate ora sono un concetto specifico di Checkmk.

Per spiegarlo, dobbiamo prima scendere di un livello nella gerarchia: qui puoi vedere l'elemento Sequential plans. Un piano sequenziale di questo tipo definisce quali suite devono essere eseguite con quali parametri. Robot Framework elaborerà queste test suite una dopo l’altra. Il motivo è semplice: in pratica, i test vengono talvolta eseguiti sul desktop e diverse test suite potrebbero interferire tra loro contemporaneamente (pensa al fatto che potrebbero rubarsi a vicenda il controllo del cursore del mouse).

I gruppi di piani sono ora un'incapsulazione per piani eseguiti in sequenza — e vengono essi stessi eseguiti in parallelo. Anche in questo caso, il ragionamento è semplice: ciò consente alle test suite che non si basano sul desktop di essere eseguite nei propri piani senza ritardi — la test suite utilizzata in questo articolo è un buon esempio di tale elaborazione.

Torniamo al dialogo: l'unica impostazione esplicita è l'intervallo di esecuzione, che si imposta in "Group execution interval".

Ora è il momento di configurare il primo piano. Puoi inserire qualsiasi nome in Application name. Questo nome non deve essere unico! Qui ha senso inserire il nome dell'applicazione per il monitoraggio, ad esempio OnlineShop, oppure, in questo esempio, semplicemente MyApplication. Naturalmente, può capitare che questo negozio online venga testato più volte, sia da altre test suite che dalla stessa test suite con parametri diversi. In questi casi, il campo "Variant" viene utilizzato per ottenere risultati univoci nonostante i nomi identici. Ad esempio, se l'applicazione OnlineShop viene testata una volta in tedesco e una volta in inglese (tramite i parametri corrispondenti), potresti utilizzare qui le abbreviazioni corrispondenti. Il monitoraggio restituirà quindi risultati per My OnlineShop_en e My OnlineShop_de.

Tuttavia, è necessaria la specifica in Relative path to test suite file or folder. Il percorso è relativo alla directory di base specificata sopra, ad esempio mybot\test.robot per C:\robots\. In alternativa, qui è possibile specificare anche una directory (con diversi file robot), nel qual caso sarebbe semplicemente mybot.

Continua con l'Execution configuration. In Limit per attempt definisci il tempo massimo trascorso — per tentativo — che una test suite può durare. Con Robot Framework re-executions puoi ora indicare a Robot Framework di ripetere le test suites completamente o in modo incrementale se i test falliscono. Se i singoli test in una test suite sono indipendenti l'uno dall'altro, la strategia incrementale è il modo migliore per risparmiare tempo. Se, d'altra parte, la test suite verifica una sequenza logica, come "Login > Apri pagina del prodotto > Prodotto nel carrello > Checkout", la test suite deve ovviamente essere rielaborata completamente. Alla fine, c'è sempre un solo risultato.

Nel caso di ripetizioni complete, per il risultato finale vengono presi in considerazione solo i risultati delle suite autonome: se un test fallisce al suo ultimo tentativo, la test suite viene considerata un fallimento. Nel caso di ripetizioni incrementali, il risultato finale è costituito dai migliori risultati parziali: se alcuni test vengono eseguiti con successo solo al terzo tentativo, anche il risultato finale viene considerato un successo. Promemoria: la combinazione dei tentativi e dei tempi massimi di esecuzione di tutti i piani in un gruppo di piani determina il loro intervallo minimo di esecuzione.

Per impostazione predefinita, l'esecuzione tramite RCC è attivata in Automated environment setup (via RCC), per cui devi inserire due valori. In primo luogo, RCC richiede la specificazione della posizione del file robot.yaml. Il suo scopo principale è fare riferimento al file conda.yaml, che si occupa di configurare l'ambiente Python, ovvero effettuare l'installazione di Python e delle dipendenze. Questa specificazione è relativa alla directory di base che hai impostato sopra in Relative path to test suite file or folder. I file YAML possono essere salvati in sottodirectory, ma la pratica migliore è la directory principale della suite. Per la directory di base sopra indicata C:\robot\ e la directory della suite C:\robot\mybot, il percorso è quindi mybot\robot.yaml.

Con il seguente limite di tempo per la creazione dell'ambiente Python, tieni presente che a volte è necessario effettuare lo scaricamento e la configurazione di grandi volumi di dati. Soprattutto per i browser richiesti, si accumulano rapidamente diverse centinaia di megabyte, ma solo al primo avvio. RCC ricostruisce gli ambienti solo se il contenuto di conda.yaml è cambiato.

In Robot Framework parameters hai la possibilità di utilizzare alcuni dei parametri della riga di comando di Robot Framework (che vengono visualizzati anche dal comando robot --help). Se desideri utilizzare parametri aggiuntivi, l'opzione Argument files ti sarà d'aiuto. Un file specificato qui può contenere qualsiasi parametro del robot. Ulteriori informazioni sui singoli parametri sono disponibili nell'aiuto in linea.

Per il nostro progetto di esempio, è attivata solo l'opzione Variables ed è impostata una variabile MYVAR con il valore My Value. Ricordi il comando Log ${MYVAR} all'inizio del file tests.robot? Questo è il riferimento corrispondente.

L'opzione Secret environment variables merita un'attenzione particolare poiché non è una funzione originale di Robot Framework. Qui puoi impostare variabili d'ambiente segrete, destinate alle password in combinazione con la libreria CryptoLibrary di Robot Framework. Le variabili impostate qui non compaiono nei log, ma vengono scritte in chiaro nei file di configurazione di Checkmk sui rispettivi host di test.

Alla fine della configurazione della suite ci sono tre opzioni che si spiegano da sole.

Execute plan as a specific user Consente l'esecuzione di Robotmk nel contesto di un account utente specifico. Contesto: per impostazione predefinita, Robotmk viene eseguito nel contesto dell'agente Checkmk (account LocalSystem), che non dispone dell'autorizzazione per accedere al desktop. Qui è possibile specificare un utente che deve essere permanentemente connesso a una sessione desktop e che ha quindi accesso alle applicazioni grafiche del desktop.

Tuttavia, non essere troppo frettoloso: i browser web sono un'eccezione in questo caso! Possono eseguire e visualizzare pagine web in modalità headless. Dovresti checkare la box per un utente specifico solo se un'applicazione desktop dedicata viene avviata al di fuori dei browser web, non da ultimo per motivi di sicurezza.

Con Assign plan/test result to piggyback host i risultati del piano/test possono essere assegnati a un altro host. Ad esempio, se Robot Framework sta testando il processo di ordinazione di un negozio online, i risultati possono essere assegnati al server web corrispondente.

Ogni esecuzione del test produce dati che vengono memorizzati in C:\ProgramData\checkmk\agent\robotmk_output\working\suites\. Per impostazione predefinita, vengono conservati i risultati degli ultimi 14 giorni, ma tieni presente che qui possono accumularsi rapidamente grandi volumi di dati. Per ogni esecuzione vengono generati almeno 500 kilobyte di dati; con test suite più complesse e screenshot incorporati, ad esempio, questo può arrivare rapidamente a diversi megabyte di dati. A seconda dell'intervallo di esecuzione, delle dimensioni del rapporto e delle tue esigenze di documentazione, dovresti intervenire in una situazione del genere.

Una volta qui, puoi ora creare ulteriori piani in questo gruppo di piani o ulteriori gruppi di piani.

Alla fine ci sono altre due opzioni, che a loro volta riguardano la configurazione completa del Robotmk scheduler.

RCC profile configuration ti permette di specificare i server proxy e gli host da escludere.

Grace period before scheduler starts può essere molto utile: lo scheduler si avvia insieme all’agente Checkmk prima dell’accesso al desktop — il che, ovviamente, significa che qualsiasi test sul desktop è destinato a fallire. L’avvio può essere ritardato manualmente utilizzando un periodo di tolleranza.

Questo completa la configurazione e puoi creare un nuovo agente con il plug-in dell'agente, per poi distribuirlo, manualmente o tramite gli aggiornamenti automatici degli agenti.

Nel monitoraggio troverai servizi relativi allo stato del Robotmk scheduler, nonché ai singoli piani e test, anche se non hai creato regole di servizio separate.

In linea di principio, potresti semplicemente archiviare l'intera directory del robot con i file standard (robot.yaml, conda.yaml, test.robot).

Tuttavia, tali test sono spesso gestiti tramite Git e di conseguenza ci sono regolarmente file che non dovrebbero essere distribuiti — questi sono tipicamente gestiti tramite un file gitignore. Per aiutarti a garantire archivi puliti, ecco due piccoli script per Windows e Linux che creano archivi senza i file da ignorare. Usa questi script solo come aiuto e verifica sempre in anticipo la funzionalità per il tuo sistema.

Per questa variante, non è necessario apportare alcuna modifica ai test stessi. Basta aprire la regola "Robotmk KPI discovery" e inserire le keyword da utilizzare per il monitoraggio come espressioni regolari o nomi molto specifici.

Attenzione: se l'espressione regolare corrisponde a più di una keyword nello stesso test, verrà riconosciuta solo una keyword e il suo stato di servizio sarà SCONOSCIUTO (perché Checkmk non sa quale corrispondenza sia effettivamente prevista).

Per una ricerca tramite marker, devi eseguire i seguenti passaggi:

Per l'installazione, il file conda.yaml di cui sopra deve essere esteso con robotframework-robotmklibrary. Le modifiche rispetto alla suite di cui sopra sono evidenziate in giallo:

La test suite tests.robot deve essere estesa dalla libreria (nell'area Settings) e da un marcatore. I KPI spesso fanno riferimento a parole chiave specifiche dell'utente, quindi qui viene aggiunta la parola chiave Foobar (che chiama solo la parola chiave standard Log ed è a sua volta chiamata dal caso di test My Test).

La parola chiave Robotmk Monitor Subsequent Keyword Runtime è il marcatore per (far attivare a Checkmk il monitoraggio della) seguente parola chiave (Foobar); più precisamente, il suo tempo di esecuzione. L'argomento opzionale discover_as può essere usato per specificare un nome individuale per il servizio nel monitoraggio — la parola chiave Foobar appare quindi nel monitoraggio come un servizio chiamato My user keyword.

Il grande vantaggio qui rispetto alla ricerca basata su pattern è che la stessa keyword può anche essere sottoposta a monitoraggio esplicito più volte all’interno di un singolo test.

Ecco l'esempio di cui sopra, esteso con due chiamate a Foobar:

Le tre chiamate alla keyword Foobar apparirebbero quindi nel monitoraggio come My user keyword, Foobar_2 e Foobar_3.

Indipendentemente da quale delle due varianti delle parole chiave venga utilizzata per il monitoraggio, il passo successivo è sempre quello di configurare la valutazione: In quale tempo di esecuzione i servizi devono essere indirizzati a WARN o CRIT? Per farlo, definisci i livelli corrispondenti nella regola Robotmk KPI monitoring.

Le parole chiave dei servizi compaiono nel monitoraggio secondo uno di questi due modelli:

La differenza sta quindi solo nell'indicazione dell'origine tra parentesi subito prima della keyword.

Come mostrato nella schermata sopra con due servizi di keyword Foobar, la suite doveva essere leggermente estesa:

Le due keyword Foobar e Barfoo compaiono entrambe con il nome Foobar nel monitoraggio, ma si distinguono grazie all'indicazione dell'origine tra parentesi.

L'esempio con due keyword diverse presenti nell'elenco sotto lo stesso nome serve principalmente a chiarire le informazioni sull'origine.

Come già menzionato sopra, lo scopo effettivo di discover_as è quello di poter richiamare una keyword più volte in un test, ma di denominare ogni occorrenza individualmente.

La pratica è molto più semplice del contesto tecnico, specialmente quando si lavora con un catalogo come archivio ZIP (o archivio tar.gz su Linux). In sostanza, basta creare il catalogo specificando la variabile ROBOCORP_HOME, esportarlo come archivio e poi distribuirlo manualmente. Di seguito trovi il percorso in dettaglio. I percorsi negli esempi seguenti sono limitati a Windows: solo se Linux richiede comandi diversi, questi saranno specificati esplicitamente.

Prima di tutto: RCCRemote non è uno strumento autonomo, non troverai alcuna documentazione né tantomeno una pagina del prodotto su Robocorp/Sema4. Il server remoto è semplicemente una parte di RCC e viene creato quando RCC viene compilato. Il server viene solitamente gestito tramite un container. Per il funzionamento in container, ora c'è un progetto sulle pagine GitHub di Elabit, lo sviluppatore del plug-in Robotmk originale, chiamato RCCRemote-Docker. Tuttavia, RCCRemote e RCCRemote-Docker non fanno parte di Checkmk Synthetic Monitoring e non sono coperti dal supporto Checkmk!

I cataloghi per questo percorso di distribuzione possono essere creati in due modi: I cataloghi esportati come file ZIP (vedi sopra) possono essere utilizzati sia per Windows che per Linux. Solo per Linux, è anche possibile creare i cataloghi direttamente nel Docker container RCCRemote, il che elimina completamente la necessità di un intervento manuale.

Puoi scoprire come configurare RCCRemote-Docker, handle i certificati e importare i cataloghi nelle pagine del progetto.

La configurazione sul lato Checkmk è ora di nuovo — in genere — piuttosto semplice: l'opzione "Environment dependency handling" questa volta è impostata su "Fetch from RCC remote server" e deve essere fornita con l'indirizzo del server.

Manca ancora un'ultima impostazione, a seconda che il tuo server RCCRemote utilizzi un certificato self-signed o firmato da una CA. In entrambi i casi, di solito devi impostare l'opzione Robotmk scheduler (Windows|Linux) da RCC profile configuration a Custom profile.

Per un certificato self-signed, è sufficiente lasciare deselezionata la box "Validate TLS certificates":

Se invece si tratta di un certificato firmato da una CA, questa opzione deve essere attivata e il certificato dell'autorità di firma deve essere salvato in Root CA (in formato PEM):

Se lo scheduler non riceve alcun dato, probabilmente la creazione dell'ambiente non è andata a buon fine. Una causa comune di questo problema sono i problemi di rete, ad esempio, a causa dei quali alcune dipendenze non possono essere caricate. In questo caso, dai un'occhiata al file di log corrispondente in C:\ProgramData\checkmk\agent\robotmk_output\working\environment_building.

Si tratta di un errore particolarmente interessante che potresti riscontrare su sistemi Windows appena installati. Il file conda.yaml può contenere anche istruzioni da eseguire dopo l'installazione delle dipendenze, ad esempio l'inizializzazione del browser di Robot Framework. Qui dovrebbero quindi essere eseguiti comandi Python. Per impostazione predefinita, Windows 11 dispone di alias per python.exe e python3.exe che rimandano al Microsoft Store. Devi disattivare questi alias in "Impostazioni/Alias per l'esecuzione delle app".

Attenzione: su Linux, il Robotmk scheduler non crea un proprio file di log (su Windows è l'robotmk_scheduler_rCURRENT.log), ma registra i log tramite l'agente e syslog. Il comando corrispondente: