如何收集 NGINX 指标(第二篇)

如何收集 NGINX 指标(第二篇)
如何收集 NGINX 指标(第二篇)

如何获取你所需要的 NGINX 指标

如何获取需要的指标取决于你正在使用的 NGINX 版本以及你希望看到哪些指标。(参见 如何监控 NGINX(第一篇) 来深入了解NGINX指标。)自由开源的 NGINX 和商业版的 NGINX Plus 都有可以报告指标度量的状态模块,NGINX 也可以在其日志中配置输出特定指标:

指标可用性

指标 NGINX (开源) NGINX Plus NGINX 日志
accepts(接受) / accepted(已接受) x x  
handled(已处理) x x  
dropped(已丢弃) x x  
active(活跃) x x  
requests (请求数)/ total(全部请求数) x x  
4xx 代码   x x
5xx 代码   x x
request time(请求处理时间)     x

指标收集:NGINX(开源版)

开源版的 NGINX 会在一个简单的状态页面上显示几个与服务器状态有关的基本指标,它们由你启用的 HTTP stub status module 所提供。要检查该模块是否已启用,运行以下命令:

nginx -V 2>&1 | grep -o with-http_stub_status_module

如果你看到终端输出了 httpstubstatus_module,说明该状态模块已启用。

如果该命令没有输出,你需要启用该状态模块。你可以在从源代码构建 NGINX 时使用 –with-http_stub_status_module 配置参数:

./configure
…
--with-http_stub_status_module
make
sudo make install

在验证该模块已经启用或你自己启用它后,你还需要修改 NGINX 配置文件,来给状态页面设置一个本地可访问的 URL(例如: /nginx_status):

server {
    location /nginx_status {
        stub_status on;

        access_log off;
        allow 127.0.0.1;
        deny all;
    }
}

注:nginx 配置中的 server 块通常并不放在主配置文件中(例如:/etc/nginx/nginx.conf),而是放在主配置会加载的辅助配置文件中。要找到主配置文件,首先运行以下命令:

nginx -t

打开列出的主配置文件,在以 http 块结尾的附近查找以 include 开头的行,如:

