Planificator (Centrul de joburi automate)

Planificatorul (/admin/tsync_scheduler) e camera de comandă pentru joburile de fundal care țin TSync în funcțiune — reîmprospătarea zilnică a valutelor, scanările de stoc redus, e-mailurile cu rapoarte programate, verificările de workflow ș.a. Nu înlocuiește cron job-ul de pe server; îți dă vizibilitate și un buton de rulare manuală peste ceea ce face deja cron-ul.

Deschide consola

Planificator în meniul lateral, sau /admin/tsync_scheduler. Se ajunge din Centrul de configurare când modul hub e activ.

Ce vezi

• Joburi — fiecare job înregistrat, ce face, când a rulat ultima dată și dacă e sănătos.
• Rulări — istoricul fiecărei rulări cu statusul ei (succes / eșuat / sărit).
• Eșecuri — rulările cu eroare, ca să observi rapid o problemă.
• Blocaje — un job rulează sub un blocaj ca să nu se suprapună cu el însuși; poți vedea (și, la nevoie, reseta) un blocaj rămas agățat.
• Diagnostic — o vedere rapidă a stării întregului planificator.

Rulează un job acum

Fiecare job are un buton Rulează acum (acțiune POST sigură, cu confirmare). Folosește-l ca să forțezi, de exemplu, reîmprospătarea valutelor fără să aștepți tick-ul zilnic. Rularea manuală e înregistrată în Rulări, ca oricare alta.

Vederea Enterprise

Planificator → Enterprise (/admin/tsync_scheduler/enterprise) arată programarea avansată: joburi care depind de alte joburi (rulează în ordinea corectă), priorități, limite SLA (un job care rulează prea mult e semnalat), dry-run-uri și detectarea anomaliilor (o rulare mult mai lentă decât de obicei e evidențiată).

Cum oprești o sarcină

Fiecare sarcină are un comutator activat/dezactivat. Dezactivarea o scoate din ce ridică cron-ul, dar îi păstrează istoricul intact — util când o sarcină face figuri și vrei ca restul programului să meargă mai departe, în loc să oprești cron-ul cu totul.

Activarea și dezactivarea cer o permisiune separată, deci un operator care poate rula o sarcină nu poate neapărat s-o și amuțească.

Repetiție cu costuri zero — dry run

În Scheduler → Enterprise, o sarcină poate fi rulată ca dry run: parcurge pașii reali, dar e marcată ca repetiție și — important — durata ei nu intră în linia de bază a sarcinii. Contează din cauza felului în care se detectează anomaliile (mai jos): câteva repetiții ar învăța altfel sistemul că sarcina e mai lentă decât e.

Rezultatul se arată imediat, cu starea și cât a durat.

Cum citești lista de rulări

Trei rezultate, iar al treilea e cel interpretat greșit:

• succes — a rulat și s-a terminat.
• eșuat — a rulat și a ridicat o eroare. Motivul e pe rulare.
• sărit — nu a rulat, și de obicei intenționat. O sarcină e sărită când e dezactivată, când lacătul ei e încă ținut de o rulare anterioară sau — în vederea Enterprise — când o sarcină de care depinde n-a reușit. O dependență sărită nu e un eșec al sarcinii ăsteia; urcă pe lanț.

Coloana „Ultima rulare" răspunde la întrebarea pusă

Majoritatea joburilor din listă sunt conduse: cron-ul platformei le cheamă direct, iar Planificatorul doar le observă. Până la v11.1.6 coloana arăta doar ultima rulare pornită din această consolă, deci aducerea zilnică a cursurilor putea scrie 10 iunie deși adusese cursurile chiar în dimineața aceea — iar un administrator conchidea, pe bună dreptate, că jobul e mort.

Coloana arată acum cea mai recentă dintre cele două și spune de unde vine, deci „când a rulat ultima oară" primește răspunsul real, nu o notă despre mecanismul la care ar fi trebuit să te gândești.

Iar unde răspunsul chiar nu există, o spune: unele joburi conduse nu înregistrează nimic nicăieri, iar acelea scriu acum „e condus, dar rulările lui nu se înregistrează". A arăta o rulare manuală în locul unui răspuns pe care consola nu-l are era chiar ce făcea coloana înșelătoare.

Cele trei dale se adună

Rulări (24h), OK (24h) și Eșuate (24h) lăsau o gaură: 2 805 rulări, 2 649 OK și o dală „Eșuate" goală — 156 de rulări care nu erau nici una, nici alta, arătate nicăieri. Nu lipseau niciodată: OK numără succes și avertisment, Eșuate numără eșec și timeout, deci sărite, blocate, în curs și învechite cădeau în niciuna.

O rulare sărită e de obicei protecția la suprapunere funcționând corect — dar trei numere care nu se adună nu se pot deosebi de un eșec tăcut. Restul e numărat acum și defalcat pe status, pe același ecran.

Când un lacăt rămâne blocat

O sarcină ține un lacăt cât rulează, ca să nu se suprapună cu ea însăși. Dacă o rulare e întreruptă — procesul PHP e omorât, serverul repornește la mijloc — lacătul poate să-i supraviețuiască, iar sarcina sare apoi fiecare ciclu, fiindcă e convinsă că o copie încă rulează.

Resetează lacătul îl eliberează. Fă asta doar când ești sigur că sarcina chiar nu mai rulează; eliberarea unui lacăt viu e exact felul în care ajungi cu două copii ale aceleiași sarcini deodată. Resetarea se înregistrează pe sarcină.

Cum se decide o anomalie

O rulare e marcată anomalie când durează mai mult decât media mobilă a sarcinii plus de două ori abaterea ei standard. Pe scurt: vizibil mai lentă decât e sarcina asta de obicei — nu mai lentă decât o limită fixă, deci o sarcină lentă prin natura ei nu dă alarme false în fiecare noapte.

O depășire de SLA e verificarea separată, absolută: sarcina și-a declarat o durată maximă și a depășit-o.

Planificatorul doar observă și îți permite să rulezi joburile existente — nu rescrie cron-ul. Dacă un job nu rulează deloc, verifică mai întâi că cron job-ul de pe server e configurat.

Sarcina „Retenție telemetrie de acces"

Începând cu v10.2.0 apare în listă o sarcină gestionată nouă: Retenție telemetrie de acces (security.telemetry_prune). Ea șterge datele de măsurare a accesului mai vechi de 30 de zile.

La aproape toate instalările o vei vedea raportând „sărit", și e corect. Măsurarea accesului se livrează oprită, deci nu există nimic de șters. Sarcina spune limpede asta în loc să raporteze „succes" — o trecere care n-a făcut nimic fiindcă n-a căutat nimic e chiar felul de raport care face o listă întreagă de necitit.

Nu ai nimic de configurat, iar dacă nu pornești măsurarea, sarcina nu va face niciodată nimic.

Zile până când un semnal critic escaladează

Lângă controlul de retenție a jurnalelor mai există o setare: zile până când un semnal critic escaladează, implicit 7, oriunde între 1 și 365.

Consolele TSync detectează problemele corect; ce nu afla nimeni era că una critică stă deschisă de săptămâni. După atâtea zile, un asemenea semnal ridică alerta „Semnal deschis de prea mult timp" în Centrul de notificări și apare în panoul „Necesită atenție". Un semnal pe care l-ai confirmat nu escaladează, iar unul care nu mai e ridicat își pierde complet ceasul.

Pune-o mai jos dacă vrei să afli mai devreme; mai sus dacă echipa ta revizuiește oricum semnalele la un interval mai lung.