这是第几遍了？

是的，我确实有这种感觉。但是，当我建立用于验证的Elasticsearch + Kibana配置时，我遇到了一些困难，所以我打算暂时将它们记下来。

引入途径

在Ubuntu的标准仓库中，没有安装elasticsearch或kibana。
您可以从Elastic公司的网站上下载打包的tar.gz文件，或者添加Elastic公司的仓库并从那里使用pkg进行安装。

日文版本的陷阱

Elastic搜索引擎的用户指南只有到5.4版本为止的日语版！！最新版本是20220626的8.2（.3）。
要注意，如果查看日语的用户指南，将会安装一个非常老旧的软件包。
（一开始没有注意到，只安装了5.4的Kibana版本、、）
https://www.elastic.co/guide/jp/index.html

只要按照英文版用户指南中的步骤，就可以顺利进行安装。
由于没有从Ubuntu存储库进行分发，因此可以选择添加Elastic存储库，或者下载包含配置和可执行文件的tar.gz文件并进行解压缩。

（离题）tar.gz和pkg

由于一开始没有认真阅读文档，我直接从顶部导入了tar.gz文件，后来意识到错误后通过pkg重新安装了https://www.elastic.co/guide/en/elasticsearch/reference/current/install-elasticsearch.html

大致上看起来，没有什么差别。
配置方面，只有路径周围稍微做了一些pkg的调整。

< #path.data: /path/to/data
---
> path.data: /var/lib/elasticsearch
37c37
< #path.logs: /path/to/logs
---
> path.logs: /var/log/elasticsearch
93c93
< # generated to configure Elasticsearch security features on 26-06-2022 00:48:50
---
> # generated to configure Elasticsearch security features on 26-06-2022 03:52:19

然而，令人困扰的是自动生成的初始密码和用于连接Kibana的令牌。
如果在tar.gz版本中使用bin/elasticsearch进行执行，将在终端上显示自动生成的密码和令牌（有效时间为30分钟）。
而如果使用pkg进行安装，并通过systemctl启动，则无法看到它们。似乎也不会在日志中输出。

由於兩者都可以透過命令重新設定/重新生成，所以雖然有點奇怪，但這就是我們的應對方法。
嗯，或許最好的方式是在初次啟動時不使用systemctl。真是難以決定。

重置密码

如前所述，如果在初次使用systemctl的时候已经安装了包，那么自动生成的密码和令牌将变得无法识别。
此外，由于密码也是自动生成的，所以无法使用任意密码，这使得操作变得困难。
因此，重新设置是必需的处理步骤。

# /usr/share/elasticsearch/bin/elasticsearch-reset-password -i -u elastic

也有一个名为elasticsearch-setup-passwords的可执行文件，但使用它会导致错误，并要求使用reset。由于它已被宣告为过时(将在未来版本中删除)，我没有详细调查错误原因。

-i 是交互模式。如果不使用它，将会使用自动生成的密码，并且该密码会在事后显示出来。
-u 是用户指定。似乎 “elastic” 是默认特权用户的账户，所以我们要更改此账户的密码。

只需要一个选项就可以看出它是否在运行。

$ curl -k -u elastic https://localhost:9200/

默认情况下启用SSL，并为您创建了自签名证书，因此普通的curl请求会验证失败，客户端会自动取消访问。
-k选项用于禁止进行证书验证。
-u指定用户账户。执行命令后会要求输入密码，
在对话中会询问密码。在这里输入先前的密码。

令牌重新发行和Kibana的初始设置

我也是。

# /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana

您可以把在这里显示的令牌复制到Kibana上的令牌字段中，该字段将在首次访问Kibana时显示。然后，系统会要求您输入一个六位数的数字，在您登录Kibana所在的服务器后输入即可。

# /usr/share/kibana/bin/kibana-verification-code

请将显示的数字放入。

这个结构有点凌乱啊。
通过输入令牌确认是Elasticsearch服务器的所有者，然后再通过6位数字确认是Kibana服务器的所有者。
嗯，做的事情是正确的吗。
我觉得这种事情应该在Kibana的配置文件中处理，或者在Kibana服务器上运行，对吗？然后我试图给令牌设置时间限制，并且希望在浏览器这个第三方能够访问的地方进行设置，结果就变成了这样。
相比传统的将用户和密码写入配置文件的 SQL 服务器连接方式，我觉得这样要安全得多。

顺便一提，Elasticsearch的elastic用户名和密码用于在Kibana的WebUI登录时使用。

尝试导入日志并查看

我先试着上传文件。

如果只是需要上传文件，似乎可以通过Kibana进行。点击左上角的三个横线-Management/Integrations。然后向下滚动左侧选项卡，点击Upload a file。接着点击右侧的Upload a file。

首先，当我在Elastic官网上查看时，”Integrations”这个词的意思是”连接和收集集成”。
这是指用于数据采集的功能集合…我觉得你可以这样理解。
它包括了许多丰富的功能，比如AWS EC2、Box、MongoDB等。

