Comment personnaliser la journalisation et activer le tampon de journal dans Nginx

Access Log

nginx écrit des informations sur une demande client dans le journal d'accès immédiatement après avoir traité la demande. Par défaut, le journal d'accès se trouve dans logs/access.log et les informations sont écrites dans le journal dans un format de combinaison prédéfini.

Si vous souhaitez enregistrer avec précision les informations d'accès, vous devez personnaliser un format de journal d'accès plus complet, comme indiqué ci-dessous :

http {
  log_format geoproxy
  '[$time_local] $remote_addr '
  '$realip_remote_addr $remote_user '
  '$request_method $server_protocol '
  '$scheme $server_name $uri $status '
  '$request_time $body_bytes_sent '
  '$geoip_city_country_code3 $geoip_region '
  '"$geoip_city" $http_x_forwarded_for '
  '$upstream_status $upstream_response_time '
  '"$http_referer" "$http_user_agent"';
  ...
}

Cette configuration de journal est nommée géoproxy, qui utilise De nombreuses variables nginx pour démontrer la fonctionnalité de journalisation nginx. Explication détaillée de la signification spécifique de chaque variable dans les options de configuration :

Lorsque l'utilisateur lance une requête, l'heure du serveur $time_local sera enregistrée et la valeur $remote_user est le nom d'utilisateur qui a été transmis. autorisation de base

#🎜🎜 #Utilisé par nginx pour traiter l'adresse IP de la connexion ouverte et l'adresse IP du client des instructions geoip_proxy et realip_header

Ensuite, enregistrez la méthode de requête http $ ; request_method, protocol $server_protocol et http method $scheme : http ou https

Bien sûr, il y a aussi le nom du serveur $server_name, l'uri demandé et le code d'état de la réponse ; 🎜#En plus des informations de base, il existe également des données de résultats statistiques : y compris les millisecondes de traitement de la demande. Temps de niveau $request_time, taille du bloc de données de réponse du serveur $body_bytes_sent;

De plus, le pays du client $geoip_city_country_code3 , les informations sur la région $geoip_region et la ville $geoip_city sont également enregistrées ;

# 🎜🎜#La variable $http_x_forwarded_for est utilisée pour enregistrer le message d'en-tête x-forwarded-for des requêtes initiées par d'autres serveurs proxy

#🎜 ; 🎜#Certaines données du module amont sont également enregistrées dans le log : la réponse du serveur proxy Code d'état $upstream_status, temps d'établissement de la connexion et réception du dernier octet du corps de réponse du serveur amont $upstream_response_time, temps d'établissement la connexion au serveur amont $upstream_connect_time, temps pour établir la connexion et recevoir le premier octet de l'en-tête de réponse du serveur amont $upstream_header_time .

La source de la requête $http_referer et l'agent utilisateur $http_user_agent peuvent également être enregistrés dans le journal ;

nginx est très puissante et flexible. Utilisation La directive log_format qui définit le format du journal ne fonctionne qu'avec la directive au niveau du bloc http. Toutes les valeurs de temps sont en millisecondes et mesurées avec une résolution en millisecondes. .

La configuration des journaux dans ce format générera les types de journaux suivants :

[25/feb/2019:16:20:42 +0000] 10.0 .1.16 192.168.0.122 derek

get http/1.1 http / 200 0.001 370 usa mi

"ann arbor" - 200 0.001 "-" "curl/7.47.0"

#🎜 🎜#

Si vous devez utiliser cette configuration de journal, vous devez l'utiliser en conjonction avec la directive access_log La directive access_log reçoit un répertoire de journal et le nom de la configuration utilisé comme paramètres :

server {
  access_log /var/log/nginx/access.log geoproxy;
  ...
}

#. 🎜🎜#access_log peut être utilisé dans plusieurs contextes. Chaque contexte peut définir son propre répertoire de journaux et son propre format de journalisation.

Conclusion : Le module de journalisation de nginx permet de configurer des formats de journaux pour différents scénarios afin d'afficher différents fichiers journaux.

Dans les applications pratiques, il est très utile de configurer différents journaux pour différents contextes. Le contenu du journal enregistré peut être de simples informations, ou toutes les informations nécessaires peuvent être enregistrées en détail. De plus, en plus de prendre en charge le texte

