用了Elasticsearch,一口气上5T

INFINI Gateway 的使用方法和使用心得分享

本文主要分享一下大神Medcl开发的INFINI Gateway的使用方法和使用心得,当然可能由于研究得不够深入某些地方理解肤浅甚至说的根本就是错的也请Medcl大神和各位专家大佬能够多多包涵,下面详细对我使用INFINI Gateway的经验进行一下分享。
安装部署
安装部署非常简单,INFINI Gateway使用go语言进行编写,linux系统基本不需要安装任何其他依赖,直接从github上下载解压即可使用,由于需要反复重启调试,同时网关需要具备进程保护功能,我使用了supervisord进行纳管,supervisord安装部署我在此省略,有兴趣的同学直接网上搜索即可。Supervisord配置文件如下:
[program:gateway]
command = /app/logger/gateway/gateway-linux64
username = appuser
autostart=false
autorestart=true
startsecs=3
priority=1007
stdout_logfile=/app/logger/gateway/log/infini_gateway.log
注意这里由于我的测试服务器kibana、gateway和es节点都部署在一起,统一都是用supervisord进行纳管,由于网关必须等到es节点启动以后才可以启动成功,所以将gateway 的autostart设置为false。另外网关节点由于流量、资源不足等问题会有一定风险自己挂掉(测试过程中就遇到过),所以推荐将autorestart设置为true,当网关节点意外挂掉以后能够马上重启不影响应用使用。
配置文件
这块可能是我比较重点想分享的地方,因为可能由于目前项目刚刚发布,medcl大神一直忙于功能开发无暇顾及使用说明的介绍(我妄自揣测,请medcl大神不要见怪^_^),所以配置文件目前在安装介质中只有一个模板,外加模板中的一些参数注释的介绍,可能对于新手进行配置还是有比较大的难度(比如我),所以在自己摸索外加medcl大神的指导下我初步成功配置并实现了预期效果,现在分享给大家。
Path模块:
path.data: data
path.logs: log
这块没什么好说的,就是这是data和log的相对路径,一般也不要改
entry模块:
entry:
- name: es_gateway #your gateway endpoint
enable: true
router: default #configure your gateway's routing flow
network:
binding: 0.0.0.0:8000
reuse_port: true #you can start multi gateway instance, they share same port, to full utilize system's resources
tls:
enabled: false #if your es is using https, the gateway entrypoint should enable https too
这里实际上就是定义gateway的总体模块,指定了gateway网关名字,绑定的地址端口和网关是否启用的开关,这个开关就是指enable参数,我发现后面的版本有的模板文件中是不带enable这个参数的,这里其实有问题,因为测试时发现如果不设置enable为true的话默认值时false,也就是说网关不生效,为了当时排查这个问题我花了不少时间。这里划重点哈,entry模块里定义最重要的参数就是router,也就是网关gateway的路由策略。gateway的配置文件包含关系是这样的,gateway的entry指定了router,router中指定了tracing_flow和default_flow以及默认flow选择策略,tracing_flow是指定网关自己的流,也就是网关监控的流的处理逻辑,和业务查询和写入是无关的,default_flow实际上是真实网关的业务流,这个流一定是要走cache的。然后flow里面才会包含filter,filter顾名思义就是网关流的过滤筛选条件,filter里会有cache逻辑、rate限流条件、filter条件、elasticsearch属性。因为网关的监控数据要单独向es写入,需要设置一些写入属性和参数,所以需要module模块去指定模板、运行态参数和pipeline,然后再pipeline模块中指定写入es属性,包括es地址、索引名、队列名、worksize、bulksize等等,另外网关自己的一些队列参数设置在queue模块中,网关监控信息参数设置在statsd模块中。
flow模块:
- name: cache_first
filter: #comment out any filter sections, like you don't need cache or rate-limiter
- name: get_cache_1
type: get_cache
- name: rate_limit_1
type: rate_limit
parameters:
message: "Hey, You just reached our request limit!"
rules: #configure match rules against request's PATH, eg: /_cluster/health, match the first rule and return
- pattern: "/(?P<index_name>test.*?)/_search" #use regex pattern to match index, will match any /$index/_search, and limit each index with max_qps ~=100
max_qps: 1000
group: index_name
- name: elasticsearch_1
type: elasticsearch
parameters:
elasticsearch: default #elasticsearch configure reference name
max_connection: 1000 #max tcp connection to upstream, default for all nodes
max_response_size: -1 #default for all nodes
balancer: weight
- host: 192.168.3.201:9200 #the format is host:port
weight: 100
- host: 192.168.3.202:9200
weight: 100
discovery:
enabled: false
- name: set_cache_1
type: set_cache
parameters:
cache_ttl: 1000s
# max_cache_items: 100000
- name: request_logging # this flow is used for request logging, refer to `router`'s `tracing_flow`
filter:
- name: request_path_filter_1
type: request_path_filter
parameters:
must: #must match all rules to continue
prefix:
- /test
- name: request_logging_1
type: request_logging
parameters:
queue_name: request_logging
如上,flow模块就是定义了两个flow,一个是cache_first,一个是request_logging,cache_first是承接业务流,所以在filter中一定要设置get_cache和set_cache强制走缓存策略,这里注意set_cache中要有缓存失效时间cache_ttl,默认是10s,这个我根据我的业务需求直接增加到了1000s,因为我想将缓存多保留一段时间,max_cache_items我直接注释掉了,不限制缓存数量的大小,如果一定要设置这个值要注意一下这个值针对的是每一个查询语句的而不是总共的。另外在cache_first中可以设置限流策略,/(?P<index_name>test.*?)表示test开头的索引全部应用限流策略。这里还有一个关键点是指定elasticsearch地址时可以配置连接权重,这个参数对我还是蛮有用的,因为我想我的应用查询通过网关只从coor节点进入而不是datanode和masternode,做到读写节点分离同时降低大查询灾难蔓延扩散的风险。所以我会将es集群中两个coor节点配置到这里,weight尽量设置的大一点,这里要注意如果这样配置必须把discovery的enable设置为false,否则网关还是会从master或者data节点进入。
request_logging的流其实就是网关trace监控自己用的,由于后面进行了filter强匹配,所以采样sample参数我就没有配置。注意这里其实我们在cache_first中并没有配置filter规则,所以这里任何过网关的查询都会进入缓存,包括查询tracing_flow自己创建的索引。在request_logging尽量按照自己的需求去配置一些filter规则来减少监控写入的索引,如果不配置,写入的量级会非常多,后续用仪表盘进行监控时响应会非常慢。目前gateway网关支持的filter类型非常全面,包括request_path_filter根据索引名或者路径去筛选,request_header_filter根据请求头部信息去筛选索引,request_method_filter根据请求的方法类型去筛选,注意如果使用request_header_filter根据请求头部信息去筛选索引,需要在应用在请求的头里加入特殊标识,比如如果要通过request_header_filter方式把所有kibana的请求全部过滤掉,就需要在kibana配置文件中增加头部参数并自定义值:
elasticsearch.customHeaders: { "app": "kibana" }
然后在request_header_filter中加过滤条件:
- name: request_header_filter1 # filter out the requests that we are not interested, reduce tracing pressure
type: request_header_filter
parameters:
exclude: # any rule match will marked request as filtered
- app: kibana # in order to filter kibana's access log, config `elasticsearch.customHeaders: { "app": "kibana" }` to your kibana's config `/config/kibana.yml`
我目前的需求是只想监控某些固定索引前缀的请求,所以我只配置了request_path_filter并must强配置了比如test索引前缀的索引,这样已经满足我得需求并最大限度的减少了监控请求数量。
这里还有一个点,就是在filter类型中还有个特殊的类型,叫做request_logging,这个是专门针对tracing_flow设计的,其中有一个重要参数是queue_name,他会在gateway网关所在的服务器磁盘上创建一个队列用来加速写入,减少tracing_flow对网关所造成的性能影响,所以这个队列在这里创建之后会在后面的pipelines中去指定写入磁盘队列。
router模块:
router:
- name: default
tracing_flow: request_logging #a flow will execute after request finish
default_flow: cache_first
rules: #rules can't be conflicted with each other, will be improved in the future
- id: 1 # this rule means match every requests, and sent to `cache_first` flow
method:
- "*"
pattern:
- /
# priority: 1
flow:
- cache_first # after match, which processing flow will go through
router模块最重要的就是指定了tracing_flow和default_flow,这里可以定义路由规则,按照默认全部匹配就走缓存可以,同时最后在flow参数指定默认要走的flow流,也就是cache_first业务请求流。
elasticsearch模块:
elasticsearch:
- name: default
enabled: true
endpoint: http://localhost:9200 # if your elasticsearch is using https, your gateway should be listen on as https as well
version: 7.9.1 #optional, used to select es adaptor, can be done automatically after connect to es
index_prefix: gateway_
basic_auth: #used to discovery full cluster nodes, or check elasticsearch's health and versions
username: elastic
password: pass
这里需要指定es地址和端口,可以配置多个,也就是说可以将业务的es和监控索引存储的es进行分离,这里有个参数index_prefix,我的理解是这个会在kibana中去创建这个索引模式,用来后续进行仪表盘监控,但是真实测试结果是这个设置没有生效,索引模式前缀都是gateway_requests,这个可能需要后续和Medcl大神再确认一下。
modules模块:
modules:
- name: elastic
enabled: true
elasticsearch: default
init_template: true
- name: pipeline
enabled: true
runners:
- name: primary
enabled: true
max_go_routine: 1
threshold_in_ms: 0
timeout_in_ms: 5000
pipeline_id: request_logging_index
modules需要配置两个模块,一个是es模块,一个是pipeline模块,主要是为
request_logging要往es中写数做准备,es模块使用默认模板,pipeline设置一些写入需要的参数,我全部没改使用默认值。
pipelines模块:
pipelines:
- name: request_logging_index
start:
joint: json_indexing
enabled: true
parameters:
index_name: "gateway_requests"
elasticsearch: "default"
input_queue: "request_logging"
timeout: "60s"
worker_size: 1
bulk_size_in_mb: 10 #in MB
process:
因为要向es中写入trace数据,所以需要在pipeline中配置写入参数,包括json方式传输,写入的es(如果es有多个需要拆分),使用的磁盘队列queue,超时时间,写入worker数以及bulksize,这个我觉得后续可以根据监控的量级进行优化。
queue模块:
queue:
min_msg_size: 1
max_msg_size: 50000000
max_bytes_per_file: 53687091200
sync_every_records: 100000 # sync by records count
sync_timeout_in_ms: 10000 # sync by time in million seconds
read_chan_buffer: 0
这个就是那个trace数据本次磁盘队列的一些写入参数,包括消息大小,磁盘文件大小,同步消息数,read buffer等等,如果像我目前的应用场景已经严格匹配索引的量级有限可以不用改,但是我觉得默认max_bytes_per_file默认值是50G,这个我觉得单个文件有点大,生产环境可以考虑调小。
statsd模块:
enabled: false
host: 127.0.0.1
port: 8125
namespace: gateway.
这个模块目前我没用到,应该是本身监控gateway状态的模块,指定了监控端口,后续可以进行验证。
使用对比结果:
通过gateway中自带仪表盘可以对使用情况和效果进行方便的监控,通过比对可以发现一条复用的查询语句走网关缓存和不走网关缓存性能差距在100倍以上,使用网关进行查询优势巨大特别明显。

