packetbeat的oracle协议扩展
oracle由于是商用软件,协议并不公开,而且相比mysql等开源数据库软件,协议复杂度加了不止一个量级。
出于版权考虑,packetbeat并没有加入oracle协议的支持,只能自己动手。
好在beats充分考虑了扩展性,把公共的基础工作抽象成框架,新协议的扩展只需要专注于协议的分析和解码。
tns协议是oracle客户端和服务端通信协议,应用可以通过OCI、JDBC等接口去访问数据库。
tns协议有多个版本,不同版本之间差异也比较大,11g是主流tns版本为314。
目前完成308、310、313、314、315版本的解析
packetbeat支持pcap、pf_ring等抓包方式,通过kafka+es+kibana展示,效果如图
继续阅读 »
出于版权考虑,packetbeat并没有加入oracle协议的支持,只能自己动手。
好在beats充分考虑了扩展性,把公共的基础工作抽象成框架,新协议的扩展只需要专注于协议的分析和解码。
tns协议是oracle客户端和服务端通信协议,应用可以通过OCI、JDBC等接口去访问数据库。
tns协议有多个版本,不同版本之间差异也比较大,11g是主流tns版本为314。
目前完成308、310、313、314、315版本的解析
packetbeat支持pcap、pf_ring等抓包方式,通过kafka+es+kibana展示,效果如图
oracle由于是商用软件,协议并不公开,而且相比mysql等开源数据库软件,协议复杂度加了不止一个量级。
出于版权考虑,packetbeat并没有加入oracle协议的支持,只能自己动手。
好在beats充分考虑了扩展性,把公共的基础工作抽象成框架,新协议的扩展只需要专注于协议的分析和解码。
tns协议是oracle客户端和服务端通信协议,应用可以通过OCI、JDBC等接口去访问数据库。
tns协议有多个版本,不同版本之间差异也比较大,11g是主流tns版本为314。
目前完成308、310、313、314、315版本的解析
packetbeat支持pcap、pf_ring等抓包方式,通过kafka+es+kibana展示,效果如图
收起阅读 »
出于版权考虑,packetbeat并没有加入oracle协议的支持,只能自己动手。
好在beats充分考虑了扩展性,把公共的基础工作抽象成框架,新协议的扩展只需要专注于协议的分析和解码。
tns协议是oracle客户端和服务端通信协议,应用可以通过OCI、JDBC等接口去访问数据库。
tns协议有多个版本,不同版本之间差异也比较大,11g是主流tns版本为314。
目前完成308、310、313、314、315版本的解析
packetbeat支持pcap、pf_ring等抓包方式,通过kafka+es+kibana展示,效果如图
收起阅读 »
ggg 发表于 : 2017-05-10 15:01
评论 (40)
【线下活动】2017-05-21 Elastic Meetup 北京站日程安排
主办:Elastic 中文社区
协办:HULU 北京研发中心
时间:2017-05-21 13:30PM-18:00PM
地点:北京市朝阳区望京大科技园浦项中心b座21楼 hulu
分享主题:
个人介绍:倪顺,Hulu软件工程师,ELK粉。主要负责用户播放日志数据的收集,处理和可视化,以及服务监控。
主题:Elasticsearch 和 Kibana 在 Hulu视频的应用实践
内容介绍:Elasticsearch作为优秀的开源工具,很早就在Hulu内部使用。Hulu是一家视频公司,我们在用Elastic stack优化视频播放体验。本次分享中,主要包括:1)Kibana可视化视频播放日志数据;2)Elastic Stack使用的经验tips。
个人介绍:黄鑫,运维开发工程师,Pythonista,在监控和部署领域耕耘多年,一年前接触了 ELK。
主题:ELK CI/CD 部署实践
内容介绍:
使用 SaltStack 对 ELK 维护。配置管理,持续集成和持续部署的设计和实施。日常运维管理。
- 背景介绍
- 可用性设计
- 配置管理和持续集成
- 持续部署
- 发现的问题和未来展望
个人介绍:罗喆,最早加入快手的视频技术工程师,负责移动直播系统的构建和调优,并且搭建了基于大数据的质量监测系统,之前曾在腾讯从事实时视音频传输优化工作。
主题:Elastic Stack驱动的直播体验优化
内容介绍:
移动端视频直播业务经过2016年的井喷期,已经进入下半场,大家的关注点已经从如何构建完善的直播平台的粗放增长阶段,转入精细化运营阶段。如何在巨大的流量、复杂的应用场景、复杂的网络条件下,持续优化用户体验,是我们亟待回答的问题。构建大数据驱动的直播优化体系是快手为应对这一难题所提出的解决方案。
为此,我们基于完善的Elastic Stack建立了流媒体大数据分析和可视化平台。一切优化均围绕着数据进行:找到用户痛点,指导优化方向,评估优化效果,走出了一条行之有效的数据驱动之路。
演讲提纲:
1. 快手直播的业务背景,移动直播体验优化的方法论
2. Elastic Stack系统构建历程和真实优化案例
继续阅读 »
协办:HULU 北京研发中心
时间:2017-05-21 13:30PM-18:00PM
地点:北京市朝阳区望京大科技园浦项中心b座21楼 hulu
分享主题:
个人介绍:倪顺,Hulu软件工程师,ELK粉。主要负责用户播放日志数据的收集,处理和可视化,以及服务监控。
主题:Elasticsearch 和 Kibana 在 Hulu视频的应用实践
内容介绍:Elasticsearch作为优秀的开源工具,很早就在Hulu内部使用。Hulu是一家视频公司,我们在用Elastic stack优化视频播放体验。本次分享中,主要包括:1)Kibana可视化视频播放日志数据;2)Elastic Stack使用的经验tips。
个人介绍:黄鑫,运维开发工程师,Pythonista,在监控和部署领域耕耘多年,一年前接触了 ELK。
主题:ELK CI/CD 部署实践
内容介绍:
使用 SaltStack 对 ELK 维护。配置管理,持续集成和持续部署的设计和实施。日常运维管理。
- 背景介绍
- 可用性设计
- 配置管理和持续集成
- 持续部署
- 发现的问题和未来展望
个人介绍:罗喆,最早加入快手的视频技术工程师,负责移动直播系统的构建和调优,并且搭建了基于大数据的质量监测系统,之前曾在腾讯从事实时视音频传输优化工作。
主题:Elastic Stack驱动的直播体验优化
内容介绍:
移动端视频直播业务经过2016年的井喷期,已经进入下半场,大家的关注点已经从如何构建完善的直播平台的粗放增长阶段,转入精细化运营阶段。如何在巨大的流量、复杂的应用场景、复杂的网络条件下,持续优化用户体验,是我们亟待回答的问题。构建大数据驱动的直播优化体系是快手为应对这一难题所提出的解决方案。
为此,我们基于完善的Elastic Stack建立了流媒体大数据分析和可视化平台。一切优化均围绕着数据进行:找到用户痛点,指导优化方向,评估优化效果,走出了一条行之有效的数据驱动之路。
演讲提纲:
1. 快手直播的业务背景,移动直播体验优化的方法论
2. Elastic Stack系统构建历程和真实优化案例
主办:Elastic 中文社区
协办:HULU 北京研发中心
时间:2017-05-21 13:30PM-18:00PM
地点:北京市朝阳区望京大科技园浦项中心b座21楼 hulu
分享主题:
个人介绍:倪顺,Hulu软件工程师,ELK粉。主要负责用户播放日志数据的收集,处理和可视化,以及服务监控。
主题:Elasticsearch 和 Kibana 在 Hulu视频的应用实践
内容介绍:Elasticsearch作为优秀的开源工具,很早就在Hulu内部使用。Hulu是一家视频公司,我们在用Elastic stack优化视频播放体验。本次分享中,主要包括:1)Kibana可视化视频播放日志数据;2)Elastic Stack使用的经验tips。
个人介绍:黄鑫,运维开发工程师,Pythonista,在监控和部署领域耕耘多年,一年前接触了 ELK。
主题:ELK CI/CD 部署实践
内容介绍:
使用 SaltStack 对 ELK 维护。配置管理,持续集成和持续部署的设计和实施。日常运维管理。
- 背景介绍
- 可用性设计
- 配置管理和持续集成
- 持续部署
- 发现的问题和未来展望
个人介绍:罗喆,最早加入快手的视频技术工程师,负责移动直播系统的构建和调优,并且搭建了基于大数据的质量监测系统,之前曾在腾讯从事实时视音频传输优化工作。
主题:Elastic Stack驱动的直播体验优化
内容介绍:
移动端视频直播业务经过2016年的井喷期,已经进入下半场,大家的关注点已经从如何构建完善的直播平台的粗放增长阶段,转入精细化运营阶段。如何在巨大的流量、复杂的应用场景、复杂的网络条件下,持续优化用户体验,是我们亟待回答的问题。构建大数据驱动的直播优化体系是快手为应对这一难题所提出的解决方案。
为此,我们基于完善的Elastic Stack建立了流媒体大数据分析和可视化平台。一切优化均围绕着数据进行:找到用户痛点,指导优化方向,评估优化效果,走出了一条行之有效的数据驱动之路。
演讲提纲:
1. 快手直播的业务背景,移动直播体验优化的方法论
2. Elastic Stack系统构建历程和真实优化案例 收起阅读 »
协办:HULU 北京研发中心
时间:2017-05-21 13:30PM-18:00PM
地点:北京市朝阳区望京大科技园浦项中心b座21楼 hulu
分享主题:
个人介绍:倪顺,Hulu软件工程师,ELK粉。主要负责用户播放日志数据的收集,处理和可视化,以及服务监控。
主题:Elasticsearch 和 Kibana 在 Hulu视频的应用实践
内容介绍:Elasticsearch作为优秀的开源工具,很早就在Hulu内部使用。Hulu是一家视频公司,我们在用Elastic stack优化视频播放体验。本次分享中,主要包括:1)Kibana可视化视频播放日志数据;2)Elastic Stack使用的经验tips。
个人介绍:黄鑫,运维开发工程师,Pythonista,在监控和部署领域耕耘多年,一年前接触了 ELK。
主题:ELK CI/CD 部署实践
内容介绍:
使用 SaltStack 对 ELK 维护。配置管理,持续集成和持续部署的设计和实施。日常运维管理。
- 背景介绍
- 可用性设计
- 配置管理和持续集成
- 持续部署
- 发现的问题和未来展望
个人介绍:罗喆,最早加入快手的视频技术工程师,负责移动直播系统的构建和调优,并且搭建了基于大数据的质量监测系统,之前曾在腾讯从事实时视音频传输优化工作。
主题:Elastic Stack驱动的直播体验优化
内容介绍:
移动端视频直播业务经过2016年的井喷期,已经进入下半场,大家的关注点已经从如何构建完善的直播平台的粗放增长阶段,转入精细化运营阶段。如何在巨大的流量、复杂的应用场景、复杂的网络条件下,持续优化用户体验,是我们亟待回答的问题。构建大数据驱动的直播优化体系是快手为应对这一难题所提出的解决方案。
为此,我们基于完善的Elastic Stack建立了流媒体大数据分析和可视化平台。一切优化均围绕着数据进行:找到用户痛点,指导优化方向,评估优化效果,走出了一条行之有效的数据驱动之路。
演讲提纲:
1. 快手直播的业务背景,移动直播体验优化的方法论
2. Elastic Stack系统构建历程和真实优化案例 收起阅读 »
【线下活动】2017-06-10南京Elastic Meetup日程安排
1. 主办方
Elastic中文社区 趋势科技
2. 时间地点
活动时间:2017年6月10日 13:30 - 18:00
活动地点:雨花区软件大道48号苏豪国际广场B座 趋势科技中国研发中心(靠花神庙地铁站)
3. 主题
分享一:The State of Elastic Stack
演讲者简介:
曾勇(Medcl) Elastic工程师与布道师
Elasticsearch爱好者,2015年加入Elastic,Elastic 中文社区的发起人,Elastic在中国的首位员工。
主题简介:
Elastic Stack是Elastic公司的开源产品:Elasticsearch、Logstash、Kibana和Beats的统称,这些产品发布速度貌似有点快,在最近已经发布了的版本中有哪些值得关注的特性,然后Elastic的工程师手头上又在忙着码哪些新的特性呢?
机器学习、AI目前非常火,Elastic在最近的5.0也发布了一个机器学习的模块,这次也会带来demo演示。
分享二: Elastic Stack的容器化使用与Alert
演讲者简介:
瞿盛熙 嘀哒物流科技有限公司运维组组长
主题简介:
介绍嘀哒物流在公有云上的Elastic Stack部署以及日志分析与监控
1.目的和环境
2.部署:自动化,容器化下kubernetes与single mode的考量
3.日志分析与alert
4.监控:prometheus与docker
分享三:Elasticsearch辅助的智能客服机器人
演讲者简介:
杨文俊 趋势科技个人消费者部机器学习工程师
从2013年开始投入大数据处理与机器学习,目前依托Elasticsearch的搜索能力构建了一系列的智能服务。
主题简介:
1. 将原始的日文记录导入Elasticsearch之中
2. 使用Elasticsearch对原始内容进行初次过滤
3. 在过滤的基础之上,调用wmd + word2vec进行rerank,并综合进行判定
分享四: Elastic在华为电信软件运维中的应用简介
演讲者简介:
肖曙旭 华为电信软件业务云运维开发部软件工程师
华为日志服务特性负责人。从2015年起开始接触Elasticsearch并使用至今。先后负责服务调用链和日志服务特性的设计和开发,依托Elasticsearch实现搜索相关能力。
主题简介:
1. 日志采集代理。提供按正则表达式匹配或者分隔符的逻辑行分割方式;支持逻辑行内按分隔符提取字段,或者按正则表达式提取字段;支持一些简易算子对字段进行处理。
2. 日志汇聚。不同的日志类型通过不同的Topic区分
3. 流式处理。日志数据二次处理,或者一些实时分析的逻辑处理。
4. 参考kibana开发搜索和可视化能力,同时支持关键词告警,环比告警等告警能力,以及整个日志服务通道的自身监控能力。
分享五:基于ES的SQL报警引擎
演讲者简介:
张立丹 南京云利来软件科技有限公司
2010年参加工作,工作内容包括:Windows音频驱动及声卡固件;Linux高并发服务器;数据采集及分析。自2015年开始接触Elasticsearch,在工作中使用ES进行网络数据(TCP/HTTP/DNS等)的安全分析。
主题简介:
1. SQL:将ES的DSL抽象成 SQL
2. RDL:规则描述语言
3. 报警规则
继续阅读 »
Elastic中文社区 趋势科技
2. 时间地点
活动时间:2017年6月10日 13:30 - 18:00
活动地点:雨花区软件大道48号苏豪国际广场B座 趋势科技中国研发中心(靠花神庙地铁站)
3. 主题
分享一:The State of Elastic Stack
演讲者简介:
曾勇(Medcl) Elastic工程师与布道师
Elasticsearch爱好者,2015年加入Elastic,Elastic 中文社区的发起人,Elastic在中国的首位员工。
主题简介:
Elastic Stack是Elastic公司的开源产品:Elasticsearch、Logstash、Kibana和Beats的统称,这些产品发布速度貌似有点快,在最近已经发布了的版本中有哪些值得关注的特性,然后Elastic的工程师手头上又在忙着码哪些新的特性呢?
机器学习、AI目前非常火,Elastic在最近的5.0也发布了一个机器学习的模块,这次也会带来demo演示。
分享二: Elastic Stack的容器化使用与Alert
演讲者简介:
瞿盛熙 嘀哒物流科技有限公司运维组组长
主题简介:
介绍嘀哒物流在公有云上的Elastic Stack部署以及日志分析与监控
1.目的和环境
2.部署:自动化,容器化下kubernetes与single mode的考量
3.日志分析与alert
4.监控:prometheus与docker
分享三:Elasticsearch辅助的智能客服机器人
演讲者简介:
杨文俊 趋势科技个人消费者部机器学习工程师
从2013年开始投入大数据处理与机器学习,目前依托Elasticsearch的搜索能力构建了一系列的智能服务。
主题简介:
1. 将原始的日文记录导入Elasticsearch之中
2. 使用Elasticsearch对原始内容进行初次过滤
3. 在过滤的基础之上,调用wmd + word2vec进行rerank,并综合进行判定
分享四: Elastic在华为电信软件运维中的应用简介
演讲者简介:
肖曙旭 华为电信软件业务云运维开发部软件工程师
华为日志服务特性负责人。从2015年起开始接触Elasticsearch并使用至今。先后负责服务调用链和日志服务特性的设计和开发,依托Elasticsearch实现搜索相关能力。
主题简介:
1. 日志采集代理。提供按正则表达式匹配或者分隔符的逻辑行分割方式;支持逻辑行内按分隔符提取字段,或者按正则表达式提取字段;支持一些简易算子对字段进行处理。
2. 日志汇聚。不同的日志类型通过不同的Topic区分
3. 流式处理。日志数据二次处理,或者一些实时分析的逻辑处理。
4. 参考kibana开发搜索和可视化能力,同时支持关键词告警,环比告警等告警能力,以及整个日志服务通道的自身监控能力。
分享五:基于ES的SQL报警引擎
演讲者简介:
张立丹 南京云利来软件科技有限公司
2010年参加工作,工作内容包括:Windows音频驱动及声卡固件;Linux高并发服务器;数据采集及分析。自2015年开始接触Elasticsearch,在工作中使用ES进行网络数据(TCP/HTTP/DNS等)的安全分析。
主题简介:
1. SQL:将ES的DSL抽象成 SQL
2. RDL:规则描述语言
3. 报警规则
1. 主办方
Elastic中文社区 趋势科技
2. 时间地点
活动时间:2017年6月10日 13:30 - 18:00
活动地点:雨花区软件大道48号苏豪国际广场B座 趋势科技中国研发中心(靠花神庙地铁站)
3. 主题
分享一:The State of Elastic Stack
演讲者简介:
曾勇(Medcl) Elastic工程师与布道师
Elasticsearch爱好者,2015年加入Elastic,Elastic 中文社区的发起人,Elastic在中国的首位员工。
主题简介:
Elastic Stack是Elastic公司的开源产品:Elasticsearch、Logstash、Kibana和Beats的统称,这些产品发布速度貌似有点快,在最近已经发布了的版本中有哪些值得关注的特性,然后Elastic的工程师手头上又在忙着码哪些新的特性呢?
机器学习、AI目前非常火,Elastic在最近的5.0也发布了一个机器学习的模块,这次也会带来demo演示。
分享二: Elastic Stack的容器化使用与Alert
演讲者简介:
瞿盛熙 嘀哒物流科技有限公司运维组组长
主题简介:
介绍嘀哒物流在公有云上的Elastic Stack部署以及日志分析与监控
1.目的和环境
2.部署:自动化,容器化下kubernetes与single mode的考量
3.日志分析与alert
4.监控:prometheus与docker
分享三:Elasticsearch辅助的智能客服机器人
演讲者简介:
杨文俊 趋势科技个人消费者部机器学习工程师
从2013年开始投入大数据处理与机器学习,目前依托Elasticsearch的搜索能力构建了一系列的智能服务。
主题简介:
1. 将原始的日文记录导入Elasticsearch之中
2. 使用Elasticsearch对原始内容进行初次过滤
3. 在过滤的基础之上,调用wmd + word2vec进行rerank,并综合进行判定
分享四: Elastic在华为电信软件运维中的应用简介
演讲者简介:
肖曙旭 华为电信软件业务云运维开发部软件工程师
华为日志服务特性负责人。从2015年起开始接触Elasticsearch并使用至今。先后负责服务调用链和日志服务特性的设计和开发,依托Elasticsearch实现搜索相关能力。
主题简介:
1. 日志采集代理。提供按正则表达式匹配或者分隔符的逻辑行分割方式;支持逻辑行内按分隔符提取字段,或者按正则表达式提取字段;支持一些简易算子对字段进行处理。
2. 日志汇聚。不同的日志类型通过不同的Topic区分
3. 流式处理。日志数据二次处理,或者一些实时分析的逻辑处理。
4. 参考kibana开发搜索和可视化能力,同时支持关键词告警,环比告警等告警能力,以及整个日志服务通道的自身监控能力。
分享五:基于ES的SQL报警引擎
演讲者简介:
张立丹 南京云利来软件科技有限公司
2010年参加工作,工作内容包括:Windows音频驱动及声卡固件;Linux高并发服务器;数据采集及分析。自2015年开始接触Elasticsearch,在工作中使用ES进行网络数据(TCP/HTTP/DNS等)的安全分析。
主题简介:
1. SQL:将ES的DSL抽象成 SQL
2. RDL:规则描述语言
3. 报警规则 收起阅读 »
Elastic中文社区 趋势科技
2. 时间地点
活动时间:2017年6月10日 13:30 - 18:00
活动地点:雨花区软件大道48号苏豪国际广场B座 趋势科技中国研发中心(靠花神庙地铁站)
3. 主题
分享一:The State of Elastic Stack
演讲者简介:
曾勇(Medcl) Elastic工程师与布道师
Elasticsearch爱好者,2015年加入Elastic,Elastic 中文社区的发起人,Elastic在中国的首位员工。
主题简介:
Elastic Stack是Elastic公司的开源产品:Elasticsearch、Logstash、Kibana和Beats的统称,这些产品发布速度貌似有点快,在最近已经发布了的版本中有哪些值得关注的特性,然后Elastic的工程师手头上又在忙着码哪些新的特性呢?
机器学习、AI目前非常火,Elastic在最近的5.0也发布了一个机器学习的模块,这次也会带来demo演示。
分享二: Elastic Stack的容器化使用与Alert
演讲者简介:
瞿盛熙 嘀哒物流科技有限公司运维组组长
主题简介:
介绍嘀哒物流在公有云上的Elastic Stack部署以及日志分析与监控
1.目的和环境
2.部署:自动化,容器化下kubernetes与single mode的考量
3.日志分析与alert
4.监控:prometheus与docker
分享三:Elasticsearch辅助的智能客服机器人
演讲者简介:
杨文俊 趋势科技个人消费者部机器学习工程师
从2013年开始投入大数据处理与机器学习,目前依托Elasticsearch的搜索能力构建了一系列的智能服务。
主题简介:
1. 将原始的日文记录导入Elasticsearch之中
2. 使用Elasticsearch对原始内容进行初次过滤
3. 在过滤的基础之上,调用wmd + word2vec进行rerank,并综合进行判定
分享四: Elastic在华为电信软件运维中的应用简介
演讲者简介:
肖曙旭 华为电信软件业务云运维开发部软件工程师
华为日志服务特性负责人。从2015年起开始接触Elasticsearch并使用至今。先后负责服务调用链和日志服务特性的设计和开发,依托Elasticsearch实现搜索相关能力。
主题简介:
1. 日志采集代理。提供按正则表达式匹配或者分隔符的逻辑行分割方式;支持逻辑行内按分隔符提取字段,或者按正则表达式提取字段;支持一些简易算子对字段进行处理。
2. 日志汇聚。不同的日志类型通过不同的Topic区分
3. 流式处理。日志数据二次处理,或者一些实时分析的逻辑处理。
4. 参考kibana开发搜索和可视化能力,同时支持关键词告警,环比告警等告警能力,以及整个日志服务通道的自身监控能力。
分享五:基于ES的SQL报警引擎
演讲者简介:
张立丹 南京云利来软件科技有限公司
2010年参加工作,工作内容包括:Windows音频驱动及声卡固件;Linux高并发服务器;数据采集及分析。自2015年开始接触Elasticsearch,在工作中使用ES进行网络数据(TCP/HTTP/DNS等)的安全分析。
主题简介:
1. SQL:将ES的DSL抽象成 SQL
2. RDL:规则描述语言
3. 报警规则 收起阅读 »
[线下活动] 2017-05-14 Elastic Meetup 上海日程
主办:Elastic 中文社区
协办:众安保险
时间:2017-05-14 13:30PM-18:00PM
地点:上海市虹口区四川北路859号中信广场42楼
PPT 下载:https://pan.baidu.com/s/1eS157 ... %252F
分享主题:
个人介绍:杨智健, 众安保险搜索组负责人。
主题:es在众安保险的实践
内容介绍: es在众安保险业务线和日志类的实践,和相关平台化建设。
录像:https://v.qq.com/x/page/x0509wkr513.html
个人介绍:Medcl, Elastic工程师与布道师,2015年加入Elastic公司, Elastic中文社区的发起人。
主题:ElasticStack 5.x 最新进展
内容介绍:ElasticStack 5.x 新增了很多新的激动人心的特性,本次分享将为大家一一解读。
录像:https://v.qq.com/x/page/m0509dt9f80.html
个人介绍:魏彬, rockybean,穿衣助手技术负责人,Elastic Stack 粉丝。
主题:用 Elastic Stack 来诊断下你的redis slowlog
内容介绍:
1. Elastic Stack 之 ElasticSearch Beats Kibana 简介
2. redis 和 slowlog 简介
3. 实现原理介绍
4. Kibana图形化结果展示介绍
5. 代码解析
6. 开源过程中的几点心得分享
录像:https://v.qq.com/x/page/m0509j6kyzj.html
个人介绍: 柯诗豪,携程旅行网高级软件工程师。
主题:基于Docker的ES PaaS云平台
内容介绍:伴随着公司越来越多的团队开始使用ES,部署和管理ES集群成本增加。所以建立了基于Docker通过Mesos提供的资源管理机制的ES PaaS平台,用户可以在平台上快捷的创建、配置和管理ES集群。
录像:https://v.qq.com/x/page/n0509pzjgxq.html
个人介绍: 彭科,13年从武汉理工毕业 ,16年进入斗鱼大数据基础架构组,主要负责日志监控平台和一些大数据技术的预研。目前已经从斗鱼离职,接下来会去一家云计算创业公司,从事大数据产品研发和AI方向研究。
主题:基于Elastic Stack+Kafka的日志监控平台架构演进
内容介绍:基于在斗鱼的工作经验,基于Elastic Stack和kafka做TB级日志监控平台搭建,架构演讲,踩过哪些坑,如何调优,与大数据组件技术对比,如何结合使用,如何监控基础组件与业务,分享一些自己的心得。
录像:https://v.qq.com/x/page/m05099qj8f9.html
继续阅读 »
协办:众安保险
时间:2017-05-14 13:30PM-18:00PM
地点:上海市虹口区四川北路859号中信广场42楼
PPT 下载:https://pan.baidu.com/s/1eS157 ... %252F
分享主题:
个人介绍:杨智健, 众安保险搜索组负责人。
主题:es在众安保险的实践
内容介绍: es在众安保险业务线和日志类的实践,和相关平台化建设。
录像:https://v.qq.com/x/page/x0509wkr513.html
个人介绍:Medcl, Elastic工程师与布道师,2015年加入Elastic公司, Elastic中文社区的发起人。
主题:ElasticStack 5.x 最新进展
内容介绍:ElasticStack 5.x 新增了很多新的激动人心的特性,本次分享将为大家一一解读。
录像:https://v.qq.com/x/page/m0509dt9f80.html
个人介绍:魏彬, rockybean,穿衣助手技术负责人,Elastic Stack 粉丝。
主题:用 Elastic Stack 来诊断下你的redis slowlog
内容介绍:
1. Elastic Stack 之 ElasticSearch Beats Kibana 简介
2. redis 和 slowlog 简介
3. 实现原理介绍
4. Kibana图形化结果展示介绍
5. 代码解析
6. 开源过程中的几点心得分享
录像:https://v.qq.com/x/page/m0509j6kyzj.html
个人介绍: 柯诗豪,携程旅行网高级软件工程师。
主题:基于Docker的ES PaaS云平台
内容介绍:伴随着公司越来越多的团队开始使用ES,部署和管理ES集群成本增加。所以建立了基于Docker通过Mesos提供的资源管理机制的ES PaaS平台,用户可以在平台上快捷的创建、配置和管理ES集群。
录像:https://v.qq.com/x/page/n0509pzjgxq.html
个人介绍: 彭科,13年从武汉理工毕业 ,16年进入斗鱼大数据基础架构组,主要负责日志监控平台和一些大数据技术的预研。目前已经从斗鱼离职,接下来会去一家云计算创业公司,从事大数据产品研发和AI方向研究。
主题:基于Elastic Stack+Kafka的日志监控平台架构演进
内容介绍:基于在斗鱼的工作经验,基于Elastic Stack和kafka做TB级日志监控平台搭建,架构演讲,踩过哪些坑,如何调优,与大数据组件技术对比,如何结合使用,如何监控基础组件与业务,分享一些自己的心得。
录像:https://v.qq.com/x/page/m05099qj8f9.html
主办:Elastic 中文社区
协办:众安保险
时间:2017-05-14 13:30PM-18:00PM
地点:上海市虹口区四川北路859号中信广场42楼
PPT 下载:https://pan.baidu.com/s/1eS157 ... %252F
分享主题:
个人介绍:杨智健, 众安保险搜索组负责人。
主题:es在众安保险的实践
内容介绍: es在众安保险业务线和日志类的实践,和相关平台化建设。
录像:https://v.qq.com/x/page/x0509wkr513.html
个人介绍:Medcl, Elastic工程师与布道师,2015年加入Elastic公司, Elastic中文社区的发起人。
主题:ElasticStack 5.x 最新进展
内容介绍:ElasticStack 5.x 新增了很多新的激动人心的特性,本次分享将为大家一一解读。
录像:https://v.qq.com/x/page/m0509dt9f80.html
个人介绍:魏彬, rockybean,穿衣助手技术负责人,Elastic Stack 粉丝。
主题:用 Elastic Stack 来诊断下你的redis slowlog
内容介绍:
1. Elastic Stack 之 ElasticSearch Beats Kibana 简介
2. redis 和 slowlog 简介
3. 实现原理介绍
4. Kibana图形化结果展示介绍
5. 代码解析
6. 开源过程中的几点心得分享
录像:https://v.qq.com/x/page/m0509j6kyzj.html
个人介绍: 柯诗豪,携程旅行网高级软件工程师。
主题:基于Docker的ES PaaS云平台
内容介绍:伴随着公司越来越多的团队开始使用ES,部署和管理ES集群成本增加。所以建立了基于Docker通过Mesos提供的资源管理机制的ES PaaS平台,用户可以在平台上快捷的创建、配置和管理ES集群。
录像:https://v.qq.com/x/page/n0509pzjgxq.html
个人介绍: 彭科,13年从武汉理工毕业 ,16年进入斗鱼大数据基础架构组,主要负责日志监控平台和一些大数据技术的预研。目前已经从斗鱼离职,接下来会去一家云计算创业公司,从事大数据产品研发和AI方向研究。
主题:基于Elastic Stack+Kafka的日志监控平台架构演进
内容介绍:基于在斗鱼的工作经验,基于Elastic Stack和kafka做TB级日志监控平台搭建,架构演讲,踩过哪些坑,如何调优,与大数据组件技术对比,如何结合使用,如何监控基础组件与业务,分享一些自己的心得。
录像:https://v.qq.com/x/page/m05099qj8f9.html 收起阅读 »
协办:众安保险
时间:2017-05-14 13:30PM-18:00PM
地点:上海市虹口区四川北路859号中信广场42楼
PPT 下载:https://pan.baidu.com/s/1eS157 ... %252F
分享主题:
个人介绍:杨智健, 众安保险搜索组负责人。
主题:es在众安保险的实践
内容介绍: es在众安保险业务线和日志类的实践,和相关平台化建设。
录像:https://v.qq.com/x/page/x0509wkr513.html
个人介绍:Medcl, Elastic工程师与布道师,2015年加入Elastic公司, Elastic中文社区的发起人。
主题:ElasticStack 5.x 最新进展
内容介绍:ElasticStack 5.x 新增了很多新的激动人心的特性,本次分享将为大家一一解读。
录像:https://v.qq.com/x/page/m0509dt9f80.html
个人介绍:魏彬, rockybean,穿衣助手技术负责人,Elastic Stack 粉丝。
主题:用 Elastic Stack 来诊断下你的redis slowlog
内容介绍:
1. Elastic Stack 之 ElasticSearch Beats Kibana 简介
2. redis 和 slowlog 简介
3. 实现原理介绍
4. Kibana图形化结果展示介绍
5. 代码解析
6. 开源过程中的几点心得分享
录像:https://v.qq.com/x/page/m0509j6kyzj.html
个人介绍: 柯诗豪,携程旅行网高级软件工程师。
主题:基于Docker的ES PaaS云平台
内容介绍:伴随着公司越来越多的团队开始使用ES,部署和管理ES集群成本增加。所以建立了基于Docker通过Mesos提供的资源管理机制的ES PaaS平台,用户可以在平台上快捷的创建、配置和管理ES集群。
录像:https://v.qq.com/x/page/n0509pzjgxq.html
个人介绍: 彭科,13年从武汉理工毕业 ,16年进入斗鱼大数据基础架构组,主要负责日志监控平台和一些大数据技术的预研。目前已经从斗鱼离职,接下来会去一家云计算创业公司,从事大数据产品研发和AI方向研究。
主题:基于Elastic Stack+Kafka的日志监控平台架构演进
内容介绍:基于在斗鱼的工作经验,基于Elastic Stack和kafka做TB级日志监控平台搭建,架构演讲,踩过哪些坑,如何调优,与大数据组件技术对比,如何结合使用,如何监控基础组件与业务,分享一些自己的心得。
录像:https://v.qq.com/x/page/m05099qj8f9.html 收起阅读 »
ES5.2.2支持geo排序+聚合
ES5.2.2真的 支持geo排序+聚合
具体查询条件,这里不写了;
查询结果如下:
{ "took": 90, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 10, "max_score": null, "hits": [ { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000000", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000000", "equipName": "灭火剂0", "equipValue": 73, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000003", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000003", "equipName": "灭火剂3", "equipValue": 47, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000001", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000001", "equipName": "灭火剂1", "equipValue": 12, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000004", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000004", "equipName": "灭火剂4", "equipValue": 2, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000002", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000002", "equipName": "灭火剂2", "equipValue": 57, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000018", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000018", "equipName": "灭火剂8", "equipValue": 61, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000014", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000014", "equipName": "灭火剂4", "equipValue": 81, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000016", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000016", "equipName": "灭火剂6", "equipValue": 81, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000015", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000015", "equipName": "灭火剂5", "equipValue": 87, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000017", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000017", "equipName": "灭火剂7", "equipValue": 90, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] } ] }, "aggregations": { "aggEquip": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "1000000", "doc_count": 1, "sumEquipValue": { "value": 73 } }, { "key": "1000001", "doc_count": 1, "sumEquipValue": { "value": 12 } }, { "key": "1000002", "doc_count": 1, "sumEquipValue": { "value": 57 } }, { "key": "1000003", "doc_count": 1, "sumEquipValue": { "value": 47 } }, { "key": "1000004", "doc_count": 1, "sumEquipValue": { "value": 2 } }, { "key": "1000014", "doc_count": 1, "sumEquipValue": { "value": 81 } }, { "key": "1000015", "doc_count": 1, "sumEquipValue": { "value": 87 } }, { "key": "1000016", "doc_count": 1, "sumEquipValue": { "value": 81 } }, { "key": "1000017", "doc_count": 1, "sumEquipValue": { "value": 90 } }, { "key": "1000018", "doc_count": 1, "sumEquipValue": { "value": 61 } }, { "key": "10000210", "doc_count": 1, "sumEquipValue": { "value": 70 } }, { "key": "10000211", "doc_count": 1, "sumEquipValue": { "value": 55 } }, { "key": "1000027", "doc_count": 1, "sumEquipValue": { "value": 19 } }, { "key": "1000028", "doc_count": 1, "sumEquipValue": { "value": 25 } }, { "key": "1000029", "doc_count": 1, "sumEquipValue": { "value": 3 } }, { "key": "10000311", "doc_count": 1, "sumEquipValue": { "value": 97 } }, { "key": "10000312", "doc_count": 1, "sumEquipValue": { "value": 79 } }, { "key": "10000313", "doc_count": 1, "sumEquipValue": { "value": 95 } }, { "key": "10000314", "doc_count": 1, "sumEquipValue": { "value": 6 } }, { "key": "10000315", "doc_count": 1, "sumEquipValue": { "value": 8 } } ] } } }
继续阅读 »
具体查询条件,这里不写了;
查询结果如下:
{ "took": 90, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 10, "max_score": null, "hits": [ { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000000", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000000", "equipName": "灭火剂0", "equipValue": 73, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000003", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000003", "equipName": "灭火剂3", "equipValue": 47, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000001", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000001", "equipName": "灭火剂1", "equipValue": 12, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000004", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000004", "equipName": "灭火剂4", "equipValue": 2, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000002", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000002", "equipName": "灭火剂2", "equipValue": 57, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000018", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000018", "equipName": "灭火剂8", "equipValue": 61, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000014", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000014", "equipName": "灭火剂4", "equipValue": 81, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000016", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000016", "equipName": "灭火剂6", "equipValue": 81, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000015", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000015", "equipName": "灭火剂5", "equipValue": 87, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000017", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000017", "equipName": "灭火剂7", "equipValue": 90, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] } ] }, "aggregations": { "aggEquip": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "1000000", "doc_count": 1, "sumEquipValue": { "value": 73 } }, { "key": "1000001", "doc_count": 1, "sumEquipValue": { "value": 12 } }, { "key": "1000002", "doc_count": 1, "sumEquipValue": { "value": 57 } }, { "key": "1000003", "doc_count": 1, "sumEquipValue": { "value": 47 } }, { "key": "1000004", "doc_count": 1, "sumEquipValue": { "value": 2 } }, { "key": "1000014", "doc_count": 1, "sumEquipValue": { "value": 81 } }, { "key": "1000015", "doc_count": 1, "sumEquipValue": { "value": 87 } }, { "key": "1000016", "doc_count": 1, "sumEquipValue": { "value": 81 } }, { "key": "1000017", "doc_count": 1, "sumEquipValue": { "value": 90 } }, { "key": "1000018", "doc_count": 1, "sumEquipValue": { "value": 61 } }, { "key": "10000210", "doc_count": 1, "sumEquipValue": { "value": 70 } }, { "key": "10000211", "doc_count": 1, "sumEquipValue": { "value": 55 } }, { "key": "1000027", "doc_count": 1, "sumEquipValue": { "value": 19 } }, { "key": "1000028", "doc_count": 1, "sumEquipValue": { "value": 25 } }, { "key": "1000029", "doc_count": 1, "sumEquipValue": { "value": 3 } }, { "key": "10000311", "doc_count": 1, "sumEquipValue": { "value": 97 } }, { "key": "10000312", "doc_count": 1, "sumEquipValue": { "value": 79 } }, { "key": "10000313", "doc_count": 1, "sumEquipValue": { "value": 95 } }, { "key": "10000314", "doc_count": 1, "sumEquipValue": { "value": 6 } }, { "key": "10000315", "doc_count": 1, "sumEquipValue": { "value": 8 } } ] } } }
ES5.2.2真的 支持geo排序+聚合
具体查询条件,这里不写了;
查询结果如下:
{ "took": 90, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 10, "max_score": null, "hits": [ { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000000", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000000", "equipName": "灭火剂0", "equipValue": 73, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000003", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000003", "equipName": "灭火剂3", "equipValue": 47, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000001", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000001", "equipName": "灭火剂1", "equipValue": 12, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000004", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000004", "equipName": "灭火剂4", "equipValue": 2, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000002", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000002", "equipName": "灭火剂2", "equipValue": 57, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000018", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000018", "equipName": "灭火剂8", "equipValue": 61, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000014", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000014", "equipName": "灭火剂4", "equipValue": 81, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000016", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000016", "equipName": "灭火剂6", "equipValue": 81, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000015", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000015", "equipName": "灭火剂5", "equipValue": 87, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000017", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000017", "equipName": "灭火剂7", "equipValue": 90, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] } ] }, "aggregations": { "aggEquip": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "1000000", "doc_count": 1, "sumEquipValue": { "value": 73 } }, { "key": "1000001", "doc_count": 1, "sumEquipValue": { "value": 12 } }, { "key": "1000002", "doc_count": 1, "sumEquipValue": { "value": 57 } }, { "key": "1000003", "doc_count": 1, "sumEquipValue": { "value": 47 } }, { "key": "1000004", "doc_count": 1, "sumEquipValue": { "value": 2 } }, { "key": "1000014", "doc_count": 1, "sumEquipValue": { "value": 81 } }, { "key": "1000015", "doc_count": 1, "sumEquipValue": { "value": 87 } }, { "key": "1000016", "doc_count": 1, "sumEquipValue": { "value": 81 } }, { "key": "1000017", "doc_count": 1, "sumEquipValue": { "value": 90 } }, { "key": "1000018", "doc_count": 1, "sumEquipValue": { "value": 61 } }, { "key": "10000210", "doc_count": 1, "sumEquipValue": { "value": 70 } }, { "key": "10000211", "doc_count": 1, "sumEquipValue": { "value": 55 } }, { "key": "1000027", "doc_count": 1, "sumEquipValue": { "value": 19 } }, { "key": "1000028", "doc_count": 1, "sumEquipValue": { "value": 25 } }, { "key": "1000029", "doc_count": 1, "sumEquipValue": { "value": 3 } }, { "key": "10000311", "doc_count": 1, "sumEquipValue": { "value": 97 } }, { "key": "10000312", "doc_count": 1, "sumEquipValue": { "value": 79 } }, { "key": "10000313", "doc_count": 1, "sumEquipValue": { "value": 95 } }, { "key": "10000314", "doc_count": 1, "sumEquipValue": { "value": 6 } }, { "key": "10000315", "doc_count": 1, "sumEquipValue": { "value": 8 } } ] } } }
收起阅读 »
具体查询条件,这里不写了;
查询结果如下:
{ "took": 90, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 10, "max_score": null, "hits": [ { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000000", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000000", "equipName": "灭火剂0", "equipValue": 73, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000003", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000003", "equipName": "灭火剂3", "equipValue": 47, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000001", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000001", "equipName": "灭火剂1", "equipValue": 12, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000004", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000004", "equipName": "灭火剂4", "equipValue": 2, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000002", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000002", "equipName": "灭火剂2", "equipValue": 57, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000018", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000018", "equipName": "灭火剂8", "equipValue": 61, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000014", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000014", "equipName": "灭火剂4", "equipValue": 81, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000016", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000016", "equipName": "灭火剂6", "equipValue": 81, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000015", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000015", "equipName": "灭火剂5", "equipValue": 87, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000017", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000017", "equipName": "灭火剂7", "equipValue": 90, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] } ] }, "aggregations": { "aggEquip": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "1000000", "doc_count": 1, "sumEquipValue": { "value": 73 } }, { "key": "1000001", "doc_count": 1, "sumEquipValue": { "value": 12 } }, { "key": "1000002", "doc_count": 1, "sumEquipValue": { "value": 57 } }, { "key": "1000003", "doc_count": 1, "sumEquipValue": { "value": 47 } }, { "key": "1000004", "doc_count": 1, "sumEquipValue": { "value": 2 } }, { "key": "1000014", "doc_count": 1, "sumEquipValue": { "value": 81 } }, { "key": "1000015", "doc_count": 1, "sumEquipValue": { "value": 87 } }, { "key": "1000016", "doc_count": 1, "sumEquipValue": { "value": 81 } }, { "key": "1000017", "doc_count": 1, "sumEquipValue": { "value": 90 } }, { "key": "1000018", "doc_count": 1, "sumEquipValue": { "value": 61 } }, { "key": "10000210", "doc_count": 1, "sumEquipValue": { "value": 70 } }, { "key": "10000211", "doc_count": 1, "sumEquipValue": { "value": 55 } }, { "key": "1000027", "doc_count": 1, "sumEquipValue": { "value": 19 } }, { "key": "1000028", "doc_count": 1, "sumEquipValue": { "value": 25 } }, { "key": "1000029", "doc_count": 1, "sumEquipValue": { "value": 3 } }, { "key": "10000311", "doc_count": 1, "sumEquipValue": { "value": 97 } }, { "key": "10000312", "doc_count": 1, "sumEquipValue": { "value": 79 } }, { "key": "10000313", "doc_count": 1, "sumEquipValue": { "value": 95 } }, { "key": "10000314", "doc_count": 1, "sumEquipValue": { "value": 6 } }, { "key": "10000315", "doc_count": 1, "sumEquipValue": { "value": 8 } } ] } } }
收起阅读 »
liushui00001 发表于 : 2017-05-06 16:50
评论 (1)
Max 发表于 : 2017-05-06 14:18
评论 (0)
_source/_all特性效果
我经过实际测试es5.2.2,发现_source/_all特性很好用:
1. _source可用通过配置includes、excludes获取应用需要的field
"_source": {
"enabled": true,
"includes": [
"comId",
"name",
"userName",
"equips.name",
"equips.amount"
],
"excludes": [
"phone",
"equips.code"
]
},
2.设置enabled=false关闭_source功能,关闭后,查询结果只返回doc的ID,而不会返回_source
"_source": {
"enabled": false,
3._all、include_in_all结合使用,是用户可用通过_all分词查询多个字段,而不需要写多个查询条件
"mappings": {
"testdoc03": {
"_all": {
"enabled": true
},
"_source": {
"enabled": false,
"includes": [
"comId",
"name",
"userName",
"equips.name",
"equips.amount"
],
"excludes": [
"phone",
"equips.code"
]
},
"properties": {
"comId": {
"type": "long"
},
"equips": {
"properties": {
"amount": {
"type": "double",
"include_in_all": true
},
"code": {
"type": "text"
},
"name": {
"type": "text",
"include_in_all": true
}
}
},
"name": {
"type": "text",
"include_in_all": true
},
"phone": {
"type": "keyword"
},
"userName": {
"type": "text",
"include_in_all": true
}
}
}
}
}
继续阅读 »
1. _source可用通过配置includes、excludes获取应用需要的field
"_source": {
"enabled": true,
"includes": [
"comId",
"name",
"userName",
"equips.name",
"equips.amount"
],
"excludes": [
"phone",
"equips.code"
]
},
2.设置enabled=false关闭_source功能,关闭后,查询结果只返回doc的ID,而不会返回_source
"_source": {
"enabled": false,
3._all、include_in_all结合使用,是用户可用通过_all分词查询多个字段,而不需要写多个查询条件
"mappings": {
"testdoc03": {
"_all": {
"enabled": true
},
"_source": {
"enabled": false,
"includes": [
"comId",
"name",
"userName",
"equips.name",
"equips.amount"
],
"excludes": [
"phone",
"equips.code"
]
},
"properties": {
"comId": {
"type": "long"
},
"equips": {
"properties": {
"amount": {
"type": "double",
"include_in_all": true
},
"code": {
"type": "text"
},
"name": {
"type": "text",
"include_in_all": true
}
}
},
"name": {
"type": "text",
"include_in_all": true
},
"phone": {
"type": "keyword"
},
"userName": {
"type": "text",
"include_in_all": true
}
}
}
}
}
我经过实际测试es5.2.2,发现_source/_all特性很好用:
1. _source可用通过配置includes、excludes获取应用需要的field
"_source": {
"enabled": true,
"includes": [
"comId",
"name",
"userName",
"equips.name",
"equips.amount"
],
"excludes": [
"phone",
"equips.code"
]
},
2.设置enabled=false关闭_source功能,关闭后,查询结果只返回doc的ID,而不会返回_source
"_source": {
"enabled": false,
3._all、include_in_all结合使用,是用户可用通过_all分词查询多个字段,而不需要写多个查询条件
"mappings": {
"testdoc03": {
"_all": {
"enabled": true
},
"_source": {
"enabled": false,
"includes": [
"comId",
"name",
"userName",
"equips.name",
"equips.amount"
],
"excludes": [
"phone",
"equips.code"
]
},
"properties": {
"comId": {
"type": "long"
},
"equips": {
"properties": {
"amount": {
"type": "double",
"include_in_all": true
},
"code": {
"type": "text"
},
"name": {
"type": "text",
"include_in_all": true
}
}
},
"name": {
"type": "text",
"include_in_all": true
},
"phone": {
"type": "keyword"
},
"userName": {
"type": "text",
"include_in_all": true
}
}
}
}
}
收起阅读 »
1. _source可用通过配置includes、excludes获取应用需要的field
"_source": {
"enabled": true,
"includes": [
"comId",
"name",
"userName",
"equips.name",
"equips.amount"
],
"excludes": [
"phone",
"equips.code"
]
},
2.设置enabled=false关闭_source功能,关闭后,查询结果只返回doc的ID,而不会返回_source
"_source": {
"enabled": false,
3._all、include_in_all结合使用,是用户可用通过_all分词查询多个字段,而不需要写多个查询条件
"mappings": {
"testdoc03": {
"_all": {
"enabled": true
},
"_source": {
"enabled": false,
"includes": [
"comId",
"name",
"userName",
"equips.name",
"equips.amount"
],
"excludes": [
"phone",
"equips.code"
]
},
"properties": {
"comId": {
"type": "long"
},
"equips": {
"properties": {
"amount": {
"type": "double",
"include_in_all": true
},
"code": {
"type": "text"
},
"name": {
"type": "text",
"include_in_all": true
}
}
},
"name": {
"type": "text",
"include_in_all": true
},
"phone": {
"type": "keyword"
},
"userName": {
"type": "text",
"include_in_all": true
}
}
}
}
}
收起阅读 »
liushui00001 发表于 : 2017-05-05 18:13
评论 (3)
Elasticsearch 5.4 发布,新增机器学习功能
出大事了,Elastic Stack 今日发布 5.4 版本,X-Pack 新增机器学习模块!
https://www.elastic.co/cn/blog ... stack
今天,我们非常荣幸地宣布,首次发布通过 X-Pack 提供的 Elastic Stack Machine Learning 功能。加入 Elastic 就像跳上了火箭船,但是经过 7 个月不可思议的工作,我们现已将 Prelert Machine Learning 技术完全集成到 Elastic Stack。这让我们很激动,而且我们非常迫切地想要收到用户的反馈。
温馨提示:请注意,不要太过激动,这项功能在 5.4.0 版本中尚标记为 beta。
Machine Learning
我们的目标是通过一系列工具为用户赋能,让他们可以从自己的 Elasticsearch 数据中获取价值和洞察。与此同时,我们将 Machine Learning 视为 Elasticsearch 搜索和分析能力的自然延伸。举例来说,Elasticsearch 能够让您在大量数据中,实时地搜索用户“steve”的交易,或者利用聚合和可视化,展示一段时间以来的十大畅销产品或交易趋势。而现在有了 Machine Learning 功能,您就可以更加深入地探究数据,例如 “有没有哪项服务的行为发生了变化?” 或者 “主机上是否运行有异常进程?” 那么要想回答这些问题,就必须要利用 Machine Learning 技术,通过数据自动构建主机或服务的行为模式。
不过, Machine Learning 目前是软件行业最被夸大其词的术语之一,因为从本质上来讲,它就是用来实现数据驱动型预测、决策和建模的一系列广泛的算法和方法。因此,我们有必要隔绝干扰信息,具体说说我们所做的工作。
时间序列异常检测
目前,X-Pack Machine Learning 功能的着眼点是,利用无监督式机器学习,提供 “时间序列异常检测” 功能。
随着时间的推移,我们计划增加更多 Machine Learning 功能,但是我们目前只专注于为用户存储的时间序列数据(例如日志文件、应用程序和性能指标、网络流量或 Elasticsearch 中的财务/交易数据)提供附加值。
示例 1 - 自动提醒关键绩效指标值的异常变化
要说这项技术最直观的用例,那就是可以识别指标值或事件速率偏离正常行为的情况。例如,服务响应时间有没有显著增加?网站访客预期数量与同一时段正常情况相比,是否存在明显差异?传统情况下,人们会利用规则、阈值或简单的统计方法来进行此类分析。但遗憾的是,这些简单的方法鲜少能够高效地处理实际数据,原因在于此类方法往往是基于无效的统计假设(例如:高斯分布),因此不支持趋势分析(长期性或周期性趋势),或者在信号发生变化时缺乏稳定性。
所以说, Machine Learning 功能的首个切入点是单一指标作业,您可以借此了解该产品如何学习正常模式,如何识别单变量时间序列数据中存在的异常。如果您发现的异常是有意义的,您就可以连续地实时运行这项分析,并在发生异常时发出警报。
尽管这看上去像是一个比较简单的用例,但是产品后台包含大量复杂的无监督式机器学习算法和统计模型,因此我们对于任意信号具有鲁棒性,并且能够准确反映。
此外,为了让该功能可以在 Elasticsearch 集群中像原生程序一样运行,我们对功能实现进行了优化,因此几秒钟即可分析数以百万计的事件。
示例 2 - 自动追踪数以千计的指标
Machine Learning 产品可以扩展到数十万指标和日志文件,那么下一步就是要同时分析多个指标。这些指标可能是来自同一个主机的多个相关指标,可能是来自同一个数据库或应用程序的性能指标,也可能是来自多个主机的多个日志文件。在这种情况下,我们可以直接单独分析,再将结果聚合到同一个窗口,展示整体的系统异常情况。
例如,假设我要处理来自一大组应用程序服务的响应时间,我可以直接分析各个服务一段时间以来的响应时间,分别确认各个行为异常的服务,同时展示整体的系统异常情况:
示例 3 - 高级作业
最后,我们的产品还有大量更高级的用途。比方说,如果您想找出与整体相比行为异常的用户、异常的 DNS 流量,或者伦敦街头的拥堵路段,这时您就可以利用高级作业,灵活地分析 Elasticsearch 中存储的任何时间序列数据。
Elastic Stack 整合
Machine Learning 是 X-Pack 中的一项功能。这就意味着,安装 X-Pack 之后,就可以使用 Machine Learning 功能实时分析 Elasticsearch 中的时间序列数据。 Machine Learning 作业与索引和分片基本类似,能够跨 Elasticsearch 集群自动分布和管理。这还意味着 Machine Learning 作业对节点故障有很好的适应性。从性能角度看,紧密集成意味着数据永远不需要离开集群,而且我们可以利用 Elasticsearch 聚合极大地提高某些作业类型的性能。而紧密集成带来的另外一个好处就是,您可以直接从 Kibana 创建异常检测作业并查看结果。
由于这种方法对数据进行原位分析,数据从不离开集群,因此与将 Elasticsearch 数据集成到外部数据科学工具相比,这种方法能够带来显著的性能和运维优势。随着我们在这个领域开发出越来越多的技术,这种架构的优势将会更加显著。
立即试用并反馈
这些 Machine Learning 功能是 X-Pack 5.4 中的 beta 功能,现已可用。我们急切地想要听听您的使用体会,所以请下载 5.4 版本,安装 X-Pack,然后直接联系我们,或者通过我们的讨论论坛联系我们。
下载地址:https://www.elastic.co/cn/downloads
继续阅读 »
https://www.elastic.co/cn/blog ... stack
今天,我们非常荣幸地宣布,首次发布通过 X-Pack 提供的 Elastic Stack Machine Learning 功能。加入 Elastic 就像跳上了火箭船,但是经过 7 个月不可思议的工作,我们现已将 Prelert Machine Learning 技术完全集成到 Elastic Stack。这让我们很激动,而且我们非常迫切地想要收到用户的反馈。
温馨提示:请注意,不要太过激动,这项功能在 5.4.0 版本中尚标记为 beta。
Machine Learning
我们的目标是通过一系列工具为用户赋能,让他们可以从自己的 Elasticsearch 数据中获取价值和洞察。与此同时,我们将 Machine Learning 视为 Elasticsearch 搜索和分析能力的自然延伸。举例来说,Elasticsearch 能够让您在大量数据中,实时地搜索用户“steve”的交易,或者利用聚合和可视化,展示一段时间以来的十大畅销产品或交易趋势。而现在有了 Machine Learning 功能,您就可以更加深入地探究数据,例如 “有没有哪项服务的行为发生了变化?” 或者 “主机上是否运行有异常进程?” 那么要想回答这些问题,就必须要利用 Machine Learning 技术,通过数据自动构建主机或服务的行为模式。
不过, Machine Learning 目前是软件行业最被夸大其词的术语之一,因为从本质上来讲,它就是用来实现数据驱动型预测、决策和建模的一系列广泛的算法和方法。因此,我们有必要隔绝干扰信息,具体说说我们所做的工作。
时间序列异常检测
目前,X-Pack Machine Learning 功能的着眼点是,利用无监督式机器学习,提供 “时间序列异常检测” 功能。
随着时间的推移,我们计划增加更多 Machine Learning 功能,但是我们目前只专注于为用户存储的时间序列数据(例如日志文件、应用程序和性能指标、网络流量或 Elasticsearch 中的财务/交易数据)提供附加值。
示例 1 - 自动提醒关键绩效指标值的异常变化
要说这项技术最直观的用例,那就是可以识别指标值或事件速率偏离正常行为的情况。例如,服务响应时间有没有显著增加?网站访客预期数量与同一时段正常情况相比,是否存在明显差异?传统情况下,人们会利用规则、阈值或简单的统计方法来进行此类分析。但遗憾的是,这些简单的方法鲜少能够高效地处理实际数据,原因在于此类方法往往是基于无效的统计假设(例如:高斯分布),因此不支持趋势分析(长期性或周期性趋势),或者在信号发生变化时缺乏稳定性。
所以说, Machine Learning 功能的首个切入点是单一指标作业,您可以借此了解该产品如何学习正常模式,如何识别单变量时间序列数据中存在的异常。如果您发现的异常是有意义的,您就可以连续地实时运行这项分析,并在发生异常时发出警报。
尽管这看上去像是一个比较简单的用例,但是产品后台包含大量复杂的无监督式机器学习算法和统计模型,因此我们对于任意信号具有鲁棒性,并且能够准确反映。
此外,为了让该功能可以在 Elasticsearch 集群中像原生程序一样运行,我们对功能实现进行了优化,因此几秒钟即可分析数以百万计的事件。
示例 2 - 自动追踪数以千计的指标
Machine Learning 产品可以扩展到数十万指标和日志文件,那么下一步就是要同时分析多个指标。这些指标可能是来自同一个主机的多个相关指标,可能是来自同一个数据库或应用程序的性能指标,也可能是来自多个主机的多个日志文件。在这种情况下,我们可以直接单独分析,再将结果聚合到同一个窗口,展示整体的系统异常情况。
例如,假设我要处理来自一大组应用程序服务的响应时间,我可以直接分析各个服务一段时间以来的响应时间,分别确认各个行为异常的服务,同时展示整体的系统异常情况:
示例 3 - 高级作业
最后,我们的产品还有大量更高级的用途。比方说,如果您想找出与整体相比行为异常的用户、异常的 DNS 流量,或者伦敦街头的拥堵路段,这时您就可以利用高级作业,灵活地分析 Elasticsearch 中存储的任何时间序列数据。
Elastic Stack 整合
Machine Learning 是 X-Pack 中的一项功能。这就意味着,安装 X-Pack 之后,就可以使用 Machine Learning 功能实时分析 Elasticsearch 中的时间序列数据。 Machine Learning 作业与索引和分片基本类似,能够跨 Elasticsearch 集群自动分布和管理。这还意味着 Machine Learning 作业对节点故障有很好的适应性。从性能角度看,紧密集成意味着数据永远不需要离开集群,而且我们可以利用 Elasticsearch 聚合极大地提高某些作业类型的性能。而紧密集成带来的另外一个好处就是,您可以直接从 Kibana 创建异常检测作业并查看结果。
由于这种方法对数据进行原位分析,数据从不离开集群,因此与将 Elasticsearch 数据集成到外部数据科学工具相比,这种方法能够带来显著的性能和运维优势。随着我们在这个领域开发出越来越多的技术,这种架构的优势将会更加显著。
立即试用并反馈
这些 Machine Learning 功能是 X-Pack 5.4 中的 beta 功能,现已可用。我们急切地想要听听您的使用体会,所以请下载 5.4 版本,安装 X-Pack,然后直接联系我们,或者通过我们的讨论论坛联系我们。
下载地址:https://www.elastic.co/cn/downloads
出大事了,Elastic Stack 今日发布 5.4 版本,X-Pack 新增机器学习模块!
https://www.elastic.co/cn/blog ... stack
今天,我们非常荣幸地宣布,首次发布通过 X-Pack 提供的 Elastic Stack Machine Learning 功能。加入 Elastic 就像跳上了火箭船,但是经过 7 个月不可思议的工作,我们现已将 Prelert Machine Learning 技术完全集成到 Elastic Stack。这让我们很激动,而且我们非常迫切地想要收到用户的反馈。
温馨提示:请注意,不要太过激动,这项功能在 5.4.0 版本中尚标记为 beta。
Machine Learning
我们的目标是通过一系列工具为用户赋能,让他们可以从自己的 Elasticsearch 数据中获取价值和洞察。与此同时,我们将 Machine Learning 视为 Elasticsearch 搜索和分析能力的自然延伸。举例来说,Elasticsearch 能够让您在大量数据中,实时地搜索用户“steve”的交易,或者利用聚合和可视化,展示一段时间以来的十大畅销产品或交易趋势。而现在有了 Machine Learning 功能,您就可以更加深入地探究数据,例如 “有没有哪项服务的行为发生了变化?” 或者 “主机上是否运行有异常进程?” 那么要想回答这些问题,就必须要利用 Machine Learning 技术,通过数据自动构建主机或服务的行为模式。
不过, Machine Learning 目前是软件行业最被夸大其词的术语之一,因为从本质上来讲,它就是用来实现数据驱动型预测、决策和建模的一系列广泛的算法和方法。因此,我们有必要隔绝干扰信息,具体说说我们所做的工作。
时间序列异常检测
目前,X-Pack Machine Learning 功能的着眼点是,利用无监督式机器学习,提供 “时间序列异常检测” 功能。
随着时间的推移,我们计划增加更多 Machine Learning 功能,但是我们目前只专注于为用户存储的时间序列数据(例如日志文件、应用程序和性能指标、网络流量或 Elasticsearch 中的财务/交易数据)提供附加值。
示例 1 - 自动提醒关键绩效指标值的异常变化
要说这项技术最直观的用例,那就是可以识别指标值或事件速率偏离正常行为的情况。例如,服务响应时间有没有显著增加?网站访客预期数量与同一时段正常情况相比,是否存在明显差异?传统情况下,人们会利用规则、阈值或简单的统计方法来进行此类分析。但遗憾的是,这些简单的方法鲜少能够高效地处理实际数据,原因在于此类方法往往是基于无效的统计假设(例如:高斯分布),因此不支持趋势分析(长期性或周期性趋势),或者在信号发生变化时缺乏稳定性。
所以说, Machine Learning 功能的首个切入点是单一指标作业,您可以借此了解该产品如何学习正常模式,如何识别单变量时间序列数据中存在的异常。如果您发现的异常是有意义的,您就可以连续地实时运行这项分析,并在发生异常时发出警报。
尽管这看上去像是一个比较简单的用例,但是产品后台包含大量复杂的无监督式机器学习算法和统计模型,因此我们对于任意信号具有鲁棒性,并且能够准确反映。
此外,为了让该功能可以在 Elasticsearch 集群中像原生程序一样运行,我们对功能实现进行了优化,因此几秒钟即可分析数以百万计的事件。
示例 2 - 自动追踪数以千计的指标
Machine Learning 产品可以扩展到数十万指标和日志文件,那么下一步就是要同时分析多个指标。这些指标可能是来自同一个主机的多个相关指标,可能是来自同一个数据库或应用程序的性能指标,也可能是来自多个主机的多个日志文件。在这种情况下,我们可以直接单独分析,再将结果聚合到同一个窗口,展示整体的系统异常情况。
例如,假设我要处理来自一大组应用程序服务的响应时间,我可以直接分析各个服务一段时间以来的响应时间,分别确认各个行为异常的服务,同时展示整体的系统异常情况:
示例 3 - 高级作业
最后,我们的产品还有大量更高级的用途。比方说,如果您想找出与整体相比行为异常的用户、异常的 DNS 流量,或者伦敦街头的拥堵路段,这时您就可以利用高级作业,灵活地分析 Elasticsearch 中存储的任何时间序列数据。
Elastic Stack 整合
Machine Learning 是 X-Pack 中的一项功能。这就意味着,安装 X-Pack 之后,就可以使用 Machine Learning 功能实时分析 Elasticsearch 中的时间序列数据。 Machine Learning 作业与索引和分片基本类似,能够跨 Elasticsearch 集群自动分布和管理。这还意味着 Machine Learning 作业对节点故障有很好的适应性。从性能角度看,紧密集成意味着数据永远不需要离开集群,而且我们可以利用 Elasticsearch 聚合极大地提高某些作业类型的性能。而紧密集成带来的另外一个好处就是,您可以直接从 Kibana 创建异常检测作业并查看结果。
由于这种方法对数据进行原位分析,数据从不离开集群,因此与将 Elasticsearch 数据集成到外部数据科学工具相比,这种方法能够带来显著的性能和运维优势。随着我们在这个领域开发出越来越多的技术,这种架构的优势将会更加显著。
立即试用并反馈
这些 Machine Learning 功能是 X-Pack 5.4 中的 beta 功能,现已可用。我们急切地想要听听您的使用体会,所以请下载 5.4 版本,安装 X-Pack,然后直接联系我们,或者通过我们的讨论论坛联系我们。
下载地址:https://www.elastic.co/cn/downloads
收起阅读 »
https://www.elastic.co/cn/blog ... stack
今天,我们非常荣幸地宣布,首次发布通过 X-Pack 提供的 Elastic Stack Machine Learning 功能。加入 Elastic 就像跳上了火箭船,但是经过 7 个月不可思议的工作,我们现已将 Prelert Machine Learning 技术完全集成到 Elastic Stack。这让我们很激动,而且我们非常迫切地想要收到用户的反馈。
温馨提示:请注意,不要太过激动,这项功能在 5.4.0 版本中尚标记为 beta。
Machine Learning
我们的目标是通过一系列工具为用户赋能,让他们可以从自己的 Elasticsearch 数据中获取价值和洞察。与此同时,我们将 Machine Learning 视为 Elasticsearch 搜索和分析能力的自然延伸。举例来说,Elasticsearch 能够让您在大量数据中,实时地搜索用户“steve”的交易,或者利用聚合和可视化,展示一段时间以来的十大畅销产品或交易趋势。而现在有了 Machine Learning 功能,您就可以更加深入地探究数据,例如 “有没有哪项服务的行为发生了变化?” 或者 “主机上是否运行有异常进程?” 那么要想回答这些问题,就必须要利用 Machine Learning 技术,通过数据自动构建主机或服务的行为模式。
不过, Machine Learning 目前是软件行业最被夸大其词的术语之一,因为从本质上来讲,它就是用来实现数据驱动型预测、决策和建模的一系列广泛的算法和方法。因此,我们有必要隔绝干扰信息,具体说说我们所做的工作。
时间序列异常检测
目前,X-Pack Machine Learning 功能的着眼点是,利用无监督式机器学习,提供 “时间序列异常检测” 功能。
随着时间的推移,我们计划增加更多 Machine Learning 功能,但是我们目前只专注于为用户存储的时间序列数据(例如日志文件、应用程序和性能指标、网络流量或 Elasticsearch 中的财务/交易数据)提供附加值。
示例 1 - 自动提醒关键绩效指标值的异常变化
要说这项技术最直观的用例,那就是可以识别指标值或事件速率偏离正常行为的情况。例如,服务响应时间有没有显著增加?网站访客预期数量与同一时段正常情况相比,是否存在明显差异?传统情况下,人们会利用规则、阈值或简单的统计方法来进行此类分析。但遗憾的是,这些简单的方法鲜少能够高效地处理实际数据,原因在于此类方法往往是基于无效的统计假设(例如:高斯分布),因此不支持趋势分析(长期性或周期性趋势),或者在信号发生变化时缺乏稳定性。
所以说, Machine Learning 功能的首个切入点是单一指标作业,您可以借此了解该产品如何学习正常模式,如何识别单变量时间序列数据中存在的异常。如果您发现的异常是有意义的,您就可以连续地实时运行这项分析,并在发生异常时发出警报。
尽管这看上去像是一个比较简单的用例,但是产品后台包含大量复杂的无监督式机器学习算法和统计模型,因此我们对于任意信号具有鲁棒性,并且能够准确反映。
此外,为了让该功能可以在 Elasticsearch 集群中像原生程序一样运行,我们对功能实现进行了优化,因此几秒钟即可分析数以百万计的事件。
示例 2 - 自动追踪数以千计的指标
Machine Learning 产品可以扩展到数十万指标和日志文件,那么下一步就是要同时分析多个指标。这些指标可能是来自同一个主机的多个相关指标,可能是来自同一个数据库或应用程序的性能指标,也可能是来自多个主机的多个日志文件。在这种情况下,我们可以直接单独分析,再将结果聚合到同一个窗口,展示整体的系统异常情况。
例如,假设我要处理来自一大组应用程序服务的响应时间,我可以直接分析各个服务一段时间以来的响应时间,分别确认各个行为异常的服务,同时展示整体的系统异常情况:
示例 3 - 高级作业
最后,我们的产品还有大量更高级的用途。比方说,如果您想找出与整体相比行为异常的用户、异常的 DNS 流量,或者伦敦街头的拥堵路段,这时您就可以利用高级作业,灵活地分析 Elasticsearch 中存储的任何时间序列数据。
Elastic Stack 整合
Machine Learning 是 X-Pack 中的一项功能。这就意味着,安装 X-Pack 之后,就可以使用 Machine Learning 功能实时分析 Elasticsearch 中的时间序列数据。 Machine Learning 作业与索引和分片基本类似,能够跨 Elasticsearch 集群自动分布和管理。这还意味着 Machine Learning 作业对节点故障有很好的适应性。从性能角度看,紧密集成意味着数据永远不需要离开集群,而且我们可以利用 Elasticsearch 聚合极大地提高某些作业类型的性能。而紧密集成带来的另外一个好处就是,您可以直接从 Kibana 创建异常检测作业并查看结果。
由于这种方法对数据进行原位分析,数据从不离开集群,因此与将 Elasticsearch 数据集成到外部数据科学工具相比,这种方法能够带来显著的性能和运维优势。随着我们在这个领域开发出越来越多的技术,这种架构的优势将会更加显著。
立即试用并反馈
这些 Machine Learning 功能是 X-Pack 5.4 中的 beta 功能,现已可用。我们急切地想要听听您的使用体会,所以请下载 5.4 版本,安装 X-Pack,然后直接联系我们,或者通过我们的讨论论坛联系我们。
下载地址:https://www.elastic.co/cn/downloads
收起阅读 »
medcl 发表于 : 2017-05-05 09:12
评论 (3)
Elasticsearch 6.0 将移除 Type
尽管之前在很多地方都提到过,不过还是有必要单独开篇文章提醒一下大家!
Type 已经打算在6.0移除了,所以在设计 elasticsearch 的数据结构的时候,要注意到后面版本的变化。
之前在很多的文章和 PPT 都有介绍Elasticsearch 的几个核心概念,Index 对应 DB,Type 对应表,Document 对应记录,然后就真的按数据库的路子用,一个 index 里面 n 个 type 的情况大有存在,但是在 Lucene 里面其实有很多问题,所以现在es移除也是考虑了很久的。
新增参数:
UID 也会移除掉 _type 的值。
Type 移除大概分为两个阶段:
第一步,不支持新的索引创建多个 type,一个索引只有一个 type,名称也是固定的,不能修改。
第二步,移除。
相应的 PR 已经 merge 了。
https://github.com/elastic/ela ... 24317
继续阅读 »
Type 已经打算在6.0移除了,所以在设计 elasticsearch 的数据结构的时候,要注意到后面版本的变化。
之前在很多的文章和 PPT 都有介绍Elasticsearch 的几个核心概念,Index 对应 DB,Type 对应表,Document 对应记录,然后就真的按数据库的路子用,一个 index 里面 n 个 type 的情况大有存在,但是在 Lucene 里面其实有很多问题,所以现在es移除也是考虑了很久的。
新增参数:
index.mapping.single_type: true
UID 也会移除掉 _type 的值。
Type 移除大概分为两个阶段:
第一步,不支持新的索引创建多个 type,一个索引只有一个 type,名称也是固定的,不能修改。
第二步,移除。
相应的 PR 已经 merge 了。
https://github.com/elastic/ela ... 24317
尽管之前在很多地方都提到过,不过还是有必要单独开篇文章提醒一下大家!
Type 已经打算在6.0移除了,所以在设计 elasticsearch 的数据结构的时候,要注意到后面版本的变化。
之前在很多的文章和 PPT 都有介绍Elasticsearch 的几个核心概念,Index 对应 DB,Type 对应表,Document 对应记录,然后就真的按数据库的路子用,一个 index 里面 n 个 type 的情况大有存在,但是在 Lucene 里面其实有很多问题,所以现在es移除也是考虑了很久的。
新增参数:
UID 也会移除掉 _type 的值。
Type 移除大概分为两个阶段:
第一步,不支持新的索引创建多个 type,一个索引只有一个 type,名称也是固定的,不能修改。
第二步,移除。
相应的 PR 已经 merge 了。
https://github.com/elastic/ela ... 24317
收起阅读 »
Type 已经打算在6.0移除了,所以在设计 elasticsearch 的数据结构的时候,要注意到后面版本的变化。
之前在很多的文章和 PPT 都有介绍Elasticsearch 的几个核心概念,Index 对应 DB,Type 对应表,Document 对应记录,然后就真的按数据库的路子用,一个 index 里面 n 个 type 的情况大有存在,但是在 Lucene 里面其实有很多问题,所以现在es移除也是考虑了很久的。
新增参数:
index.mapping.single_type: true
UID 也会移除掉 _type 的值。
Type 移除大概分为两个阶段:
第一步,不支持新的索引创建多个 type,一个索引只有一个 type,名称也是固定的,不能修改。
第二步,移除。
相应的 PR 已经 merge 了。
https://github.com/elastic/ela ... 24317
收起阅读 »
Sql on Elasticsearch
esql
Git地址
https://github.com/unimassystem/esql5
继续阅读 »
Git地址
https://github.com/unimassystem/esql5
create table my_index.my_table (
id keyword,
name text,
age long,
birthday date
);
select * from my_index.my_type;
select count(*) from my_index.my_table group by age;
#Create table
字段参数,ES中分词规则、索引类型、字段格式等高级参数的支持
create table my_table (
name text (analyzer = ik_max_word),
dd text (index=no),
age long (include_in_all=false)
);
对象、嵌套字段支持 as
create table my_index (
id long,
name text,
obj object as (
first_name text,
second_name text (analyzer=pinyin)
)
);
create table my_index (
id long,
name text,
obj nested as (
first_name text,
second_name text (analyzer=pinyin)
)
);
ES索引高级参数支持 with option
create table my_index (
id long,
name text
) with option (
index.number_of_shards=10,
index.number_of_replicas = 1
);
#Insert/Bulk
单条数据插入
insert into my_index.index (name,age) values ('zhangsan',24);
多条插入
bulk into my_index.index (name,age) values ('zhangsan',24),('lisi',24);
对象数据插入,list,{}Map
insert into my_index.index (ds) values (['zhejiang','hangzhou']);
insert into my_index.index (dd) values ({address='zhejiang',postCode='330010'});
#select/Aggregations
select * from my_table.my_index where name like 'john *' and age between 20 and 30 and (hotel = 'hanting' or flight = 'MH4510');
地理位置中心点查询
select * from hz_point where geo_distance({distance='1km',location='30.306378,120.247427'});
地理坐标区域查询
select * from hz_point where geo_bounding_box({location={top_left='31.306378,119.247427',bottom_right='29.285797,122.172329'}});
pipeline统计 move_avg
select count(*) as total, moving_avg({buckets_path=total}) from my_index group by date_histogram({field=timestamp,interval='1h'});
Getting Started
环境要求python >= 2.7
export PYTHONHOME=(%python_path)
export PATH=$PYTHONHOME/bin:$PATH
安装第三方依赖包
pip install -r esql5.egg-info/requires.txt
或python setup.py install
运行esql5服务
(standalone):
cd esql5
python -m App.app
(with uwsgi)
cd esql5
uwsgi --ini conf/uwsgi.ini
shell终端:
python -m elsh.Command
esql
Git地址
https://github.com/unimassystem/esql5
Git地址
https://github.com/unimassystem/esql5
create table my_index.my_table (
id keyword,
name text,
age long,
birthday date
);
select * from my_index.my_type;
select count(*) from my_index.my_table group by age;
#Create table
字段参数,ES中分词规则、索引类型、字段格式等高级参数的支持
create table my_table (
name text (analyzer = ik_max_word),
dd text (index=no),
age long (include_in_all=false)
);
对象、嵌套字段支持 as
create table my_index (
id long,
name text,
obj object as (
first_name text,
second_name text (analyzer=pinyin)
)
);
create table my_index (
id long,
name text,
obj nested as (
first_name text,
second_name text (analyzer=pinyin)
)
);
ES索引高级参数支持 with option
create table my_index (
id long,
name text
) with option (
index.number_of_shards=10,
index.number_of_replicas = 1
);
#Insert/Bulk
单条数据插入
insert into my_index.index (name,age) values ('zhangsan',24);
多条插入
bulk into my_index.index (name,age) values ('zhangsan',24),('lisi',24);
对象数据插入,list,{}Map
insert into my_index.index (ds) values (['zhejiang','hangzhou']);
insert into my_index.index (dd) values ({address='zhejiang',postCode='330010'});
#select/Aggregations
select * from my_table.my_index where name like 'john *' and age between 20 and 30 and (hotel = 'hanting' or flight = 'MH4510');
地理位置中心点查询
select * from hz_point where geo_distance({distance='1km',location='30.306378,120.247427'});
地理坐标区域查询
select * from hz_point where geo_bounding_box({location={top_left='31.306378,119.247427',bottom_right='29.285797,122.172329'}});
pipeline统计 move_avg
select count(*) as total, moving_avg({buckets_path=total}) from my_index group by date_histogram({field=timestamp,interval='1h'});
Getting Started
环境要求python >= 2.7
export PYTHONHOME=(%python_path)
export PATH=$PYTHONHOME/bin:$PATH
安装第三方依赖包
pip install -r esql5.egg-info/requires.txt
或python setup.py install
运行esql5服务
(standalone):
cd esql5
python -m App.app
(with uwsgi)
cd esql5
uwsgi --ini conf/uwsgi.ini
shell终端:
python -m elsh.Command
收起阅读 »
用logstash导入ES且自定义mapping时踩的坑
问题发生背景:
1.本来我是使用logstash的默认配置向ES导入日志的。然后很嗨皮,发现一切OK,后来我开始对日志进行聚合统计,发现terms聚合时的key很奇怪,后来查询这奇怪的key,发现这些关键字都是源字符串的一段,而且全部复现场景都是出现"xxxx-xxxxxx"时就会截断,感觉像是分词器搞的鬼。所以想自己定制mapping。下面是原来的logstash配置
说干就干:
开始四处查阅文档,发现可以定制mapping,很开心。
}没有什么一帆风顺:
问题1:
但是我发现我已经上传了自定义的template,但是就是不能生效。
这时知道了,这个要设置order才能覆盖,默认的order是0,必须更大才行,参考
http://elasticsearch.cn/article/21
问题2:
我看到自己上传的template的order已经是1了,怎么还是不生效呢?
原来自己的索引名称不匹配自己的template的名称,所以不能使用,就又用了默认的template。
改成下面后OK,终于生效了。(注意index名称变化)output{
}问题3:
发现导入失败,原来自己的时间字符串不能用默认的date的format匹配,
如2017-04-11 00:07:25 不能用 { "type" : "date"} 的默认format匹配,
改成:"format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
这样就能解析了。
一切OK,谢谢社区,谢谢Google(你是我见过的除了书籍和老师之后最提升生产力的工具)
附上我的模板
继续阅读 »
1.本来我是使用logstash的默认配置向ES导入日志的。然后很嗨皮,发现一切OK,后来我开始对日志进行聚合统计,发现terms聚合时的key很奇怪,后来查询这奇怪的key,发现这些关键字都是源字符串的一段,而且全部复现场景都是出现"xxxx-xxxxxx"时就会截断,感觉像是分词器搞的鬼。所以想自己定制mapping。下面是原来的logstash配置
output{
elasticsearch{
action => "index"
hosts => ["xxxxxx:9200"]
index => "xxxxx"
document_type => "haha"
}
}
说干就干:
开始四处查阅文档,发现可以定制mapping,很开心。
output{
elasticsearch{
action => "index"
hosts => ["xxx"]
index => "logstashlog"
template => "xx/http-logstash.json"
template_name => "http-log-logstash"
template_overwrite => true
}
stdout{
codec => rubydebug
}
}没有什么一帆风顺:
问题1:
但是我发现我已经上传了自定义的template,但是就是不能生效。
这时知道了,这个要设置order才能覆盖,默认的order是0,必须更大才行,参考
http://elasticsearch.cn/article/21
问题2:
我看到自己上传的template的order已经是1了,怎么还是不生效呢?
原来自己的索引名称不匹配自己的template的名称,所以不能使用,就又用了默认的template。
改成下面后OK,终于生效了。(注意index名称变化)output{
elasticsearch{
action => "index"
hosts => ["xxx"]
index => "http-log-logstash"
document_type => "haha"
template => "xxx/http-logstash.json"
template_name => "http-log-logstash"
template_overwrite => true
}
stdout{
codec => rubydebug
}
}问题3:
发现导入失败,原来自己的时间字符串不能用默认的date的format匹配,
如2017-04-11 00:07:25 不能用 { "type" : "date"} 的默认format匹配,
改成:"format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
这样就能解析了。
一切OK,谢谢社区,谢谢Google(你是我见过的除了书籍和老师之后最提升生产力的工具)
附上我的模板
{
"template" : "qmpsearchlog",
"order":1,
"settings" : { "index.refresh_interval" : "60s" },
"mappings" : {
"_default_" : {
"_all" : { "enabled" : false },
"dynamic_templates" : [{
"message_field" : {
"match" : "message",
"match_mapping_type" : "string",
"mapping" : { "type" : "string", "index" : "not_analyzed" }
}
}, {
"string_fields" : {
"match" : "*",
"match_mapping_type" : "string",
"mapping" : { "type" : "string", "index" : "not_analyzed" }
}
}],
"properties" : {
"@timestamp" : { "type" : "date"},
"@version" : { "type" : "integer", "index" : "not_analyzed" },
"path" : { "type" : "string", "index" : "not_analyzed" },
"host" : { "type" : "string", "index" : "not_analyzed" },
"record_time":{"type":"date","format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
"method":{"type":"string","index" : "not_analyzed"},
"unionid":{"type":"string","index" : "not_analyzed"},
"user_name":{"type":"string","index" : "not_analyzed"},
"query":{"type":"string","index" : "not_analyzed"},
"ip":{ "type" : "ip"},
"webbrower":{"type":"string","index" : "not_analyzed"},
"os":{"type":"string","index" : "not_analyzed"},
"device":{"type":"string","index" : "not_analyzed"},
"ptype":{"type":"string","index" : "not_analyzed"},
"serarch_time":{"type":"date","format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
"have_ok":{"type":"string","index" : "not_analyzed"},
"legal":{"type":"string","index" : "not_analyzed"}
}
}
}
}
问题发生背景:
1.本来我是使用logstash的默认配置向ES导入日志的。然后很嗨皮,发现一切OK,后来我开始对日志进行聚合统计,发现terms聚合时的key很奇怪,后来查询这奇怪的key,发现这些关键字都是源字符串的一段,而且全部复现场景都是出现"xxxx-xxxxxx"时就会截断,感觉像是分词器搞的鬼。所以想自己定制mapping。下面是原来的logstash配置
说干就干:
开始四处查阅文档,发现可以定制mapping,很开心。
}没有什么一帆风顺:
问题1:
但是我发现我已经上传了自定义的template,但是就是不能生效。
这时知道了,这个要设置order才能覆盖,默认的order是0,必须更大才行,参考
http://elasticsearch.cn/article/21
问题2:
我看到自己上传的template的order已经是1了,怎么还是不生效呢?
原来自己的索引名称不匹配自己的template的名称,所以不能使用,就又用了默认的template。
改成下面后OK,终于生效了。(注意index名称变化)output{
}问题3:
发现导入失败,原来自己的时间字符串不能用默认的date的format匹配,
如2017-04-11 00:07:25 不能用 { "type" : "date"} 的默认format匹配,
改成:"format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
这样就能解析了。
一切OK,谢谢社区,谢谢Google(你是我见过的除了书籍和老师之后最提升生产力的工具)
附上我的模板
收起阅读 »
1.本来我是使用logstash的默认配置向ES导入日志的。然后很嗨皮,发现一切OK,后来我开始对日志进行聚合统计,发现terms聚合时的key很奇怪,后来查询这奇怪的key,发现这些关键字都是源字符串的一段,而且全部复现场景都是出现"xxxx-xxxxxx"时就会截断,感觉像是分词器搞的鬼。所以想自己定制mapping。下面是原来的logstash配置
output{
elasticsearch{
action => "index"
hosts => ["xxxxxx:9200"]
index => "xxxxx"
document_type => "haha"
}
}
说干就干:
开始四处查阅文档,发现可以定制mapping,很开心。
output{
elasticsearch{
action => "index"
hosts => ["xxx"]
index => "logstashlog"
template => "xx/http-logstash.json"
template_name => "http-log-logstash"
template_overwrite => true
}
stdout{
codec => rubydebug
}
}没有什么一帆风顺:
问题1:
但是我发现我已经上传了自定义的template,但是就是不能生效。
这时知道了,这个要设置order才能覆盖,默认的order是0,必须更大才行,参考
http://elasticsearch.cn/article/21
问题2:
我看到自己上传的template的order已经是1了,怎么还是不生效呢?
原来自己的索引名称不匹配自己的template的名称,所以不能使用,就又用了默认的template。
改成下面后OK,终于生效了。(注意index名称变化)output{
elasticsearch{
action => "index"
hosts => ["xxx"]
index => "http-log-logstash"
document_type => "haha"
template => "xxx/http-logstash.json"
template_name => "http-log-logstash"
template_overwrite => true
}
stdout{
codec => rubydebug
}
}问题3:
发现导入失败,原来自己的时间字符串不能用默认的date的format匹配,
如2017-04-11 00:07:25 不能用 { "type" : "date"} 的默认format匹配,
改成:"format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
这样就能解析了。
一切OK,谢谢社区,谢谢Google(你是我见过的除了书籍和老师之后最提升生产力的工具)
附上我的模板
{
"template" : "qmpsearchlog",
"order":1,
"settings" : { "index.refresh_interval" : "60s" },
"mappings" : {
"_default_" : {
"_all" : { "enabled" : false },
"dynamic_templates" : [{
"message_field" : {
"match" : "message",
"match_mapping_type" : "string",
"mapping" : { "type" : "string", "index" : "not_analyzed" }
}
}, {
"string_fields" : {
"match" : "*",
"match_mapping_type" : "string",
"mapping" : { "type" : "string", "index" : "not_analyzed" }
}
}],
"properties" : {
"@timestamp" : { "type" : "date"},
"@version" : { "type" : "integer", "index" : "not_analyzed" },
"path" : { "type" : "string", "index" : "not_analyzed" },
"host" : { "type" : "string", "index" : "not_analyzed" },
"record_time":{"type":"date","format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
"method":{"type":"string","index" : "not_analyzed"},
"unionid":{"type":"string","index" : "not_analyzed"},
"user_name":{"type":"string","index" : "not_analyzed"},
"query":{"type":"string","index" : "not_analyzed"},
"ip":{ "type" : "ip"},
"webbrower":{"type":"string","index" : "not_analyzed"},
"os":{"type":"string","index" : "not_analyzed"},
"device":{"type":"string","index" : "not_analyzed"},
"ptype":{"type":"string","index" : "not_analyzed"},
"serarch_time":{"type":"date","format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
"have_ok":{"type":"string","index" : "not_analyzed"},
"legal":{"type":"string","index" : "not_analyzed"}
}
}
}
}
收起阅读 »
jiakechong1642 发表于 : 2017-04-26 16:14
评论 (5)
社区网站服务器迁移完毕
感谢 ConvertLab 为本站提供服务器,目前服务器已经迁移完毕,大家可以感受一下速度!
同时感谢在此之前为本站提供网站空间的:谱时
社区账号也支持 Github 绑定了。
感谢大家一路支持,社区有你更精彩。
感谢 ConvertLab 为本站提供服务器,目前服务器已经迁移完毕,大家可以感受一下速度!
同时感谢在此之前为本站提供网站空间的:谱时
社区账号也支持 Github 绑定了。
感谢大家一路支持,社区有你更精彩。 收起阅读 »
ELK学习资料整理
刚开始学习使用ELK,整理一个学习资料列表,当做备忘录。
1.第一个当然是官方文档
2.中文文档
欢迎补充……
继续阅读 »
1.第一个当然是官方文档
- ElasticSearch参考手册,学习 DSL查询语法,包括查找(query)、过滤(filter)和聚合(aggs)等。
- Logstash参考手册,学习数据导入,包括输入(input)、过滤(filter)和输出( output)等,主要是filter中如何对复杂文本 进行拆分和类型 转化。
- Kibana参考手册,使用Kibana提供的前端界面对数据进行快速展示,主要是对Visulize 模块的使
2.中文文档
- ElasticSearch
- Logstash:Logstash 最佳实践,ELKStack中文指南
- Kibana:ELKStack中文指南
欢迎补充……
刚开始学习使用ELK,整理一个学习资料列表,当做备忘录。
1.第一个当然是官方文档
2.中文文档
欢迎补充…… 收起阅读 »
1.第一个当然是官方文档
- ElasticSearch参考手册,学习 DSL查询语法,包括查找(query)、过滤(filter)和聚合(aggs)等。
- Logstash参考手册,学习数据导入,包括输入(input)、过滤(filter)和输出( output)等,主要是filter中如何对复杂文本 进行拆分和类型 转化。
- Kibana参考手册,使用Kibana提供的前端界面对数据进行快速展示,主要是对Visulize 模块的使
2.中文文档
- ElasticSearch
- Logstash:Logstash 最佳实践,ELKStack中文指南
- Kibana:ELKStack中文指南
欢迎补充…… 收起阅读 »
logstash多时间(date)字段文档导入
我们都知道如果文档中有表示时间的字段时可以用如下方法将字段转化为date(timestamp)格式导入
继续阅读 »
date {
match => [ "submission_time", "yyyyMMdd" ]
}
但是如果一条记录中有多个字段需要使用date类型呢?有人遇到了 同样的问题How to parse multiple date fields?其实多次使用date{}语法就行了,例如:date {
match => [ "submission_time", "UNIX_MS" ]
target => "@timestamp"
}
date {
match => [ "submission_time", "UNIX_MS" ]
target => "submission_time"
}
date {
match => [ "start_time", "UNIX_MS" ]
target => "start_time"
}
date {
match => [ "end_time", "UNIX_MS" ]
target => "end_time"
}
查看官方文档后, 发现一直使用的date是省去了参数target的,而target默认值为@timestamp。
我们都知道如果文档中有表示时间的字段时可以用如下方法将字段转化为date(timestamp)格式导入
date {
match => [ "submission_time", "yyyyMMdd" ]
}
但是如果一条记录中有多个字段需要使用date类型呢?有人遇到了 同样的问题How to parse multiple date fields?其实多次使用date{}语法就行了,例如:date {
match => [ "submission_time", "UNIX_MS" ]
target => "@timestamp"
}
date {
match => [ "submission_time", "UNIX_MS" ]
target => "submission_time"
}
date {
match => [ "start_time", "UNIX_MS" ]
target => "start_time"
}
date {
match => [ "end_time", "UNIX_MS" ]
target => "end_time"
}
查看官方文档后, 发现一直使用的date是省去了参数target的,而target默认值为@timestamp。 收起阅读 »