行动是治愈恐惧的良药,而犹豫、拖延将不断滋养恐惧。

ES7.17版本terms查询性能问题

背景

1.对于7版本(大版本)集群希望只维护一个版本,最终选择7.17,对同大版本的7.5版本集群进行升级

2.根据官方描述,_id放到堆外性能损失非常小可以忽略,且对BKD进行了优化

3.升级完成,一段时间之后,收到用户报障

1-cpu.png

2-time.png

4.抽样检查了下部分升级的集群,其中部分受到影响,部分不受影响。且每个集群内存均有一定优化(预期内)

调查&分析

1.发现is_deleted文档特别多,怀疑是7.17版本对于碎片过于敏感。做forcemerge,没什么效果。

2.GET _nodes/hot_threads 查看耗时部分,结果展示笼统,没得到关键信息。

3.给语句加上profile,查看耗时部分。

GET index-v1/_search
{"profile":"true","query":{"bool":{"filter":[{"term":{"xid":{"value":"11111111","boost":1.0}}},{"terms":{"status":[2,3,4],"boost":1.0}},{"terms":{"platform":["aaa","bbb"],"boost":1.0}},{"terms":{"pId":[1,2],"boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},"sort":[{"time":{"order":"desc"}}]}

从脱敏的简化结果中可以看出来,主要是 status、pId 字段耗时高,这两个字段都是integer类型,并且使用了terms查询。

{
  "took": 554,
  "timed_out": false,
  "_shards": {
    "total": 3,
    "successful": 3,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 5,
      "relation": "eq"
    },
    "max_score": null,
    "hits": [
      ...
    ]
  },
  "profile": {
    "shards": [
      {
        "id": "[APxxxxxxxxxxxxxxQ][index-v1][0]",
        "searches": [
          {
            "query": [
              {
                "type": "BooleanQuery",
                "description": "#xid:111111111 #status:{2 3 4} #ConstantScore(platform:aaa platform:bbb) #pId:{1 2}",
                "time_in_nanos": 415205306,
                "breakdown": {
                  ...
                  "build_scorer": 415028271
                },
                "children": [
                  {
                    "type": "TermQuery",
                    "description": "xid:111111111",
                    "time_in_nanos": 102656,
                    "breakdown": {
                      .....
                      "build_scorer": 86264
                    }
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "status:{2 3 4}",
                    "time_in_nanos": 220394978,
                    "breakdown": {
                      ....
                      "build_scorer": 220385119
                    }
                  },
                  {
                    "type": "ConstantScoreQuery",
                    "description": "ConstantScore(platform:aaa platform:bbb)",
                    "time_in_nanos": 341845,
                    "breakdown": {
                      .....
                      "build_scorer": 282277
                    },
                    "children": [
                      {
                        "type": "BooleanQuery",
                        "description": "platform:aaa platform:bbb",
                        "time_in_nanos": 329042,
                        "breakdown": {
                          .....
                          "build_scorer": 277752
                        },
                        "children": [
                          {
                            "type": "TermQuery",
                            "description": "platform:aaa",
                            "time_in_nanos": 62446,
                            "breakdown": {
                              .....
                              "build_scorer": 37931
                            }
                          },
                          {
                            "type": "TermQuery",
                            "description": "platform:bbb",
                            "time_in_nanos": 15093,
                            "breakdown": {
                              .....
                              "build_scorer": 6981
                            }
                          }
                        ]
                      }
                    ]
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "pId:{1 2}",
                    "time_in_nanos": 194164297,
                    "breakdown": {
                      ....
                      "build_scorer": 194160452
                    }
                  }
                ]
              }
            ],
            "rewrite_time": 40044,
            "collector": [
              {
                "name": "SimpleFieldCollector",
                "reason": "search_top_hits",
                "time_in_nanos": 144012
              }
            ]
          }
        ]

4.单个的profile无法说明问题,进一步排查:使用arthas工具获取一段时间内的火焰图

3-火焰图.png

可以看到主要就是BKD数据结构占用的CPU。

5.参考官方论坛相似问题:https://discuss.elastic.co/t/very-slow-search-performance-after-upgrade-to-7-16-1/296152/3

6.integer类型的terms查询性能较差,看起来官方描述的BKD相关优化指的是range

7.测试验证,将字段改成keyword,查看结果,CPU查询耗时恢复到正常范围

4-结果.png

5-结果-time.png

继续阅读 »

背景

1.对于7版本(大版本)集群希望只维护一个版本,最终选择7.17,对同大版本的7.5版本集群进行升级

2.根据官方描述,_id放到堆外性能损失非常小可以忽略,且对BKD进行了优化

3.升级完成,一段时间之后,收到用户报障

1-cpu.png

2-time.png

4.抽样检查了下部分升级的集群,其中部分受到影响,部分不受影响。且每个集群内存均有一定优化(预期内)

调查&分析

1.发现is_deleted文档特别多,怀疑是7.17版本对于碎片过于敏感。做forcemerge,没什么效果。

2.GET _nodes/hot_threads 查看耗时部分,结果展示笼统,没得到关键信息。

3.给语句加上profile,查看耗时部分。

GET index-v1/_search
{"profile":"true","query":{"bool":{"filter":[{"term":{"xid":{"value":"11111111","boost":1.0}}},{"terms":{"status":[2,3,4],"boost":1.0}},{"terms":{"platform":["aaa","bbb"],"boost":1.0}},{"terms":{"pId":[1,2],"boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},"sort":[{"time":{"order":"desc"}}]}

从脱敏的简化结果中可以看出来,主要是 status、pId 字段耗时高,这两个字段都是integer类型,并且使用了terms查询。

{
  "took": 554,
  "timed_out": false,
  "_shards": {
    "total": 3,
    "successful": 3,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 5,
      "relation": "eq"
    },
    "max_score": null,
    "hits": [
      ...
    ]
  },
  "profile": {
    "shards": [
      {
        "id": "[APxxxxxxxxxxxxxxQ][index-v1][0]",
        "searches": [
          {
            "query": [
              {
                "type": "BooleanQuery",
                "description": "#xid:111111111 #status:{2 3 4} #ConstantScore(platform:aaa platform:bbb) #pId:{1 2}",
                "time_in_nanos": 415205306,
                "breakdown": {
                  ...
                  "build_scorer": 415028271
                },
                "children": [
                  {
                    "type": "TermQuery",
                    "description": "xid:111111111",
                    "time_in_nanos": 102656,
                    "breakdown": {
                      .....
                      "build_scorer": 86264
                    }
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "status:{2 3 4}",
                    "time_in_nanos": 220394978,
                    "breakdown": {
                      ....
                      "build_scorer": 220385119
                    }
                  },
                  {
                    "type": "ConstantScoreQuery",
                    "description": "ConstantScore(platform:aaa platform:bbb)",
                    "time_in_nanos": 341845,
                    "breakdown": {
                      .....
                      "build_scorer": 282277
                    },
                    "children": [
                      {
                        "type": "BooleanQuery",
                        "description": "platform:aaa platform:bbb",
                        "time_in_nanos": 329042,
                        "breakdown": {
                          .....
                          "build_scorer": 277752
                        },
                        "children": [
                          {
                            "type": "TermQuery",
                            "description": "platform:aaa",
                            "time_in_nanos": 62446,
                            "breakdown": {
                              .....
                              "build_scorer": 37931
                            }
                          },
                          {
                            "type": "TermQuery",
                            "description": "platform:bbb",
                            "time_in_nanos": 15093,
                            "breakdown": {
                              .....
                              "build_scorer": 6981
                            }
                          }
                        ]
                      }
                    ]
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "pId:{1 2}",
                    "time_in_nanos": 194164297,
                    "breakdown": {
                      ....
                      "build_scorer": 194160452
                    }
                  }
                ]
              }
            ],
            "rewrite_time": 40044,
            "collector": [
              {
                "name": "SimpleFieldCollector",
                "reason": "search_top_hits",
                "time_in_nanos": 144012
              }
            ]
          }
        ]

4.单个的profile无法说明问题,进一步排查:使用arthas工具获取一段时间内的火焰图

3-火焰图.png

可以看到主要就是BKD数据结构占用的CPU。

5.参考官方论坛相似问题:https://discuss.elastic.co/t/very-slow-search-performance-after-upgrade-to-7-16-1/296152/3

6.integer类型的terms查询性能较差,看起来官方描述的BKD相关优化指的是range

7.测试验证,将字段改成keyword,查看结果,CPU查询耗时恢复到正常范围

4-结果.png

5-结果-time.png

收起阅读 »

API 网关 Apache APISIX 集成 Elasticsearch 实现实时日志监控

本文将为你介绍 Apache APISIX 的 elasticsearch-logger 插件的相关信息,以及如何通过此插件获取 APISIX 的实时日志。

背景信息

Apache APISIX 是一个动态、实时、高性能的 API 网关,提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。作为 API 网关,Apache APISIX 不仅拥有丰富的插件,而且支持插件的热加载。

Elasticsearch 是一个基于 Lucene 库的搜索引擎。它提供了分布式、RESTful 风格的搜索和数据分析引擎,具有可扩展性、可分布式部署和可进行相关度搜索等特点,能够解决不断涌现出的各种用例。同时还可以集中存储用户数据,帮助用户发现意料之中以及意料之外的情况。

插件介绍

APISIXHTTP 请求的方式向 Elasticsearch 发送 APISIXRuntime 日志。插件 elasticsearch-logger 采用 bulk 的格式进行日志上报,这允许 APISIX 可以将多条日志合并后再进行上报,这使得 APISIX 在对 Elasticsearch 进行日志上报方面更加灵活并且具有较好的性能。你可以参考文档 APISIX 批处理器 对日志合进行更加细致的配置。

配置步骤

首先,你需要安装完成 APISIX,本文所有步骤基于 Centos 7.5 系统进行。详细的安装步骤参考 APISIX 安装指南

步骤1:启动 Elasticsearch

本示例只演示了通过 docker-compose 启动 Elasticsearch 单节点的方式,其它启动方式可参考 Elasticsearch 官方文档

# 使用 docker-compose 启动 1 个 Elasticsearch 节点, 1 个 kibana
version: '3.8'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.1
    container_name: elasticsearch
    environment:
      ES_JAVA_OPTS: -Xms512m -Xmx512m
      discovery.type: single-node
      xpack.security.enabled: 'false'
    networks:
      - es-net
    ports:
      - "9200:9200"
      - "9300:9300"

  kibana:
    image: docker.elastic.co/kibana/kibana:7.17.1
    container_name: kibana
    environment:
      ELASTICSEARCH_HOSTS: http://elasticsearch:9200
      I18N_LOCALE: zh-CN
    networks:
      - es-net
    depends_on:
      - elasticsearch
    ports:
      - "5601:5601"

networks:
  es-net:
    driver: bridge

步骤2:创建路由并配置插件

APISIX 默认配置文件中已启用 elasticsearch-logger 插件,所以你只需要通过下方命令创建路由并配置 elasticsearch-logger 插件就可以在 APISIX 中正常使用了。

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins":{
        "elasticsearch-logger":{
            "endpoint_addr":"http://127.0.0.1:9200",
            "field":{
                "index":"services",
                "type":"collector"
            },
            "ssl_verify":false,
            "retry_delay":1,
            "buffer_duration":60,
            "max_retry_count":0,
            "batch_max_size":1000,
            "inactive_timeout":5,
            "name":"elasticsearch-logger"
        }
    },
    "upstream":{
        "type":"roundrobin",
        "nodes":{
            "127.0.0.1:1980":1
        }
    },
    "uri":"/elasticsearch.do"
}'

上述代码中配置了 Elasticsearch 地址、目标 field,用户名与密码。

通过上述设置,就可以实现将 /elasticsearch.do 路径的 API 请求日志发送至 Elasticsearch 的功能。

步骤3:发送请求

接下来我们通过 API 发送一些请求。

curl -i http://127.0.0.1:9080/elasticsearch.do\?q\=hello
HTTP/1.1 200 OK
...
hello, world

此时你可以登录 Kibana 控制台检索查看相关日志:

index

自定义日志结构

当然,在使用过程中我们也可以通过 elasticsearch-logger 插件提供的元数据配置,来设置发送至 Elasticsearch 的日志数据结构。通过设置 log_format 数据,可以控制发送的数据类型。

比如以下数据中的 $host$time_iso8601 等,都是来自于 NGINX 提供的内置变量;也支持如 $route_id$service_idApache APISIX 提供的变量配置。

curl http://127.0.0.1:9180/apisix/admin/plugin_metadata/elasticsearch-logger \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "log_format": {
        "host": "$host",
        "@timestamp": "$time_iso8601",
        "client_ip": "$remote_addr"
    }
}'

通过发送请求进行简单测试,可以看到上述日志结构设置已生效。目前 Apache APISIX 提供多种日志格式模板,在配置上具有极大的灵活性,更多日志格式细节可参考 Apache APISIX 官方文档

此时你可以登录 Kibana 控制台检索查看相关自定义日志:

如需关闭自定义日志结构,可参考下方操作。

curl http://127.0.0.1:9180/apisix/admin/plugin_metadata/elasticsearch-logger \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X DELETE

此时,插件 elasticsearch-logger 将使用默认格式上报日志。

关闭插件

如使用完毕,只需移除路由配置中 elasticsearch-logger 插件相关的配置并保存,即可关闭路由上的插件。得益于 Apache APISIX 的动态化优势,开启和关闭插件的过程都不需要重启 Apache APISIX

curl http://127.0.0.1:9080/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "methods": ["GET"],
    "uri": "/hello",
    "plugins": {},
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

总结

本文为大家介绍了关于 elasticsearch-logger 插件的功能与使用步骤,更多关于 elasticsearch-logger 插件说明和完整配置列表,可以参考官方文档。

也欢迎随时在 GitHub Discussions 中发起讨论,或通过邮件列表进行交流。

继续阅读 »

本文将为你介绍 Apache APISIX 的 elasticsearch-logger 插件的相关信息,以及如何通过此插件获取 APISIX 的实时日志。

背景信息

Apache APISIX 是一个动态、实时、高性能的 API 网关,提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。作为 API 网关,Apache APISIX 不仅拥有丰富的插件,而且支持插件的热加载。

Elasticsearch 是一个基于 Lucene 库的搜索引擎。它提供了分布式、RESTful 风格的搜索和数据分析引擎,具有可扩展性、可分布式部署和可进行相关度搜索等特点,能够解决不断涌现出的各种用例。同时还可以集中存储用户数据,帮助用户发现意料之中以及意料之外的情况。

插件介绍

APISIXHTTP 请求的方式向 Elasticsearch 发送 APISIXRuntime 日志。插件 elasticsearch-logger 采用 bulk 的格式进行日志上报,这允许 APISIX 可以将多条日志合并后再进行上报,这使得 APISIX 在对 Elasticsearch 进行日志上报方面更加灵活并且具有较好的性能。你可以参考文档 APISIX 批处理器 对日志合进行更加细致的配置。

配置步骤

首先,你需要安装完成 APISIX,本文所有步骤基于 Centos 7.5 系统进行。详细的安装步骤参考 APISIX 安装指南

步骤1:启动 Elasticsearch

本示例只演示了通过 docker-compose 启动 Elasticsearch 单节点的方式,其它启动方式可参考 Elasticsearch 官方文档

# 使用 docker-compose 启动 1 个 Elasticsearch 节点, 1 个 kibana
version: '3.8'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.1
    container_name: elasticsearch
    environment:
      ES_JAVA_OPTS: -Xms512m -Xmx512m
      discovery.type: single-node
      xpack.security.enabled: 'false'
    networks:
      - es-net
    ports:
      - "9200:9200"
      - "9300:9300"

  kibana:
    image: docker.elastic.co/kibana/kibana:7.17.1
    container_name: kibana
    environment:
      ELASTICSEARCH_HOSTS: http://elasticsearch:9200
      I18N_LOCALE: zh-CN
    networks:
      - es-net
    depends_on:
      - elasticsearch
    ports:
      - "5601:5601"

networks:
  es-net:
    driver: bridge

步骤2:创建路由并配置插件

APISIX 默认配置文件中已启用 elasticsearch-logger 插件,所以你只需要通过下方命令创建路由并配置 elasticsearch-logger 插件就可以在 APISIX 中正常使用了。

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins":{
        "elasticsearch-logger":{
            "endpoint_addr":"http://127.0.0.1:9200",
            "field":{
                "index":"services",
                "type":"collector"
            },
            "ssl_verify":false,
            "retry_delay":1,
            "buffer_duration":60,
            "max_retry_count":0,
            "batch_max_size":1000,
            "inactive_timeout":5,
            "name":"elasticsearch-logger"
        }
    },
    "upstream":{
        "type":"roundrobin",
        "nodes":{
            "127.0.0.1:1980":1
        }
    },
    "uri":"/elasticsearch.do"
}'

上述代码中配置了 Elasticsearch 地址、目标 field,用户名与密码。

通过上述设置,就可以实现将 /elasticsearch.do 路径的 API 请求日志发送至 Elasticsearch 的功能。

步骤3:发送请求

接下来我们通过 API 发送一些请求。

curl -i http://127.0.0.1:9080/elasticsearch.do\?q\=hello
HTTP/1.1 200 OK
...
hello, world

此时你可以登录 Kibana 控制台检索查看相关日志:

index

自定义日志结构

当然,在使用过程中我们也可以通过 elasticsearch-logger 插件提供的元数据配置,来设置发送至 Elasticsearch 的日志数据结构。通过设置 log_format 数据,可以控制发送的数据类型。

比如以下数据中的 $host$time_iso8601 等,都是来自于 NGINX 提供的内置变量;也支持如 $route_id$service_idApache APISIX 提供的变量配置。

curl http://127.0.0.1:9180/apisix/admin/plugin_metadata/elasticsearch-logger \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "log_format": {
        "host": "$host",
        "@timestamp": "$time_iso8601",
        "client_ip": "$remote_addr"
    }
}'

通过发送请求进行简单测试,可以看到上述日志结构设置已生效。目前 Apache APISIX 提供多种日志格式模板,在配置上具有极大的灵活性,更多日志格式细节可参考 Apache APISIX 官方文档

此时你可以登录 Kibana 控制台检索查看相关自定义日志:

如需关闭自定义日志结构,可参考下方操作。

curl http://127.0.0.1:9180/apisix/admin/plugin_metadata/elasticsearch-logger \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X DELETE

此时,插件 elasticsearch-logger 将使用默认格式上报日志。

关闭插件

如使用完毕,只需移除路由配置中 elasticsearch-logger 插件相关的配置并保存,即可关闭路由上的插件。得益于 Apache APISIX 的动态化优势,开启和关闭插件的过程都不需要重启 Apache APISIX

curl http://127.0.0.1:9080/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "methods": ["GET"],
    "uri": "/hello",
    "plugins": {},
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

总结

本文为大家介绍了关于 elasticsearch-logger 插件的功能与使用步骤,更多关于 elasticsearch-logger 插件说明和完整配置列表,可以参考官方文档。

也欢迎随时在 GitHub Discussions 中发起讨论,或通过邮件列表进行交流。

收起阅读 »

Observability:使用 Elastic Agent 来进行 Uptime 监控

在 Elastic Stack 7.x 中,Elastic 引入 Heartbeat 来对网站或微服务来进行监控。通过 Heartbeat 的应用,我们可以知道网站及微服务的运行情况,我们甚至可以针对服务器的证书的有效期进行监控。随着 Elastic Agent 的推出,Elastic 更建议我们使用 Elastic Agent 的方法来对网站及微服务来进行监控。为了大家能对 Heartbeat 及 Elastic Agent 有更多的认识和了解,请参阅我之前的文章:

Beats:使用 Heartbeat 进行 Uptime 监控

Observability:使用 Elastic Agent 来摄入日志及指标 - Elastic Stack 8.0

Observability:如何使用 Elastic Agents 把微服务的数据摄入到 Elasticsearch 中

1.png

 
更多阅读,请参阅 https://elasticstack.blog.csdn ... 29912
继续阅读 »
在 Elastic Stack 7.x 中,Elastic 引入 Heartbeat 来对网站或微服务来进行监控。通过 Heartbeat 的应用,我们可以知道网站及微服务的运行情况,我们甚至可以针对服务器的证书的有效期进行监控。随着 Elastic Agent 的推出,Elastic 更建议我们使用 Elastic Agent 的方法来对网站及微服务来进行监控。为了大家能对 Heartbeat 及 Elastic Agent 有更多的认识和了解,请参阅我之前的文章:

Beats:使用 Heartbeat 进行 Uptime 监控

Observability:使用 Elastic Agent 来摄入日志及指标 - Elastic Stack 8.0

Observability:如何使用 Elastic Agents 把微服务的数据摄入到 Elasticsearch 中

1.png

 
更多阅读,请参阅 https://elasticstack.blog.csdn ... 29912 收起阅读 »

Elasticsearch:如何在不更新证书的情况下为集群之间建立互信

我们知道,建立集群之间的互信非常重要。这个是为我们进行 CCR 及 CCS 操作的基础。只有建立好了集群之间的互信,我们才可以创建集群之间的 remote connection。特别是针对含有 SSL 连接的集群,他们含有各自的证书,那么我们该如何建立集群之间的互信呢?在我之前的文章 “Elasticsearch:如何为 CCR 及 CCS 建立带有安全的集群之间的互信” 中,我详述了如何通过更新证书来建立集群之间的互信。更新证书在很多的情况下,可能并不是最好的途径。在今天的文章中,我将详述如何在不更新证书的情况下,为集群之间建立互信。

在今天的展示中,我将使用如下的架构:

trust.png



如上所示,我们创建两个不同的集群。它们分别运行于两个不同的机器上。它们使用不同的 IP 地址。我将使用最新的 Elastic Stack 8.4.1 来进行展示。


如何在不更新证书的情况下为集群之间建立互信

针对非 keystore 及 truststore 的安装
如果你的 Elasticsearch 的部署不是按照 keystore 及 truststore 来进行安装的,而是参照我之前的文章 “Security:如何安装 Elastic SIEM 和 EDR” 来进行安装的话,那么你可以直接把另外一个集群的证书添加到相应的 config/elasticsearch.yml 的配置中去即可:

config/elasticsearch.yml

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.key: /etc/elasticsearch/certs/elasticsearch.key
xpack.security.transport.ssl.certificate: /etc/elasticsearch/certs/elasticsearch.crt
xpack.security.transport.ssl.certificate_authorities: [ "/etc/elasticsearch/certs/ca/ca.crt", "certificate_from_another_cluster.crt ]
在这种情况下的配置就非常简单明了。我们就不赘述了。
 
更多阅读,请参阅 https://elasticstack.blog.csdn ... 26063
 
继续阅读 »
我们知道,建立集群之间的互信非常重要。这个是为我们进行 CCR 及 CCS 操作的基础。只有建立好了集群之间的互信,我们才可以创建集群之间的 remote connection。特别是针对含有 SSL 连接的集群,他们含有各自的证书,那么我们该如何建立集群之间的互信呢?在我之前的文章 “Elasticsearch:如何为 CCR 及 CCS 建立带有安全的集群之间的互信” 中,我详述了如何通过更新证书来建立集群之间的互信。更新证书在很多的情况下,可能并不是最好的途径。在今天的文章中,我将详述如何在不更新证书的情况下,为集群之间建立互信。

在今天的展示中,我将使用如下的架构:

trust.png



如上所示,我们创建两个不同的集群。它们分别运行于两个不同的机器上。它们使用不同的 IP 地址。我将使用最新的 Elastic Stack 8.4.1 来进行展示。


如何在不更新证书的情况下为集群之间建立互信

针对非 keystore 及 truststore 的安装
如果你的 Elasticsearch 的部署不是按照 keystore 及 truststore 来进行安装的,而是参照我之前的文章 “Security:如何安装 Elastic SIEM 和 EDR” 来进行安装的话,那么你可以直接把另外一个集群的证书添加到相应的 config/elasticsearch.yml 的配置中去即可:

config/elasticsearch.yml

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.key: /etc/elasticsearch/certs/elasticsearch.key
xpack.security.transport.ssl.certificate: /etc/elasticsearch/certs/elasticsearch.crt
xpack.security.transport.ssl.certificate_authorities: [ "/etc/elasticsearch/certs/ca/ca.crt", "certificate_from_another_cluster.crt ]
在这种情况下的配置就非常简单明了。我们就不赘述了。
 
更多阅读,请参阅 https://elasticstack.blog.csdn ... 26063
  收起阅读 »

《Elastic Stack 实战手册》 介绍及下载

本书由数十位 Elasticsearch 技术圈的优秀开发者共创而成,得到了许多资深业界精英,社区技术大咖,Elastic Stack 相关书籍作者的支持,凝聚了众多创作人的实践经验和创作能力。 书籍涵盖了一位 Elastic Stack 开发者所需的必要知识,尤其对于刚入门的开发者,从上篇基础的 Elastic Stack 产品能力到下篇的应用实践,提供了系统性学习参考的上手指南。

Elasticsearch 无疑是大数据搜索引擎中的王者,它以其开放及免费、易用、多语言接口、卓越性能及不断创新的优势,被许多 IT 企业所采用。当今的许多IT 企业很难绕过它。在中国,Elastic Stack 有一个很强大的生态圈。在本书的创作过程中,我非常高兴看到有数十位志愿者参与到本书的创作中。这本书集众技术大咖及专家们的无私奉献,是他们牺牲了自己宝贵的时间,利用业余时间共创完成,在一遍遍的修改中把内容做得更完善。在这里衷心感谢他们的无私付出和合作。

写书和做社区贡献,是需要情怀的。我一直坚信帮助别人,也会成就自己。分享自己的知识,也是一件很快乐的事,因为这样可以证明自己的人生价值。我有超过16 年的社区参与经历,也非常喜欢分享我学到的知识。从加入Elastic 公司以来,我在CSDN 上已经发表了将近660 篇关于Elastic Stack 方面的文章,涵盖了Elastic Stack 方方面面的知识。

作为本书主编,我投入了很多时间来策划、创作、校正及阅读这本书,尽力保证本书的完整性、正确性、一致性及每篇文章的独立性。尽管如此,里面可能有不尽之处,希望读者们海涵!这本书涵盖了Elastic Stack 的介绍、安装、实操、产品能力、方案及案例,特别适合初学者,

对有经验的开发者来说也是一本难得的参考书。在未来,希望有更多的开发者分享自己的知识,

让我们一起把Elastic 社区做得更好!

我强烈推荐想学 Elastic Stack 技术的开发者,下载这本书作为参考。下载连接为 Elastic Stack 实战手册-藏经阁-阿里云开发者社区 https://developer.aliyun.com/ebook/7687
 
https://elasticstack.blog.csdn ... 01982
 

alibaba_book.png

 
 
继续阅读 »
本书由数十位 Elasticsearch 技术圈的优秀开发者共创而成,得到了许多资深业界精英,社区技术大咖,Elastic Stack 相关书籍作者的支持,凝聚了众多创作人的实践经验和创作能力。 书籍涵盖了一位 Elastic Stack 开发者所需的必要知识,尤其对于刚入门的开发者,从上篇基础的 Elastic Stack 产品能力到下篇的应用实践,提供了系统性学习参考的上手指南。

Elasticsearch 无疑是大数据搜索引擎中的王者,它以其开放及免费、易用、多语言接口、卓越性能及不断创新的优势,被许多 IT 企业所采用。当今的许多IT 企业很难绕过它。在中国,Elastic Stack 有一个很强大的生态圈。在本书的创作过程中,我非常高兴看到有数十位志愿者参与到本书的创作中。这本书集众技术大咖及专家们的无私奉献,是他们牺牲了自己宝贵的时间,利用业余时间共创完成,在一遍遍的修改中把内容做得更完善。在这里衷心感谢他们的无私付出和合作。

写书和做社区贡献,是需要情怀的。我一直坚信帮助别人,也会成就自己。分享自己的知识,也是一件很快乐的事,因为这样可以证明自己的人生价值。我有超过16 年的社区参与经历,也非常喜欢分享我学到的知识。从加入Elastic 公司以来,我在CSDN 上已经发表了将近660 篇关于Elastic Stack 方面的文章,涵盖了Elastic Stack 方方面面的知识。

作为本书主编,我投入了很多时间来策划、创作、校正及阅读这本书,尽力保证本书的完整性、正确性、一致性及每篇文章的独立性。尽管如此,里面可能有不尽之处,希望读者们海涵!这本书涵盖了Elastic Stack 的介绍、安装、实操、产品能力、方案及案例,特别适合初学者,

对有经验的开发者来说也是一本难得的参考书。在未来,希望有更多的开发者分享自己的知识,

让我们一起把Elastic 社区做得更好!

我强烈推荐想学 Elastic Stack 技术的开发者,下载这本书作为参考。下载连接为 Elastic Stack 实战手册-藏经阁-阿里云开发者社区 https://developer.aliyun.com/ebook/7687
 
https://elasticstack.blog.csdn ... 01982
 

alibaba_book.png

 
  收起阅读 »

Elasticsearch:Apache spark 大数据集成

Elasticsearch 已成为大数据架构中的常用组件,因为它提供了以下几个特性:

它使你可以快速搜索大量数据。
对于常见的聚合操作,它提供对大数据的实时分析。
使用 Elasticsearch 聚合比使用 Spark 聚合更容易。
如果你需要转向快速数据解决方案,在查询后从文档子集开始比对所有数据进行全面重新扫描要快。
用于处理数据的最常见的大数据软件现在是 Apache Spark (http://spark.apache.org/),它被认为是过时的 Hadoop MapReduce 的演变,用于将处理从磁盘移动到内存。
在本中,我们将看到如何将 Elasticsearch 集成到 Spark 中,用于写入和读取数据。 最后,我们将看到如何使用 Apache Pig 以一种简单的方式在Elasticsearch 中写入数据。

https://elasticstack.blog.csdn ... 68453
继续阅读 »
Elasticsearch 已成为大数据架构中的常用组件,因为它提供了以下几个特性:

它使你可以快速搜索大量数据。
对于常见的聚合操作,它提供对大数据的实时分析。
使用 Elasticsearch 聚合比使用 Spark 聚合更容易。
如果你需要转向快速数据解决方案,在查询后从文档子集开始比对所有数据进行全面重新扫描要快。
用于处理数据的最常见的大数据软件现在是 Apache Spark (http://spark.apache.org/),它被认为是过时的 Hadoop MapReduce 的演变,用于将处理从磁盘移动到内存。
在本中,我们将看到如何将 Elasticsearch 集成到 Spark 中,用于写入和读取数据。 最后,我们将看到如何使用 Apache Pig 以一种简单的方式在Elasticsearch 中写入数据。

https://elasticstack.blog.csdn ... 68453 收起阅读 »

一个迷惑性很高的生产故障-Elasticsearch日志rotate导致节点CPU激增

背景

Elasticsearch CPU很高的场景很常见,优化读写以及扩容即可解决问题。

如果只有一个节点CPU高,那可能的情况就比较多了,节点机器异常?读写不均匀?GC过高?forcemerge?

这里描述一个极具迷惑性的case。

问题

收到用户报障碍,突然有写入被reject,并且有一个节点的CPU突然增高。

zmccc1.png

分析、验证与结论

1.常用套路,先大致了解集群、索引。

集群层面:6.8.5 版本,18个节点(冷热分离)

索引层面:近3000个索引,大多数小索引(mb、1~10gb级别),template(设置1主分片、1副本分片)

用户行为:写多读少的OLAP场景

2.检查节点(pod)监控、宿主机监控、ES集群监控。没有很明显的异常行为。只能观测到异常节点CPU高、出现reject。用户的读写流量也没有观测到明显变化。

3.集群GC、merge等行为都很正常,并且只有一个节点CPU高(刚好用户索引都是1主1副),开始认为和热点相关。可能是某个索引的读写导致了节点CPU的上升。

4.使用 GET _nodes/hot_threads 查看CPU使用情况,果然抓到了异常节点占用CPU的主要是 write 线程。

5.由于hot_threads只能抓取瞬时的数据,不一定准确。准备进入容器,使用arthas工具抓取perf信息(arthas是阿里的开源工具、已经被我们集成到ES镜像里)。

通过arthas简要的获取热点线程:可以看到主要是write线程在执行bulk请求,然后还有日志打印的堆栈。

zmcccc2.png

继续抓取2min内的统计信息:可以看到主要是search在使用CPU。和之前获取的信息不符。

zmccc3.pg_.png

6.分析到底是读还是写影响的CPU。

a.如果是写热点导致,应该会有2个节点CPU高;

b.写入一般很难长时间打高CPU,而一个拉全量/大量数据的大请求很可能拉高CPU,由于index设置1主1副本,刚好可以解释只有一个节点CPU高;

c.考虑到抓取的数据perf结果,2min内的抓取结果比瞬时的可信;

综合来看,大查询导致的CPU高的概率很大。

7.继续走排障流程,查看日志信息

看到异常节点日志里大多都是这类异常。

elasticsearch org.apache.logging.log4j.core.appender.AppenderLoggingException: Error writing to stream /usr/share/elasticsearch/logs/e100024741.log org.apache.logging.log4j.core.appender.AppenderLoggingException: Error writing to stream....

由于节点已经跑了很长时间,log盘写满也是有可能的,而且不太可能瞬间拉高CPU,暂时忽略。

8.进一步验证,将异常节点重启。

果然异常节点CPU下去了,另一个节点CPU起来了,进一步证明了是查询导致的,1主1副的case下,一个节点挂了,另一个承载流量。

zmccc4.png

继续观察异常节点的流量:outgoing的流量比较高,又进一步佐证了是查询带来的异常。

zmccc5.png

继续查看IO,write/read都相对比较高。

9.考虑到查询无法被阻断、且该节点异常带来的影响并不大,准备等“拉数据的大请求”执行完毕自动恢复。

10.开始关注其他问题。等待一段时间,发现依然没有恢复,且CPU完全没有下降的趋势。考虑到一个大请求不会执行这么长时间,如果多个大请求,至少reject、cpu曲线会有些波动,不会如此稳定。准备继续排查。再次执行多次hot_thread API,依然有很多次都只抓到了write线程占用大量CPU,如果大请求存在,不会一直抓不到search请求。

11.考虑其他思路。找到重启前异常节点和重启异常节点后才异常的节点共有的index(互为主备),在众多index中发现了一个较大的index(800G)。看了下文档数:2147483519,至此,找到了问题的答案。

12.结论:使用了同一template的大量索引(1 primary 1 replica),存在一个index写了大量doc数,超过了lucene的最大限制(integer的最大值),疯狂报错reject,并且记录大量异常日志,日志不断的rotate、清理造成了CPU的大幅上升。

仔细检查异常开始时间节点的日志,可以发现如下异常信息:

[2022-07-22T12:00:36,376][DEBUG][o.e.a.b.TransportShardBulkAction] [e100024741-es-default-1][cp0006014_2022_07][0] failed to execute bulk item (index) index {[cp0006014_2022_07][event_cp][Ir_HJYIBi3-VIQ2V8GIT], source[{"rowkey":"fff5e48f-13d9-4f68-b9c9-8cfc1f0fefa3","column01":"BatchValidateRecevieCouponRealTime","column02":"1","column03":"289358095","column04":"100009826","column05":"nkryj","column06":"32001052810269459246","column08":"fff5e48f-13d9-4f68-b9c9-8cfc1f0fefa3","column09":"[34m~L[34m~A34m~O~Q34m~H[34m~D34m| "column11":"2022-07-22 20:00:29.703","column12":"1","column20":"0","datachangelasttime":1658491229707,"rules":[],"rulesh":[],"scenes":[]}]}
java.lang.IllegalArgumentException: number of documents in the index cannot exceed 2147483519
        at org.apache.lucene.index.DocumentsWriterPerThread.reserveOneDoc(DocumentsWriterPerThread.java:226) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:235) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1616) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1235) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.elasticsearch.index.engine.InternalEngine.addDocs(InternalEngine.java:1175) ~[elasticsearch-6.8.5.jar:6.8.5]
        at org.elasticsearch.index.engine.InternalEngine.indexIntoLucene(InternalEngine.java:1120) ~[elasticsearch-6.8.5.jar:6.8.5]

进一步验证:进入容器清理日志文件,会立刻生成并rotate出多个日志文件。

最终处理:清理掉异常索引立刻恢复正常:

zmccc6.png

解释前面的坑

1.arthas采集2min内的CPU信息,得到的search结论是正确的,该集群确实存在search大请求。虽然频率不高,但是采集到的概率很大。

zmccc7.png

2.异常节点的out流量很大。这个逻辑也是正确的,只是并不是导致异常的根本原因。

确实有拉数据的请求存在;节点存在大量索引的分片,无法确认流量来源是否是其他index;该异常情况下用户收到异常ack之后会有重试,影响到流量的统计。

zmccc8.pnng_.png

3.重启后另一个节点CPU就开始激增,是因为副本分片成为了主分片,然后开始reject,并疯狂打印日志、进行rotate和清理。

4.为什么只有一个节点CPU高。写入流程是主分片写入成功后,异步转发请求给所有副本(此处只有1),由于主分片写入失败,直接异常,副本也就不会受到影响。

思考

1.经验流大多情况有效,有时却不可取。时刻根据事实排障,避免先入为主。

2.相似的现象以及采集排障数据的巧合进入思维误区,集群业务复杂度增加了排障难度:

大量的日志难以查找(被AppenderLoggingException淹没),且都被判定为和本次异常无关,如 bulk reject 被认为是CPU高的场景下正常的表现,AppenderLoggingException 被认为无法快速消耗CPU,number of documents in the index cannot exceed 2147483519 刚看到时也被认为无法导致CPU增高(仅仅是无法写入);

index太多,无法从单个index层面获取更多信息。(没有明确目标的情况下难以发现那一个异常index)。

3.arthas write线程的堆栈信息中有体现,bulk之后就在打印日志,这两点之间的关联被忽略。

4.优化方向:需要更细粒度的监控和巡检能力,快速发现异常index可大大加快排障进程,不再强依赖OPS的知识体系与推理。

继续阅读 »

背景

Elasticsearch CPU很高的场景很常见,优化读写以及扩容即可解决问题。

如果只有一个节点CPU高,那可能的情况就比较多了,节点机器异常?读写不均匀?GC过高?forcemerge?

这里描述一个极具迷惑性的case。

问题

收到用户报障碍,突然有写入被reject,并且有一个节点的CPU突然增高。

zmccc1.png

分析、验证与结论

1.常用套路,先大致了解集群、索引。

集群层面:6.8.5 版本,18个节点(冷热分离)

索引层面:近3000个索引,大多数小索引(mb、1~10gb级别),template(设置1主分片、1副本分片)

用户行为:写多读少的OLAP场景

2.检查节点(pod)监控、宿主机监控、ES集群监控。没有很明显的异常行为。只能观测到异常节点CPU高、出现reject。用户的读写流量也没有观测到明显变化。

3.集群GC、merge等行为都很正常,并且只有一个节点CPU高(刚好用户索引都是1主1副),开始认为和热点相关。可能是某个索引的读写导致了节点CPU的上升。

4.使用 GET _nodes/hot_threads 查看CPU使用情况,果然抓到了异常节点占用CPU的主要是 write 线程。

5.由于hot_threads只能抓取瞬时的数据,不一定准确。准备进入容器,使用arthas工具抓取perf信息(arthas是阿里的开源工具、已经被我们集成到ES镜像里)。

通过arthas简要的获取热点线程:可以看到主要是write线程在执行bulk请求,然后还有日志打印的堆栈。

zmcccc2.png

继续抓取2min内的统计信息:可以看到主要是search在使用CPU。和之前获取的信息不符。

zmccc3.pg_.png

6.分析到底是读还是写影响的CPU。

a.如果是写热点导致,应该会有2个节点CPU高;

b.写入一般很难长时间打高CPU,而一个拉全量/大量数据的大请求很可能拉高CPU,由于index设置1主1副本,刚好可以解释只有一个节点CPU高;

c.考虑到抓取的数据perf结果,2min内的抓取结果比瞬时的可信;

综合来看,大查询导致的CPU高的概率很大。

7.继续走排障流程,查看日志信息

看到异常节点日志里大多都是这类异常。

elasticsearch org.apache.logging.log4j.core.appender.AppenderLoggingException: Error writing to stream /usr/share/elasticsearch/logs/e100024741.log org.apache.logging.log4j.core.appender.AppenderLoggingException: Error writing to stream....

由于节点已经跑了很长时间,log盘写满也是有可能的,而且不太可能瞬间拉高CPU,暂时忽略。

8.进一步验证,将异常节点重启。

果然异常节点CPU下去了,另一个节点CPU起来了,进一步证明了是查询导致的,1主1副的case下,一个节点挂了,另一个承载流量。

zmccc4.png

继续观察异常节点的流量:outgoing的流量比较高,又进一步佐证了是查询带来的异常。

zmccc5.png

继续查看IO,write/read都相对比较高。

9.考虑到查询无法被阻断、且该节点异常带来的影响并不大,准备等“拉数据的大请求”执行完毕自动恢复。

10.开始关注其他问题。等待一段时间,发现依然没有恢复,且CPU完全没有下降的趋势。考虑到一个大请求不会执行这么长时间,如果多个大请求,至少reject、cpu曲线会有些波动,不会如此稳定。准备继续排查。再次执行多次hot_thread API,依然有很多次都只抓到了write线程占用大量CPU,如果大请求存在,不会一直抓不到search请求。

11.考虑其他思路。找到重启前异常节点和重启异常节点后才异常的节点共有的index(互为主备),在众多index中发现了一个较大的index(800G)。看了下文档数:2147483519,至此,找到了问题的答案。

12.结论:使用了同一template的大量索引(1 primary 1 replica),存在一个index写了大量doc数,超过了lucene的最大限制(integer的最大值),疯狂报错reject,并且记录大量异常日志,日志不断的rotate、清理造成了CPU的大幅上升。

仔细检查异常开始时间节点的日志,可以发现如下异常信息:

[2022-07-22T12:00:36,376][DEBUG][o.e.a.b.TransportShardBulkAction] [e100024741-es-default-1][cp0006014_2022_07][0] failed to execute bulk item (index) index {[cp0006014_2022_07][event_cp][Ir_HJYIBi3-VIQ2V8GIT], source[{"rowkey":"fff5e48f-13d9-4f68-b9c9-8cfc1f0fefa3","column01":"BatchValidateRecevieCouponRealTime","column02":"1","column03":"289358095","column04":"100009826","column05":"nkryj","column06":"32001052810269459246","column08":"fff5e48f-13d9-4f68-b9c9-8cfc1f0fefa3","column09":"[34m~L[34m~A34m~O~Q34m~H[34m~D34m| "column11":"2022-07-22 20:00:29.703","column12":"1","column20":"0","datachangelasttime":1658491229707,"rules":[],"rulesh":[],"scenes":[]}]}
java.lang.IllegalArgumentException: number of documents in the index cannot exceed 2147483519
        at org.apache.lucene.index.DocumentsWriterPerThread.reserveOneDoc(DocumentsWriterPerThread.java:226) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:235) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1616) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1235) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.elasticsearch.index.engine.InternalEngine.addDocs(InternalEngine.java:1175) ~[elasticsearch-6.8.5.jar:6.8.5]
        at org.elasticsearch.index.engine.InternalEngine.indexIntoLucene(InternalEngine.java:1120) ~[elasticsearch-6.8.5.jar:6.8.5]

进一步验证:进入容器清理日志文件,会立刻生成并rotate出多个日志文件。

最终处理:清理掉异常索引立刻恢复正常:

zmccc6.png

解释前面的坑

1.arthas采集2min内的CPU信息,得到的search结论是正确的,该集群确实存在search大请求。虽然频率不高,但是采集到的概率很大。

zmccc7.png

2.异常节点的out流量很大。这个逻辑也是正确的,只是并不是导致异常的根本原因。

确实有拉数据的请求存在;节点存在大量索引的分片,无法确认流量来源是否是其他index;该异常情况下用户收到异常ack之后会有重试,影响到流量的统计。

zmccc8.pnng_.png

3.重启后另一个节点CPU就开始激增,是因为副本分片成为了主分片,然后开始reject,并疯狂打印日志、进行rotate和清理。

4.为什么只有一个节点CPU高。写入流程是主分片写入成功后,异步转发请求给所有副本(此处只有1),由于主分片写入失败,直接异常,副本也就不会受到影响。

思考

1.经验流大多情况有效,有时却不可取。时刻根据事实排障,避免先入为主。

2.相似的现象以及采集排障数据的巧合进入思维误区,集群业务复杂度增加了排障难度:

大量的日志难以查找(被AppenderLoggingException淹没),且都被判定为和本次异常无关,如 bulk reject 被认为是CPU高的场景下正常的表现,AppenderLoggingException 被认为无法快速消耗CPU,number of documents in the index cannot exceed 2147483519 刚看到时也被认为无法导致CPU增高(仅仅是无法写入);

index太多,无法从单个index层面获取更多信息。(没有明确目标的情况下难以发现那一个异常index)。

3.arthas write线程的堆栈信息中有体现,bulk之后就在打印日志,这两点之间的关联被忽略。

4.优化方向:需要更细粒度的监控和巡检能力,快速发现异常index可大大加快排障进程,不再强依赖OPS的知识体系与推理。

收起阅读 »

期待已久的 Elasticserach 多集群管理平台 INFINI Console 最新的 0.3 版本正式发布!

INFINI Console v0.3 正式发布

极限实验室上新啦,期待已久的 INFINI Console 最新的 0.3 版本正式发布!

01 产品名称的变化

还记得最开始的极限数据平台么,现在已经升级成为 INFINI Console 了。

与极限实验室的其它产品保持一致,家族 Logo 一览如下:

图片

接下来,将为大家隆重介绍一下本次产品更新都有哪些亮点吧。

02 统一的监控

作为目前最方便的 Elasticsearch 管理工具,跨版本、跨集群的监控自然是必不可少的一个基础能力啦。

除了使用方便,颜值自然也是高高的,多套集群的监控终于在一起了。

INFINI Console 提供了市面上最全面的各项统计指标的监控,帮助您快速掌握集群内部运行状态,快速定位集群问题,提高诊断效率,缩短故障时间。

图片

03 统一的安全

相信您的 Elasticsearch 集群不止一个,INFINI Console v0.3 新增了平台级统一的安全管控能力。

多个集群可以统一实现基于角色的用户权限管理,数据和 UI 的权限也可以分别进行设置,可以做到不同的部门看到的集群各不一样,不同的人员看到的索引各不一样,不同的角色读写权限各不一样。

在一个平台里面统一的进行管理,再也不用割裂的维护 N 套安全配置了。

图片

04 统一的告警

平台层的监控还是空白么?还在一套集群一套集群的配置告警规则么?Elasticsearch 内的业务数据还在被动响应么?

INFINI Console v0.3 新增了强大的告警规则引擎,通过配置告警规则,将业务关注点自动化、流程化、主动化,引擎支持常见的统计函数,使用起来简单且灵活,支持 Webhook 方式灵活对接钉钉、微信、Slack 或是内部通知系统。

只要是在 Elasticsearch 的数据,都可以借助告警引擎“活”起来。

图片

05 统一的探索

还在不同 Kibana 之间来回跳转么?还在傻傻创建 IndexPattern 才能分析数据么?

拒绝复杂,回归简单,INFINI Console 新增了跨集群的数据探索功能,不需要提前创建 IndexPattern,想要探索数据一键直达,切换不同集群、切换不同索引、切换不同时间维度,都只在一步完成。

让数据分析和探索的体验尽可能简单是我们努力在做的事情。

图片

06 更多细节

当然本次更新也新增了不少细节特性和修复了不少 Bug,具体的细节请访问产品的 Release Notes 页面:

欢迎大家下载体验,下载安装及文档地址:

继续阅读 »

INFINI Console v0.3 正式发布

极限实验室上新啦,期待已久的 INFINI Console 最新的 0.3 版本正式发布!

01 产品名称的变化

还记得最开始的极限数据平台么,现在已经升级成为 INFINI Console 了。

与极限实验室的其它产品保持一致,家族 Logo 一览如下:

图片

接下来,将为大家隆重介绍一下本次产品更新都有哪些亮点吧。

02 统一的监控

作为目前最方便的 Elasticsearch 管理工具,跨版本、跨集群的监控自然是必不可少的一个基础能力啦。

除了使用方便,颜值自然也是高高的,多套集群的监控终于在一起了。

INFINI Console 提供了市面上最全面的各项统计指标的监控,帮助您快速掌握集群内部运行状态,快速定位集群问题,提高诊断效率,缩短故障时间。

图片

03 统一的安全

相信您的 Elasticsearch 集群不止一个,INFINI Console v0.3 新增了平台级统一的安全管控能力。

多个集群可以统一实现基于角色的用户权限管理,数据和 UI 的权限也可以分别进行设置,可以做到不同的部门看到的集群各不一样,不同的人员看到的索引各不一样,不同的角色读写权限各不一样。

在一个平台里面统一的进行管理,再也不用割裂的维护 N 套安全配置了。

图片

04 统一的告警

平台层的监控还是空白么?还在一套集群一套集群的配置告警规则么?Elasticsearch 内的业务数据还在被动响应么?

INFINI Console v0.3 新增了强大的告警规则引擎,通过配置告警规则,将业务关注点自动化、流程化、主动化,引擎支持常见的统计函数,使用起来简单且灵活,支持 Webhook 方式灵活对接钉钉、微信、Slack 或是内部通知系统。

只要是在 Elasticsearch 的数据,都可以借助告警引擎“活”起来。

图片

05 统一的探索

还在不同 Kibana 之间来回跳转么?还在傻傻创建 IndexPattern 才能分析数据么?

拒绝复杂,回归简单,INFINI Console 新增了跨集群的数据探索功能,不需要提前创建 IndexPattern,想要探索数据一键直达,切换不同集群、切换不同索引、切换不同时间维度,都只在一步完成。

让数据分析和探索的体验尽可能简单是我们努力在做的事情。

图片

06 更多细节

当然本次更新也新增了不少细节特性和修复了不少 Bug,具体的细节请访问产品的 Release Notes 页面:

欢迎大家下载体验,下载安装及文档地址:

收起阅读 »

Elasticsearch:我的 Elasticsearch 集群中应该有多少个分片?

Elasticsearch 是一个非常通用的平台,它支持各种用例,并在数据组织和复制策略方面提供了极大的灵活性。但是,这种灵活性有时会导致难以预先确定如何最好地将数据组织到索引和分片中,尤其是在你不熟悉 Elastic Stack 的情况下。虽然次优选择在刚开始时不一定会导致问题,但随着数据量的增长,它们有可能导致性能问题。集群拥有的数据越多,纠正问题也就越困难,因为有时可能需要对大量数据进行重新索引。

当我们遇到遇到性能问题的用户时,通常可以追溯到有关数据索引方式和集群中分片数量的问题。对于涉及多租户和/或使用基于时间的索引的用例尤其如此。在与用户讨论这个问题时,无论是在活动或会议上当面还是通过我们的论坛,一些最常见的问题是 “我应该拥有多少分片?” 和  “我的分片应该有多大?”

这篇博文旨在帮助您回答这些问题,并为涉及在一个地方使用基于时间的索引(例如,日志记录或安全分析)的用例提供实用指南。
 
https://elasticstack.blog.csdn ... 15198
继续阅读 »
Elasticsearch 是一个非常通用的平台,它支持各种用例,并在数据组织和复制策略方面提供了极大的灵活性。但是,这种灵活性有时会导致难以预先确定如何最好地将数据组织到索引和分片中,尤其是在你不熟悉 Elastic Stack 的情况下。虽然次优选择在刚开始时不一定会导致问题,但随着数据量的增长,它们有可能导致性能问题。集群拥有的数据越多,纠正问题也就越困难,因为有时可能需要对大量数据进行重新索引。

当我们遇到遇到性能问题的用户时,通常可以追溯到有关数据索引方式和集群中分片数量的问题。对于涉及多租户和/或使用基于时间的索引的用例尤其如此。在与用户讨论这个问题时,无论是在活动或会议上当面还是通过我们的论坛,一些最常见的问题是 “我应该拥有多少分片?” 和  “我的分片应该有多大?”

这篇博文旨在帮助您回答这些问题,并为涉及在一个地方使用基于时间的索引(例如,日志记录或安全分析)的用例提供实用指南。
 
https://elasticstack.blog.csdn ... 15198 收起阅读 »

Elasticsearch8.2 使用snapshot备份能力

背景

1.有个向量搜索相关需求,选择使用ES8版本,并且在k8s环境中容器化部署; 2.考虑核心程度以及成本问题,不需要准备多数据中心的备份集群,为了保证数据可靠性,预期使用snapshot备份能力;

选型

ES支持将snapshot存储到各种存储产品,例如 fs(本地)、S3(或者ceph)、hdfs等。 1.OSS,考虑到已经和阿里云OSS有合作,且支持S3接口 -----> 测试 2.ceph,私有云部署,不好控制容量,成本偏高 --------> 暂不考虑 3.hdfs,私有云部署,不好控制容量,成本偏高,需要安装插件 -----> 暂不考虑 4.fs,本地,由于团队还在做juicefs产品,可以juicefs挂载到本地目录,ES snapshot 存到本地目录即可完成上传到公有云OSS ------> 测试

snapshot直接从ES传到OSS

1.创建账号、bucket,获取ak/sk;

2.ES容器实例如何加载密钥库

通过官方文档可知需要执行如下命令:将密钥设置到ES密钥库 https://www.elastic.co/guide/en/elasticsearch/reference/current/repository-s3.html

bin/elasticsearch-keystore add s3.client.default.access_key
bin/elasticsearch-keystore add s3.client.default.secret_key

考虑到容器环境不允许直接进入pod执行命令,secret也不允许直接写死到镜像中,则需要在entrypoint.sh中设置完成该命令。 最终方案如下:

文章image1.png
1.在k8s环境中创建secret,记录ak/sk信息 2.pod创建时候mount到指定目录 3.container(ES)启动的时候读取指定目录信息,并执行elasticsearch-keystore命令

3.具体操作

0.安装 repository-s3 插件 略(ES8版本内置了该插件,无需安装)

文章image2.png
1.创建secret

kubectl apply -f secret.yml

# cat secret.yml
apiVersion: v1
kind: Secret
metadata:
  namespace: uat-es
  name: es-snapshot-oss-secret
type: Opaque
data:
  access_key: xxx(注意base64编码)
  secret_key: xxx(注意base64编码)

2.修改crd的yaml,将该secret mount到指定目录

# 定义secret
  volumes:  
  - name: "oss-secret"
    secret: 
      secretName: "es-snapshot-oss-secret"

# 指定容器挂载选项
containers:
    ...
  volumeMounts:
  - mountPath: "/mnt/secret/oss"
    name: "oss-secret"
    readOnly: true

3.镜像修改 注:Dockerfile中最后是通过docker-entrypoint.sh完成ES实例的启动 ENTRYPOINT ["/usr/local/bin/docker-entrypoint.sh"]

# docker-entrypoint.sh 增加如下内容
/usr/share/elasticsearch/bin/elasticsearch-keystore create
chown root:root /usr/share/elasticsearch/config/elasticsearch.keystore
echo "$(</mnt/secret/oss/access_key)" | /usr/share/elasticsearch/bin/elasticsearch-keystore add --stdin s3.client.default.access_key
echo "$(</mnt/secret/oss/secret_key)" | /usr/share/elasticsearch/bin/elasticsearch-keystore add --stdin s3.client.default.secret_key
chown elasticsearch:elasticsearch /usr/share/elasticsearch/config/elasticsearch.keystore

1.可以看到先执行了 bin/elasticsearch-keystore create 命令,因为发行版的ES中config目录并没有elasticsearch.keystore文件,需要通过 bin/elasticsearch-keystore create 命令生成密钥库(即 config/elasticsearch.keystore 文件);

文章image3.png
注:如果不create,可以发现pod中最后也会生成密钥库,并且含有一个 seed 的密钥信息。该部分是ES启动时创建的,所以在启动之前必须create,否则执行bin/elasticsearch-keystore add 会触发一个密钥库不存在的异常; 2.可以看到先通过 chown root:root xxx 命令将config/elasticsearch.keystore文件的用户和group都设置成了root,执行完成命令后将其改回elasticsearch,因为bin/elasticsearch-keystore命令执行时对密钥库的权限有要求,pod启动是root用户,所以必须将该文件改成root权限,后续改成elasticsearch用户是为了保证container(ES)启动时的权限,ES的启动是使用elasticsearch用户; 注:该方式是在ES启动之前先将密钥加载到密钥库,ES提供另一个方式,允许在ES启动后执行 elasticsearch-keystore add 命令后再 reload,也能生效,这里不讨论。

4.测试创建repository、snapshot命令

# 创建repository
# 注:对象存储OSS不允许出现对象name中带 “/” ,所以 base_path 中 “-” 表示层级
PUT _snapshot/zmc_test_oss_repository
{
  "type": "s3",
  "settings": {
    "bucket": "es-snapshot",
    "endpoint": "http://dataplatform.xxxx.com",
    "base_path":"user-elasticsearch-uat-1067"
  }
}
# 创建snapshot
PUT /_snapshot/zmc_test_oss_repository/snapshot_1?wait_for_completion=true
{
  "indices": "zmc",
  "ignore_unavailable": true,
  "include_global_state": false,
  "metadata": {
    "taken_by": "zmc",
    "taken_because": "backup test"
  }
}
# 该命令异常:
amazon_s3_exception: Aws MultiChunkedEncoding is not supported. (Service: Amazon S3; Status Code: 400; Error Code: NotImplemented; Request ID: xxxxx; S3 Extended Request ID: es-snapshot.dataplatform.xxx.com

5.测试结果

很不幸,OSS暂时不支持MultiChunkedEncoding;(和OSS同学沟通后发现是 主集群暂时不支持,海外小集群已经支持该接口,后续会推到主集群) 这条路无法走通,继续测试其他方案;

snapshot存本地后通过juicefs上传OSS

juicefs是一个分布式文件系统,简言之就是通过juicefs程序可以将远程对象存储与本地目录关联,将文件写入本地即可上传到对象存储。该产品对ES而言比较适合作为snapshot的存储以及ES冷热分离架构中的冷数据存储。 juicefs有一定的维护成本,这里仅提供一种snapshot备份设计的新思路。对ES8而言更简要的方案可以考虑hdfs、ceph以及亚马逊的s3对象存储,弊端主要在成本和容量规划,体量较小或者公司支持较好则可以忽略。

预期架构如下:

文章image4.png
可以看到从使用层面看ES只需将snapshot存在本地目录即可完成上公有云操作; juicefs部分只需从运维层面考虑,将进程打到镜像中、或者通过CSI、静态PVC的方式均可实现。图中元数据引擎是juicefs架构中的一环,从ES使用的角度看可以忽略; 此处juicefs可以替换成任何分布式共享存储。 ----------------------------end---------------------------------

继续阅读 »

背景

1.有个向量搜索相关需求,选择使用ES8版本,并且在k8s环境中容器化部署; 2.考虑核心程度以及成本问题,不需要准备多数据中心的备份集群,为了保证数据可靠性,预期使用snapshot备份能力;

选型

ES支持将snapshot存储到各种存储产品,例如 fs(本地)、S3(或者ceph)、hdfs等。 1.OSS,考虑到已经和阿里云OSS有合作,且支持S3接口 -----> 测试 2.ceph,私有云部署,不好控制容量,成本偏高 --------> 暂不考虑 3.hdfs,私有云部署,不好控制容量,成本偏高,需要安装插件 -----> 暂不考虑 4.fs,本地,由于团队还在做juicefs产品,可以juicefs挂载到本地目录,ES snapshot 存到本地目录即可完成上传到公有云OSS ------> 测试

snapshot直接从ES传到OSS

1.创建账号、bucket,获取ak/sk;

2.ES容器实例如何加载密钥库

通过官方文档可知需要执行如下命令:将密钥设置到ES密钥库 https://www.elastic.co/guide/en/elasticsearch/reference/current/repository-s3.html

bin/elasticsearch-keystore add s3.client.default.access_key
bin/elasticsearch-keystore add s3.client.default.secret_key

考虑到容器环境不允许直接进入pod执行命令,secret也不允许直接写死到镜像中,则需要在entrypoint.sh中设置完成该命令。 最终方案如下:

文章image1.png
1.在k8s环境中创建secret,记录ak/sk信息 2.pod创建时候mount到指定目录 3.container(ES)启动的时候读取指定目录信息,并执行elasticsearch-keystore命令

3.具体操作

0.安装 repository-s3 插件 略(ES8版本内置了该插件,无需安装)

文章image2.png
1.创建secret

kubectl apply -f secret.yml

# cat secret.yml
apiVersion: v1
kind: Secret
metadata:
  namespace: uat-es
  name: es-snapshot-oss-secret
type: Opaque
data:
  access_key: xxx(注意base64编码)
  secret_key: xxx(注意base64编码)

2.修改crd的yaml,将该secret mount到指定目录

# 定义secret
  volumes:  
  - name: "oss-secret"
    secret: 
      secretName: "es-snapshot-oss-secret"

# 指定容器挂载选项
containers:
    ...
  volumeMounts:
  - mountPath: "/mnt/secret/oss"
    name: "oss-secret"
    readOnly: true

3.镜像修改 注:Dockerfile中最后是通过docker-entrypoint.sh完成ES实例的启动 ENTRYPOINT ["/usr/local/bin/docker-entrypoint.sh"]

# docker-entrypoint.sh 增加如下内容
/usr/share/elasticsearch/bin/elasticsearch-keystore create
chown root:root /usr/share/elasticsearch/config/elasticsearch.keystore
echo "$(</mnt/secret/oss/access_key)" | /usr/share/elasticsearch/bin/elasticsearch-keystore add --stdin s3.client.default.access_key
echo "$(</mnt/secret/oss/secret_key)" | /usr/share/elasticsearch/bin/elasticsearch-keystore add --stdin s3.client.default.secret_key
chown elasticsearch:elasticsearch /usr/share/elasticsearch/config/elasticsearch.keystore

1.可以看到先执行了 bin/elasticsearch-keystore create 命令,因为发行版的ES中config目录并没有elasticsearch.keystore文件,需要通过 bin/elasticsearch-keystore create 命令生成密钥库(即 config/elasticsearch.keystore 文件);

文章image3.png
注:如果不create,可以发现pod中最后也会生成密钥库,并且含有一个 seed 的密钥信息。该部分是ES启动时创建的,所以在启动之前必须create,否则执行bin/elasticsearch-keystore add 会触发一个密钥库不存在的异常; 2.可以看到先通过 chown root:root xxx 命令将config/elasticsearch.keystore文件的用户和group都设置成了root,执行完成命令后将其改回elasticsearch,因为bin/elasticsearch-keystore命令执行时对密钥库的权限有要求,pod启动是root用户,所以必须将该文件改成root权限,后续改成elasticsearch用户是为了保证container(ES)启动时的权限,ES的启动是使用elasticsearch用户; 注:该方式是在ES启动之前先将密钥加载到密钥库,ES提供另一个方式,允许在ES启动后执行 elasticsearch-keystore add 命令后再 reload,也能生效,这里不讨论。

4.测试创建repository、snapshot命令

# 创建repository
# 注:对象存储OSS不允许出现对象name中带 “/” ,所以 base_path 中 “-” 表示层级
PUT _snapshot/zmc_test_oss_repository
{
  "type": "s3",
  "settings": {
    "bucket": "es-snapshot",
    "endpoint": "http://dataplatform.xxxx.com",
    "base_path":"user-elasticsearch-uat-1067"
  }
}
# 创建snapshot
PUT /_snapshot/zmc_test_oss_repository/snapshot_1?wait_for_completion=true
{
  "indices": "zmc",
  "ignore_unavailable": true,
  "include_global_state": false,
  "metadata": {
    "taken_by": "zmc",
    "taken_because": "backup test"
  }
}
# 该命令异常:
amazon_s3_exception: Aws MultiChunkedEncoding is not supported. (Service: Amazon S3; Status Code: 400; Error Code: NotImplemented; Request ID: xxxxx; S3 Extended Request ID: es-snapshot.dataplatform.xxx.com

5.测试结果

很不幸,OSS暂时不支持MultiChunkedEncoding;(和OSS同学沟通后发现是 主集群暂时不支持,海外小集群已经支持该接口,后续会推到主集群) 这条路无法走通,继续测试其他方案;

snapshot存本地后通过juicefs上传OSS

juicefs是一个分布式文件系统,简言之就是通过juicefs程序可以将远程对象存储与本地目录关联,将文件写入本地即可上传到对象存储。该产品对ES而言比较适合作为snapshot的存储以及ES冷热分离架构中的冷数据存储。 juicefs有一定的维护成本,这里仅提供一种snapshot备份设计的新思路。对ES8而言更简要的方案可以考虑hdfs、ceph以及亚马逊的s3对象存储,弊端主要在成本和容量规划,体量较小或者公司支持较好则可以忽略。

预期架构如下:

文章image4.png
可以看到从使用层面看ES只需将snapshot存在本地目录即可完成上公有云操作; juicefs部分只需从运维层面考虑,将进程打到镜像中、或者通过CSI、静态PVC的方式均可实现。图中元数据引擎是juicefs架构中的一环,从ES使用的角度看可以忽略; 此处juicefs可以替换成任何分布式共享存储。 ----------------------------end---------------------------------

收起阅读 »

Observability:如何使用 Elastic Agents 把定制的日志摄入到 Elasticsearch 中

在我之前的文章 “Observability:使用 Elastic Agent 来摄入日志及指标 - Elastic Stack 8.0”,我详细地描述了如何安装 Elasticsearch,Stack 及 Elastic Agents 来采集系统日志及指标。很多开发者可能会有疑问,在我们的实际使用中,我们更多的可能是需要采集定制的应用日志,而不是系统日志。那么在这个时候,我们该如何使用 Elastic Agents 来把这些日志摄入呢?在以前的系统中,我们可以使用如下的几种方式来采集日志:

原文链接:https://elasticstack.blog.csdn ... 36634
继续阅读 »
在我之前的文章 “Observability:使用 Elastic Agent 来摄入日志及指标 - Elastic Stack 8.0”,我详细地描述了如何安装 Elasticsearch,Stack 及 Elastic Agents 来采集系统日志及指标。很多开发者可能会有疑问,在我们的实际使用中,我们更多的可能是需要采集定制的应用日志,而不是系统日志。那么在这个时候,我们该如何使用 Elastic Agents 来把这些日志摄入呢?在以前的系统中,我们可以使用如下的几种方式来采集日志:

原文链接:https://elasticstack.blog.csdn ... 36634 收起阅读 »

Elasticsearch:部署 ECE (Elastic Cloud Enterprise)

Elasticsearch 公司提供 Elastic Cloud Enterprise (ECE),它与 Elasticsearch Cloud (https://www.elastic.co/cloud) 中使用的工具相同,并且免费提供。 该解决方案可在 AWS、Azure 或 GCP 上的平台即服务 (PaaS) 上使用,可以在本地安装以在 Elasticsearch 之上提供企业解决方案。如果你需要跨团队或跨地域管理多个 Elastic 部署,你可以利用 ECE 集中部署管理以实现以下功能:

供应
监控
扩展
复制
升级
备份和恢复
使用 ECE 集中管理部署可强制实施统一的版本控制、数据治理、备份和用户策略。 通过更好的管理提高硬件利用率也可以降低总成本。

前提条件
由于此解决方案针对大量服务器的大型安装,因此最低测试要求是 8 GB RAM 节点。 ECE 解决方案依赖于 Docker 的安装,因此 Docker 必须安装在节点上。ECE 仅支持部分操作系统; 兼容性矩阵可在线获取 Support Matrix | Elastic。在其他配置上,ECE 可以工作,但在出现问题时不受支持。

原文链接:https://elasticstack.blog.csdn ... 90247
继续阅读 »
Elasticsearch 公司提供 Elastic Cloud Enterprise (ECE),它与 Elasticsearch Cloud (https://www.elastic.co/cloud) 中使用的工具相同,并且免费提供。 该解决方案可在 AWS、Azure 或 GCP 上的平台即服务 (PaaS) 上使用,可以在本地安装以在 Elasticsearch 之上提供企业解决方案。如果你需要跨团队或跨地域管理多个 Elastic 部署,你可以利用 ECE 集中部署管理以实现以下功能:

供应
监控
扩展
复制
升级
备份和恢复
使用 ECE 集中管理部署可强制实施统一的版本控制、数据治理、备份和用户策略。 通过更好的管理提高硬件利用率也可以降低总成本。

前提条件
由于此解决方案针对大量服务器的大型安装,因此最低测试要求是 8 GB RAM 节点。 ECE 解决方案依赖于 Docker 的安装,因此 Docker 必须安装在节点上。ECE 仅支持部分操作系统; 兼容性矩阵可在线获取 Support Matrix | Elastic。在其他配置上,ECE 可以工作,但在出现问题时不受支持。

原文链接:https://elasticstack.blog.csdn ... 90247 收起阅读 »

Elasticsearch:字段太多, 在 Elasticsearch 中防止映射爆炸的 3 种方法

当一个系统具有三样东西时,它就被称为“可观察的”:日志、指标和跟踪。 虽然指标和跟踪具有可预测的数据结构,但日志(尤其是应用程序日志)通常是非结构化数据,需要收集和解析才能真正有用。 因此,控制日志可以说是实现可观察性最难的部分。如果你想了解如何把一个数据进行结构化,请参考我之前的文章 “Elasticsearch:Elastic可观测性 - 运用 pipeline 使数据结构化”。你可以在 “Elastic:开发者上手指南” 查找更多的文章。

在本文中,我们将深入探讨开发人员可以用来通过 Elasticsearch 管理日志的三种有效策略。

[相关文章:利用 Elastic 改善云中的数据管理和可观察性]

让 Elasticsearch 为你的数据工作
有时我们无法控制我们在集群中收到的日志类型。 想想一个日志分析提供商,它有一个特定的预算来存储其客户的日志,并且需要保持存储空间(Elastic 在咨询中处理了许多类似的案例)。

通常情况下,我们有客户索引字段 “以防万一” 他们需要用于搜索。 如果你是这种情况,那么以下技术在帮助你降低成本并将集群性能集中在真正重要的事情上应该被证明是有价值的。

让我们首先概述问题。 考虑以下具有三个字段的 JSON 文档:message、transaction.user、transaction.amount:

{
 "message": "2023-06-01T01:02:03.000Z|TT|Bob|3.14|hello",
 "transaction": {
   "user": "bob",
   "amount": 3.14
 }
}
将保存此类文档的索引的映射可能类似于以下内容:

PUT dynamic-mapping-test
{
 "mappings": {
   "properties": {
     "message": {
       "type": "text"
     },
     "transaction": {
       "properties": {
         "user": {
           "type": "keyword"
         },
         "amount": {
           "type": "long"
         }
       }
     }
   }
 }
}
但是,Elasticsearch 允许我们为新字段编制索引,而不必事先指定映射,这也是 Elasticsearch 易于使用的部分原因:我们可以轻松载入新数据。 因此,可以对偏离原始映射的内容进行索引,
 
更多阅读 https://elasticstack.blog.csdn ... 59151
继续阅读 »
当一个系统具有三样东西时,它就被称为“可观察的”:日志、指标和跟踪。 虽然指标和跟踪具有可预测的数据结构,但日志(尤其是应用程序日志)通常是非结构化数据,需要收集和解析才能真正有用。 因此,控制日志可以说是实现可观察性最难的部分。如果你想了解如何把一个数据进行结构化,请参考我之前的文章 “Elasticsearch:Elastic可观测性 - 运用 pipeline 使数据结构化”。你可以在 “Elastic:开发者上手指南” 查找更多的文章。

在本文中,我们将深入探讨开发人员可以用来通过 Elasticsearch 管理日志的三种有效策略。

[相关文章:利用 Elastic 改善云中的数据管理和可观察性]

让 Elasticsearch 为你的数据工作
有时我们无法控制我们在集群中收到的日志类型。 想想一个日志分析提供商,它有一个特定的预算来存储其客户的日志,并且需要保持存储空间(Elastic 在咨询中处理了许多类似的案例)。

通常情况下,我们有客户索引字段 “以防万一” 他们需要用于搜索。 如果你是这种情况,那么以下技术在帮助你降低成本并将集群性能集中在真正重要的事情上应该被证明是有价值的。

让我们首先概述问题。 考虑以下具有三个字段的 JSON 文档:message、transaction.user、transaction.amount:

{
 "message": "2023-06-01T01:02:03.000Z|TT|Bob|3.14|hello",
 "transaction": {
   "user": "bob",
   "amount": 3.14
 }
}
将保存此类文档的索引的映射可能类似于以下内容:

PUT dynamic-mapping-test
{
 "mappings": {
   "properties": {
     "message": {
       "type": "text"
     },
     "transaction": {
       "properties": {
         "user": {
           "type": "keyword"
         },
         "amount": {
           "type": "long"
         }
       }
     }
   }
 }
}
但是,Elasticsearch 允许我们为新字段编制索引,而不必事先指定映射,这也是 Elasticsearch 易于使用的部分原因:我们可以轻松载入新数据。 因此,可以对偏离原始映射的内容进行索引,
 
更多阅读 https://elasticstack.blog.csdn ... 59151 收起阅读 »

Elasticsearch:如何部署 NLP:命名实体识别 (NER) 示例

在本文章中,我们将通过一个示例,使用命名实体识别 (NER - Name Entity Recognition) NLP 模型来定位和提取非结构化文本字段中预定义的实体类别。 使用公开可用的模型,我们将向你展示如何将该模型部署到 Elasticsearch,使用新的 _infer API在文本中查找命名实体,并在提取管道中使用 NER 模型在文档被提取到 Elasticsearch 时提取实体。

NER 模型对于使用自然语言从全文字段中提取人物(people)、地点(places)和组织(organization)等实体很有用。

在此示例中,我们将通过 NER 模型运行《悲惨世界》一书的段落,并使用该模型从文本中提取字符和位置,并将它们之间的关系可视化。

更多关于 NLP 的阅读:

Elasticsearch:如何部署 NLP:文本嵌入和向量搜索

在 Elasticsearch 中使用 PyTorch 进行现代自然语言处理的介绍

Elasticsearch:如何部署 NLP:情绪分析示例

安装
如果你还没有安装好自己的 Elasticsearch,Kibana 及 Eland,那么请阅读之前的文章 “Elasticsearch:如何部署 NLP:文本嵌入和向量搜索”。

将 NER 模型部署到 Elasticsearch
首先,我们需要选择一个可以从文本字段中提取字符名称和位置的 NER 模型。 幸运的是,我们可以在 Hugging Face 上选择一些可用的 NER 模型,并查看 Elastic 文档,我们看到一个 uncased NER model from Elastic  模型。

现在我们已经选择了要使用的 NER 模型,我们可以使用 Eland 来安装模型。 在本例中,我们将通过 docker 镜像运行 Eland 命令,但首先我们必须通过克隆 Eland GitHub 存储库来构建 docker 镜像,并在你的客户端系统上创建 Eland 的 docker 镜像。详细步骤请在文章  “Elasticsearch:如何部署 NLP:文本嵌入和向量搜索”。中进行查看,这里就不再赘述了。

我们接下来使用如下的命令来上传模型:

docker run -it --rm elastic/eland \
    eland_import_hub_model \
      --url https://elastic:lOwgBZT3KowJrQ ... 9200/ \
      --hub-model-id elastic/distilbert-base-uncased-finetuned-conll03-english \
      --task-type ner \
      --insecure \
      —-start 
注意:请根据自己的用户账号信息更新 --url 选项中的 Elasticsearch 信息。由于我们使用的是自签名的证书部署的,在这里,我们使用 --insecure 来规避 SSL 签名证书的检查。

由于我们在 eland import 命令末尾使用了 --start 选项,因此 Elasticsearch 会将模型部署到所有可用的机器学习节点并将模型加载到内存中。 如果我们有多个模型并且想要选择要部署的模型,我们可以使用 Kibana 的机器学习 > 模型管理用户界面来管理模型的启动和停止。

原文链接:https://blog.csdn.net/UbuntuTo ... 77711
继续阅读 »
在本文章中,我们将通过一个示例,使用命名实体识别 (NER - Name Entity Recognition) NLP 模型来定位和提取非结构化文本字段中预定义的实体类别。 使用公开可用的模型,我们将向你展示如何将该模型部署到 Elasticsearch,使用新的 _infer API在文本中查找命名实体,并在提取管道中使用 NER 模型在文档被提取到 Elasticsearch 时提取实体。

NER 模型对于使用自然语言从全文字段中提取人物(people)、地点(places)和组织(organization)等实体很有用。

在此示例中,我们将通过 NER 模型运行《悲惨世界》一书的段落,并使用该模型从文本中提取字符和位置,并将它们之间的关系可视化。

更多关于 NLP 的阅读:

Elasticsearch:如何部署 NLP:文本嵌入和向量搜索

在 Elasticsearch 中使用 PyTorch 进行现代自然语言处理的介绍

Elasticsearch:如何部署 NLP:情绪分析示例

安装
如果你还没有安装好自己的 Elasticsearch,Kibana 及 Eland,那么请阅读之前的文章 “Elasticsearch:如何部署 NLP:文本嵌入和向量搜索”。

将 NER 模型部署到 Elasticsearch
首先,我们需要选择一个可以从文本字段中提取字符名称和位置的 NER 模型。 幸运的是,我们可以在 Hugging Face 上选择一些可用的 NER 模型,并查看 Elastic 文档,我们看到一个 uncased NER model from Elastic  模型。

现在我们已经选择了要使用的 NER 模型,我们可以使用 Eland 来安装模型。 在本例中,我们将通过 docker 镜像运行 Eland 命令,但首先我们必须通过克隆 Eland GitHub 存储库来构建 docker 镜像,并在你的客户端系统上创建 Eland 的 docker 镜像。详细步骤请在文章  “Elasticsearch:如何部署 NLP:文本嵌入和向量搜索”。中进行查看,这里就不再赘述了。

我们接下来使用如下的命令来上传模型:

docker run -it --rm elastic/eland \
    eland_import_hub_model \
      --url https://elastic:lOwgBZT3KowJrQ ... 9200/ \
      --hub-model-id elastic/distilbert-base-uncased-finetuned-conll03-english \
      --task-type ner \
      --insecure \
      —-start 
注意:请根据自己的用户账号信息更新 --url 选项中的 Elasticsearch 信息。由于我们使用的是自签名的证书部署的,在这里,我们使用 --insecure 来规避 SSL 签名证书的检查。

由于我们在 eland import 命令末尾使用了 --start 选项,因此 Elasticsearch 会将模型部署到所有可用的机器学习节点并将模型加载到内存中。 如果我们有多个模型并且想要选择要部署的模型,我们可以使用 Kibana 的机器学习 > 模型管理用户界面来管理模型的启动和停止。

原文链接:https://blog.csdn.net/UbuntuTo ... 77711 收起阅读 »

Elasticsearch:Elastic Maps 现在支持机器学习异常层

现在可以在 Elastic Maps 中查看使用 geographical functions 的机器学习 (ML) 异常检测作业的结果。 Elastic Maps 8.1.0 版本可以按位置生成异常地图,帮助你探索数据中的新趋势。

Elastic Maps 在 Elastic Cloud 上可用。 你还可以下载 Elastic Stack 和我们的云编排产品 Elastic Cloud Enterprise (ECE) 和 Elastic Cloud for Kubernetes (ECK),以获得自我管理的体验。

在此示例中,我们将使用通用运输饲料规范 (GTFS) 数据。 GTFS 定义了公共交通时刻表和相关地理信息的通用格式。

在下面的展示中,我将使用 Elastic Stack 8.2 来进行展示。

Geographical functions
地理功能检测输入数据的地理位置异常。lat_long 函数检测输入数据的地理位置异常。

注意:你不能为包含地理函数的异常检测作业创建预测。 你也不能将带有条件的规则添加到使用地理函数的检测器中。

该函数支持以下属性:

field_name (required)
by_field_name (optional)
over_field_name (optional)
partition_field_name (optional)
比如,我们在如下的例子中,使用 lat_long 函数来分析信用卡交易的异常:

PUT _ml/anomaly_detectors/example1
{
  "analysis_config": {
    "detectors": [{
      "function" : "lat_long",
      "field_name" : "transaction_coordinates",
      "by_field_name" : "credit_card_number"
    }]
  },
  "data_description": {
    "time_field":"timestamp",
    "time_format": "epoch_ms"
  }
}
我们知道,在通常的情况下,你的信用卡不可能在一个很小的时间范围里,在美国和中国同时耍卡,除非飞机飞的真的很快很快。如果你在异常检测作业的检测器中使用此 lat_long 函数,它会检测到信用卡交易的地理位置对于特定客户的信用卡而言的异常。 异常可能表明存在欺诈。

重要:你提供的 field_name 必须是一个字符串,其中包含两个逗号分隔的数字,格式为纬度、经度、geo_point 字段、包含点值的 geo_shape 字段或 geo_centroid 聚合。 纬度和经度必须在 -180 到 180 的范围内,并且代表地球表面上的一个点。

比如,JSON 数据可能包含以下交易坐标:

{
  "time": 1460464275,
  "transaction_coordinates": "40.7,-74.0",
  "credit_card_number": "1234123412341234"
}
在 Elasticsearch 中,位置数据很可能存储在 geo_point 字段中。 有关详细信息,请参阅 geo_point 数据类型。 机器学习功能原生支持此数据类型。 具体来说,当从 geo_point 字段中提取数据时,datafeed 将在发送到异常检测作业之前将数据转换为适当的纬度、经度字符串格式。
Elasticsearch:Elastic Maps 现在支持机器学习异常层原文链接:https://blog.csdn.net/UbuntuTo ... 58783
继续阅读 »
现在可以在 Elastic Maps 中查看使用 geographical functions 的机器学习 (ML) 异常检测作业的结果。 Elastic Maps 8.1.0 版本可以按位置生成异常地图,帮助你探索数据中的新趋势。

Elastic Maps 在 Elastic Cloud 上可用。 你还可以下载 Elastic Stack 和我们的云编排产品 Elastic Cloud Enterprise (ECE) 和 Elastic Cloud for Kubernetes (ECK),以获得自我管理的体验。

在此示例中,我们将使用通用运输饲料规范 (GTFS) 数据。 GTFS 定义了公共交通时刻表和相关地理信息的通用格式。

在下面的展示中,我将使用 Elastic Stack 8.2 来进行展示。

Geographical functions
地理功能检测输入数据的地理位置异常。lat_long 函数检测输入数据的地理位置异常。

注意:你不能为包含地理函数的异常检测作业创建预测。 你也不能将带有条件的规则添加到使用地理函数的检测器中。

该函数支持以下属性:

field_name (required)
by_field_name (optional)
over_field_name (optional)
partition_field_name (optional)
比如,我们在如下的例子中,使用 lat_long 函数来分析信用卡交易的异常:

PUT _ml/anomaly_detectors/example1
{
  "analysis_config": {
    "detectors": [{
      "function" : "lat_long",
      "field_name" : "transaction_coordinates",
      "by_field_name" : "credit_card_number"
    }]
  },
  "data_description": {
    "time_field":"timestamp",
    "time_format": "epoch_ms"
  }
}
我们知道,在通常的情况下,你的信用卡不可能在一个很小的时间范围里,在美国和中国同时耍卡,除非飞机飞的真的很快很快。如果你在异常检测作业的检测器中使用此 lat_long 函数,它会检测到信用卡交易的地理位置对于特定客户的信用卡而言的异常。 异常可能表明存在欺诈。

重要:你提供的 field_name 必须是一个字符串,其中包含两个逗号分隔的数字,格式为纬度、经度、geo_point 字段、包含点值的 geo_shape 字段或 geo_centroid 聚合。 纬度和经度必须在 -180 到 180 的范围内,并且代表地球表面上的一个点。

比如,JSON 数据可能包含以下交易坐标:

{
  "time": 1460464275,
  "transaction_coordinates": "40.7,-74.0",
  "credit_card_number": "1234123412341234"
}
在 Elasticsearch 中,位置数据很可能存储在 geo_point 字段中。 有关详细信息,请参阅 geo_point 数据类型。 机器学习功能原生支持此数据类型。 具体来说,当从 geo_point 字段中提取数据时,datafeed 将在发送到异常检测作业之前将数据转换为适当的纬度、经度字符串格式。
Elasticsearch:Elastic Maps 现在支持机器学习异常层原文链接:https://blog.csdn.net/UbuntuTo ... 58783 收起阅读 »