两周前荣耀刚刚发布了2015年旗舰机型荣耀7，这次又要发布新品，为荣耀4A，并且在7月21到7月23日举办荣耀暑飙节。同时会联合民谣歌手专门为荣耀4A征集创作一首《青春优等生》的主题曲。 青春盛惠6大看点 1、荣耀家族全系产品携神秘新品亮相 2、7.15-20每天10:08以7.21元开秒热门手机 3、十大销售平台三天九场开售 4、十大平台购买用户抽奖赢取荣耀产品 5、配件4折起 6、15万份精彩旅程任性送…耀青春飙起来 这是华为荣耀第二次举办暑飙节，暑飙节主要是面对放暑假的学生，这次暑飙节，相信华为荣耀肯定会备足货，给年轻人的一次青春盛宴。 还有一个激动点：7月15到7月20日 每天都可以vmall上7.21元秒杀荣耀手机，现在就要设闹铃提醒了。

在java中产生uuid的方式是使用java.util.UUID。 UUID.randomUUID().toString(); 我在测试redis性能时，使用uuid产生测试数据，发现多线程测试redis的rpush接口的时候，性能老是上不去。 查看cpu利用率也不高，网卡流量也不大。就是tps上不去。但是如果用两台client去测，又可以达到更高的tps。 后来直接用jstack查看了下堆栈，发现大多数线程停留在： java.lang.Thread.State: BLOCKED (on object monitor) at java.security.SecureRandom.nextBytes(Unknown Source) - waiting to lock <0x00000005ffe1c548> (a java.security.SecureRandom) at java.util.UUID.randomUUID(Unknown Source) 原来uuid的生成遇到了性能瓶颈。于是我单独测试了下生成随机uuid的性能,发现无论是1个线程还是32个线程还是300个线程，它的tps只能到10万级别。 甚至是线程数越大，tps越低。tps在每个机器上都不一样，有的机器上测试tps只有5万。我们就以一台双核4G内存的虚拟机为例： tps在 140000+ 我们看randomUUID方法的javadoc的描述是： The UUID is generated using a cryptographically strong pseudo random number generator 也就是说uuid使用了一个强随机数，也也保证了uuid的不重复性。 public static UUID randomUUID() { SecureRandom ng=numberGenerator; if(ng == null) numberGenerator=ng=new SecureRandom(); byte[] randomBytes=new byte[16]; ng.nextBytes(randomBytes); return new UUID(randomBytes); } 再看SecureRandom的javadoc Note: Depending on the implementation, the generateSeed and nextBytes methods may block as entropy is being gathered, for example, if they need to read from /dev/random on various unix-like operating systems. ...

2015年6月30日，荣耀7发布，7天预约时间，京东和华为商城总预约量创纪录的达900多万，7月7日第一次发售，20万荣耀7在2分钟内售罄，说明华为荣耀又一次得到了花粉的认可和喜爱。不知道是什么时候开始，华为手机的一些独有技术被花粉称为黑科技，并为花粉喜爱。本文主要细数一下荣耀7有哪些黑科技： 第一：双卡盲插功能，自动识别SIM卡 荣耀7全网通可以实时检测两个4G卡的网络信号，自动选择最佳的信号。双通道智能下载，可以支持双卡同时上网。 第二：指纹识别，双硬件保护。 指纹识别有自学习功能，越用越灵敏，其次指纹识别键还可以做home键等其它功能。 第三：荣耀小口哨 荣耀小口哨是个智能蓝牙耳机，可以实现语音控制，可以插到手机上充电，可以同时支持两部手机。 第四：智灵键 双击智灵键可以打开情景智能功能，长按智灵键可以打开荣耀7的语音控制功能。用户可以查询饭店、购买车票甚至一键语音打车，整个过程不需要二次操作直达用户需求。 第五：语言找手机功能，黑屏打电话。 只要喊一句“荣耀小七，你在哪儿”，你的手机就会自动回应并播放音乐。 当然除此之外，华为荣耀7还有其它优势，例如NFC、红外遥控，2000W像素，全金属机身，3G内存，麒麟935、光绘摄影等。我想无论是配置还功能上这次荣耀7都无可挑剔。 当然一些米粉总是要挖空心思找一些东西来喷的。