, le contenu du journal peut également enregistrer des données au format json et xml. En fait, les journaux nginx vous aident à comprendre des informations telles que le trafic du serveur, l'utilisation du client et l'origine du client. De plus, les journaux d'accès peuvent également vous aider à localiser les réponses et les problèmes liés au serveur en amont ou à des URI spécifiques ; les journaux d'accès sont également utiles pour les tests, car ils peuvent être utilisés pour analyser le trafic et simuler des scénarios d'interaction utilisateur réels. Les journaux sont indispensables au dépannage, au débogage, à l’analyse des applications et aux ajustements commerciaux.

Journal des erreurs

Afin de localiser avec précision le journal des erreurs nginx, utilisez la directive error_log intégrée pour définir le répertoire et enregistrements du journal des erreurs Le niveau de journal des erreurs est configuré comme suit :

error_log /var/log/nginx/error.log warn;

error_log La configuration de la directive nécessite un répertoire de journal requis et une option facultative de niveau d'erreur. Sauf la directive if, la directive error_log peut être utilisée dans tous les contextes. Les niveaux de journal des erreurs incluent :

debug, info, notice, warn, error, crit, alert et emerg. L'ordre des niveaux de journalisation donné

est l'ordre des niveaux de journalisation, du plus petit au plus rigoureux. Il convient de noter que le journal de débogage

doit être utilisé lors de la compilation du serveur nginx avec l'indicateur --with-debug.

Lorsqu'il y a une erreur dans la configuration du serveur, vous devez d'abord consulter le journal des erreurs pour localiser le problème. Le journal des erreurs

est également un outil utile pour localiser les serveurs d'applications (tels que les services fastcgi). Grâce au journal des erreurs, nous pouvons déboguer les erreurs de connexion aux processus de travail, l'allocation de mémoire, les problèmes d'IP client et de serveur d'applications. Le format du journal des erreurs ne prend pas en charge les formats de journal personnalisés ; cependant, il enregistre également des données telles que l'heure actuelle, le niveau de journalisation et des informations spécifiques.

注意：错误日志的默认设置适用于全局。要覆盖它，请将 error_log 指令放在 main （顶级）配置上下文中。 error_log 在开源 nginx 1.5.2 版中添加了在同一配置级别指定多个指令的功能。

通过 syslog 将日志发送到统一服务器

既然不再需要将日志写到磁盘的某个目录，而是发送到统一的日志服务器，则将原有的目录部分替换为服务器 ip 即可，配置如下：

error_log syslog:server=10.0.1.42 debug;
access_log syslog:server=10.0.1.42,tag=nginx,severity=info geoproxy;

#error_log server=unix:/var/log/nginx.sock debug;
#access_log syslog:server=[2001:db8::1]:1234,facility=local7,tag=nginx,severity=info;

error_log 和 access_log 指令的 syslog 参数紧跟冒号 : 和一些参数选项。包括：必选的 server 标记表示需要连接的 ip、dns 名称或 unix 套接字；

可以使用如上注释的高端玩。

可选参数有 facility 、 severity 、 tag :

server 参数接收带端口的 ip 地址或 dns 名称；默认是 udp 514 端口。

facility 参数设置 syslog 的类型 facility ，值是 syslog rfc 标准定义的 23 个值中一个，默认值为 local7 。其他可能的值是： auth ， authpriv ， daemon ， cron ， ftp ， lpr ， kern ， mail ， news ， syslog ， user ， uucp ， local0 ... local7

tag 参数表示日志文件中显示时候的标题，默认值是 nginx 。

severity 设置消息严重程度，默认是 info 级别日志。

日志缓冲区

当系统处于负载状态时，启用日志缓冲区以降低 nginx worker 进程阻塞。大量的磁盘读写和 cpu 资源使用对于服务器资源也是一种巨大消耗。将日志数据缓冲到内存中可能是很小的一个优化手段， buffer 参数意义是缓冲区的大小，功能是当缓冲区已经写满时，日志会被写入文件中； flush 参数意义是缓冲区内日志在缓冲区内存中保存的最长时间，功能即当缓存中的日志超过最大缓存时间，也会被写入到文件中， 不足的地方即写入到日志文件的日志有些许延迟，即时调试中应当关闭日志缓冲。 。配置如下：

http {
  access_log /var/log/nginx/access.log main buffer=32k flush=1m;
}

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!