L'alerting dans la Suite Elastic
L'alerting est un élément fondamental des cas d'utilisation Elastic. Depuis le lancement de Watcher (notre première suite de fonctionnalités d'alerting pour Elasticsearch) en 2015, un grand nombre d'utilisateurs nous ont fait part de leurs commentaires, ce qui nous a permis de mieux comprendre ce qu'ils attendaient d'un système d'alerting, ainsi que de l'expérience utilisateur associée. Dans cet article, nous allons résumer les principaux enseignements que nous avons tirés au fil des ans, expliquer comment ils ont influencé nos projets en 2019, et ce que nous réserve la fonctionnalité d'alerting de la Suite Elastic pour les années à venir.
Qu'avons-nous appris ?
Nous avons soufflé la quatrième bougie de la fonctionnalité d'alerting d'Elastic – l'occasion de faire le point sur l'incroyable quantité de connaissances que nous avons acquises au sujet des systèmes d'alerting. Dans cet article, je vais tenter de synthétiser ces enseignements en trois points prospectifs : les alertes font partie intégrante de tous les cas d'utilisation ; nous devons comprendre ce qu'elles signifient pour chaque cas d'utilisation ; la détection des alertes et la réponse qu'elles entraînent sont de plus en plus avancées. Forts de ces enseignements, nous sommes mieux armés pour penser l'avenir de l'alerting.
Omniprésence de l'alerting
L'alerting fait partie intégrante de tous nos produits et cas d'utilisation. À partir du moment où vous disposez de données actives, vous avez un cas d'utilisation d'alerting. C'est à partir de constat que nous avons développé Watcher – et cela explique son succès. Mais lorsqu'on y regarde de plus près, on s'aperçoit clairement qu'il existe autant de façons d'exploiter l'alerting qu'il y a de cas d'utilisation.
Les alertes et les notifications jouent un rôle essentiel, que ce soit dans des produits comme Elastic Logs, SIEM, APM, Uptime, Infrastructure et Maps, que dans des fonctionnalités comme Monitoring et Machine Learning, en passant par une multitude de tableaux de bord Kibana – pourtant, chacun d'entre eux présente des besoins uniques, qu'il s'agisse de détecter des conditions, de les exprimer ou de les afficher en contexte. Pour être efficaces, l'alerting et le monitoring nécessitent une intégration étroite au produit. Avec l'évolution de la Suite et de ses différents usages, il nous est clairement apparu que nous devions compléter l'alerting Elasticsearch pour permettre l'étroite intégration des alertes, ainsi que la richesse de leur expression dans chaque cas d'utilisation.
Comprendre la signification des alertes
L'omniprésence de l'alerting a pour corollaire qu'avec l'explosion des alertes générées par les différents cas d'utilisation, celles-ci deviennent leur propre source de données et nous donnent l'occasion de comprendre les systèmes et leur état. Pour paraphraser les ingénieurs de la fiabilité des sites (SRE), nous pourrions aussi dire qu'elles nous donnent l'occasion d'améliorer l'observabilité de l'ensemble du système.
Chaque cas d'utilisation interprète les données à sa façon : les alertes montrent ainsi différents aspects d'une situation. La réponse adaptée à un incident dépend souvent de données provenant de différentes sources, ainsi que de la corrélation des différents types d'alertes et d'événements permettant de comprendre la situation. Dans certains domaines tels que la gestion de l'information et des événements de sécurité (SIEM), les alertes de haut niveau sont déclenchées à partir de modèles associés à des alertes de bas niveau.
Avec l'explosion des cas d'utilisation de la Suite Elastic, un système d'alerting efficace ne se contente pas de générer des alertes : il vous aide à comprendre ce qu'elles signifient pour chaque cas d'utilisation. Par exemple, des alertes Uptime peuvent signaler l'indisponibilité d'un service, des alertes APM, expliquer quelle transaction en est à l'origine, et des alertes Monitoring, en indiquer la cause. Un système d'alerting doit fournir du contexte, permettre la corrélation et accroître la visibilité globale – pour les humains, comme pour les machines.
Détection et action
La compréhension de la signification des alertes a quant a elle pour corollaire qu'avec un système plus observable, nous sommes en mesure de détecter des situations plus complexes et d'entreprendre des actions plus élaborées. Et de plus en plus souvent, cela dépasse la définition habituelle de l'alerting.
L'alerting est habituellement centré sur la détection d'une condition qui est ensuite signalée à un humain. Et cela s'arrête souvent là. Mais avec un peu de recul, on comprend qu'un système d'alerting peut faire partie intégrante d'une boucle de contrôle ou de rétroaction : observation, détection d'une condition, action, et nouvelle observation.
De nos jours, l'action implique habituellement une notification : un humain est mis dans la boucle pour contrôler le système et tenter de résoudre le problème. Mais avec la meilleure visibilité que nous avons sur les systèmes, l'action peut jouer un plus grand rôle, généralement sous la supervision d'un humain. Il peut s'agir d'un système semi-autonome piloté par une conversation bidirectionnelle (comme un chatbot), ou d'un système complètement autonome, comme on en voit dans la tendance à l'autoscaling, à l'autoréparation, ou encore à l'auto-optimisation des applications.
Un système d'alerting doit permettre une détection et des actions avancées, sachant que la détection ne se limite pas nécessairement à l'envoi d'une requête vers Elasticsearch, et que l'action ne se limite plus non plus à l'envoi d'un e-mail ou à l'appel d'un webhook.
Nos enseignements mis en pratique
À l'automne 2018 nous avons décidé d'aligner notre alerting sur les trois observations ci-dessus.
Nous avons aussi décidé que le meilleur moyen d'y parvenir était de faire des alertes un élément primordial de Kibana :
- Omniprésence de l'alerting : des intégrations d'alerting ultracomplètes dans tous nos produits, aux niveaux des plug-ins, des API et des interfaces utilisateur
- Comprendre la signification des alertes : offrir une interface intuitive pour tous les types d'alerting
- Détection et action : des mécanismes de détection et d'action avancés grâce aux plug-ins Kibana
Watcher nous a aussi appris que l'alerting doit pouvoir scaler pour s'adapter aux charges d'alertes de production, tout en étant hautement disponible et extrêmement fiable. Les contrats des API, des interfaces utilisateur, des plug-ins et des bibliothèques qui soutiennent ces trois observations doivent s'appuyer sur une base à la fois solide et scalable. Pour résumer, le système d'alerting d'Elastic comporte quatre couches :
En 2019, nous avons jeté les bases du nouveau système d'alerting de Kibana.
En janvier, Task Manager faisait son apparition dans la version 6.7, intégrant à Kibana la planification en arrière-plan des tâches persistantes pouvant être distribuées sur différentes instances Kibana pour une scalabilité et une disponibilité accrues. Les composants de la couche de base des alertes tels que Task Manager ne se limitent pas à l'alerting. Par exemple, Task Manager peut assurer une meilleure expérience des rapports planifiés dans Kibana.
En juin, nous avons ajouté deux nouveaux jeux d'API à Kibana : l'API d'alerting et l'API d'actions.
L'API d'actions permet à Kibana d'enregistrer et de déclencher des actions, tout en fournissant un contrat simple, vous permettant de définir vos propres actions, ce qui facilite la personnalisation. La première version proposait aussi des exemples d'actions pour le logging, pour Slack et pour les notifications par e-mail.
L'API d'alerting permet quant à elle à Kibana d'enregistrer des formes de détection en tant que "types d'alertes", puis d'exécuter ces vérifications suivant un calendrier grâce au système Task Manager. Tout comme pour les actions, le contrat d'alerting est simple : il suffit de l'exprimer dans une fonction JavaScript exécutée sur le serveur Kibana pour alimenter une alerte.
La Suite Elastic 7.4 vient étoffer les niveaux inférieurs du système d'alerting : renforcement des API ; prise en charge de Security et de Spaces ; nouvelles actions intégrées, telles que l'indexation, les webhooks et PagerDuty.
Et ensuite ?
Depuis deux mois, le développement du système d'alerting de Kibana bat son plein, et nous allons continuer sur notre lancée tout au long du cycle de publication de la version 7.x. Nous prévoyons de déployer le système en trois étapes .
La première étape, bien entamée en 2019, consistait à jeter les bases. Elle était centrée sur la scalabilité de la gestion des tâches et de la planification, sur les contrats de l'alerting et des actions, ainsi que sur les API.
Nous passons maintenant à la deuxième étape, qui va permettre d'intégrer différents cas d'utilisation au système d'alerting, aux niveaux de l'API et de la bibliothèque. Cette étape comprend également la conception et le développement d'une interface utilisateur dans Kibana (qui viendra soutenir la compréhension de la signification des alertes), puis sa validation avec des cas d'utilisation spécifiques (comme le monitoring, la disponibilité ou SIEM, par exemple).
La troisième étape viendra étendre le thème de "l'omniprésence de l'alerting", ainsi que celui de "la détection et de l'action". Elle permettra à l'utilisateur de définir des alertes dans tout Kibana, qu'il s'agisse d'alertes basées sur un modèle ou même d'alertes basées sur une expression, grâce à des méthodes telles que les expressions Canvas.
Notre objectif ? Proposer un système fidèle à notre vision de l'alerting dans la Suite Elastic :
- Omniprésence de l'alerting : Les alertes sont des éléments primordiaux, qui tiennent comptent des différents espaces de Kibana. Cela permet de segmenter la création et l'affichage des alertes entre les différents groupes, mais aussi d'assurer l'intégration ultracomplète de l'alerting dans des produits comme SIEM, Monitoring et Uptime, pour n'en citer que quelques-uns. L'alerting viendra compléter Watcher, mais ne le remplacera pas.
- Comprendre la signification des alertes : Outre ces intégrations, l'alerting pourra compter sur une interface utilisateur Kibana, qui permettra un affichage détaillé des types d'alertes. Il proposera aussi des outils de corrélation, pour une compréhension plus fine de l'historique des alertes.
- Détection et action : Les API et les plug-ins sont conçus pour accepter n'importe quel mécanisme de détection ou d'action, à partir du moment où ils sont exprimés en JavaScript sur le serveur Kibana. Nous vous laissons imaginer les détections et les actions innovantes qui fleuriront dans Kibana grâce à des produits comme SIEM ou nos solutions d'observabilité.