Comment lire les journaux nginx

Il existe deux principaux types de journaux nginx : les journaux d'accès et les journaux d'erreurs. Le journal d'accès enregistre principalement chaque demande du client pour accéder à nginx, et le format peut être personnalisé ; le journal des erreurs enregistre principalement le journal lorsque le client fait une erreur lors de l'accès à nginx, et le format ne prend pas en charge la personnalisation. Les deux journaux peuvent éventuellement être désactivés.

Grâce aux journaux d'accès, vous pouvez obtenir des informations pertinentes telles que l'origine géographique de l'utilisateur, la source du saut, le terminal d'utilisation, le nombre de visites à une certaine URL grâce aux journaux d'erreurs ; , vous pouvez Vous pouvez obtenir le goulot d'étranglement des performances d'un certain service ou serveur dans le système. Par conséquent, en faisant bon usage des journaux, vous pouvez obtenir de nombreuses informations précieuses.

Journal d'accès

[Access.log]

log_format  main  '$remote_addr $remote_user [$time_local] "$request" $http_host '
                  '$status $upstream_status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" $ssl_protocol $ssl_cipher $upstream_addr '
                  '$request_time $upstream_response_time';

Description :

Algorithmes en données d'échangeL'adresse de l'arrière-planLa durée totale de toute la demandeDemande en cours,

Remarque : La valeur de $http_host est liée à la valeur que vous saisissez dans le navigateur.

Journal des erreurs

Nom de la variable	Description de la variable	Exemple
$remote_addr	Adresse du client	113.140 15.90<.>
$remote_user	Client nom d'utilisateur	-
$time_local	Heure et fuseau horaire d'accès	18/juillet/2012 : 17:00:01 +0800
$demande	Demandé URI et HTTPProtocole	"GET /pa/img/home/logo-alipay-t.png HTTP/1.1"
$http_host	L'adresse de la demande est l'adresse que vous saisissez dans le navigateur ( IP ou Nom de domaine)	img.alipay.com 10.253.70.103
$statut	HTTPStatut de la demande	200
$upstream_status	upstreamstatut	200
$body_bytes_sent	Taille du contenu du fichier envoyé au client	547
$http_referer	Aller à la source	"https://cashier.alipay.com.../"
$http_user_agent	Agent de terminal utilisateur	"Mozilla/4.0 (compatible ; MSIE 8.0 ; Windows NT 5.1 ; Trident/4.0 ; GTB7.0 ;
SSL Version du protocole	TLSv1	$ssl_cipher
RC4-SHA		$upstream_addr
en amont , c'est-à-dire l'adresse de l'hôte qui réellement fournit le service	10.228.35.247:80	$request_time
0,205		$upstream_response_time
amont Délai de réponse	0,002

Lors de la connexion, si le backend Lorsque l'utilisateur rencontre le backend lors de la lecture des données après une connexion réussie permet de définir les requêtes clients autorisées pour être accepté. La valeur maximale du contenu, la valeur par défaut est

Message d'erreur	Description de l'erreur
"en amont prématurément (prématuré) connexion fermée"	L'exception qui se produit lors de la demande de uri est causée par la déconnexion de l'utilisateur lorsque en amont n'a pas renvoyé de réponse à l'utilisateur. Elle n'a aucun impact sur le système et peut être ignorée<.>
"échec de recv() (104 : réinitialisation de la connexion par un homologue)"	( 1) Le nombre de connexions simultanées du serveur dépasse sa capacité, et le serveur coupera certaines connexions ( 2) Le client a fermé le navigateur, mais le serveur envoie toujours des données au client ( 3) Le navigateur cliqué sur Arrêter
"(111 : Connexion refusée) lors de la connexion en amont"	amont se bloque ou est bloqué, l'utilisateur recevra cette erreur
"(111 : Connexion refusée) lors de la lecture de l'en-tête de réponse depuis l'amont"	En amont raccroche ou est bloqué, vous recevrez cette erreur
"(111 : Connexion refusée) lors de l'envoi de la requête en amont "	Lorsque Nginx et en amont sont connectés avec succès et envoient des données, si le backend en amont se bloque ou n'est pas disponible, vous recevrez cette erreur
"(110 : connexion expirée) lors de la connexion en amont" " (110 : La connexion a expiré) lors de la lecture en amont"	nginx a expiré lors de la lecture de la réponse de en amont
	"(110 : expiration du délai de connexion) lors de la lecture de l'en-tête de réponse depuis l'amont" nginx a expiré lors de la lecture de l'en-tête de réponse de en amont
"(110 : expiration du délai de connexion) lors de la lecture en amont"	nginx a expiré lors de la lecture de la réponse de en amont
"(104 : Connexion réinitialisée par un homologue) lors de la connexion en amont"	en amont envoyé RST, réinitialisation de la connexion
"en amont envoyé un en-tête invalide lors de la lecture de l'en-tête de réponse en amont"	L'en-tête de réponse envoyé par l'amont n'est pas valide
"L'amont n'a envoyé aucun en-tête HTTP/1.0 valide lors de la lecture de l'en-tête de réponse depuis l'amont"	L'en-tête de réponse envoyé par l'amont n'est pas valide
"client destiné à envoyer un corps trop volumineux"	1M, le corps envoyé par le client dépasse la valeur définie
"réouverture des journaux"	L'utilisateur envoie la commande kill -USR1
"arrêt gracieux",	L'utilisateur envoie la commande kill -WINCH
"aucun serveur n'est à l'intérieur en amont"	non les serveurs sont en amont Configurer le serveur
"pas d'amont en direct lors de la connexion en amont"	Les serveurs en amont ont tous raccroché
"Échec de SSL_do_handshake()"	Échec de la négociation SSL
"SSL_write( ) a échoué (SSL:) lors de l'envoi au client"
"(13 : Autorisation refusée) lors de la lecture en amont"
"(98 : Adresse déjà utilisée) lors de la connexion en amont"
"(99 : Impossible d'attribuer l'adresse demandée) lors de la connexion en amont"
"Échec de ngx_slab_alloc() : pas de mémoire dans le cache partagé de la session SSL"
"Impossible d'ajouter une nouvelle session SSL au cache de session pendant l'établissement de liaison SSL"	La taille de SSL_session_cache est insuffisante et d'autres raisons causées par
"send() a échoué ( 111 : Connexion refusée)"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!