Doc Technique - SYSLOG / OPERLOG Incident Analyzer V2

SYSLOG / OPERLOG Incident Analyzer V2 – Analyseur d’incidents z/OS

Objectif du guide

Installer, tester et exploiter syslog_operlog_incident_analyzer_v2.py, un utilitaire autonome qui analyse des exports SYSLOG, OPERLOG, JES, HASP, IEF, IEC, ICH, RACF, CICS, DB2, IMS, sysplex et storage afin de produire une timeline d’incident exploitable.

Télécharger l’utilitaire SYSLOG / OPERLOG Incident Analyzer V2

Le bouton principal pointe explicitement vers /static/toolbox/syslog_operlog_incident_analyzer_v2.py. Dépose ce script dans static/toolbox/ pour l’exposer depuis IDEO-Lab.

Download syslog_operlog_incident_analyzer_v2.py Django static tag

Cet outil est conçu pour le support production mainframe : au lieu de lire des centaines ou milliers de lignes SYSLOG/OPERLOG, il extrait les événements, classe les familles de messages, reconstruit des clusters temporels et met en avant les causes probables.

Timeline

Reconstruction des événements dans l’ordre : jobs, ABEND, datasets, sécurité, CICS, DB2, IMS, sysplex.

Correlation

Regroupement en clusters d’incident par fenêtre temporelle, système, job, subsystem et sévérité.

Export

Production HTML, JSON, CSV events, issues, jobs, clusters et subsystems.

Ce que le moteur analyse

Domaine	Signaux analysés	Diagnostic produit
JES / jobs	`$HASP`, `IEF`, job started/ended, RC, MAXCC, ABEND.	Début/fin de job, statut, step fautif, corrélation avec le log système.
Datasets / storage	`IEC`, `IGD`, `IOS`, B37/D37/E37, allocation, catalog, I/O error.	Problème espace, catalogage, volume, SMS, I/O, channel ou DASD.
Sécurité	`ICH`, `IRR`, RACF, access denied, S913.	Accès refusé, dataset protégé, profil sécurité, user non autorisé.
Subsystems	`DFH`, `DSN`, `DFS`, `CEE`, `BPX`, `IDC`, `ICE`.	Incident CICS, DB2, IMS, runtime, UNIX System Services, IDCAMS ou SORT.
Sysplex	`IXC`, `IXG`, `IXL`, `CSV`, system logger, coupling facility.	Suspicion de problème sysplex, logger, CF, structure ou membre instable.
Opérations	WTOR, REPLY, action opérateur, messages critiques ou répétés.	Action humaine requise, alarme prioritaire, incident en escalade.

Positionnement : la V2 sert de base à un vrai portail d’exploitation mainframe : timeline, root cause, clusters, score de risque, historique SQL futur et dashboard par subsystem.

Téléchargement des fichiers

Cette page fournit les liens explicites vers le script Python, les samples d’incident et le pack complet. Pour IDEO-Lab, les fichiers doivent être déposés sous /static/toolbox/.

Utilitaire principal

Script Python autonome, sans dépendance externe, à lancer sur un export SYSLOG/OPERLOG/JES texte.

Download syslog_operlog_incident_analyzer_v2.py Static tag

Sample mixed incident

Incident composite : job, ABEND, dataset, RACF, CICS/DB2 et messages opérateur.

Download mixed

Sample sysplex

Messages IXC/IXG/IXL, logger, coupling facility et suspicion sysplex.

Download sysplex

Sample security

RACF, ICH/IRR, access denied, S913 et éléments de conformité.

Download security

Sample storage

IEC/IGD/IOS, allocation, B37, catalog, I/O et problèmes de volumes.

Download storage

Rapport HTML démo

Rapport généré depuis le sample mixed pour validation visuelle.

Download report

Pack ZIP

Script, samples, exports et rapports de démonstration.

Download ZIP

Arborescence static recommandée

static/
                toolbox/
                syslog_operlog_incident_analyzer_v2.py
                syslog_operlog_incident_analyzer_v2_pack.zip
                sample_syslog_v2_mixed_incident.txt
                sample_syslog_v2_sysplex_incident.txt
                sample_syslog_v2_security_incident.txt
                sample_syslog_v2_storage_incident.txt
                sample_syslog_v2_mixed_report.html
                syslog_operlog_incident_analyzer_v2_guide.html

