3月1日OpenSSL.org官方发布一个OpenSSL的高危漏洞（CVE-2016-0800，别名"DROWN"）。该漏洞可能被黑客利用进行中间人攻击，窃取HTTPS加密数据的内容。OpenSSL官方已发布修复方案，建议各位用户关注并尽快升级系统修复漏洞！
        详情请查看官方公告：https://www.openssl.org/news/secadv/20160301.txt
        受影响的服务版本：
        Apache: 非2.4.x版本
        Nginx: 0.7.64、0.8.18及更早版本
        Postfix: 早于2.9.14、2.10.8、2.11.6、3.0.2的版本 (2015.07.20之前发布的版本)
        Openssl: 1.0.2a、1.0.1m、1.0.0r、0.9.8zf及更早版本
        OpenSSL版本检测：
        openssl version
        若版本低于修复版本请更新openssl
        针对web server,可通过如下方法检测：

        openssl s_client -connect 待测域名或IP地址:443 -ssl2
        漏洞修复方案：

        对于已经运行的云服务器，UCLOUD软件源已经提供了修复漏洞的openssl软件包，您可以通过手动更新openssl进行修复。
        详细修复方法如下：
        1、CentOS版本：
        yum clean all & yum makecache
        yum -y update openssl
        2、Ubuntu\Debian版本：
        sudo apt-get update
        sudo apt-get install libssl1.0.0
        若不想立即进行升级，您可以禁用sslv2协议，操作方法如下：

        1）Apache禁用sslv2协议：
        在Apache的SSL配置文件中禁用SSLv2协议（建议同时禁用SSLv3），确保SSLProtocol配置项内容如下：
        SSLProtocol All -SSLv2
        配置完毕，重启apache服务。
        2）Nginx禁用sslv2协议：
        修改nginx的SSL配置文件，设置只允许使用TLS协议，确保ssl_protocols配置项内容如下：
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2
        配置完毕，重启nginx服务

近日struts2官方发布了1个远程代码执行漏洞（CVE-2016-3087），该漏洞主要影响Struts 2.3.20 - Struts 2.3.28 (除2.3.20.3、2.3.24.3、2.3.28.1)版本，攻击者可利用该漏洞获取Struts程序的权限远程执行任意命令。

        受影响版本：
        Struts 2.3.20 - Struts 2.3.28 （2.3.20.3、2.3.24.3、2.3.28.1除外）

        漏洞描述：
        使用到REST插件的Struts2应用，在开启动态方法调用（DMI）的情况下，会被攻击者实现远程代码执行攻击。
        https://cwiki.apache.org/confluence/display/WW/S2-033 

        漏洞验证：
        检查Struts2的配置文件struts.xml，确认“struts.enable.DynamicMethodInvocation” 是否为“true"，如为“true"，且版本在受影响版本范围内，则说明受影响，否则不受影响。

        修复方案：
        如果您使用了Struts2并在受影响版本内，我们建议您尽快按照如下方案进行修复：
        1、禁用动态方法调用（DMI），修改Struts2的配置文件struts.xml，将struts.enable.DynamicMethodInvocation设置为“false”；
        2、目前官方已经推出了2.3.20.3、2.3.24.3和2.3.28.1修复这个问题，大家可以针对自己所使用的版本进行升级。下载地址：https://struts.apache.org/download.cgi#struts23281

关于蘑菇街：
中国最大的女性时尚社交电商平台。成立于2011年,总部位于浙江杭州, 目前(2015.Q3)拥有1.3亿注册用户,双十一日UV超2000万。2015.11.21日宣布完成D轮融资,并实施"一街双城"战略,杭州+北京,杭 州偏电商方向,北京偏社交媒体方向。 

蘑菇街业务架构-导购期（2011-2012）

运维早期情况 
早期阶段(2011-2012年)
      – 两位数机器、个位数网络设备
      – 没有运维,开发即运维,靠牛逼的脚本和一些开源工具搞定 
蘑菇街业务架构-转型期（2013）


运维的发展 
中间阶段(2013年-2014年)
           – 三位数服务器、两位数网络设备
           – 2-3名专职运维同学(主机&网络&DB&缓存&......) – 问题响应式的工作方式
– 工具化的运维平台

[]机器资源管理(CMDB的雏形)[/][] PHP发布系统[/][] 从指标维度监控系统(主机、QPS、RT、调用次数.... ) [/]

