Scheduler Erste Seite |
| 19. Mai 2002 |
Jeder Job-Lauf wird verzeichnet. Festgehalten werden
An der TCP-Schnittstelle sind Auszüge der Historie lesbar.
Spalten der Historie
| id | Eindeutige Kennung der Task (Tabellenschlüssel) |
| spooler_id | Scheduler-ID |
| job_name | Job-Name |
| start_time | Startzeit (yyyy-mm-dd HH:MM:SS) |
| end_time | Endezeit (yyyy-mm-dd HH:MM:SS) |
| steps | Anzahl Aufgerufener spooler_process() |
| cause | Anlass des Starts |
| error | 0: Kein Fehler; 1: Fehler |
| error_code | Fehlercode |
| error_text | Fehlertext |
| parameters | Parameter des Jobs (wenn vorhanden) als XML-Dokument (Clob) |
| log | Job-Protokoll (nicht in der tabulierten Datei bei Verwendung ohne Datenbank) |
Die Historie kann in einfache Dateien oder in eine Datenbank geschrieben werden.
Für jeden Job wird im Verzeichnis der Protokolldateien (Option -log-dir=) eine Datei fortgeschrieben. Die Datenfelder werden durch Tabulator getrennt. Beim Start eines Jobs wird ein Satz geschrieben, der beim Ende mit den vollständigen Daten überschrieben wird.
Dateiname ist log_dir/history. scheduler_id.job.jobname.txt
Die Datei wird beim Job Scheduler Start neu angelegt. Eine bereits vorhandene Datei kann zurvor umbenannt und komprimiert werden.
Der Job Scheduler schreibt in die erste Zeile die Spaltennamen.
Tabulatoren in den Daten (v.a. Fehlermeldung) werden unterdrückt.
Jedes Feld hat für 1024 Zeichen Platz. Längere Einträge werden abschnitten.
Archivierung
Beim Start des Job Schedulers werden die Historien der Jobs überschrieben. Die vorhandenen Historien können mit dem Eintrag history_archive in der Konfigurationsdatei factory.ini archiviert werden:
[spooler] history_archive = yes|no|gzip [Job jobname] history_archive = yes|no|gzip
history_archive=yes benennt die Datei um. Dazu wird der Dateiname um einen Zeitstempel (sekundengenau) ergänzt.
history_archive=gzip komprimiert die Datei mit zlib (gzip) von Jean-loup Gailly (http://www.gzip.org/zlib/). Der Dateiname wird neben dem Zeitstempel um die Endung .gz ergänzt. Die Datei kann mit gzip dekomprimiert werden. Sie lässt sich auch mit der Hostware mit "nl | gzip | history.gz" lesen.
Alle Daten werden in eine Tabelle geschrieben. Das Task-Protokoll wird in ein Blob geschrieben.
Die Tabellennamen können in der Konfigurationsdatei factory.ini eingestellt werden:
[spooler] db_history_table = tabellenname | SCHEDULER_HISTORY db_variables_table = tabellenname | SCHEDULER_VARIABLES
In der Tabelle SCHEDULER_VARIABLES wird in einem Eintrag die nächste freie Job-Nummer gehalten.
need_db
Mit dem Eintrag need_db=no kann eingestellt werden, dass der Job Scheduler auch starten soll, wenn die Datenbank sich nicht öffnen lässt. Voreingestellt ist need_db=yes.
[spooler] db = odbc -db=scheduler need_db = no
Wenn mit db= nur ein Datenbankdateiname und log_dir=*stderr eingestellt sind, kann die Datenbank mangels Verzeichnis nicht geöffnet werden. Bei need_db=yes startet dann der Job Scheduler nicht.
Microsoft-Access-Datenbank wird automatisch angelegt
Wenn bei db= nur ein einfacher Dateiname angegeben ist, stellt der Job Scheduler ihm "odbc -create" voran. Damit wird eine Microsoft MS-Access automatisch angelegt (s. Dateityp ODBC).
In der Datenbank werden die Tabellen SCHEDULER_HISTORY und SCHEDULER_VARIABLES verwendet. Sie werden bei Bedarf eingerichtet, wobei die SQL-Syntax von MS-Access verwendet wird.
Satz für Job Scheduler Start
Der Job Scheduler schreibt beim Start einen Satz mit einer eigenen ID in die Historie. Beim Beenden trägt er in diesem Satz die Zeit ein, so dass ein Satz mit Start- und Endezeitpunkt des Job Schedulers vorliegt. Job-Name ist "(Spooler)".
In der Konfigurationsdatei factory.ini lassen sich einstellen:
[spooler] db = datenbank db_history_table = SCHEDULER_HISTORY db_variables_table = SCHEDULER_VARIABLES history = no|yes history_columns = feld1, feld2, history_on_process = yes|1|2 history_with_log = no|yes|gzip history_archive = no|yes|gzip [Job jobname] history = no|yes history_file = dateiname history_columns = feld1, feld2, history_on_process = yes|1|2 history_with_log = no|yes|gzip history_archive = no|yes|gzip
Die Einstellungen unter [Job jobname] haben Vorrang vor [spooler].
history=no unterdrückt die Historie. Wenn eine Datenbank angegeben ist, wird dennoch der Satz für den Job Scheduler Start geschrieben.
history_on_process gibt die Anzahl der Aufrufe von spooler_process() an, ab der ein Eintrag in die Historie geschrieben werden soll. Bei 1 wird ein Satz nicht geschrieben, wenn spooler_open false liefert.
history_with_log lässt das Task-Protokoll in die Datenbank mit aufnehmen. Wahlweise komprimiert.
In der Historie enthält die Spalte cause den Anlass des Job-Laufs:
| Code des Anlasses | Bedeutung |
|---|---|
| none | Task ist nicht gestartet (das kommt in der Historie nicht vor) |
| period_once | <run_time once="yes"> |
| period_single | <run_time single_start="..."> |
| period_repeat | <run_time repeat="..."> |
| job_repeat | spooler_job.repeat=... |
| queue | spooler_job.start() oder <start_job> |
| queue_at | wie queue, aber mit bestimmter Zeitangabe (Option at) |
| directory | eine Verzeichnisüberwachung (start_when_directory_changed)lässt den Job starten |
| signal | <signal_object> |
| delay_after_error | spooler_job.delay_after_error |
Jede Task, die für einen Job gestartet wurde, erhält eine Kennung. Wenn eine Datenbank verwendet wird, ermittelt der Job Scheduler sie aus der Tabelle SCHEDULER_VARIABLES. Die Kennung ist dann für alle Job Scheduler eindeutig, die diese Datenbanktabelle nutzen. Andernfalls wird eine fortlaufende Nummer vergeben. Die erste Task hat die Nummer 1.
Die Kennung kann im Skripten, die das Job Scheduler API verwenden, mit der Eigenschaft id abgefragt werden:
meine_id = spooler_task.id
Die Historie kann weitere beliebige Felder aufnehmen, die der Job füllen kann:
spooler_task.history_field( "feldname" ) = wert
Das Feld feldname muss als Spalte in der tabulierten Datei oder in der Historientabelle bekannt sein. Groß-/ Kleinschreibung spielt keine Rolle.
Wenn die Historie in einer Datenbank geführt wird, kann es eine Rolle spielen, von welchem Typ wert ist, insbesondere ob Zahl oder Zeichenkette.
Die zusätzlichen Spalten werden in der Konfigurationsdatei factory.ini bekannt gemacht
[spooler] history_columns = spalteniste [Job jobname] history_columns = spaltenliste
Die spaltenliste ist eine durch Komma getrennte Liste von Spaltennamen, die der tabulierten Datei hinzugefügt werden sollen.
Die zusätzlichen Spalten in der Historientabelle werden automatisch erkannt.
Wenn der Job Scheduler die Tabelle SCHEDULER_HISTORY anlegt, richtet er auch die extra Spalten ein, die in history_columns aufgeführt sind. Als Typ wird char(250) verwendet.
<show_history job="jobname" prev="anzahl|all "what="all"/>
liefert rückwärts geordnet die letzten anzahl Einträge der Historie des angegeben Jobs jobname. Voreinstellung für anzahl ist 10. Alle Einträge werden mit tail="all" gelesen. Die Funktion benötigt viel Speicherplatz, denn die Historie wird als XML-Dokument mit DOM im Speicher aufgebaut. Max. 1000 Einträge werden geliefert.
what="all" liefert auch die Job-Protokolle.
Mit folgenden Varianten lassen sich Ausschnitte der Historie lesen. Das Attribut what kann immer angegeben werden.
Um anzahl Einträge vor der id zu erhalten:
<show_history job="jobname" id="id" prev="anzahl"/>
Um anzahl Einträge nach der id zu erhalten:
<show_history job="jobname" id="id" next="anzahl"/>
Um nur den Eintrag der id zu bekommen. Gut, wenn mit what="all" das Jobprotokoll einer bestimmten Task gelesen werden soll.
<show_history job="jobname" id="id"/>
Das Ergebnis sind dann so aus:
<history> <history.entry id="kennung" job="jobname" start_time="startzeit" end_time="endezeit" ...> <variableset> <variable name="name1" value="wert1"/> <variable name="name2" value="wert2"/> </variableset> <log>Jobprotokoll</log> </history.entry> <history.entry ...> ... </history.entry> ... </history>
Fehler beim Öffnen oder Schreiben der Historie werden ins Job Scheduler Protokoll geschrieben und ignoriert.
Zuletzt geändert von aa, 2007-10-09 |