Contrôle visuel : le bouton Download syslog_operlog_incident_analyzer_v2.py est présent en haut de la page, dans l’onglet Téléchargement, dans Installation et dans Fichiers input.

Installation de SYSLOG / OPERLOG Incident Analyzer V2

Le script est autonome. Il suffit d’une version Python moderne et d’un fichier texte exporté depuis SYSLOG, OPERLOG, SDSF, JESMSGLG, JESYSMSG ou une source équivalente.

1. Arborescence locale recommandée

syslog_operlog_lab/
                bin/
                syslog_operlog_incident_analyzer_v2.py
                input/
                sample_syslog_v2_mixed_incident.txt
                sample_syslog_v2_sysplex_incident.txt
                sample_syslog_v2_security_incident.txt
                sample_syslog_v2_storage_incident.txt
                output/
                reports/
                csv/
                json/

Lien direct du script à installer

Ce bouton pointe explicitement vers /static/toolbox/syslog_operlog_incident_analyzer_v2.py.

Download syslog_operlog_incident_analyzer_v2.py Django static tag

2. Installation Linux / macOS

mkdir -p syslog_operlog_lab/bin syslog_operlog_lab/input syslog_operlog_lab/output/reports syslog_operlog_lab/output/csv syslog_operlog_lab/output/json
                cp syslog_operlog_incident_analyzer_v2.py syslog_operlog_lab/bin/
                cp sample_syslog_v2_*_incident.txt syslog_operlog_lab/input/
                cd syslog_operlog_lab
                python3 bin/syslog_operlog_incident_analyzer_v2.py --demo mixed

3. Installation Windows PowerShell

New-Item -ItemType Directory -Force syslog_operlog_lab\bin, syslog_operlog_lab\input, syslog_operlog_lab\output\reports, syslog_operlog_lab\output\csv, syslog_operlog_lab\output\json
                Copy-Item .\syslog_operlog_incident_analyzer_v2.py .\syslog_operlog_lab\bin\
                Copy-Item .\sample_syslog_v2_*_incident.txt .\syslog_operlog_lab\input\
                Set-Location .\syslog_operlog_lab
                python .\bin\syslog_operlog_incident_analyzer_v2.py --demo mixed

4. Test de validation

python bin/syslog_operlog_incident_analyzer_v2.py input/sample_syslog_v2_mixed_incident.txt \
                --profile production \
                --html output/reports/sample_syslog_v2_mixed_report.html \
                --json output/json/sample_syslog_v2_mixed_analysis.json \
                --csv-events output/csv/sample_syslog_v2_mixed_events.csv \
                --csv-issues output/csv/sample_syslog_v2_mixed_issues.csv \
                --csv-jobs output/csv/sample_syslog_v2_mixed_jobs.csv \
                --csv-clusters output/csv/sample_syslog_v2_mixed_clusters.csv \
                --csv-subsystems output/csv/sample_syslog_v2_mixed_subsystems.csv

Résultat attendu : le sample mixed doit produire une timeline, plusieurs issues, des clusters d’incident, un score de risque élevé et un rapport HTML consultable.

Fichiers input attendus

La V2 attend un fichier texte brut. L’extension peut être .txt, .log, .syslog, .operlog, .jes ou .lst. Le point clé est de conserver les timestamps, les familles de messages et les lignes système.

Utilitaire nécessaire pour analyser les inputs

Télécharger d’abord le script Python, puis lancer l’analyse sur un export SYSLOG/OPERLOG/JES.

Download syslog_operlog_incident_analyzer_v2.py

1. Sources acceptées

Source	Contenu typique	Usage
`SYSLOG`	Messages système z/OS, JES, IEF, IEC, opérateur, jobs, subsystems.	Base d’analyse incident hors sysplex ou par système.
`OPERLOG`	Journal opérateur consolidé, utile en environnement sysplex.	Corrélation multi-système, messages opérateur, WTOR/REPLY.
`JESMSGLG / JESYSMSG`	Messages job, HASP, IEF, RC, ABEND, step, dataset.	Corrélation avec jobs fautifs et batch windows.
`CICS / DB2 / IMS`	`DFH`, `DSN`, `DFS`, messages subsystem.	Détection incident applicatif ou transactionnel.
`Sysplex`	`IXC`, `IXG`, `IXL`, `CSV`, logger, CF.	Analyse des problèmes cluster, logger ou coupling facility.

2. Exemple minimal de timeline