网关截图.png


未来展望:
首先感谢Medcl大神把这么好的东西发布出来,使用网关对于业务查询有百倍上的性能提升确实十分诱人。而且目前虽然INFINI Gateway刚刚发布出来,但是已经陆陆续续迭代了好几个版本,可以明显看到一些bug修复、功能增强和性能优化提高,目前最新的版本又增加了请求灰度切换、流量迁移和流量复制功能,可以实现双写和多写,这个功能对于我来说后续很可能会应用到,因为实际上是一种变相的多集群数据同步方式的实现。所以可以看出INFINI Gateway网关不仅仅定位于查询缓存网关,而是集查询和写入功能为一体的综合性大网关,期待Medcl大神后续的精彩表演,让我们拭目以待。
继续阅读 »
本文主要分享一下大神Medcl开发的INFINI Gateway的使用方法和使用心得,当然可能由于研究得不够深入某些地方理解肤浅甚至说的根本就是错的也请Medcl大神和各位专家大佬能够多多包涵,下面详细对我使用INFINI Gateway的经验进行一下分享。
安装部署
安装部署非常简单,INFINI Gateway使用go语言进行编写,linux系统基本不需要安装任何其他依赖,直接从github上下载解压即可使用,由于需要反复重启调试,同时网关需要具备进程保护功能,我使用了supervisord进行纳管,supervisord安装部署我在此省略,有兴趣的同学直接网上搜索即可。Supervisord配置文件如下:
[program:gateway]
command = /app/logger/gateway/gateway-linux64
username = appuser
autostart=false
autorestart=true
startsecs=3
priority=1007
stdout_logfile=/app/logger/gateway/log/infini_gateway.log
注意这里由于我的测试服务器kibana、gateway和es节点都部署在一起,统一都是用supervisord进行纳管,由于网关必须等到es节点启动以后才可以启动成功,所以将gateway 的autostart设置为false。另外网关节点由于流量、资源不足等问题会有一定风险自己挂掉(测试过程中就遇到过),所以推荐将autorestart设置为true,当网关节点意外挂掉以后能够马上重启不影响应用使用。
配置文件
这块可能是我比较重点想分享的地方,因为可能由于目前项目刚刚发布,medcl大神一直忙于功能开发无暇顾及使用说明的介绍(我妄自揣测,请medcl大神不要见怪^_^),所以配置文件目前在安装介质中只有一个模板,外加模板中的一些参数注释的介绍,可能对于新手进行配置还是有比较大的难度(比如我),所以在自己摸索外加medcl大神的指导下我初步成功配置并实现了预期效果,现在分享给大家。
Path模块:
path.data: data
path.logs: log
这块没什么好说的,就是这是data和log的相对路径,一般也不要改
entry模块:
entry:
- name: es_gateway #your gateway endpoint
enable: true
router: default #configure your gateway's routing flow
network:
binding: 0.0.0.0:8000
reuse_port: true #you can start multi gateway instance, they share same port, to full utilize system's resources
tls:
enabled: false #if your es is using https, the gateway entrypoint should enable https too
这里实际上就是定义gateway的总体模块,指定了gateway网关名字,绑定的地址端口和网关是否启用的开关,这个开关就是指enable参数,我发现后面的版本有的模板文件中是不带enable这个参数的,这里其实有问题,因为测试时发现如果不设置enable为true的话默认值时false,也就是说网关不生效,为了当时排查这个问题我花了不少时间。这里划重点哈,entry模块里定义最重要的参数就是router,也就是网关gateway的路由策略。gateway的配置文件包含关系是这样的,gateway的entry指定了router,router中指定了tracing_flow和default_flow以及默认flow选择策略,tracing_flow是指定网关自己的流,也就是网关监控的流的处理逻辑,和业务查询和写入是无关的,default_flow实际上是真实网关的业务流,这个流一定是要走cache的。然后flow里面才会包含filter,filter顾名思义就是网关流的过滤筛选条件,filter里会有cache逻辑、rate限流条件、filter条件、elasticsearch属性。因为网关的监控数据要单独向es写入,需要设置一些写入属性和参数,所以需要module模块去指定模板、运行态参数和pipeline,然后再pipeline模块中指定写入es属性,包括es地址、索引名、队列名、worksize、bulksize等等,另外网关自己的一些队列参数设置在queue模块中,网关监控信息参数设置在statsd模块中。
flow模块:
- name: cache_first
filter: #comment out any filter sections, like you don't need cache or rate-limiter
- name: get_cache_1
type: get_cache
- name: rate_limit_1
type: rate_limit
parameters:
message: "Hey, You just reached our request limit!"
rules: #configure match rules against request's PATH, eg: /_cluster/health, match the first rule and return
- pattern: "/(?P<index_name>test.*?)/_search" #use regex pattern to match index, will match any /$index/_search, and limit each index with max_qps ~=100
max_qps: 1000
group: index_name
- name: elasticsearch_1
type: elasticsearch
parameters:
elasticsearch: default #elasticsearch configure reference name
max_connection: 1000 #max tcp connection to upstream, default for all nodes
max_response_size: -1 #default for all nodes
balancer: weight
- host: 192.168.3.201:9200 #the format is host:port
weight: 100
- host: 192.168.3.202:9200
weight: 100
discovery:
enabled: false
- name: set_cache_1
type: set_cache
parameters:
cache_ttl: 1000s
# max_cache_items: 100000
- name: request_logging # this flow is used for request logging, refer to `router`'s `tracing_flow`
filter:
- name: request_path_filter_1
type: request_path_filter
parameters:
must: #must match all rules to continue
prefix:
- /test
- name: request_logging_1
type: request_logging
parameters:
queue_name: request_logging
如上,flow模块就是定义了两个flow,一个是cache_first,一个是request_logging,cache_first是承接业务流,所以在filter中一定要设置get_cache和set_cache强制走缓存策略,这里注意set_cache中要有缓存失效时间cache_ttl,默认是10s,这个我根据我的业务需求直接增加到了1000s,因为我想将缓存多保留一段时间,max_cache_items我直接注释掉了,不限制缓存数量的大小,如果一定要设置这个值要注意一下这个值针对的是每一个查询语句的而不是总共的。另外在cache_first中可以设置限流策略,/(?P<index_name>test.*?)表示test开头的索引全部应用限流策略。这里还有一个关键点是指定elasticsearch地址时可以配置连接权重,这个参数对我还是蛮有用的,因为我想我的应用查询通过网关只从coor节点进入而不是datanode和masternode,做到读写节点分离同时降低大查询灾难蔓延扩散的风险。所以我会将es集群中两个coor节点配置到这里,weight尽量设置的大一点,这里要注意如果这样配置必须把discovery的enable设置为false,否则网关还是会从master或者data节点进入。
request_logging的流其实就是网关trace监控自己用的,由于后面进行了filter强匹配,所以采样sample参数我就没有配置。注意这里其实我们在cache_first中并没有配置filter规则,所以这里任何过网关的查询都会进入缓存,包括查询tracing_flow自己创建的索引。在request_logging尽量按照自己的需求去配置一些filter规则来减少监控写入的索引,如果不配置,写入的量级会非常多,后续用仪表盘进行监控时响应会非常慢。目前gateway网关支持的filter类型非常全面,包括request_path_filter根据索引名或者路径去筛选,request_header_filter根据请求头部信息去筛选索引,request_method_filter根据请求的方法类型去筛选,注意如果使用request_header_filter根据请求头部信息去筛选索引,需要在应用在请求的头里加入特殊标识,比如如果要通过request_header_filter方式把所有kibana的请求全部过滤掉,就需要在kibana配置文件中增加头部参数并自定义值:
elasticsearch.customHeaders: { "app": "kibana" }
然后在request_header_filter中加过滤条件:
- name: request_header_filter1 # filter out the requests that we are not interested, reduce tracing pressure
type: request_header_filter
parameters:
exclude: # any rule match will marked request as filtered
- app: kibana # in order to filter kibana's access log, config `elasticsearch.customHeaders: { "app": "kibana" }` to your kibana's config `/config/kibana.yml`
我目前的需求是只想监控某些固定索引前缀的请求,所以我只配置了request_path_filter并must强配置了比如test索引前缀的索引,这样已经满足我得需求并最大限度的减少了监控请求数量。
这里还有一个点,就是在filter类型中还有个特殊的类型,叫做request_logging,这个是专门针对tracing_flow设计的,其中有一个重要参数是queue_name,他会在gateway网关所在的服务器磁盘上创建一个队列用来加速写入,减少tracing_flow对网关所造成的性能影响,所以这个队列在这里创建之后会在后面的pipelines中去指定写入磁盘队列。
router模块:
router:
- name: default
tracing_flow: request_logging #a flow will execute after request finish
default_flow: cache_first
rules: #rules can't be conflicted with each other, will be improved in the future
- id: 1 # this rule means match every requests, and sent to `cache_first` flow
method:
- "*"
pattern:
- /
# priority: 1
flow:
- cache_first # after match, which processing flow will go through
router模块最重要的就是指定了tracing_flow和default_flow,这里可以定义路由规则,按照默认全部匹配就走缓存可以,同时最后在flow参数指定默认要走的flow流,也就是cache_first业务请求流。
elasticsearch模块:
elasticsearch:
- name: default
enabled: true
endpoint: http://localhost:9200 # if your elasticsearch is using https, your gateway should be listen on as https as well
version: 7.9.1 #optional, used to select es adaptor, can be done automatically after connect to es
index_prefix: gateway_
basic_auth: #used to discovery full cluster nodes, or check elasticsearch's health and versions
username: elastic
password: pass
这里需要指定es地址和端口,可以配置多个,也就是说可以将业务的es和监控索引存储的es进行分离,这里有个参数index_prefix,我的理解是这个会在kibana中去创建这个索引模式,用来后续进行仪表盘监控,但是真实测试结果是这个设置没有生效,索引模式前缀都是gateway_requests,这个可能需要后续和Medcl大神再确认一下。
modules模块:
modules:
- name: elastic
enabled: true
elasticsearch: default
init_template: true
- name: pipeline
enabled: true
runners:
- name: primary
enabled: true
max_go_routine: 1
threshold_in_ms: 0
timeout_in_ms: 5000
pipeline_id: request_logging_index
modules需要配置两个模块,一个是es模块,一个是pipeline模块,主要是为
request_logging要往es中写数做准备,es模块使用默认模板,pipeline设置一些写入需要的参数,我全部没改使用默认值。
pipelines模块:
pipelines:
- name: request_logging_index
start:
joint: json_indexing
enabled: true
parameters:
index_name: "gateway_requests"
elasticsearch: "default"
input_queue: "request_logging"
timeout: "60s"
worker_size: 1
bulk_size_in_mb: 10 #in MB
process:
因为要向es中写入trace数据,所以需要在pipeline中配置写入参数,包括json方式传输,写入的es(如果es有多个需要拆分),使用的磁盘队列queue,超时时间,写入worker数以及bulksize,这个我觉得后续可以根据监控的量级进行优化。
queue模块:
queue:
min_msg_size: 1
max_msg_size: 50000000
max_bytes_per_file: 53687091200
sync_every_records: 100000 # sync by records count
sync_timeout_in_ms: 10000 # sync by time in million seconds
read_chan_buffer: 0
这个就是那个trace数据本次磁盘队列的一些写入参数,包括消息大小,磁盘文件大小,同步消息数,read buffer等等,如果像我目前的应用场景已经严格匹配索引的量级有限可以不用改,但是我觉得默认max_bytes_per_file默认值是50G,这个我觉得单个文件有点大,生产环境可以考虑调小。
statsd模块:
enabled: false
host: 127.0.0.1
port: 8125
namespace: gateway.
这个模块目前我没用到,应该是本身监控gateway状态的模块,指定了监控端口,后续可以进行验证。
使用对比结果:
通过gateway中自带仪表盘可以对使用情况和效果进行方便的监控,通过比对可以发现一条复用的查询语句走网关缓存和不走网关缓存性能差距在100倍以上,使用网关进行查询优势巨大特别明显。