include /etc/nginx/conf.d/*.conf;

在其中一个包含的配置文件中,你应该会找到主 server 块,你可以如上所示配置 NGINX 的指标输出。更改任何配置后,通过执行以下命令重新加载配置文件:

nginx -s reload

现在,你可以浏览状态页看到你的指标:

Active connections: 24
server accepts handled requests
1156958 1156958 4491319
Reading: 0 Writing: 18 Waiting : 6

请注意,如果你希望从远程计算机访问该状态页面,则需要将远程计算机的 IP 地址添加到你的状态配置文件的白名单中,在上面的配置文件中的白名单仅有 127.0.0.1。

NGINX 的状态页面是一种快速查看指标状况的简单方法,但当连续监测时,你需要按照标准间隔自动记录该数据。监控工具箱 Nagios 或者 Datadog,以及收集统计信息的服务 collectD 已经可以解析 NGINX 的状态信息了。

指标收集: NGINX Plus

商业版的 NGINX Plus 通过它的 ngxhttpstatus_module 提供了比开源版 NGINX 更多的指标。NGINX Plus 以字节流的方式提供这些额外的指标,提供了关于上游系统和高速缓存的信息。NGINX Plus 也会报告所有的 HTTP 状态码类型(1XX,2XX,3XX,4XX,5XX)的计数。一个 NGINX Plus 状态报告例子可在此查看

如何收集 NGINX 指标(第二篇)
如何收集 NGINX 指标(第二篇)

注:NGINX Plus 在状态仪表盘中的“Active”连接的定义和开源 NGINX 通过 stubstatusmodule 收集的“Active”连接指标略有不同。在 NGINX Plus 指标中,“Active”连接不包括Waiting状态的连接(即“Idle”连接)。

NGINX Plus 也可以输出 JSON 格式的指标,可以用于集成到其他监控系统。在 NGINX Plus 中,你可以看到 给定的上游服务器组的指标和健康状况,或者简单地从上游服务器的单个服务器得到响应代码的计数:

{"1xx":0,"2xx":3483032,"3xx":0,"4xx":23,"5xx":0,"total":3483055}

要启动 NGINX Plus 指标仪表盘,你可以在 NGINX 配置文件的 http 块内添加状态 server 块。 (参见上一节,为收集开源版 NGINX 指标而如何查找相关的配置文件的说明。)例如,要设置一个状态仪表盘 (http://your.ip.address:8080/status.html)和一个 JSON 接口(http://your.ip.address:8080/status),可以添加以下 server 块来设定:

server {
    listen 8080;
    root /usr/share/nginx/html;

    location /status {
        status;
    }

    location = /status.html {
    }
}

当你重新加载 NGINX 配置后,状态页就可以用了:

nginx -s reload

关于如何配置扩展状态模块,官方 NGINX Plus 文档有 详细介绍

指标收集:NGINX 日志

NGINX 的 日志模块 会把可自定义的访问日志写到你配置的指定位置。你可以通过添加或移除变量来自定义日志的格式和包含的数据。要存储详细的日志,最简单的方法是添加下面一行在你配置文件的 server 块中(参见上上节,为收集开源版 NGINX 指标而如何查找相关的配置文件的说明。):

access_log logs/host.access.log combined;

更改 NGINX 配置文件后,执行如下命令重新加载配置文件:

nginx -s reload

默认包含的 “combined” 的日志格式,会包括一系列关键的数据,如实际的 HTTP 请求和相应的响应代码。在下面的示例日志中,NGINX 记录了请求 /index.html 时的 200(成功)状态码和访问不存在的请求文件 /fail 的 404(未找到)错误。

127.0.0.1 - - [19/Feb/2015:12:10:46 -0500] "GET /index.html HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari 537.36"

127.0.0.1 - - [19/Feb/2015:12:11:05 -0500] "GET /fail HTTP/1.1" 404 570 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36"

你可以通过在 NGINX 配置文件中的 http 块添加一个新的日志格式来记录请求处理时间:

log_format nginx '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent $request_time '
                 '"$http_referer" "$http_user_agent"';

并修改配置文件中 server 块的 access_log 行:

access_log logs/host.access.log nginx;

重新加载配置文件后(运行 nginx -s reload),你的访问日志将包括响应时间,如下所示。单位为秒,精度到毫秒。在这个例子中,服务器接收到一个对 /big.pdf 的请求时,发送 33973115 字节后返回 206(成功)状态码。处理请求用时 0.202 秒(202毫秒):

127.0.0.1 - - [19/Feb/2015:15:50:36 -0500] "GET /big.pdf HTTP/1.1" 206 33973115 0.202 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36"

你可以使用各种工具和服务来解析和分析 NGINX 日志。例如,rsyslog 可以监视你的日志,并将其传递给多个日志分析服务;你也可以使用自由开源工具,比如 logstash 来收集和分析日志;或者你可以使用一个统一日志记录层,如 Fluentd 来收集和解析你的 NGINX 日志。

结论

监视 NGINX 的哪一项指标将取决于你可用的工具,以及监控指标所提供的信息是否满足你们的需要。举例来说,错误率的收集是否足够重要到需要你们购买 NGINX Plus ,还是架设一个可以捕获和分析日志的系统就够了?

在 Datadog 中,我们已经集成了 NGINX 和 NGINX Plus,这样你就可以以最小的设置来收集和监控所有 Web 服务器的指标。在本文中了解如何用 NGINX Datadog 来监控 ,并开始 Datadog 的免费试用吧。


via: https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/

作者:K Young 译者:strugglingyouth 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

来源:https://linux.cn/article-5985-1.html

Linux:Linux常见问题解答–如何修复"tar:由于前一个错误导致于失败状态中退出"

问题: 当我想试着用tar命令来创建一个压缩文件时,总在执行过程中失败,并且抛出一个错误说明”tar:由于前一个错误导致于失败状态中退出”(“Exiting with failure status due to previous errors”). 什么导致这个错误的发生,要如何解决?

Linux:Linux常见问题解答--如何修复"tar:由于前一个错误导致于失败状态中退出"
Linux:Linux常见问题解答–如何修复"tar:由于前一个错误导致于失败状态中退出"

如果当你执行tar命令时,遇到了下面的错误,那么最有可能的原因是对于你想用tar命令压缩的某个文件中,你并不具备其读权限。

tar: Exiting with failure status due to previous errors

那么我们要如何确定引起错误的这个(些)文件呢?或者如何确定其它的错误根源?

事实上tar命令应该会打印出所谓的“上一个错误”(“previous errors”)到底是什么错误,但是如果你让tar运行在详细模式(即verbose mode,例如, -cvf),那么你会很容易错失这些信息。要找到这些信息,你可以像下面那样,把tar的标准输出(stdout)信息过滤掉。

$ tar cvzfz backup.tgz my_program/ > /dev/null

然后你会看到tar输出的标准错误(stderr)信息。(LCTT 译注:自然,不用 v 参数也可以。)

tar: my_program/src/lib/.conf.db.~lock~: Cannot open: Permission denied
tar: Exiting with failure status due to previous errors

你可以从上面的例子中看到,引起错误的原因的确是“读权限不允许”(denied read permission.)要解决这个问题,只要简单地更改(或移除)问题文件的权限,然后重新执行tar命令即可。


via: http://ask.xmodulo.com/tar-exiting-with-failure-status-due-to-previous-errors.html

作者:Dan Nanni 译者:XLCYun(袖里藏云) 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

来源:https://linux.cn/article-5817-1.html

Linux:使用 varnish + nginx + lua 搭建网站的降级系统

前言

通常一个网站数据库挂掉后,后果将是非常严重的。基本上整个网站基本不可用了。对于一些网站来说,当数据库挂掉后,如果能提供基本的浏览服务,也是不错的。本文将尝试使用 varnish + nginx + lua 搭建网站降级系统来实现整个目标。

Linux:使用 varnish + nginx + lua 搭建网站的降级系统
Linux:使用 varnish + nginx + lua 搭建网站的降级系统

降级目标

降级方案的目标是,当网站出现致命故障时(如出现500错误,不能提供服务),可以把缓存的页面数据展现给用户。从而提供基本的浏览服务。

  1. 只提供基本的浏览服务
  2. 浏览的数据都是非登录状态下的数据
  3. 支持手动和自动降级。自动降级是当后端返回500错误次数在一段时间内达到一定阈值(不包含503)。手动降级是从控制界面操作。

降级方案

存储

使用varnish作为存储。有效的节约了物理内存,并保持了较好的性能。

更新

使用crond脚本从nginx的access日志中分析出请求url,然后向varnish发请求,从而更新varnish的缓存。缓存的异步更新,减少对nginx的压力。

降级

支持手动降级和自动降级。降级后,nginx自动从varnish中提取数据,并返回给用户。

流程图

Linux:使用 varnish + nginx + lua 搭建网站的降级系统
Linux:使用 varnish + nginx + lua 搭建网站的降级系统

流程描述

  1. 用户请求到nginx时,nginx会判断当前是否是降级状态。如果属于降级状态,直接从varnish中获取数据。非降级状态,把请求转到php-fpm。
  2. 当crond脚本请求varnish进行缓存数据更新时,如果当前varnish处于降级状态,则不进行缓存更新。如果没有处在降级状态,则把请求转到nginx,获取数据。然后把获取的数据缓存到varnish中。
  3. varnish会自动监控后端nginx的状态。如果检测到nginx已经处于降级状态,则varnish也会自动进入降级状态。

安装部署

vanish安装到/home/varnish 目录下。安装步骤如下:

首先,安装libpcre。

sudo yum install pcre pcre-devel

其次,安装varnish。

./configure --prefix=/home/varnish
make
sudo -u admin make install
sudo -u admin mkdir -p /home/varnish/vcache/
sudo chown admin:admin -R /home/varnish
sudo -u admin touch /home/varnish/vcache/varnish_cache.data
sudo chmod 777 /home/varnish/vcache/varnish_cache.data

再次,修改varnish配置文件和部署相关脚本。点击下载文件压缩包。配置文件名为default.vcl。

最后,启动varnish。启动脚本也在压缩包中,名称为 varnishctl

sudo /home/admin/varnish/sbin/varnishctl start

注意:启动后可以通过varnishlog命令查看是否运行正常。如果出现以下字样,说明运行正常。http的返回状态为200

$ /home/varnish/bin/varnishlog
0 Backend_health - default Still healthy 4--X-RH 4 2 4 0.002698 0.001722 HTTP/1.1 200 OK

部署lua脚本

lua脚本在/home/admin/nginx/data/lua目录下。 确保目录下有如下几个个脚本。

pc_get_downgrade_data.lua
init.lua
pc_status_stat.lua
pc_get_status.lua
pc_set_satus.lua

这几个脚本在下载的压缩包中有。

修改nginx配置文件

首先,在http域增加

init_by_lua_file 'lua/init.lua';
lua_shared_dict pc_status 1m;
lua_shared_dict pc_auto_status 1m;
#varnish config
upstream varnish{
    server 127.0.0.1:8080 weight=1 max_fails=2 fail_timeout=5s;
}

最后,在server域宏增加如下配置。

location @php {
  include fastcgi_params;
}
location @var {
 proxy_pass http://varnish$str_params;
}
location ~* ^(.+.php)(.*)$ {
  #check downgrade status, then get data from varnish
  set $str_params $uri;
  content_by_lua_file lua/pc_get_downgrade_data.lua;
}
location /hl_get_auto_status {
           if ($white_ip = 0) {
               return 403;
           }
           content_by_lua_file lua/pc_get_auto_status.lua;
 }
location /hl_get_status {
     if ($white_ip = 0) {
         return 403;
     }
     content_by_lua_file lua/pc_get_status.lua;
}
location /hl_set_status {
           if ($white_ip = 0) {
               return 403;
           }
           content_by_lua_file lua/pc_set_status.lua;
}

log_by_lua_file  lua/pc_status_stat.lua;

部署crond脚本

脚本varnish_crond.php。在crond中增加执行命令。每分钟执行一次。

来自crond的请求,user-agent数据为varnish_crond。把user-agent为varnish_crond请求特殊处理。保证能正常请求,并返回相关数据。

降级管理

varnish降级

只要让varnish配置中指定的监控脚本check.php返回500错误即可。varnish监控到指定脚本不可用,自动会进入降级状态。当脚本返回200状态后,varnish自动又会恢复正常。

nginx降级

设置降级:

curl -H "Host:demo.bo56.com" -i http://127.0.0.1/hl_set_status?status=1

恢复正常:

curl -H "Host:demo.bo56.com" -i http://127.0.0.1/hl_set_status?status=0

查看降级状态:

curl -H "Host:demo.bo56.com" -i http://127.0.0.1/hl_get_status

如果返回的值为1表示降级。

来源:http://www.bo56.com/%E4%BD%BF%E7%94%A8varnish-nginx-lua%E6%90%AD%E5%BB%BA%E7%BD%91%E7%AB%99%E7%9A%84%E9%99%8D%E7%BA%A7%E7%B3%BB%E7%BB%9F/

Linux:Linux 下查看某一个程序所使用的内存方法

在 Linux 上进行开发和运营维护的时候,免不了要查看某一个程序所占用内存的情况。有很多个命令都可以达到我们的需求,这里给大家列举几个:

1:

top -p pid 查看程序的情况

2:

ps -aux | grep process_name

3:

cat /proc/pid/status

  这里会打印出当前进程详细的情况,其中,内存是 VmRSS。

Linux:Iptables DDOS/CC 自动屏蔽脚本

最近不停地被 CC (DDOS的一种)频繁干扰,分享一个 iptables 屏蔽 DDOS 的脚本。 

让 crond 每分钟运行一次。

############### KILL DDOS ##############
iptables_log="/data/logs/iptables_conf.log"
### Iptables 配置导出的路径,可任意修改 ###
########################################
status=`netstat -na|awk '$5 ~ /[0-9]+:[0-9]+/ {print $5}'|awk -F ":" -- '{print $1}' |sort -n|uniq -c |sort -n|grep -v 127.0.0.1|tail -n 1`
NUM=`echo $status|awk '{print $1}'`
IP=`echo $status|awk '{print $2}'`
result=`echo "$NUM > 200" | bc`
### 如果同时连接数大于 200 则干掉!###
if [[ $result = 1 ]]
then
echo IP:$IP is over $NUM, BAN IT!
/sbin/iptables -A INPUT -s $IP -j DROP
fi
########################################
iptables-save > ${iptables_log}
### 输出当前的 iptable 配置作为日志 ###
########################################

有朋友指出,“ 這個腳本裏應該把tail -n 1和grep -v 127.0.0.1倒一倒,否則有些情況下會完全不起作用的”,所以对原脚本有修改。

via http://www.linuxde.net/2013/05/13538.html

Linux:Linux 系统中僵尸进程

  Linux 系统中僵尸进程和现实中僵尸(虽然我也没见过)类似,虽然已经死了,但是由于没人给它们收尸,还能四处走动。僵尸进程指的是那些虽然已经终止的进程,但仍然保留一些信息,等待其父进程为其收尸。

僵尸进程如何产生的?

  如果一个进程在其终止的时候,自己就回收所有分配给它的资源,系统就不会产生所谓的僵尸进程了。那么我们说一个进程终止之后,还保留哪些信息?为什么终止之后还需要保留这些信息呢?

  一个进程终止的方法很多,进程终止后有些信息对于父进程和内核还是很有用的,例如进程的ID号、进程的退出状态、进程运行的CPU时间等。因此进程 在终止时,回收所有内核分配给它的内存、关闭它打开的所有文件等等,但是还会保留以上极少的信息,以供父进程使用。父进程可以使用 wait/waitpid 等系统调用来为子进程收拾,做一些收尾工作。

  因此,一个僵尸进程产生的过程是:父进程调用fork创建子进程后,子进程运行直至其终止,它立即从内存中移除,但进程描述符仍然保留在内存中(进程描述符占有极少的内存空间)。子进程的状态变成EXIT_ZOMBIE,并且向父进程发送SIGCHLD 信号,父进程此时应该调用 wait() 系 统调用来获取子进程的退出状态以及其它的信息。在 wait 调用之后,僵尸进程就完全从内存中移除。因此一个僵尸存在于其终止到父进程调用 wait 等函数这个时间的间隙,一般很快就消失,但如果编程不合理,父进程从不调用 wait 等系统调用来收集僵尸进程,那么这些进程会一直存在内存中。

  在 Linux 下,我们可以使用 ps 等命令查看系统中僵尸进程,僵尸进程的状态标记为‘Z’:

Linux:Linux 系统中僵尸进程
Linux:Linux 系统中僵尸进程

产生一个僵尸进程

  根据上面的描述,我们很容易去写一个程序来产生僵尸进程,如下代码:

#include #include int main(){    //fork a child process    pid_t pid = fork();    if (pid > 0)   //parent process    {        printf(“in parent process, sleep for one miniute…zZ…n”);        sleep(60);        printf(“after sleeping, and exit!n”);    }    else if (pid == 0)      {        //child process exit, and to be a zombie process        printf(“in child process, and exit!n”);        exit(0);    }    return 0;}

  父进程并没有写 wait 等系统调用函数,因此在子进程退出之后变成僵尸进程,父进程并没有为其去收尸。我们使用下面命令编译运行该进程,然后查看系统中进程状态:

guohailin@guohailin:~/Documents$ gcc zombie.c -o zombieguohailin@guohailin:~/Documents$ ./zombie in parent process, sleep for one miniute…zZ…in child process, and exit!# 打开另一个终端:guohailin@guohailin:~$ ps aux | grep -w ‘Z’1000      2211  1.2  0.0      0     0 ?        Z    13:24   6:53 [chromium-browse] 1000      4400  0.0  0.0      0     0 ?        Z    10月16   0:00 [fcitx] 1000     10871  0.0  0.0      0     0 pts/4    Z+   22:32   0:00 [zombie]

  父进程并没有写 wait 等系统调用函数,因此在子进程退出之后变成僵尸进程,父进程并没有为其去收尸。我们使用下面命令编译运行该进程,然后查看系统中进程状态:

guohailin@guohailin:~/Documents$ gcc zombie.c -o zombieguohailin@guohailin:~/Documents$ ./zombie in parent process, sleep for one miniute…zZ…in child process, and exit!# 打开另一个终端:guohailin@guohailin:~$ ps aux | grep -w ‘Z’1000      2211  1.2  0.0      0     0 ?        Z    13:24   6:53 [chromium-browse] 1000      4400  0.0  0.0      0     0 ?        Z    10月16   0:00 [fcitx] 1000     10871  0.0  0.0      0     0 pts/4    Z+   22:32   0:00 [zombie]

  从上面可以看出,系统中多了一个僵尸进程。但如果等父进程睡眠醒来退出之后,我们再次查看系统进程信息,发现刚才的僵尸进程不见了。

guohailin@guohailin:~/Documents$ ./zombie in parent process, sleep for one miniute…zZ…in child process, and exit!after sleeping, and exit!guohailin@guohailin:~/Documents$ ps aux | grep -w ‘Z’1000      2211  1.2  0.0      0     0 ?        Z    13:24   6:53 [chromium-browse] 1000      4400  0.0  0.0      0     0 ?        Z    10月16   0:00 [fcitx]

  这是为什么呢?父进程到死都也没有为其子进程收尸呀,怎么父进程退出之后,那个僵尸进程就消失了呢?难道父进程在退出时会为子进程收拾吗?其实不 然….真正的原因是:父进程死掉之后,其所有子进程过继给 init 进程,init 进程成为该僵尸进程的新进程,init 进程会周期性地去调用 wait 系统调用来清除它的僵尸孩子。因此,你会发现上面例子中父进程死掉之后,僵尸进程也跟着消失,其实是 init 进程为其收尸的!

怎样避免僵尸进程的产生

  不能使用 kill 后接 SIGKILL 信号这样的命令像杀死普通进程一样杀死僵尸进程,因为僵尸进程是已经死掉的进程,它不能再接收任何信号。事实上,如果系统中僵尸进程并不多的话,我们也无需去消除它们,少数的僵尸进程并不会对系统的性能有什么影响。

  那么在编程时,如果能避免系统中大量产生僵尸进程呢?根据上面描述的,子进程在终止时会向父进程发 SIGCHLD 信号,Linux 默认是忽略该信号的,我们可以显示安装该信号,在信号处理函数中调用 wait 等函数来为其收尸,这样就能避免僵尸进程长期存在于系统中了。示例代码如下:

#include #include #include #include #include sig_atomic_t child_exit_status;void clean_up_child_process(int signal_num){    /* clean up child process */    int status;    wait (&status);    /* store its exit status in a global variable */    child_exit_status = status;}int main(){    /* handle SIGCHLD by calling clean_up_child_process  */    struct sigaction sigchild_action;    memset(&sigchild_action, 0, sizeof(sigchild_action));    sigchild_action.sa_handler = &clean_up_child_process;    sigaction(SIGCHLD, &sigchild_action, NULL);    /* fork a child, and let the child process dies before parent */    pid_t c_pid;    c_pid = fork();    if (c_pid > 0)    {        printf(“in parent process, and sleep for on mininute…zZ…n”);        sleep(60);    }    else if(c_pid == 0)    {        printf(“in child process, and exit nown”);        exit(0);    }    else    {        printf(“fork failed!n”);    }    return 0;}  