08:53:37 $HASP373 PAYROLL01 STARTED - INIT 1 - CLASS A - SYS ZOS1
                08:54:12 IGD17272I VOLUME SELECTION HAS FAILED FOR DATA SET PAYROLL.WORK.FILE
                08:54:16 IEC030I B37-04,IFG0554A,PAYROLL01,STEP030,SYSUT2
                08:54:17 IEF450I PAYROLL01 STEP030 - ABEND=SB37 REASON=00000004
                08:54:18 $HASP395 PAYROLL01 ENDED - RC=0012

3. Samples disponibles

Mixed incident

Incident multi-signal pour valider la corrélation complète.

Download

Sysplex incident

IXC/IXG/IXL, logger, coupling facility et structures sysplex.

Download

Security incident

RACF, ICH, IRR, S913, access denied et datasets sensibles.

Download

Storage incident

IEC/IGD/IOS, B37, allocation, volume, SMS et I/O.

Download

Règle de sécurité : un vrai SYSLOG/OPERLOG peut révéler des jobnames, user IDs, datasets, noms de LPAR, volumes, subsystems et horaires sensibles. Utiliser --redact avant partage externe.

Utilisation quotidienne

1. Modes démo intégrés

python syslog_operlog_incident_analyzer_v2.py --demo mixed
                python syslog_operlog_incident_analyzer_v2.py --demo sysplex
                python syslog_operlog_incident_analyzer_v2.py --demo security
                python syslog_operlog_incident_analyzer_v2.py --demo storage

2. Analyse simple d’un fichier

python syslog_operlog_incident_analyzer_v2.py input/sample_syslog_v2_mixed_incident.txt

3. Analyse complète avec exports

python syslog_operlog_incident_analyzer_v2.py input/sample_syslog_v2_mixed_incident.txt \
                --profile production \
                --json output/json/sample_syslog_v2_mixed_analysis.json \
                --html output/reports/sample_syslog_v2_mixed_report.html \
                --csv-events output/csv/sample_syslog_v2_mixed_events.csv \
                --csv-issues output/csv/sample_syslog_v2_mixed_issues.csv \
                --csv-jobs output/csv/sample_syslog_v2_mixed_jobs.csv \
                --csv-clusters output/csv/sample_syslog_v2_mixed_clusters.csv \
                --csv-subsystems output/csv/sample_syslog_v2_mixed_subsystems.csv

4. Filtrage temporel

Les options --since et --until permettent d’isoler une fenêtre d’incident précise.

python syslog_operlog_incident_analyzer_v2.py input/operlog_export.txt \
                --since 08:50:00 \
                --until 09:10:00 \
                --profile production \
                --html output/reports/operlog_0850_0910.html

5. Mode anonymisé

python syslog_operlog_incident_analyzer_v2.py input/production_operlog.txt \
                --redact \
                --html output/reports/production_operlog_redacted.html \
                --json output/json/production_operlog_redacted.json

6. Mode batch strict

python syslog_operlog_incident_analyzer_v2.py input/nightly_operlog.txt \
                --profile production \
                --html output/reports/nightly_operlog_report.html \
                --csv-issues output/csv/nightly_operlog_issues.csv \
                --fail-on CRITICAL

Lecture recommandée : commencer par le rapport HTML, puis exploiter les CSV pour historisation, tri, SQL ou dashboard.

Paramètres de ligne de commande

1. Paramètres d’entrée et de sortie

Paramètre	Description	Exemple
`input_file`	Fichier SYSLOG/OPERLOG/JES texte à analyser.	`input/operlog.txt`
`--demo`	Lance un sample intégré : `mixed`, `sysplex`, `security`, `storage`.	`--demo mixed`
`--json`	Exporte l’analyse complète en JSON.	`--json output/analysis.json`
`--html`	Génère le rapport HTML.	`--html output/report.html`
`--csv-events`	Exporte la timeline événementielle normalisée.	`--csv-events output/events.csv`
`--csv-issues`	Exporte les anomalies détectées.	`--csv-issues output/issues.csv`
`--csv-jobs`	Exporte les jobs, RC, ABEND et statuts détectés.	`--csv-jobs output/jobs.csv`
`--csv-clusters`	Exporte les clusters temporels d’incident.	`--csv-clusters output/clusters.csv`
`--csv-subsystems`	Exporte la synthèse par subsystem ou famille de message.	`--csv-subsystems output/subsystems.csv`

