LVS 三种工作模式原理、以及优缺点比较

LVS 三种工作模式原理、以及优缺点比较

一、NAT模式(VS-NAT)

原理:   就是把客户端发来的数据包的IP头的目的地址,在负载均衡器上换成其中一台RS的IP地址,并发至此RS来处理,RS处理完成后把数据交给经过负载均衡器,负载均衡器再把数据包的原IP地址改为自己的IP,将目的地址改为客户端IP地址即可?期间,无论是进来的流量,还是出去的流量,都必须经过负载均衡器?   优点:集群中的物理服务器可以使用任何支持TCP/IP操作系统,只有负载均衡器需要一个合法的IP地址。   缺点:扩展性有限。当服务器节点(普通PC服务器)增长过多时,负载均衡器将成为整个系统的瓶颈,因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时,大量的数据包都交汇在负载均衡器那,速度就会变慢!

二、IP隧道模式(VS-TUN)

原理:   首先要知道,互联网上的大多Internet服务的请求包很短小,而应答包通常很大。那么隧道模式就是,把客户端发来的数据包,封装一个新的IP头标记(仅目的IP)发给RS,RS收到后,先把数据包的头解开,还原数据包,处理后,直接返回给客户端,不需要再经过负载均衡器?注意,由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持IPTUNNEL协议?所以,在RS的内核中,必须编译支持IPTUNNEL这个选项   优点:负载均衡器只负责将请求包分发给后端节点服务器,而RS将应答包直接发给用户。所以,减少了负载均衡器的大量数据流动,负载均衡器不再是系统的瓶颈,就能处理很巨大的请求量,这种方式,一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。   缺点:隧道模式的RS节点需要合法IP,这种方式需要所有的服务器支持"IP Tunneling"(IP Encapsulation)协议,服务器可能只局限在部分Linux系统上。

三、直接路由模式(VS-DR)

  原理:   负载均衡器和RS都使用同一个IP对外服务?但只有DR对ARP请求进行响应,所有RS对本身这个IP的ARP请求保持静默?也就是说,网关会把对这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC(因为IP一致)并将请求分发给这台RS?这时RS收到这个数据包,处理完成之后,由于IP一致,可以直接将数据返给客户,则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端?由于负载均衡器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域,也可以简单的理解为在同一台交换机上?   优点:和TUN(隧道模式)一样,负载均衡器也只是分发请求,应答包通过单独的路由方法返回给客户端。与VS-TUN相比,VS-DR这种实现方式不需要隧道结构,因此可以使用大多数操作系统做为物理服务器。   缺点:(不能说缺点,只能说是不足)要求负载均衡器的网卡必须与物理网卡在一个物理段上。

keepalived高可用服务工作原理

什么是Keepalived呢,keepalived观其名可知,保持存活,在网络里面就是保持在线了, 也就是所谓的高可用或热备,用来防止单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生,那说到keepalived时不得 不说的一个协议就是VRRP协议,可以说这个协议就是keepalived实现的基础,那么首先我们来看看VRRP协议

一.VRRP协议

VRRP协议 学过网络的朋友都知道,网络在设计的时候必须考虑到冗余容灾,包括线路冗余,设备冗余等,防止网络存在单点故障,那在路由器或三层交换机处实现冗余就显得 尤为重要,在网络里面有个协议就是来做这事的,这个协议就是VRRP协议,Keepalived就是巧用VRRP协议来实现高可用性(HA)的

keepalived是以VRRP协议为实现基础的,VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议。

虚拟路由冗余协议,可以认为是实现路由器高可用的协议,即将N台提供相同功能的路由器组成一个路由器组,这个组里面有一个master和多个backup,master上面有一个对外提供服务的vip(该路由器所在局域网内其他机器的默认路由为该vip),master会发组播,当backup收不到vrrp包时就认为master宕掉了,这时就需要根据VRRP的优先级来选举一个backup当master。这样的话就可以保证路由器的高可用了。

VRRP的工作过程如下: 1. 路由器开启VRRP功能后,会根据优先级确定自己在备份组中的角色。优先级高的路由器成为主用路由器,优先级低的成为备用路由器。主用路由器定期发送VRRP通告报文,通知备份组内的其他路由器自己工作正常;备用路由器则启动定时器等待通告报文的到来。 2. VRRP在不同的主用抢占方式下,主用角色的替换方式不同:l在抢占方式下,当主用路由器收到VRRP通告报文后,会将自己的优先级与通告报文中的优先级进行比较。如果大于通告报文中的优先级,则成为主用路由器;否则将保持备用状态。l在非抢占方式下,只要主用路由器没有出现故障,备份组中的路由器始终保持主用或备用状态,备份组中的路由器即使随后被配置了更高的优先级也不会成为主用路由器。 3. 如果备用路由器的定时器超时后仍未收到主用路由器发送来的VRRP通告报文,则认为主用路由器已经无法正常工作,此时备用路由器会认为自己是主用路由器,并对外发送VRRP通告报文。备份组内的路由器根据优先级选举出主用路由器,承担报文的转发功能。

keepalived完全遵守VRRP协议,包括竞选机制等等

二.Keepalived原理

Keepalived原理 keepalived也是模块化设计,不同模块复杂不同的功能,下面是keepalived的组件 core check vrrp libipfwc libipvs-2.4 libipvs-2.6 core:是keepalived的核心,复杂主进程的启动和维护,全局配置文件的加载解析等 check:负责healthchecker(健康检查),包括了各种健康检查方式,以及对应的配置的解析包括LVS的配置解析 vrrp:VRRPD子进程,VRRPD子进程就是来实现VRRP协议的 libipfwc:iptables(ipchains)库,配置LVS会用到 libipvs*:配置LVS会用到 注意,keepalived和LVS完全是两码事,只不过他们各负其责相互配合而已

