ELK极简上手

引言

首先，下载相关的包

其次，安装启动elasticsearch

下一步，安装并启动logstash

最后，安装并启动kibana

进一步的，测试数据的流动

引言

最近整理电脑发现之前的一篇ELK极简入门笔记，现整理发出来，希望对感兴趣的小伙伴有帮助。

要说ELK是什么，我们先给一个引子。早期，计算机方面比较实用的技术是体系结构相关的内容。那时候，各个大学的计算机系主任大部分是体系结构方面的专家；后来，算法逐渐占据上风，开始流行起来，当年微软将谷歌作为最大的竞争对手，不无道理；再后来，人工智能开始如滔天大浪席卷了几乎所有高科技公司和高校，现在再去看各个高校的计算机系主任，不沾点人工智能的边都不好意思把简历放出来。在这个历史过程中，搜索算法一度被认为是算法皇冠上的明珠，尤其是在互联网大潮来临后，数据生产呈现爆炸式增长，如何快速准确的检索需要的数据，成为了算法工程师的终极梦想。这方面的技术仍然在不断的进化演进，ELK就是在大数据领域的一个搜索引擎成果包。简而言之，ELK由三个子包构成，E代表elasticsearch，可升缩的查找引擎；L代表logstash，这里我们比较通用的将其理解为数据解析转换器，而非日志；K代表kibana，可视化的一套组件。放在一起就是，logstash将生产的数据，按照规则，解析过滤转换为结构化的数据，提交给elasticsearch，kibana提供简洁丰富的可视化界面，方便用户查找elasticsearch中的数据。

下面看看如何搭建最基本的ELK环境。

首先，下载相关的包

官网国内下载地址过慢，可以找国内镜像下载

https://elasticsearch.thans.cn/downloads/logstash/logstash-6.4.3.tar.gz

https://artifacts.elastic.co/downloads/logstash/logstash-6.4.3.tar.gz

其次，安装启动elasticsearch

elastic 高版本出现一些错误打印，不再研究，考虑下载低版本

下载6.4版本，启动，提示killed

修改config目录下的jvm options配置文件，将虚拟机内存要求降低，从1G到512M

再次运行，提示错误can not run elasticsearch as root

因为安全问题elasticsearch 不让用root用户直接运行，所以要创建新用户，用非root用户启动，提示

Exception in thread "main" java.nio.file.AccessDeniedException: /home/work/ELK/elasticsearch-6.4.3/config/jvm.options

是因为目录没有非root用户的执行权限，用root用户chmod -R 777 安装目录

然后再次启动elasticsearch，成功

在机器内部执行curl -get http://127.0.0.1:9200可以访问，说明elasticsearch启动成功

curl -get http://127.0.0.1:9200

{

  "name" : "DxD9f_v",

  "cluster_name" : "elasticsearch",

  "cluster_uuid" : "7z49ZWMyQR2QYdCfghiVkg",

  "version" : {

    "number" : "6.4.3",

    "build_flavor" : "default",

    "build_type" : "tar",

    "build_hash" : "fe40335",

    "build_date" : "2018-10-30T23:17:19.084789Z",

    "build_snapshot" : false,

    "lucene_version" : "7.4.0",

    "minimum_wire_compatibility_version" : "5.6.0",

    "minimum_index_compatibility_version" : "5.0.0"

  },

  "tagline" : "You Know, for Search"

}

但是外部网络访问不了，打开config下的yml配置文件，将里面的net host项打开，并指定外部访问的IP地址 0.0.0.0

重启服务，提示max fs过小，vm max mem过小

对max fs过小，按照网上的，修改/etc/security/limits配置文件，将65535改成65536

对于vm max mem过小，按照网上修改，将/etc/sysctl.conf配置文件，增加一行vm配置，按照elasticsearch启动时提示的错误信息，补充需要的大小，21xxx44

执行sysctl -p 使配置生效

对于第一个修改的生效，需要重新登录

之后，再次启动elasticsearch成功，在浏览器中访问192.168.0.108:9200 成功

向elasticsearch插入数据，需要指定头部

curl -XPUT 'http://localhost:9200/twitter/_doc/1?pretty' -H 'Content-Type: application/json' -d '

{

    "user": "kimchy",

    "post_date": "2009-11-15T13:12:00",

    "message": "Trying out Elasticsearch, so far so good?"

}'

获取内容

curl -XGET 'http://localhost:9200/twitter/_doc/1?pretty=true'

