[FEATURE] Publish-subscribe mechanism in Alerting plugin for event driven plugin to plugin integration

[sbcd90]

Introduction

Alerting plugin allows users to monitor data and create alert notifications that trigger when conditions occur in one or more indexes. Users create a monitor with trigger conditions that generate various alert notifications through the message channel you select as a destination. Notifications can be sent to email, Slack, or Amazon Chime. The concepts of monitor, findings & alerts introduced in this plugin is generic enough to be reused by other plugins to meet their alerting requirements.

Problem Statement

Today, if other plugins would want to interact with Alerting plugin, plugins make transport layer calls to Alerting plugins' CRUD based monitor apis to schedule the periodic jobs & then make get transport calls to fetch findings & alerts from Alerting plugin. Alerting plugin also integrates with Notifications plugin to provide event based notification messages to external channels like Slack, Chime etc. However, we do not have a good mechanism today for the scenario, where a plugin wants to be notified when a finding/alert is generated in the Alerting plugin. The scenario can be further extended to use cases where Alerting would be publishing events once & it would be received by all the plugins who subscribe to those corresponding events.

Proposed Solution

This issue proposes an approach to design a publish-subscribe system for the Alerting plugin. This system allows Alerting plugin to define hooks at specific points in the alerting workflows & then trigger events whenever those hook points are hit during execution of the workflow.

Security considerations in the proposed solution

The Composite Event Listener considers the current user from the threadcontext & make transport layer calls to the subscribing plugins. So, if the threadcontext user does not have cluster permission to access the transport layer handler, the subscribing plugin would not receive the event.