2. Paramètres d’analyse et de gouvernance

Paramètre	Effet	Usage recommandé
`--profile`	Profil : `production`, `batch`, `security`, `cics`, `db2`, `ims`, `sysplex`, `storage`, `training`.	Ajuster la lecture métier et prioriser les familles de messages.
`--since` / `--until`	Filtre temporel sur la fenêtre d’incident.	Isoler 10 ou 20 minutes autour d’une panne.
`--redact`	Masque les datasets et identifiants sensibles dans les sorties.	Partage externe, support, ticket ou démonstration.
`--fail-on`	Retourne un code erreur à partir d’une sévérité donnée.	`--fail-on ERROR` ou `--fail-on CRITICAL`.

3. Exemple profil sysplex

python syslog_operlog_incident_analyzer_v2.py input/sample_syslog_v2_sysplex_incident.txt \
                --profile sysplex \
                --html output/reports/sysplex_incident.html \
                --csv-clusters output/csv/sysplex_clusters.csv \
                --csv-subsystems output/csv/sysplex_subsystems.csv

Exemples d’utilisation

Scénario 1 – Incident batch avec ABEND et dataset

Cas classique : un job échoue, un message IEC/IGD précède l’ABEND, puis JES publie le RC final.

python syslog_operlog_incident_analyzer_v2.py input/sample_syslog_v2_mixed_incident.txt \
                --profile batch \
                --html output/reports/batch_incident.html \
                --csv-issues output/csv/batch_issues.csv

Scénario 2 – Incident sécurité / RACF

Cas sécurité : access denied, S913, messages ICH/IRR et datasets sensibles à anonymiser.

python syslog_operlog_incident_analyzer_v2.py input/sample_syslog_v2_security_incident.txt \
                --profile security \
                --redact \
                --html output/reports/security_incident_redacted.html \
                --csv-issues output/csv/security_issues.csv

Scénario 3 – Incident sysplex / logger / coupling facility

Cas sysplex : corrélation des messages IXC/IXG/IXL avec les clusters temporels.

python syslog_operlog_incident_analyzer_v2.py input/sample_syslog_v2_sysplex_incident.txt \
                --profile sysplex \
                --html output/reports/sysplex_incident.html \
                --csv-clusters output/csv/sysplex_clusters.csv

Scénario 4 – Incident storage / B37 / I/O

Cas storage : IEC/IGD/IOS, allocation, volume, SMS ou DASD à vérifier.

python syslog_operlog_incident_analyzer_v2.py input/sample_syslog_v2_storage_incident.txt \
                --profile storage \
                --html output/reports/storage_incident.html \
                --csv-issues output/csv/storage_issues.csv \
                --csv-subsystems output/csv/storage_subsystems.csv

Scénario 5 – Contrôle nocturne automatisé

0 5 * * * /opt/syslog-operlog/bin/python /opt/syslog-operlog/syslog_operlog_incident_analyzer_v2.py \
                /data/operlog/nightly_operlog.txt \
                --profile production \
                --html /var/www/reports/syslog/nightly_operlog_report.html \
                --csv-issues /var/log/syslog-operlog/nightly_operlog_issues.csv \
                --json /var/log/syslog-operlog/nightly_operlog_analysis.json \
                --fail-on CRITICAL >> /var/log/syslog-operlog/analyzer.log 2>&1

Corrélation et lecture incident

La valeur principale de la V2 n’est pas seulement de reconnaître un code message. Elle consiste à replacer chaque message dans une séquence temporelle pour isoler ce qui ressemble à une root cause, un symptôme ou une conséquence.

1. Timeline intelligente

08:53:37 JOB PAYROLL01 STARTED
                08:54:12 DATASET ALLOCATION WARNING
                08:54:16 IEC030I B37
                08:54:17 STEP030 ENDED ABEND=SB37
                08:54:18 JOB PAYROLL01 FAILED

2. Types de clusters produits

Cluster	Signaux typiques	Lecture
Batch failure	HASP, IEF, ABEND, RC élevé, dataset mention.	Échec job, step fautif, cause technique à confirmer.
Storage allocation	IEC, IGD, B37/D37/E37, volume, SMS.	Problème espace, allocation, catalog ou policy SMS.
Security	ICH, IRR, RACF, S913, access denied.	Autorisation manquante ou profil de sécurité à corriger.
Subsystem	DFH, DSN, DFS, CEE, BPX.	Incident applicatif, CICS, DB2, IMS, LE ou UNIX System Services.
Sysplex	IXC, IXG, IXL, system logger, CF.	Problème cluster, logger, coupling facility ou communication sysplex.