参考资料

 

文章来自:http://www.cnblogs.com/hazir/p/zombie_process.html

Linux:Linux 面试基础问题 – 3

在有关面试问题的这一系列话题的前两篇文章中,我们收到了许多好的反馈,在此表示极大的感谢,同时,我们将延续这一系列话题。在这里,我们将再次展示10个问题来进行相互学习。

Linux:Linux 面试基础问题 - 3
Linux:Linux 面试基础问题 – 3

Q.1. 你如何向你的系统中添加一个新的用户(例如,tux)?

  • 使用useradd指令
  • 使用adduser 指令
  • 使用linuxconf指令
  • 以上全是
  • 以上答案全都不对

: 以上全是,即useradd, adduser 和 linuxconf 都可向你的linux系统添加新用户。

Q.2. 在一个硬盘上,可能有多少主分区?

  • 1
  • 2
  • 4
  • 16

: 一个硬盘上最多可能有4个主分区。

Q.3. Apache/Http 的默认端口号是多少?

  • 8080
  • 80
  • 8443
  • 91
  • 以上答案全都不对

: Apache/Http默认配置是80端口

Q.4. GNU代表什么?

  • GNU’s not Unix
  • General Unix
  • General Noble Unix
  • Greek Needed Unix
  • 以上答案全都不对

