elasticsearch（41）
1、使用minimum_should_match参数
elasticsearch query中的minimum_should_match ，字面意思就很清晰了，就是最小匹配度，但是它却有很多种配置方式。
正向匹配度比如 &minimum_should_match&:3 官方原文解释是：Indicates a fixed value regardless of the number of optional clauses.
这里要说明一下为什么是optional clauses（翻译为可选的子句），因为对于被analyzer分解出来的每一个term都会构造成一个should的bool query的查询,每个term变成一个term query子句。
例如&query&: &how not to be&，被解析成：
& &bool&: {
& & &should&: [
& & & { &term&: { &body&: &how&}},
& & & { &term&: { &body&: &not&}},
& & & { &term&: { &body&: &to&}},
& & & { &term&: { &body&: &be&}}
& & &minimum_should_match&: 3
（注：在bool query中minimum_should_match只能紧跟在should的后面，放其他地方会出异常）
或者 &minimum_should_match&:75%，可以配置一个一个百分比，至少optional clauses至少满足75%，这里是向下取整的。
比如有5个clause,5*75%=3.75,向下取整为3，也就是至少需要match 3个clause。
逆向匹配和正向匹配相反，比如我们可以近似理解为-25%和75%表示的是一个意思，但是有些小小的差异，比如有5个clause，逆向匹配-25%，5*25%=1.25，取整是1,5-1=4，即要匹配4个clause，而75%算出来是3个clause。
term(job,“”销售经理“”)结果可能会出现：促销员或者是4S店经理/维修站经理等
如果使用：QueryBuilders.matchQuery(job,“”销售经理“”).minimumShouldMatch(&90%&) &则不会出现。
因为销售经理经过分词会出现：
token: &销售&,
start_offset: 0,
end_offset: 2,
type: &CN_WORD&,
position: 0
token: &销&,
start_offset: 0,
end_offset: 1,
type: &CN_WORD&,
position: 1
token: &售&,
start_offset: 1,
end_offset: 2,
type: &CN_WORD&,
position: 2
token: &经理&,
start_offset: 2,
end_offset: 4,
type: &CN_WORD&,
position: 3
}配置了匹配度最少为90% 意味着召回的doc中至少有 4*0.9=3.6向下取整3个词条才可以。
2、使用短语查询
QueryBuilders.matchPhraseQuery(field, value).slop(2)
表示将value分词后中间允许存在两个分词结果的词条；如原句子是：
我是你们公司部门的经理
经过分词后：
token: &我&,
start_offset: 0,
end_offset: 1,
type: &CN_CHAR&,
position: 0
token: &你们&,
start_offset: 2,
end_offset: 4,
type: &CN_WORD&,
position: 1
token: &公司&,
start_offset: 4,
end_offset: 6,
type: &CN_WORD&,
position: 2
token: &部门&,
start_offset: 6,
end_offset: 8,
type: &CN_WORD&,
position: 3
token: &经理&,
start_offset: 9,
end_offset: 11,
type: &CN_WORD&,
position: 4
}QueryBuilders.matchPhraseQuery(field, &我是经理&).slop(2)
那么查不到，因为‘我是经理’分词后是我 & 经理；在这两个中间最多允许2个分词的词条。但是我是你们‘’我是你们公司部门的经理&在我 & 经理中间有3个词条，索引搜索不到。
QueryBuilders.matchPhraseQuery(field, &我是经理&).slop(3)或者大于3也可以。
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：204786次
积分：4018
积分：4018
排名：第18617名
原创：158篇
转载：284篇
评论：16条
(9)(7)(7)(10)(27)(13)(7)(11)(4)(8)(6)(3)(2)(1)(8)(6)(17)(41)(11)(15)(6)(11)(12)(19)(20)(11)(22)(7)(1)(43)(37)(24)(1)(2)(1)(1)(1)(5)(4)(1)分布式搜索elasticsearch集群监控工具bigdesk　　bigdesk是elasticsearch的一个集群监控工具，可以通过它来查看es集群的各种状态，如：cpu、内存使用情况，索引数据、搜索情况，http连接数等。项目git地址：&。和head一样，它也是个独立的网页程序，使用方式和head一样。
　　插件安装运行：
　　1.bin/plugin&-install&lukas-vlcek/bigdesk
　　3.打开http://localhost:9200/_plugin/bigdesk/&
　　当然，也可以直接下载源码运行index.html
　　同样是输入ip地址和端口后连接，界面如下。加星的表示主节点。
　　下面介绍下各个图表。
　　系统监控：
　　这里包含系统方面的一些状态，左起分别为：cpu，内存，交换区和平均负载的情况
　　显示jvm的一些状态，左起分别为：jvm heap内存使用情况，蓝色的为已使用内存；非heap使用内存；线程数；gc情况（次数和时间）；
　　进程：
　　下面四张图主要显示es的进程对系统资源的使用情况，左起分别为：进程打开文件数，内存使用情况，cpu时间和进程的cpu使用率
　　内存使用情况中的
　　Total virtual指linux下虚拟内存，它包括virtual memory map中的所有数据量之和。包括：程序类+程序数据+jar包空间+jre占用空间等。
　　resident memory指程序实际占用的物理内存。
　　通讯：
　　这里可以查看tcp和http链接的一些数据。
　　索引：
　　这里可以查看索引数据和搜索的一些情况。
　　左上起：每秒索引请求，搜索时间，每秒取数据请求，取数据时间。
　　左下起：缓存大小，缓存失效个数，每秒索引请求，索引时间。
　　文件系统：
　　显示硬盘的读写情况
　　本文地址：版权印作品库
用ElasticSearch监控MySQL
发布日期：
题图版权申明：此文章首发于公众号程序员在深圳，搜索 studycode 即可关注本文无需授权即可转载，转载时请务必注明作者介绍本文是一个使用ELK来监控mysql的介绍，基本监控了一些关键指标，当然根据业务的不同，可能有不同的指标需求，但使用该方法监控，原理不会变化，非常适合入门。ELK是一个非常强大的软件组合，在github上有开源，star数大的惊人，感兴趣的朋友可以了解下，这套工具学习曲线比较陡峭，推荐使用本文提到的mysqlbeat这类简单的工具作为采集工具开始，一开始先不使用官方提供的beat，一方面是因为默认的配置什么数据都上报，浪费存储空间，另一方面复杂的嵌套表结构（document）更增加了学习难度，更具体的原因后面还会提及。而本文涉及到的表结构（document）只有一层，说不定你输入一个key:value，例如INNODB_PAGE_SIZE:16384，就把pagesize为16KB的记录全部列出来了。但这并不意味着你不会掉到坑里去，学好这套工具还是需要大量的学习和摸索，其实ELK的难点在于ES，建议可以读一下它的原版教程ElasticSearch权威指南。监控工具mysqlbeatmysqlbeat是一个高度可定制的mysql监控agent，通过查询information_schema.global_status中部分字段，并上报到
不允许编辑作品内容
非专有使用
授权价格：
允许编辑作品内容
非专有使用
授权价格：
作品认证详情
其他版权作品
发布时间：
发布时间：
发布时间：
发布时间：
发布时间：
版权印活动专区
版权印推荐作品
本作品系本权利人的原创作品，本权利人对本作品享有完整的著作权，任何个人或单位未经许可不得进行任何使用。使用者可以通过版权印平台获取授权在互联网环境下对本作品进行转载使用或素材使用。使用者必须按照授权说明中规定的使用方式使用作品。未获取授权或未按照规定的使用方式使用作品的，都属于侵权行为，将承担相应法律责任。用Elasticsearch+Redis构建投诉监控系统，看Airbnb如何保证用户持续增长
如今，我们如何了解到用户日益增长的新问题？
对特定某个人来说，这个问题似乎很好回答——对于每家公司来说，都是明确易答的问题。但实际上，我们发现这个问题没那么简单。
当然，我们的数据库存储有用户问题的数据，但对于上述问题，我们也没有很好的答案。我们缺乏有效的方法来总结问题的趋势，也没有能力实时监控问题。大多情况下，当我们发现趋势出现时，想要解决就已经太迟了。考虑到这种情况，我们开始设计相应的解决方案。
相关的一点背景：从Airbnb开站以来，我们已经接待了800亿名访客，用户量增长十分迅猛。随之，我们的工程师团队一直在寻求解决之道，以应对具有挑战性的新问题。
在Airbnb的实际运营中，有很大一部分来自房东与房客们的问题要靠客服人员来处理。挑战之一在于：了解我们数量巨大的表单，并找出其中的趋势或者实时探测到不希望出现的问题。我们需要一种监控方式，当特定问题频繁出现时提醒并警告我们。
我们所构建的：
我们构建了一个基于web的服务，可以根据用户提交的表单来计算趋势，并可将指定时间内的主要趋势可视化。包含表单的一些不同属性，比如问题类型、浏览器版本、用户国家、标题、来源等等。有了这些数据，我们就能分析一定时间内所有表单的各项属性，并通过算法排序，以找出其峰值或趋势。实际上，我们同时运行着两种不同的算法，以便在优化的同时仍保留之前的基准，以便进行比对。
需要我们将其划分为一些不同的部分，首先是存储表单的数据存储模块，负责存储并在数据处理时也可以快速查询。我们使用了Elasticsearch来负责这个部分。然后，我们还需要运行负责接受新表单数据请求的web服务，这里我们使用了Node.js应用来处理新的表单。
此外，我们还运行着一个单独的任务实例，能够持续计算表单趋势。它可以负责查询表单数据的Elasticsearch实例，并将结果存储到Redis实例中。Redis中存有表单趋势结果的缓存，以便Node.js在web中进行渲染。整个前端都构建于React之上，因此想要开发丰富的UI来展示数据就非常简单了。
我们决定按照表单创建的方式，以流数据的形式将其实时录入Elasticsearch的集群中。之后通过定期运行的批处理操作来处理这些数据，计算表单的趋势。将这些表单存储在Elasticsearch中使得扩展与执行数据组相关的聚集查询都非常简单。根据所存储数据的类型，对表单字段进行索引。
任务worker
我们的任务worker是负责查询存储数据，并及结算各个表单组的趋势分数的。我们使用了单独的实例，用web worker来执行这项任务，因为我们不希望处理的时间太长，而导致负责新表单数据请求录入的API出现延迟。之后，结果趋势数据会被发送给Redis，另一个web实例会拿取相应数据。
如何找出趋势
探测趋势是所有这些工作的核心。我们先是在Elasticsearch中运行multi-search查询，得出一定时间内的表单，所有表单附有各项所需的表单属性，然后使用这些属性来总结趋势。之后将评分模型运用于所有的时间序列，将结果归类并返回所有高于最小阈值的趋势属性。这些结果就成为了相应时间段的趋势。
评分模型的任务就是按周期进行调整，删除干扰项，让图谱曲线更加平滑，然后确定该曲线中是否存在波峰。为了对周期趋势进行平滑和调整，我们通过傅里叶变换（Fourier transform）将图谱转化为频率范围，找出频率峰值，只留接近的频率，删除其它所有。这样调整之后的曲线，就是我们的表单在某个周期之内的统计呈现。在修剪过原始图谱之后，我们就能得出现有图谱与预计数值的差异。根据最终调整完成的图谱，依据其中的一些因素，比如最大改变值与某段时间内的总表单数量，得出最终分值。
当计算出每小时各个表单字段的得分后，我们会将存储中得分较高的那些存入Redis，供前端使用。
一旦我们计算得出的数据被存入Redis，显示起来就很快了。我们添加了相应功能，比如查看过去某段时间内的趋势，以及较长一段时间内最热门的项目。
自从发布以来，我们的面板对快速探测问题起了很大作用，例如：我们发现了一个峰值——用户纷纷报告在搜索时看不到结果。刚开始使用的新用户通常都会遇到这类问题，因此客户人员并未太过关注。此外，由于并不是完全没有结果返回，这种问题更经常出现在微妙的边界情况下，因此工程师团队没有立刻发现这是个问题。但是，由于我们探测到了表单波峰，因此很确定有问题出现，需要修复。我们的工程师们很快修复了这个问题，过了没多久表单提交数量就出现回落，让我们确信问题已经修复。没有这个面板的话，这个问题可能会持续数日甚至数周，造成客服的高负荷以及用户的不满。
在Airbnb，这个面板我们已经用了有半年多，还找出了一些很难发觉的问题。我们捕捉到了多个波峰，包括一些很小的bug，也包括一些可能会发展成大问题的小问题。这个表单面板并未取代现有的宕机与系统错误监控系统，而是用于解决各类问题。
事实证明，这个新的表单监控系统在我们看来，是每个大型公司都应当拥有的无价之宝。通过将影响最大的问题曝露出来，获得及时修复而减少了用户的问题。我们预计，该表单面板能够减少表单总量的3%。
该项目是Airbnb的一个hackathon项目演化成的系统。有时候看到一个由两人写就的编程马拉松（hackathon）项目最终为Airbnb的用户节省了大量的时间，并让一切步上正轨可真是疯狂。
原文：/airbnb-engineering/how-airbnb-manages-to-monitor-customer-issues-at-scale-b1#.pikn6t8bk
译者：孙薇 微博@Verawala
天猫互动创意大赛，互动技术形式不限，专业评审团点评，丰厚奖金诱惑，获奖团队可获得完整商业方案支持，成为天猫长期合作伙伴。点击“阅读原文”报名！
大数据杂谈
ID：BigdataTina2016
▲长按二维码识别关注
专注大数据和机器学习，
分享前沿技术，交流深度思考。
欢迎加入社区！
责任编辑：
声明：本文由入驻搜狐公众平台的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。nginx与Elasticsearch结合使用 – 运维生存时间
你可能喜欢
有回复时邮件通知我
12345678910
12345678910
关于本站 本站以分享运维技术为主，欢迎大家参与技术分享，同时也欢迎大家吐槽，本站提供以下交流圈：QQ群①：*****（满）QQ群②：6690706 QQ群③： QQ群④：（新） 微信公众号：ttlsacom 商务合作QQ：
记住我的登录信息
点击“立即注册”转到用户注册页面。
输入用户名或电子邮箱地址，您会收到一封新密码链接的电子邮件。
用户名或电子邮件地址