3. Bon réflexe de diagnostic

Ne pas commencer par le dernier message : chercher le premier message anormal dans le cluster.
Lire les messages IEC/IGD/ICH/IRR juste avant un IEF450I ou HASP395.
Comparer les événements d’un même job avec les messages système globaux autour de la même minute.
Vérifier si plusieurs jobs échouent dans une même fenêtre : cela suggère un problème infrastructure plutôt qu’applicatif.
Sur sysplex, vérifier si plusieurs systèmes ou subsystems émettent des messages corrélés.

Attention : l’outil propose des candidats de root cause. Le diagnostic final doit toujours être validé par un ingénieur production, storage, sécurité, CICS/DB2/IMS ou sysplex selon le domaine.

Exports et exploitation des résultats

Rapport HTML

Vue lisible : score, timeline, root causes, issues, jobs, clusters, subsystems et evidence lines.

Analyse JSON

Format complet pour API, ingestion SQL, archivage ou comparaison automatique.

Events CSV

Une ligne par événement normalisé avec timestamp, famille, sévérité et message.

Issues CSV

Une ligne par anomalie, avec sévérité, code, contexte et recommandation.

Jobs CSV

Jobs détectés, statut, RC, ABEND, lignes associées et synthèse.

Clusters CSV

Groupes temporels d’incident pour corrélation et analyse post-mortem.

Exemple de synthèse console

SYSLOG / OPERLOG Incident Analyzer V2
                Status           : FAILED
                Highest severity : CRITICAL
                Risk score       : 100/100
                Events           : 42
                Issues           : 15
                Jobs             : 3
                Clusters         : 4
                Subsystems       : JES, IEF, IEC, IGD, ICH, DFH, DSN

Idée de table SQL pour historisation

CREATE TABLE syslog_operlog_incident_run (
                id BIGINT AUTO_INCREMENT PRIMARY KEY,
                source_name VARCHAR(255),
                profile VARCHAR(32),
                status VARCHAR(32),
                highest_severity VARCHAR(16),
                risk_score INTEGER,
                event_count INTEGER,
                issue_count INTEGER,
                job_count INTEGER,
                cluster_count INTEGER,
                subsystem_summary VARCHAR(1000),
                report_path VARCHAR(500),
                created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
                );

Vision produit : la V2 peut devenir un véritable tableau de bord d’exploitation z/OS : historique SQL, recherche par message, heatmap des incidents, comparaison de fenêtres et synthèse executive.

Dépannage et bonnes pratiques

1. Le script ne détecte pas de timeline

Cause possible	Correction
Le fichier n’est pas un texte brut.	Exporter depuis SDSF, SYSLOG ou OPERLOG en texte, pas en PDF image.
Les timestamps ont été supprimés.	Conserver le format horaire ou date/heure du log original.
Le fichier ne contient que des lignes applicatives.	Ajouter JESMSGLG/JESYSMSG ou un extrait SYSLOG complet autour de l’incident.
Format site spécifique.	Créer une règle parser dédiée ou normaliser le fichier en amont.

2. Trop d’issues remontées

Certains OPERLOG contiennent beaucoup de bruit. Commencer par filtrer avec --since et --until, puis choisir un --profile adapté : batch, security, sysplex, storage ou training.

python syslog_operlog_incident_analyzer_v2.py input/operlog.txt \
                --since 08:50:00 \
                --until 09:05:00 \
                --profile storage \
                --fail-on CRITICAL \
                --html output/reports/focused_storage_incident.html

3. Check-list avant partage externe

Utiliser --redact pour masquer datasets et identifiants sensibles.
Anonymiser jobnames, LPARs, sysplex names, volumes, applications et horaires si nécessaire.
Conserver une copie brute interne pour valider le parsing et les evidence lines.
Ne jamais conclure uniquement sur le dernier message : lire la première anomalie du cluster.
Valider le diagnostic avec l’équipe compétente : production, sécurité, storage, CICS/DB2/IMS ou sysplex.

Point critique : SYSLOG et OPERLOG peuvent exposer la topologie opérationnelle d’un mainframe. Les exports doivent être traités comme des documents sensibles.