...
Action Items (1 Aug 2022 incident) | Owner | ||||||||
---|---|---|---|---|---|---|---|---|---|
Look at list of CSV files that were received (as per esr.queue.csv.invalid and any others subsequent to stopping the ESR services that would have not been processed at all because the services were stopped) | |||||||||
Review RabbitMQ esr.dlq.all messages [to identify any issues (such as?)] | |||||||||
Generate some Neo4J queries to check if a given {message id} was processed despite being in the DLQ | |||||||||
Once turned-on MongoDB - check which files exported to ESR today, that they were processed before 16:11 failure | DONE Reuben Roberts | ||||||||
Manually resend rabbit messages for reprocessing (excluding any found in neo4j that were processed despite being in the DLQ) | Joseph (Pepe) Kelly Whilst verifying successful replay of first found that it was already queued. Message IDs: 1db2f10c-2400-4a16-83bb-440d9962091e REPLAYED but UNNEEDED | ||||||||
Restart ESR services (instructions for sequencing for this are here: https://hee-nhs-tis.slack.com/archives/C01C7V5GT43/p1612957581030400 ) | |||||||||
Consider: for the position, placement and post queues, it is possible that create+delete messages will be processed in the incorrect order. Is there a way to check this? | |||||||||
Work out how to retrigger file processing (as per list of CSV files to be reprocessed that will be found in S3 bucket and others that were not processed at all and were received after approx. 16:11) DE_SEV_RMC_20220730_00001157.DAT (16:10:36) DE_SEV_RMC_20220731_00001158.DAT (16:11:00) DE_WES_RMC_20220729_00003589.DAT DE_WES_RMC_20220730_00003590.DAT DE_WES_RMC_20220731_00003591.DAT (16:12:40) DE_WMD_RMC_20220729_00003421.DAT DE_WMD_RMC_20220730_00003422.DAT DE_WMD_RMC_20220731_00003423.DAT DE_YHD_RMC_20220729_00003512.DAT DE_YHD_RMC_20220730_00003513.DAT DE_YHD_RMC_20220731_00003514.DAT DE_SEV_RMC_20220729_00001156.DAT DE_EMD_RMC_20220801_00003116.DAT …checked through deneries to find the additional RMC files… DE_EOE_RMC_20220801_00003316.DAT | DONE Joseph (Pepe) Kelly | ||||||||
Fix restart config for stage mongo & mongo_exporter services | |||||||||
Modify S3 File trigger to put file notification in a queue (rather than
| |||||||||
Post-incident action items: | |||||||||
Look back over similar past incidents to see if there are other actions we should consider | |||||||||
Ticket-up an action for adding VM memory alerting to slack | DONE Reuben Roberts
|
...
Lessons Learned
Consider script to restart container if memory usage exceeds threshold
Since we are moving to a managed MongoDB Atlas service, the cost-benefit of further analysis of this issue is somewhat limited. However, this may be reviewed if:
The frequency of incidents increases, or the move to MongoDB Atlas is delayed
Particular developer interest in the issue (as personal development, which may include additional Mongo training)