网关截图.png


未来展望:
首先感谢Medcl大神把这么好的东西发布出来,使用网关对于业务查询有百倍上的性能提升确实十分诱人。而且目前虽然INFINI Gateway刚刚发布出来,但是已经陆陆续续迭代了好几个版本,可以明显看到一些bug修复、功能增强和性能优化提高,目前最新的版本又增加了请求灰度切换、流量迁移和流量复制功能,可以实现双写和多写,这个功能对于我来说后续很可能会应用到,因为实际上是一种变相的多集群数据同步方式的实现。所以可以看出INFINI Gateway网关不仅仅定位于查询缓存网关,而是集查询和写入功能为一体的综合性大网关,期待Medcl大神后续的精彩表演,让我们拭目以待。 收起阅读 »

社区日报 第1142期 (2020-12-18)

1、Elasticsearch集群多可用区容灾实现原理及最佳实践
https://mp.weixin.qq.com/s/7VzmoK4ZsVfnJflEs_B9tA
2、为博客添加Elasticsearch引擎
https://blog.lsonline.fr/2020/ ... blog/
3、Elasticsearch最佳实践
https://blockgeni.com/best-pra ... arch/
 
编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1、Elasticsearch集群多可用区容灾实现原理及最佳实践
https://mp.weixin.qq.com/s/7VzmoK4ZsVfnJflEs_B9tA
2、为博客添加Elasticsearch引擎
https://blog.lsonline.fr/2020/ ... blog/
3、Elasticsearch最佳实践
https://blockgeni.com/best-pra ... arch/
 
