-----------CRON: cron_mailreader_EBRC.php
Frequency: 2 minutes
1.Reads all e-mail notifications from eximius.support Saas.
2.Clear SD_EBRC, insert emails in SD_EBRC
3.Does matching on RECOVERY/PROBLEM
4.Actions are made on SD_EBRC_history. If matched then mail is moved to Completed. Sideeffect: next run it will no longer be re-imported.
-----------Cycle 0: Read from Mailbox
-----------Cycle 1: check if new RECOVERY alert can be matched with existing PROBLEM
Search from most recent alert to oldest and search if alert is RECOVERY.
If recovery -> search with NewKey for matching PROBLEM in EBRC_History table
Conditions: Matching Newkey, Type=PROBLEM, EventTime=Today, JiraKey is existing, JiraClosed=N
-----------Cycle 2: Matching algorithm
Here we move in reverse order: from oldest to newest.
If currently checked element (which is not marked as skipped -> this is because if it was Y, then it was already tagged before)
has value RECOVERY, then we will archive it because we start in reverse order, so if it was a match it would already have been detected in cycle 1
therefore skip it now (tag it as skip=Y).
If the type is PROBLEM, then check if in the new recordset we can find a RECOVERY message for this PROBLEM with matching NewKey
If found, update matches in DB, set skip = Y.
-----------Cycle 3: Move all records where skip=Y to folder completed and delete from EBRC table
-----------CRON: cron_opsgenie_unmatchedAlerts_EBRC.php
Frequency: 5 minutes
1.Loops over all unmatched Jira tickets ie. PROBLEMS where timing is > 10 minutes -> create Jira ticket
2.Determine type of Alert and Jira ticket & assignee (also take care of 'auto')
3.Make OPSGenie rest call for Steven. (Steven will parse and create ticket/rings depending on servicetype)
4.Impact: UPDATE SD_EBRC_History SET Match=-3, IsJiraCandidate=Y,OPSGenie_requestID=:REQID
5.Impact: Delete from SD_EBRC, Move email to Completed
run cron_opsgenie_unmatchedAlerts_EBRC.php
-----------CRON: cron_opsgenie_EBRCLinkwithJira.php
Frequency: 5 minutes
1.In file cron_opsgenie_unmatchedAlerts_EBRC.php, alerts that need to be converted to a Jira ticket are flagged as -3
In that file an OPSGenie alert is created, for which Steven's code will create Jira tickets.
In this code we will try to retrieve this Jira ticket, so our goal is to filter on tickets with match= -3 that not yet have a BX reference
Once the ticket is created, table SD_EBRC_History is updated with the created BX ticket
2.Impact: UPDATE SD_EBRC_HISTORY set JiraKey=:JIRAKEY WHERE ID=:ID
run cron_opsgenie_EBRCLinkwithJira.php
-----------SUB: sub_opsgenie_analytics.php
Frequency: Cron runs 10 minutes - SUB: when clicked
1.Make REST call to OPSgenie and check list of EBRC Alerts (filtered on 2LSB-BEDC-TEAM). Only the last 100 alerts are retrieved!
2.Loop over every alert and check if alert is already in OPS_Alerts
3.If not, then create record in OPS_Alerts and try to retrieve Jira keys.
4.If yes, then update who has acked or closed the alert, get Jira keys (if previously unknown).
5.Impact: create/update OPS_Alerts record
run cron_opsgenie_analytics.php (display alerts 000-099)
run cron_opsgenie_analytics.php (display alerts 100-199)
-----------CRON: cron_opsgenie_EBRCEarlyAlertMail.php
Frequency: 3 minutes
1.Loops over all OPS_Alert records with Tag_AlertType=[ebrcax] and (coalesce(EBRCEarlyAlertProcessed,'N') = 'N')
2.If found, then search for destinees (see escalation page in portal) and send email to notify that potential issue as occurred
3.This code also has a second part in which we check for a closing email. in case the ticket is marked as closed and EBRCEarlyAlertProcessedCloseMail = N.
4.Impact: UPDATE OPS_Alerts set EBRCEarlyAlertProcessed='Y',EBRCEarlyAlertProcessedCloseMail='Y'
run cron_opsgenie_EBRCEarlyAlertMail.php