--- title: Planificator (Centrul de joburi automate) description: Camera de comandă pentru joburile de fundal TSync — valute, stoc redus, rapoarte programate, verificări de flux: vezi rulările, eșecurile și blocajele și rulezi un job acum. product: TSync Intelligence 11.3.6 language: ro canonical: https://docs.tsync.pro/ro/scheduler/ source: https://docs.tsync.pro/llms.txt --- # 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](setup-cron-job.md) 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](configuration-center.md) 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](setup-cron-job.md) 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](notifications.md) ș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.