cassandra2.1版终于出了稳定版-cassandra2.1.6版。照例把之前的功能在新版本上跑一跑。但是仍然遇到一个问题： 创建一个表 CREATE TABLE test ( a int, b int, c int, d int, PRIMARY KEY (a, b, c) ); 根据a=1 and b<6查询结果是： select * from test where a=1 and b<6; a | b | c | d —+—+—+— 1 | 3 | 1 | 2 1 | 3 | 2 | 2 1 | 3 | 4 | 2 1 | 3 | 5 | 2 1 | 4 | 4 | 2 1 | 5 | 5 | 2 ...

单个文件，对其内容进行排序，使用sort命令： sort a.txt 去重加-u选项 sort -u a.txt 输出到一个文件 sort -o a.txt_sort -u a.txt 如果是100个1G大小的文件呢？如何进行排序去重呢？使用sort命令也是可以实现的。 第一步：先对单个文件进行排序去重 sort -o a1.txt -u a1.txt sort -o a2.txt -u a2.txt sort -o a3.txt -u a3.txt sort -o a4.txt -u a4.txt 。。。。 sort -o a100.txt -u a100.txt 第二步：使用sort的合并排序 sort -o a.txt -u -m a*.txt -m选项 表示merge已经有序的文件，如果文件事先没有排好序，这个可能会出错。 在执行merge的时候，你可能会遇到空间不足，无法写/tmp/sortXXXX的错误。 因为是多个大文件的合并操作，内存不够用，肯定是要写临时文件的。默认sort是写到/tmp目录下。 还好sort命令想的周到，你可以通过-T 选项指定一个较大空间的磁盘目录作为sort的临时文件目录。 sort -o a.txt -T /disk/temp -u -m a*.txt 最后等结果吧。

写博客，写的不好的时候，就想删除，目录结构设计的不合理，就想更改。但是有一些网页已经被百度等搜索引擎收录了。用户访问的时候就会显示404页面，表示页面不存在。 在过去，网站通常的做法是把404页面写上友好的提示语，或者随机显示一则笑话，甚至是直接跳转到主页。 现在有很多大型的网站，像百度、腾讯等都已经把404页面改为公益广告，特别是寻找丢失儿童的广告。例如腾讯公司内部员工志愿者就发起了这样一起互联网公益活动，建议站长博主在自己的404页面中嵌入一段简单的代码，就能通过互联网来迅速传播失踪儿童信息，从而提高找回失踪儿童的概率。 我认为这是个好主意，从今天开始，赵岩的博客正式加入公益404页面，打开不存在的页面都会跳转到公益寻人广告页面。 比如：http://zhaoyanblog.com/404.html

华为昨日公布了P8Max这款旗舰机的价格（3788元），同时也向媒体公布了其上半年手机出货量的情况。据华为介绍称，2015年上半年，华为手机出货量达到5000万部，5月单月出货量便达到1000万部，销量同比增长了40%，中国市场占比50%。 提到P8 Max这款新机时，华为终端中国区总裁朱平表示，中国中、高、低端手机都有一定的市场空间，而价格并非决定消费者需求的关键。P8 Max配置了6.8英寸的超大屏幕，主打高端商务人群，3788元的价格在中国手机市场中也属于高端水平。 华为CMO杨哲杨哲也表示，只要产品能够触及用户的真正需求，价格并不是问题。华为P8 Max国行版将于6月26日正式开售

