Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSOutput Should not silently tolerate exceptions during rule creation #11941

Open
klannon opened this issue Mar 20, 2024 · 2 comments · May be fixed by #12194
Open

MSOutput Should not silently tolerate exceptions during rule creation #11941

klannon opened this issue Mar 20, 2024 · 2 comments · May be fixed by #12194

Comments

@klannon
Copy link

klannon commented Mar 20, 2024

Impact of the bug
MSOutput

Describe the bug
A change in Rucio caused tape output rule creation to fail and we missed this for 3 weeks causing 7 PB of tape transfers to pile up.

How to reproduce it
Break Rucio

Expected behavior
If MSOutput fails to create a rule it, it should trigger an alarm, at least if it fails for multiple cycles.

Additional context and error message
None

@amaltaro
Copy link
Contributor

And I just stumbled upon this issue, after resolving another 3-4 weeks outage of rule creation in MSOutput, addressed in this ticket: #12044

I am setting this ticket to Q4 such that we can at least implement an alarm and get notified when the whole MSOutputConsumer cycle is skipped.

@mapellidario
Copy link
Member

After a private discussion with Alan, we decided that I can start working on this issue. so far, we agreed on a two-pronged approach:

  • make sure that if MSOutput has trouble processing a single workflow, it continues processing the next workflow and does not break from the loop.
  • Send monitoring data to a new AMQ topic (or re-use and existing topic with a new document type).
    • the idea is to have a single plot with a time series of the number of workflows that MSOutput needs to process
    • if MSOutput fails to process one or more workflows, then it will be visible as a non-zero baseline in this new plot. I like this approached because it worked reliably for CRAB's Publisher monitoring
    • we can setup a grafana alert on this plot (send a message if the number of workflows is above a threshold for longer than X days.)

We considered the idea of having MSOutput sending an alert if it fails to process a workflow N times, but it would require to implement some new logic to keep track of past attempts. Too much effort developing new code when we can achieve the same result exploiting existing monitoring infrastructure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

3 participants