…虽然丰富是好事，但是当我们将其用于注重运用需求的环境中时，反而会觉得里面有很多多余的东西，让人感到很不舒服。虽然现在已经不是那个时代了，但是还是有点不知所措。

如果定期地倒入的话

以下是一个中文的本地化版本：

可以选择使用Beats（Filebeat）作为中期解决方案，或者采用Filebeat + Logstash的组合方式。另外，还可以考虑使用fluentd。

暂时简单地使用filebeat进行短期处理。

# apt install filebeat

然后，配置/etc/filebeat/filebeat.yml。
https://www.elastic.co/guide/en/beats/filebeat/8.2/filebeat-installation-configuration.html

连接设置

在这个例子中，密码是以明文的形式输入的，所以要确保按照正确的方式进行操作。你可以参考以下链接了解更多相关信息：https://www.elastic.co/guide/en/beats/filebeat/8.2/keystore.html

# filebeat keystore create
Created filebeat keystore

# filebeat keystore add ES_PWD
Enter value for ES_PWD: 
Successfully updated the keystore

只需要一个选项，把以下内容以中文重新表述：
然后是将SSL指纹输入。
可以通过以下方式查询指纹。

# cat /etc/elasticsearch/certs/http_ca.crt | openssl x509 -sha256 -fingerprint -noout | cut -d "=" -f 2 | sed "s/://g"

所以，总结如下。

# cat /etc/filebeat/filebeat.yml
(抜粋)
output.elasticsearch:
  hosts: ["localhost:9200"]

  # Protocol - either `http` (default) or `https`.
  protocol: "https"

  username: "elastic"
  password: "${ES_PWD}"

  ssl:
    enabled: true
    ca_trusted_fingerprint: "<上で調べたやつ>"

如果密码设置为”${ES_PWD}”，它将使用之前在密钥库中注册的密码。如果未明确指定协议为https，它将自动使用http进行连接。这指纹问题相当麻烦，我一直纠结于它。最初我是通过openssl s_client -connect 来获取指纹的，但这将导致获取的是服务器证书的指纹。输入应该是CA的指纹（虽然如果有人告诉我应该这么写，我会知道）

可以使用令牌的方法？由于有这种可能性，所以我们需要重新审视这里。。

设置飞行记录

以”module”作为处理方式，决定跳过某些日志。
仅测试目的，跳过auditd的日志。

# filebeat modules enable auditd
Enabled auditd

模块的设置存放在/etc/filebeat/modules.d目录下，初始状态为auditd.yml.disabled。
执行上述命令后，名称会变为auditd.yml。
但是内容保持不变（enabled: false），需要按照手册进行调整。

# cat /etc/filebeat/modules.d/auditd.yml
- module: auditd
  log:
    enabled: true
    var.paths: ["/var/log/audit.log*"]

好的，接下来进行语法检查。

# filebeat test config -e

如果一连串地出现，并且最后出现了”Config OK”，那就表示OK。

那好，试试看吧。

先进行测试。

# filebeat setup -e

如果设置正确，日志会连续不断地输出，并创建名为.ds-filebeat的索引到Elasticsearch。

只要Kibana没有启动，最后就会出现错误。
Kibana似乎强制运行注册仪表板的功能。
我认为是在设置的setup.kibana部分，但是不知道禁用的方法。

终止生产

如果你要使用它，那么这是一项必须一直了解的信息。
https://www.elastic.co/jp/support/eol

「Elastic产品的支持期限从主要发布/一般公开日期开始为18个月。」如果说8.2.2中，8代表了”主要发布”，8.2代表了”次要发布”，8.2.2代表了”维护发布”，那么根据EOL列表，似乎将”次要发布”的一般公开设置为18个月。不过，看实际情况来看，7.0和8.0之间有近三年的间隔，所以应该是”次要发布的一般公开日期开始为18个月”吧，肯定是这样。

无论如何，18个月对于这个数字来说相当关键，但感觉上和RHEL差不多。
对于次要版本来说，我们可以积极地无畏地增加补丁，就像大家所说的。
以7系为例，7.0版本的发布日期是2019/4（根据GIT信息，没有找到其他可靠的来源），而（目前）7系的最后一个7.17版本的预计发布日期是2023/8/2的9.0.0版本。
如果积极地更新次要版本，那么将会持续约4年多。

如果是Ubuntu，LTS版本也会在那个时候终止支持。

暫時，在cvedetails上並未找到Elasticsearch過去的弱點信息，但這反而讓人感到害怕。
而且，由於Java是一同發布的，一旦Java出現弱點，很容易被忽視。
或許還是那邊更令人害怕。
我們可以再來瀏覽一下附帶的Java版本。

暫時先做

今天就到这里吧。
对于导入的数据进行分析之类的事情还没有做，所以真的不确定是否导入成功，这方面之后再说。
另外，安全设置/运营（漏洞管理）需要仔细考虑一次，否则可能会有问题。
而且资源问题的考虑方式，要做的事情真的很多。。