蘑菇街业务架构-社会化电商 我们应该怎么做 ​思路:

[]建立以应用服务为核心的管理标准体系[/][]打造CMDB、流程申请、持续集成和监控为一体的自动化运维系统, 而不是孤立的单点系统[/][]把运维能力服务化(API),使运维的能力无处不在 [/]

关于应用服务管理 ​ 案例介绍让我们看一个从服务器管理—申请—代码发布—线上监控的案例 关于应用服务器-Hestia服务和资源管理

[]从业务的维度来管理主机-CMDB的核心概念[/][]支持扩容、上下线、设备保障、权限等常规流程申请 [/]

[]自动化任务的配置和下发 [/]

关于应用服务管理-Mops流程申请系统 关于应用服务管理-发布系统以trade_ordership_service为标示,进行代码发布  关于应用服务管理-监控系统Sentry通用+自定义监控，运维+开发可以时刻关注自己的服务状态和质量 运维的现状 ​专业的运维团队 – 系统运维– 应用运维 – DBA– 运维开发• 运维的能力向平台化和服务化发展(DevOps,依赖于能力而不是人) – CMDB服务化平台– PHP+Java持续集成发布平台– 统一的监控平台– 全链路服务质量分析平台 – 稳定性平台– 容量评估平台(待做)• 工作方式的改变– 从问题响应式,向整体解决方案提供方向发展 双11技术保障，运维做了什么？

双11关键技术分享—全链路系统 全链路背景

[]复杂的分布式系统,页面上的一次链接点击,在后端 可能会产生几十次的RPC调用,Web、服务化、缓存、 消息、DB.......都有可能涉及,如果出了问题,如何快 速定位到故障点?要扩容,如何合理评估?[/][]关键概念,全局唯一的TraceId [/]

全链路技术架构 

全链路应用-快速发现问题点和瓶颈点

全链路应用-调用合理性分析 
没有明显的瓶颈点,每一次调用RT也很正常,但是全链整体的RT却很高, 问题又出在哪里了呢? 


全链路使用后的收益和后续
使用全链路后的收益
– 提升问题的定位效率 – 准确的评估容量
 
后续
– Mogu-Watch,与前端打通,实现用户全链路的分析 – 压测做到平时,与容量评估平台和资源分配打通
– 引入云资源弹性扩容,避免应对峰值的批量机器采购 
压测之后，关键技术改造-ATS静态化方案
静态化方案背景和简介
– 主链路(首页-详情&活动-交易-支付),降低RT,提升容量

– 资源类的如图片、CSS、JS等的静态化方案都会采用CDN技术

– 对于页面内容类的数据,如商品名称、商品详情等都属于静态数据,而 商品的库存、优惠等则需要获取动态结果

– 对于活动页面、H5活动推广页面等,则可以完全静态化 

ATS(Apache Traffic Server)静态化技术方案-Cheetah 

ATS静态化案例-商品详情页 ​

ATS静态化使用后的收益和后续 ​
• 使用静态化后的收益 
–  详情页(全站流量的30%+)静态化在双11期间的命中率达到95%,换言之,减少了后端服务接近30%的流量压力
–  RT从原来200ms降低到50ms,用户体验大大提升
–  容量提升,减少了后端服务器的数量

• 后续
– 借助云资源搭建云上的ATS,更贴近用户 – ATS Cluster方案
– 支持HTTPS
– 回源流控和容灾控制 
限流&降级开关推送和WEB应急扩容方案
• 限流&降级开关
– 限流,Web层,防止被流量打垮
– 降级,App层(服务化),保障核心应用

• Web应急扩容方案
– 选择Docker 容器,批量生成效率高 – 启动速度快
– 资源利用率提升明显 

大数据的出现,必将颠覆传统的数据管理方式。在数据来源、数据处理方式和数据思维等方面都会对其带来革命性的变化。对于数据库研究人员和从业人员而言,必须清楚的是,从数据库(DB)到大数据(BD),看似只是一个简单的技术演进,但细细考究不难发现两者有着本质上的差别。 

如果要用简单的方式来比较传统的数据库和大数据的区别的话,我们认为"池塘捕鱼" 和"大海捕鱼:是个很好的类比。"池塘捕鱼"代表着传统数据库时代的数据管理方式,而 "大海捕鱼"则对应着大数据时代的数据管理方式,"鱼"是待处理的数据。"捕鱼"环境条件的变化导致了"捕鱼"方式的根本性差异。这些差异主要体现在如下几个方面: 
 
