为什么运行docker命令返回"/var/run/docker.sock"权限拒绝?

大数据/云计算Ansible 发表了文章 • 0 个评论 • 1462 次浏览 • 2015-07-24 00:51 • 来自相关话题

/var/run/docker.sock: permission denied

# docker ps
FATA[0000] Get http:///var/run/docker.sock/v1.16/containers/json:
dial unix /var/run/docker.sock: permission denied.
Are you trying to connect to a TLS-enabled daemon without TLS?      首先你得确认/var/run/docker.sock文件是否存在# ls -l /var/run/docker.sock
srw-rw---- 1 root docker 0 sty 28 11:53 /var/run/docker.sock      解决方案现在很清楚了,通过添加你的登陆用户到docker用户组来解决这个问题,如下所示:# sudo gpasswd -a ${USER} docker      /etc/group文件内容应该可以看出变化了# cat /etc/group | grep ^docker      下面我们打开一个新的终端来检查登陆用户是否加入到了docker用户组,应该存在于如下命令结果中# groups      如果你的登陆用户还没有加入到docker用户组,你可以尝试重启机器。如果你可以正常重启docker容器,就不需要重启服务器了。# sudo service docker.io restart然后你运行docker ps应该就没有问题了! 查看全部
idocker.png


/var/run/docker.sock: permission denied


# docker ps
FATA[0000] Get http:///var/run/docker.sock/v1.16/containers/json:
dial unix /var/run/docker.sock: permission denied.
Are you trying to connect to a TLS-enabled daemon without TLS?
      首先你得确认/var/run/docker.sock文件是否存在
# ls -l /var/run/docker.sock
srw-rw---- 1 root docker 0 sty 28 11:53 /var/run/docker.sock
      解决方案现在很清楚了,通过添加你的登陆用户到docker用户组来解决这个问题,如下所示:
# sudo gpasswd -a ${USER} docker
      /etc/group文件内容应该可以看出变化了
# cat /etc/group | grep ^docker
      下面我们打开一个新的终端来检查登陆用户是否加入到了docker用户组,应该存在于如下命令结果中
# groups
      如果你的登陆用户还没有加入到docker用户组,你可以尝试重启机器。如果你可以正常重启docker容器,就不需要重启服务器了。
# sudo service docker.io restart
然后你运行docker ps应该就没有问题了!

logstash一个坑

回复

运维技术采菊篱下 发起了问题 • 1 人关注 • 0 个回复 • 1324 次浏览 • 2015-07-23 21:54 • 来自相关话题

探底df和du命令统计磁盘使用结果不一致

运维技术OpenSkill 发表了文章 • 2 个评论 • 1011 次浏览 • 2015-07-23 01:42 • 来自相关话题