keepalived启动后会有三个进程 父进程:内存管理,子进程管理等等 子进程:VRRP子进程 子进程:healthchecker子进程

有图可知,两个子进程都被系统WatchDog看管,两个子进程各自复杂自己的事,healthchecker子进程复杂检查各自服务器的健康程度,例如HTTP,LVS等等,如果healthchecker子进程检查到MASTER上服务不可用了,就会通知本机上的兄弟VRRP子进程,让他删除通告,并且去掉虚拟IP,转换为BACKUP状态

Nginx+FastCGI运行原理

Nginx不支持对外部程序的直接调用或者解析,所有的外部程序(包括PHP)必须通过FastCGI接口来调用。FastCGI接口在Linux下是socket(这个socket可以是文件socket,也可以是ip socket)。为了调用CGI程序,还需要一个FastCGI的wrapper(wrapper可以理解为用于启动另一个程序的程序),这个wrapper绑定在某个固定socket上,如端口或者文件socket。当Nginx将CGI请求发送给这个socket的时候,通过FastCGI接口,wrapper接收到请求,然后派生出一个新的线程,这个线程调用解释器或者外部程序处理脚本并读取返回数据;接着,wrapper再将返回的数据通过FastCGI接口,沿着固定的socket传递给Nginx;最后,Nginx将返回的数据发送给客户端。这就是Nginx+FastCGI的整个运作过程,如图所示。 Nginx+FastCGI运行原理

MySQL主从同步原理

Replication 线程

Mysql的 Replication 是一个异步的复制过程,从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成,其中两个线程(Sql线程和IO线程)在 Slave 端,另外一个线程(IO线程)在 Master 端。 要实现 MySQL 的 Replication ,首先必须打开 Master 端的Binary Log(mysql-bin.xxxxxx)功能,否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全 顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用 “—log-bin” 参数选项,或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加 “log-bin” 参数项。

MySQL 复制的基本过程如下:

  1. Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
  2. Master 接收到来自 Slave 的 IO 线程的请求后,通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息,返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 Binary Log 中的位置;
  3. Slave 的 IO 线程接收到信息后,将接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端,并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中,以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”
  4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后,会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句,并在自身执行这些 Query。这样,实际上就是在 Master 端和 Slave 端执行了同样的 Query,所以两端的数据是完全一样的。 实际上,在老版本中,MySQL 的复制实现在 Slave 端并不是由 SQL 线程和 IO 线程这两个线程共同协作而完成的,而是由单独的一个线程来完成所有的工作。但是 MySQL 的工程师们很快发现,这样做存在很大的风险和性能问题,主要如下:     首先,如果通过一个单一的线程来独立实现这个工作的话,就使复制 Master 端的,Binary Log日志,以及解析这些日志,然后再在自身执行的这个过程成为一个串行的过程,性能自然会受到较大的限制,这种架构下的 Replication 的延迟自然就比较长了。

其次,Slave 端的这个复制线程从 Master 端获取 Binary Log 过来之后,需要接着解析这些内容,还原成 Master 端所执行的原始 Query,然后在自身执行。在这个过程中,Master端很可能又已经产生了大量的变化并生成了大量的 Binary Log 信息。如果在这个阶段 Master 端的存储系统出现了无法修复的故障,那么在这个阶段所产生的所有变更都将永远的丢失,无法再找回来。这种潜在风险在Slave 端压力比较大的时候尤其突出,因为如果 Slave 压力比较大,解析日志以及应用这些日志所花费的时间自然就会更长一些,可能丢失的数据也就会更多。

所以,在后期的改造中,新版本的 MySQL 为了尽量减小这个风险,并提高复制的性能,将 Slave 端的复制改为两个线程来完成,也就是前面所提到的 SQL 线程和 IO 线程。最早提出这个改进方案的是Yahoo!的一位工程师“Jeremy Zawodny”。通过这样的改造,这样既在很大程度上解决了性能问题,缩短了异步的延时时间,同时也减少了潜在的数据丢失量。

当然,即使是换成了现在这样两个线程来协作处理之后,同样也还是存在 Slave 数据延时以及数据丢失的可能性的,毕竟这个复制是异步的。只要数据的更改不是在一个事务中,这些问题都是存在的。

如果要完全避免这些问题,就只能用 MySQL 的 Cluster 来解决了。不过 MySQL的 Cluster 知道笔者写这部分内容的时候,仍然还是一个内存数 据库的解决方案,也就是需要将所有数据包括索引全部都 Load 到内存中,这样就对内存的要求就非常大的大,对于一般的大众化应用来说可实施性并不是太大。当然,在之前与 MySQL 的 CTO David 交流的时候得知,MySQL 现在正在不断改进其 Cluster 的实现,其中非常大的一个改动就是允许数据不用全部 Load 到内存中,而仅仅只是索引全部 Load 到内存中,我想信在完成该项改造之后的 MySQL Cluster 将会更加受人欢迎,可实施性也会更大。

用户第一次访问网站的基本流程