编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

社区日报 第1141期 (2020-12-17)

1.记录一次filebeat日志丢失的问题
https://www.jianshu.com/p/2bfd2d633f0c
2.Elasticsearch-CCR源码剖析
https://www.jianshu.com/p/b9169d1b6791
3.ElasticSearch读写底层原理及性能调优
https://my.oschina.net/wangzhi ... 09389

编辑:金桥
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1.记录一次filebeat日志丢失的问题
https://www.jianshu.com/p/2bfd2d633f0c
2.Elasticsearch-CCR源码剖析
https://www.jianshu.com/p/b9169d1b6791
3.ElasticSearch读写底层原理及性能调优
https://my.oschina.net/wangzhi ... 09389

编辑:金桥
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

配置 Elasticsearch 服务器 logs

当我们运行 Elasticsearch 集群时,我们可以看到一些 Elasticsearch 的日志,比如我们可以在如下的目录中找到相应的一些 server 日志:

<cluster name>.log
<cluster name>_server.json

假如我在 config/eleasticsearch.yml 文件中把 cluster.name 定义为如下的值:cluster.name: liuxg-cluster那么我们就可以在 logs/ 目录下看到如下的文件:

$ pwd
/Users/liuxg/elastic0/elasticsearch-7.10.0/logs
liuxg:logs liuxg$ ls liuxg-cluster*
liuxg-cluster.log
liuxg-cluster_audit.json
liuxg-cluster_deprecation.json
liuxg-cluster_deprecation.log
liuxg-cluster_index_indexing_slowlog.json
liuxg-cluster_index_indexing_slowlog.log
liuxg-cluster_index_search_slowlog.json
liuxg-cluster_index_search_slowlog.log
liuxg-cluster_server.json