: GNU意为GNU’s not Unix.

Q.5. 如果你在shell提示符中输入mysql并得到“can’t connect to local MySQL server through socket ‘/var/mysql/mysql.sock’ ”的提示,你首先应该检查什么?

: 看到这条错误消息,我首先会使用service mysql status或者service mysqld status指令来检查mysql服务是否正在运行。如果mysql服务没有运行,就启动所需服务。

注意:上面的错误消息可能是由于my.cnf或者mysql的用户权限错误配置导致的。如果启动mysql服务之后仍不管用,你需要检查这两项。

Q.6. 如何将windows ntfs分区挂载到Linux上面?

: 首先,使用apt或者yum工具安装ntfs3g包,然后使用 “sudo mount ­t ntfs­3g /dev/ /<挂载点­>” 命令来将windows分区挂载到Linux上面

Q.7. 下面哪一个不是基于RPM的操作系统?

  • RedHat Linux
  • Centos
  • Scientific Linux
  • Debian
  • Fedora

: ‘Debian’ 系统不是基于RPM的,其它的几个都是

Q.8. Linux中,哪一个指令用来重命名文件?

  • mv
  • ren
  • rename
  • change
  • 以上答案全都不对

: 在Linux中,mv 指令用来重命名一个文件。例如:mv /pathtoFile/originalfilename.extension /PathtoFile/New_name.extension