客户端用户在web浏览器输入网站地址,到看到网站内容的完整访问流程: 第一步:客户端用户在浏览器里输入blog.ygqygq2.com网站地址,回车后,系统首先会查找系统本地的DNS缓存及hosts文件信息,确定是否存在blog.ygqygq2.com域名对应的IP解析记录,如果有就直接获取IP地址,然后去访问这个IP地址对应域名blog.ygqygq2.com的服务器。一般第一次请求时,DNS缓存是没有解析记录的,而hosts多在内部临时测试时使用。 第二步:如果客户端本地DNS缓存及hosts文件没有blog.ygqygq2.com域名对应的解析记录,那么,系统会把浏览器的解析请求发送给客户端本地设置的DNS服务器地址(通常称此DNS为LDNS,即Local DNS)解析,如果LDNS服务器的本地缓存有对应的解析记录就会直接返回IP地址给客户端,如果没有,则LDNS会负责继续请求其他DNS服务器。 第三步:LDNS从DNS系统的(“.”)根开始请求对blog.ygqygq2.com域名的解析,并针对各个层级的DNS服务器系统进行一系列的查找。最终会查找到linuxba.com域名对应的授权DNS服务器,而这个授权DNS服务器正是企业购买域名时用于管理域名解析的服务器,这个授权服务器会有blog.ygqygq2.com对应的IP解析记录。如果此时没有,就表示企业的域名管理人员没有人blog.ygqygq2.com域名做解析设置,即网站还没有架设好。 第四步:linuxba.com域名的授权DNS服务器会把blog.ygqygq2.com对应的最终IP解析记录(例如:1.1.1.1)发给LDNS。 第五步:LDNS把来自授权DNS服务器blog.ygqygq2.com对应的IP解析记录发给客户端浏览器,并且它会把该域名和IP的对应解析缓存起来,以便下一次更快地返回相同解析请求的记录,这些缓存记录在指定的时间(DNS TTL值控制)内不会过期。 第六步:客户端浏览器获取了blog.ygqygq2.com的对应IP地址,接下来,浏览器会请求获取IP地址对应的网站服务器,网站服务器接收到客户的请求并响应处理(此处的处理可能是数百台集群的服务器系统,可可能是一台云主机),将客户请求的内容返回给客户端浏览器。到此,一次访问浏览网页的完整过程就完成了。

DNS解析流程

DNS的解析流程实际上就是从用户在客户端浏览器中输入网站地址并按回车开始的,一直持续到获取域名的对应IP,整个过程可分为如下几个步骤: 第一步:客户端用户在浏览器里输入blog.ygqygq2.com网站地址,回车后,系统首先会查找系统本地的DNS缓存及hosts文件信息,确定是否存在blog.ygqygq2.com域名对应的IP解析记录,如果有就直接获取IP地址,然后去访问这个IP地址对应域名blog.ygqygq2.com的服务器。一般第一次请求时,DNS缓存是没有解析记录的,而hosts多在内部临时测试时使用。 第二步:如果客户端本地DNS缓存及hosts文件没有blog.ygqygq2.com域名对应的解析记录,那么,系统会把浏览器的解析请求发送给客户端本地设置的DNS服务器地址(通常称此DNS为LDNS,即Local DNS)解析,如果LDNS服务器的本地缓存有对应的解析记录就会直接返回IP地址给客户端,如果没有,则LDNS会负责继续请求其他DNS服务器。 第三步:LDNS从DNS系统的(“.”)根开始请求对blog.ygqygq2.com域名的解析,根DNS服务器在全球一共有13台,根服务器下面是没有blog.ygqygq2.com域名解析记录的,但是根下面有blog.ygqygq2.com对应的顶级域名.com的解析记录,因此,根会把.com对应的DNS服务器地址返回给LDNS。 第四步:LDNS获取到.com对应的DNS服务器地址后,就会去.com服务器请求blog.ygqygq2.com域名的解析,而.com服务器下面也没有blog.ygqygq2.com域名对应的解析记录,但是有linuxba.com域名的解析记录,因此,.com服务器会把linuxba.com对应的DNS服务器地址返回给LDNS。 第五步:同理,LDNS获取到linuxba.com对应的DNS服务器地址后,就会去baidu.com服务器请求对blog.ygqygq2.com域名的解析,linuxba.com域名对应的DNS服务器是该域名的授权DNS服务器,这个DNS服务器正是企业购买域名时用于管理解析的服务器(也可能是自建的授权DNS服务器),这个服务器会有与blog.ygqygq2.com对应的IP解析记录,如此此时没有,就表示企业的域名管理人员没有为blog.ygqygq2.com域名做解析,即网站还没架设好。 第六步:linuxba.com域名DNS服务器会把blog.ygqygq2.com对应的IP解析记录(例如1.1.1.1)发给LDNS。 第七步:LDNS把来自授权DNS服务器的与blog.ygqygq2.com对应的IP解析记录发给客户端浏览器,并且LDNS会在本地把域名和IP的对应解析记录缓存起来,以便下一次更快地返回相同解析请求记录。至此,整个DNS的解析流程就完成了。

TCP/IP连接与断开过程

TCP/IP三次握手与四次挥手

一.TCP报文格式

TCP/IP协议的详细信息参看《TCP/IP协议详解》三卷本。下面是TCP报文格式图: 图1 TCP报文格式

图1 TCP报文格式

上图中有几个字段需要重点介绍下: (1)序号:Seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。 (2)确认序号:Ack序号,占32位,只有ACK标志位为1时,确认序号字段才有效,Ack=Seq+1。 (3)标志位:共6个,即URG、ACK、PSH、RST、SYN、FIN等,具体含义如下: (A)URG:紧急指针(urgent pointer)有效。 (B)ACK:确认序号有效。 (C)PSH:接收方应该尽快将这个报文交给应用层。 (D)RST:重置连接。 (E)SYN:发起一个新连接。 (F)FIN:释放一个连接。 需要注意的是: (A)不要将确认序号Ack与标志位中的ACK搞混了。 (B)确认方Ack=发起方Req+1,两端配对。

