PRoblème avec les statistiques

whistler · 2011-07-07 09:49:41

Bonjour,

Je rencontre un soucis avec les statistiques par tickets.
En effet, je me retrouve avec des temps de résolution négatifs :

Yannick Coupe 956 957 (100%) 4 (0%) 962 (101%) 0 0 - 8 Jour(s) 15 Heure(s) 26 Min(s) - 8 Jour(s) 5 Heure(s) 48 Min(s) 45 Min(s) 30 Jour(s) 7 Min(s)

Ce qui comme vous vous en doutez fausse totalement toutes les statistiques de temps de résolution.
En générant un graphique d'après ces statistiques, je vois que statistiques deviennent fausses autour de la mi-mai.
La version à l'époque était 0.74 et nous sommes désormais en 0.80.

Comme je ne sais pas comment sont calculés les temps de résolutions / temps de résolution moyen, je suis bien incapable de voir d'ou vient le problème.

Merci de bien vouloir m'aider dans la résolution de problème génant.

perating Systems : Windows NT GLPI 6.1 build 7601 (Unknow Windows version Standard Edition Service Pack 1) i586
PHP 5.3.5 (Core, PDO, PDO_ODBC, Phar, Reflection, SPL, SQLite, SimpleXML, apache2handler, bcmath, bz2, calendar, com_dotnet,
ctype, date, dom, ereg, exif, filter, ftp, gd, gettext, hash, iconv, imap, json, ldap, libxml, mbstring, mcrypt, mhash, ming,
mysql, mysqli, mysqlnd, odbc, pcre, pdo_mysql, pdo_sqlite, session, soap, sockets, sqlite3, standard, tokenizer, wddx, xml,
xmlreader, xmlrpc, xmlwriter, zip, zlib)
Setup: memory_limit="128M" max_execution_time="30" safe_mode="" session.save_handler="files" post_max_size="8M"
upload_max_filesize="128M"
Software: Apache/2.2.17 (Win32) mod_ssl/2.2.17 OpenSSL/0.9.8o PHP/5.3.4 mod_perl/2.0.4 Perl/v5.10.1 (Apache/2.2.17 (Win32)
mod_ssl/2.2.17 OpenSSL/0.9.8o PHP/5.3.4 mod_perl/2.0.4 Perl/v5.10.1 Server at 172.17.0.30 Port 80)
Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0
MySQL: 5.5.8 (root@localhost/glpidb)

../config : OK
../files : OK
../files/_dumps : OK
../files/_sessions : OK
../files/_cron : OK
../files/_cache/ : OK
../files/_graphs : OK
../files/_log : OK

MoYo · 2011-07-07 12:54:33

Temps de resolution = date resolution - date ouverture

whistler · 2011-07-07 16:45:30

Merci de jeter un oeil à mon soucis.

D'accord mais comment le résultat peut il être négatif ?

MoYo · 2011-07-07 16:51:16

je ne vois pas trop.
Dans vos tables les éléments solvedate sont bien définis pour vos tickets ?

whistler · 2011-07-07 17:09:48

Bien vu !
Il y a un petit paquet (29) de "solvedate" = NULL
Il en va de même pour certains tickets Clos.
Aucune idée de la manière dont ils se sont retrouvés comme cela ...

Je pense que l'on peut attribuer à "solvedate" et closedate la date de dernière modification sans soucis ?

MoYo · 2011-07-07 17:13:28

oui c'est ce qui a du être fait automatique lors de la migration

whistler · 2011-07-07 17:24:54

J'ai modifié mes 29 entrées mais il semble que cela n'altère en rien mon soucis de temps de résolution négatif ...
Une autre idée ?

MoYo · 2011-07-07 20:14:02

solvedate est bien supérieur à date pour vos tickets ?

whistler · 2011-07-08 09:58:58

Je pense pouvoir affirmer que oui, toujours strictement supérieur ou égal.

Le problème ne pourrait il pas venir de la méthode de calcul ?

MoYo · 2011-07-08 10:05:48

avez vous le moyen de m'envoyer votre BDD pour tests ? car je n'arrive pas du tout à reproduire le problème.

whistler · 2011-07-08 10:10:30

La base au total fait dans les 50Mo je crois ... l'envoi risque d'être un peu technique.

Petite info : j'ai des date de dernière modification en 2011 sur des tickets clos en 2009. Cela peut il jouer ?

EDIT : Après compression, elle fait à peine 6Mo. Puis - je avoir votre adresse mail ?

Last edited by whistler (2011-07-08 10:16:03)

MoYo · 2011-07-08 10:14:17

la date de modification n'est pas prise en compte dans les stats.

Si vous souhaitez m'indiquer comment récupérer la DB mon adresse :
moyo {AT} indepnet {DOT} net

whistler · 2011-07-08 10:19:56

J'ai des soucis avec l'export, pour gagner du temps puis je vous envoyer uniquement la table contenant les tickets ?

MoYo · 2011-07-08 10:21:33

même avec un mysql dump vous avez des problèmes ?
Que les tickets ca peut être compliqué de mon côté mais dans un premier temps on peut faire comme ca effectivement

whistler · 2011-07-08 10:30:24

Je vous envoie la table à l'instant.
Si j'ai trop de soucis avec la base au complet je vous enverrai un dump du début de semaine mais il ne comportera pas les modifications faites sur les solvdate - date en négatif.

whistler · 2011-07-08 11:44:49

Problème résolu, merci beaucoup

MoYo · 2011-07-08 12:03:29

merci à vous, nous avons pu détecter des causes possibles de calculs des stats.
Nous avons ajouté des sécurités supplémentaires.

Forum GLPI-Project

Announcement

#1 2011-07-07 09:49:41

PRoblème avec les statistiques

#2 2011-07-07 12:54:33

Re: PRoblème avec les statistiques

#3 2011-07-07 16:45:30

Re: PRoblème avec les statistiques

#4 2011-07-07 16:51:16

Re: PRoblème avec les statistiques

#5 2011-07-07 17:09:48

Re: PRoblème avec les statistiques

#6 2011-07-07 17:13:28

Re: PRoblème avec les statistiques

#7 2011-07-07 17:24:54

Re: PRoblème avec les statistiques

#8 2011-07-07 20:14:02

Re: PRoblème avec les statistiques

#9 2011-07-08 09:58:58

Re: PRoblème avec les statistiques

#10 2011-07-08 10:05:48

Re: PRoblème avec les statistiques

#11 2011-07-08 10:10:30

Re: PRoblème avec les statistiques

#12 2011-07-08 10:14:17

Re: PRoblème avec les statistiques

#13 2011-07-08 10:19:56

Re: PRoblème avec les statistiques

#14 2011-07-08 10:21:33

Re: PRoblème avec les statistiques

#15 2011-07-08 10:30:24

Re: PRoblème avec les statistiques

#16 2011-07-08 11:44:49

Re: PRoblème avec les statistiques

#17 2011-07-08 12:03:29

Re: PRoblème avec les statistiques

Board footer