1、数据规模:"池塘"和"大海"最容易发现的区别就是规模。"池塘"规模相对较小, 即便是先前认为比较大的“池塘”,譬如 VLDB(Very Large Database),和"大海"XLDB(Extremely Large Database)相比仍旧偏小。"池塘"的处理对象通常以 MB 为基本单位,而"大海"则 常常以GB,甚至是 TB、PB 为基本处理单位。 

2、数据类型:过去的"池塘"中,数据的种类单一,往往仅仅有一种或少数几种,这 些数据又以结构化数据为主。而在"大海"中,数据的种类繁多,数以千计,而这些数据又 包含着结构化、半结构化以及非结构化的数据,并且半结构化和非结构化数据所占份额越来 越大。
 
3、模式(Schema)和数据的关系:传统的数据库都是先有模式,然后才会产生数据。这 就好比是先选好合适的"池塘",然后才会向其中投放适合在该"池塘"环境生长的"鱼"。 而大数据时代很多情况下难以预先确定模式,模式只有在数据出现之后才能确定,且模式随 着数据量的增长处于不断的演变之中。这就好比先有少量的鱼类,随着时间推移,鱼的种类 和数量都在不断的增长。鱼的变化会使大海的成分和环境处于不断的变化之中。 

4、处理对象:在"池塘"中捕鱼,"鱼"仅仅是其捕捞对象。而在"大海"中,"鱼" 除了是捕捞对象之外,还可以通过某些"鱼"的存在来判断其他种类的"鱼"是否存在。也 就是说传统数据库中数据仅作为处理对象。而在大数据时代,要将数据作为一种资源来辅助 解决其他诸多领域的问题。 

5、处理工具:捕捞"池塘"中的"鱼",一种渔网或少数几种基本就可以应对,也就是 所谓的 One Size Fits All。但是在"大海"中,不可能存在一种渔网能够捕获所有的鱼类,也 就是说 No Size Fits All。 
 
从"池塘"到"大海",不仅仅是规模的变大。传统的数据库代表着数据工程(Data Engineering)的处理方式,大数据时代的数据已不仅仅只是工程处理的对象,需要采取新的 数据思维来应对。图灵奖获得者、著名数据库专家 Jim Gray 博士观察并总结人类自古以来, 在科学研究上,先后历经了实验、理论和计算三种范式。当数据量不断增长和累积到今天, 传统的三种范式在科学研究,特别是一些新的研究领域已经无法很好的发挥作用,需要有一 种全新的第四种范式来指导新形势下的科学研究。基于这种考虑,Jim Gray

一、什么是大数据，其核心和特点




二、预测演变而来的功能


一个东西要出故障，不会是瞬间的，而是慢慢地出问题的。通过收集所有的数据，我们可以预先捕捉到事物要出故障的信号，比方说发动机的嗡嗡声、引擎过热都说明它们可能要出故障了。系统把这些异常情况与正常情况进行对比，就会知道什么地方出了毛病。通过尽早地发现异常，系统可以提醒我们在故障之前更换零件或者修复问题。通过找出一个关联物并监控它，我们就能预测未来。
 
它不知道是哪些因素导致了机票价格的波动。机票降价是因为有很多没卖掉的座位、季节性原因，还是所谓的“周六晚上不出门”，它都不知道。这个系统只知道利用其他航班的数据来预测未来机票价格的走势。通过预测机票价格的走势以及增降幅度，Farecast票价预测工具能帮助消费者抓住最佳购买时机。
 

用来分析的数据包括好几百种生活方式的数据，比如爱好、常浏览的网站、常看的节目、收入估计等。通过利用相关关系，保险公司可以在每人身上节省125美元，然而这个纯数据分析法只需要花费5美元。

系统也设计了尽量少左转的路线，因为左转要求货车在交叉路口穿过去，所以更容易出事故。而且，货车往往需要等待一会儿才能左转，也会更耗油，因此，减少左转使得行车的安全性和效率都得到了大幅提升。
 
 
5000万条美国人最频繁检索的词条和美国疾控中心在2003年至2008年间季节性流感传播时期的数据进行了比较。他们希望通过分析人们的搜索记录来判断这些人是否患上了流感。谷歌公司为了测试这些检索词条，总共处理了4.5亿个不同的数学模型。在将得出的预测与2007年、2008年美国疾控中心记录的实际流感病例进行对比后，谷歌公司发现，他们的软件发现了45条检索词条的组合，将它们用于一个特定的数学模型后，他们的预测与官方数据的相关性高达97%。而疾控中心则要在流感爆发一两周后才能判断。

