有哪些关键参数和最佳实践需要掌握-Apache访问日志配置中

教程大全 2026-01-20 22:26:56 浏览

Apache 访问日志配置详解

Apache日志配置关键参数 Apache 访问日志

Apache 服务器是一款广泛使用的开源 Web 服务器软件,它提供了强大的功能,包括访问日志记录,访问日志记录可以帮助管理员了解网站的用户访问情况,分析用户行为,优化网站性能,本文将详细介绍 Apache 访问日志的配置方法。

Apache 访问日志配置步骤

修改 Apache 配置文件

我们需要修改 Apache 的配置文件,即 httpd.conf,在 httpd.conf 文件中,找到以下配置行:

LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i""CustomLog logs/access_log combined

LogFormat 定义了日志的格式,CustomLog 定义了日志的存储位置和格式。

修改日志格式

默认的日志格式为,它包含了以下信息:

根据实际需求,可以修改 LogFormat 的内容,如果我们只需要记录客户端 IP 地址和访问时间,可以将 LogFormat 修改为:

LogFormat "%h %t" simple

修改日志存储位置

默认情况下,访问日志存储在 Apache 安装目录下的 logs/access_log 文件中,如果需要修改日志存储位置,可以在 CustomLog 配置中指定新的路径,将日志存储在 /var/log/apache2/ 目录下,可以修改为:

CustomLog /var/log/apache2/access_log simple

重启 Apache 服务

修改完配置文件后,需要重启 Apache 服务以使配置生效,在 Linux 系统中,可以使用以下命令重启 Apache:

sudo systemctl Restart apache2

Apache 访问日志分析工具

Apache 访问日志分析工具可以帮助管理员快速了解网站的用户访问情况,以下是一些常用的 Apache 访问日志分析工具:

Q1:如何查看 Apache 访问日志?A1:在 Apache 安装目录下的 logs/ 目录中,找到 access_log 文件,使用文本编辑器打开即可查看。

Q2:如何修改 Apache 访问日志的存储位置?A2:在 httpd.conf 文件中,找到 CustomLog 配置行,修改其中的路径即可,将 CustomLog “/var/log/apache2/access_log combined” 修改为 CustomLog “/path/to/new/log/access_log combined”。


如何配置PHPadmin

phpadmin就是一个产品,用于管理MYSQL数据库的,毕竟很多数据库服务器不能够公开连接,所以只能够使用http的方式来进行连接管理。 下载phpadmin(解压到apache能够访问的一个目录中(首先apache和php已经集成好了,能够浏览php页面)。 运行访问会出现一些提示情况。 如果你的mysql安全设置不错的话,可能默认情况下是不能够连接到你的服务器的,需要修改一些配置信息。 修改phpadmin/文件,其中主要是对mysql连接方式,连接路径以及用户名密码的设置。 修改如下:$cfg[PmaAbsoluteUri] =$cfg[PmaAbsoluteUri_DisableWarning] = TRUE;$cfg[blowfish_secret] = admin;$cfg[Servers][$i][port]= ;// MySQL port - leave blank for default port$cfg[Servers][$i][socket]= ;// Path to the socket - leave blank for default socket$cfg[Servers][$i][connect_type]= tcp; // How to connect to MySQL server (tcp or socket)$cfg[Servers][$i][extension] = mysql; // The php MySQL extension to use (mysql or mysqli)$cfg[Servers][$i][compress]= FALSE; // Use compressed protocol for the MySQL connection// (requires PHP >= 4.3.0)$cfg[Servers][$i][controluser] = ;// MySQL control user settings// (this user must have read-only$cfg[Servers][$i][controlpass] = ;// access to the mysql/user// and mysql/db tables).// The controluser is also// used for all relational// features (pmadb)$cfg[Servers][$i][auth_type] = cookie;// Authentication method (config, http or cookie based)?$cfg[Servers][$i][user]= ;// MySQL user$cfg[Servers][$i][password]= ;// MySQL password (only needed其中比较重要的几个参数意义:PmaAbsoluteUri phpadmin的全路径,如果在apache中设定了一个alias的话就使用这个了PmaAbsoluteUri_DisableWarning 这个好像是用于取消警告的,经常安装好了在访问的页面上面会出现一些红色字体的警告(安全等等),如果设置成为true就不出现了blowfish_secret 这个是如果授权方式设置成为cookie的话就会使用这个来进行加密存入到cookie中的用户名和密码auth_type 用于设置登陆方式,config是直接从这个文件中获取user/password然后连接数据库,http则是在客户端访问的时候会弹出一个输入用户名密码的框进行认证处理 cookie则是通过页面输入用户名密码进行连接。 其中config的安全等级最低,cookie的等级最高,不过如果禁用了cookie则无法使用cookie的方式进行认证。 通常设置成为cookie的方式以后要在apache的文件中修改对应的配置:#added for phpmyadminAlias /phpadmin/ website/phpMyAdmin-2.6.1-rc2/#php_admin_flag engine on #php_admin_flag safe_mode off DirectoryIndex Options Indexes MultiViews AllowOverride None order allow,deny Allow from all #php_admin_flag engine on #php_admin_flag safe_mode off #php_admin_value open_basedir none #php_admin_value open_basedir website/phpMyAdmin-2.6.1-rc2/ 当然主要是设置访问权限和别名

Apache服务器中prefork和worker工作模式的区别以及性能优化

1、RedHat Linux下查看apache版本号在Apache安装目录bin下,使用以下命令查看即可。 使用命令:./httpd -v示例:2、查看Apache当前工作模式Apache有prefork和worker工作模式使用命令:./apachectl –l示例:从以上结果可知,当时httpd工作在prefork模式下。 在configure时,可以通过指定参数,将工作模式设置为worker模式或prefork模式。 使用命令:./configure --with-mpm=worker示例:设置为worker模式Apache服务的两种工作模式详解:prefork的工作原理及配置如果不用“--with-mpm”显式指定某种MPM,prefork就是Unix平台上缺省的MPM。 它所采用的预派生子进程方式也是Apache 1.3中采用的模式。 prefork本身并没有使用到线程,2.0版使用它是为了与1.3版保持兼容性;另一方面,prefork用单独的子进程来处理不同的请求,进程之间是彼此独立的,这也使其成为最稳定的MPM之一。 若使用prefork,在make编译和make install安装后,使用“httpd -l”来确定当前使用的MPM,应该会看到prefork.c(如果看到worker.c说明使用的是worker MPM,依此类推)。 再查看缺省生成的配置文件,里面包含如下配置段:StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0prefork的工作原理是,控制进程在最初建立“StartServers”个子进程后,为了满足MinSpareServers设置的需要创建一个进程,等待一秒钟,继续创建两个,再等待一秒钟,继续创建四个……如此按指数级增加创建的进程数,最多达到每秒32个,直到满足MinSpareServers设置的值为止。 这就是预派生(prefork)的由来。 这种模式可以不必在请求到来时再产生新的进程,从而减小了系统开销以增加性能。 MaxSpareServers设置了最大的空闲进程数,如果空闲进程数大于这个值,Apache会自动kill掉一些多余进程。 这个值不要设得过大,但如果设的值比MinSpareServers小,Apache会自动把其调整为MinSpareServers+1。 如果站点负载较大,可考虑同时加大MinSpareServers和MaxSpareServers。 MaxRequestsPerChild设置的是每个子进程可处理的请求数。 每个子进程在处理了“MaxRequestsPerChild”个请求后将自动销毁。 0意味着无限,即子进程永不销毁。 虽然缺省设为0可以使每个子进程处理更多的请求,但如果设成非零值也有两点重要的好处:◆ 可防止意外的内存泄漏;◆ 在服务器负载下降的时侯会自动减少子进程数。 因此,可根据服务器的负载来调整这个值。 个人认为左右比较合适。 MaxClients是这些指令中最为重要的一个,设定的是Apache可以同时处理的请求,是对Apache性能影响最大的参数。 其缺省值150是远远不够的,如果请求总数已达到这个值(可通过ps -ef|grep http|wc -l来确认),那么后面的请求就要排队,直到某个已处理请求完毕。 这就是系统资源还剩下很多而HTTP访问却很慢的主要原因。 系统管理员可以根据硬件配置和负载情况来动态调整这个值。 虽然理论上这个值越大,可以处理的请求就越多,但Apache默认的限制不能大于256。 如果把这个值设为大于256,那么Apache将无法起动。 事实上,256对于负载稍重的站点也是不够的。 在Apache 1.3中,这是个硬限制。 如果要加大这个值,必须在“configure”前手工修改的源代码树下的src/include/httpd.h中查找256,就会发现“#define HARD_SERVER_LIMIT 256”这行。 把256改为要增大的值(如4000),然后重新编译Apache即可。 在Apache 2.0中新加入了ServerLimit指令,使得无须重编译Apache就可以加大MaxClients。 下面是prefork配置段:StartServers 10 MinSpareServers 10 MaxSpareServers 15 ServerLimit 2000 MaxClients 1000 MaxRequestsPerChild 上述配置中,ServerLimit的最大值是2000,对于大多数站点已经足够。 如果一定要再加大这个数值,对位于源代码树下server/mpm/prefork/prefork.c中以下两行做相应修改即可:#define DEFAULT_SERVER_LIMIT 256#define MAX_SERVER_LIMIT 2000worker的工作原理及配置相对于prefork,worker是2.0 版中全新的支持多线程和多进程混合模型的MPM。 由于使用线程来处理,所以可以处理相对海量的请求,而系统资源的开销要小于基于进程的服务器。 但是,worker也使用了多进程,每个进程又生成多个线程,以获得基于进程服务器的稳定性。 这种MPM的工作方式将是Apache 2.0的发展趋势。 在configure -with-mpm=worker后,进行make编译、make install安装。 在缺省生成的中有以下配置段:StartServers 2 MaxClients 150 MinSparethreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0worker的工作原理是,由主控制进程生成“StartServers”个子进程,每个子进程中包含固定的ThreadsPerChild线程数,各个线程独立地处理请求。 同样,为了不在请求到来时再生成线程,MinSpareThreads和MaxSpareThreads设置了最少和最多的空闲线程数;而MaxClients设置了所有子进程中的线程总数。 如果现有子进程中的线程总数不能满足负载,控制进程将派生新的子进程。 MinSpareThreads和MaxSpareThreads的最大缺省值分别是75和250。 这两个参数对Apache的性能影响并不大,可以按照实际情况相应调节。 ThreadsPerChild是worker MPM中与性能相关最密切的指令。 ThreadsPerChild的最大缺省值是64,如果负载较大,64也是不够的。 这时要显式使用ThreadLimit指令,它的最大缺省值是。 上述两个值位于源码树server/mpm/worker/worker.c中的以下两行:#define DEFAULT_THREAD_LIMIT 64#define MAX_THREAD_LIMIT 这两行对应着ThreadsPerChild和ThreadLimit的限制数。 最好在configure之前就把64改成所希望的值。 注意,不要把这两个值设得太高,超过系统的处理能力,从而因Apache不起动使系统很不稳定。 Worker模式下所能同时处理的请求总数是由子进程总数乘以ThreadsPerChild值决定的,应该大于等于MaxClients。 如果负载很大,现有的子进程数不能满足时,控制进程会派生新的子进程。 默认最大的子进程总数是16,加大时也需要显式声明ServerLimit(最大值是)。 这两个值位于源码树server/mpm/worker/worker.c中的以下两行:#define DEFAULT_SERVER_LIMIT 16#define MAX_SERVER_LIMIT 需要注意的是,如果显式声明了ServerLimit,那么它乘以ThreadsPerChild的值必须大于等于MaxClients,而且MaxClients必须是ThreadsPerChild的整数倍,否则Apache将会自动调节到一个相应值(可能是个非期望值)。 下面是worker配置段:StartServers 3 MaxClients 2000 ServerLimit 25 MinSpareThreads 50 MaxSpareThreads 200 ThreadLimit 200 ThreadsPerChild 100 MaxRequestsPerChild 0通过上面的叙述,可以了解到Apache 2.0中prefork和worker这两个重要MPM的工作原理,并可根据实际情况来配置Apache相关的核心参数,以获得最大的性能和稳定性。

nginx配置文件中怎么把hostname的值赋给其它变量

Nginx 的配置文件使用的就是一门微型的编程语言,许多真实世界里的 Nginx 配置文件其实就是一个一个的小程序。 当然,是不是“图灵完全的”暂且不论,至少据我观察,它在设计上受 Perl 和 Bourne Shell 这两种语言的影响很大。 在这一点上,相比 Apache 和 Lighttpd 等其他 Web 服务器的配置记法,不能不说算是 Nginx 的一大特色了。 既然是编程语言,一般也就少不了“变量”这种东西(当然,Haskell 这样奇怪的函数式语言除外了)。 熟悉 Perl、Bourne Shell、C/C++ 等命令式编程语言的朋友肯定知道,变量说白了就是存放“值”的容器。 而所谓“值”,在许多编程语言里,既可以是 3.14 这样的数值,也可以是 hello world 这样的字符串,甚至可以是像数组、哈希表这样的复杂数据结构。 然而,在 Nginx 配置中,变量只能存放一种类型的值,因为也只存在一种类型的值,那就是字符串。 比如我们的 文件中有下面这一行配置:set $a hello world;我们使用了标准 ngx_rewrite 模块的 set 配置指令对变量 $a 进行了赋值操作。 特别地,我们把字符串 hello world 赋给了它。 我们看到,Nginx 变量名前面有一个 $ 符号,这是记法上的要求。 所有的 Nginx 变量在 Nginx 配置文件中引用时都须带上 $ 前缀。 这种表示方法和 Perl、PHP 这些语言是相似的。 虽然 $ 这样的变量前缀修饰会让正统的 Java 和 C# 程序员不舒服,但这种表示方法的好处也是显而易见的,那就是可以直接把变量嵌入到字符串常量中以构造出新的字符串:set $a hello;set $b $a, $a;这里我们通过已有的 Nginx 变量 $a 的值,来构造变量 $b 的值,于是这两条指令顺序执行完之后,$a 的值是 hello,而 $b 的值则是 hello, hello. 这种技术在 Perl 世界里被称为“变量插值”(variable interpolation),它让专门的字符串拼接运算符变得不再那么必要。 我们在这里也不妨采用此术语。 我们来看一个比较完整的配置示例:server {listen 8080;location /test {set $foo hello;echo foo: $foo;}}这个例子省略了 配置文件中最外围的 http 配置块以及 events 配置块。 使用 curl 这个 HTTP 客户端在命令行上请求这个 /test 接口,我们可以得到$ curlhello这里我们使用第三方 ngx_echo 模块的 echo 配置指令将 $foo 变量的值作为当前请求的响应体输出。 我们看到,echo 配置指令的参数也支持“变量插值”。 不过,需要说明的是,并非所有的配置指令都支持“变量插值”。 事实上,指令参数是否允许“变量插值”,取决于该指令的实现模块。 如果我们想通过 echo 指令直接输出含有“美元符”($)的字符串,那么有没有办法把特殊的 $ 字符给转义掉呢?答案是否定的(至少到目前最新的 Nginx 稳定版 1.0.10)。 不过幸运的是,我们可以绕过这个限制,比如通过不支持“变量插值”的模块配置指令专门构造出取值为 $ 的 Nginx 变量,然后再在 echo 中使用这个变量。 看下面这个例子:geo $dollar {default $;}server {listen 8080;location /test {echo This is a dollar sign: $dollar;}}测试结果如下:$ curlis a dollar sign: $这里用到了标准模块 ngx_geo 提供的配置指令 geo 来为变量 $dollar 赋予字符串 $,这样我们在下面需要使用美元符的地方,就直接引用我们的 $dollar 变量就可以了。 其实 ngx_geo 模块最常规的用法是根据客户端的 IP 地址对指定的 Nginx 变量进行赋值,这里只是借用它以便“无条件地”对我们的 $dollar 变量赋予“美元符”这个值。 在“变量插值”的上下文中,还有一种特殊情况,即当引用的变量名之后紧跟着变量名的构成字符时(比如后跟字母、数字以及下划线),我们就需要使用特别的记法来消除歧义,例如:server {listen 8080;location /test {set $first hello ;echo ${first}world;}}这里,我们在 echo 配置指令的参数值中引用变量 $first 的时候,后面紧跟着 world 这个单词,所以如果直接写作 $firstworld 则 Nginx “变量插值”计算引擎会将之识别为引用了变量 $firstworld. 为了解决这个难题,Nginx 的字符串记法支持使用花括号在 $ 之后把变量名围起来,比如这里的 ${first}. 上面这个例子的输出是:$ curlworldset 指令(以及前面提到的 geo 指令)不仅有赋值的功能,它还有创建 Nginx 变量的副作用,即当作为赋值对象的变量尚不存在时,它会自动创建该变量。 比如在上面这个例子中,如果 $a 这个变量尚未创建,则 set 指令会自动创建 $a 这个用户变量。 如果我们不创建就直接使用它的值,则会报错。 例如server {listen 8080;location /bad {echo $foo;}}此时 Nginx 服务器会拒绝加载配置:1[emerg] unknown foo variable是的,我们甚至都无法启动服务!有趣的是,Nginx 变量的创建和赋值操作发生在全然不同的时间阶段。 Nginx 变量的创建只能发生在 Nginx 配置加载的时候,或者说 Nginx 启动的时候;而赋值操作则只会发生在请求实际处理的时候。 这意味着不创建而直接使用变量会导致启动失败,同时也意味着我们无法在请求处理时动态地创建新的 Nginx 变量。 Nginx 变量一旦创建,其变量名的可见范围就是整个 Nginx 配置,甚至可以跨越不同虚拟主机的 server 配置块。 我们来看一个例子:server {listen 8080;location /foo {echo foo = [$foo];}location /bar {set $foo 32;echo foo = [$foo];}}这里我们在 location /bar 中用 set 指令创建了变量 $foo,于是在整个配置文件中这个变量都是可见的,因此我们可以在 location /foo 中直接引用这个变量而不用担心 Nginx 会报错。 下面是在命令行上用 curl 工具访问这两个接口的结果:$ curl= []$ curl= [32]$ curl= []从这个例子我们可以看到,set 指令因为是在 location /bar 中使用的,所以赋值操作只会在访问 /bar 的请求中执行。 而请求 /foo 接口时,我们总是得到空的 $foo 值,因为用户变量未赋值就输出的话,得到的便是空字符串。 从这个例子我们可以窥见的另一个重要特性是,Nginx 变量名的可见范围虽然是整个配置,但每个请求都有所有变量的独立副本,或者说都有各变量用来存放值的容器的独立副本,彼此互不干扰。 比如前面我们请求了 /bar 接口后,$foo 变量被赋予了值 32,但它丝毫不会影响后续对 /foo 接口的请求所对应的 $foo 值(它仍然是空的!),因为各个请求都有自己独立的 $foo 变量的副本。 对于 Nginx 新手来说,最常见的错误之一,就是将 Nginx 变量理解成某种在请求之间全局共享的东西,或者说“全局变量”。 而事实上,Nginx 变量的生命期是不可能跨越请求边界的。

本文版权声明本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,请联系本站客服,一经查实,本站将立刻删除。

发表评论

热门推荐