L’article explique comment configurer Mimir, le backend de stockage long terme pour les métriques Prometheus développé par Grafana, afin d’améliorer l’observabilité dans un environnement Kubernetes. Il détaille d’abord l’installation locale de Mimir sur le même serveur que Grafana et Prometheus, avec une authentification basic auth et un certificat TLS pour sécuriser l’accès au port 9009. La configuration repose sur un fichier YAML simplifié, où les données sont stockées localement et les composants (ingester, querier, etc.) sont définis pour une instance unique.

Ensuite, l’auteur décrit le déploiement de Grafana Alloy sur Kubernetes pour collecter les métriques et les logs, en s’appuyant sur une infrastructure existante. Un namespace monitoring est créé, ainsi qu’un secret pour l’authentification, tandis qu’un fichier Helm (alloy-values.yml) configure Alloy en tant que daemonset avec des volumes spécifiques pour accéder aux métriques système des nœuds Kubernetes. La configuration inclut aussi le relabeling des cibles Prometheus pour identifier correctement les instances.

Enfin, l’article souligne l’intégration entre Alloy et Mimir, où Alloy scrappe les métriques des nœuds et les envoie vers Mimir via remote_write, permettant ainsi une observabilité centralisée. La solution est présentée comme une alternative pour remplacer ou compléter des outils comme Prometheus en stockage long terme, tout en garantissant une configuration sécurisée et adaptée à Kubernetes.

L’article explique comment générer des fichiers Excel volumineux avec Airflow sans dépasser la mémoire disponible, en évitant les erreurs OOM (Out Of Memory). L’idée principale repose sur l’utilisation du streaming pour lire les données depuis MySQL et du mode write-only d’openpyxl pour écrire le fichier Excel sans tout charger en mémoire. Cette approche permet de stabiliser la consommation mémoire, contrairement à une méthode naïve qui charge l’intégralité des données en mémoire avant de les exporter.

L’auteur souligne que les solutions classiques, comme l’utilisation de pandas avec un chunksize, ne suffisent pas, car elles ne réduisent pas la mémoire utilisée lors de la lecture initiale. En revanche, un curseur non bufferisé pour MySQL et une écriture progressive avec openpyxl permettent de traiter les données par lots, limitant ainsi l’empreinte mémoire.

Enfin, l’article met en garde contre les coûts élevés liés à l’augmentation de la mémoire dans le cloud et propose une solution efficace pour des environnements contraints, comme AWS ECS Fargate. Cette méthode est particulièrement utile pour les pipelines de data engineering où les ressources sont optimisées pour réduire les dépenses.