La Fibre

Télécom => Réseau => reseau IPv6 => Discussion démarrée par: vivien le 23 avril 2015 à 15:45:23

Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: vivien le 23 avril 2015 à 15:45:23
L'objectif est de publier un baromètre pour voir la progression de l'IPv6 en France.

Je cherche un outil, capable, à  partir de log apache2, de sortir des statistiques IPv6 par AS :

Idéalement un classement du top 100 des AS qui sont le plus présentes dans les log avec :

- Le numéro de l'AS (et en bonus son pays et son nom)
- Le pourcentage de hits (ligne dans le fichier de log Apache2) en IPv6 (sur le nombre total de lignes)
- Le classement global (IPv4 + IPv6) et terne de nombre de hits
- Le classement IPv4 only en terme de hits
- Le classement IPv6 only en terme de hits
- Le nombre de hits IPv4 sur la période
- Le nombre de hits IPv6 sur la période

Un plug-in existe pour http://www.awstats.org ?
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: kgersen le 23 avril 2015 à 19:37:14
A défaut de trouver un outil existant tu peux toujours envoyer les logs dans une 'fusion table' ou un tableur Drive et faire des graphes ensuite.

L'ajout de données peut s'automatiser avec un simple 'import (https://developers.google.com/fusiontables/docs/v2/using#ImportingRowsIntoTables)' quotidien par exemple (c'est un simple HTTP POST) ou par un script Apps Script (https://developers.google.com/apps-script/) (qu'il faudra utiliser de toute facon pour obtenir l'AS probablement via un webservice comme http://www.telize.com/geoip/ par exemple).
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: vivien le 24 avril 2015 à 17:39:48
Pour chaque ligne du fichier log apache, il faut :

On se retrouve ensuite avec un tableau de ce type :

AS            hits IPv4            taille IPv4          hits IPv6        taille IPv6
32151502186504564305654
1232211021865045630457654

En important ce tableau dans un tableur on peut facilement faire des stats en opérant un tri et des ratios entre IPv4 et IPv6.

Comment fait traceroute avec l'option -A pour récupérer l'AS ?
Vu le nombre de ligne à traiter, je vais me faire jeter, si j'utilise un apps-script qui fait des appels en ligne.

Chez geoip c'est :
string geoip_asnum_by_name ( string $hostname )Exemple :
<?php
$asn 
geoip_asnum_by_name('www.example.com');

if (
$asn) {
    echo 
'The ASN is: ' $asn;
}
?>
Cela donne : "The ASN is: AS15133 EdgeCast Networks, Inc"

La base de donnée est en local avec GeoIP : C'est téléchargeable ici pour la base des AS: http://dev.maxmind.com/geoip/legacy/geolite/

Voici les données sources pour les AS pour chaque IP :
ARIN : ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest
RIPE :   ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest
AFRINIC : ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest
APNIC : ftp://ftp.apnic.net/pub/stats/apnic/delegated-apnic-latest
LACNIC : ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest



Pour la table, vu que le nombre de ligne est restreint (une ligne par AS, donc je pense qu'on a un maximum de 10000 AS différents), je ne pense pas qu'utiliser MySQL soit intéressant.

Installation : apt install libgeoip1 libgeoip-dev php-geoip geoipupdate
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: vivien le 24 avril 2015 à 18:12:20
Dans la base du RIPE, ce n'est pas l'AS qui apparaît : l'AS5410 de Bouygues Telecom n’apparaît pas pour la plage 5.48.0.0 :
ripencc|FR|ipv4|5.48.0.0|262144|20120522|allocated
% Information related to '5.48.0.0/14AS5410'

route:          5.48.0.0/14
descr:          BOUYGUES Telecom ISP Wireline
origin:         AS5410
mnt-by:         BYTEL-MNT
source:         RIPE # Filtered

Autre exemple avec Free : l'AS12322 n’apparaît pas
ripencc|FR|ipv4|212.27.32.0|8192|19990306|allocated
% Information related to '212.27.32.0/19AS12322'

route:          212.27.32.0/19
descr:          ProXad network / Free SA
descr:          Paris, France
origin:         AS12322
mnt-by:         PROXAD-MNT
source:         RIPE # Filtered
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: buddy le 24 avril 2015 à 18:17:50
Un plug-in existe pour http://www.awstats.org ?[/size]

oui. Mais il ne fait pas grand chose ... juste le reverse.. aucune stat ipv4/ipv6. (c'est "possible" que je sois passé à côté n'étant pas fan de awstats ...)

@vivien, c'est pour faire des stats sur lafibre.info ? ce n'est pas ipv4 only pour le moment ?

Tien pour info, google vient toujours crawler en ipv4 sur les sites pourtant ipv6 ready.
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: jack le 24 avril 2015 à 18:21:58
Ce devrait être faisable avec un bout de awk + gnuplot.
Pour chopper le mapping ip2as: utilise dig (http://www.team-cymru.org/IP-ASN-mapping.html#dns)
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: kgersen le 24 avril 2015 à 18:30:23
D'apres sa man page, traceroute fait un lookup sur whois.ra.net ( ca serait donc une requete whois standard).
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: kgersen le 24 avril 2015 à 18:54:22
  • Si l'AS existe déjà dans la table, incrèmenter les compteur "hits" de +1 et "taille" de la taille téléchargée coté IPv6 si IPv6 ou coté IPv4 sir IPv4

Tu n'as pas besoin de calculer les hits et la taille par AS. Les requêtes et les graphes feront ca tout seuls.

Le plus simple est d'injecter tout le log dans une table (tableau, fusion, BdD, etc) et d'ajouter des colonnes (des champs) a cette table: un champ pour l'AS et un qui dit IPv4 ou IPv6 (TypeIP). Ensuite tu peux faire des graphes et requêtes sur cette table: genre hits par AS au cours du dernier mois glissant par exemple, etc. Tu peux aussi ajouter les champs FAI, Pays et Ville par exemple.

Le truc ensuite est d'avoir un processus (script, programme, etc) qui met a jour la table quotidiennement et qui "rempli" les champs supplèmentaires (AS,TypeIP, etc) des nouvelles entrées.


Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: vivien le 24 avril 2015 à 19:05:03
kgersen, cela ne fonctionne pas pour les gros logs.

1 million de ligne, c'est vite arrivé avec Apache. (Calc et Excel limitent les tableau a 1 million de ligne et ont bien du mal à gérer des tableau de cette taille)
Uniquement lafibre.info doit dépasser le million de ligne de log par jour => https://lafibre.info/stats/
(une page est composé de plusieurs éléments, chaque image c'est une ligne)

C'est pour cela que je verrais bien un tableau avec une ligne par AS. Cela permet de faire des stats mensuelles ou trimestrielles avec un tableau de moins de 10 000 lignes.

@vivien, c'est pour faire des stats sur lafibre.info ? ce n'est pas ipv4 only pour le moment ?
LaFibre.info va passer en IPv6 dans quelques mois.

Je ne comprend pas que Google ne fasse pas des stats plus détaillées que ça : https://www.google.fr/ipv6/statistics.html

On parle beaucoup d'IPv6, mais qui l'active par défaut ? J'avais compris que K-Net l'activait par défaut, mais vu le trafic très faible, je suppose que cela a été stoppé. Il se dit que Free active l'IPv6 par défaut, mais sur les nouvelles lignes Free que j'ai regardé, ce n'était pas le cas. Quel pourcentage d'IPv6 chez SFR ? Orange ? Bouygues ? Ce script permettrait de répondre aux questions, avec le biais de la population du site visité, qui n'est pas forcèment représentative.

(https://lafibre.info/images/ipv6/201504_stats_ipv6_google_1.png)

J’imagine au vu des problème de l'IPv6 en France, que c'était lié à la saturation des chemins empruntés pour avoir Youtube en IPv6, avant que Free mette en place des GGC.

(https://lafibre.info/images/ipv6/201504_stats_ipv6_google_2.png)

IPv6 ne deviens plus négligeable au niveau mondial !

(https://lafibre.info/images/ipv6/201504_stats_ipv6_google_3.png)
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: jack le 24 avril 2015 à 19:11:45
Citer
J'avais compris que K-Net l'activait par défaut, mais vu le trafic très faible, je suppose que cela a été stoppé.
C'est activé sur la moitié du parc uniquement.
Nos routeurs ont un défaut, le mauvais switch chinois s'en moquent, les bons commutateurs français beaucoup moins.

Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: buddy le 24 avril 2015 à 19:21:38
On parle beaucoup d'IPv6, mais qui l'active par défaut ? J'avais compris que K-Net l'activait par défaut, mais vu le trafic très faible, je suppose que cela a été stoppé. Il se dit que Free active l'IPv6 par défaut, mais sur les nouvelles lignes Free que j'ai regardé, ce n'était pas le cas. Quel pourcentage d'IPv6 chez SFR ? Orange ? Bouygues ? Ce script permettrait de répondre aux questions, avec le biais de la population du site visité, qui n'est pas forcèment représentative.

j'avais entendu dire que Free l'activer par défaut sur les FB révolution > dec 2011...
Pour la part d'ipv6 chez Orange et Bouygues, 0 % non ?
Chez SFR, çà augmentera peut être avec le firmware 3.5 qui gèrera l'ipv6 natif ... (car en FTTH se retrouvait limité à moins de 100 MBits (je n'ai plus le chiffre exact) à cause de l'ipv6 çà fait "mal".)

Si jamais tu trouves quelque chose qui marche bien, je veux bien "traiter" des logs aussi avec.
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: kgersen le 24 avril 2015 à 19:57:52
Je pensais a une ligne par "IP+user agent" et par jour donc je ne pensais a des millions de lignes (grosso modo ca fait une ligne par user par jour). Effectivement si t'as pas l'usage de l'IP et l'UA tu peux cumuler par AS.

Citer
"c'est pour cela que je verrais bien un tableau avec une ligne par AS"

Je ne capte pas la logique la. Si t'as trop de lignes pour que ca rentre dans un tableau, tu peux réduire a une ligne par AS par jour mais il faut bien garder une dimension 'temporelle' pour faire des stats avec du temps (mois, année, etc). Tu n'a pas plus d'une dizaine d'AS différents par jour non ou aller au pire 100? ca fait 100 lignes/jour ca passe en tableur sinon tu passes en fusion ou SQL.

T'as juste besoin de sommer les hits et les volumes par AS et par jour donc.

Sinon passes en SQL si tu veux tout garder (tout = cumul journalisé par IP/UA donc c'est pas des millions non plus), quitte à  faire des tables cumulatives en plus, style par AS/jour et AS/mois si les requetes sont trop lentes (mais ca c'est de l'opti qu'on fait plus tard).



Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: vivien le 24 avril 2015 à 20:06:52
La dimension temporelle, le mois ou le trimestre me semble suffisant, donc géré manuellement (je fais chaque mois ou chaque trimestre et je rentre les résultats des AS représentatives dans un autre tableau.

Il y aura forcèment de très nombreux AS avec seulement quelques hits (des petits réseaux, des réseaux étrangers)
C'est pour cela que je pense qu'il y aura plus de 1000 AS.

Maintenant, c'est vrai qu'il serai possible de géré dans l'outil les dates, mais le ration IPv4 vs IPv6 évolue lentement et on a intérêt à agréger pas mal de données pour ne pas avoir trop de fluctuations.
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: corrector le 24 avril 2015 à 22:40:56
Je pense que des données journalières seraient intéressantes.
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: kgersen le 24 avril 2015 à 22:42:10
tu devrais regarder du coté de http://piwik.org/ aussi. Il peut importer des logs et il y a un module IPv6 : https://plugins.piwik.org/IPv6Usage
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: vivien le 25 avril 2015 à 09:06:43
Piwik nécessite de mettre un tracker sur le site web et cela ne fonctionne que sur les site web (un truc de plus à charger).

Pour avoir des stats sur les fichiers téléchargés sur testdebit.info, avec les SpeedTest ou les miroirs que j'héberge, les analyses se font obligatoirement au niveau des log apache2.
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: buddy le 25 avril 2015 à 09:57:31
tu peux bien "donner" à manger à piwik des logs apache.
http://piwik.org/docs/log-analytics-tool-how-to/#how-to-run-the-log-file-analysis-script-with-default-options

Je ne l'ai pas testé encore, je testerai éventuellement si j'arrive à obtenir des résultats corrects sur des fichiers 100 % statiques.
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: kgersen le 25 avril 2015 à 16:42:24
oui je mentionnais Pikwik en mode import et pas en mode tracker. Reste a voir si c'est praticable.
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: vivien le 28 avril 2015 à 19:02:24
Récupération d'un AS en perl :

use Geo::IP;
my $gi = Geo::IP->open( "/usr/local/share/GeoIP/GeoIPASNum.dat", GEOIP_STANDARD );
print $gi->name_by_addr('24.24.24.24') || '';

use Geo::IP;
my $gi = Geo::IP->open( "/usr/local/share/GeoIP/GeoIPASNumv6.dat", GEOIP_STANDARD );
print $gi->name_by_addr_v6('::ffff:24.24.24.24') || '';

Pour distinguer une IPv4 d'une IPv6, la bonne solution c'est bien :
- rechercher si ":" est présent au minimum trois fois dans le champ => Si positif, c'est une IPv6
- rechercher si "." est présent trois fois dans le champ => Si positif, c'est une IPv4
- autre cas : loger l'IP dans un fichier log (il devrait être vide)

Du code en perl tout fait qui distingue une IPv4 d'une IPv6 avec un port optionnel, ce qui est inutile pour des logs apache : (en IPv6, on rajoute le port de cette façon : [2605:2700:0:3::4713:93e3]:80 )

sub parse_ip {
my $str = shift;
$str =~ s/^\s*//;
$str =~ s/\s*$//;
 
if ($str =~ s/^((?:\d+\.)+\d+)(?::(\d+))?$//) {
return 'v4', parse_v4($1, $2);
}
 
my ($ip, $port);
if ($str =~ /^\[(.*?)\]:(\d+)$/) {
$port = $2;
$ip = parse_v6($1);
} else {
$port = -1;
$ip = parse_v6($str);
}
 
return unless $ip;
return 'v6', $ip, $port;
}

Source : http://rosettacode.org/wiki/Parse_an_IP_Address
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: kgersen le 21 décembre 2015 à 19:33:08
J'ai un peu repensé a ton probleme: tu peux utiliser la stack ELK (Elasticsearch, Logstash, Kibana) c'est suffisamment puissant pour ce que tu veux faire.

Le principe et les produits requis:

Logstash: https://www.elastic.co/products/logstash . C'est un outil de collecte, analyse et stockage de journaux (logs) (un ETL dans le jargon: Extract-Transform-Load). En entrée il sait géré et connait plein de types de format de logs comme syslog ou les logs d'apache2. Puis il analyse les données et les met dans un format commun via des filtres programmables. On peut ensuite exporter les données vers ce qu'on veut pour stockage ou traitement. Notamment ici on va exporter vers Elasticsearch.

Elasticsearch: https://www.elastic.co/products/elasticsearch . C'est moteur de recherche distribué basé sur Apache Lucene. Il va stocker les données et permettre tout sorte de requêtes, recherches et analyses dessus.

Kibana:  https://www.elastic.co/products/kibana . C'est la partie graphique/visuelle d'Elasticsearch qui permet d'afficher presque tout ce qu'on souhaite. Ca permet de faire des Dashboards temp réel par exemple ou des graphes/rapports analytiques.

Bases Maxmind Geolite: http://dev.maxmind.com/geoip/legacy/geolite/ . Ce sont les bases de geoloc gratuites de Maxmind. il y a 3 bases: pays, ville et AS. chacune avec sa version IPv4 et IPv6. donc 6 bases en tout. Elles sont mises a jour tout les mois.

Les trucs a lire pour comprendre puis faire soi-meme (histoire de s'occuper pendant les vacances...):

A. https://www.linode.com/docs/databases/elasticsearch/webserver-logs-with-elk-stack
C'est une simple demo de comment installer et configurer ELK pour visualiser des infos sur les logs d'Apache. Y'a la tout ce qu'il faut pour commencer et faire une config simple. Si on ne veut pas 'saloper' une machine réelle on peut faire tourner tout dans Docker. On trouve des compositions Docker toute prêtes comme : https://github.com/deviantony/docker-elk  par exemple.

B. https://www.digitalocean.com/community/tutorials/how-to-map-user-location-with-geoip-and-elk-elasticsearch-logstash-and-kibana
Un exemple pour ajouter un traitement dans Logstash pour utiliser une base Geolite pour obtenir les coordonnées geo des IP présentes dans les logs d'un serveur web NGinx. Suivi d'une visualisation en carto dans Kibana.

Le boulot à  faire (ou trouver sur le Net si quelqu'un a déjà fait ca mais j'ai rien trouvé):
- adapter B (nginx) a A (Apache) puis modifier le tout pour obtenir l'AS avec les 2 bases qui vont bien (IPv4 et IPv6)
- en option: adapter A pour injecter aussi les anciens logs archivés (opération à  faire qu'une fois).
- créer les stats voulues dans Kibana.

Ca ne me semble pas bien compliqué à  faire et ca m’intéresse pour un autre projet. Mais pendant les 2 semaines qui viennent la je n'ai vraiment pas le temps de me pencher la dessus plus que ca.
Donc si Vivien ou quelqu'un d'autre se sent d'attaque pour tenter le coup , a vous de jouer. Sinon je verrais en janvier pour bricoler un truc.
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: vivien le 21 décembre 2015 à 20:48:18
Cela me semble complexe, mais c'est vrai que l'outil est sympa pour visualiser les infos.

Les points qui me semble importants c'est le fait d'afficher :
- le nombre de hits (nombre d'éléments chargés) par FAI (donc AS)
- le pourcentage IPv6 vs IPv4 par FAI
- classement des FAI par taux de pénétration IPv6
- Taille (en Go / To) envoyé par FAI par jour (important pour testdebit.info, pas pour lafibre.info)

En bonus, en exploitant le user agent :
- répartition des différents systèmes d'exploitations
- répartition des différents navigateurs utilisés
- répartition des différents navigateur utilisés par système d'exploitation
- répartition fixe / mobile

Et en super bonus des croisements :
- pourcentage d'IPv6 par système d’exploitation
- pourcentage d'IPv6 par navigateur

Idéalement il serait possible de visualiser des graphes montrant l’évolution sur plusieurs années.

Par contre si les données ne sont pas agrégées, cela va être très lent et prendre beaucoup de place.
Il ne me semble de supprimer les logs après post-traitement (post-traitement qui incrèmente des compteurs permettant de faire les calculs).

J'imagine trois tables produites quotidiennement (on va dire que la 3ème dimension sera le temps)
- Table FAI avec 5 colonnes : AS ; hits IPv4 ; hits IPv6 ; taille IPv4 ; taille IPv6
- Table os / navigateur avec 5 colonnes : mixte OS/Navigateur ; hits IPv4 ; hits IPv6 ; taille IPv4 ; taille IPv6
- Table géolocalisation avec 5 colonnes : Pays ; hits IPv4 ; hits IPv6 ; taille IPv4 ; taille IPv6

Chaque ligne de log va incrèmenter des compteurs dans les 3 tables.
Il est impossible d'utiliser les 3 tables simultanèment : savoir quel est le navigateur le plus utilisé chez Free n'est pas possible.

Ce que j’appelle mixte OS/Navigateur, c'est une donnée avec les couples OS / Navigateurs les plus utilisés. La liste n'est pas longue si on propose "autre" :
- Windows 10 / server 2016 + Chrome
- Windows 10 / server 2016 + Firefox
- Windows 10 / server 2016 + Edge
- Windows 10 / server 2016 + Internet Explorer
- Windows 10 / server 2016 + autre navigateur
- Windows 8.x / server 2012 + Chrome
- Windows 8.x / server 2012 + Firefox
- Windows 8.x / server 2012 + Internet Explorer
- Windows 8.x / server 2012 + autre navigateur
- Windows 7 / server 2008 R2 + Chrome
- Windows 7 / server 2008 R2 + Firefox
- Windows 7 / server 2008 R2 + Internet Explorer
- Windows 7 / server 2008 R2 + autre navigateur
- Vista / server 2008 + Chrome
- Vista / server 2008 + Firefox
- Vista / server 2008 + Internet Explorer
- Vista / server 2008 + autre navigateur
- vieux Windows + Chrome
- vieux Windows + Firefox
- vieux Windows + Internet Explorer
- vieux Windows + autre navigateur
- MacOS X + Safari
- MacOS X + Chrome
- MacOS X + Firefox
- MacOS X + autre navigateur
- Linux + Chrome
- Linux + Firefox
- Linux + wget
- Linux + curl
- Linux + autre navigateur
- Android + Chrome
- Android + Firefox
- Android + autre navigateur
- iOS + Safari
- iOS + Firefox
- iOS + autre navigateur
- Autre système d'exploitation + Chrome
- Autre système d'exploitation + Firefox
- Autre système d'exploitation + Safari
- Autre système d'exploitation + Internet explorer
- Autre système d'exploitation + Edge
- Autre système d'exploitation + autre navigateur
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: kgersen le 21 décembre 2015 à 22:25:51
Par contre si les données ne sont pas agrégées, cela va être très lent et prendre beaucoup de place.

oui et non. agrégées des données c'est perdre de l'information quelque part.
Elasticsearch est fait pour ca. C'est très costeau, distribuable sur plusieurs machines et on peut créer des aggregations au besoin.
Beaucoup de gros du web utilisent Elasticsearch, notamment Deezer, Soundcloud, Github, Docker, etc et meme Orange et Netflix.

Il faut bien voir qu'on est dans le monde "NoSQL" ou avoir des gros volumes est très courant. C'est fait pour ca.

L'important , a mon avis, est d'avoir tes logs, augmentés des info geoloc, dans Elasticsearch. A partir de la tu verra comment optimiser éventuellement les données si la performance des requêtes pose un probleme.

Mais je ne mettrais pas la charrue avec les bœufs comme on dit.
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: vivien le 22 décembre 2015 à 13:53:56
Même sans parler de performance, avec 300 Mo par jour, cela fait 9 Go par mois, 216 Go pour deux ans d'historique.
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: corrector le 22 décembre 2015 à 15:37:00
Sous quel format?
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: vivien le 22 décembre 2015 à 15:59:27
format texte (oui, cela se compresse)
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: corrector le 22 décembre 2015 à 16:22:29
Sans même parler d'algorithme coûteux de compression, ou même de Huffman :

En format texte, une IPv4 de 32 bits (4 octets) prend jusqu'à 16 octets incluant le délimiteur : surcoût facteur 4.

Le user-agent "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36" (qui occupe 110 octets) correspond à une entropie de 12.89 bits (<4 octets) d'après https://panopticlick.eff.org/

C'est pas juste que cela se compresse, cela se compresse beaucoup, beaucoup.

Donc avant de détruire de l'information, tu peux envisager d'optimiser la représentation sans pour autant rendre le format complexe : tu peux représenter certains champs comme des nombres et non comme du texte. En plus l'adresse IPv* est bien à la base un nombre et se manipule avec des opérateurs binaires.
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: corrector le 22 décembre 2015 à 17:22:19
Il manque une information cruciale dans ce log : inscrit ou anonyme?
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: kgersen le 26 décembre 2015 à 22:36:20
regardes ca aussi: http://www.logswan.org/

C'est fait par le type qui avait fait http://www.telize.com/, (l'équivalent d'un ip.lafibre.info), service qui a eu trop de succès (150 millions de hit par jour). Pour analyser ses logs il a fait logswan.

Lecture intéressante pourquoi il a arrêté de fournir gratuitement le service: http://www.cambus.net/adventures-in-running-a-free-public-api/
(en espérant que ca ne t'arrive pas avec ip.lafibre.info  ;D).
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: vivien le 28 janvier 2016 à 13:53:55
Pour les stats du site, je pense qu'il faut créer un outil qui analyse chaque ligne de log Apache2 et qui utilise les informations
- adresse IP (deux choses m'intéressent : l'AS (le réseau à et le fait qu'elle soit IPv4 ou IPv6)
- port de retour TCP (je suis intéressé pour savoir si il est cohérent avec le user-agent ou non. Un % important de port non cohérent indique la présence de CG-Nat)
- Taille de téléchargement
- User-agent

Pour remplir une table My-SQL comme ceci :

Système   Navigateur   IPTaille   Nb hits total   Nb hits port retour anormal
TotalTotalIPv4   
TotalTotalIPv6
TotalMozillaIPv4
TotalMozillaIPv6
TotalGoogleIPv4
TotalGoogleIPv6
TotalMicrosoftIPv4
TotalMicrosoftIPv6
TotalAutreIPv4
TotalAutreIPv6
Windows10TotalIPv4
Windows10TotalIPv6
Windows legacyTotalIPv4
Windows legacyTotalIPv6
Windows XPTotalIPv4
Windows XPTotalIPv6
Windows PhoneTotalIPv4
Windows PhoneTotalIPv6
MacOS XTotalIPv4
MacOS XTotalIPv6
MacOS X legacyTotalIPv4
MacOS X legacyTotalIPv6
Linux 64bitsTotalIPv4
Linux 64bitsTotalIPv6
Linux 32bitsTotalIPv4
Linux 32bitsTotalIPv6
AndroidTotalIPv4
AndroidTotalIPv6
Android legacyTotalIPv4
Android legacyTotalIPv6
iOSTotalIPv4
iOSTotalIPv6
TVTotalIPv4
TVTotalIPv6
RSSTotalIPv4
RSSTotalIPv6
ProgrammesTotalIPv4
ProgrammesTotalIPv6
RobotsTotalIPv4
RobotsTotalIPv6
AutreTotalIPv4
AutreTotalIPv6
Windows10MozillaIPv4
Windows10MozillaIPv6
Windows10GoogleIPv4
Windows10GoogleIPv6
Windows10MicrosoftIPv4
Windows10MicrosoftIPv6
Windows10AutreIPv4
Windows10AutreIPv6
Windows legacyMozillaIPv4
Windows legacyMozillaIPv6
Windows legacyGoogleIPv4
Windows legacyGoogleIPv6
Windows legacyMicrosoftIPv4
Windows legacyMicrosoftIPv6
Windows legacyAutreIPv4
Windows legacyAutreIPv6
Windows XPMozillaIPv4
Windows XPMozillaIPv6
Windows XPGoogleIPv4
Windows XPGoogleIPv6
Windows XPMicrosoftIPv4
Windows XPMicrosoftIPv6
Windows XPAutreIPv4
Windows XPAutreIPv6
MacOS XMozillaIPv4
MacOS XMozillaIPv6
MacOS XGoogleIPv4
MacOS XGoogleIPv6
MacOS XAppleIPv4
MacOS XAppleIPv6
MacOS XAutreIPv4
MacOS XAutreIPv6
MacOS X legacyMozillaIPv4
MacOS X legacyMozillaIPv6
MacOS X legacyGoogleIPv4
MacOS X legacyGoogleIPv6
MacOS X legacyAppleIPv4
MacOS X legacyAppleIPv6
MacOS X legacyAutreIPv4
MacOS X legacyAutreIPv6
Linux 64bitsMozillaIPv4
Linux 64bitsMozillaIPv6
Linux 64bitsGoogleIPv4
Linux 64bitsGoogleIPv6
Linux 64bitsAutreIPv4
Linux 64bitsAutreIPv6
Linux 32bitsMozillaIPv4
Linux 32bitsMozillaIPv6
Linux 32bitsGoogleIPv4
Linux 32bitsGoogleIPv6
Linux 32bitsAutreIPv4
Linux 32bitsAutreIPv6
AndroidMozillaIPv4
AndroidMozillaIPv6
AndroidGoogleIPv4
AndroidGoogleIPv6
AndroidAutreIPv4
AndroidAutreIPv6
Android legacyMozillaIPv4
Android legacyMozillaIPv6
Android legacyGoogleIPv4
Android legacyGoogleIPv6
Android legacyAutreIPv4
Android legacyAutreIPv6
AutreMozillaIPv4
AutreMozillaIPv6
AutreGoogleIPv4
AutreGoogleIPv6
AutreAutreIPv4
AutreAutreIPv6


Une seconde table My-SQL serait remplie, avec une ligne par AS puis toutes les informations de cette table sous forme de colonnes (plusieurs centaines de colonnes)

En fait si la ligne correspondant à l'AS xxxxx existe déjà, les colonnes correspondantes sont incrèmentée d'un hit ou de la taille.

Si la ligne correspondant à l'AS xxxx n'existe pas, il faut la créer.

Je me demande si cela ne pourrait pas faire l'objet d'un projet en école d'ingénieur (je m'adresse a ceux qui sont étudiants) vu que ce type de logiciel d'analyse de log ne semble pas exister.

Ensuite la seconde étape serait de faire une interface qui va chercher les informations et calcul le % d'IPv4 vs IPv6 , le % port anormal, le % d'utilisation des différents système d’exploitation et navigateurs.

Je pense qu'il faudrait créer tous les mois une nouvelle table pour les informations pas AS afin de rajouter une dimension temporelle et faire des courbes d'évolutions.
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: e-TE le 28 janvier 2016 à 14:54:18
pas besoin d'une nouvelle table, mais juste une colonne de plus au format date...

et soit tu définis que tu faiss une colonne avec une date à la précision du jour (et pour tous les hits de la même journée tu updates cette ligne), soit heure, soit semaine, ou mois...


ou alors une seule colonne date avec le timestamp du hit, et tu faiss l’agrégation de donnée dans un deuxième temps... (plus de ligne en table, moins de traitement à l'insertion, mais plus de taff à la restitution)
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: vivien le 28 janvier 2016 à 15:36:42
Je pense qu'un granularité au mois ou au trimestre est la bonne granularité.

Pour chaque AS (un AS = une ligne) j'ai des centaines de colonnes quand je compile les hits / taille / ipv4 / IPv6 avec tous les navigateurs et systèmes d’exploitations.

donc pour rajouter la date, il me semble plus simple de re-créer une table, ce qui évite aussi les tables qui s'alourdissent et qui sont de plus en plus longue a manipuler. (quand une table fait plusieurs centaines de Mo, chaque opération prend une éternités)

C'est aussi sur le fait que je vais avoir des centaines d'AS avec très peu de hits qui seront différents chaque mois (des réseaux étrangers) donc j'ai pensé plus pertinent d'avoir une table par mois (ou trimestre) au lieu d'avoir une table pour chaque couple  hits / taille / ipv4 / IPv6 / OS / navigateur

J'ai faux ?
Titre: Analyser la progression d'IPv6 via les logs Apache2
Posté par: e-TE le 28 janvier 2016 à 15:44:40
bah faut voir les données, mais on peut imaginer une clé sur numero d'AS / date (yyyyMM) / OS / type IP (les champs sur lesquels tu veux l'unicité) et les autres tu les incrèmentes aux besoins...

niveau perf ca devrait pas poser trop de soucis si tu as bien une clé composé / index dessus