Commandes Linux et compétences Shell
curl : le client Web en ligne de commande qui exécute le script Web
curl est le client HTTP de poche de chaque boîte à outils d'opérations : diagnostique, convivial pour les pipelines et honnête sur ce qui est revenu. Sa surface de drapeau semble énorme et n'est pour la plupart pas en jeu : environ une douzaine de drapeaux couvrent l'utilisation opérationnelle quotidienne, et les connaître fait la différence entre des contrôles de santé scriptés et des drapeaux chanceux. La règle qui permet d'économiser le plus de pagination est triviale : définissez --max-time à chaque fois, car la patience de curl est infinie et la vôtre ne l'est pas.
Points clés
- Regardez avant de télécharger : curl -sSI https://host renvoie la méthode, les en-têtes et le statut sans corps ; ajoutez -v lorsque les poignées de main TLS, les proxys ou les en-têtes d'hôtes se comportent étrangement.
- La discipline de délai d'attente n'est pas négociable : --connect-timeout 5 tue les connexions mortes, --max-time 15 tue les connexions lentes ; un bilan de santé sans les deux peut survivre à la panne qu’il était censé détecter.
- Les codes de sortie sont le contrat dans les scripts : 7 est une connexion refusée, 28 est un délai d'attente, 22 est une erreur HTTP signalée par --fail ; lisez le code, pas seulement la sortie, sinon votre surveillance n'apprend rien.
- Associez la visibilité à l'application : -w '%{http_code} %{time_total}\n' rapporte ce qui s'est passé, tandis que --fail-with-body fait apparaître le corps de l'erreur ; sans l’un de ces éléments, l’échec ressemble exactement au succès.
- Testez ce que les utilisateurs ont réellement touché : --resolve example.com:443:10.1.2.3 vérifie un backend nommé sans jeux DNS, et -H 'Host: vhost.example.com' couvre le côté vhost de la même requête.
- Les transferts reçoivent des indicateurs délibérés : -o nomme la sortie, -L suit les redirections que vous avez examinées, --retry 3 --retry-delay 2 adoucit les amonts instables et -F gère les téléchargements en plusieurs parties dont on ne s'est jamais soucié.
- Les en-têtes et les sockets transportent le monde non-navigateur : -H 'Authorization: Bearer ...' pour les API et --unix-socket /run/app/app.sock pour sonder les services locaux qui ne touchent jamais TCP du tout.
- Connaissez les deux pièges classiques : les variables d'environnement proxy détournent une requête que -v expose en quelques secondes et les redirections qui transforment silencieusement un POST en GET, à moins que vous ne le pensiez.
Note de terrain
Le contrôle de santé qui a été bloqué pendant quinze minutes a été exécuté sans --max-time dans une boucle cron, et il a duré plus longtemps que la panne qu'il était censé détecter. Les délais d'attente sont désormais placés avant l'URL, en principe.
Questions fréquentes
Pourquoi curl est-il sorti à 0 lorsque le site a renvoyé un 500 ? Le succès de
curl signifie que le transport a fonctionné ; Les erreurs au niveau HTTP sont invisibles sans --fail (exit 22) ou une lecture de %{http_code} depuis -w. Les scripts de surveillance insistent sur l'un des deux.
curl ou wget pour les scripts ?
curl pour les API, les en-têtes, les corps POST et un contrôle précis ; wget pour la mise en miroir et la récursivité. Pour un GET unique, l'un ou l'autre fonctionne, et un pipeline mélangeant les deux est généralement un signe que personne n'a décidé à qui appartenait le travail.
L'omission de la vérification TLS est-elle parfois justifiée ?
Pour un diagnostic interactif par rapport à un certificat de laboratoire auto-signé, parfois ; dans tout ce qui est scripté ou piloté par cron, non. -k désactive la seule vérification qui empêche un intermédiaire de posséder votre transfert.
Comment puis-je savoir où une requête lente se bloque ?
Variables de synchronisation : -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' exécuté plusieurs fois sépare les flocons du DNS de la douleur de la poignée de main des blocages du backend.
Comment Kinetikatech vous aide avec commandes linux et compétences shell
Soyons honnêtes, la plupart des équipes viennent nous voir après avoir essayé d'abord par elles-mêmes : Les commandes et habitudes de script qui décident si un administrateur exploite un serveur ou le combat : rechercher, transformer, transférer et superviser le texte et les processus avec les outils présents dans chaque installation de base. Notre service Sécurité des serveurs Linux et Gestion de serveurs existe pour que vous n'ayez pas à apprendre commandes linux et compétences shell à vos dépens : nous gérons l'installation, la supervision et les surprises de 3 h du matin.