从上面,我们可以看到所有的文件以 liuxg-cluster 开始的文件名。这些日志记录了 elasticsearch 运行的状态。依据不同的日志等级,它会记录不同的事件。
 
详细阅读,请参阅 https://elasticstack.blog.csdn ... 90556
继续阅读 »
当我们运行 Elasticsearch 集群时,我们可以看到一些 Elasticsearch 的日志,比如我们可以在如下的目录中找到相应的一些 server 日志:

<cluster name>.log
<cluster name>_server.json

假如我在 config/eleasticsearch.yml 文件中把 cluster.name 定义为如下的值:cluster.name: liuxg-cluster那么我们就可以在 logs/ 目录下看到如下的文件:

$ pwd
/Users/liuxg/elastic0/elasticsearch-7.10.0/logs
liuxg:logs liuxg$ ls liuxg-cluster*
liuxg-cluster.log
liuxg-cluster_audit.json
liuxg-cluster_deprecation.json
liuxg-cluster_deprecation.log
liuxg-cluster_index_indexing_slowlog.json
liuxg-cluster_index_indexing_slowlog.log
liuxg-cluster_index_search_slowlog.json
liuxg-cluster_index_search_slowlog.log
liuxg-cluster_server.json

从上面,我们可以看到所有的文件以 liuxg-cluster 开始的文件名。这些日志记录了 elasticsearch 运行的状态。依据不同的日志等级,它会记录不同的事件。
 