Facebook跟踪用户的“状态更新”和“喜好”，以确定最佳的广告位从而赚取收入;据说亚马逊销售额的三分之一都是来自于它的个性化推荐系统。
 
其他：车主识别，美国有一家叫23andMe的新公司提供个人的DNA测试分析，以发现一些疾病征兆。苹果公司的史蒂夫·乔布斯尝试了非常不同的方法。他得了癌症后，就有了自己全部的基因密码，数十亿的碱基对测序。这花费了他超过10万美元的成本，但这可以让医生完整地洞察他的基因密码。每当药物由于乔布斯的癌症病变而失去有效性，他们就可以根据乔布斯特定的基因信息，寻找到有效的替代药物。遗憾的是，这也没有保住乔布斯的命，但是在这一过程中获得的数据，已经延长了他的生命。使用大数据分析，每分钟可以搜集这些婴儿超过一千个数据点，麦格雷戈发现一个令人震惊的事实：每当这些早产儿出现非常稳定的标志时，他们的身体其实并不稳定，正在准备发病。有了这方面的知识，她就能在一个非常早期的阶段，确定婴儿是否需要药物治疗，从而挽救更多孩子的生命。
三、大数据下供应链变化
从供应链管理的维度上，企业建立基于消费者个体信息的数据库，并在此基础上，整合供应链管理信息，开展供应链协同营销，是降低营销成本，提升竞争力的重要方向。基于互动媒体、数据库及利害关系管理的互动式整合营销传播即能满足企业的这种需求，它强调，供应链上的企业应将建立关系的对象，从顾客扩大到包含供应商、经销商、组织内部人员、投资者等多方利益相关者，同时在销售、营销、顾客服务等方面建立更深层次的合作关系。
 
以零售供应链为例
1、实时交付管理 
 跟踪交货装运货物已有所改善。大数据有助于进一步改善它，通过启用实时交付管理,分析天气,交通,和卡车位置反馈来确定准确的交货时间。传感器可以用来跟踪高价物品装运。来自几个物流供应商的服务,如联邦快递SenseAware,通过提供实时信息让你在传播过程中控制你的供应链，在装运的环境条件,它的位置,它是否已被打开等等。 
 
这个功能可以帮助零售商实现运输易腐或高价产品或需要跟踪他们的出货量等其他原因。好消息是,解决方案可以实现无需重大改变现有的供应链设置的大部分工作，重点在整合不同的数据源。
 
2、提高订单拣货
订单拣货是一个劳动密集型的过程。如果订单可以更快,它们可以出货更快,更好的执行订单。大型零售商使用各种自动化机制快速选择命令,但随着大数据甚至是更小的零售商也可以改善订单拣货过程。 
 
大数据解决方案允许来自不同数据源的数据如订单、产品库存、仓库布局和历史分拣时间。通过零售商根据所定义的规则一起分析以改善整体的拣货过程。这个解决方案还可以在仿真模式下帮助改进订单拣货过程。在设计仓库和商店最后过程之前，订单拣货过程可以在仿真模式下进行优化通过调整不同的参数和设置，以最小影响仓库或存储。
 
3、更好的供应商管理
大多数零售商在他们的供应链有多个供应商，包括船舶供应商、第三方物流供应商、运输供应商和包装供应商。大数据分析解决方案对一组关键性能指标（KPI）启用实时评估的供应商绩效管理。 这些KPI包括供应商的盈利能力、及时的服务和客户的反馈和投诉。KPI与供应商系统实时跟踪通过整合。
 
KPI与供应商系统通过整合实时跟踪、财政投入（比如商品成本）、社交网络源相关供应商交货和产品包装，如果KPI不在定义的范围内，规则可以创建生成警报。这些实时分析解决方案确保服务质量和供应商业务的盈利能力保持在所需的水平而不需要任何额外的努力。 厂商也受益,因为他们知道究竟什么是要求他们继续保持您的业务。
 
4、自动化产品采购
由于产品缺货失去收入是痛苦的。大数据解决方案通过实时视图产品需求、产品销售和采购流程，帮助克服这一挑战。此外,一旦大数据解决方案部署,零售商可以停止标记某些产品的“延期交货”，因为他们总是知道确切的交货时间为他们采购，这也减少了废弃的购物车的数量。实际交货期与客户通过显示一个准确航运窗口前的订单共享,从而减少查询的订单。 
 
自动化解决方案的产品采购分析购买历史,产品交货期,和其他因素,可能会影响产品销售,如市场推广或天气变化。 在多个仓库或直接发运供应商的情况下,解决方案可以从不同的位置使用数据来确定源产品的最佳方式。
 
5、个性化或分段供应链
现今越来越多的顾客需要个性化的客户服务和个性化的产品。 通过大数据,零售商可以分析客户交互所在的所有渠道——社会、移动和web -确定客户是如何使用所购买的产品或如何购买。
 
例如,零售商可以部分提供一些购物者可配置产品的供应链,在那里他们可以选择特性,如颜色或有线与无线。 一段不同的顾客可以获得产品环保,和另一段可能会提供增值等功能包装。 所有这一切都可以做到实时匹配可用的产品与目标客户群体。 这将增加零售商总收入并提高盈利能力。沃尔玛：飓风来临之前，飓风用品和蛋挞放一起。 
 
结论 ：大数据提高供应链还有许多其他的方式 

[]供应商管理库存,直接连接到客户的系统。[/][]实时财务分析、计划和预测,以避免不必要的意外或成本。[/][]通过与合作伙伴收入共享即时满足商品。大多数的这些改进要求必须首先是合理的，忽略了大数据炒作的投资。[/]

 
四、我们的理解——客观面对"大" "数据"
我们的理解：大数据和贝叶斯理论（观点将随事实的改变而改变）有相似和共同之处：事实越多，观点也就越准确。
 
大数据是否可以全信？
如果亨利·福特问大数据他的顾客想要的是什么，大数据将会回答，“一匹更快的马。”如果依靠大数据，很显然只会得到错误的结论。在大数据的世界中，包括创意、直觉、冒险精神和知识野心在内的人类特性的培养显得尤为重要，因为进步正是源自我们的独创性。 
 
卓越的才华并不依赖于数据。史蒂夫·乔布斯多年来持续不断地改善Mac笔记本，依赖的可能是行业分析，但是他发行的iPod、iPhone和iPad靠的就不是数据，而是直觉——他依赖于他的第六感。当记者问及乔布斯苹果推出iPad之前做了多少市场调研时，他那个著名的回答是这样的：“没做！消费者没义务去了解自己想要什么。” 
 
效用层叠：“效用层叠”是一连串的自持事件，它可能开始于相对将要事件的媒体报道，然后引起公众恐慌和大规模群体行动。有些情况下，关于某一风险的媒体报道能抓住部分公众的注意力，这部分注意力进而会变成激愤和焦虑，而这种情感本身也是一种宣扬，会推进媒体跟进报道，继而会使人产生更大的焦虑，波及面也会更大。此时数据变得不可信。

比如：拉夫运河灾难、艾拉恐慌。

实例：在2013年4月，一家新闻机构的Twitterfeed被黑客攻击，该黑客发出了虚假的tweet，声称白宫正受到攻击。这则消息导致几家投资机构开始抛售股票，最终让这些公司遭遇巨大的财产损失。

这样的故事给我们敲响了警钟，数据，即使是大数据，并不一定是准确或者可行的。
 
五、结语
大数据提供的不是最终答案，只是参考答案，为我们提供暂时的帮助，以便等待更好的方法和答案出现。这也提醒我们在使用这个工具的时候，应当怀有谦恭之心，铭记人性之本。
 
物流专业男生组倾情打造分享！

#!/bin/bash



#增加1G的swap空间

dd if=/dev/zero of=/swapfile bs=1MB count=1024



#制作一个swap文件

mkswap /swapfile



#启动swap分区

swapon /swapfile



#添加开机自启

echo '/swapfile               none                    swap    defaults        0 0'   >>  /etc/fstab

1、蜻蜓FM 【 http://www.qingting.fm/#/home 】


2、豆瓣FM【 https://douban.fm/ 】


3、多听FM【 http://www.duotin.com/ 】

 
4、考拉FM【 http://www.kaolafm.com/ 】

 
5、荔枝FM【 http://lizhi.fm 】

 
6、喜马拉雅FM【 http://www.ximalaya.com/explore/】

 
7、酷FM【 http://fm.kugou.com】

 
8、企鹅FM【 http://fm.qq.com 】

 
周末放下工作，放空心情。打开手机或者你的APP，选择一个FM电台，用心倾听！还有其他喜欢的可以评论贴出！

Elasticsearch是一个开源的分布式实时搜索与分析引擎，支持云服务。它是基于Apache Lucene搜索引擎的类库创建的，提供了全文搜索能力、多语言支持、专门的查询语言、支持地理位置服务、基于上下文的搜索建议、自动完成以及搜索片段（snippet）的能力。Elasticsearch支持RESTful的API，可以使用JSON通过HTTP调用它的各种功能，包括搜索、分析与监控。此外，它还为Java、PHP、Perl、Python以及Ruby等各种语言提供了原生的客户端类库。下面是收集总结了一下使用elasticsearch所遇到的各类问题以及相关的解决方案。
 
1、由gc引起节点脱离集群
现象：

因为当ES节点发生gc（特别是old gc）时会使jvm停止工作，如果某个节点gc时间过长，master ping 3次（zen discovery ping失败重试3次

[默认]）不通后就会把该节点剔除出集群，从而导致索引进行重新分配。

解决避免方法：

1、优化gc设置，尽量减少gc时间。

2、调大zen discovery的重试次数（es参数：ping_retries）和超时时间（es参数：ping_timeout）。

3、注意硬盘的监控避免因为节点空间不足造成性能下降和出现脱离节点的问题。

 
2、out of memory错误
现象：

因为默认情况下ES对字段数据缓存（Field Data Cache）大小是无限制的，查询时会把字段值放到内存，特别是facet查询，对内存要求非常高，它会把结果都放在内存，然后进行排序等操作，一直使用内存，直到内存用完，当内存不够用时就有可能出现out of memory错误。

 解决避免方法：

1、设置es的缓存类型为Soft Reference,它的主要特点是据有较强的引用功能。只有当内存不够的时候,才进行回收这类内存,因此在内存足够的时候,它们通常不被回收。另外，这些引用对象还能保证在Java抛出OutOfMemory异常之前，被设置为null。它可以用于实现一些常用图片的缓存，实现Cache的功能，保证最大限度的使用内存而不引起OutOfMemory。在es的配置文件加上index.cache.field.type: soft即可。

2、设置es最大缓存数据条数和缓存失效时间，通过设置index.cache.field.max_size: 50000 来把缓存field的最大值设置为50000，设置index.cache.field.expire: 10m 把过期时间设置成10分钟。

3、无法创建本地线程问题
ES恢复时报错，如下：

RecoverFilesRecoveryException[[index][3] Failed to transfer [215] files with total size of [9.4gb]]; nested: OutOfMemoryError[unable to create new native thread]; ]]

 解决避免方法：
刚开始以为是文件句柄数限制，但想到之前报的是too many open file这个错误，并且也把数据改大了。查资料得知一个进程的jvm进程的最大线程数为：虚拟内存 /（堆栈大小10241024），也就是说虚拟内存越大或堆栈越小，能创建的线程越多。
重新设置后还是会报这个错，按理说可创建线程数完全够用了的，就想是不是系统的一些限制。后来在网上找到说是max user processes的问题，这个值默认是1024，这个参数单看名字是用户最大打开的进程数，但看官方说明，就是用户最多可创建线程数，因为一个进程最少有一个线程，所以间接影响到最大进程数。调大这个参数后就没有报这个错了。

1、增大jvm的heap内存或降低xss堆栈大小（默认的是512K）。

2、打开/etc/security/limits.conf 把soft  nproc  1024这行的1024增大。

4、集群状态为黄色时并发插入数据报错

[7]: index [index], type [index], id [1569133], message [UnavailableShardsException[[index][1] [4] shardIt, [2] active : Timeout waiting for [1m], request: org.elasticsearch.action.bulk.BulkShardRequest@5989fa07]]

这是错误信息，当时集群状态为黄色，即副本没有分配。当时副本设置为2，只有一个节点，当你设置的副本大于可分配的机器时，此时如果你插入数据就有可能报上面的错，因为es的写一致性默认是使用quorum，即quorum值必须大于（副本数/2+1），我这里2/2+1=2也就是说要要至少插入到两份索引中，由于只有一个节点，quorum等于1，所以只插入到主索引，副本找不到从而报上面那个错。
 
