Je travaille actuellement sur un site Web qui a la fonctionnalité de connexion. J'ai besoin de suivre les activités de l'utilisateur comme l'heure de connexion-déconnexion, la durée totale de la navigation, l'adresse IP, l'emplacement, etc. Toutes ces données seront utilisées à des fins d'analyse et de sécurité.

Maintenant, il y a deux options (au moins je sais) pour enregistrer une telle énorme donnée soit dans la base de données ou dans les fichiers journaux.

Quelle est la bonne chose à faire pour enregistrer dans la base de données ou dans les journaux? .

Au cas où quelqu'un voudrait le savoir, j'utilise PHP comme langage de programmation et MySQL comme base de données et je n'ai aucune expérience en analyse de données.

0
WeAreRight 24 janv. 2017 à 12:30

4 réponses

Meilleure réponse

Mieux vaut aller avec DB car si vous voulez analyser ou trier les tentatives de connexion par IP, emplacement ..etc. vous pouvez facilement le faire avec les requêtes MySQL, mais lorsque vous vous connectez, vous devriez avoir un éditeur et rechercher quelque chose sera vraiment difficile. Je connecte personnellement la même fonctionnalité dans mon application.Voici un code pour obtenir les informations du navigateur et l'adresse IP.

<?php

function log_login_activity($loginEmail, $loginAuthType = '', $loginAttemptStatus = '', $error = '', $loginRedirect = '',$HeaderInfo = ''){
    $loginTime = time();
    $browserInfo = getBrowser();
    $browser = $browserInfo['name'].' '.$browserInfo['version'];
    $loginIP = isset($_SERVER['HTTP_X_FORWARDED_FOR']) ? $_SERVER['HTTP_X_FORWARDED_FOR'] : $_SERVER['REMOTE_ADDR'];
    $protocol = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off' || $_SERVER['SERVER_PORT'] == 443) ? "HTTPS" : "HTTP";
    $browserAgent = $browserInfo['userAgent'];
    DB::insert('?:login_logs',array('email' => $loginEmail, 'time' =>$loginTime, 'browserInfo' =>$browser, 'loginAuthType' =>$loginAuthType, 'IP' =>$loginIP, 'error' => $error, 'protocol' => $protocol, 'loginRedirect' => $loginRedirect, 'browser' => $browserAgent));
}
1
Thamaraiselvam 24 janv. 2017 à 09:47

Cela dépend définitivement de deux choses:
1. Montant des actions des utilisateurs.
2. Scénarios d'utilisation des données.
Par exemple, s'il y a 500000 nouveaux enregistrements quotidiens et que tout ce que vous voulez, c'est faire une analyse d'agrégation, vous pouvez enregistrer les données de journal sur HDFS et effectuer des analyses à l'aide d'Apache Hive ou d'Apache Spark.
Si la quantité de données est encore énorme et que vous souhaitez effectuer des analyses et que vous souhaitez en plus avoir la capacité de récupérer les enregistrements d'action en fonction de l'utilisateur et de l'horodatage, vous devez d'abord enregistrer les données dans une base de données clé-valeur (comme Apache Cassandra), puis effectuer des analyses à l'aide d'Apache Spark. Vous pouvez en savoir plus sur les scénarios Cassandra et Big Data ici (avertissement: je travaille dans cette entreprise).
S'il y a 2000 enregistrements par jour, il suffit de le mettre dans n'importe quelle base de données relationnelle et de faire une analyse sur place, et ce serait la meilleure solution.

1
S. Stas 20 avril 2017 à 10:07

Cela vaut la peine de revenir en arrière et d'analyser les exigences.

En règle générale, les utilisateurs professionnels doivent comprendre le comportement métier du site. Combien de personnes se sont connectées hier? Combien de temps ont-ils passé sur le site? Ont-ils acheté quelque chose?

La manière courante de répondre à cette exigence consiste à configurer un package d'analyse (par exemple, Google Analytics). Les packages d'analyse sont bons pour comprendre le comportement sur le site Web et peuvent être configurés facilement pour modifier les structures de rapport et d'analyse. Cependant, ils ne sont généralement pas très bons pour rapporter des actions individuelles, et leur rapport est basé sur le "comportement du Web" - vous devez traduire "cliqué sur le bouton Ajouter au panier" en concept commercial "acheté quelque chose".

Les utilisateurs du support client et la logique de l'application doivent comprendre le comportement spécifique des individus. Lorsque le support client reçoit un appel disant "Aide, je ne peux pas me connecter", il veut probablement savoir quand cet utilisateur s'est-il connecté pour la dernière fois? Si un module de logique d'application souhaite savoir si cet utilisateur est intéressé par le produit X, il doit savoir s'il a examiné les produits associés.

Ces données sont généralement incluses en tant que données relationnelles dans une base de données, car elles sont faciles à interroger. Cependant, il est difficile de modifier les modèles relationnels et les utilisateurs non techniques ne peuvent pas écrire de requêtes SQL, c'est donc beaucoup plus rigide.

Les utilisateurs techniques doivent comprendre l'état de santé de l'application et pouvoir enquêter sur les incidents.

Ces informations sont généralement stockées sous forme de fichiers journaux. Les fichiers journaux sont souvent énormes - un site Web modérément occupé créera des journaux Apache de plusieurs gigaoctets par jour - et ne peuvent être interrogés qu'à l'aide d'outils d'analyse de journaux dédiés; ceux-ci s'adressent aux utilisateurs techniques et non aux professionnels. Les fichiers journaux sont souvent conservés pendant une courte période (des semaines ou des mois) et tournés une fois par jour. Ainsi, pour répondre à la question «quand l'utilisateur x s'est-il connecté pour la dernière fois», il peut être nécessaire d'analyser l'équivalent d'un mois de fichiers journaux, et si vous supprimez les journaux après un mois, vous n'obtiendrez peut-être pas la bonne réponse. Cependant, les instructions de journal sont faciles à insérer dans le code, et la modification de la journalisation (par exemple en enregistrant uniquement les messages «d'erreur» et non de «débogage») est facile.

Donc, pour «analyse» (je suppose que c'est par les utilisateurs professionnels) - insérez dans une base de données ou utilisez l'analyse Web. Pour des «raisons de sécurité» (je suppose que c'est pour l'analyse des incidents par les utilisateurs techniques) - les fichiers journaux.

1
Neville Kuyt 20 avril 2017 à 10:31

Je pense que DB est le bon choix ici. C'est beaucoup plus puissant et flexible. Sinon, vous vous retrouverez avec (plusieurs?) Fichiers volumineux et sans signification.

0
MarcinSte_ 24 janv. 2017 à 09:44