Create subtickets for alert updates

[linkeal]

Thanks for the great project. Really appreciate it. I've thought about creating subtickets for every additional alert that is fired. This way you e.g. you have a full audit trail of alerts and don't loose any alert update.

Example:

1. Alert: CPU > 90% on Server1
2. Alert CPU > 90% on Server1, Server2
3. Alert CPU > 90% on Server1, Server3, Server5, Server9

With the current setup this information is just not updated within the ticket. It will stay forever with the 1. Alert and you don't even notice that you have similar problems on other hosts. I've thought about just updating the ticket (and then you could also see the audit in the issue history) but I thought that additional subtask would make it even more verbose.

With the subtask you can e.g. see on one view that now the CPU load is spreading among your cluster. E.g. due to a some suspicious attack

So proposed behavior: For every alert that is fired (and already an existing incident was created) we create a new subtask.

I'm happy to open a PR and contribute this feature to the repository if you like the idea. I've already started on it. Happy to discuss.

[eveningcafe]

@linkeal your ideal maybe good, i'm faceing same problem as you. You have fork project that you're working on for this feature? Share with me your work, hope i can help. [email protected]

And. I have an ideal. Proposed behavior: if we have config:

route:
group_by: ['event','environment']
receivers:
- name: 'jira-ab_task'
  webhook_configs: ...
continue: true
routes:
  - group_by: ['event','environment','host']
    receiver:
     - name: 'jira-ab_sub_task'
        webhook_configs: ...

So the task will be: [ alert CPU, product] subtasks:
[ alert CPU, product, server1 ] [ alert CPU, product, server2 ]

what do you think?

[bharatinturi]

Dear @linkeal @ngohoa211 have you got any solution for creating sub ticket? Thank you Regards Bharath