详细阅读,请参阅 https://elasticstack.blog.csdn ... 90556 收起阅读 »

Elastic:Data tiers 介绍及索引生命周期管理 - 7.10 之后版本


Data tier 也就是数据层。是一个在 7.10 版本的一个新概念。数据层是具有相同数据角色的节点的集合,这些节点通常共享相同的硬件配置文件:
  • Content tier (内容层)节点处理诸如产品目录之类的内容的索引和查询负载。
  • Hot tier (热层) 节点处理诸如日志或指标之类的时间序列数据的索引负载,并保存你最近,最常访问的数据。
  • Warm tier (温层)节点保存的时间序列数据访问频率较低,并且很少需要更新。
  • Cold tier (冷层)节点保存时间序列数据,这些数据偶尔会被访问,并且通常不会更新。

 
详细阅读,请参阅 “Elastic:Data tiers 介绍及索引生命周期管理 - 7.10 之后版本”  https://elasticstack.blog.csdn ... 50474
继续阅读 »

Data tier 也就是数据层。是一个在 7.10 版本的一个新概念。数据层是具有相同数据角色的节点的集合,这些节点通常共享相同的硬件配置文件:
  • Content tier (内容层)节点处理诸如产品目录之类的内容的索引和查询负载。
  • Hot tier (热层) 节点处理诸如日志或指标之类的时间序列数据的索引负载,并保存你最近,最常访问的数据。
  • Warm tier (温层)节点保存的时间序列数据访问频率较低,并且很少需要更新。
  • Cold tier (冷层)节点保存时间序列数据,这些数据偶尔会被访问,并且通常不会更新。

 