二.三次握手

所谓三次握手(Three-Way Handshake)即建立TCP连接,就是指建立一个TCP连接时,需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中,这一过程由客户端执行connect来触发,整个流程如下图所示: 图2 TCP三次握手

图2 TCP三次握手

(1)第一次握手:Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给Server,Client进入SYN_SENT状态,等待Server确认。 (2)第二次握手:Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置为1,ack=J+1,随机产生一个值seq=K,并将该数据包发送给Client以确认连接请求,Server进入SYN_RCVD状态。 (3)第三次握手:Client收到确认后,检查ack是否为J+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给Server,Server检查ack是否为K+1,ACK是否为1,如果正确则连接建立成功,Client和Server进入ESTABLISHED状态,完成三次握手,随后Client与Server之间可以开始传输数据了。

三.四次挥手

所谓四次挥手(Four-Way Wavehand)即终止TCP连接,就是指断开一个TCP连接时,需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中,这一过程由客户端或服务端任一方执行close来触发,整个流程如下图所示: 图3 TCP四次挥手

图3 TCP四次挥手

由于TCP连接时全双工的,因此,每个方向都必须要单独进行关闭,这一原则是当一方完成数据发送任务后,发送一个FIN来终止这一方向的连接,收到一个FIN只是意味着这一方向上没有数据流动了,即不会再收到数据了,但是在这个TCP连接上仍然能够发送数据,直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭,而另一方则执行被动关闭,上图描述的即是如此。 (1)第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。 (2)第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态。 (3)第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。 (4)第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手。 上面是一方主动关闭,另一方被动关闭的情况,实际中还会出现同时发起主动关闭的情况,具体流程如下图: 图4 同时挥手

图4 同时挥手

流程和状态在上图中已经很明了了,在此不再赘述,可以参考前面的四次挥手解析步骤。

四.附注

关于三次握手与四次挥手通常都会有典型的面试题,在此提出供有需求的XDJM们参考: (1)三次握手是什么或者流程?四次握手呢?答案前面分析就是。 (2)为什么建立连接是三次握手,而关闭连接却是四次挥手呢? 这是因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。而关闭连接时,当收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,己方也未必全部数据都发送给对方了,所以己方可以立即close,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送。

五.SYN攻击

在三次握手过程中,服务器发送SYN-ACK之后,收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态.当收到ACK后,服务器转入ESTABLISHED状态. Syn攻击就是 攻击客户端 在短时间内伪造大量不存在的IP地址,向服务器不断地发送syn包,服务器回复确认包,并等待客户的确认,由于源地址是不存在的,服务器需要不断的重发直 至超时,这些伪造的SYN包将长时间占用未连接队列,正常的SYN请求被丢弃,目标系统运行缓慢,严重者引起网络堵塞甚至系统瘫痪。 Syn攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便,当你在服务器上看到大量的半连接状态时,特别是源IP地址是随机的,基本上可以断定这是一次SYN攻击.在Linux下可以如下命令检测是否被Syn攻击netstat -ntp | grep SYN_RECV 一般较新的TCP/IP协议栈都对这一过程进行修正来防范Syn攻击,修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等。 但是不能完全防范syn攻击。

http协议通信原理

WWW是以Internet作为传输媒介的一个应用系统,WWW网上最基本的传输单位是Web网页。WWW的工作基于客户机/服务器计算模型,由Web 浏览器(客户机)和Web服务器(服务器)构成,两者之间采用超文本传送协议(HTTP)进行通信。HTTP协议是基于TCP/IP协议之上的协议,是Web浏览器和Web服务器之间的应用层协议,是通用的、无状态的、面向对象的协议。

HTTP协议的作用原理包括四个步骤:   (1) 连接:Web浏览器与Web服务器建立连接,打开一个称为socket(套接字)的虚拟文件,此文件的建立标志着连接建立成功。  (2) 请求:Web浏览器通过socket向Web服务器提交请求。HTTP的请求一般是GET或POST命令(POST用于FORM参数的传递)。GET命令的格式为:  GET 路径/文件名 HTTP/1.0  文件名指出所访问的文件,HTTP/1.0指出Web浏览器使用的HTTP版本。 (3) 应答:Web浏览器提交请求后,通过HTTP协议传送给Web服务器。Web服务器接到后,进行事务处理,处理结果又通过HTTP传回给Web浏览器,从而在Web浏览器上显示出所请求的页面。

例:假设客户机与blog.ygqygq2.com:8080/mydir/index.html建立了连接,就会发送GET命令:GET /mydir/index.html HTTP/1.0。主机名为blog.ygqygq2.com的Web服务器从它的文档空间中搜索子目录mydir的文件index.html。如果找到该文件,Web服务器把该文件内容传送给相应的Web浏览器。为了告知 Web浏览器传送内容的类型,Web服务器首先传送一些HTTP头信息,然后传送具体内容(即HTTP体信息),HTTP头信息和HTTP体信息之间用一个空行分开。

常用的HTTP头信息有:   ① HTTP 1.0 200 OK  这是Web服务器应答的第一行,列出服务器正在运行的HTTP版本号和应答代码。代码"200 OK"表示请求完成。   ② MIME_Version:1.0  它指示MIME类型的版本。   ③ content_type:类型  这个头信息非常重要,它指示HTTP体信息的MIME类型。如:content_type:text/html指示传送的数据是HTML文档。   ④ content_length:长度值  它指示HTTP体信息的长度(字节)。   (4) 关闭连接:当应答结束后,Web浏览器与Web服务器必须断开,以保证其它Web浏览器能够与Web服务器建立连接。

