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 页面：

• [http://console.infinilabs.com/ ... otes/](http://console.infinilabs.com/ ... notes/)
  
  欢迎大家下载体验，下载安装及文档地址：
  
  
• [http://console.infinilabs.com/](http://console.infinilabs.com/)

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

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

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

背景

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/e ... .html
<br /> bin/elasticsearch-keystore add s3.client.default.access_key<br /> bin/elasticsearch-keystore add s3.client.default.secret_key<br />
考虑到容器环境不允许直接进入pod执行命令，secret也不允许直接写死到镜像中，则需要在entrypoint.sh中设置完成该命令。
最终方案如下：

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

3.具体操作

0.安装 repository-s3 插件
略（ES8版本内置了该插件，无需安装）

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编码)
<br /> 2.修改crd的yaml，将该secret mount到指定目录<br />

定义secret

volumes:

• name: "oss-secret"
  secret:
  secretName: "es-snapshot-oss-secret"
  
  

  指定容器挂载选项
  

  containers:
  ...
  volumeMounts:
  

• mountPath: "/mnt/secret/oss"
  name: "oss-secret"
  readOnly: true
  <br /> 3.镜像修改<br /> 注：Dockerfile中最后是通过docker-entrypoint.sh完成ES实例的启动<br /> ENTRYPOINT ["/usr/local/bin/docker-entrypoint.sh"]<br />
  

  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 文件）；
  

  

  
  注：如果不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": "<a href="http://dataplatform.xxxx.com"" rel="nofollow" target="_blank">http://dataplatform.xxxx.com",
  "base_path":"user-elasticsearch-uat-1067"
  }
  }
  <br />
  

  创建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对象存储，弊端主要在成本和容量规划，体量较小或者公司支持较好则可以忽略。
  
  预期架构如下：
  

  

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

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

原文链接：https://elasticstack.blog.csdn ... 36634