Q.9. 在Linux中,哪个命令用来创建并显示文件?

  • ed
  • vi
  • cat
  • nano
  • 以上答案全都不对

答 : ‘cat‘ 命令用来创建并且显示文件

10. 哪层协议用于支持用户和程序,如支持密码、资源分享、文件传输和网络管理?

  • 第四层协议
  • 第五层协议
  • 第六层协议
  • 第七层协议
  • 以上答案全都不对

答案 : ‘第七层协议

 


via: http://www.tecmint.com/linux-interview-questions-and-answers-for-linux-beginners/

译者:tomatoKiller 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

来源:https://linux.cn/article-2371-1.html

Linux:15分钟学会使用Git和远程代码库

Git是个了不起但却复杂的源代码管理系统。它能支持复杂的任务,却因此经常被认为太过复杂而不适用于简单的日常工作。让我们诚实一记吧:Git是复杂的,我们不要装作它不是。但我仍然会试图教会你用(我的)基本的Git和远程代码库干活的工作步骤,在15分钟内。

工作步骤

我会展示以下的步骤,通常能帮我独自在一台或多台机器上做项目。
 
  1. 创建一个远程的空代码库(在BitBucket上)
  2. 在本地代码库添加一个项目
  3. 在分支上开发新功能
  4. a) 保留新功能 或者 b) 丢弃它们
  5. 也许,回到某个早先的时间点
  6. 将本地代码库推送到远程代码库
  7. 在另一台机器上取得远程代码库

安装Git