http协议分析

一、HTTP协议简述

HTTP是一个客户端和服务器端请求和应答的标准(TCP)。客户端是终端用户,服务器端是网站。通过使用Web浏览器、网络爬虫或者其它的工具,客户端发起一个到服务器上指定端口(默认端口为80)的HTTP请求。(我们称这个客户端)叫用户代理(user agent)。应答的服务器上存储着(一些)资源,比如HTML文件和图像。(我们称)这个应答服务器为源服务器(origin server)。在用户代理和源服务器中间可能存在多个中间层,比如代理,网关,或者隧道(tunnels)。尽管TCP/IP协议是互联网上最流行的应用,HTTP协议并没有规定必须使用它和(基于)它支持的层。 事实上,HTTP可以在任何其他互联网协议上,或者在其他网络上实现。HTTP只假定(其下层协议提供)可靠的传输,任何能够提供这种保证的协议都可以被其使用。

二、HTTP协议通信过程

当我们在浏览器的地址栏输入“blog.ygqygq2.com”然后按回车,这之后发生了什么事,我们直接看到的是打开了对应的网页,那么内部客户端和服务端是如何通信的呢?

  1. URL自动解析 HTTP URL包含了用于查找某个资源的足够信息,基本格式如下:HTTP://host[“:”port][abs_path],其中HTTP表示桶盖HTTP协议来定位网络资源;host表示合法的主机域名或IP地址,port指定一个端口号,缺省80;abs_path指定请求资源的URI;如果URL中没有给出abs_path,那么当它作为请求URI时,必须以“/”的形式给出,通常这个工作浏览器自动帮我们完成。 例如:输入blog.ygqygq2.com;浏览器会自动转换成:HTTP://blog.ygqygq2.com/
  2. 获取IP,建立TCP连接 浏览器地址栏中输入"HTTP://blog.ygqygq2.com/"并提交之后,首先它会在DNS本地缓存表中查找,如果有则直接告诉IP地址。如果没有则要求网关DNS进行查找,如此下去,找到对应的IP后,则返回会给浏览器。 当获取IP之后,就开始与所请求的Tcp建立三次握手连接,连接建立后,就向服务器发出HTTP请求。
  3. 客户端浏览器向服务器发出HTTP请求 一旦建立了TCP连接,Web浏览器就会向Web服务器发送请求命令,接着以头信息的形式向Web服务器发送一些别的信息,之后浏览器发送了一空白行来通知服务器,它已经结束了该头信息的发送。
  4. Web服务器应答,并向浏览器发送数据 客户机向服务器发出请求后,服务器会客户机回送应答,

HTTP/1.1 200 OK 应答的第一部分是协议的版本号和应答状态码,正如客户端会随同请求发送关于自身的信息一样,服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。

Web服务器向浏览器发送头信息后,它会发送一个空白行来表示头信息的发送到此为结束,接着,它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据

  1. Web服务器关闭TCP连接 一般情况下,一旦Web服务器向浏览器发送了请求数据,它就要关闭TCP连接,然后如果浏览器或者服务器在其头信息加入了这行代码

Connection:keep-alive TCP连接在发送后将仍然保持打开状态,于是,浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间,还节约了网络带宽。

Squid proxy 失败问题处理

[squid,代理]

[TOC]

公司香港有服务器,因此装了个 Squid 服务用来 proxy。今天突然有人说,proxy 不了了,此记录用于记录解决此次翻墙失败问题。

1.问题

proxy 失败,像 google、dropbox 等都不能通过 proxy 访问。

2.处理过程

1.重现问题

使用翻墙失败的帐户,在自己电脑重现问题。 发现能访问国内像 ip138(查看自己出口 IP)、百度等网站,都正常,根据出口 IP,确认已翻墙。

2.登录服务器用 curl 访问谷歌、dropbox

服务器能正常解析,能正常访问谷歌、dropbox。

2.查看日志

使用 tail -f tail /var/squid/access.log 实时查看客户端使用代理访问谷歌日志,看到无实时日志输出,或者日志非常少。

3.查看服务配置文件

因为在代理本机上,能正常解析和访问谷歌、dropbox,那换 dns,看 squid 能不能正常解析和访问呢? 于是配置 squid 的 dns,增加配置参数: dns_nameservers 8.8.8.8 reload squid 后,再次测试。发现解析和访问很快。问题解决。

总结

其实 dns 可用性并不是非常的高,检查 dns 和切换 dns 的使用,可能可以解决你许久解决不了而又其名的问题。像 Oracle,也是经常遇到由于 dns 或者解析的莫名问题。

Zabbix 监控 Tengine

[nginx, zabbix, tengine]

[TOC]

Tengine 是由淘宝网发起的 Web 服务器项目。它在 Nginx 的基础上,针对大访问量网站的需求,添加了很多高级功能和特性。Tengine 的性能和稳定性已经在大型的网站如淘宝网,天猫商城等得到了很好的检验。现在作为一个开源项目,也越来越多的人使用它代替 nginx。

1.添加 Tengine 配置

tengine 配置文件添加如下 server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
server {
listen 80 ;
server_name 127.0.0.1 ;

location /nginx-status {
stub_status on;
allow 127.0.0.1;
deny all;
access_log off;
}

location /check-status {
check_status;
allow 127.0.0.1;
deny all;
access_log off;
}
}

重载 Tengine 后,本机查看结果: # curl 127.0.0.1/nginx-status Active connections: 1 server accepts handled requests 1805146 1805146 1805167 Reading: 0 Writing: 1 Waiting: 0

以上为正常显示结果。

2.添加 nginx 监控源脚本

cat /usr/local/zabbix/shell/nginx_status.sh

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
#!/bin/bash

HOST="127.0.0.1"
PORT="80"

# Functions to return nginx stats
function active {
/usr/bin/curl "http://$HOST:$PORT/nginx-status" 2>/dev/null| grep 'Active' | awk '{print $NF}'
}
function reading {
/usr/bin/curl "http://$HOST:$PORT/nginx-status" 2>/dev/null| grep 'Reading' | awk '{print $2}'
}
function writing {
/usr/bin/curl "http://$HOST:$PORT/nginx-status" 2>/dev/null| grep 'Writing' | awk '{print $4}'
}
function waiting {
/usr/bin/curl "http://$HOST:$PORT/nginx-status" 2>/dev/null| grep 'Waiting' | awk '{print $6}'
}
function accepts {
/usr/bin/curl "http://$HOST:$PORT/nginx-status" 2>/dev/null| awk NR==3 | awk '{print $1}'
}
function handled {
/usr/bin/curl "http://$HOST:$PORT/nginx-status" 2>/dev/null| awk NR==3 | awk '{print $2}'
}
function requests {
/usr/bin/curl "http://$HOST:$PORT/nginx-status" 2>/dev/null| awk NR==3 | awk '{print $3}'
}
# Run the requested function
$1

3.编辑 zabbix agentd 配置文件

修改如下: vim /usr/local/zabbix/etc/zabbix_agentd.conf 这里写图片描述

添加 zabbix 自定义 key,重启 zabbix agentd vim /usr/local/zabbix/etc/zabbix_agentd.conf.d/nginx_status_key

1
2
3
4
5
6
7
8
#nginx_status_key
UserParameter=nginx.accepts,/usr/local/zabbix/shell/nginx_status.sh accepts
UserParameter=nginx.handled,/usr/local/zabbix/shell/nginx_status.sh handled
UserParameter=nginx.requests,/usr/local/zabbix/shell/nginx_status.sh requests
UserParameter=nginx.connections.active,/usr/local/zabbix/shell/nginx_status.sh active
UserParameter=nginx.connections.reading,/usr/local/zabbix/shell/nginx_status.sh reading
UserParameter=nginx.connections.writing,/usr/local/zabbix/shell/nginx_status.sh writing
UserParameter=nginx.connections.waiting,/usr/local/zabbix/shell/nginx_status.sh waiting

从 zabbix server 端获取监控数据,结果如下为正常: 这里写图片描述

4.导入 zabbix 监控 Tengine 模板

Alt text

