ElasticSearch

背景 日志系统接入的日志种类多、格式复杂多样，主流的有以下几种日志： filebeat采集到的文本日志，格式多样 winbeat采集到的操作系统日志 设备上报到logstash的syslog日志 接入到kafka的业务日志 以上通过各种渠道接入的日志，存在2个主要的问题： 格式不统一、不规范、标准化不够 如何从各类日志中提取出用户关心的指标，挖掘更多的业务价值 为了解决上面2个问题，我们基于flink和drools规则引擎做了实时的日志处理服务。 系统架构 架构比较简单，架构图如下： 各类日志都是通过kafka汇总，做日志中转。 flink消费kafka的数据，同时通过API调用拉取drools规则引擎，对日志做解析处理后，将解析后的数据存储到Elasticsearch中，用于日志的搜索和分析等业务。 为了监控日志解析的实时状态，flink会将日志处理的统计数据，如每分钟处理的日志量，每种日志从各个机器IP来的日志量写到Redis中，用于监控统计。 模块介绍 系统项目命名为eagle。 eagle-api：基于springboot，作为drools规则引擎的写入和读取API服务。 eagle-common：通用类模块。 eagle-log：基于flink的日志处理服务。 重点讲一下eagle-log： 对接kafka、ES和Redis 对接kafka和ES都比较简单

原文: Docker安装Skywalking APM分布式追踪系统 Skywalking简单介绍 　　Skywalking是一个应用性能管理(APM)系统，具有服务器性能监测，应用程序间调用关系及性能监测等功能，Skywalking分为服务端、管理界面、以及嵌入到程序中的探针部分，由程序中的探针采集各类调用数据发送给服务端保存，在管理界面上可以查看各类性能数据。本文介绍服务端及管理界面的安装。 环境介绍 　　本文使用虚拟机unbutu18+docker。本unbutu18系统IP地址为： 192.168.150.134 大家在使用时记得将此地址换成自己的实际地址。 　　docker的安装可参考： https://www.cnblogs.com/sunyuliang/p/11422674.html Skywalking安装 　　 1：安装服务端： 这里介绍服务端的两种存储等式，一种是默认的H2存储，即数据存储在内存中，一种是使用elasticsearch存储，大家可以任选1.1或1.2其中一种安装方式 1.1 ：默认H2存储 　　　　　输入以下命令，并耐心待下载。 　　　　　 sudo docker run --name skywalking -d -p 1234 : 1234 -p 11800 : 11800 -p 12800 : 12800 --restart always

点击上方蓝色“ 程序猿DD ”，选择“设为星标” 回复“ 资源 ”获取独家整理的学习资料！ 作者 | linkt1234 来源 | https://blog.csdn.net/Linkthaha/article/details/100575278 最近，在对公司容器云的日志方案进行设计的时候，发现主流的ELK或者EFK比较重，再加上现阶段对于ES复杂的搜索功能很多都用不上最终选择了Grafana开源的Loki日志系统，下面介绍下Loki的背景。 背景和动机 当我们的容器云运行的应用或者某个节点出现问题了，解决思路应该如下： 我们的监控使用的是基于prometheus体系进行改造的，prometheus中比较重要的是metric和alert,metric是来说明当前或者历史达到了某个值，alert设置metric达到某个特定的基数触发了告警，但是这些信息明显是不够的。我们都知道，k8s的基本单位是pod,pod把日志输出到stdout和stderr,平时有什么问题我们通常在界面或者通过命令查看相关的日志,举个例子：当我们的某个pod的内存变得很大，触发了我们的alert，这个时候管理员，去页面查询确认是哪个pod有问题，然后要确认pod内存变大的原因，我们还需要去查询pod的日志，如果没有日志系统，那么我们就需要到页面或者使用命令进行查询了： 如果，这个时候应用突然挂了

注意：在下载tar包的时候需要注意下安装的es版本号，按照官网的说明版本是对应一致的。 #下载tar包 $ wget https://artifacts.elastic.co/downloads/kibana/kibana-6.2.2-linux-x86_64.tar.gz #解压tar包 $ tar -xzf kibana-6.2.2-linux-x86_64.tar.gz 编辑配置文件 $ vim /home/es/kibana-6.2.2-linux-x86_64/config/kibana.yml server.port: 5601 server.host: "0.0.0.0" #外网访问 elasticsearch.url: "http://localhost:9200" #启动kibana $ ./home/es/kibana-6.2.2-linux-x86_64/bin/kibana #后台启动kibana $ nohup ./kibana & #查看log命令 $ tail -f nohup.out kibana访问地址 http://127.0.0.1:5601/ 来源： oschina 链接： https://my.oschina.net/u/4418120/blog/3576082

目录 骚年被解析成了骚 我们需要解析为骚年 在同级目录之下创建一个文件 这个文件就是词典 自定义词典 custom.dic 重启es 骚年 开源中国 已被分词 骚年被解析成了骚 我们需要解析为骚年 { "tokens": [ { "token": "骚", "start_offset": 0, "end_offset": 1, "type": "CN_CHAR", "position": 0 }, { "token": "年在", "start_offset": 1, "end_offset": 3, "type": "CN_WORD", "position": 1 }, { "token": "开源", "start_offset": 3, "end_offset": 5, "type": "CN_WORD", "position": 2 }, { "token": "中国学", "start_offset": 5, "end_offset": 8, "type": "CN_WORD", "position": 3 }, { "token": "中国", "start_offset": 5, "end_offset": 7, "type": "CN_WORD", "position": 4 }, { "token": "国学", "start_offset": 6, "end

MQ理论介绍 一、为什么需要消息队列(MQ) 主要原因是由于在高并发环境下，同步请求来不及处理，请求往往会发生阻塞。大量的请求到达访问数据库，导致行锁表锁，最后请求线程会堆积过多，从而触发 too many connection错误，引发雪崩效应。我们使用消息队列，通过异步处理请求，从而缓解系统的压力。核心：异步处理、流量削峰、应用解耦 二、应用场景 异步处理，流量削峰，应用解耦，消息通讯四个场景 2.1、异步处理 场景1：用户注册后，需要发送注册邮件和注册短信。 串行方式：将注册信息写入 数据库 成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端 并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。 因为CPU在单位时间内处理的请求数是一定的，假设CPU在1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。 并行方式处理的请求量是10次（1000/100） 小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题？ 引入消息队列，将不是必须的业务逻辑，异步处理