在大多数*nix系统(Linux、OS X)上,Git已经被安装了。你通过发送下面的命令,可以通过Git自身,把它更新到最新的的开发版本(不推荐)。
 
git clone https://github.com/git/git
 
在Windows上,你可以在这里下载Git的安装程序。如果你真的需要其他系统的安装程序,Mac OS X安装文件在这里,Linux的操作指导在这里

创建一个远程代码库

很多人喜欢用Github。我个人更喜欢BitBucket,因为它提供了不限制的私有代码库,那是我最需要的。你可以将下列指令转换到Github上,这些过程是相同的。
那么,去到www.bitbucket.org并注册一个账号。一旦完成,登录后点击最上方的“create(创建)”按钮。照着填写表格,勾选私有代码库。你可不想让其他人来偷窥你的Facebook的杀手级应用的源代码,对吧。
 你现在可以离开BitBucket了,我们在已经有了所有那里需要的东西了。

设置Git

在我们能用Git工作之前,我们需要做个一次性的配置。为了Git能跟踪到谁做了修改,我们需要设置你的用户名。我强烈建议你使用与注册BitBucket账号相同的用户名和电子邮箱地址。发送这些命令,相应地替换掉其中的“your_username”和“your_email@domain.com”(注意引号):
 
git config –global user.name”your_username”
git config –global user.email your_email@domain.com
 
我们也会设定推送(push)的默认值为‘simple’。要了解这是什么意思,快速阅读我之前发布的关于推送的默认值(非必须)。发送这条命令:
 
git config –global push.default simple
 
我们都设好了。你无需在你的机器上再重复这些配置,但如果你在另一台机器上工作的话,不要忘记这些配置。如果你忘记做初始的配置,Git不会允许你提交任何东西,这会让你困扰。

创建一个本地代码库

作为例子,我们会假装我们有一个网站(无所谓技术)存在于我们机器上的‘workspace’文件夹下的’my_site’文件夹内。在命令行中,去到你的站点的根文件夹。在OS X和Linux上:
 
cd~/workspace/my_site/
 
在Windows上:
 
cdc:workspacemy_site
 
我们首先需要告诉Git这个文件夹是我们需要跟踪的项目。所以我们发送这个命令来初始化一个新的本地Git代码库
 
git init
 
Git会在my_site文件夹内创建一个名为.git的隐藏文件夹,那就是你的本地代码库。

加载(Stage)文件

我们现在需要命令Git我们需要加载(stage)所有项目文件。发送:
 
git add .
 
最后的“.”符号的意思是“所有文件、文件夹和子文件夹”。假如我们只想要把特定文件添加到源代码控制中去,我们可以指定它们:
 
git add my_file, my_other_file 

提交文件

现在,我们想要提交已加载(staged)的文件。阅读“添加一个时间点,在这里你的文件处在一个可还原的状态”。我们提交我们的文件时,总是附带着有意义的注释,描述了它们现在的状态。我一直用“initial commit”来作为第一个提交的注释。
 
git commit -m”initial commit”
 
就这样。现在你随时都可以回滚到这个提交状态。如果你有需要检查你现在的已加载(staged)和未加载(unstaged)文件的状态、提交等,你可以询问git的状态:
 
git status

创建分支

建立分支是你创建代码的独立版本的动作,独立于你的主干分支。默认地,每次你提交到Git的文件都会被储存到“master(主干)”分支。
现在我们来说说,你想要向项目里添加一个功能,但你想要能够回滚到现在版本,以防出现差错,或者你决定要放弃这个功能。这就是你创建分支的时候了。创建并同时切换到你新建的分支,发送:
 
git checkout -b new_feature
 
或者,你可以先创建一个分支然后手动切换,就像这样:
 
git branch new_featuregit checkout new_feature
 
要看你现在项目下所有的分支,发送这个:
 
git branch
 
现在你可以在你的项目上无所顾忌地做任何你想做的:任何时候,你都可以回到你创建分支前的状态。注意,你同时可以有多个分支,甚至可以从一个分支上再创建一个分支。 

合并分支

当你对你的新功能满意了的时候,你想要把它加到主干分支上。当你在你的新功能分支上时,你首先需要加载(stage)并且提交你的文件:
 
git add .git commit -m”adds my new feature”
 
然后你移到你的主干分支:
 
git checkout master
 
像这样合并:
 
git merge new_feature
 
此时,你的主干分支和你的新功能分支会变成一样的了。

丢弃分支

相反,如果你打算丢弃你在分支里做的修改,你首先需要加载(stage)你的文件并且在分支里提交:
 
git add .git commit -m”feature to be discarded”
 
然后,你移到主干分支:
 
git checkout master
 
现在,你的代码处于你创建分支之前的状态了。

删除一个分支

如果你要把你的分支合并到主干分支,从主干(master)分支上发送:
 
git branch -d new_feature
 
假如修改已经合并了,它只会删除分支。假如分支没有合并,你会得到一个错误信息。删除一个未合并的分支(通常你不想保留的修改),你需要发送一样的命令附带一个大写D。意思是“强制删除分支,无论如何我不想要它了。”:
 
git branch -D new_feature

回滚到之前的提交状态

在某些时候,你可能想要回到之前的代码版本。首先,你需要找到你想回到哪个版本。要看所有的完成了的提交,发送:
 
git log
 
这会输出你的提交的历史记录,像这样:
 
commit ca82a6dff817ec66f44342007202690a93763949Author: your_username your_email@domain.comDate:   Mon Nov 4 12:52:11 2013 -0700    changes the frontpage layout
commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7Author: your_username your_email@domain.comDate:   Mon Nov 4 11:40:33 2013 -0700    adds my new feature
commit a11bef06a3f659402fe7563abf99ad00de2209e6Author: your_username your_email@domain.comDate:   Mon Nov 4 10:37:28 2013 -0700    initial commit
 