解决避免方法：

1、去掉没分配的副本

2、把写一致性改成one，即只写入一份索引就行。

5、设置jvm锁住内存时启动警告
当设置bootstrap.mlockall: true时，启动es报警告Unknown mlockall error 0，因为linux系统默认能让进程锁住的内存为45k。
 
解决方法：
设置为无限制，linux命令：

ulimit -l unlimited

6、错误使用api导致集群卡死
其实这个是很低级的错误。功能就是更新一些数据，可能会对一些数据进行删除，但删除时同事使用了deleteByQuery这个接口，通过构造BoolQuery把要删除数据的id传进去，查出这些数据删除。但问题是BoolQuery最多只支持1024个条件，100个条件都已经很多了，所以这样的查询一下子就把es集群卡死了。
 
解决方法：
用bulkRequest进行批量删除操作。
 
7、org.elasticsearch.transport.RemoteTransportException: Failed to deserialize exception response from stream
原因:
es节点之间的JDK版本不一样
 
解决方法：统一JDK环境
 

8、org.elasticsearch.client.transport.NoNodeAvailableException: No node available
1） 端口错

client = new TransportClient().addTransportAddress(new InetSocketTransportAddress(ipAddress, 9300));

这里9300 写成9200的话会No node available
要是你连的不是本机，注意IP有没有正确
2 ）jar报引用版本不匹配，开启的服务是什么版本，引用的jar最好匹配（这个我没有去试，反正我的是匹配的）

3） 要是你改了集群名字，还有设置集群名字

Settings settings = ImmutableSettings.settingsBuilder().put("cluster.name", "xxx").build();

            client = new TransportClient(settings).addTransportAddress(new InetSocketTransportAddress(ipAddress, 9300));

4）集群超过5s没有响应

解决方法：
1.设置client.transport.ping_timeout设大
             
 2.代码内加入

while (true) {

try {

bulk.execute().actionGet(getRetryTimeout());

break;

}

catch (NoNodeAvailableException cont) {

Thread.sleep(5000);

continue;

}

}

9.elasticsearch 近日被发现漏洞，可以远程执行任意代码，由于elasticsearch提供了http接口，导致可能通过CSRF等方式借助恶意页面浏览发生攻击。 漏洞影响版本:
elasticsearch 1.2以下
 测试代码：  浏览器会返回/etc/passwd内容解决方案：

1、在配置文件elasticsearch.yml里设置script.disable_dynamic: true

2、严格限制可访问elasticsearch服务的IP地址

参考：
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-scripting.html#_disabling_dynamic_scripts
重启后报503错误 
详情如此下：

[2015-09-23 17:42:33,499][WARN ][transport.netty          ] [Erik Magnus Lehnsherr] Message not fully read (request) for [4961353] and 

action [discovery/zen/join/validate], resetting

[2015-09-23 17:42:33,522][INFO ][discovery.zen            ] [Erik Magnus Lehnsherr] failed to send join request to master [[Red Lotus][

UG2WbJpDTHOB-EjzJFRsow][n025.corp.ncfgroup.com][inet[/10.18.6.25:9300]]], reason [org.elasticsearch.transport.RemoteTransportException:

 [Red Lotus][inet[/10.18.6.25:9300]][discovery/zen/join]; org.elasticsearch.transport.RemoteTransportException: [Erik Magnus Lehnsherr]

[inet[/10.18.6.90:9300]][discovery/zen/join/validate]; org.elasticsearch.ElasticsearchIllegalArgumentException: No custom index metadat

a factory registered for type [rivers]]

问题原因：都采用默认集群名字的话，不同人不同I配置发到集群会进行连接并选Master，有时候可能因为IP限制连接不上。
更改：自己的测试服务尽量个性命名。

专业画图11年，你值得拥有！画图运维最基本的技能，但是这手法的高低就取决于你的技巧和水平了！废话不多说，观看视频学习即可！

Crazysales是一家典型的跨境电商企业，以澳洲和英国作为主要目标市场，产品大多数由国内供应商提供。Crazysales不但是Amazon、eBay等大型电商平台上的大卖家，同时在澳洲、新西兰建设有自营电商网站，为广大用户提供完整的网购服务。 
 