以下代码保存为 nginx.xml,zabbix 导入此文件。

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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
<?xml version="1.0" encoding="UTF-8"?>
<zabbix_export>
<version>2.0</version>
<date>2016-07-07T09:19:04Z</date>
<groups>
<group>
<name>Templates</name>
</group>
</groups>
<templates>
<template>
<template>Template App Nginx Service</template>
<name>Template App Nginx Service</name>
<description/>
<groups>
<group>
<name>Templates</name>
</group>
</groups>
<applications>
<application>
<name>Nginx service</name>
</application>
</applications>
<items>
<item>
<name>HTTP service is running</name>
<type>3</type>
<snmp_community/>
<multiplier>0</multiplier>
<snmp_oid/>
<key>net.tcp.service[http]</key>
<delay>60</delay>
<history>7</history>
<trends>365</trends>
<status>0</status>
<value_type>3</value_type>
<allowed_hosts/>
<units/>
<delta>0</delta>
<snmpv3_contextname/>
<snmpv3_securityname/>
<snmpv3_securitylevel>0</snmpv3_securitylevel>
<snmpv3_authprotocol>0</snmpv3_authprotocol>
<snmpv3_authpassphrase/>
<snmpv3_privprotocol>0</snmpv3_privprotocol>
<snmpv3_privpassphrase/>
<formula>1</formula>
<delay_flex/>
<params/>
<ipmi_sensor/>
<data_type>0</data_type>
<authtype>0</authtype>
<username/>
<password/>
<publickey/>
<privatekey/>
<port/>
<description/>
<inventory_link>0</inventory_link>
<applications>
<application>
<name>Nginx service</name>
</application>
</applications>
<valuemap>
<name>Service state</name>
</valuemap>
<logtimefmt/>
</item>
<item>
<name>nginx status connections active</name>
<type>0</type>
<snmp_community/>
<multiplier>0</multiplier>
<snmp_oid/>
<key>nginx.connections.active</key>
<delay>30</delay>
<history>90</history>
<trends>365</trends>
<status>0</status>
<value_type>3</value_type>
<allowed_hosts/>
<units/>
<delta>0</delta>
<snmpv3_contextname/>
<snmpv3_securityname/>
<snmpv3_securitylevel>0</snmpv3_securitylevel>
<snmpv3_authprotocol>0</snmpv3_authprotocol>
<snmpv3_authpassphrase/>
<snmpv3_privprotocol>0</snmpv3_privprotocol>
<snmpv3_privpassphrase/>
<formula>1</formula>
<delay_flex/>
<params/>
<ipmi_sensor/>
<data_type>0</data_type>
<authtype>0</authtype>
<username/>
<password/>
<publickey/>
<privatekey/>
<port/>
<description/>
<inventory_link>0</inventory_link>
<applications>
<application>
<name>Nginx service</name>
</application>
</applications>
<valuemap/>
<logtimefmt/>
</item>
<item>
<name>nginx status connections reading</name>
<type>0</type>
<snmp_community/>
<multiplier>0</multiplier>
<snmp_oid/>
<key>nginx.connections.reading</key>
<delay>30</delay>
<history>90</history>
<trends>365</trends>
<status>0</status>
<value_type>3</value_type>
<allowed_hosts/>
<units/>
<delta>0</delta>
<snmpv3_contextname/>
<snmpv3_securityname/>
<snmpv3_securitylevel>0</snmpv3_securitylevel>
<snmpv3_authprotocol>0</snmpv3_authprotocol>
<snmpv3_authpassphrase/>
<snmpv3_privprotocol>0</snmpv3_privprotocol>
<snmpv3_privpassphrase/>
<formula>1</formula>
<delay_flex/>
<params/>
<ipmi_sensor/>
<data_type>0</data_type>
<authtype>0</authtype>
<username/>
<password/>
<publickey/>
<privatekey/>
<port/>
<description/>
<inventory_link>0</inventory_link>
<applications>
<application>
<name>Nginx service</name>
</application>
</applications>
<valuemap/>
<logtimefmt/>
</item>
<item>
<name>nginx status connections waiting</name>
<type>0</type>
<snmp_community/>
<multiplier>0</multiplier>
<snmp_oid/>
<key>nginx.connections.waiting</key>
<delay>30</delay>
<history>90</history>
<trends>365</trends>
<status>0</status>
<value_type>3</value_type>
<allowed_hosts/>
<units/>
<delta>0</delta>
<snmpv3_contextname/>
<snmpv3_securityname/>
<snmpv3_securitylevel>0</snmpv3_securitylevel>
<snmpv3_authprotocol>0</snmpv3_authprotocol>
<snmpv3_authpassphrase/>
<snmpv3_privprotocol>0</snmpv3_privprotocol>
<snmpv3_privpassphrase/>
<formula>1</formula>
<delay_flex/>
<params/>
<ipmi_sensor/>
<data_type>0</data_type>
<authtype>0</authtype>
<username/>
<password/>
<publickey/>
<privatekey/>
<port/>
<description/>
<inventory_link>0</inventory_link>
<applications>
<application>
<name>Nginx service</name>
</application>
</applications>
<valuemap/>
<logtimefmt/>
</item>
<item>
<name>nginx status connections writing</name>
<type>0</type>
<snmp_community/>
<multiplier>0</multiplier>
<snmp_oid/>
<key>nginx.connections.writing</key>
<delay>30</delay>
<history>90</history>
<trends>365</trends>
<status>0</status>
<value_type>3</value_type>
<allowed_hosts/>
<units/>
<delta>0</delta>
<snmpv3_contextname/>
<snmpv3_securityname/>
<snmpv3_securitylevel>0</snmpv3_securitylevel>
<snmpv3_authprotocol>0</snmpv3_authprotocol>
<snmpv3_authpassphrase/>
<snmpv3_privprotocol>0</snmpv3_privprotocol>
<snmpv3_privpassphrase/>
<formula>1</formula>
<delay_flex/>
<params/>
<ipmi_sensor/>
<data_type>0</data_type>
<authtype>0</authtype>
<username/>
<password/>
<publickey/>
<privatekey/>
<port/>
<description/>
<inventory_link>0</inventory_link>
<applications>
<application>
<name>Nginx service</name>
</application>
</applications>
<valuemap/>
<logtimefmt/>
</item>
<item>
<name>nginx status server accepts</name>
<type>0</type>
<snmp_community/>
<multiplier>0</multiplier>
<snmp_oid/>
<key>nginx.accepts</key>
<delay>30</delay>
<history>90</history>
<trends>365</trends>
<status>0</status>
<value_type>3</value_type>
<allowed_hosts/>
<units/>
<delta>0</delta>
<snmpv3_contextname/>
<snmpv3_securityname/>
<snmpv3_securitylevel>0</snmpv3_securitylevel>
<snmpv3_authprotocol>0</snmpv3_authprotocol>
<snmpv3_authpassphrase/>
<snmpv3_privprotocol>0</snmpv3_privprotocol>
<snmpv3_privpassphrase/>
<formula>1</formula>
<delay_flex/>
<params/>
<ipmi_sensor/>
<data_type>0</data_type>
<authtype>0</authtype>
<username/>
<password/>
<publickey/>
<privatekey/>
<port/>
<description/>
<inventory_link>0</inventory_link>
<applications>
<application>
<name>Nginx service</name>
</application>
</applications>
<valuemap/>
<logtimefmt/>
</item>
<item>
<name>nginx status server handled</name>
<type>0</type>
<snmp_community/>
<multiplier>0</multiplier>
<snmp_oid/>
<key>nginx.handled</key>
<delay>30</delay>
<history>90</history>
<trends>365</trends>
<status>0</status>
<value_type>3</value_type>
<allowed_hosts/>
<units/>
<delta>0</delta>
<snmpv3_contextname/>
<snmpv3_securityname/>
<snmpv3_securitylevel>0</snmpv3_securitylevel>
<snmpv3_authprotocol>0</snmpv3_authprotocol>
<snmpv3_authpassphrase/>
<snmpv3_privprotocol>0</snmpv3_privprotocol>
<snmpv3_privpassphrase/>
<formula>1</formula>
<delay_flex/>
<params/>
<ipmi_sensor/>
<data_type>0</data_type>
<authtype>0</authtype>
<username/>
<password/>
<publickey/>
<privatekey/>
<port/>
<description/>
<inventory_link>0</inventory_link>
<applications>
<application>
<name>Nginx service</name>
</application>
</applications>
<valuemap/>
<logtimefmt/>
</item>
<item>
<name>nginx status server requests</name>
<type>0</type>
<snmp_community/>
<multiplier>0</multiplier>
<snmp_oid/>
<key>nginx.requests</key>
<delay>30</delay>
<history>90</history>
<trends>365</trends>
<status>0</status>
<value_type>3</value_type>
<allowed_hosts/>
<units/>
<delta>0</delta>
<snmpv3_contextname/>
<snmpv3_securityname/>
<snmpv3_securitylevel>0</snmpv3_securitylevel>
<snmpv3_authprotocol>0</snmpv3_authprotocol>
<snmpv3_authpassphrase/>
<snmpv3_privprotocol>0</snmpv3_privprotocol>
<snmpv3_privpassphrase/>
<formula>1</formula>
<delay_flex/>
<params/>
<ipmi_sensor/>
<data_type>0</data_type>
<authtype>0</authtype>
<username/>
<password/>
<publickey/>
<privatekey/>
<port/>
<description/>
<inventory_link>0</inventory_link>
<applications>
<application>
<name>Nginx service</name>
</application>
</applications>
<valuemap/>
<logtimefmt/>
</item>
</items>
<discovery_rules/>
<macros/>
<templates/>
<screens/>
</template>
</templates>
<triggers>
<trigger>
<expression>{Template App Nginx Service:net.tcp.service[http].max(#3)}=0</expression>
<name>HTTP service is down on {HOST.NAME}</name>
<url/>
<status>0</status>
<priority>3</priority>
<description/>
<type>0</type>
<dependencies/>
</trigger>
</triggers>
<graphs>
<graph>
<name>nginx status connections</name>
<width>900</width>
<height>200</height>
<yaxismin>0.0000</yaxismin>
<yaxismax>100.0000</yaxismax>
<show_work_period>1</show_work_period>
<show_triggers>1</show_triggers>
<type>0</type>
<show_legend>1</show_legend>
<show_3d>0</show_3d>
<percent_left>0.0000</percent_left>
<percent_right>0.0000</percent_right>
<ymin_type_1>0</ymin_type_1>
<ymax_type_1>0</ymax_type_1>
<ymin_item_1>0</ymin_item_1>
<ymax_item_1>0</ymax_item_1>
<graph_items>
<graph_item>
<sortorder>0</sortorder>
<drawtype>0</drawtype>
<color>00C800</color>
<yaxisside>0</yaxisside>
<calc_fnc>2</calc_fnc>
<type>0</type>
<item>
<host>Template App Nginx Service</host>
<key>nginx.connections.active</key>
</item>
</graph_item>
<graph_item>
<sortorder>1</sortorder>
<drawtype>0</drawtype>
<color>C80000</color>
<yaxisside>0</yaxisside>
<calc_fnc>2</calc_fnc>
<type>0</type>
<item>
<host>Template App Nginx Service</host>
<key>nginx.connections.reading</key>
</item>
</graph_item>
<graph_item>
<sortorder>2</sortorder>
<drawtype>0</drawtype>
<color>0000C8</color>
<yaxisside>0</yaxisside>
<calc_fnc>2</calc_fnc>
<type>0</type>
<item>
<host>Template App Nginx Service</host>
<key>nginx.connections.waiting</key>
</item>
</graph_item>
<graph_item>
<sortorder>3</sortorder>
<drawtype>0</drawtype>
<color>C800C8</color>
<yaxisside>0</yaxisside>
<calc_fnc>2</calc_fnc>
<type>0</type>
<item>
<host>Template App Nginx Service</host>
<key>nginx.connections.writing</key>
</item>
</graph_item>
</graph_items>
</graph>
<graph>
<name>nginx status server</name>
<width>900</width>
<height>200</height>
<yaxismin>0.0000</yaxismin>
<yaxismax>100.0000</yaxismax>
<show_work_period>1</show_work_period>
<show_triggers>1</show_triggers>
<type>0</type>
<show_legend>1</show_legend>
<show_3d>0</show_3d>
<percent_left>0.0000</percent_left>
<percent_right>0.0000</percent_right>
<ymin_type_1>0</ymin_type_1>
<ymax_type_1>0</ymax_type_1>
<ymin_item_1>0</ymin_item_1>
<ymax_item_1>0</ymax_item_1>
<graph_items>
<graph_item>
<sortorder>0</sortorder>
<drawtype>0</drawtype>
<color>00C800</color>
<yaxisside>0</yaxisside>
<calc_fnc>2</calc_fnc>
<type>0</type>
<item>
<host>Template App Nginx Service</host>
<key>nginx.accepts</key>
</item>
</graph_item>
<graph_item>
<sortorder>1</sortorder>
<drawtype>0</drawtype>
<color>C80000</color>
<yaxisside>0</yaxisside>
<calc_fnc>2</calc_fnc>
<type>0</type>
<item>
<host>Template App Nginx Service</host>
<key>nginx.handled</key>
</item>
</graph_item>
<graph_item>
<sortorder>2</sortorder>
<drawtype>0</drawtype>
<color>0000C8</color>
<yaxisside>0</yaxisside>
<calc_fnc>2</calc_fnc>
<type>0</type>
<item>
<host>Template App Nginx Service</host>
<key>nginx.requests</key>
</item>
</graph_item>
</graph_items>
</graph>
</graphs>
</zabbix_export>

5.Zabbix 主机链接模板

这里写图片描述

6.监控成功

这里写图片描述

总结

从上文看到,Zabbix 添加自定义监控数据,需要做到: Zabbix agentd 添加自定义 key; 自定义 key 调用的是获取监控数据源脚本等; 添加 Zabbix 主机数据源模板,主机链接模板。

0%