如果你想回到“adds my new feature”这个提交,简单地用提交的ID做签出(checkout)(我通常只用到ID开头的9个字符)
 
git checkout 085bb3bcb
 
你也可以签出到一个新的分支,像这样:
 
git checkout -b my_previous_version 085bb3bcb
 
只是别太疯狂了!你的分支越复杂,就越难确定你真正在做什么。

推送到远程代码库

在第一次你想推送一个本地代码库到远程代码库时,你需要把它添加到你的项目配置里。像这样做:
 
git remote add origin https://your_username@bitbucket.org/your_username/name_of_remote_repository.git
 
注意这里的“origin”只是一个习惯。它是你的远程代码库的别名,但是你可以用其他任何你喜欢的词。你甚至可以有多个远程代码库,你只需要给它们起不同的别名。
之后,你想要推送你的本地代码库的主干分支到你的远程代码库:
 
git push origin master
 
如果你使用Bitbucket,在这时,你会被请求输入你的密码。照做,你的本地代码库会被推送到你的远程代码库上。

取得远程代码库的一份本地拷贝

如果你还没有一份远程代码库的本地版本(例如,如果你在另一台机器上开始工作,这台机器上还没有用过这个项目),你首先需要拷贝(clone)它。去到你的代码库想要拷贝到的文件夹下,并发送:
 
git clone https://your_username@bitbucket/your_username/name_of_remote_repository.git
 
另一方面,如果你已经在本地的项目上工作了,只是想从远程代码库上取得它最新的版本,移动到项目的根目录下,并发送:
 
git pull origin master

别名

Git允许你为你常用的命令创建快捷方式(别名)。例如,如果你不想每次都输入git commit -m “some comment”,而是输入git c “some comment”,你可以向你的git全局配置里添加一个别名来实现,像这样:
 
git config –globalalias.c’commit -m’
 
这是我使用的别名列表:
 
git config –globalalias.c’commit -m’
git config –globalalias.co’checkout’
git config –globalalias.cob’checkout -b’
git config –globalalias.br’branch’
git config –globalalias.m’merge’
git config –globalalias.a’add .’
git config –globalalias.s’status’
git config –globalalias.dbr’branch -d’

进一步

当然,还有比这些更多的Git内容。如果你想要更了解Git,我推荐官方文档和教程,你可以在http://git-scm.com/documentation找到。
有任何建议、技巧和问题?在下面留言!

 

原文链接: Nico   翻译: 伯乐在线 – cjpan译文链接: http://blog.jobbole.com/53573/

python中自动化配置Nginx服务器的反向代理

python中自动化配置Nginx服务器的反向代理是如何来实现的呢?下面的内容将会通过具体的实例来演示python中自动化配置Nginx服务器的反向代理的实现方法及相关技巧:

2015628104630354.png (640×479)

如果可以减少过多的外部隔离的API和简化部署的细节 这会是非常好的。

在以前的文章中,我解释了”一些使用反向代理的好处”。在我目前的项目里,我们已经构建分布式面向服务的架构,也显式提供了一个HTTP API,我们使用反向代理将请求路由通过API路由给单个组件。我们选择了Nginx Web这个优秀的服务器作为我们的反向代理,它快速、可靠且易于配置。我们通过它将多个HTTP的API服务聚合到一个URL空间。举例来说,当你键入:

http://api.example.com/product/pinstripe_suit

它将被路由到:

http://10.0.1.101:8001/product/pinstripe_suit

但当你访问:

http://api.example.com/customer/103474783

它将被路由到:

http://10.0.1.104:8003/customer/103474783

对使用者来言,他们觉得是在使用同一个URL空间(http://api.example.com/blah/blah),但在后端不同的顶级分类的URL被路由到不同的后端服务器。 /prodect/…路由到 10.0.1.101:8001, /customer/…则路由到10.0.1.104:8003。 我们也希望这是自动配置。比如说我想创建一个新的组件来记录的库存水平。相比于扩展现有的组件,我更希望能够写另一个独立的可执行文件或提供服务的HTTP端点,然后自动部署成为我的云计算基础架构中的主机之一,并使Nginx的自动将http ://api.example.com/sock/whatever 路由我新组件。 我们也想进行 后端服务的负载平衡,我们也想部署我们的股票 新API的多个服务实例间的Nginx自动轮询。

我们称每个顶级分类(/stock、/produck、/customer)为一个声明。 A组件上线时通过RabbitMQ发布了一个’AddApiClaim’。此消息有3个字段:’声明’,’IP地址’,’端口地址’。我们有一个’ProxyAutomation’的特殊组件,这个组件接收这些消息并按要求重写Nginx配置项。它使用SSH和SCP登录到nginx服务器,传输各种配置文件,并指示Nginx的重新加载配置。我们使用the excellent SSH.NET库来进行自动化。

Nginx的配置是一个非常好的事情是支持通配符。看一看我们的顶级配置文件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
...



 http {



     include       /etc/nginx/mime.types;



     default_type  application/octet-stream;







     log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '



                       '$status $body_bytes_sent "$http_referer" '



                       '"$http_user_agent" "$http_x_forwarded_for"';







     access_log  /var/log/nginx/access.log  main;







     sendfile        on;



     keepalive_timeout  65;





     include /etc/nginx/conf.d/*.conf;



 }

如16行所描述, 将conf.d目录的所有.conf引用到此处.

在conf.d文件夹内,有一个文件包含了所有api.example.com的请求配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
include     /etc/nginx/conf.d/api.example.com.conf.d/upstream.*.conf;







 server {



     listen          80;



     server_name     api.example.com;







     include         /etc/nginx/conf.d/api.example.com.conf.d/location.*.conf;







     location / {



         root    /usr/share/nginx/api.example.com;



         index   index.html index.htm;



     }



 }

这段配置让 Nginx 侦听来自 80 端口的 api.example.com 的请求。

这里包括两部分。第一个部分是第一行,我将在以后讨论。第7行表述了将子目录”api.example.com.conf.d”中的location.*.conf引用到配置中来。我们代理服务器的自动化组件添加新的组件(AKA API claims)通过引入新的location.*.conf。举个例子,我们的股票组件可能创建一个location.stock.conf配置文件,像这样:

1
2
3
4
5
6
7
8
9
location /stock/ {



     proxy_pass http://stock;



 }

这只是简单的告诉Nginx将所有api.example.com/stock/…的代理请求转发到’stock’中定义的后端服务器,这些定义存放在’upstream.*.conf’中。代理自动化组件也引入了一个名为upstream.stock.conf文件,它看起来像这样:

1
2
3
4
5
6
7
8
9
10
11
12
13
upstream stock {



    server 10.0.0.23:8001;



    server 10.0.0.23:8002;



}

这些配置告诉Nginx将所有到api.example.com/stock/的请求轮询到给定的地址,在这个例子中两个实例在同一台机器(10.0.0.23)上,一个在8001端口,一个在8002端口。

正如股票组件的部署一样,添加新条目可以同样增加到upstream.stock.conf中。同样,当组件卸载时,只要删除对应条目就可以了,当所有组件移除时,将整个文件已就删除。

这种基础架构可以让我们聚合组件的基础设备。我们可以 通过简单地添加新的组件实例来扩展应用程序。作为组件开发人员也不需要做任何代理配置,只需要确保组件发送了添加或删除API声明的消息就可以了。

python中自动化配置Nginx服务器的反向代理就是这样,欢迎大家参考。。。。

Linux:ngxtop:在命令行实时监控 Nginx 的神器

Nginx网站服务器在生产环境中运行的时候需要进行实时监控。实际上,诸如Nagios, Zabbix, Munin 的网络监控软件是支持 Nginx 监控的。

如果你不需要以上软件提供的综合性报告或者长期数据统计功能,只是需要一种快速简便的办法去监控 Nginx 服务器的请求的话,我建议你采用一个叫 ngxtop 的命令行工具。

你马上就会发现 ngxtop 从界面和名称都借鉴了著名的top命令。ngxtop 是通过分析 Nginx 或者其他的日志文件,使用类似 top 命令的界面实时展示出来的。你可以说你知道的其他高端监控工具,但是在简洁这方面 ngxtop 无疑是最好的。简单就意味着不可替代。

本指南中,我将介绍如何使用 ngxtop 实时监控 Nginx 网站服务器。

Linux 上安装 ngxtop

首先在 Linux 系统中安装依赖库pip(LCTT译注:ngxtop是用python编写的)。

然后使用如下命令安装 ngxtop。

$ sudo pip install ngxtop

ngxtop 使用

基本使用方法如下:

ngxtop [options]
ngxtop [options] (print|top|avg|sum) 
ngxtop info

这里是一些通用选项。

  • -l : 指定日志文件的完整路径 (Nginx 或 Apache2)
  • -f : 日志格式
  • –no-follow: 处理当前已经写入的日志文件,而不是实时处理新添加到日志文件的日志
  • -t : 更新频率
  • -n : 显示行号
  • -o : 排序规则(默认是访问计数)
  • -a …, –a …: 添加表达式(一般是聚合表达式如: sum, avg, min, max 等)到输出中。
  • -v: 输出详细信息
  • -i : 只处理符合规则的记录

以下是一些内置变量,他们的含义不言自明。

  • bodybytessend
  • http_referer
  • httpuseragent
  • remote_addr
  • remote_user
  • request
  • status
  • time_local

使用 ngxtop 监控 Nginx

ngxtop 默认会从其配置文件 (/etc/nginx/nginx.conf) 中查找 Nginx 日志的地址。所以,监控 Nginx ,运行以下命令即可:

$ ngxtop

这将会列出10个 Nginx 服务,按请求数量排序。

显示前20个最频繁的请求:

$ ngxtop -n 20
Linux:ngxtop:在命令行实时监控 Nginx 的神器
Linux:ngxtop:在命令行实时监控 Nginx 的神器

获取Nginx基本信息:

$ ngxtop info

你可以自定义显示的变量,简单列出需要显示的变量。使用 “print” 命令显示自定义请求。

$ ngxtop print request http_user_agent remote_addr
Linux:ngxtop:在命令行实时监控 Nginx 的神器
Linux:ngxtop:在命令行实时监控 Nginx 的神器

显示请求最多的客户端IP地址

$ ngxtop top remote_addr

显示状态码是404的请求

$ ngxtop -i 'status == 404' print request status
Linux:ngxtop:在命令行实时监控 Nginx 的神器
Linux:ngxtop:在命令行实时监控 Nginx 的神器

除了Nginx,ngtop 还可以处理其他的日志文件,比如 Apache 的访问文件。使用以下命令监控 Apache 服务器:

$ tail -f /var/log/apache2/access.log | ngxtop -f common

via: http://xmodulo.com/2014/06/monitor-nginx-web-server-command-line-real-time.html

译者:shipsw 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

来源:https://linux.cn/article-3205-1.html