详细阅读,请参阅 “Elastic:Data tiers 介绍及索引生命周期管理 - 7.10 之后版本”  https://elasticstack.blog.csdn ... 50474 收起阅读 »

社区日报 第1138期 (2020-12-14)

1、filebeat采集日志乱序现象以及对应的解决方案
https://segmentfault.com/q/1010000014343913

2、ElasticSearch 索引配置隐私字段
https://blog.csdn.net/Vancl_Wa ... 16012

3、elasticsearch存储聊天消息的最佳实践
https://stackoverflow.com/ques ... earch

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1、filebeat采集日志乱序现象以及对应的解决方案
https://segmentfault.com/q/1010000014343913

2、ElasticSearch 索引配置隐私字段
https://blog.csdn.net/Vancl_Wa ... 16012

3、elasticsearch存储聊天消息的最佳实践
https://stackoverflow.com/ques ... earch

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

在 Kibana 中的四种表格制作方式

在 Kibana 的可视化中,我们经常会绘制表格。我总结了一下,有如下的四种方法:
  • 在 Discover 界面中制作
  • 使用 table 可视化进行制作
  • 使用 TSVB  来制作
  • 使用 Lens 进行制作

 
在这几种方式中,几种制作最后的结果是不一样的。我们在实际的使用中,需要根据自己的需求来分别进行选择。
详细阅读,请参阅 https://elasticstack.blog.csdn ... 88189
 
继续阅读 »
在 Kibana 的可视化中,我们经常会绘制表格。我总结了一下,有如下的四种方法:
  • 在 Discover 界面中制作
  • 使用 table 可视化进行制作
  • 使用 TSVB  来制作
  • 使用 Lens 进行制作

 
在这几种方式中,几种制作最后的结果是不一样的。我们在实际的使用中,需要根据自己的需求来分别进行选择。
详细阅读,请参阅 https://elasticstack.blog.csdn ... 88189
  收起阅读 »

社区日报 第1137期 (2020-12-13)

1.安全防护Elasticsearch。
https://www.twingate.com/blog/ ... gate/
2.如何在Kafka和Elasticsearch探索数据。
https://lenses.io/blog/2020/04 ... -sql/
3.(自备梯子)赛博朋克2077通过Proton兼容层在Linux上运行。
https://twitter.com/Plagman2/s ... 34784

编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1.安全防护Elasticsearch。
https://www.twingate.com/blog/ ... gate/
2.如何在Kafka和Elasticsearch探索数据。
https://lenses.io/blog/2020/04 ... -sql/
3.(自备梯子)赛博朋克2077通过Proton兼容层在Linux上运行。
https://twitter.com/Plagman2/s ... 34784

编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
收起阅读 »

社区日报 第1135期 (2020-12-11)

1、Elasticsearch 国外在线基础教程
https://www.javatpoint.com/ela ... cture
2、如何设计可扩展的 Elasticsearch 数据存储的架构
https://www.elastic.co/cn/blog ... scale
3、15分钟介绍ELK(PDF)
http://karunsubramanian.com/wp ... 1.pdf
 

