blog-image

Intégration OpenObserve®

  • dHENRY
  • 12/06/2023
  • (Durée de lecture : 2 mn)

Je m’interresse depuis un moment au projet Zinc, qui a évolué vers Openobserve, et permet de stocker et analyser les logs, traces et métriques d’une infrastructure. Au niveau capacité, on en reparle mais j’ai déjà fait un test de +7Millions de documents, ca va très vite (sur X86_64).

Passons maintenant aux Raspberry Pi 4 : Très compliqué à trouver, comme les raspberry PI d’ailleurs, impossible d’assembler le soft sur Raspberry PI4. OOMKilled en fin de piste. Après plusieurs essais, et pour le POC, j’ai fini par dégager la partie serveur web applicative (web/dist) qui est intégré directement à l’exécutable et c’est passé en obtenant un exécutable de 66 Mo.

Il m’a fallu, par conséquent, fabriquer un autre “container”, chargé de servir le contenu de l’application. Choses faîtes, j’ai maintenant deux “containers” qui ne s’éloignent pas du tout du code source original, ca fait juste un peu de manipulations… et ca fonctionne très bien dans le cluster Kubernetes (K8s sur Raspberry PI4) :

  • Un “container” serveur API
  • Un “container” pour servir l’application web, une simple ligne de commande “python3 -m http.server”, avec la copie du build (mais sans les routes statiques, pour l’instant…).

C’est installé depuis 8h et déjà +20000 Documents pour la partie “Logs systèmes” (5 serveurs).

Toute l’ingestion se fait via “Fluent-bit”.

Il reste à voir avec l’équipe dans quelle mesure, il peuvent (ou pas) trouver une solution pour ne pas embarquer (en option) le code source de l’application Web dans l’exécutable…

P.S. : Le Dockerfile.aarch64 (cross-compilation) ne fonctionne pas sur Rasbperry PI4, les flags proposés pour la compilation ne sont pas compatibles avec la CPU Cortex-A72, on obtient l’erreur “Illegal instruction” à l’exécution.

Pour les perfs : 150 Mo de RAM et 50m CPU, avec des pics a +400 Documents/seconde.

Toute la discussion sur Github +++

(*) Image Rendering Powered by