Un moyen simple d'identifier algorithmiquement un pic d'erreurs enregistrées

Nous avons besoin d'un système d'alerte précoce. Je traite avec un serveur qui est connu pour avoir des problèmes de performances sous charge. Les erreurs sont enregistrées dans une base de données avec un horodatage. Il existe certaines étapes d'intervention manuelle qui peuvent être prises pour réduire la charge du serveur, mais uniquement si quelqu'un est au courant du problème ...

Étant donné un ensemble de fois où des erreurs se sont produites, comment puis-je identifier le début d'un pic d'erreurs (en temps réel)? Nous pouvons calculer périodiquement ou à chaque occurrence d'erreur.

Nous ne sommes pas préoccupés par les erreurs occasionnelles, mais nous n'avons pas de seuil spécifique. Je pourrais simplement informer quelqu'un chaque fois que nous obtenons, disons, trois erreurs en cinq minutes, mais je suis sûr qu'il y a une meilleure façon ...

Je voudrais pouvoir ajuster la sensibilité de l'algorithme en fonction des commentaires des administrateurs système. Pour l'instant, ils aimeraient qu'il soit assez sensible, même si nous savons que nous pouvons nous attendre à des faux positifs.

Je ne suis pas un statisticien, ce qui est sûr, c'est évident, et l'implémentation doit être relativement simple avec nos outils existants: SQL Server et ASP JScript à l'ancienne. Je ne cherche pas de réponse dans le code, mais si cela nécessite un logiciel supplémentaire, cela ne fonctionnera probablement pas pour nous (bien que je me réjouisse des solutions pratiques mais idéales en tant que commentaire, pour ma propre curiosité).

Cela fait 5 mois que vous avez posé cette question, et j'espère que vous avez trouvé quelque chose. Je vais faire quelques suggestions différentes ici, en espérant que vous les trouverez utiles dans d'autres scénarios.

Pour votre cas d'utilisation, je ne pense pas que vous ayez besoin d'examiner les algorithmes de détection des pics.

Alors voici: Commençons par une image des erreurs survenant sur une chronologie:

Ce que vous voulez, c'est un indicateur numérique, une "mesure" de la vitesse à laquelle les erreurs se produisent. Et cette mesure doit pouvoir faire l'objet d'un seuillage - vos administrateurs système doivent pouvoir définir des limites qui contrôlent avec quelle sensibilité les erreurs se transforment en avertissements.

Mesure 1

Vous avez mentionné les «pointes», la façon la plus simple d'obtenir une pointe est de tracer un histogramme toutes les 20 minutes:

Vos administrateurs système définiraient la sensibilité en fonction des hauteurs des barres, c'est-à-dire le plus d'erreurs tolérables dans un intervalle de 20 minutes.