编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup

继续阅读 »
1、Elasticsearch 国外在线基础教程
https://www.javatpoint.com/ela ... cture
2、如何设计可扩展的 Elasticsearch 数据存储的架构
https://www.elastic.co/cn/blog ... scale
3、15分钟介绍ELK(PDF)
http://karunsubramanian.com/wp ... 1.pdf
 

编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup

收起阅读 »

社区日报 第1134期 (2020-12-10)

1.Elastic on Elastic:如何部署基础架构并与ECK保持同步
https://www.elastic.co/blog/el ... h-eck
2.性能爆表!INFINI Gateway 性能与压力测试结果
https://elasticsearch.cn/article/14174
3.ELK多租户方案
https://mp.weixin.qq.com/s/3n77tXW4jnP_Z64baRFFyA

编辑:金桥
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1.Elastic on Elastic:如何部署基础架构并与ECK保持同步
https://www.elastic.co/blog/el ... h-eck
2.性能爆表!INFINI Gateway 性能与压力测试结果
https://elasticsearch.cn/article/14174
3.ELK多租户方案
https://mp.weixin.qq.com/s/3n77tXW4jnP_Z64baRFFyA

编辑:金桥
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

Elasticsearch:Node 介绍 - 7.9 之后版本

在 Elastic Stack 7.9 之后的发布中,我们可以直接在 Elasticsearch 的配置文件中配置 Node 的角色 (node roles)。这是一个新的变化。在 7.9 发布版之前,我们使用 node.master: true 这样的方式来定义一个 master 节点,但是从 7.9 开始之后,我们也可以使用另外一个方法来定义一个 master 节点。我们可以通过 node.roles 来定义一个 master 节点。但是这两种方法只可以选其一,不能两种方法同时使用。从 7.9 发布后,建议使用  node.roles 来定义 node 的角色。在今天的文章中,我来介绍 node.roles。 
 
详细阅读 https://elasticstack.blog.csdn ... 47372
继续阅读 »
在 Elastic Stack 7.9 之后的发布中,我们可以直接在 Elasticsearch 的配置文件中配置 Node 的角色 (node roles)。这是一个新的变化。在 7.9 发布版之前,我们使用 node.master: true 这样的方式来定义一个 master 节点,但是从 7.9 开始之后,我们也可以使用另外一个方法来定义一个 master 节点。我们可以通过 node.roles 来定义一个 master 节点。但是这两种方法只可以选其一,不能两种方法同时使用。从 7.9 发布后,建议使用  node.roles 来定义 node 的角色。在今天的文章中,我来介绍 node.roles。 
 
详细阅读 https://elasticstack.blog.csdn ... 47372 收起阅读 »

深入理解 Dissect ingest processor

Dissect 和 Grok 摄入处理器在数据结构化中被广泛使用。与 Grok 处理器不同,解析不使用正则表达式。 这使得 Dissect 的语法更加简单,并且在某些情况下比 Grok Processor 更快。Dissect ingest processoor 以其高效的性能优于 Grok 而在很多情形下被优先考虑。由于 dissect 的对数据的格式要求非常严格。在我们处理数据时需要格外小心。详细阅读,请参阅 “深入理解 Dissect ingest processor” https://elasticstack.blog.csdn ... 20145
继续阅读 »
Dissect 和 Grok 摄入处理器在数据结构化中被广泛使用。与 Grok 处理器不同,解析不使用正则表达式。 这使得 Dissect 的语法更加简单,并且在某些情况下比 Grok Processor 更快。Dissect ingest processoor 以其高效的性能优于 Grok 而在很多情形下被优先考虑。由于 dissect 的对数据的格式要求非常严格。在我们处理数据时需要格外小心。详细阅读,请参阅 “深入理解 Dissect ingest processor” https://elasticstack.blog.csdn ... 20145 收起阅读 »

社区日报 第1133期 (2020-12-09)

1、ELASTICSEARCH集群节点的扩容
https://ngx.hk/2019/01/07/elas ... .html
2、基于 Go 和 Elasticsearch 构建一个搜索服务
https://maiyang.me/post/2018-0 ... arch/
3、elasticsearch集群如何添加一个datanode节点
https://logz.io/blog/elasticse ... rial/

编辑:wt
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1、ELASTICSEARCH集群节点的扩容
https://ngx.hk/2019/01/07/elas ... .html
2、基于 Go 和 Elasticsearch 构建一个搜索服务
https://maiyang.me/post/2018-0 ... arch/
3、elasticsearch集群如何添加一个datanode节点
https://logz.io/blog/elasticse ... rial/

编辑:wt
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »