项目中使用到了RabbitMQ,使用了大量的一次性队列,然而没有设置自动过期、自动删除等特性。长期运行导致了大量的队列产生,非常影响性能及问题排查效率。这里收集了一些可以批量删除队列的方法,供参考。
优点:操作简单,可针对有规律的队列进行策略设置
缺点:想不到有什么缺点
# 设置规则
rabbitmqctl set_policy delete_gen "amq.gen-.*" '{"expires":1}' --apply-to queues
# 取消规则
rabbitmqctl clear_policy delete_gen
# 如果要作用于所有队列
rabbitmqctl set_policy delete_all ".*" '{"expires":1}' --apply-to queues
优点:简单,删除全部队列
缺点:粗暴
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app
优点:删除一个vhost的所有队列,包括Exchange
缺点:仅适用需要删除一个vhost的场景
curl -i -XDELETE http://USERNAME:PASSWORD@127.0.0.1:15672/api/vhosts/VHOST_NAME
# 例子
curl -i -XDELETE http://admin:123456@127.0.0.1:15672/api/vhosts/%2F
优点:HTTP API灵活
缺点:一次删一个
curl -i -XDELETE http://USERNAME:PASSWORD@HOST:PORT/api/queues/VHOST/QUEUE_NAME
# 例子:
curl -i -XDELETE http://admin:123456@127.0.0.1:15672/api/queues/%2F/test_queue
优点:使用方便
缺点:底层也是使用HTTP API实现的
rabbitmqadmin --host=HOST --port=15672 --ssl --vhost=VHOST --username=USERNAME --password=PASSWORD delete queue name=QUEUE_NAME
对于http端口:80,https端口:443
frontend app
bind *:80
bind :443 ssl crt /etc/haproxy/server.pem no-sslv3
mode http
option httplog
option forwardfor
rspidel ^Server.*
redirect scheme https if !{ ssl_fc }
default_backend app
backend app
mode http
option httpchk HEAD /
server app01 server1:3000 check inter 2000 rise 2 fall 5
对于http、https端口不为80、443时,以上的方法就行不通了,得使用下面的方法
frontend app
bind *:8080
bind :8443 ssl crt /etc/haproxy/server.pem no-sslv3
mode http
option httplog
option forwardfor
rspidel ^Server.*
http-request redirect code 301 location https://www.haxi.cc:8443%[capture.req.uri] if !{ ssl_fc }
default_backend app
backend app
mode http
option httpchk HEAD /
server app01 server1:3000 check inter 2000 rise 2 fall 5
在短时间内恢复服务正常运营(满足 SLA [Service-Level Agreement]),将业务运营的负面影响降至最低。
范围
包括:
对企业的价值
基本概念
处理时限:
故障模型:
模型包括:
重大故障:
当前我们公司内部服务器实例有上百台,管理客户的服务器也将近有上百个服务器示例。各个服务器上的管理人员很多(开发、运维、项目、工程人员等),在大家登录使用Linux服务器时,不同职能的员工对Linux系统的熟悉程度不同,因此导致操作很不规范,root权限泛滥(几乎所有员工都使用root权限操作),经常导致文件等莫名其妙的丢失,服务器文件、目录权限混乱等问题。这样使得公司内部、客户服务器安全存在很大的不稳定性、及操作安全隐患。据调查企业服务器环境,50%以上的安全问题都来源于内部,而不是外部。为了解决以上问题,单个用户管理权限过大现状,现提出针对Linux服务器用户权限集中管理的解决方案。
当前我们公司管理着几大平台和数十个小平台。我们的客服、工程、研发人员都是直接连接SSH的,其中的操作不可过滤、不可审计、不可追溯。如果出现了操作失误,将无法追溯,不知道是谁操作的,不知道什么时候操作的,不知道操作了什么。
所有自主程序和部分第三方开源程序(如redis)都使用root权限来运行,使用root权限存在非常大的安全隐患。比如:
1) 程序原本的功能是想删除自身的日志文件,如果程序有BUG,拼接路径时考虑不周全,可能会导致误删了系统文件。严重时可导致系统奔溃,数据丢失。
2) 程序使用了开源框架有远程执行命令的安全漏洞,那么黑客可能会获得系统的root权限,既可为所欲为,公司、客户数据安全则面临着巨大的威胁。
3) redis的弱密码、空密码存在很大的安全隐患,如使用root运行redis,黑客很容易就拿下操作系统的root权限。