现象:

      最近有一台主机,磁盘不断告警,提示磁盘空间使用大于95%,告警邮件如下图




      然后我就登陆服务器查看,然后df -h 和du -csh统计结果如下所示:[root@JAVA_HOST1 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 20G 18G 873M 96% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/vdb 197G 105G 83G 57% /data[root@JAVA_HOST1 /]# du -csh ./*
6.6M ./bin
41M ./boot
4.0K ./boot_ucloud
105G ./data
156K ./dev
26M ./etc
4.0K ./home
130M ./lib
21M ./lib64
16K ./lost+found
4.0K ./media
4.0K ./mnt
24K ./opt
du: 无法访问"./proc/3741/task/3741/fd/4": 没有那个文件或目录
du: 无法访问"./proc/3741/task/3741/fdinfo/4": 没有那个文件或目录
du: 无法访问"./proc/3741/fd/4": 没有那个文件或目录
du: 无法访问"./proc/3741/fdinfo/4": 没有那个文件或目录
0 ./proc
168K ./root
16M ./sbin
4.0K ./selinux
4.0K ./srv
513M ./swapfile
0 ./sys
13M ./tmp
982M ./usr
378M ./var
107G 总用量      从du命令统计的结果可以看出,除掉/data分区的105G使用量,/分区的使用大小应该为2G,但是df查看却使用了18G,这明显不正常,那下面让我们来看看到底是为什么?

浅谈原理

du的工作原理
      du命令会对待统计文件逐个调用fstat这个系统调用,获取文件大小。它的数据是基于文件获取的,所以有很大的灵活性,不一定非要针对一个分区,可以跨越多个分区操作。如果针对的目录中文件很多,du速度就会很慢了。
 
df的工作原理
      df命令使用的事statfs这个系统调用,直接读取分区的超级块信息获取分区使用情况。它的数据是基于分区元数据的,所以只能针对整个分区。由于df直接读取超级块,所以运行速度不受文件多少影响,所以比较快速。

实验模拟说明

创建并删除文件
      创建文件前的磁盘容量情况:      # df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 5.7G 5.5G 51% /
tmpfs 506M 0 506M 0% /dev/shm      创建文件:# dd if=/dev/zero of=test.iso bs=1024k count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 14.3055 seconds, 73.3 MB/s      现在的磁盘情况:文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 6.7G 4.6G 60% /
tmpfs 506M 0 506M 0% /dev/shm      模拟某个进程正在使用该文件:# tail -f /tmp/test.iso      删除该文件
      打开另一个终端,登陆到系统中。查看是否有进程正在使用上面创建的文件:# lsof |grep test.iso
tail 2175 root 3r REG 8,1 1048576000 752972 /tmp/test.iso      把该文件删掉,并确认:# rm /tmp/test.iso
rm:是否删除 一般文件 “/tmp/test.iso”? y
# ls /tmp/test.iso
ls: /tmp/test.iso: 没有那个文件或目录      查看是否还有进程在使用(注意结尾的标记):# lsof |grep test.iso
tail 2175 root 3r REG 8,1 1048576000 752972 /tmp/test.iso (deleted)      查看磁盘使用情况:# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 6.7G 4.6G 60% /
tmpfs 506M 0 506M 0% /dev/shm
# cat /proc/diskstats |grep sda1
8 1 sda1 54385 5184 1626626 130090 20434 635997 5251448 5345733 0 111685 5475829      可见,虽然从ls 已经无法找到该文件,但因为tail 进程仍在使用该文件,故实际上内核并没有把这文件所占用的空间释放出来(df 结果和删除文件之前是一样的)。
 
停止tail进程:
      回到第一终端,用Ctrl+C 终止tail 进程,查看结果:# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 5.7G 5.5G 51% /
tmpfs 506M 0 506M 0% /dev/shm
# cat /proc/diskstats |grep sda1
8 1 sda1 54473 5184 1627402 130617 20453 636042 5251960 5345756 0 112226 5476379      至此,文件所占用的空间已完全释放。
实验结果:1、若有进程在占用某个文件,而其他进程把这文件删掉,只会删除其在磁盘中的标记,而不会释放其占用的磁盘空间;直到所有访问该文件的进程退出为止;
2、df 是从内核中获取磁盘占用情况数据的,而du是统计当前磁盘文件大小的结果,由于磁盘标记已被删掉,因此du 不会计算上述被删除文件的空间,导致df 与 du的结果不一致。

解决问题

1、把占用文件的相关进程关闭
      通过下面的命令得到这些已被删除,但未释放空间的文件和进程信息,然后删除  # lsof |grep deleted 找到这些进程后,在安全的情况下把其kill,空间自会马上释放。
# lsof |grep deleted |awk '{print $2}'|xargs -n1 -t kill -9
2、以清空的方式替代删除
      归根到底,产生问题的原因是,访问该文件的文件指针(句柄),在rm 动作后,因为进程仍在访问,因此,仍处在文件里面(中间或结尾处)。所以,如果用清空的方式,把文件指针重置,该文件所占用的空间也会马上释放出来。# echo > /tmp/test.iso
# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 5.7G 5.5G 51% /
tmpfs 506M 0 506M 0% /dev/shm
# tail -f /tmp/test.iso
tail: /tmp/test.iso: file truncated      所以,对于常发生类似问题的文件,如:日志记录文件等。以改名、清空、删除的顺序操作可避免该问题发生。

教育意义

code当出现du和df差距很大的情况时,考虑是否是有删除文件未完成造成的,方法是lsof命令,然后停止相关进程即可。
(2)可以使用清空文件的方式来代替删除文件,方式是:echo > test.iso。
(3)对于经常发生删除问题的日志文件,以改名、清空、删除的顺序操作。
(4)除了rm外,有些命令会间接的删除文件,如gzip命令完成后会删除原来的文件,为了避免删除问题,压缩前先确认没有进程打开该文件。[/code]

文件空洞

文件读写时,如果先文件指针偏移很大一段,然后写入1byte;这样这个文件实际占用1byte空间,但是stat查看文件大小,或者读写时,都会发现文件很大;所有没有写内容的都返回0,且不占用空间,这样的文件叫 'sparse file',即文件空洞
容易发生在一个进程在写一个文件,这是人工进行清空文件操作,就会产生。 查看全部


现象:


      最近有一台主机,磁盘不断告警,提示磁盘空间使用大于95%,告警邮件如下图
d1.png

      然后我就登陆服务器查看,然后df -h 和du -csh统计结果如下所示:
[root@JAVA_HOST1 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 20G 18G 873M 96% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/vdb 197G 105G 83G 57% /data
[root@JAVA_HOST1 /]# du -csh ./*
6.6M ./bin
41M ./boot
4.0K ./boot_ucloud
105G ./data
156K ./dev
26M ./etc
4.0K ./home
130M ./lib
21M ./lib64
16K ./lost+found
4.0K ./media
4.0K ./mnt
24K ./opt
du: 无法访问"./proc/3741/task/3741/fd/4": 没有那个文件或目录
du: 无法访问"./proc/3741/task/3741/fdinfo/4": 没有那个文件或目录
du: 无法访问"./proc/3741/fd/4": 没有那个文件或目录
du: 无法访问"./proc/3741/fdinfo/4": 没有那个文件或目录
0 ./proc
168K ./root
16M ./sbin
4.0K ./selinux
4.0K ./srv
513M ./swapfile
0 ./sys
13M ./tmp
982M ./usr
378M ./var
107G 总用量
      从du命令统计的结果可以看出,除掉/data分区的105G使用量,/分区的使用大小应该为2G,但是df查看却使用了18G,这明显不正常,那下面让我们来看看到底是为什么?


浅谈原理


du的工作原理
      du命令会对待统计文件逐个调用fstat这个系统调用,获取文件大小。它的数据是基于文件获取的,所以有很大的灵活性,不一定非要针对一个分区,可以跨越多个分区操作。如果针对的目录中文件很多,du速度就会很慢了。
 
df的工作原理
      df命令使用的事statfs这个系统调用,直接读取分区的超级块信息获取分区使用情况。它的数据是基于分区元数据的,所以只能针对整个分区。由于df直接读取超级块,所以运行速度不受文件多少影响,所以比较快速。


实验模拟说明


创建并删除文件
      创建文件前的磁盘容量情况:      
# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 5.7G 5.5G 51% /
tmpfs 506M 0 506M 0% /dev/shm
      创建文件:
# dd if=/dev/zero of=test.iso bs=1024k count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 14.3055 seconds, 73.3 MB/s
      现在的磁盘情况:
文件系统                容量  已用   可用   已用%  挂载点
/dev/sda1 12G 6.7G 4.6G 60% /
tmpfs 506M 0 506M 0% /dev/shm
      模拟某个进程正在使用该文件:
# tail -f /tmp/test.iso
      删除该文件
      打开另一个终端,登陆到系统中。查看是否有进程正在使用上面创建的文件:
# lsof |grep test.iso
tail 2175 root 3r REG 8,1 1048576000 752972 /tmp/test.iso
      把该文件删掉,并确认:
# rm /tmp/test.iso
rm:是否删除 一般文件 “/tmp/test.iso”? y
# ls /tmp/test.iso
ls: /tmp/test.iso: 没有那个文件或目录
      查看是否还有进程在使用(注意结尾的标记):
# lsof |grep test.iso
tail 2175 root 3r REG 8,1 1048576000 752972 /tmp/test.iso (deleted)
      查看磁盘使用情况:
# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 6.7G 4.6G 60% /
tmpfs 506M 0 506M 0% /dev/shm
# cat /proc/diskstats |grep sda1
8 1 sda1 54385 5184 1626626 130090 20434 635997 5251448 5345733 0 111685 5475829
      可见,虽然从ls 已经无法找到该文件,但因为tail 进程仍在使用该文件,故实际上内核并没有把这文件所占用的空间释放出来(df 结果和删除文件之前是一样的)。
 
停止tail进程:
      回到第一终端,用Ctrl+C 终止tail 进程,查看结果:
# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 5.7G 5.5G 51% /
tmpfs 506M 0 506M 0% /dev/shm
# cat /proc/diskstats |grep sda1
8 1 sda1 54473 5184 1627402 130617 20453 636042 5251960 5345756 0 112226 5476379
      至此,文件所占用的空间已完全释放。
实验结果:
1、若有进程在占用某个文件,而其他进程把这文件删掉,只会删除其在磁盘中的标记,而不会释放其占用的磁盘空间;直到所有访问该文件的进程退出为止;
2、df 是从内核中获取磁盘占用情况数据的,而du是统计当前磁盘文件大小的结果,由于磁盘标记已被删掉,因此du 不会计算上述被删除文件的空间,导致df 与 du的结果不一致。


解决问题


1、把占用文件的相关进程关闭
      通过下面的命令得到这些已被删除,但未释放空间的文件和进程信息,然后删除  
# lsof |grep deleted 
找到这些进程后,在安全的情况下把其kill,空间自会马上释放。
# lsof |grep deleted |awk '{print $2}'|xargs -n1 -t kill -9

2、以清空的方式替代删除
      归根到底,产生问题的原因是,访问该文件的文件指针(句柄),在rm 动作后,因为进程仍在访问,因此,仍处在文件里面(中间或结尾处)。所以,如果用清空的方式,把文件指针重置,该文件所占用的空间也会马上释放出来。
# echo > /tmp/test.iso
# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 5.7G 5.5G 51% /
tmpfs 506M 0 506M 0% /dev/shm
# tail -f /tmp/test.iso
tail: /tmp/test.iso: file truncated
      所以,对于常发生类似问题的文件,如:日志记录文件等。以改名、清空、删除的顺序操作可避免该问题发生。


教育意义


code当出现du和df差距很大的情况时,考虑是否是有删除文件未完成造成的,方法是lsof命令,然后停止相关进程即可。
(2)可以使用清空文件的方式来代替删除文件,方式是:echo > test.iso。
(3)对于经常发生删除问题的日志文件,以改名、清空、删除的顺序操作。
(4)除了rm外,有些命令会间接的删除文件,如gzip命令完成后会删除原来的文件,为了避免删除问题,压缩前先确认没有进程打开该文件。[/code]


文件空洞


  文件读写时,如果先文件指针偏移很大一段,然后写入1byte;这样这个文件实际占用1byte空间,但是stat查看文件大小,或者读写时,都会发现文件很大;所有没有写内容的都返回0,且不占用空间,这样的文件叫 'sparse file',即文件空洞
容易发生在一个进程在写一个文件,这是人工进行清空文件操作,就会产生。


一次被劫持挂马经历--Elasticsearch的远程执行漏洞

大数据/云计算OpenSkill 发表了文章 • 0 个评论 • 683 次浏览 • 2015-07-22 19:11 • 来自相关话题

起因:

           公司使用的是Ucloud的云主机服务,今天上午突然被告知有一台服务器的出口流量激增,对外发包量短时间内达到了100万,而且都是UDP类型的,第一感觉就是:诶呀,莫不是被黑了,被当肉鸡了呀!

探究:

           立马登录对应的服务器,首先使用iftop查看流量状况








           可以看出出口流量好吓人,1分钟内累计700M流量,查了一下这2个IP地址,一个是在美国,一个是在浙江电信;赶紧查看正在运行的进程,找出疑似进程,还真有所发现:




           [.ECC6DFE919A382]这个进程还想冒充系统进程,疑点极大,而且/tmp/freeBSD也是一个很奇怪的东西,而498这个UID对应的用户是elasticsearch,想起来昨天部署了Elasticsearch + Logstash,以实现日志统计系统,不会是ES有bug吧,继续查看原因




            疑/tmp/freeBSD就是被挂马的程序,可惜已经被删除了,无法查看了

原因:

            罪魁祸首查出来了,细致的原因还需要详查,所以现在最重要的就是解决问题,迅速kill掉相关进程,再次查看iftop发现流量迅速回落了,更加证实了我们的判断;
            接下来就需要查找被劫持挂马的原因和具体的劫持方式,以绝后患,而通过外部搜索引擎也是很快就定位了问题的原因,就是“Elasticsearch远程任意代码执行”漏洞:
[]ElasticSearch有脚本执行(scripting)的功能,可以很方便地对查询出来的数据再加工处理; ElasticSearch用的脚本引擎是MVEL,这个引擎没有做任何的防护,或者沙盒包装,所以直接可以执行任意代码。[/][]而在ElasticSearch 1.2之前的版本里,默认配置是打开动态脚本功能的,因此用户可以直接通过http请求,执行任意代码。[/][]其实官方是清楚这个漏洞的,在文档里有说明:[/][]First, you should not run Elasticsearch as the root user, as this would allow a script to access or do anything on your server, without limitations. Second, you should not expose Elasticsearch directly to users, but instead have a proxy application inbetween.            [/]
           终于找到原因,那就解决吧

解决方案:

           法一:手动关闭ES远程执行脚本的功能,即在每一个ES节点的配置文件elasticsearch.yml中添加如下一行即可script.disable_dynamic: true           然后重启ES即可.
           法二:升级ES至1.2版本以上也可,因为在ES1.2版本中已默认关闭了远程执行脚本的功能,但需考虑与Logstash的兼容性问题

后续:

[]根据官方的资料,为了保证ES的安全性,不可以root身份启动ES,且可考虑使用代理(负载均衡器也可),对外开放非9200端口(如9300),转发至内网的9200端口,可有效防止小人们的恶意端口扫描;[/][]因为已经被挂马了一次,所以在重新启用ES之前,还需全面检查被入侵的主机是否还有其它隐患,这就涉及web安全扫描的内容了,暂时小白,还未了解,故希望有经验的前辈可以多多请教![/]
           最近我也遇到了这个问题,然后搜索发现这篇文章不错,然后就想分享给大家,希望大家可以避免踩坑!
原文地址 查看全部


起因:


           公司使用的是Ucloud的云主机服务,今天上午突然被告知有一台服务器的出口流量激增,对外发包量短时间内达到了100万,而且都是UDP类型的,第一感觉就是:诶呀,莫不是被黑了,被当肉鸡了呀!


探究:


           立马登录对应的服务器,首先使用iftop查看流量状况
e1.jpg

e2.jpg

           可以看出出口流量好吓人,1分钟内累计700M流量,查了一下这2个IP地址,一个是在美国,一个是在浙江电信;赶紧查看正在运行的进程,找出疑似进程,还真有所发现:
e3.jpg

           [.ECC6DFE919A382]这个进程还想冒充系统进程,疑点极大,而且/tmp/freeBSD也是一个很奇怪的东西,而498这个UID对应的用户是elasticsearch,想起来昨天部署了Elasticsearch + Logstash,以实现日志统计系统,不会是ES有bug吧,继续查看原因
e4.jpg

            疑/tmp/freeBSD就是被挂马的程序,可惜已经被删除了,无法查看了


原因:


            罪魁祸首查出来了,细致的原因还需要详查,所以现在最重要的就是解决问题,迅速kill掉相关进程,再次查看iftop发现流量迅速回落了,更加证实了我们的判断;
            接下来就需要查找被劫持挂马的原因和具体的劫持方式,以绝后患,而通过外部搜索引擎也是很快就定位了问题的原因,就是“Elasticsearch远程任意代码执行”漏洞:
    []ElasticSearch有脚本执行(scripting)的功能,可以很方便地对查询出来的数据再加工处理; ElasticSearch用的脚本引擎是MVEL,这个引擎没有做任何的防护,或者沙盒包装,所以直接可以执行任意代码。[/][]而在ElasticSearch 1.2之前的版本里,默认配置是打开动态脚本功能的,因此用户可以直接通过http请求,执行任意代码。[/][]其实官方是清楚这个漏洞的,在文档里有说明:[/][]First, you should not run Elasticsearch as the root user, as this would allow a script to access or do anything on your server, without limitations. Second, you should not expose Elasticsearch directly to users, but instead have a proxy application inbetween.            [/]

           终于找到原因,那就解决吧


解决方案:


           法一:手动关闭ES远程执行脚本的功能,即在每一个ES节点的配置文件elasticsearch.yml中添加如下一行即可
script.disable_dynamic: true
           然后重启ES即可.
           法二:升级ES至1.2版本以上也可,因为在ES1.2版本中已默认关闭了远程执行脚本的功能,但需考虑与Logstash的兼容性问题


后续:


    []根据官方的资料,为了保证ES的安全性,不可以root身份启动ES,且可考虑使用代理(负载均衡器也可),对外开放非9200端口(如9300),转发至内网的9200端口,可有效防止小人们的恶意端口扫描;[/][]因为已经被挂马了一次,所以在重新启用ES之前,还需全面检查被入侵的主机是否还有其它隐患,这就涉及web安全扫描的内容了,暂时小白,还未了解,故希望有经验的前辈可以多多请教![/]

           最近我也遇到了这个问题,然后搜索发现这篇文章不错,然后就想分享给大家,希望大家可以避免踩坑!
原文地址

pip install greenlet 报错

运维技术OpenSkill 回复了问题 • 2 人关注 • 1 个回复 • 1203 次浏览 • 2015-07-21 15:52 • 来自相关话题

reids 故障 'I/O error trying to sync with MASTER: connection lost'

数据库OpenSkill 发表了文章 • 0 个评论 • 823 次浏览 • 2015-07-20 23:40 • 来自相关话题

现象:

业务出现告警,业务未处理数量增加,发现连接reids很慢。然后再去PING redis机器发现 内网PING redis server 延迟很高 1000ms以上.

排查过程:

[]换网线不起作用。发现网卡一直在100M左右,然后又发现网卡口协商的是百兆,可能是交换机的问题[/][]为什么会有100M的流量呢。redis 主从之间流量异常 查看redis log 的时候可以看到[/]
[2325] 25 Dec 14:55:32.400 * MASTER SLAVE sync started
[2325] 25 Dec 14:55:32.400 * Non blocking connect for SYNC fired the event.
[2325] 25 Dec 14:55:32.433 * Master replied to PING, replication can continue...
[2325] 25 Dec 14:55:32.447 * Partial resynchronization not possible (no cached master)
[2325] 25 Dec 14:55:32.457 * Full resync from master: de89c0fdb8ecf70677585245f69ad956a4275102:33404969647192
[2325] 25 Dec 14:56:37.159 * MASTER SLAVE sync: receiving 3609059211 bytes from master
[2325] 25 Dec 14:59:12.193 # I/O error trying to sync with MASTER: connection lost      3、从redis不停的去从主上同步数据,但一直lost
      4、为什么LOST呢。 google了一下client-output-buffer-limit 这个参数对slave 同步时候所用的buffer做限制了

默认值是这个 client-output-buffer-limit slave 256mb 64mb 60(这是说负责发数据给slave的client,如果buffer超过256m或者连续60秒超过64m,就会被立刻强行关闭!!! Traffic大的话一定要设大一点。否则就会出现一个很悲剧循环,Master传输一个大的RDB给Slave,Slave努力的装载,但还没装载 完,Master对client的缓存满了,再来一次。)      5、这里有个插曲。因为redis不能重启。要用命令config set client-output-buffer-limit 这个命令 因为我用的是telnet在设置config set client-output-buffer-limit ‘slave 536870912 134217728 120′ 这样一直不成功。报参数不正确

Wrong number of arguments for CONFIG SET”

用redis-cli 就正常,应该是空格的问题,不细查了。

有将近9个GB的数据redis_master,然后设置成 ‘slave 536870912 134217728 120’还是同步失败,最后设置成了confg set client-output-buffer-limit ‘slave 2036870912 1534217728 300’就成功了,所以这个设置还得根据你同步数据的多少有针对性的设定。 查看全部


现象:


业务出现告警,业务未处理数量增加,发现连接reids很慢。然后再去PING redis机器发现 内网PING redis server 延迟很高 1000ms以上.


排查过程:


    []换网线不起作用。发现网卡一直在100M左右,然后又发现网卡口协商的是百兆,可能是交换机的问题[/][]为什么会有100M的流量呢。redis 主从之间流量异常 查看redis log 的时候可以看到[/]

[2325] 25 Dec 14:55:32.400 * MASTER  SLAVE sync started
[2325] 25 Dec 14:55:32.400 * Non blocking connect for SYNC fired the event.
[2325] 25 Dec 14:55:32.433 * Master replied to PING, replication can continue...
[2325] 25 Dec 14:55:32.447 * Partial resynchronization not possible (no cached master)
[2325] 25 Dec 14:55:32.457 * Full resync from master: de89c0fdb8ecf70677585245f69ad956a4275102:33404969647192
[2325] 25 Dec 14:56:37.159 * MASTER SLAVE sync: receiving 3609059211 bytes from master
[2325] 25 Dec 14:59:12.193 # I/O error trying to sync with MASTER: connection lost
      3、从redis不停的去从主上同步数据,但一直lost
      4、为什么LOST呢。 google了一下
client-output-buffer-limit 这个参数对slave 同步时候所用的buffer做限制了

默认值是这个 client-output-buffer-limit slave 256mb 64mb 60(这是说负责发数据给slave的client,如果buffer超过256m或者连续60秒超过64m,就会被立刻强行关闭!!! Traffic大的话一定要设大一点。否则就会出现一个很悲剧循环,Master传输一个大的RDB给Slave,Slave努力的装载,但还没装载 完,Master对client的缓存满了,再来一次。)
      5、这里有个插曲。
因为redis不能重启。要用命令config set client-output-buffer-limit 这个命令 因为我用的是telnet在设置config set client-output-buffer-limit ‘slave 536870912 134217728 120′ 这样一直不成功。报参数不正确

Wrong number of arguments for CONFIG SET”

用redis-cli 就正常,应该是空格的问题,不细查了。

有将近9个GB的数据redis_master,然后设置成 ‘slave 536870912 134217728 120’还是同步失败,最后设置成了confg set client-output-buffer-limit ‘slave 2036870912 1534217728 300’就成功了,所以这个设置还得根据你同步数据的多少有针对性的设定。

Centos安装pip和elasticsearch模块基本使用

运维技术OpenSkill 发表了文章 • 2 个评论 • 898 次浏览 • 2015-07-20 23:21 • 来自相关话题

CentOS安装python包管理安装工具pip的方法如下:

# wget --no-check-certificate https://github.com/pypa/pip/archive/1.5.5.tar.gz
# mv 1.5.5 1.5.5.tar.gz
# tar zxf 1.5.5.tar.gz
# cd pip-1.5.5/
# python setup.py install
验证:
# pip -V
pip 1.5.5 from /usr/lib/python2.6/site-packages/pip-1.5.5-py2.6.egg (python 2.6)

安装elasticsearch模块如下:

# pip install elasticsearch

使用示例如下:

>>> from datetime import datetime
[quote]>> from elasticsearch import Elasticsearch[/quote]

# 默认情况下我们连接 localhost:9200
[quote]>> es = Elasticsearch()[/quote]

# datetimes 将序列化
[quote]>> es.index(index="my-index", doc_type="test-type", id=42, body={"any": "data", "timestamp": datetime.now()})
{u'_id': u'42', u'_index': u'my-index', u'_type': u'test-type', u'_version': 1, u'ok': True}[/quote]

# 但不是反序列化
[quote]>> es.get(index="my-index", doc_type="test-type", id=42)['_source']
{u'any': u'data', u'timestamp': u'2013-05-12T19:45:31.804229'}
[/quote] 查看全部


CentOS安装python包管理安装工具pip的方法如下:


# wget --no-check-certificate https://github.com/pypa/pip/archive/1.5.5.tar.gz
# mv 1.5.5 1.5.5.tar.gz
# tar zxf 1.5.5.tar.gz
# cd pip-1.5.5/
# python setup.py install
验证:
# pip -V
pip 1.5.5 from /usr/lib/python2.6/site-packages/pip-1.5.5-py2.6.egg (python 2.6)


安装elasticsearch模块如下:


# pip install elasticsearch


使用示例如下:


>>> from datetime import datetime
[quote]>> from elasticsearch import Elasticsearch[/quote]

# 默认情况下我们连接 localhost:9200
[quote]>> es = Elasticsearch()[/quote]

# datetimes 将序列化
[quote]>> es.index(index="my-index", doc_type="test-type", id=42, body={"any": "data", "timestamp": datetime.now()})
{u'_id': u'42', u'_index': u'my-index', u'_type': u'test-type', u'_version': 1, u'ok': True}[/quote]

# 但不是反序列化
[quote]>> es.get(index="my-index", doc_type="test-type", id=42)['_source']
{u'any': u'data', u'timestamp': u'2013-05-12T19:45:31.804229'}
[/quote]

关于GlusterFS的可用空间

回复

大数据/云计算OpenSkill 发起了问题 • 1 人关注 • 0 个回复 • 1031 次浏览 • 2015-07-19 11:35 • 来自相关话题

ArchSummit全球架构师峰会见闻之APM

互联网资讯Ansible 发表了文章 • 0 个评论 • 1507 次浏览 • 2015-07-18 00:27 • 来自相关话题

引言:

     近几年来是一个创客的时代,我们每天都能在各种不同的地方看到不同的人在各种不同的产品,国内已形成一种创业的热潮。媒体捧吹,政府政策支持,这年头不说自己是创业者都不好意思创业。就拿北京来说,不知道一天内有多少家创业公司兴起,有多少家创业公司倒闭。

    从2011年开始,大数据逐渐进入互联网热词行列。2012年美国硅谷投资的最热门主题就是大数据,大数据的时代的到来也造就了不少创业公司。国外的比如,大数据业务分析公司Splunk、数据服务公司Metamarkets、数据可视化公司Tableau、大数据分析公司ParAccel等。当大数据这个热词涌入国内的时候也促进国内的互联网巨头们也在纷纷布局切分蛋糕,比如阿里、百度、腾讯、金山,还有在线教育的小象学院和早期成立的数据分析专业社区炼数成金。

    进入到2013年莫过于最火的就是云计算和虚拟化技术,作为技术人员熟悉的kvm,vm,esi,cloudstack,openstack等,逐渐进入到互联网技术人员的视野。其中也不乏不少创业者看到了方向。比如基于openstack技术成立于2013年的OpenStack开源云计算公司UnitedStack,还有基于基于cloudstack市场的天云趋势等。

    2014年大家听得最多的莫过于devops和Iass这两个词语吧。devops让我们的运维同学从脚本时代走进了coding时代,因为现在越来越多的公司都要求你会python或者其他的语言,不只简简单单的会个shell脚本就行了,因为互联网在进步。从云的概念进入中国市场,越来越多的创业者看到了中国这个行业的大市场,在国内做Iass服务的,有我们熟知的阿里云,腾讯云,ucloud,青云等。

    从2014年下半年到2015年互联网创客,熟知的应该就是基于Docker容器技术的创业者们,比如DAOCLOUD,云雀,数人科技,希云,Tenxcloud等,同样APM这个词也逐渐成为创客们中的热词了,在国外有我们熟知的APM的创业公司比如:Compuware、iMaster、New Relic、AppDynamics等,而国内的创业者们也看到了中国这个大市场,大蛋糕,也不乏创业公司比如:云智慧、OneAPM、听云等。

  APM是什么鬼    应用性能管理(Application Performance Management)是一个比较新的网络管理方向,主要指对企业的关键业务应用进行监测、优化,提高企业应用的可靠性和质量,保证用户得到良好的服务,降低IT总拥有成本(TCO)。使用全业务链的敏捷APM监控,可使一个企业的关键业务应用的性能更强大,可以提高竞争力,并取得商业成功,因此,加强应用性能管理(APM)可以产生巨大商业利益。              如果你还不了解APM是什么东东,请你移驾这里一张图告诉你什么是APM,想知道什么是真正的APM看这里。

AMP见闻之云智慧
              2015的ArchSummit架构师大会可谓是空前盛况,有将近近千名的架构师们参加。不乏百度、AWS、小米、华为、腾讯等大公司的架构师参加,也有Ucloud、青云、DAOCLOUD、云智慧等新型创业公司的加盟。
 
              作为一个运维人员我可能最关心的就是我们线上的架构应该怎么部署合理和现有架构的性能在哪里的问题,所以我这次特别关心了一下APM主题的演讲,所以在这里我为大家介绍一下我在大会看到的云智慧 高级架构师 高驰涛(Neeke)演讲的"APM与高性能架构"
 
              首先我先介绍一下他在PPT中展示演讲的三个点:性能瓶颈----->瓶颈是谁----->怎么解决 ,那下面我就逐一介绍。
 
性能瓶颈
      1.用户体验            




               不管是一个网站、产品、衣服,用户体验是很重要的,因为只有公司的产品有了用户,这家公司才有前景,才有收益。我之前一个同学在小米的应用推广平台做运维,有一天他跟我说,他们今天平台的日流水要破千万了,可想而知,一个产品只有用户才是你最大的支柱,只有用户体验好了,才能留住用户,你的产品才能体现出更高的价值。所以雷军说过要把产品做到极致,而这个极致的背后就是用户体验。
 
               而用户体验的改善我们需要去从不同的角度去分析,就如上图所示的一样,从设计方面,我们设计出更符合现在用户更喜欢的UI的风格界面,从服务方面,我们需要做好技术售后的服务和海底捞式的优服务,从产品方面我们要把产品做到极致,从性能方面,我们要让用户体验的更爽,让他的抱怨更少,从架构方面,我们应该拿出GEEK的精神去部署,从交互方面,我们应该做到简约明了,而这些并不是每个公司都能做到的,我们可以通过第三方的SaaS提供商来解决这些,可以促进我们更快、更高效的解决这些问题,当这些问题不存在了,作为工程师的我们就可以坐到办公室里面喝茶了,而不是天天焦急频繁迭代去改善我们产品的这些问题,当然这是一个最理想的状态,我想不久的将来会是这么一个状态,因为我们就在做这件事。
      2.网站架构模型








                 作为技术人员我们都知道网站的典型架构模型如上所示,随着业务增长,架构也会越来越大,关系的方面很多有网站的高可用性、数据的一致性、数据存储和搜索等等一系列的问题。随着这些问题的不断产生、扩张,你觉得作为技术人员的你,还有时间喝茶吗,公司只会不停的去招人,不停的去解决这些问题,从而导致你的网站、产品的质量和体验值都会下降,所以应用系统性能对用户的体验是至关重要的!
      3.应用系统性能




                 说起流氓这个词,我想流氓会武术,谁都挡不住哦。但是在这个创客的时代,创业者们本来就是"流氓",因为创业就是这样的,你成功了你就是预言家,失败了你就是在催牛逼。




                 前不久淘宝、携程相继出现故障,我想对他们自己的业务带来了不小的影响,淘宝还好,我相信淘宝确时是因为光缆破坏导致的故障,可怜的是携程,整个业务故障时间整整有半天之久,这个对用户的体验是非常不好的。也会造成用户对公司的信任,我的个人信息是不是会被暴露等一些问题,所以说应用的性能确实很重要,直接影响到了公司财政收入啊。难怪携程故障,老板会发出话来说,谁能给我最快的速度解决问题,奖励100万呢!

瓶颈是谁
        1.环境分析




                 一个公司由不同的部门组成,又我们的技术客服、运维、开发、市场等组成。作为一个互联网公司,当公司发展的道路上,遇到了阻力,我们产品的应用性能问题,到底是谁负责,谁来解决呢?通常我们一般都会先想到我们可爱的开发者同学们身上,然后我们开发的同学就不停的加班,解决bug和问题,但是最后效果并不是很好。就如下图所示:




                 那就让我们来分析分析应用的环境吧




                 没错,如上图所示应用就是一个多技术栈复合的整合环境。我想大家看到这么一个细化的环境,你让我们可爱的开发同学,怎么去发现问题点,即使花了大部分时间找出的问题所在,这么一个环境一个人可能完成吗,需要多个开发同学配合修复,但是等你花了大部分时间来分析你应用的时候,你公司的业务进度也是停滞不前的,蛋糕也许就被别人切走了!所以这就是APM的价值所在,透视宝则孕育而生





       2.坑在哪里








                   问题出现了,作为技术人员就会去找坑,但是业务环境和系统环境都可能有问题,所以找坑成为一种苦恼,喝茶的时间自然没有,我们需要从前端cdn层、web层、缓存存、数据层等方面着手一一去分析,但是最后你不一定可以准确的找到答案。就拿我们线上一次事件来说吧,我们的业务任务调度出现了瓶颈,我们足足花了三天之久的时间,最后才有80%的把握确认瓶颈出现在缓存系统redis上面,虽然已经找到了问题所在,最后重启redis,把资源释放了,最后暂时把问题解决了,但是最后这种问题还是会发生了,所以最后我们只好扩展redis,最后选择用来豌豆荚开源出来的分布式redis系统codis得于解决。从这个案例上来看,可想而知,查找坑是多嘛痛苦的事情啊,这让我想起了一句歌词"多么痛的领悟"! 而APM正好可以帮你解决你的痛苦。
 
怎么解决
                     那我们到底应该怎么去发现和解决呢?
       1.优化方案




                      我们的分享人给出了如上图所示的一些建议。无可厚非,我们在设计架构和语言程序的选择上面,头期一定要多考虑到性能问题和可扩展和高可用的问题,要不后期随着产品和业务的增长你只能去找坑,填坑了!








                      对于监控大家当然不陌生,监控是作为一个业务增长保证的基础,因为在业务增长的同时,我们要未雨绸缪的考虑到一些性能方面的问题,而监控正好可以我们很好的做个预警工作,可以让我们有足够充裕的时间来解决问题,不至于等到问题出现,来临时抱佛脚,着急的处理。而云智慧他们有这个优势,因为他们还有一款产品监控宝, 我想大家应该都听说过吧。
     
        2.发现解决




                       如上图是云智慧产品透视宝的Smart Agent的架构图,那它的特点是什么,能干什么?




                       从上图可以看出smart agent就是类似于我们常说的一个嵌入的sdk一样,只不过这是一个比较高级的sdk,它可以自动发现你主机上面的应用程序、代码执行效率、已经整个环境的生态关系和性能指标的采集、分析数据,从而发现你这个应用系统的性能瓶颈所在。那有人,就会问了这个东西安装在我服务器上是否安全,我的信息是否会被盗取和丢失呢?




                         我想作为用户有担心是无可厚非的,但是我想做一个长久的公司,是会考虑到我们用户的感受的,看到如上图的解释,我想安全问题,应该不存在的。那这个系统实现原理是怎么样的,是怎么实现的?大会上分享人给出了一个php code执行的数据流图




                          整个系统又能解决哪些问题呢?




                          web端用户体验问题








                          作为运维工程师,经常会有客户反应公司网站慢,但是作为运维人员有不能很好的去查询预知,哪个地方的客户访问比较慢,只有客户反应过来才了解,这样就导致用户体验不好的问题,以致业务收到影响。我这里举个例子,我上家公司是做app市场推广和下载的,类似于91助手,我们公司的用户群体主要集中在北京、上海、深圳、广州等一线城市,有一天我们领导要我分别去测试评估这几个城市在我们平台用户下载速度,这可是给我出了一道难题了,我只好让朋友帮忙,测试了,然后评估一个数据了。页面详情追踪我想,为我们做web优化做出了很好的分析,可以针对相应慢的资源,做出相应的优化方案,不错觉得功能还可以,可以解决痛点!
                         后端服务事务分析








                         深入到后端可以让我们清晰的了解性能出现在哪个节点上面,代码级别可以让我们深入了解开发者的代码性能的问题,已经查询SQL性能的问题。看起来挺好高级的,但是如果能提供解决方案更好了。比如查询出来我有一个SQL执行时间过长,然后给出一个认为更优的SQL语句,来做到真正为用户考虑,尽最大力度,减小用户的痛点,就更好了,不过作为创业公司已经做的很不错了,继续加油吧!
                          应用架构




                          有一个清晰的业务应用架构,当然对解决问题是有很大帮助的。最后问题发现了,解决了,是不是可以喝茶了,balabala,happy!








                           真心要喝茶去了,因为大牛的分享结束了,真是意犹未尽啊!
下面我分享几张现场的照片和大牛的PPT给大家
PPT下载地址
































本人文笔有限,欢迎大家交流、拍砖 查看全部
a3.png

引言:


     近几年来是一个创客的时代,我们每天都能在各种不同的地方看到不同的人在各种不同的产品,国内已形成一种创业的热潮。媒体捧吹,政府政策支持,这年头不说自己是创业者都不好意思创业。就拿北京来说,不知道一天内有多少家创业公司兴起,有多少家创业公司倒闭。

    从2011年开始,大数据逐渐进入互联网热词行列。2012年美国硅谷投资的最热门主题就是大数据,大数据的时代的到来也造就了不少创业公司。国外的比如,大数据业务分析公司Splunk、数据服务公司Metamarkets、数据可视化公司Tableau、大数据分析公司ParAccel等。当大数据这个热词涌入国内的时候也促进国内的互联网巨头们也在纷纷布局切分蛋糕,比如阿里、百度、腾讯、金山,还有在线教育的小象学院和早期成立的数据分析专业社区炼数成金。

    进入到2013年莫过于最火的就是云计算和虚拟化技术,作为技术人员熟悉的kvm,vm,esi,cloudstack,openstack等,逐渐进入到互联网技术人员的视野。其中也不乏不少创业者看到了方向。比如基于openstack技术成立于2013年的OpenStack开源云计算公司UnitedStack,还有基于基于cloudstack市场的天云趋势等。

    2014年大家听得最多的莫过于devops和Iass这两个词语吧。devops让我们的运维同学从脚本时代走进了coding时代,因为现在越来越多的公司都要求你会python或者其他的语言,不只简简单单的会个shell脚本就行了,因为互联网在进步。从云的概念进入中国市场,越来越多的创业者看到了中国这个行业的大市场,在国内做Iass服务的,有我们熟知的阿里云,腾讯云,ucloud,青云等。

    从2014年下半年到2015年互联网创客,熟知的应该就是基于Docker容器技术的创业者们,比如DAOCLOUD,云雀,数人科技,希云,Tenxcloud等,同样APM这个词也逐渐成为创客们中的热词了,在国外有我们熟知的APM的创业公司比如:Compuware、iMaster、New Relic、AppDynamics等,而国内的创业者们也看到了中国这个大市场,大蛋糕,也不乏创业公司比如:云智慧、OneAPM、听云等。


  APM是什么鬼   
    应用性能管理(Application Performance Management)是一个比较新的网络管理方向,主要指对企业的关键业务应用进行监测、优化,提高企业应用的可靠性和质量,保证用户得到良好的服务,降低IT总拥有成本(TCO)。使用全业务链的敏捷APM监控,可使一个企业的关键业务应用的性能更强大,可以提高竞争力,并取得商业成功,因此,加强应用性能管理(APM)可以产生巨大商业利益。
              如果你还不了解APM是什么东东,请你移驾这里一张图告诉你什么是APM,想知道什么是真正的APM看这里。

AMP见闻之云智慧
              2015的ArchSummit架构师大会可谓是空前盛况,有将近近千名的架构师们参加。不乏百度、AWS、小米、华为、腾讯等大公司的架构师参加,也有Ucloud、青云、DAOCLOUD、云智慧等新型创业公司的加盟。
 
              作为一个运维人员我可能最关心的就是我们线上的架构应该怎么部署合理和现有架构的性能在哪里的问题,所以我这次特别关心了一下APM主题的演讲,所以在这里我为大家介绍一下我在大会看到的云智慧 高级架构师 高驰涛(Neeke)演讲的"APM与高性能架构"
 
              首先我先介绍一下他在PPT中展示演讲的三个点:性能瓶颈----->瓶颈是谁----->怎么解决 ,那下面我就逐一介绍。
 
性能瓶颈
      1.用户体验            
st1.png

               不管是一个网站、产品、衣服,用户体验是很重要的,因为只有公司的产品有了用户,这家公司才有前景,才有收益。我之前一个同学在小米的应用推广平台做运维,有一天他跟我说,他们今天平台的日流水要破千万了,可想而知,一个产品只有用户才是你最大的支柱,只有用户体验好了,才能留住用户,你的产品才能体现出更高的价值。所以雷军说过要把产品做到极致,而这个极致的背后就是用户体验。
 
               而用户体验的改善我们需要去从不同的角度去分析,就如上图所示的一样,从设计方面,我们设计出更符合现在用户更喜欢的UI的风格界面,从服务方面,我们需要做好技术售后的服务和海底捞式的优服务,从产品方面我们要把产品做到极致,从性能方面,我们要让用户体验的更爽,让他的抱怨更少,从架构方面,我们应该拿出GEEK的精神去部署,从交互方面,我们应该做到简约明了,而这些并不是每个公司都能做到的,我们可以通过第三方的SaaS提供商来解决这些,可以促进我们更快、更高效的解决这些问题,当这些问题不存在了,作为工程师的我们就可以坐到办公室里面喝茶了,而不是天天焦急频繁迭代去改善我们产品的这些问题,当然这是一个最理想的状态,我想不久的将来会是这么一个状态,因为我们就在做这件事。
      2.网站架构模型
st2.png

st3.png

                 作为技术人员我们都知道网站的典型架构模型如上所示,随着业务增长,架构也会越来越大,关系的方面很多有网站的高可用性、数据的一致性、数据存储和搜索等等一系列的问题。随着这些问题的不断产生、扩张,你觉得作为技术人员的你,还有时间喝茶吗,公司只会不停的去招人,不停的去解决这些问题,从而导致你的网站、产品的质量和体验值都会下降,所以应用系统性能对用户的体验是至关重要的!
      3.应用系统性能
st4.png

                 说起流氓这个词,我想流氓会武术,谁都挡不住哦。但是在这个创客的时代,创业者们本来就是"流氓",因为创业就是这样的,你成功了你就是预言家,失败了你就是在催牛逼。
at4.png

                 前不久淘宝、携程相继出现故障,我想对他们自己的业务带来了不小的影响,淘宝还好,我相信淘宝确时是因为光缆破坏导致的故障,可怜的是携程,整个业务故障时间整整有半天之久,这个对用户的体验是非常不好的。也会造成用户对公司的信任,我的个人信息是不是会被暴露等一些问题,所以说应用的性能确实很重要,直接影响到了公司财政收入啊。难怪携程故障,老板会发出话来说,谁能给我最快的速度解决问题,奖励100万呢!

瓶颈是谁
        1.环境分析
at5.png

                 一个公司由不同的部门组成,又我们的技术客服、运维、开发、市场等组成。作为一个互联网公司,当公司发展的道路上,遇到了阻力,我们产品的应用性能问题,到底是谁负责,谁来解决呢?通常我们一般都会先想到我们可爱的开发者同学们身上,然后我们开发的同学就不停的加班,解决bug和问题,但是最后效果并不是很好。就如下图所示:
at6.png

                 那就让我们来分析分析应用的环境吧
at7.png

                 没错,如上图所示应用就是一个多技术栈复合的整合环境。我想大家看到这么一个细化的环境,你让我们可爱的开发同学,怎么去发现问题点,即使花了大部分时间找出的问题所在,这么一个环境一个人可能完成吗,需要多个开发同学配合修复,但是等你花了大部分时间来分析你应用的时候,你公司的业务进度也是停滞不前的,蛋糕也许就被别人切走了!所以这就是APM的价值所在,透视宝则孕育而生
at8.png


       2.坑在哪里
at9.png

at10.png

                   问题出现了,作为技术人员就会去找坑,但是业务环境和系统环境都可能有问题,所以找坑成为一种苦恼,喝茶的时间自然没有,我们需要从前端cdn层、web层、缓存存、数据层等方面着手一一去分析,但是最后你不一定可以准确的找到答案。就拿我们线上一次事件来说吧,我们的业务任务调度出现了瓶颈,我们足足花了三天之久的时间,最后才有80%的把握确认瓶颈出现在缓存系统redis上面,虽然已经找到了问题所在,最后重启redis,把资源释放了,最后暂时把问题解决了,但是最后这种问题还是会发生了,所以最后我们只好扩展redis,最后选择用来豌豆荚开源出来的分布式redis系统codis得于解决。从这个案例上来看,可想而知,查找坑是多嘛痛苦的事情啊,这让我想起了一句歌词"多么痛的领悟"! 而APM正好可以帮你解决你的痛苦。
 
怎么解决
                     那我们到底应该怎么去发现和解决呢?
       1.优化方案
as5.png

                      我们的分享人给出了如上图所示的一些建议。无可厚非,我们在设计架构和语言程序的选择上面,头期一定要多考虑到性能问题和可扩展和高可用的问题,要不后期随着产品和业务的增长你只能去找坑,填坑了!
as6.png

as7.png

                      对于监控大家当然不陌生,监控是作为一个业务增长保证的基础,因为在业务增长的同时,我们要未雨绸缪的考虑到一些性能方面的问题,而监控正好可以我们很好的做个预警工作,可以让我们有足够充裕的时间来解决问题,不至于等到问题出现,来临时抱佛脚,着急的处理。而云智慧他们有这个优势,因为他们还有一款产品监控宝, 我想大家应该都听说过吧。
     
        2.发现解决
as8.png

                       如上图是云智慧产品透视宝的Smart Agent的架构图,那它的特点是什么,能干什么?
as9.png

                       从上图可以看出smart agent就是类似于我们常说的一个嵌入的sdk一样,只不过这是一个比较高级的sdk,它可以自动发现你主机上面的应用程序、代码执行效率、已经整个环境的生态关系和性能指标的采集、分析数据,从而发现你这个应用系统的性能瓶颈所在。那有人,就会问了这个东西安装在我服务器上是否安全,我的信息是否会被盗取和丢失呢?
ab1.png

                         我想作为用户有担心是无可厚非的,但是我想做一个长久的公司,是会考虑到我们用户的感受的,看到如上图的解释,我想安全问题,应该不存在的。那这个系统实现原理是怎么样的,是怎么实现的?大会上分享人给出了一个php code执行的数据流图
ab2.png

                          整个系统又能解决哪些问题呢?
ab3.png

                          web端用户体验问题
ab4.png

ab5.png

                          作为运维工程师,经常会有客户反应公司网站慢,但是作为运维人员有不能很好的去查询预知,哪个地方的客户访问比较慢,只有客户反应过来才了解,这样就导致用户体验不好的问题,以致业务收到影响。我这里举个例子,我上家公司是做app市场推广和下载的,类似于91助手,我们公司的用户群体主要集中在北京、上海、深圳、广州等一线城市,有一天我们领导要我分别去测试评估这几个城市在我们平台用户下载速度,这可是给我出了一道难题了,我只好让朋友帮忙,测试了,然后评估一个数据了。页面详情追踪我想,为我们做web优化做出了很好的分析,可以针对相应慢的资源,做出相应的优化方案,不错觉得功能还可以,可以解决痛点!
                         后端服务事务分析
ab6.png

ab7.png

                         深入到后端可以让我们清晰的了解性能出现在哪个节点上面,代码级别可以让我们深入了解开发者的代码性能的问题,已经查询SQL性能的问题。看起来挺好高级的,但是如果能提供解决方案更好了。比如查询出来我有一个SQL执行时间过长,然后给出一个认为更优的SQL语句,来做到真正为用户考虑,尽最大力度,减小用户的痛点,就更好了,不过作为创业公司已经做的很不错了,继续加油吧!
                          应用架构
ab8.png

                          有一个清晰的业务应用架构,当然对解决问题是有很大帮助的。最后问题发现了,解决了,是不是可以喝茶了,balabala,happy!
ab9.png

ab10.png

                           真心要喝茶去了,因为大牛的分享结束了,真是意犹未尽啊!
下面我分享几张现场的照片和大牛的PPT给大家
PPT下载地址
2.jpg

3.jpg

4.jpg

5.jpg

6.jpg

7.jpg

8.jpg

9.jpg

本人文笔有限,欢迎大家交流、拍砖

KVM管理平台与股市

大数据/云计算OpenSkill 发表了文章 • 0 个评论 • 937 次浏览 • 2015-07-17 09:30 • 来自相关话题

先吐槽下qq群的调查功能,先后搞了2次调查,都没有了,数据消失了。难道qq调查的理念是,玩“闪调”,调查完就消失?




说下调查结果
OpenStack从调查结果看,OpenStack无疑是王者,前几天刚过了5岁生日,已经5岁了,但是还没有成熟,依旧活力四射。有人说OpenStack就是一个框架,一个协议族,就像网络的TCP/IP模型,真正要实施还要靠自己。
大家形成的共识是,玩OpenStack没有一定规模的开发团队搞不定,对中小型企业来说,要使用OpenStack,买一个有支持的发行版也是一个思路。OpenStack 评级 持有 还会继续升值
 
Cloudstack OpenNebulaCloudstack OpenNebula 这一年来,明显社区活跃度在下降,尤其是思杰投入到OpenStack阵营,更是对Cloudstack的打击,如果一直在使用这两个平台,可以继续使用,如果没有使用过,这两个平台建议就不要选择了。Cloudstack OpenNebula 评级 出售 升值空间已经不大了
 
oVirt/RHEVoVirt/RHEV 更适合中小型企业使用,设计目标也是中小型企业的管理工具,从个人测试的结果看,也是大问题没有,小问题不断,而且更新频繁,经常造成安装都是问题,要稳定使用还需要打磨。oVirt/RHEV 评级 持有 还会继续升值
 
ZStackZStack 是国人开发的开源管理软件,脱胎于Cloudstack,许多理念和Cloudstack一样,但是比Cloudstack部署、使用方便很多,现在版本迭代非常快,很快要推出中文版了。ZStack 评级 关注 还会继续升值,建议考虑在1.0的时候买入
 
WebVirtMgrWebVirtMgr 是一个纯Python写的管理工具,前端和后端都是Python,是Python用户者的最爱,许多Python爱好者都对WebVirtMgr做了二次定制,目前主要的问题是功能太少。WebVirtMgr 评级 关注 又可能继续升值,建议考虑在成熟的时候买入
 
Virtsh+VirtManagerVirtsh+VirtManager 是老牌绩优股,是每个人必备的工具,这个就不多说了。Virtsh+VirtManager 评级 持有 长期稳定升值
 
自己研发自己研发也是一个思路,底层的Libvirt已经非常完善了,完全可以在这个基础上,根据自己需求,开发一个非常简单的,适合自己的平台就ok。自己研发 评级 持有 会持续升值
 
热爱虚拟化技术的同学,可以扫描二维码,订阅哦!




原文地址 查看全部
kvm.png

先吐槽下qq群的调查功能,先后搞了2次调查,都没有了,数据消失了。难道qq调查的理念是,玩“闪调”,调查完就消失?
kvm1.png

说下调查结果
OpenStack
从调查结果看,OpenStack无疑是王者,前几天刚过了5岁生日,已经5岁了,但是还没有成熟,依旧活力四射。有人说OpenStack就是一个框架,一个协议族,就像网络的TCP/IP模型,真正要实施还要靠自己。
大家形成的共识是,玩OpenStack没有一定规模的开发团队搞不定,对中小型企业来说,要使用OpenStack,买一个有支持的发行版也是一个思路。
OpenStack 评级 持有 还会继续升值
 
Cloudstack OpenNebula
Cloudstack OpenNebula 这一年来,明显社区活跃度在下降,尤其是思杰投入到OpenStack阵营,更是对Cloudstack的打击,如果一直在使用这两个平台,可以继续使用,如果没有使用过,这两个平台建议就不要选择了。
Cloudstack OpenNebula 评级 出售 升值空间已经不大了
 
oVirt/RHEV
oVirt/RHEV 更适合中小型企业使用,设计目标也是中小型企业的管理工具,从个人测试的结果看,也是大问题没有,小问题不断,而且更新频繁,经常造成安装都是问题,要稳定使用还需要打磨。
oVirt/RHEV 评级 持有 还会继续升值
 
ZStack
ZStack 是国人开发的开源管理软件,脱胎于Cloudstack,许多理念和Cloudstack一样,但是比Cloudstack部署、使用方便很多,现在版本迭代非常快,很快要推出中文版了。
ZStack 评级 关注 还会继续升值,建议考虑在1.0的时候买入
 
WebVirtMgr
WebVirtMgr 是一个纯Python写的管理工具,前端和后端都是Python,是Python用户者的最爱,许多Python爱好者都对WebVirtMgr做了二次定制,目前主要的问题是功能太少。
WebVirtMgr 评级 关注 又可能继续升值,建议考虑在成熟的时候买入
 
Virtsh+VirtManager
Virtsh+VirtManager 是老牌绩优股,是每个人必备的工具,这个就不多说了。
Virtsh+VirtManager 评级 持有 长期稳定升值
 
自己研发
自己研发也是一个思路,底层的Libvirt已经非常完善了,完全可以在这个基础上,根据自己需求,开发一个非常简单的,适合自己的平台就ok。
自己研发 评级 持有 会持续升值
 
热爱虚拟化技术的同学,可以扫描二维码,订阅哦!
kvm2.png

原文地址