cassandra是集群部署，多个节点，多个数据备份，一两个节点挂掉，一般不会有数据丢失。只要删除当掉的节点，对其它节点进行repair，数据都会自动均衡到完整的份数。 但是如果大面积节点掉电，或者机房着火那就肯定要丢失数据了，使用cassandra作为数据存储的业务，肯定是很大的业务，数据量超大的那种。机房容灾肯定是必不可少的。 cassandra提供多种多数据中心部署、机架敏感策略。这里介绍一种最普通的一种: GossipingPropertyFileSnitch GossipingPropertyFileSnitch策略支持简单的多个数据中心，和多机架。 第一步： 在cassandra.yaml配置文件中指定集群支持该策略： endpoint_snitch: GossipingPropertyFileSnitch 第二步： 在cassandra.yaml的seeds中把两个数据中心的种子节点都配上 seeds: “192.168.22.101,192.168.22.102,192.168.23.101,192.168.23.102” 第三步： 配置cassandra-rackdc.properties 每台机器都配置自己所属的数据中心名称和机架名称 dc=DC1 rack=RAC1 配置机架的目的是，防止整个机框掉电，数据丢失。cassandra可以尽量保证同一份数据的多个副本不存在于同一个机架上。 这就要求你的机架个数要大约等于你的数据副本个数，同时每个机架的节点个数尽量相同，否则会导致某些节点数据偏多，分布不均 第四步 创建keyspace使用NetworkTopologyStrategy策略，并且制定每个集群的份数。 CREATE KEYSPACE mykeyspace WITH replication = { ‘class’: ‘NetworkTopologyStrategy’, ‘DC1’: ‘3’, ‘DC2’: ‘3’ }; 第五步 客户端使用数据一致性策略，从QUORUM改为LOCAL_QUORUM。这样客户端会先从LOCAL数据中查询，LOCAL无法查询，再从REMOTE数据中心进行查询。 cassandra JAVA官方驱动，把默认首先连上的节点所属的数据中心视为LOCAL数据中心。所以你不要容灾数据中心节点IP配到了代码中。

6月15日 @华为荣耀官方微博确定了荣耀7的发布时间和地点： 2015年6月30日 北京工业大学奥林匹克体育馆 海报是一个大大的指纹，确认荣耀7是带指纹识别无疑。 这是工信部网站注册型号为PLK-AL10的一款手机，想必就是荣耀7，从背面看，荣耀7的指纹识别是借用了Mate7的设计。 至于更多的细节和科技提升，我们要等发布会当天知晓了。

Elasticsearch 是默认延迟加载fielddata到内存里的。当elasticsearch第一次遇到一个查询需要一个指定field的fielddata的时候，就会把索引的每个段中整个field加载到内存。对于小段，这是个可以忽略不计的时间，但是如果你有一些5G大小的段并且需要加载10GB的fielddata到内存里，这个过程需要数十秒，习惯于秒内响应时间的用户会被网突如其来的迟钝所打击。 有三种方法应对这种延迟尖峰： Eagerly load fielddata（饿汉式（预）加载fielddata） Eagerly load global ordinals（饿汉式（预）加载全局序数） Prepopulate caches with warmers （使用warmer提前加载缓存）。 所有这些都是一个意思：预先加载fielddata到内存里，这样当用户需要执行一个搜索的时候就感受不到延迟了。 饿汉式（预）加载fielddata 首先是预先加载（而不是默认的延迟加载），当一个新的段形成时（无乱是刷新，写入或者是合并），可以预先加载的field会提前把段的fielddata加载到内存里，在这段可以用于搜索之前。 这意味着当你第一次查询的时候，如果碰到在这个段上，你不需要再触发加载fielddata的操作，它们已经在内存中了，这会防止你的用户遇到一些冷到缓存而发生延迟尖峰。 预先加载是基于每个field的，所以你可以控制哪些field进行预加载。 PUT /music/_mapping/_song { "price_usd": { "type": "integer", "fielddata": { "loading" : "eager" } } } 备注: 通过设置fielddata.loading: eager，告诉elasticsearch预先加载这个field的内容到内存里。 fielddata的加载可以设置成饿汉模式（预先加载）还是懒惰模式（延迟加载），使用update-mapping的api。 预先加载是简单对fielddata加载的开销的转移，从查询时间转义到刷新时刻。 大段的刷新时间会比小段的时间长，通常大段的产生都是由哪些已经可搜素的小段合并而来的，所以慢一点的刷新时间不是那么重要（译者注：意思是大段的刷新时间长不影响你的搜索，在大段合并成前的小段可以用于搜索）。 全局序数 其中一项用于减少string类型的fielddata占用内存的技术叫做序数。 假设我们有十亿条文档，每个文档都有一个status的field，只有三个值：status_pending, status_published, status_deleted，如果我们把所有的status加载到内存里，每个文档需要14-16byte，也就是说15GB 相反，我们可以确认这三个特殊的字符串，对他们排序，依次编号0,1,2 Ordinal | Term ------------------- 0 | status_deleted 1 | status_pending 2 | status_published 序号对应的字符串值要在序号列表中存储一次，每个文档只要使用他们的编号来表示他们所包含的值就可以了。 Doc | Ordinal ------------------------- 0 | 1 # pending 1 | 1 # pending 2 | 2 # published 3 | 0 # deleted 这个可以把15GB的内存占用减少到小于1GB ...