{

  "_index" : "twitter",

  "_type" : "_doc",

  "_id" : "1",

  "_version" : 1,

  "found" : true,

  "_source" : {

    "user" : "kimchy",

    "post_date" : "2009-11-15T13:12:00",

    "message" : "Trying out Elasticsearch, so far so good?"

  }

}

查看elasticsearch的状态

curl -X GET "localhost:9200/_cat"

可以查看到支持命令列表

 =^.^=

/_cat/allocation

/_cat/shards

/_cat/shards/{index}

/_cat/master

/_cat/nodes

/_cat/tasks

/_cat/indices

/_cat/indices/{index}

/_cat/segments

/_cat/segments/{index}

/_cat/count

/_cat/count/{index}

/_cat/recovery

/_cat/recovery/{index}

/_cat/health

/_cat/pending_tasks

/_cat/aliases

/_cat/aliases/{alias}

/_cat/thread_pool

/_cat/thread_pool/{thread_pools}

/_cat/plugins

/_cat/fielddata

/_cat/fielddata/{fields}

/_cat/nodeattrs

/_cat/repositories

/_cat/snapshots/{repository}

/_cat/templates

查看节点健康状态

curl -X GET "localhost:9200/_cat/health?v"

epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent

1699100535 20:22:15  elasticsearch yellow          1         1     30  30    0    0       15             0                  -                 66.7%

查看节点的状态

curl -X GET "localhost:9200/_cat/nodes?v"

ip           heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name

192.168.0.99           60          96   2    0.00    0.00     0.00 mdi       *      DxD9f_v

查看索引

curl -X GET "localhost:9200/_cat/indices?v"

health status index                           uuid                   pri rep docs.count docs.deleted store.size pri.store.size

green  open   .monitoring-kibana-6-2020.04.05 dEiKRojsQv-o22ZL7POLVA   1   0      25917            0      3.2mb          3.2mb

green  open   .monitoring-es-6-2020.04.05     dosbfiHqR_uQcDNS6KTXGw   1   0      95077          200     36.2mb         36.2mb

yellow open   bank                            9X6hpCfMRgG0Hg_pldRghA   5   1       1000            0      483kb          483kb

yellow open   blog                            TWYzd5SgRsCR5VEu1szVSg   5   1       1110            0    329.1kb        329.1kb

green  open   .monitoring-es-6-2020.04.12     L2kP2a1sRJmYv32WJiR9ug   1   0      34872            0     14.9mb         14.9mb

green  open   .monitoring-kibana-6-2020.04.13 7JMe7HYlQaKr_SEAocLXuA   1   0         15            0     81.4kb         81.4kb

green  open   .monitoring-es-6-2020.04.06     VIwdUGpxQ_q3GUNDaiBrFQ   1   0      10283          216        5mb            5mb

green  open   .monitoring-kibana-6-2020.04.04 L3uJIJ9GQ2WxtDFUVqT0Xg   1   0      13629            0      1.9mb          1.9mb

yellow open   test                            3wkfLrXHRXS-HZsWXkDYjg   5   1          2            0     10.8kb         10.8kb

green  open   .monitoring-kibana-6-2020.04.12 7okTRX0VTrya7qCKusG6kQ   1   0       9184            0      1.1mb          1.1mb

green  open   .monitoring-kibana-6-2020.04.06 Bq9YykB7Smi3IqY7KqSUew   1   0       2361            0      326kb          326kb

green  open   .monitoring-es-6-2020.04.04     X05uCpFqTtupA5x9OKFCvA   1   0      45040           46     16.7mb         16.7mb

green  open   .monitoring-kibana-6-2020.04.08 bpTl2-TdSn6hRKFG2WdPlQ   1   0          8            0     48.3kb         48.3kb

green  open   .monitoring-es-6-2020.04.13     ku_cSQXDRIG88gKRmZy3cw   1   0        147           44    234.6kb        234.6kb

green  open   .monitoring-es-6-2020.04.07     _GTr8c30Q1iam0Jq49MacQ   1   0      27084          203     11.2mb         11.2mb

green  open   .monitoring-kibana-6-2020.04.07 or0a2MePRuiQ815Q7SQKlw   1   0       7180            0   1000.2kb       1000.2kb

green  open   .monitoring-es-6-2023.11.04     UDOLcrBPSRGo0w_5XGuxuQ   1   0       3674          135      2.1mb          2.1mb