由于涉及跨国网络部署，不可避免地需要穿过“万里长城”，因此应用架构相对普通电商网站更加复杂，管理成本也自然提升，如何能够及时了解分布在中国、澳洲、英国等地不同业务系统的运行状态，是运维部门最关心的工作。

跨境电商的典型IT架构

Crazysales的核心业务系统及网店系统均搭建在Amazon的AWS平台之上，用Amazon CloudFront进行前端内容分发，而后端的数据维护平台因为供应商在国内，所以也在国内。 系统架构如下图：



目前，我们应用的技术都不是“高大上”的新技术，但稳定性得到很好的保证： 1.传统的PHP＋LINUX＋MYSQL，辅助数据的统计和分析应用mongoDB , 搜索引擎基于Solr。 系统架构做到前后低耦合，前端网站强依赖数据库转变成弱依赖。 2.MYSQL部署了两台slave 和定时静态备份数据，确保数据库的异地备份，和读写分离，为以后的无限扩展搭好基础。 3.通过每个应用层的监控，及时发现系统的瓶颈，针对性地优化。 整套系统都是我们团队经过多年合作开发逐步建立和维护的，所以很难保证统一的代码风格和代码水平，那是可遇不可求的。因此，必须建立合理的监控体系及时发现项目管理的漏洞、测试的漏洞、线上的性能瓶颈，这都让运维的工作在整个系统生命周期里更重要，这也是时下运维开发工程师的工作核心。

跨境电商的最佳监控解决方案

因为使用了Amazon的云服务，所以我们运维工程师不必花费大量时间维护基础硬件设施，而有更多的时间和精力来研究和优化我们的业务系统，其中监控体系是令我们为之骄傲的一部分。 



我们的自建监控系统能够及时、准确的发现部署在AWS上和国内的各个业务系统的运行状况，但对于通过CloudFront分发出去的前端内容，以及主要分布于英国、澳大利亚、新西兰等不同国家的用户的访问体验，则是自建监控系统很难准确感知的。另外我们的开发和运维团队主要在国内，因此需要一款既能准确感知海外用户访问Crazysales网站情况，又能通过手机短信、微信等手段给国内技术团队提供准确告警消息的监控工具。经过多方测试，我们最终采用云智慧的监控宝网站监控和网页性能监控功能，负责网站从CDN到前端浏览器环节的可用性监控。  


 
各个层级设不同的监控点

红色部分使用监控宝的监控系统，绿色是监控宝和自建监控系统混合使用 这是我们目前实施的监控架构： 通过脚本／自建监控系统 ／ 外部监控点（模拟真实客户访问） 多种实时监控数据来监测业务系统的运作状态，根据不同系统的特性来调整数据采样的频率，多维度的监控和及时的告警信息让维护人员及时知道系统的运作情况，保障系统的正常运作和提高异常处理的及时性，最终实现故障出现前预防和故障出现后及时解决的效果。 例如，我们的内部监控系统发现数据库在凌晨4点会出现服务很忙，同时监控宝监控数据显示前台出现等待时间过长（>10s），通过和我们的后台任务调度系统的运行时间进行对比，发现一个JOB需要大量SQL查询，导致数据库CPU占用过多，因此及时调整SQL的查询指向其它Slave，同时优化该SQL。 如下图，马上就看到优化后的效果了：  



监控宝遍布全球的分布式监测点能够模拟真实客户访问，及时了解客户遇到的问题，避免IT团队无法取到第一手材料导致丢失重现系统故障的机会，这是我们设置外部监控点的原因。如果自己购买服务器和节点进行部署的话，维护成本很高，也不专业。监控宝基于SaaS的服务和收费模式，很好的解决了成本和维护的问题，帮助我们掌握在澳洲，英国，中国大陆等地的访问速度，可用性等数据。 监控宝模拟客户端在各个监测点的数据采样频率最高可达到5分钟每次，不但能在第一时间发现故障并给予告警，而且能帮助我们掌握Web页面的性能表现，让开发人员可以针对性进行页面优化。而监控宝在全球范围内不断地增加的监测点数量，也和我们公司不断拓展英语国家业务的发展思路不谋而合。 最后说一下告警方式，众所周知，告警是监控的最后一步，大部分监控平台使用的是邮件和短信告警，但现在最流行的社交应用是微信，也是我们现在用得最多和最及时的平台。因此，我们将多种收集数据的介质通过监控宝转化到微信进行提示，基本上能做到故障发生半分钟内运维同事作出反应。