最近几日 @华为荣耀 官方微博已经连续发布微博海报，表示6月8日会有新产品发布。 无论是从小苹果的苹果把，还是汽水瓶的吸管，形状都预示这款产品很可能是荣耀旗舰机型荣耀7。 而且荣耀6是去年6月24日发布的，时隔一年，荣耀7也是时候横空出世了。 但是总觉得这个宣传还不到位，首先发布会在一周前才开始宣传，而且至今也没有曝光媒体邀请函，以及发布会地点，有点反常。 很希望这次发布的是荣耀7，但是也有可能是荣耀其它产品，期待6月8日发布会。 6月6日 有那么一点冰爽，#有点意思# 6月5日 有那么一点勇敢，#有点意思# 6月4日 有那么一点诱惑，#有点意思# 6月3日 有那么一点速度，#有点意思# #李娜产女# 荣耀也有新宝贝！@李娜#有点意思# 6月2日 有那么一点生活，#有点意思# 6月1日 想象力概括了世界的一切。——阿尔伯特·爱因斯坦

ThreadPool部分 Elasticsearch 内部使用了线程池，通过这些线程池之间的合作完成工作，在需要时传递工作。一般来说你不需要调整和优化线程池。但是有时候你看着这些线程池的状态，对你掌握你的集群行为是很有帮助的。 这有十几个线程池，他们的格式都是类似的： "index": { "threads": 1, "queue": 0, "active": 0, "rejected": 0, "largest": 1, "completed": 1 } 每个线程都列出了配置的线程数，其中有多少个线程是正在处理事务的，也就是活动的，还有多少等待处理的事务在队列里。 如果队列满了，超出了限制，新的事务就会开始被拒绝，你可以看到拒绝的事务的统计，这通常表示你的集群正处在一个资源瓶颈，因为一个满的队列表示你的集群或者节点正在以最大的速度处理事务，但是依然赶不上新事务增加的速度。 关于bulk的拒绝 如果你的线程队列出现拒绝请求的事情，那么醉有可能发生的就是bulk批量索引的请求，通过采用并发导入线程，很容易发给elasticsearch很多的bulk请求，并发请求越多越好吗？ 现实中，任何集群都有一定的线程，造成入不敷出。一旦这个阈值达到了，你的队列就会被迅速的填满，新的bulk请求就会被拒绝。 这是一个好事，队列的拒绝是对压力的一个有效措施，他们告诉你你的集群正在处于最大的容量，这要好过把数据全部塞到内存队列里。增大队列大小不会提升性能，它只会隐藏问题，如果你的集群每秒只能处理1万个文档，这和你的队列大小是100还是一千万没有任何关系，你的集群每秒的处理能力仍然是1万个文档。 队列只会隐藏性能问题，并且带来数据丢失的风险，在队列里的表示还没有被处理的，如果你的节点挂了，那么这些请求就会永远的丢失了，此外队列会消耗很大的内存，这不是个好主意。 最好我们通过优雅的解决队列满了的问题来清理队列。当你遇到bulk拒绝请求时候，你应该采取如下措施： 1、停止插入线程3-5秒 2、从bluk请求里提取被拒绝的操作，可能大部分请求都成功了。bulk的响应里会告诉你哪些操作成功了，哪些操作被拒绝了。 3、把拒绝的操作重新生成一个新的bulk请求。 4、如果再有拒绝请求发生，就重复上面的步骤。 通过这种方式，你的代码会自然的适应你的集群的负载，自然的减压。 请求拒绝不是错误，它们只是表示你需要过会重试。 有十几个线程池，大部分你可以忽视，但是有少部分需要你特别注意： indexing 正常的索引文档的请求 bulk 批量请求，这有区别于非批量的请求 get 根据id获取文档的操作 search 索引的检索和查询请求 merging 专门管理lucene合并的线程池 FS和Network部分（剩余空间和网络） 继续看node stats api返回的信息，你会看到一个关于文件系统的统计信息，剩余空间，数据存放目录，磁盘io等待。如果你没有监控剩余磁盘空间大小，你可以从这里得到。磁盘io也是很容易得到，但是一些更专业的命令行工具（例如iostat）可能更有用。 很显然，如果你的磁盘空间不足了，elasticsearch肯定完蛋了，所以一定要保证充足的磁盘空间。 下面是关于network统计的两个部分： "transport": { "server_open": 13, "rx_count": 11696, "rx_size_in_bytes": 1525774, "tx_count": 10282, "tx_size_in_bytes": 1440101928 }, "http": { "current_open": 4, "total_opened": 23 }, transport: 显示了网络传输的基本信息，这涉及到节点之间的通信（通常是9300端口）和一些客户端和节点之间的链接。如果你看到很多链接在这里，不要担心，elasticsearch会保持大量的节点之间的链接。 ...