green  open   .kibana                         32YGBWOgSTK5cxPAyz1ZUA   1   0          5            0     27.5kb         27.5kb

查看索引的文档，如果不存在，会提示错误

curl -X GET "localhost:9200/_cat/indices/blog"

yellow open blog TWYzd5SgRsCR5VEu1szVSg 5 1 1110 0 329.1kb 329.1kb

查询索引中的数据，pretty会让数据美化输出，主要是按照层次结构输出，下面命令中，search应该是内置命令字

curl -X GET "localhost:9200/blog/_search?pretty"

执行accounts数据示例，注意，会提示bulk命令需要一个回车换行，其实是在accounts文件尾部增加一个回车换行

curl -H "Content-Type: application/json" -XPOST "localhost:9200/bank/_doc/_bulk?pretty&refresh" --data-binary "@accounts.json"

现在就向elasticsearch中增加了bank这个索引，并有1000个文档数据

curl "localhost:9200/_cat/indices?v"

查询所有索引，可以看到有bank索引

检索特定索引，这里是刚创建的bank索引

curl -X GET "localhost:9200/bank/_search?q=*&sort=account_number:asc&pretty"

？后面是参数列表，以&分割。q表示匹配所有参数，sort表示按照accountsnumber升序排列，pretty表示美化输出

以上可以在安装包的Readme中查找到使用例子

===========================================================

下一步，安装并启动logstash

logstash-6.4.3/bin/logstash --help

Unrecognized VM option 'UseParNewGC'

Error: Could not create the Java Virtual Machine.

Error: A fatal exception has occurred. Program will exit.

注释掉config/jvm.options文件中的 -XX:+UseParNewGC 行即可

运行出现exit，查看输出日志，是因为更新了JDK到11所致，这个版本的JDK需要降低，使用jdk1.8.0，Logstash启动成功。

===========================================================

最后，安装并启动kibana

发现启动kibana后，elasticsearch就会出现killed

进一步分析发现，kibana在启动过程中会连接elasticsearch

对于killed现象初步分析可能是jvm 内存出错导致，很可能是内存不够

之前的Hadoop相关java进程都是以1g内存参数启动jvm的，在elasticsearch中将其修改为512了，这一点上两块使用java前后有所不同步

其次，是否是因为这些java进程的存在，消耗了大量jvm内存，导致后面再开新的java进程会崩溃，由于内存不够

关闭Hadoop相关进程，使用jps，重新运行elasticsearch和kibana，成功，可以通过web看到kibana的页面

jps只有elasticsearch一个进程，kibana难道不是java进程启动？？？？

原来因为kibana是使用node.js写的，所以进程在node中。但是查找到的node进程不一定就是kibana的，

所以还需要根据端口进一步确认，直接查看5601端口的占用情况，确定下进程ID，然后在查看下node进程的ID,

如果一致，就可以确定该node进程就是kibana的进程了。

这是很关键的一点。之前出现过关闭elasticsearch后，再次启动elasticsearch后，出现kibana启动后卡住，CPU占比接近100%的情况

无意中发现此时kibana的web端仍然是可用工作的，才想起来它可能在后台工作，并没有退出。

此时，可通过netstat 查看5601端口是否仍然在工作

netstat -anlp | grep 5601

(Not all processes could be identified, non-owned process info

will not be shown, you would have to be root to see it all.)

tcp 0 0 0.0.0.0:5601 0.0.0.0:* LISTEN 78985/bin/../node/b

进一步的找到进程78985

ps aux | grep 78985

ywg 78985 1.2 8.3 1439760 184632 ? Sl 06:59 2:37 bin/../node/bin/node --no-warnings bin/../src/cli

此即为kibana关联的node进程

===========================================================

进一步的，测试数据的流动

Logstash 的配置文件中使用了网络的例子，

input {

  file {

    path => "/var/log/bootstrap.log"         

    start_position => "beginning"

    type => "test"

  }

}

输入使用了上述日志文件，并以beginning为开始标记

使用echo命令向上述日志文件中增加内容，可以在Logstash的日志中看到新内容解析

{

    "message" => "Mytest ELK",

    "@timestamp" => 2023-11-04T14:20:08.571Z,

          "path" => "/var/log/bootstrap.log",

          "type" => "test",

          "tags" => [

        [0] "_grokparsefailure"

    ],

    "host" => "ubuntu",

    "@version" => "1"

}

从kibana中可以看到日志信息及统计信息变化