Notification system investigation

[mshustov]

I would like to start by clarifying the functional requirements for high-level components for Notification System (NS) MVP (TODO: add a link to MVP issue)

The design and terminology are outlined in the issue are not definitive. Consider it as a starting point in the discussion.

High-level outlook

Components:

Sourcing

Provides API (JS, HTTP maybe) to external sources to create notification event in the notification system.
Functional requirements:

• Identify notification sources and describe use-cases. Known sources:

  • Stack (ranked in somewhat priority order)
    • Onboarding suggestions
    • Search sessions ([Meta] Search Sessions Roadmap #61738)
    • Cases (Support "@"mentioning other users #80334)
    • Security messages (Alert users when authentication features are not enabled #73929)
    • Alerting ([UI] Notifications bell menu #51547)
    • Scheduled reports ([Reporting] Scheduled Reports #79905)
    • Deployment issues (stack monitoring essentially)
  • Cloud
    • Stack notifications from multiple deployments
    • Cloud console notifications
    • Billing
    • Autoscaling
    • Critical errors, issues with cloud platform, completed actions, expiring trials, warnings, new releases, and more.
  • Marketing
  • Elastic news feed
    • With personalization, potentially support for multiple subscriptions (Support multiple news feeds #61550)
  • Support (need to discuss in more detail with support). On Cloud only.
    • Cases updates from support
  • Training (need to discuss in more detail with training). On Cloud only.
    • Suggested trainings

• Is confirmation for status change (sent, delivered) required? No

• Does sender knows a notification recipient?
  There are several use-cases: with a recipient, with a group of recipients, without a particular recipient.

  • Onboarding suggestions
    To start, we will know a lot about the cluster itself and general actions taken. So suggestions provided by this service will likely be global to Kibana. Any suggestions for data sources, etc. would initially be shown to all users (maybe filtered by ingest permissions in this example.).
    Once we have users and start learning more about a user, these suggestions can become more personalized. In which case, I would expect the suggestion service to provide the unique user ID in the suggestion provided.
  • Elastic news feed
    The Elastic news feed content is also global to Kibana. The feed itself is absent of any consumer and is simply meant to be consumed by Kibana. In this case, maybe absence of a recipient = global.
  • Search session
    A search session has been created by a user ([data.search] Add user information to background session service #84975), so we will have this information readily available. For any notifications generated by the feature, I would expect the unique user ID to be passed along as well.
  • Case assignment / mention
    With case assignment and mentions, both actions will be assigned to a user (Support "@"mentioning other users #80334). For any notifications generated, I would expect that unique user ID to be passed along.
    Blocker: Requires alignment on User entity across all the data sources is covered by Object Level Security #39259 and Support "@"mentioning other users #80334

• Can a sender send a message to an arbitrary group of users?
  Who defines the rules for targeting the notification audience? Tiers are domain-specific: e.g, the spaces concept exists in the Stack only, Cloud has teams concept

• Does NS implement rate-limiting for the number of created notifications?
  Senders implement domain-specific throttling. NS implements rate limiting as protection against DDOS attacks.

Non-functional requirements:

• Do notification sources need to have access to Kibana to use NS API? Some of the notification sources might exist outside of the Kibana deployments spun up inside private networks.
  • push vs pull mechanism

Storage

Stores notification events.
Functional requirements:

• For how long notifications are stored?
  Notification lifetime might be:

• Source defined
  Today, the news feed defines the lifetime of a notification and the current implementation will filter out the feed based on dates. This allows marketing to proactively define what’s available in the feed based on dates, allowing them to curate a list far out into the future (example PR).
  Related, search sessions will have a lifetime associated with them (either a default or admin defined value). I would think we want to persist the notifications to be searchable in the notification center for the lifetime of that search. We’d need to discuss with the team though.

• Global default
  We define a global default (either by number of notifications and / or time). Something like 30, 60 or 90 days seems reasonable, but will need to do more research.

• Admin configurable
  Depending on how a cluster is used, we’ll likely want to make this configurable as a global Kibana configuration

• Does it support export / import operations across different Kibana instances? No

Non-functional requirements:

• Acceptable down-time window

Delivery

Provides API to deliver a notification to an end-user, retrieve the notifications for an end-user.
Functional requirements:

• Identify supported delivery mechanism.
  Confirmed: Notification center in Kibana UI. Maybe in the future others (SMS, email, slack).
• Who configures the delivery mechanism: sender, recipient, or the system according to the business rules? Unnecessary
• Should we support real-time notifications? No. Acceptable delay up to 1-2 minutes (a preliminary value)
• Do messages have different priorities? Yes, there are different properties in terms of urgency of delivery and position in UI.
• System guarantees the delivery of notifications?
• Should NS provide API to export notifications for an arbitrary user?

Non-functional requirements:

• Supported level of notifications processed by the system per minute/hour.
  Should handle spikes in the number of created notifications without affecting the Kibana performance.
• Must work with deployments containing multiple Kibana instances

Notification system control API

Provides control over notification status, notification sources, user specific notification preferences.

Functional requirements:

• Allows an end-user to change notification status: read / unread, pin / unpin.
• Users can filter notification list by
  • notification type
• What kind of control granularity will a user have for managing sources and event types?
  • We don't allow a user to unsubscribe from / subscribe to a source. A user can filter the notification list to change the output.
• Stores user-specific notification preferences.

Notification event

The notification informs an end-user about the occurrence of some event at a certain point in time. Some notifications might have CTA associated with it.

Functional requirements:

• Should NS support internationalization? A sender does not know what locale a recipient uses.
  For any system / Kibana generated content, yes. We treat the notification center like any other UI. For user generated content, no.
• How customizable should the notification format be? HTML or a predefined structure with limited functionality.
  Notification content has a predefined structure: Icon, badge, title / link, description and action
• May the notification event contain sensitive data (API token, for example)? No

Licensing

• Licensing requirements for functionality, sources, delivery mechanism.
  • Do we support User entity for OSS ?

[ryankeairns]

For reference, here is the EUI issue which contains a prototype link for the notifications center UI design.

[mshustov]

closed in favor of #90297