操作系统和进程部分 操作系统和进程部分的含义是很清楚的，这里不会描述的很详细。他们列出了基本的资源统计，例如CPU和负载。操作系统部分描述了整个操作系统的情况，进程部分只是描述了Elasticsearch的JVM进程的使用情况。 这显然是很有用的统计， 但是往往会被忽视，一些统计包括如下部分： CPU 负载 内存使用情况 swap使用情况 打开文件句柄数 JVM部分 jvm部分包含一些有关于运行elasticsearch的jvm进程的关键信息。最重要的是，它包含了垃圾回收方面的细节，这对你的elasticsearch的集群的稳定性有很大影响。 垃圾收集（GC）入门 在我们描述这个之前，很有必要先介绍下GC以及它对elasticsearch的影响。如果你对jvm中的GC很熟悉，可以跳过这一章。 java是一个自己进行垃圾回收的语言，也就是说程序员不需要主动管理内存的分配和释放。程序员只要专心写自己的代码，java虚拟机会管理根据需要分配内存的过程，然后当内存不再使用的时候，它自己会去释放。 当内存被分配给JVM进程，它会被分配成一个叫堆的大块区域。JVM会把这个堆分成两组，叫做“代”： 年轻代（或者伊甸园） 新实例化的对象就在这里分配空间，年轻代的空间通常很小，大约100MB-500MB。年轻代包含两个幸存者区域 老年代 存储那些老的对象的区域。这些对象是长期存在，并且持续很长时间。老年代通常比年轻代大很多。你可以看到elasticsearch节点的老年代可能大到30GB 当一个对象被实例化后，它会被放置到年轻代，当年轻代的空间满了，一个年轻代的垃圾回收就启动了。那些仍然存活的对象就会被移动到其中一个幸存者区域。而死了的对象就会被清除了。如果一个对象在年轻代中经历了多次GC仍然幸存，那它将被晋升到老年代。 类似的过程也发生在老年代，当老年代的空间越来越满了，一个垃圾回收就启动了，同时死了对象会被清除。 天下没有免费的午餐，年轻代和老年代的垃圾回收都包含一个“stop-the-world”的阶段。在这个时间内，JVM会停止程序的执行，进行对象的标记和收集，在这个stop-the-world的阶段，没有任何事情发生，请求不会被处理，ping不会被会回应。shards不会再进行迁移。整个世界真的停止了。 对于年轻代这不是一个问题，因为它很小，GC执行的很快。但是对于大一点的老年代，缓慢的GC意味着1s甚至15s的停顿，这对于一个服务器软件来说是不可接受的。 垃圾回收在JVM是很复杂的算法，为了减少停顿做了很多的工作。同时Elasticsearch很努力适应GC，比如通过内部对象的重用，利用网络缓冲区，并挺贵一些特征值例如文档的数量。但是GC的频率和长短是需要你特别留意的信息，因为它是集群不稳定的头号元凶。 如果一个集群经常性的发生长时间GC，那么你的集群一定内存不足并且负载特别高。这些长时间GC会导致节点周期性的脱离集群。这种不稳定会导致分片数据不断的重新生成，以保证集群内的平衡以及足够的分片数量。这会增加网络贷款和磁盘IO，同时你的集群还要承担进行正常的索引数据和查询。 简而言之，长时间的GC是很糟糕的，需要尽可能的减少。 因为GC对Elasticsearch如此重要，你必须对node stats的API显示的这个部分特别熟悉才行。 "jvm": { "timestamp": 1408556438203, "uptime_in_millis": 14457, "mem": { "heap_used_in_bytes": 457252160, "heap_used_percent": 44, "heap_committed_in_bytes": 1038876672, "heap_max_in_bytes": 1038876672, "non_heap_used_in_bytes": 38680680, "non_heap_committed_in_bytes": 38993920, jvm部分首先列出的是有关堆内存使用情况的一般情况，你可以看到多少heap被用到，有多少可以被使用（已经分配了线程），还有堆内存最大可以长到多少。理想情况下heap_committed_in_bytes应该和heap_max_in_bytes相同，如果被分配的堆较小，那JVM将会不得不调整堆的大小，这个过程代价是很高的。如果你的这两个值是不同的，请看《Heap: Sizing and Swapping》章节，确认你配置的是否正确。 heap_used_percent 是你必须盯着看的一个有用的参数。Elasticsearch配置的是当堆使用到75%的时候进行GC，如果你的节点总是大约75%，那你节点正在承受内存方面的压力，这是一个告警，预示着你不久就会出现慢GC。 如果你的heap使用率一直在85%以上，那你有麻烦了，90-95%的概率会因为10-30s的GC 发生性能问题，这还是好的，最坏的就是发生内存溢出。 "pools": { "young": { "used_in_bytes": 138467752, "max_in_bytes": 279183360, "peak_used_in_bytes": 279183360, "peak_max_in_bytes": 279183360 }, "survivor": { "used_in_bytes": 34865152, "max_in_bytes": 34865152, "peak_used_in_bytes": 34865152, "peak_max_in_bytes": 34865152 }, "old": { "used_in_bytes": 283919256, "max_in_bytes": 724828160, "peak_used_in_bytes": 283919256, "peak_max_in_bytes": 724828160 } } }, young, survivor, and old sections 显示了每个代在GC中的使用情况，供你分析。这些数据方便你看到他们的相对大小，但是对于你调查问题往往不是很重要。 ...

第一：去掉一些不用的html head内容，让页面更小 在function.php中加入： remove_action( ‘wp_head’, ‘wp_generator’); remove_action( ‘wp_head’, ‘wlwmanifest_link’); remove_action( ‘wp_head’, ‘rsd_link’); remove_action( ‘wp_head’, ‘index_rel_link’ ); remove_action( ‘wp_head’, ‘parent_post_rel_link’, 10, 0 ); remove_action( ‘wp_head’, ‘start_post_rel_link’, 10, 0 ); remove_action( ‘wp_head’, ‘adjacent_posts_rel_link_wp_head’, 10, 0 ); remove_action( ‘wp_head’, ‘feed_links’, 2 ); remove_action( ‘wp_head’, ‘feed_links_extra’, 3 ); remove_action( ‘wp_head’, ‘wp_print_head_scripts’, 9 ); remove_action( ‘wp_head’, ‘rel_canonical’ ); remove_action( ‘wp_head’, ‘wp_shortlink_wp_head’, 10, 0 ); 第二：去掉一些定时任务，这些定时任务会频繁访问数据库和网络 在function.php中加入： remove_action( ‘init’, ‘wp_schedule_update_checks’ ); remove_action( ’load-plugins.php’, ‘wp_update_plugins’ ); remove_action( ’load-themes.php’, ‘wp_update_themes’ ); remove_action( ’load-update-core.php’, ‘wp_update_plugins’ ); remove_action( ’load-update-core.php’, ‘wp_update_themes’ ); remove_action( ’load-update.php’, ‘wp_update_plugins’ ); remove_action( ’load-update.php’, ‘wp_update_themes’ ); remove_action( ‘upgrader_process_complete’, ‘wp_update_plugins’ ); remove_action( ‘upgrader_process_complete’, ‘wp_update_themes’ ); remove_action( ‘upgrader_process_complete’, ‘wp_version_check’ ); remove_action( ‘wp_maybe_auto_update’, ‘wp_maybe_auto_update’ ); remove_action( ‘wp_update_plugins’, ‘wp_update_plugins’ ); remove_action( ‘wp_update_themes’, ‘wp_update_themes’ ); remove_action( ‘wp_version_check’, ‘wp_version_check’ ); ...

集群的健康只是一个方面，它是对整个集群所有方面的一个很高的概括。节点状态的api是另外一个方面，它提供了关于你的集群中每个节点令你眼花缭乱的统计数据。 节点的状态提供了那么多的统计数据，在你很熟悉它们执勤，你可能不确定哪些指标是至关重要。我们会把需要监控的最重要的几个指标跳出来（我们建议你把所有的统计指标记录下来，例如使用Marvel插件，因为你不知道你哪天可能就需要）。 节点状态的API可以通过下面的方式执行 GET _nodes/stats 在输出内容的开头，我们可以看到集群的名字和我们第一个node的信息： { "cluster_name": "elasticsearch_zach", "nodes": { "UNr6ZMf5Qk-YCPA_L18BOQ": { "timestamp": 1408474151742, "name": "Zach", "transport_address": "inet[zacharys-air/192.168.1.131:9300]", "host": "zacharys-air", "ip": [ "inet[zacharys-air/192.168.1.131:9300]", "NONE" ], ... 节点会根据一个hash值的顺序来显示，也就是node的uuid值。还有一些关于node的网络属性会显示（例如传输地址和HOST）。这些信息有助于调试发现问题，比如那些节点没有加入集群。通常你可能会发现端口用错了，或者节点绑错了IP地址等等。 Indices部分 indices部分列出的是对于所有的索引在该节点上的汇总信息。 "indices": { "docs": { "count": 6163666, "deleted": 0 }, "store": { "size_in_bytes": 2301398179, "throttle_time_in_millis": 122850 }, 它返回的统计信息可以分成这样几个部分： docs: 显示有多少文档在该节点，以及有多少删除的文档还没有从数据段中清除出去。 store: 显示该节点消耗了多少物理存储，这个数据包含主分片和副分片，如果throttle_time_in_millis太大，说明你设置的磁盘流量太低（参考段的合并一章节） "indexing": { "index_total": 803441, "index_time_in_millis": 367654, "index_current": 99, "delete_total": 0, "delete_time_in_millis": 0, "delete_current": 0 }, "get": { "total": 6, "time_in_millis": 2, "exists_total": 5, "exists_time_in_millis": 2, "missing_total": 1, "missing_time_in_millis": 0, "current": 0 }, "search": { "open_contexts": 0, "query_total": 123, "query_time_in_millis": 531, "query_current": 0, "fetch_total": 3, "fetch_time_in_millis": 55, "fetch_current": 0 }, "merges": { "current": 0, "current_docs": 0, "current_size_in_bytes": 0, "total": 1128, "total_time_in_millis": 21338523, "total_docs": 7241313, "total_size_in_bytes": 5724869463 }, indexing： 表示索引文档的次数，这个是通过一个计数器累加计数的。当文档被删除时，它不会减少。注意这个值永远是递增的，发生在内部索引数据的时候，包括那些更新操作。 ...