show 308 results

Blog entries

  • Logilab à Pas Sage en Seine 2018 #PSES2018

    2018/07/13 by Arthur Lutz

    Nous étions présents à la conférence Pas Sage en Seine 2018 pour assister aux conférences, mais aussi pour participer à la tenue du stand de l'APRIL dont Logilab est adhérente depuis sa création pour soutenir la promotion et la défense du logiciel libre.

    Voici un court retour sous forme de notes sur les conférences auxquelles nous avons assistées et qui sont en lien avec notre activité.

    Le programme était chargé, retrouvez le sur https://programme.passageenseine.fr/

    Conf zero knowledge webapp

    M4Dz de AlwaysData a effectué avec brio cette présentation.

    Article wikipedia sur Zero Knowledge Proof

    Dans le navigateur, certains acronymes sont familiers, d'autres un peu moins :

    • CORS
    • CSP
    • SRI - protection (signature de code)
    • Referrer-Policy
    • Key-storage (WebCrypto, File-API), éviter LocalStorage (peut être purgé comme du cache)

    WebAssembly (ASMjs) - prévient la lecture du code executé et rend l'extraction de données complexe. Plus difficile d'exploiter un binaire que un bout de JS où on peut se brancher où on veut (ralentir les attaques).

    Pendant les questions/réponses il a été question de "chiffrement homomorphique" comme potentielle solution pour les questions d'indexations de contenus chiffrés.

    Applications où y des choses similaires, dont certaines que nous utilisons à Logilab :

    Full-remote : guide de survie en environnement distant

    Encore une fois M4Dz de AlwaysData.

    Beaucoup de contenu, mais j'ai bien aimé les notions suivantes :

    • mentorat
    • mini-projet interne pour débuter - pour aller discuter avec les anciens
    • manifesto : exemple http://remoteonly.org (auquel on peut apporter quelques critiques)
    • exemple de remote le matin, pour ensuite être dans les bureaux l'après-midi
    • environnement sonore (à personnaliser)

    Pas mal de propos sur les canaux de communication:

    • tchat / voice / video / documents
    • exemple de github qui a enlevé le mail de ses outils de communication
    • virtualopenspace, notamment pour pause café (voir notre inspiration peopledoc et gitlab)
    • abuser des status type jabber/xmpp - pour communiquer sur notre disponibilité (notamment quand on a besoin d'être concentré et pas interrompu)

    Le temps de trajet peut être utile pour décompreser ou se mettre en condition pour travailler. Selon M4Dz, c'est reproductible en teletravail (aller faire un tour du quartier).

    Exemples de rencontres informelles entre télétravailleurs : nextcloud a une équipe très distribuée, ils vont travailler chez les uns les autres (ceux qui ont des affinités entre eux).

    À voir absolument si votre entreprise a une reflexion sur le télétravail, même en partiel (comme c'est le cas à Logilab).

    Jour 2

    Privacy by design

    Notes :

    • GRDP check list
    • déléger l'authentification à l'autres par exemple : openid
    • libjs : jwcrypto, jsencrypt, js-nacl (lien dans les slides pour la liste complète)
    • séparer les consentements (par service tiers)
    • exemple de nextcloud qui fait bien les choses https://nextcloud.com/privacy/
    • matomo (ex-piwik) fait bien les choses en terme de respect de vie privée
    • documentation des api (swagger et apiary pour supprimer les données

    Sur la pseudonimiation (pour publier des jeux de données), M4Dz nous a parlé de Differential privacy

    Crypto quantique

    Comment commencer à tester la crypto quantique en pratique :

    Conclusion, il est urgent d'attendre, on a plein d'autres problèmes de securité à résoudre.

    GRPDBookClub

    Super retour d'experience sur comment aborder un texte de loi ou une reglementation compliquée de manière collective.

    La RGPD pour les noobs

    Excellent complément de la conférence précédente sur le RGPD.

    Fin

    Voilà. Plein d'autres conférences méritent d'être visionnées sur https://video.passageenseine.fr/ (peertube, what else?), bravo pour la captation, la diffusion en direct et la mise à disposition des contenus.

    Bravo à tout l'équipe d'organisation pour les contenus riches et variés de cette édition du festival. Et merci à toutes les personnes avec qui j'ai pu échanger en marge des conférences

    Si vous êtes arrivés jusqu'ici, déjà bravo, et puis sachez que Logilab recrute, rejoignez nous pour travailler sur ces questions.

    Logilab recrute!


  • Experiment to safely refactor your code in Python

    2018/05/05 by Nicolas Chauvat

    "Will my refactoring break my code ?" is the question the developer asks himself because he is not sure the tests cover all the cases. He should wonder, because tests that cover all the cases would be costly to write, run and maintain. Hence, most of the time, small decisions are made day after day to test this and not that. After some time, you could consider that in a sense, the implementation has become the specification and the rest of the code expects it not to change.

    Enters Scientist, by GitHub, that inspired a Python port named Laboratory.

    Let us assume you want to add a cache to a function that reads data from a database. The function would be named read_from_db, it would take an int as parameter item_id and return a dict with attributes of the items and their values.

    You could experiment with the new version of this function like so:

    import laboratory
    
    def read_from_db_with_cache(item_id):
        data = {}
        # some implementation with a cache
        return data
    
    @laboratory.Experiment.decorator(candidate=read_from_db_with_cache)
    def read_from_db(item_id):
         data = {}
         #  fetch data from db
         return data
    

    When you run the above code, calling read_from_db returns its result as usual, but thanks to laboratory, a call to read_from_db_with_cache is made and its execution time and result are compared with the first one. These measurements are logged to a file or sent to your metrics solution for you to compare and study.

    In other words, things continue to work as usual as you keep the original function, but at the same time you experiment with its candidate replacement to make sure switching will not break or slow things down.

    I like the idea ! Thank you for Scientist and Laboratory that are both available under the MIT license.

    https://www.logilab.org/file/10128331/raw/chemistry.png

  • Reduce docker image size with multi-stage builds

    2018/03/21 by Philippe Pepiot

    At logilab we use more and more docker both for test and production purposes.

    For a CubicWeb application I had to write a Dockerfile that does a pip install and compiles javascript code using npm.

    The first version of the Dockerfile was:

    FROM debian:stretch
    RUN apt-get update && apt-get -y install \
        wget gnupg ca-certificates apt-transport-https \
        python-pip python-all-dev libgecode-dev g++
    RUN echo "deb https://deb.nodesource.com/node_9.x stretch main" > /etc/apt/sources.list.d/nodesource.list
    RUN wget https://deb.nodesource.com/gpgkey/nodesource.gpg.key -O - | apt-key add -
    RUN apt-get update && apt-get -y install nodejs
    COPY . /sources
    RUN pip install /sources
    RUN cd /sources/frontend && npm install && npm run build && \
        mv /sources/frontend/bundles /app/bundles/
    # ...
    

    The resulting image size was about 1.3GB which cause issues while uploading it to registries and with the required disk space on production servers.

    So I looked how to reduce this image size. What is important to know about Dockerfile is that each operation result in a new docker layer, so removing useless files at the end will not reduce the image size.

    https://www.logilab.org/file/10128049/raw/docker-multi-stage.png

    The first change was to use debian:stretch-slim as base image instead of debian:stretch, this reduced the image size by 18MB.

    Also by default apt-get would pull a lot of extra optional packages which are "Suggestions" or "Recommends". We can simply disable it globally using:

    RUN echo 'APT::Install-Recommends "0";' >> /etc/apt/apt.conf && \
        echo 'APT::Install-Suggests "0";' >> /etc/apt/apt.conf
    

    This reduced the image size by 166MB.

    Then I looked at the content of the image and see a lot of space used in /root/.pip/cache. By default pip build and cache python packages (as wheels), this can be disabled by adding --no-cache to pip install calls. This reduced the image size by 26MB.

    In the image we also have a full nodejs build toolchain which is useless after the bundles are generated. The old workaround is to install nodejs, build files, remove useless build artifacts (node_modules) and uninstall nodejs in a single RUN operation, but this result in a ugly Dockerfile and will not be an optimal use of the layer cache. Instead we can setup a multi stage build

    The idea behind multi-stage builds is be able to build multiple images within a single Dockerfile (only the latest is tagged) and to copy files from one image to another within the same build using COPY --from= (also we can use a base image in the FROM clause).

    Let's extract the javascript building in a single image:

    FROM debian:stretch-slim as base
    RUN echo 'APT::Install-Recommends "0";' >> /etc/apt/apt.conf && \
        echo 'APT::Install-Suggests "0";' >> /etc/apt/apt.conf
    
    FROM base as node-builder
    RUN apt-get update && apt-get -y install \
        wget gnupg ca-certificates apt-transport-https \
    RUN echo "deb https://deb.nodesource.com/node_9.x stretch main" > /etc/apt/sources.list.d/nodesource.list
    RUN wget https://deb.nodesource.com/gpgkey/nodesource.gpg.key -O - | apt-key add -
    RUN apt-get update && apt-get -y install nodejs
    COPY . /sources
    RUN cd /sources/frontend && npm install && npm run build
    
    FROM base
    RUN apt-get update && apt-get -y install python-pip python-all-dev libgecode-dev g++
    RUN pip install --no-cache /sources
    COPY --from=node-builder /sources/frontend/bundles /app/bundles
    

    This reduced the image size by 252MB

    The Gecode build toolchain is required to build rql with gecode extension (which is a lot faster that native python), my next idea was to build rql as a wheel inside a staging image, so the resulting image would only need the gecode library:

    FROM debian:stretch-slim as base
    RUN echo 'APT::Install-Recommends "0";' >> /etc/apt/apt.conf && \
        echo 'APT::Install-Suggests "0";' >> /etc/apt/apt.conf
    
    FROM base as node-builder
    RUN apt-get update && apt-get -y install \
        wget gnupg ca-certificates apt-transport-https \
    RUN echo "deb https://deb.nodesource.com/node_9.x stretch main" > /etc/apt/sources.list.d/nodesource.list
    RUN wget https://deb.nodesource.com/gpgkey/nodesource.gpg.key -O - | apt-key add -
    RUN apt-get update && apt-get -y install nodejs
    COPY . /sources
    RUN cd /sources/frontend && npm install && npm run build
    
    FROM base as wheel-builder
    RUN apt-get update && apt-get -y install python-pip python-all-dev libgecode-dev g++ python-wheel
    RUN pip wheel --no-cache-dir --no-deps --wheel-dir /wheels rql
    
    FROM base
    RUN apt-get update && apt-get -y install python-pip
    COPY --from=wheel-builder /wheels /wheels
    RUN pip install --no-cache --find-links /wheels /sources
    # a test to be sure that rql is built with gecode extension
    RUN python -c 'import rql.rql_solve'
    COPY --from=node-builder /sources/frontend/bundles /app/bundles
    

    This reduced the image size by 297MB.

    So the final image size goes from 1.3GB to 300MB which is more suitable to use in a production environment.

    Unfortunately I didn't find a way to copy packages from a staging image, install it and remove the package in a single docker layer, a possible workaround is to use an intermediate http server.

    The next step could be to build a Debian package inside a staging image, so the build process would be separated from the Dockerfile and we could provide Debian packages along with the docker image.

    Another approach could be to use Alpine as base image instead of Debian.


  • Meetup Nantes Monitoring - janvier 2018 - netdata & sensu

    2018/01/31 by Arthur Lutz

    En janvier, j'ai fait une présentation interactive sur :

    Le tout en mode "on monte une infra en live/atelier"...

    Les diapos de la présentation sont sur : http://slides.logilab.fr/2018/meetup_monitoring_sensu_netdata.pdf

    https://www.logilab.org/file/10127892/raw/Screenshot%20from%202018-01-31%2009-45-04.png

    Pour les prochaines rencontres, inscrivez vous sur la page du meetup


  • Mon 2ème Hackathon BnF

    2017/11/30 by Adrien Di Mascio

    Et de 2 !

    La semaine reprend tranquillement après ma participation au 2ème hackathon organisé par la BnF. Tout comme pour le premier, il faut tout d'abord saluer une organisation exemplaire de la BnF et la grande disponibilité de ses membres représentés par l'équipe jaune pour aider l'équipe rouge des participants. Quelqu'un a fait une allusion à une célèbre émission de télévision où le dernier survivant gagne… je ne sais pas dans notre cas si c'est un rouge ou un jaune.

    Lors de ce hackathon, j'ai eu le plaisir de retrouver certains de mes coéquipiers de l'an dernier et même si nous étions cette année sur des projets différents, je leur ai donné un petit coup de main sur des requêtes SPARQL dans data.bnf.fr. Peut-être que je pourrai demander un T-shirt mi-jaune mi-rouge l'an prochain ?

    Pour ma part, j'ai intégré, avec une personne des Archives Nationales, une équipe pré-existante (des personnes de la société PMB et de Radio-France qui travaillent déjà ensemble dans le cadre du projet doremus) qui avait envisagé le projet suivant : partir d'une programmation de concert à la Philharmonie de Paris ou Radio-France et découvrir l'environnement des œuvres musicales qui y sont jouées. Pour y aboutir, nous avons choisi de :

    • récupérer la programmation des concerts depuis doremus,
    • récupérer les liens des œuvres de ce concert vers les notices de la BnF lorsqu'ils existent,
    • récupérer des informations sur data.bnf.fr (date de création, style, compositeur, chorégraphe, etc.)
    • récupérer des extraits sonores de Gallica en utilisant l'API SRU,
    • récupérer les extraits des journaux de Gallica qui parlent de l'œuvre en question au moment de sa création,
    • récupérer des informations de wikipedia et IMSLP en utilisant les alignements fournis par data.bnf.fr,
    • récupérer un extrait sonore et une jaquette de CD en utilisant l'API de Deezer à partir des EAN ou des codes ISRC récupérés de data.bnf.fr ou des alignements sur MusicBrainz

    Finalement, rien de trop compliqué pour que ça rentre dans un hackathon de 24h mais comme l'an dernier, tout est allé très vite entre les différents points d'étape devant le jury, les requêtes qui ne marchent pas comme on voudrait, la fatigue et la difficulté à bien répartir le travail entre tous les membres de l'équipe…

    Félicitations à MusiViz qui a remporté l'adhésion du jury ! Je suis pour ma part très heureux des échanges que j'ai eus avec mes coéquipiers et du résultat auquel nous avons abouti. Nous avons plein d'idées pour continuer le projet dont le code se trouve désormais sur http://framagit.org/adimascio/auconcert et un démonstrateur temporaire ici.

    Yapuka continuer…

  • Mercurial Sprint 4.4

    2017/10/10 by Denis Laxalde
    Mercurial

    In late September, I participated on behalf of Logilab to the Mercurial 4.4 sprint that held at Facebook Dublin. It was the opportunity to meet developers of the project, follow active topics and forthcoming plans for Mercurial. Here, I'm essentially summarizing the main points that held my attention.

    Amongst three days of sprint, the first two mostly dedicated to discussions and the last one to writing code. Overall, the organization was pretty smooth thanks to Facebook guys doing a fair amount of preparation. Amongst an attendance of 25 community members, some companies had a significant presence: noticeably Facebook had 10 employees and Google 5, the rest consisting of either unaffiliated people and single-person representing their affiliation. No woman, unfortunately, and a vast majority of people with English as a native or dominant usage language.

    The sprint started by with short talks presenting the state of the Mercurial project. Noticeably, in the state of the community talk, it was recalled that the project governance now holds on the steering committee while some things are still not completely formalized (in particular, the project does not have a code of conduct yet). Quite surprisingly, the committee made no explicit mention of the recurring tensions in the project which recently lead to a banishment of a major contributor.

    Facebook, Google, Mozilla and Unity then presented by turns the state of Mercurial usages in their organization. Both Facebook and Google have a significant set of tools around hg, most of them either aiming at making the user experience more smooth with respect to performance problems coming from their monorepos or towards GUI tools. Other than that, it's interesting to note most of these corporate users have now integrated evolve on the user side, either as is or with a convenience wrapper layer.

    After that, followed several "vision statements" presentations combined with breakout sessions. (Just presenting a partial selection.)

    The first statement was about streamlining the style of the code base: that one was fairly consensual as most people agreed upon the fact that something has to be done in this respect; it was finally decided (on the second day) to adopt a PEP-like process. Let's see how things evolve!

    Second, Boris Feld and I talked about the development of the evolve extension and the ongoing task about moving it into Mercurial core (slides). We talked about new usages and workflows around the changeset evolution concept and the topics concept. Despite the recent tensions on this technical topic in the community, we tried to feel positive and reaffirmed that the whole community has interests in moving evolve into core. On the same track, in another vision statement, Facebook presented their restack workflow (sort of evolve for "simple" cases) and suggested to push this into core: this is encouraging as it means that evolve-like workflows tend to get mainstream.

    Rust

    Another interesting vision statement was about using Rust in Mercurial. Most people agreed that Mercurial would benefit from porting its native C code in Rust, essentially for security reasons and hopefully to gain a bit of performance and maintainability. More radical ideas were also proposed such as making the hg executable a Rust program (thus embedding a Python interpreter along with its standard library) or reimplementing commands in Rust (which would pose problems with respect to the Python extension system). Later on, Facebook presented mononoke, a promising Mercurial server implemented in Rust that is expected to scale better with respect to high committing rates.

    Back to a community subject, we discussed about code review and related tooling. It was first recalled that the project would benefit from more reviewers, including people without a committer status. Then the discussion essentially focused on the Phabricator experiment that started in July. Introduction of a web-based review tool in Mercurial was arguably a surprise for the community at large since many reviewers and long-time contributors have always expressed a clear preference over email-based review. This experiment is apparently meant to lower the contribution barrier so it's nice to see the project moving forward on this topic and attempt to favor diversity by contribution. On the other hand, the choice of Phabricator was quite controversial. From the beginning (see replies to the announcement email linked above), several people expressed concerns (about notifications notably) and some reviewers also complained about the increase of review load and loss of efficiency induced by the new system. A survey recently addressed to the whole community apparently (no official report yet at the time of this writing) confirms that most employees from Facebook or Google seem pretty happy with the experiment while other community members generally dislike it. Despite that, it was decided to keep the "experiment" going while trying to improve the notification system (better threading support, more diff context, subscription-based notification, etc.). That may work, but there's a risk of community split as non-corporate members might feel left aside. Overall, adopting a consensus-based decision model on such important aspects would be beneficial.

    Yet another interesting discussion took place around branching models. Noticeably, Facebook and Google people presented their recommended (internal) workflow respectively based on remotenames and local bookmarks while Pulkit Goyal presented the current state to the topics extension and associated workflows. Bridging the gap between all these approaches would be nice and it seems that a first step would be to agree upon the definition of a stack of changesets to define a current line of work. In particular, both the topics extension and the show command have their own definition, which should be aligned.

    (Comments on reddit.)


  • Better code archaeology with Mercurial

    2017/09/21 by Denis Laxalde

    For about a year, Logilab has been involved in Mercurial development in the framework of a Mozilla Open Source Support (MOSS) program. Mercurial is a foundational technology for Mozilla, as the VCS used for the development of Firefox. As the main protagonist of the program, I'd first like to mention this has been a very nice experience for me, both from the social and technical perspectives. I've learned a lot and hope to continue working on this nice piece of software.

    The general objective of the program was to improve "code archaeology" workflows, especially when using hgweb (the web UI for Mercurial). Outcomes of program spread from versions 4.1 to 4.4 of Mercurial and I'm going to present the main (new) features in this post.

    Better navigation in "blame/annotate" view (hgweb)

    The first feature concerns the "annotate" view in hgweb; the idea was to improve navigation along "blamed" revisions, a process that is often tedious and involves a lot of clicks in the web UI (not easier from the CLI, for that matter). Basically, we added an hover box on the left side of file content displaying more context on blamed revision along with a couple of links to make navigation easier (links to parent changesets, diff and changeset views). See below for an example about mercurial.error module (to try it at https://www.mercurial-scm.org/repo/hg/annotate/4.3/mercurial/error.py)

    The hover box in annotate view in hgweb.

    Followlines

    While this wasn't exactly in the initial scope of the program, the most interesting result of my work is arguably the introduction of the "followlines" feature set. The idea is to build upon the log command instead of annotate to make it easier to follow changes across revisions and the new thing is to make this possible by filtering changes only affecting a block of lines in a particular file.

    The first component introduced a revset, named followlines, which accepts at least two arguments a file path and a line range written as fromline:toline (following Python slice syntax). For instance, say we are interested the history of LookupError class in mercurial/error.py module which, at tag 4.3, lives between line 43 and 59, we'll use the revset as follows:

    $ hg log -r 'followlines(mercurial/error.py, 43:59)'
    changeset:   7633:08cabecfa8a8
    user:        Matt Mackall <mpm@selenic.com>
    date:        Sun Jan 11 22:48:28 2009 -0600
    summary:     errors: move revlog errors
    
    changeset:   24038:10d02cd18604
    user:        Martin von Zweigbergk <martinvonz@google.com>
    date:        Wed Feb 04 13:57:35 2015 -0800
    summary:     error: store filename and message on LookupError for later
    
    changeset:   24137:dcfdfd63bde4
    user:        Siddharth Agarwal <sid0@fb.com>
    date:        Wed Feb 18 16:45:16 2015 -0800
    summary:     error.LookupError: rename 'message' property to something
    else
    
    changeset:   25945:147bd9e238a1
    user:        Gregory Szorc <gregory.szorc@gmail.com>
    date:        Sat Aug 08 19:09:09 2015 -0700
    summary:     error: use absolute_import
    
    changeset:   34016:6df193b5c437
    user:        Yuya Nishihara <yuya@tcha.org>
    date:        Thu Jun 01 22:43:24 2017 +0900
    summary:     py3: implement __bytes__() on most of our exception classes
    

    This only yielded changesets touching this class.

    This is not an exact science (because the algorithm works on diff hunks), but in many situations it gives interesting results way faster that with an iterative "annotate" process (in which one has to step from revision to revision and run annotate every times).

    The followlines() predicate accepts other arguments, in particular, descend which, in combination with the startrev, lets you walk the history of a block of lines in the descending direction of history. Below the detailed help (hg help revset.followlines) of this revset:

    $ hg help revsets.followlines
        "followlines(file, fromline:toline[, startrev=., descend=False])"
          Changesets modifying 'file' in line range ('fromline', 'toline').
    
          Line range corresponds to 'file' content at 'startrev' and should hence
          be consistent with file size. If startrev is not specified, working
          directory's parent is used.
    
          By default, ancestors of 'startrev' are returned. If 'descend' is True,
          descendants of 'startrev' are returned though renames are (currently)
          not followed in this direction.
    

    In hgweb

    The second milestone of the program was to port this followlines filtering feature into hgweb. This has been implemented as a line selection mechanism (using mouse) reachable from both the file and annotate views. There, you'll see a small green ± icon close to the line number. By clicking on this icon, you start the line selection process which can be completed by clicking on a similar icon on another line of the file.

    Starting a line selection for followlines in hgweb.

    After that, you'll see a box inviting you to follow the history of lines <selected range> , either in the ascending (older) or descending (newer) direction.

    Line selection completed for followlines in hgweb.

    Here clicking on the "newer" link, we get:

    Followlines result in hgweb.

    As you can notice, this gives a similar result as with the command line but it also displays the patch of each changeset. In these patch blocks, only the diff hunks affecting selected line range are displayed (sometimes with some extra context).

    What's next?

    At this point, the "followlines" feature is probably complete as far as hgweb is concerned. In the remainder of the MOSS program, I'd like to focus on a command-line interface producing a similar output as the one above in hgweb, i.e. filtering patches to only show followed lines. That would take the form of a --followlines/-L option to hg log command, e.g.:

    $ hg log -L mercurial/error.py,43:59 -p
    

    That's something I'd like to tackle at the upcoming Mercurial 4.4 sprint in Dublin!


  • Linkdump suite au Meetup Docker Nantes sur OpenShift

    2017/06/28 by Arthur Lutz

    La Poste nous a fait un retour d’expérience sur la mise en place et l'adoption de OpenShift ainsi que les pratiques associées.

    Affiche Docker Meetup - OpenShift

    À défaut de faire un compte rendu, voici (en vrac) quelques liens collectés pendant la présentation :

    Merci aux organisateurs et à Guillaume et Pascal pour leur présentation. Merci à Epitech pour l’accueil, et Seyos et Zenika pour le moment de convivialité après la présentation.


  • Logilab présent à pgDay Toulouse

    2017/06/16 by Philippe Pepiot

    Le 8 juin 2017 nous avons assisté à pgDay, le moment de rencontre et de conférences de la communauté PostgreSQL francophone, qui s'est déroulée au campus de Météo France à Toulouse.

    https://www.logilab.org/file/10126216/raw/logo_pgfr_sans_900_400x400.png

    Partitionement

    Gilles Darold nous a fait un tour d'horizon des solutions de partitionnement, de la méthode manuelle avec des triggers et d'héritage de table en passant par l'extension pg_partman jusqu'au partitionnement déclaratif de la future version 10 avec la syntaxe PARTITION OF

    Le partitionnement permet de gérer plus facilement la maintenance et les performances de tables avec beaucoup d'enregistrements.

    Transaction autonomes

    Le même Gilles Darold nous a parlé des transactions autonomes c'est-à-dire des transactions qui s'exécutent dans une transaction parente et qui peut être validée ou annulée indépendamment de celle-ci, ce qui peut être utile pour enregistrer des événements.

    PostgreSQL buffers

    Vik Fearing nous a expliqué le fonctionnement et l'interaction des différents tampons mémoire dans PostgreSQL.

    Les pages sont chargées du disque vers les shared_buffers, qui sont partagés par toutes les connexions, et ont un usageCount entre un et cinq qui est incrémenté à chaque fois qu'elle est accédée. Lorsqu'une nouvelle page doit être chargée, un mécanisme de clock-sweep boucle sur le cache et décrémente l'usageCount et quand il vaut zéro la page est remplacée par la nouvelle. Ainsi pour une page avec un usageCount à cinq, il faudra au moins cinq tours des shared_buffers par le clock-sweep avant quelle ne soit remplacée.

    En cas d'un accès à une grosse table pour ne pas vider tout le cache, PostgreSQL utilise un tampon circulaire (ou ring buffer) limité en taille pour cette table.

    Les tables temporaires utilisent un tampon dédié, le temp_buffers.

    Quand une page est modifiée, elle l'est d'abord dans les wal buffers qui sont écrits sur disque lors du commit par le processus wal writer.

    Le writer process parcoure les shared_buffers tout les bgwriter_delay (200ms) et écrit sur disque un certain nombre de pages qui ont été modifiées, ce nombre est contrôlé par les paramètres bgwriter_lru_maxpages et bgwriter_lru_multiplier.

    Des checkpoint s'exécutent aussi tout les checkpoint_timeout ou plus fréquemment quand la taille des wals dépasse la valeur du paramètre max_wal_size. Lors d'un checkpoint on cherche des pages à écrire (ou dirty pages) et on les trie pour éviter les écritures aléatoires sur le disque. Le paramètre checkpoint_completion_target permet d'étaler la vitesse d'écriture entre deux checkpoint. Idéalement on veut qu'ils se déclenchent toujours par timeout et que l'écriture soit la plus étalée pour avoir des performances de lecture et d'écriture constantes.

    Pour déboguer l'utilisation des buffers et les I/O disques il y a la table pg_stat_bgwriter, l'extension pg_buffercache, et le paramètre track_io_timing à utiliser avec EXPLAIN (ANALYZE, BUFFERS).

    Les pires pratiques PostgreSQL

    Thomas Reiss et Philippe Beaudoin nous ont présenté quelques unes des plus mauvaises pratiques avec PostgreSQL, notamment de celle répandue du manque ou d'excès d'index. À ce sujet Dalibo a développé l'outil PoWA qui analyse l'activité d'une base et fait des suggestions d'index. Attention aussi à la tentation de (trop) destructurer les données, PostgreSQL possède de nombreux types qui offrent une garantie forte sur la consistance des données et de nombreuses opérations dessus, par exemple les types ranges.

    La communauté des développeurs de PostgreSQL

    Daniel Vérité nous a fait un historique de Ingres puis Postgres, et enfin PostgreSQL avant de nous montrer des statistiques sur les commits et la liste de diffusion utilisée pour le développement de PostgreSQL

    Les éléphants mangent-ils des cubes ?

    Cédric Villemain nous a parlé des fonctionnalités de PostgreSQL pour des requêtes de type OLAP. L'implémentation de TABLESAMPLE qui permet de faire des requêtes sur un échantillon aléatoire d'une table. Le paramètre default_statistic_target et la nouvelle commande de la version 10 CREATE STATISTICS qui permettent d'obtenir de meilleurs statistiques sur la distribution de la table et donc d'avoir de meilleurs plans d'exécution.

    Aussi depuis la version 9.4, la syntaxe GROUP BY ROLLUP permet de faire des agrégats sur plusieurs GROUP BY dans une seule requête. Auparavant il fallait faire plusieurs UNION pour obtenir le même résultat.

    À noter aussi l'utilisation d'index BRIN et BLOOM.

    Comment fonctionne la recherche plein texte ?

    Adrien Nayrat nous a présenté les fonctions de recherche plein texte dans PostgreSQL et le moyen de l'améliorer en créant ses propres configurations et dictionnaires de mots, ainsi qu'à la rendre plus performante avec les index GIN et GIST.

    GeoDataScience

    Olivier Courtin nous a montré avec un exemple concret comment PostgreSQL pouvait être un environnement idéal pour la géomatique et le machine learning avec les extensions PostGIS, ainsi que plpythonu utilisé pour exécuter du code python directement sur le serveur PostgreSQL. L'extension dédiée crankshaft propose des API basées sur scipy et scikit-learn et peut être appelée via des procédures SQL.

    https://www.logilab.org/file/10126217/raw/freefall.gif

  • Compte rendu Nantes Monitoring mai 2017

    2017/05/11 by Arthur Lutz

    Voici un compte rendu du Meetup Nantes Monitoring de mai 2017

    Présente ta stack

    Léo / Matlo

    Léo de Matlo nous a présenté son utilisation de prometheus https://prometheus.io/ . Matlo a commencé à migrer vers une solution SASS (monitoring as a service) chez https://bleemeo.com/ (entreprise Toulousaine). La stack de bleemeo est décrite sur stackshare: https://stackshare.io/bleemeo/bleemeo. L'agent de bleemeo est publié en logiciel libre https://github.com/bleemeo/bleemeo-agent et repose sur telegraf https://github.com/influxdata/telegraf . Bleemeo semble utiliser MQTT-SSL pour remonter les métriques permettant ainsi un usage raisonnable des connexions réseau (cf diagramme https://bleemeo.com/features/).

    https://bleemeo.com/images/bleemeo_agent.png

    Emeric / OasisWork

    Emeric de OasisWork nous a présenté leur utilisation de sensu https://sensuapp.org/ qui permet d'avoir une architecture en mode "push". La configuration se fait par "rôles" coté serveur, simplifiant la configuration des agents. Des plugins sont utilisables pour les checks https://sensuapp.org/plugins et Oasiswork a contribué à ces plugins (https://github.com/oasiswork/sensu-community-plugins/) et en a écrit en python (habituellement c'est en ruby principalement). Sensu a la particularité d'utiliser dans son architecture RabbitMQ pour le transport https://sensuapp.org/docs/latest/overview/architecture.html. Pour la visualisation l'interface web libre de sensu est utilisée : uchiwa.

    https://uchiwa.io/img/browser.png

    Arthur / Logilab

    J'ai fait un bref exposé de nos briques de supervision/monitoring à Logilab. Du munin, du shinken, du statsd, graphite, graphite events, grafana, et en particulier la génération de ces configuration (coté serveur et client) par Saltstack. Nous utilisons aussi salt pour remonter des métriques en utilisant son bus de communication zmq à l'échelle de notre infrastructure, permettant par conséquent de re-développer des équivalents de smokeping et weathermap avec salt, carbon, graphite et grafana. Pour plus de détails sur ce type d'architecture voir les épisodes précédents (, ici, et aussi, et là).

    https://www.logilab.org/file/10125980/raw/architecture.png

    Quels outils choisir pour son monitoring ?

    Exercice difficile, nous avons listé les produits connus par les participants puis un certain nombres de critères de choix, et puis nous avons rempli (partiellement) un tableau en discutant de chaque point.

    Produits

    • nagios
    • shinken
    • icinga
    • sensu
    • prometheus
    • ELK
    • packet beats
    • file beats
    • zabbix
    • centreon
    • check-mk
    • ganglia
    • statsd
    • graphite
    • influxdb
    • telegraf
    • cadvisor
    • graylog
    • rsyslog
    • splunk
    • thruk
    • collectd
    • metrics(java)
    • logentries
    • datadog
    • bleemeo
    • prtg
    • munin
    • smokeping
    • fluentd
    • dynatrace
    • OMD

    (liste non-exhaustive, forcément... )

    Critères

    • language
    • prix
    • age
    • maintenu
    • communauté
    • scalable
    • facilité de mise en place (pkgs, devops, etc.)
    • champs d'application
    • push / pull architecture
    • configuration - format
    • configuration - serveur/agent
    • open core
    • securité
    • IOT ready
    • modularité / plugins
    • interface utilisateur (UX, interface web, etc.)
    • alertes
    • developpement de sondes

    Début de tableau

    Bien evidemment, nous n'avons pas rempli la totalité du tableau, mais les échanges ont été riches d'enseignements. Voici un apercu (flou) du tableau élaboré collectivement.

    https://www.logilab.org/file/10125977/raw/2017-05-09%2021.16.15.jpg

    Fin

    En fin de meetup nous avons parlé des conférences devoxx publiés récemment https://www.youtube.com/channel/UCsVPQfo5RZErDL41LoWvk0A et des contenus sur le monitoring et l'aggrégation de logs, notamment le projet cerebro de voyage-sncf : https://github.com/voyages-sncf-technologies/cerebro


show 308 results