Cet article est une rapide introduction à Loki. Ce projet est soutenu par Grafana et a pour but de centraliser des journaux d’activités (serveurs ou conteneurs).

La source principale d’inspiration de Loki vient de Prometheus, avec l’idée de l’appliquer à la gestion des logs, le but étant de disposer du même mécanisme :

• utilisation d’étiquettes (labels) pour le stockage des données ;
• réclamer très peu de ressources pour son exécution.

Dans ce qui va suivre, nous allons revenir sur le principe de fonctionnement de Prometheus et donner quelques exemples d’utilisation dans le cadre d’un déploiement sous Kubernetes.

Par le passé, j’ai été un grand utilisateur de Nagios et ses différents forks. J’avais pour habitude de le coupler avec un PNP4Nagios pour obtenir de jolies courbes sur les métriques remontées par mes greffons de surveillance. J’ai également commencé à utiliser l’outil Beats d’Elastic.

Pour diverses raisons, j’ai arrêté d’utiliser ces outils, pour passer sur une stack très différente basée sur Prometheus et Grafana.

Ansible est un outil de la mouvance actuelle autour du DevOps. J'ai commencé à aborder son fonctionnement il y a maintenant quelques mois et force est de constater que sa prise en main est beaucoup plus simple que d'autres produits ayant la même finalité, ceci pour plusieurs raisons :

• l'apprentissage du langage est très rapide ;
• il n'y a pas d'infrastructure à gérer : pas de serveur central (j'y reviendrai un peu plus tard) et surtout pas d'agent.

Il vous est sans doute arrivé de ne plus être en mesure de faire face aux nombres de transactions d’une application, d’avoir des impératifs de résultat vis-à-vis des pannes matérielles (réduire votre temps d'indisponibilité), de vouloir améliorer les performances de votre système ou d’en augmenter les capacités.
Nous avons souvent vu, chez des clients victimes de leur succès, une application devant faire face à des centaines de transactions par seconde alors qu’elle était prévue pour une dizaine seulement.
Dans ce cas, on améliore le système par l’adjonction de nouveaux éléments qui permettent d’augmenter sa capacité transactionnelle. Il existe également des techniques de basculement dans le cas de crash. Dans ce cas, on ne fait que des reprises automatiques d’activité sans faire appel à de la répartition de charge.

Cette solution est intéressante lorsqu’un nœud supporte le volume de transaction et que l’ajout d’un répartiteur de charge fait augmenter la charge du système.
Dans ce qui va suivre, j'essaierai de vous présenter quelques solutions applicables à différentes parties d'une chaîne applicative n-tiers classique.

Kdenlive 0.7.3 vient de sortir. Cette version embarque de nombreux correctifs de bugs incluant des crashs suite au passage à Qt 4.5. Cette version est également l'occasion d'un petit nettoyage du code.

Mais trêve de bavardage, voici une liste des nouveautés :

• Groupement de vidéo ;
  
• Création de script pour rendu différé ;
  
• Codage en deux passes pour le rendu ;
  
• Configuration de la couleur d'arrière plan du moniteur de prévisualisation ;
  
• Nouveauté du site Web : vous pouvez télécharger des nouveaux profils de rendu depuis le site web de Kdenlive ;
  
• Possibilité de séparer le son et l'image d'une vidéo ;
  
• Meilleure compatibilité avec les fichiers de Kdenlive 0.5.