Signoz et OpenTelemetry avec une app .net sous linux

.net 6.0, Asp .net, Asp.net Core, Azure Devops, C#, Debian, DevOps, Microsoft .net, Nginx

Disclamer A l’heure ou j’écris cet article, le code source d’OpenTelemetry et Signoz sont en alpha/beta/pre-release.  Certaine lib sont en release officielle. J’édite au fur et à mesure certaine infos. Le code évolue et cet article aussi.  Il n’est certainement plus « à la page » lorsque vous lirez ces ligne.  Et de même, la doc officielle, celle de Microsoft et les ReadMe des repos ne sont pas tous mis à jours en temps et en heure.  C’est un sujet chaud pattate !!! Besoins Comme d’habitude, j’écris un article avec un vrai besoin et une application dans la vraie vie.  J’ai un serveur en prod et je souhaite le monitorer pour : observer son comportement (nombre de requêtes, % de CPU/RAM/Disk, periode d’activité/repos etc) analyser des problèmes, avoir accès aux logs sans ouvrir un terminal être alerté en cas de problème et pouvoir définir ces alertes avoir une vue d’ensemble avec des KPI de base   Contexte Depuis peu (qq années) on a la possibilité de faire tourner du .net sous linux. Ca change quoi allez vous me dire ?  Personnelement une question de coût. Un VPS (virual private server) sous linux c’est au moins deux fois moins cher que sous Windows (ça dépend avec quel fournisseur et les prix ont aussi évolué dans le temps). Mais aujourd’hui un VPS linux est utlra compétitif. Et j’ai pas de besoin cloud (même si j’y pense). Avec Windows on était habitué à installer des outils graphiques supplémentaires. Et meme de base on avait des outils de monitoring. Sous linux, c’est moins évident car on utilise principalement la ligne de commande. Et personnellement j’y retrouve pas mon compte. Même si on peut aussi mettre une interface graphique, c’est pas le but d’un serveur. Enfin, je voudrais pouvoir consulter ceci sans me loguer en ssh (depuis une interface web) et avoir des alertes email et sms serait top.  Actuellement je développe un nouveau produit (https://outquest.fr). Celui ci comporte un site web (game) et un site backoffice (qg). Le site officiel (outquest.fr) et le shop sont hébergés ailleurs (planethoster). J’ai une prod et un staging. (donc 4 site webs au final). J’ai commencé avec un serveur low cost à 2.99€/mois (Debian, 1 core,  2 Go Ram, 25Go SSD …) chez Ikoula. Franchement à ce prix la, ça marche bien pour faire tourner 4 sites webs.(avec que moi dessus hein !) Ces 4 sites web tournent sous 4 services kernel (autorestart) linux et géré par un serveur web frontal NGinx.  –> pour la config voir cet article J’ai de plus une CI/CD géré par azure devops (voir article Azure Devops) qui me permet via des pipelines de deployer automatiquement mon code sur les serveurs web respectif à chaque push git sur mes branches dev et master.  Ca a dla gueule ! Pour un mec tout seul (pour le moment) je sors la grosse artillerie. J’aurais pu partir direct avec un site web en prod et debuger dessus à l’ancienne. Mais j’aime bien apprendre à faire les choses bien :). Et justement, pour faire bien, la prochaine étape c’est le monitoring des serveurs (ya aussi les backups, je pense que j’en ferai un article à part).  Du coup j’ai voulu tester une solution qui me paraissait pas mal, un APM (Application Performance Management) : CheckMK.  Le souci c’est que j’ai vu trop gros (ce machin permet de gérer tout un parc informatique, plusieurs serveurs, node, kubernetes…) Et en l’installation, le machin à fait fondre mon serveur. Plus moyen d’y accéder pendant un temps et pas moyen de le redémarrer (j’ai contacté le support, ce qui m’a pris plusieurs jours, à ce prix la fallait pas attendre des miracles.) Le bon moment pour passer à un niveau supérieur.  A ce stade j’avais ma prod et mon staging sur la meme petite bécanne. Du coup je me dis qu’il faudra quand meme passer sur qq chose de plus sérieux pour la prod. J’ai donc opté pour un VPS OMGServ avec cette config :  Et une option payante supplémentaire de backup. (snapshots) CheckMK tourne déjà beaucoup mieux, mais comme je le disais c’est pas une solution pour moi. Ca install une bardé de trucs dont Apache2, qui fout la merde avec mon Nginx.  Après qq recherches, je suis tombé sur Signoz et OpenTelemetry. Et c’est ce qu’il me faut !   Signoz   Signoz est une interface web permettant de visualiser un ensemble de données sur votre serveur linux.  C’est une solution Open Source, récente et encore en dev. C’est un concurrent à DataDog (payant).  Elle permet de monitorer des applications et de fournir des éléments pertinents pour les devops.  Cette solution naît d’un constat. Les équipes techniques sont frustrées d’utiliser pleins d’outils différents provenants de sources de données elles aussi différentes pour voir leurs logs/metrics/traces …   De plus les outils existants sont « lourds », taillé pour de la grosse boite (faut bien vendre) avec des standards propriétaires et non générique.  Je n’ai pas de recul suffisant mais mon sentiment c’est que c’est compliqué et qu’un outil simple, uniformisé gratuit et open source manquait à ce niveau pour un niveau « intermediaire » (PME, TPME, indé) Un standard est en train d’émerger concernant toute ces données que l’on appelle OpenTelemetry. OpenTelemetry Encore un nouveau framework ? C’est quoi, une couche de plus ? OpenTelemetry c’est une collection d’outil, d’APIs et de SDKs permettant de mesurer, generer, collecter et exporter des données de télémetrie (metrics, logs et traces) afin de mieux analyser le comportement et les performances de nos applications.  Super mais qui porte le truc ? Est ce que c’est un projet qui va être adopté ? Oui, en tout cas par Microsoft : https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-overview Vu l’investissement de Microsoft pour les projets à succès Open Source, et vu le besoin, je pense qu’OpenTelemetry a de l’avenir.  Installer Signoz Il existe plusieurs façon d’installer Signoz, j’ai choisi pour ma part la version Standalone (https://signoz.io/docs/install/docker/) sur mon VPS linux Debian 11. Vous devrez télécharger le repo git : git clone -b main https://github.com/SigNoz/signoz.git puis vous rendre dans le répertoire suivant :…

Azure Devops Pipeline (CI/CD) – Relancer les services

.net 6.0, Asp.net Core, Azure, Azure Devops, CI/CD, Debian, Nginx, Non classé, pipeline

Services Debian systemctl Suite à mon dernier article, j’ai été confronté à un problème que j’ai mis longtemps à identifier. Lorsque je mets à jour mon site web, mettons celui du staging avec une nouvelle publication, je modifie les fichiers à la racine du projet, c’est à dire var/etc/www/staging.blazordemo.reactor.fr/ dans mon cas. Pour ma part j’applique une politique du "j’effface tout" et "j’upload tout". Pas de remplacement de fichier. C’est plus long mais je suis certain qu’il y a pas un mauvais fichier en ligne.  Hormis des pb de cache ou de rafraichissement, mon site web est bien à jour.  Mais pas mon service Kernel. En tout cas sur linux Nginx, lorsque je rajoute par exemple un controler "api/plateform" coté serveur, si je ne relance pas mon service avec les commandes suivantes : sudo systemctl stop kestrel-staging.blazordemo.reactor.fr.service sudo systemctl start kestrel-staging.blazordemo.reactor.fr.service sudo systemctl status kestrel-staging.blazordemo.reactor.fr.service mon api « plateform » ne sera pas accessible. En tapant ces commandes, l’api est accessible. Il serait bon d’inclure cela dans la pipeline, histoire qu’on est rien à faire à la main à chaque run de pipeline si le code c# est modifié coté serveur. Pour cela, il suffit de rajouter ces lignes : – task: SSH@0 displayName: ‘Restart Kestrel Service’ inputs: sshEndpoint: ‘SSH to Ikoula’ runOptions: ‘commands’ commands: | sudo systemctl stop kestrel-staging.blazordemo.reactor.fr.service sudo systemctl start kestrel-staging.blazordemo.reactor.fr.service sudo systemctl status kestrel-staging.blazordemo.reactor.fr.service readyTimeout: ‘20000’ Ca donne ça dans les ‘logs’ des jobs de l’execution du pipeline :

.net Core sous Linux Nginx 80 http 443 https firewall

Asp.net Core, C#, Debian, DevOps, Nginx1 Commentaire

En voila un titre bien déguelasse. Suite à l’article précédent (comment heberger asp.net, un bref historique) je voulais consigner ici mes trouvailles concernant la mise en place d’un site web asp.net core sur Linux Debian.  Pour cela j’ai loué un VPS Linux chez iKoula pour 4€.  On a donc un accès SSH suite à l’obtention de ce dernier, on se connecte et je vous montre comment on fait un site web qui marche en .net Core.   Sources Voici les quelques sites web qui m’ont servit dans cet article. # Installer Dotnethttps://docs.microsoft.com/fr-fr/dotnet/core/install/linux-debian# Installer un firewall UFWhttps://debian-facile.org/doc:systeme:ufw# Installer NGinxhttps://idroot.us/install-nginx-debian-11/https://www.howtoforge.com/how-to-install-nginx-on-debian-11/# Config Nginxhttps://docs.microsoft.com/fr-fr/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-6.0# Multi Sitehttps://webdock.io/en/docs/how-guides/shared-hosting-multiple-websites/how-configure-nginx-to-serve-multiple-websites-single-vps Projet web Asp.net core On commence par la création locale d’un site web en asp.net core .net 5. Qu’il faut bien entendu avoir sur son poste. Je vous renvois à la doc pour toute la paprasse,  https://docs.microsoft.com/fr-fr/aspnet/core/getting-started/?view=aspnetcore-6.0&tabs=windows C’est une des meilleurs doc du web, donc profitez en. Je vais pas la réinventer, je vais a l’essentiel. La commande suivante va vous créer une api web de base.  dotnet new webapi -o TodoApi On va garder l’exemple de microsoft « TodoApi », qui est en fait une api toute conne avec un seul control qui donne la météo. Je m’en fou total de ce truc, c’est pour l’exemple.  Pour moi il manque une route, celle de la « home ». Alors je rajoute un controler « home Histoire d’avoir qq chose à afficher à la racine du site. On teste le site web  dotnet run.  De base vos ports sont 5001 sur https (avec un certificat local de developer) et 5000 en http.  Ces ports sont localisés dans  Properties/launchSettings.json dans la propriété applicationUrl Si comme moi, vous avez plusieurs sites asp.net core, vous allez probablement changer ces ports. Et on va le voir par la suite cela a une grande importance. Moi je le fait directement dans le code source, mais ya d’autre méthodes. Le site tourne on va le publier  avec la commande suivante  dotnet publish -c Release Ce qui va créer un nouveau répertoire  binReleasenet5.0publish Ou on aura tous les fichiers nécessaires pour notre site web en production dedans.  Install Server VPS Alors avant toute chose, je suis pas un expert linux. Si je dis une connerie, faut le signaler dans les commentaires svp. J’ai un passif Windows qui m’a éloignié de Linux, meme si de base, je suis ingé système et réseau, de ya 20 ans… On commence, on se connecte en SSH.  Alors perso, j’ai découvert une extension de visual studio code qui facilite la vie. C’est Remote-SSH.Ca permet d’éditer des fichiers distants directement dans VS (et d’avoir tous les outils, couleurs, syntaxe, etc…) Mais ca fait aussi explorateur de fichier, FTP et bien entendu on a toujours une ligne de commande à porté de main, tout ca dans VS code. Un must have. Dotnet 5.0 Alors le serveur est une version Debian 11 de linux. C’est important de checker avant si .net Core est compatible ou pashttps://docs.microsoft.com/fr-fr/dotnet/core/install/linux   Nous on continue sur une Debian 11 :https://docs.microsoft.com/fr-fr/dotnet/core/install/linux-debian   On référence les packages Microsoft(wgt ==> w g e t, va savoir pourquoi je peux pas écrire ce mot la sur wordpress) wgt https://packages.microsoft.com/config/debian/11/packages-microsoft-prod.deb -O packages-microsoft-prod.debsudo dpkg -i packages-microsoft-prod.debrm packages-microsoft-prod.deb   Puis on install le SDK .Net 5.0 (la version 6.0 est sortie peu de temps avant cet article, donc passer en 6.0 c’est mieux)   sudo apt-get updatesudo apt-get install -y apt-transport-httpssudo apt-get updatesudo apt-get install -y dotnet-sdk-5.0 Nginx Pré install  sudo apt update sudo apt upgrade sudo apt install curl gnupg2 ca-certificates lsb-release Install sudo apt install nginx On Check nginx -v Ce qui donne pour moi : nginx version: nginx/1.18.0  on en profite pour installer un firewall ufw apt-get update && apt-get install ufw et on l’active  ufw enable Alors attention, ca pourrait couper votre connexion SSH, mais les gars ils sont pas trop con, ils ont par defaut ouvert le port 22.  On ajoute les règles de bases NGinx sudo ufw allow ‘Nginx HTTP’ A ce stade on devrait avoir un site web qui tourne. Donc aller changer votre DNS pour modifier ou ajouter un domain, par exemple prout.com qui pointe vers l’ip de votre serveur. Profitez en pour ajouter une nouvelle entrée A dans votre zone DNS todoapi.prout.com qui pointe vers la meme IP. Ca peut prendre jusqu’à 24h, mais aujourd’hui ca va plus vite. Si c’est un .fr ca devrait pas trainer. Sinon, faut pinger l’adresse jusqu’à avoir une réponse et une IP qui va bien.  Aller dans votre navigateur préféré et taper votre domaine, pour moi : http://prout.com et si vous voulez pas attendre taper directement l’ip de votre serveur. Notez que pour le moment on parle pas encore de https.  Et bimm : Tu n’as un beau serveur d’enculé ! Config Nginx On fait un pti point pour comprendre les choses.  Dans /var/www/html on a le code source de notre site web.  Dans /etc/Nginx on a notre serveur web Nginx et ses conf Le répertoire sites-available va contenir les configurations de nos sites web. Le répertoire sites-enabled va contenir des liens vers les config précédentes. Ce qui les rendra actives ! C’est ce que l’on va faire, on va créer un nouveau site. Pour cela on va commencer par mettre un nouveau répertoire dans /var/www qui va contenir le publish de tout à l’heure. Alors on y va, on copie… Ensuite il faut créer un fichier dans /etc/nginx/sites-available/, par exemple todoapi.prout.com.conf et on y met ceci server {    server_name todoapi.prout.com;    root /var/www/todapi;    location / {        proxy_pass         http://127.0.0.1:5002;        proxy_http_version 1.1;        proxy_set_header   Upgrade $http_upgrade;        proxy_set_header   Connection keep-alive;        proxy_set_header   Host $host;        proxy_cache_bypass $http_upgrade;        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;        proxy_set_header   X-Forwarded-Proto $scheme;    }  }   Noter 3 points, le serveur name avec le DNS de tout à l’heure. le root avec l’emplacement de notre publish. Et enfin le proxy pass et son port 5002. On…