(À ce stade, vous vous demandez peut-être si cette durée de fenêtre de 20 minutes ne peut pas être ajustée. C'est possible, et vous pouvez penser à la longueur de la fenêtre comme définissant le mot ensemble dans les erreurs de phrase qui apparaissent ensemble .)

Quel est le problème avec cette méthode pour votre scénario particulier? Eh bien, votre variable est un entier, probablement inférieur à 3. Vous ne définiriez pas votre seuil à 1, car cela signifie simplement que "chaque erreur est un avertissement" qui ne nécessite pas d'algorithme. Vos choix de seuil vont donc être de 2 et 3. Cela ne donne pas à vos administrateurs système beaucoup de contrôle fin.

Mesure 2

Au lieu de compter les erreurs dans une fenêtre de temps, gardez une trace du nombre de minutes entre les erreurs actuelles et les dernières. Lorsque cette valeur devient trop petite, cela signifie que vos erreurs deviennent trop fréquentes et vous devez déclencher un avertissement.

Vos administrateurs système fixeront probablement la limite à 10 (c'est-à-dire si les erreurs se produisent à moins de 10 minutes d'intervalle, c'est un problème) ou à 20 minutes. Peut-être 30 minutes pour un système moins critique.

Cette mesure offre plus de flexibilité. Contrairement à la mesure 1, pour laquelle il était possible de travailler avec un petit ensemble de valeurs, vous disposez désormais d'une mesure qui fournit de bonnes valeurs de 20 à 30. Vos administrateurs système auront donc plus de possibilités de réglage fin.

Conseils amicaux

Il existe une autre façon d'aborder ce problème. Plutôt que de regarder les fréquences d'erreur, il peut être possible de prévoir les erreurs avant qu'elles ne se produisent.

Vous avez mentionné que ce problème se produisait sur un seul serveur, qui est connu pour avoir des problèmes de performances. Vous pouvez surveiller certains indicateurs de performance clés sur cette machine et les faire vous dire quand une erreur va se produire. Plus précisément, vous examineriez l'utilisation du processeur, l'utilisation de la mémoire et les indicateurs de performance clés relatifs aux E / S de disque. Si votre utilisation du processeur dépasse 80%, le système va ralentir.

(Je sais que vous avez dit que vous ne vouliez installer aucun logiciel, et il est vrai que vous pourriez le faire en utilisant PerfMon. Mais il existe des outils gratuits qui le feront pour vous, comme Nagios et Zenoss .)

Et pour les personnes qui sont venues ici dans l'espoir de trouver quelque chose sur la détection des pics dans une série chronologique:

Détection des pics dans une série chronologique

La chose la plus simple à faire est de calculer une moyenne mobile de vos valeurs d'entrée. Si votre série est , alors vous calculez une moyenne mobile après chaque observation comme:$x_1, x_2,...$

$M_k = (1 - \alpha) M_{k-1} + \alpha x_k$

où le déterminerait combien de poids donnerait la dernière valeur de .$\alpha$$x_k$

Si votre nouvelle valeur s'est trop éloignée de la moyenne mobile, par exemple

$\frac{x_k - M_k}{M_k} > 20\%$

vous lancez un avertissement.

Les moyennes mobiles sont agréables lorsque vous travaillez avec des données en temps réel. Mais supposons que vous ayez déjà un tas de données dans une table, et que vous vouliez simplement exécuter des requêtes SQL sur elle pour trouver les pics.

Je voudrais suggerer:

1. Calculez la valeur moyenne de votre série chronologique
2. Calculer l' écart type $\sigma$
3. Isolez les valeurs supérieures de plus de la moyenne (vous devrez peut-être ajuster ce facteur de "2")$2\sigma$

Plus de trucs amusants sur les séries chronologiques

1. De nombreuses séries chronologiques réelles présentent un comportement cyclique. Il existe un modèle appelé ARIMA qui vous aide à extraire ces cycles de votre série chronologique.

2. Moyennes mobiles qui tiennent compte du comportement cyclique: Holt et Winters

+1 pour le contrôle statistique des processus, il y a quelques informations utiles ici sur la détection d'étape .

Pour SPC, il n'est pas trop difficile d'écrire une implémentation des Western Electric Rules ou des Nelson Rules .

Créez simplement un USP dans le serveur SQL qui parcourra un ensemble de données et exécutera une commande ping sur chaque point par rapport aux règles en utilisant ses points voisins. Peut-être résumer le nombre d'erreurs par heure (en fonction de vos besoins).

Ce type se rapporte à une question que j'ai postée sur Stack Overflow il y a quelque temps (je viens de rédiger une réponse rapide si cela aide): Graphiques de contrôle des processus statistiques dans SQL Server 2008 R2

Une recherche d' algorithmes de détection en ligne serait un début.

Plus d'informations sur stackoverflow: Peak Dection du signal mesuré

Une implémentation en python d'une routine de détection de pic naïve se trouve sur github

Vous voudrez peut-être examiner le contrôle statistique des processus. Ou surveillance des séries chronologiques. Il y a des tonnes de travail dans ce sens, et la réponse optimale dépend probablement beaucoup de ce que vous faites exactement (avez-vous besoin de filtrer les saisonnalités annuelles ou hebdomadaires de la charge avant de détecter des anomalies, etc.).