Memcached和Redis监控脚本分享
Memcached：
Redis：
#!/usr/bin/env python
#coding=utf8
import sys
import os
class GetMemStatus():
def __init__(self):
self.val = {}
def check(self):
try:
import memcache
self.mc = memcache.Client(['127.0.0.1:11211'], debug=0)
except:
raise Exception, 'Plugin needs the memcache module'
def extract(self, key):
stats = self.mc.get_stats()
try:
if key in stats[0][1]:
self.val[key] = stats[0][1][key]
return self.val[key]
except:
raise Exception, 'ERROR: key is not in stats!!!'
def main():
if len(sys.argv) == 1:
print "ERROR! Please enter a key"
elif len(sys.argv) == 2:
key = sys.argv[1]
a = GetMemStatus()
a.check()
print a.extract(key)
if __name__ == "__main__":
main()
Redis：
#!/usr/bin/env python收起阅读 »
#coding=utf8
import sys
import os
class GetRedisStatus():
def __init__(self):
self.val = {}
def check(self):
try:
import redis
self.redis = redis.Redis('127.0.0.1', port=6379, password=None)
except:
raise Exception, 'Plugin needs the redis module'
def extract(self, key):
info = self.redis.info()
try:
if key in info:
self.val[key] = info[key]
return self.val[key]
except:
raise Exception, 'ERROR info not include this key!'
def main():
if len(sys.argv) == 1:
print "ERROR! Please enter a key"
elif len(sys.argv) == 2:
key = sys.argv[1]
a = GetRedisStatus()
a.check()
print a.extract(key)
if __name__ == "__main__":
main()
nmap端口扫描初识(一)
什么是端口扫描
端口扫描是指某些别有用心的人发送一组端口扫描消息，试图以此侵入某台计算机，并了解其提供的计算机网络服务类型(这些网络服务均与端口号相关)，但是端口扫描不但可以为黑客所利用，同时端口扫描还是网络安全工作者的必备的利器，通过对端口的扫描，了解网站中出现的漏洞以及端口的开放情况，对网站安全方面有着不可或缺的贡献，是网络安全中的基础认知。
目前在市面上主要的端口扫描工具是X_Scan、SuperScan、nmap，其中在这里主推的是nmap，因为nmap具有以下的这一些优点：
- 多种多样的参数，丰富的脚本库，满足用户的个人定制需求，其中脚本库还提供了很多强大的功能任你选择
- 强大的可移植性，基本上能在所有的主流系统上运行，而且代码是开源的
- 详细的文档说明，和强大的社区团队进行支持，方便新人上手
Nmap是一款开源免费的网络发现（Network Discovery）和安全审计（Security Auditing）工具，但是nmap也是有一些缺点的，比如说上手较难，但是难上手是相对的，与其他达到这种功能性的软件产品相比，还是比较容易上手的，但是这也不妨碍nmap成为世界千万安全专家列为必备的工具之一，在其中的一些影视作品中《黑客帝国2》、《特警判官》中都有亮相。
Nmap功能介绍
Centos Install:
# yum -y install nmapUbuntu Install:
# apt-get install nmap -yNmap包含四项基本功能：
- 主机发现（Host Discovery）
- 端口扫描（Port Scanning）
- 版本侦测（Version Detection）
- 操作系统侦测（Operating System Detection）
下面我们介绍一下主机发现，主机发现顾名思义就是发现所要扫描的主机是否是正在运行的状态，接下来就来一个简单例子：获取http://baidu.com 的主机是否开启， 命令：nmap -F -sT -v baidu.com
- -F：扫描100个最有可能开放的端口
- -v 获取扫描的信息
- -sT：采用的是TCP扫描 不写也是可以的，默认采用的就是TCP扫描
- -R 为所有的目标主机进行解析
- --system-dns 使用系统域名解析器进行解析，这个解析起来会比较慢
- --dns-server 服务器选择DNS解析
好了，示例也讲完了，下面我们就来分析一下扫描的各种方法：一、端口扫描1、TCP扫描（-sT）这是一种最为普通的扫描方法，这种扫描方法的特点是：扫描的速度快，准确性高，对操作者没有权限上的要求，但是容易被防火墙和IDS(防入侵系统)发现运行的原理：通过建立TCP的三次握手连接来进行信息的传递扫描方法
Starting Nmap 7.00 ( https://nmap.org ) at 2016-09-19 23:57 CSTNmap scan report for baidu.com (220.181.57.217)Host is up (0.010s latency).Other addresses for baidu.com (not scanned): 180.149.132.47 123.125.114.144 111.13.101.208Not shown: 998 filtered portsPORT STATE SERVICE80/tcp open http443/tcp open httpsNmap done: 1 IP address (1 host up) scanned in 5.41 seconds接下来还有各种扫描方法的端口列表参数:
- -PS 端口列表用,隔开[tcp80 syn 扫描]
- -PA 端口列表用,隔开[ack扫描](PS+PA测试状态包过滤防火墙【非状态的PA可以过】)【默认扫描端口1-1024】
- -PU 端口列表用,隔开[udp高端口扫描 穿越只过滤tcp的防火墙]
其他的常见命令
输出命令
-oN 文件名 输出普通文件
-oX 文件名 输出xml文件
错误调试：
--log-errors 输出错误日志
--packet-trace 获取从当前主机到目标主机的所有节点
更多参数参考：http://www.2cto.com/Article/201203/125686.html
文章参考：http://www.myhack58.com/Article/60/76/2015/67856.htm?utm_source=tuicool&utm_medium=referral 收起阅读 »
Elasticsearch聚合限制内存使用
限制内存使用
通常为了让聚合(或者任何需要访问字段值的请求)能够快点，访问fielddata一定会快点， 这就是为什么加载到内存的原因。但是加载太多的数据到内存会导致垃圾回收(gc)缓慢， 因为JVM试着发现堆里面的额外空间，甚至导致OutOfMemory异常。
最让你吃惊的是，你会发现Elaticsearch不是只把符合你的查询的值加载到fielddata. 而是把index里的所document都加载到内存，甚至是不同的 _type 的document。
逻辑是这样的，如果你在这个查询需要访问documents X，Y和Z， 你可能在下一次查询就需要访问别documents。而一次把所有的值都加载并保存在内存 ， 比每次查询都去扫描倒排索引要更方便。
JVM堆是一个有限制的资源需要聪明的使用。有许多现成的机制去限制fielddata对堆内存使用的影响。这些限制非常重要，因为滥用堆将会导致节点的不稳定（多亏缓慢的垃圾回收）或者甚至节点死亡（因为OutOfMemory异常）；但是垃圾回收时间过长，在垃圾回收期间，ES节点的性能就会大打折扣，查询就会非常缓慢，直到最后超时。
如何设置堆大小
对于环境变量 $ES_HEAP_SIZE 在设置Elasticsearch堆大小的时候有2个法则可以运用:
- 不超过RAM的50%
- 不超过32G
参数 indices.fielddata.cache.size 控制有多少堆内存是分配给fielddata。当你执行一个查询需要访问新的字段值的时候，将会把值加载到内存，然后试着把它们加入到fielddata。如果结果的fielddata大小超过指定的大小 ，为了腾出空间，别的值就会被驱逐出去。 默认情况下，这个参数设置的是无限制 — Elasticsearch将永远不会把数据从fielddata里替换出去。 这个默认值是故意选择的：fielddata不是临时的cache。它是一个在内存里为了快速执行必须能被访问的数据结构，而且构建它代价非常昂贵。如果你每个请求都要重新加载数据，性能就会很差。 一个有限的大小强迫数据结构去替换数据。我们将看看什么时候去设置下面的值，首先让我们看一个警告： 【warning】这个设置是一个保护措施，而不是一个内存不足的解决方案Fielddata大小
indices.fielddata.cache.size: 40%当然可以设置成堆大小的百分比，也可以是一个具体的值，比如 8gb；通过适当的设置这个值，最近被访问的fielddata将被清除出去，给新加载的数据腾出空间。 在网上你可能会看到另外一个设置参数： indices.fielddata.cache.expire 。千万不要使用这个设置！这个设置高版本已经废弃。这个设置告诉Elasticsearch把比过期时间老的数据从fielddata里驱逐出去，而不管这个值是否被用到。这对性能是非常可怕的 。驱逐数据是有代价的，并且这个有目的的高效的安排驱逐数据并没有任何真正的收获。没有任何理由去使用这个设置；我们一点也不能从理论上制造一个假设的有用的情景。现阶段存 在只是为了向后兼容。我们在这个书里提到这个设置是因为这个设置曾经在网络上的各种文章里 被作为一个 ``性能小窍门'' 被推荐过。记住永远不要使用它，就ok！
监控fielddata使用了多少内存以及是否有数据被驱逐是非常重要的。大量的数据被驱逐会导致严重的资源问题以及不好的性能。 Fielddata使用可以通过下面的方式来监控：监控fielddata
- 对于单个索引使用 {ref}indices-stats.html[indices-stats API]:
GET /_stats/fielddata?fields=*
- 对于单个节点使用 {ref}cluster-nodes-stats.html[nodes-stats API]:
GET /_nodes/stats/indices/fielddata?fields=*
- 或者甚至单个节点单个索引
GET /_nodes/stats/indices/fielddata?level=indices&fields=*通过设置 ?fields=* 内存使用按照每个字段分解了.
断路器(breaker)
聪明的读者可能已经注意到fielddata大小设置的一个问题。fielddata的大小是在数据被加载之后才校验的。如果一个查询尝试加载到fielddata的数据比可用的内存大会发生什么情况？答案是不客观的：你将会获得一个OutOfMemory异常。
Elasticsearch包含了一个 fielddata断路器 ，这个就是设计来处理这种情况的。断路器通过检查涉及的字段（它们的类型，基数，大小等等）来估计查询需要的内存。然后检查加 载需要的fielddata会不会导致总的fielddata大小超过设置的堆的百分比。
如果估计的查询大小超过限制，断路器就会触发并且查询会被抛弃返回一个异常。这个发生在数据被加载之前，这就意味着你不会遇到OutOfMemory异常。
Elasticsearch拥有一系列的断路器，所有的这些都是用来保证内存限制不会被突破：
indices.breaker.fielddata.limit这个 fielddata 断路器限制fielddata的大小为堆大小的60%，默认情况下。
indices.breaker.request.limit这个 request 断路器估算完成查询的其他部分要求的结构的大小，比如创建一个聚集通， 以及限制它们到堆大小的40%，默认情况下。
indices.breaker.total.limit这个total断路器封装了 request 和 fielddata 断路器去确保默认情况下这2个 使用的总内存不超过堆大小的70%。
断路器限制可以通过文件 config/elasticsearch.yml 指定，也可以在集群上动态更新：
PUT /_cluster/settings这个限制设置的是堆的百分比。
{
"persistent" : {
"indices.breaker.fielddata.limit" : 40% (1)
}
}
最好把断路器设置成一个相对保守的值。记住fielddata需要和堆共享 request 断路器， 索引内存缓冲区，过滤器缓存，打开的索引的Lucene数据结构，以及各种各样别的临时数据 结构。所以默认为相对保守的60%。过分乐观的设置可能会导致潜在的OOM异常，从而导致整 个节点挂掉。
从另一方面来说，一个过分保守的值将会简单的返回一个查询异常，这个异常会被应用处理。 异常总比挂掉好。这些异常也会促使你重新评估你的查询：为什么单个的查询需要超过60%的 堆空间。
断路器和Fielddata大小
在 Fielddata大小部分我们谈到了要给fielddata大小增加一个限制去保证老的不使用 的fielddata被驱逐出去。indices.fielddata.cache.size 和 indices.breaker.fielddata.limit 的关系是非常重要的。如果断路器限制比缓冲区大小要小，就会没有数据会被驱逐。为了能够 让它正确的工作，断路器限制必须比缓冲区大小要大。
我们注意到断路器是和总共的堆大小对比查询大小，而不是和真正已经使用的堆内存区比较。 这样做是有一系列技术原因的（比如，堆可能看起来是满的，但是实际上可能正在等待垃圾 回收，这个很难准确的估算）。但是作为终端用户，这意味着设置必须是保守的，因为它是 和整个堆大小比较，而不是空闲的堆比较。
参考：Elasticsearch权威指南笔记
官网：https://www.elastic.co/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html
收起阅读 »
Hadoop fs命令学习小记
1，hadoop fs –fs [local |
2，hadoop fs –ls
3，hadoop fs –lsr
4，hadoop fs –du
5，hadoop fs –dus
6，hadoop fs –mv
7，hadoop fs –cp
8，hadoop fs –rm [-skipTrash]
9，hadoop fs –rmr [skipTrash]
10，hadoop fs –rmi [skipTrash]
11，hadoop fs –put
12，hadoop fs –copyFromLocal
13，hadoop fs –moveFromLocal
14，hadoop fs –get [-ignoreCrc] [-crc]
15，hadoop fs –getmerge
16，hadoop fs –cat
17，hadoop fs –copyToLocal [-ignoreCrc] [-crc]
18，hadoop fs –mkdir
19，hadoop fs –setrep [-R] [-w]
20，hadoop fs –chmod [-R]
21，hadoop fs -chown [-R] [OWNER][:[GROUP]] PATH…：修改文件的所有者和组。-R表示递归。
22，hadoop fs -chgrp [-R] GROUP PATH…：等价于-chown … :GROUP …。
23，hadoop fs –count[-q]
最后就是万能的hadoop fs –help 收起阅读 »
Hbase shell常用命令小记
$HBASE_HOME/bin/hbase shell
如果有kerberos认证，需要事先使用相应的keytab进行一下认证（使用kinit命令），认证成功之后再使用hbase shell进入可以使用whoami命令可查看当前用户
hbase(main):002:0> whoami
2016-09-12 13:09:42,440 WARN [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
root (auth:SIMPLE)
groups: root
2、表的管理
1）查看有哪些表
hbase(main):001:0> list2）创建表
TABLE
pythonTrace
1 row(s) in 0.1320 seconds
语法：create
