注意：不同版本的JDK可能略有差异
|
|
jps(Java Virtual Machine Process Status Tool)。jps只是用来显示Java进程信息，用来查看基于HotSpot的JVM里面中，所有具有访问权限的Java进程的具体状态, 包括进程ID，进程启动的路径及启动参数等等。
如果使用jps查看远程服务器的Java进程信息，需要在远程服务器上开启jstatd服务。
|
|
通过help提示可以看出基本的命令格式
|
|
|
|
参考文章：
前阵子MongoDB和Elasticsearch被黑客利用漏洞入侵并删除数据的事情闹得沸沸扬扬，我们公司使用Elasticsearch也是受害者之一，幸好我们使用Elasticsearch只是应用日志数据，不涉及到业务数据，所以被删除的日志数据对我们影响不是很大。这里我总结一下我们遇到的问题，和处理措施。
Elasticsearch被黑客入侵的事情发生在2017年1月份，当时Elasticsearch技术群有人遇到了索引数据无故丢失的现象，然后出现非法的.warning索引，正好当天我也发现我们Elasticsearch的索引也少了几天的日志索引，打开.warning索引之后发现类似如下信息。
索引的描述信息说明你的数据已经被backup到黑客的服务器上，如果想要恢复需要给他们0.5比特币。
看来这回是真的中招了，开始分析黑客能够入侵的原因。首先想到的就是先把ES的http端口9200禁止对外开放，以前是为了维护ES索引方便，所以把9200端口对外网开放了，虽然做了外网IP的访问控制，但是仍然被入侵进来，说明对外开放ES的9200端口并不安全。然后开始检查服务器的防火墙，对外网开放的IP过滤情况。这里我检查了服务器本身的防火墙并没有问题，然后也咨询过运维的同学ES服务器做了外网IP访问的限制。
但是为什么还会出现这种情况呢？我又仔细的检查了一遍全部的服务器配置，这里我们的服务器使用的是阿里云的服务器，访问的流程是：client客户端 -> SLB服务器 -> Kibana/ES服务器，通过和运维的同学一起排查，终于找到了问题的原因，原因是运维同学的马虎，只对ES服务器进行了外网IP的过滤，没有对SLB服务器进行外网IP的访问限制，而且我们的ES服务器也使用的默认9200端口，所以直接访问SLB的9200即可直接操作我们的ES的索引数据。
问题的原因：
处理措施：
问题的原因就分析到这里，下面我们说明一下如何在Nginx中设置的用户登录认证。
主要就是利用Nginx接管所有Kibana请求，通过Nginx配置将Kibana的访问加上权限控制，简单常见的方式可以使用如下两种方式：
方式一：使用Nginx的用户认证模块（ngx_http_auth_basic_module模块，Nginxg一般已经默认安装），用户访问时会直接弹出登录提示，要求输入用户名及密码后登录。
此方案需要依赖htpasswd命令生成密码文件。
方式二：利用Nginx的IP访问控制，限定允许和禁止访问的IP，非允许的IP访问后网页会显示403 Forbidden信息。
这里我们在本地可以尝试方式二，因为我们的线上环境使用了阿里云的SLB代理，SLB已经提供了类似的功能，所以就不在自己的Nginx中进行IP访问设置了。
|
|
nginx.conf配置文件
|
|
配置好Nginx的配置文件之后，需要重新加载
|
|
也可以通过curl命令来进行测试
|
|
更多关于ES的安全防护措施请阅读参考文章
参考文章：
最近公司有需要查询历史日志的需求，但是之前在ES设置只保存了最近7天的日志，为了满足需求我将ES服务器的磁盘存储升级到了500G，同时延长了日志的周期至30天，但是这只是临时的解决方案，因为查询历史日志的需求仅仅是最近一个月还不够，所以为了长远考虑需要做日志的持久化存储。
目前公司的架构比较简单，现在需要同时写入到HDFS中。
|
|
这里考虑继续使用Logstash写入到HDFS中，当然也可以选择其他方案从Kafka读取数据写入HDFS的（例如：Flume，KafkaConnector等等），使用Logstash会有下面两种方案。
方案一
方案二
这里我们的需求是要在HDFS中保存原始的日志，所以选择的方案二。
其实Logstash官方并没有提供写入HDFS的插件，但是这里官网推荐社区开发的插件logstash-output-webhdfs
logstash-output-webhdfs插件地址：
|
|
|
|
|
|
可以导出或者cat输出HDFS中的日志文件查看内容，就先写到这里了。
刚开始在使用Logstash写入HDFS的并没有遇到什么问题，然后我把收集Go，Node，PHP的日志3个Logstash进程全部配置完成并启动，一切都很正常。然后开始在线上进行部署，但是第二天发现Go的Logstash进程已经挂掉了，查看Logstash的日志发现，我发现Logstash的日志开始出现如下的错误信息。仔细观察了一下错误信息，发现
SSH登录到服务器发现Logstash报错，连接不上Hadoop的50075端口，于是查找了一下Hadoop的50075端口是什么服务使用的，发现50075是Hadoop的DataNode的http服务端口号，jps查看了一下果然没有DataNode进程，说明DataNode进程已经挂了。
|
|
然后查看DataNode的日志文件，发现如下的错误信息，DataNode的进程挂掉是因为内存不够用了，无法创建新的线程了。
|
|
既然找到是内存不足的原因，就只能从这方面进行优化了，这里我尝试修改Hadoop的启动HeapSize大小来控制内存的使用，Hadoop的HeapSize默认是1000m。可以在环境变量配置如下信息来控制Hadoop各个进程的HeapSize大小。
|
|
控制Hadoop的启动HeapSize大小之后，我开始重启HDFS服务和YARN服务，服务启动都正常。但是当我尝试启动Logstash开始写入数据到HDFS时，Logstash报错如下。错误信息大概的意思是HDFS的文件/logstash/2017/02/10/node_proxy-05.log被锁住了，当前Logstash进程无法写入到这个文件。
|
|
我有开始Google百度相关错误信息，发现HDFS为了防止文件并发写，有一个Lease（租约）的概念。实际上HDFS（及大多数分布式文件系统）不支持文件并发写，Lease是HDFS用于保证唯一写的手段。Lease可以看做是一把带时间限制的写锁，仅持有写锁的客户端可以写文件。更多Lease相关的知识请看参考文章。
既然已经知道是HDFS的Lease锁住了文件，那就去Hadoop官网找相应释放Lease的方法即可。最后我在Hadoop的官网找到了相关的命令如下：
|
|
释放完HDFS的Lease之后，我继续尝试重启Logstash，发现Logstash可以开始写入数据到HDFS中。但是还是偶尔会报下面的错误信息。仔细看错误信息发现和上面的错误类似，仍然是Lease的问题。但是这里的错误只是说Lease正在被另一个进程释放中，需要等会再试。这样就说明可能是我们Logstash写入HDFS的频率过快，导致HDFS来不及释放Lease。
|
|
然后我尝试优化Logstash的如下配置
retry_interval : 两次重试之间等待多长时间
提高flush_size的值，来减少访问webhdfs的频率，同时提高HDFS的写入量
|
|
使用新的配置之后，重启Logstash已经看不到上面因为Lease未释放导致重试的异常信息了。折腾了一个下午也是不容易啊，最后写个博客记录一下处理过程，辛苦了。。
参考文章：
上一篇介绍了Dockerfile的配置详情用法，这里具体在讲解一下Docker的run命令使用，之前在构建自己的Docker镜像时，很多参数都没有深入研究，只是保证Docker容器的正常使用，这里run命令可以动态设置一些启动Docker容器的参数。
最基本的docker run命令的格式如下：
|
|
之前第一篇Docker文章介绍过Docker的基础命令，其中也说明了run命令的一些参数，这里我们在回顾一下。
|
|
注意：
这里在说明一下自己的之前构建的镜像的问题，这里不推荐在Docker中安装SSH，通过SSH来远程登录到Docker容器，应该通过在宿主机运行docker exec的方式进入Docker容器来进行操作，这样安全性更好，这是自己之前构建Docker镜像存在的一些问题。
可以通过三种方式为容器命名：
这个UUID标示是由Docker deamon生成的。如果你在执行docker run时没有指定–name，那么deamon会自动生成一个随机字符串UUID。但是对于一个容器来说有个name会非常方便，当你需要连接其它容器时或者类似需要区分其它容器时，使用容器名称可以简化操作。无论容器运行在前台或者后台，这个名字都是有效的。
|
|
推荐运行Docker容器的时候指定一个容器名字，后续对于Docker容器的操作比较容易，否则每次使用Docker容器的ID操作都需要使用docker ps来查看比较麻烦。
如果在使用Docker时有自动化的需求，你可以将containerID输出到指定的文件中（PIDfile），类似于某些应用程序将自身ID输出到文件中，方便后续脚本操作。
|
|
当一个镜像的名称不足以分辨这个镜像所代表的含义时，你可以通过tag将版本信息添加到run命令中，以执行特定版本的镜像。这个也是我之前比较常用的方式。
|
|
默认情况下，所有的容器都开启了网络接口，同时可以接受任何外部的数据请求。这个是设置Docker网络配置的参数，如果你有多个Docker容器之前需要网络通信，那么这个参数是比较常用的。
|
|
你可以通过docker run –net none来关闭网络接口，此时将关闭所有网络数据的输入输出，你只能通过STDIN、STDOUT或者files来完成I/O操作。默认情况下，容器使用主机的DNS设置，你也可以通过–dns来覆盖容器内的DNS设置。同时Docker为容器默认生成一个MAC地址，你可以通过–mac-address 12:34:56:78:9a:bc来设置你自己的MAC地址。
Docker支持的网络模式有：
/etc/hosts文件中会包含容器的hostname信息，我们也可以使用–add-host这个参数来动态添加/etc/hosts中的数据。使用–add-host参数我们就可以动态配置hosts，而不需要在构建镜像的时候将/etc/hosts文件写好并且覆盖到Docker镜像中，这个也是我之前所犯下的错误。
|
|
默认情况下，每个容器在退出时，它的文件系统也会保存下来，这样一方面调试会方便些，因为你可以通过查看日志等方式来确定最终状态。另外一方面，你也可以保存容器所产生的数据。但是当你仅仅需要短暂的运行一个容器，并且这些数据不需要保存，你可能就希望Docker能在容器结束时自动清理其所产生的数据。这个时候你就需要–rm这个参数了，–rm参数设置为true会在停止Docker容器的时候自动删除该容器的，在构建调试Docker容器的时候比较方便，省去手动反复删除Docker容器的操作，自己深有体会推荐构建调试的时候使用。
|
|
Docker run命令可以指定参数来覆盖Dockerfile中的配置，这些参数中，有四个是无法被覆盖的：FROM、MAINTAINER、RUN和ADD（这里可能是原作者写漏了，COPY也应该是无法被覆盖的），其余参数都可以通过docker run进行覆盖。我们将介绍如何对这些参数进行覆盖。
|
|
|
|
这个命令中的COMMAND部分是可选的。因为这个IMAGE在build时，开发人员可能已经设定了默认执行的命令。作为操作人员，你可以使用上面命令中新的command来覆盖旧的command。
如果镜像中设定了ENTRYPOINT，那么命令中的CMD也可以作为参数追加到ENTRYPOINT中。
|
|
|
|
这个ENTRYPOINT和COMMAND类似，它指定了当容器执行时，需要启动哪些进程。相对COMMAND而言，ENTRYPOINT是很难进行覆盖的，这个ENTRYPOINT可以让容器设定默认启动行为，所以当容器启动时，你可以执行任何一个二进制可执行程序。你也可以通过COMMAND为ENTRYPOINT传递参数。但当你需要在容器中执行其它进程时，你就可以指定其它ENTRYPOINT了。
下面就是一个例子，容器可以在启动时自动执行Shell，然后启动其它进程。
|
|
|
|
|
|
–expose可以让容器接受外部传入的数据。容器内监听的端口不需要和外部主机的端口相同。比如说在容器内部，一个HTTP服务监听在80端口，对应外部主机的端口就可能是49880.
如果使用-p或者-P，那么容器会开放部分端口到主机，只要对方可以连接到主机，就可以连接到容器内部。当使用-P时，Docker会在主机中随机从49153和65535之间查找一个未被占用的端口绑定到容器。你可以使用docker port来查找这个随机绑定端口。
当你使用–link方式时，作为客户端的容器可以通过私有网络形式访问到这个容器。同时Docker会在客户端的容器中设定一些环境变量来记录绑定的IP和PORT。
|
|
|
|
这将在容器中设置简单（非数组）环境变量。 为了说明这里显示所有三个标志。 其中-e，-env取一个环境变量和值，或者如果没有提供”=”，那么通过export设置该变量的当前值（即，来自主机的$MYVAR1被设置为容器中的$MYVAR1） 。当没有提供”=”且该变量没有在客户端环境中定义时，那个变量将从容器的环境变量列表中删除。所有三个标志，-e，–env和–env文件可以重复。
不管这三个标志的顺序如何，首先处理–env文件，然后处理-e，-env标志。 这样，-e或–env将根据需要覆盖变量。
|
|
–env-file标志采用文件名作为参数，并且期望每一行都处于VAR = VAL格式，模拟传递给–env的参数。 注释行只需要前缀为＃
使用–env-file传递的文件示例
|
|
通过”-v”参数来覆盖挂载路径，这个是比较常用的，因为大多数日志或者数据文件都会挂载到宿主机目录的。
|
|
|
|
容器中默认的用户是root，但是开发人员创建新的用户之后，这些新用户也是可以使用的。开发人员可以通过Dockerfile的USER设定默认的用户，并通过”-u”来覆盖这些参数。
|
|
容器中默认的工作目录是根目录（/）。开发人员可以通过Dockerfile的WORKDIR来设定默认工作目录，操作人员可以通过”-w”来覆盖默认的工作目录。
|
|
这里我只记录了自己使用Docker常用的配置，更多详细配置用法请看参考文章，谢谢!
参考文章：
虽然自己构建了很多自己的Docker镜像，但是随着自己对于Docker的慢慢熟悉，发现自己之前构建的Docker镜像的用法不是很推荐使用，还有就是很多Docker的细节用法不是很熟悉，本篇具体记录了Docker配置文件的一些用法，以及比较容易混淆的配置。
Docker配置文件详解
指定基础镜像，用于继承其他镜像使用的
|
|
镜像创建者的基本信息
|
|
RUN用来执行命令行命令的，只是在构建镜像build的时候执行
RUN的两种格式：
|
|
CMD指令的主要功能是在build完成后，为了给docker run启动到容器时提供默认命令或参数，构建镜像build时不执行。如果用户启动容器run时指定了运行的命令，则会覆盖掉CMD指定的命令。
注意：CMD只有最后一个有效
CMD的格式：
|
|
ENTRYPOINT配置容器启动后执行的命令，构建镜像build时不执行，并且不可被 docker run 提供的参数覆盖。
注意：每个 Dockerfile 中只能有一个 ENTRYPOINT，当指定多个时，只有最后一个起效。
ENTRYPOINT的格式：
|
|
RUN是在build成镜像时就运行的，先于CMD和ENTRYPOINT的。Build完成了，RUN也运行完成后，再运行CMD或者ENTRYPOINT。CMD会在每次启动容器的时候运行，而RUN只在创建镜像时执行一次，固化在image中。
ENTRYPOINT和CMD的不同点在于执行docker run时参数传递方式，CMD指定的命令可以被docker run传递的命令覆盖，如果docker run没有指定参数，则会使用CMD的默认参数执行，例如，如果用CMD指定：
|
|
然后运行
|
|
那么CMD里指定的echo会被新指定的echo覆盖，所以最终相当于运行echo foo，所以最终打印出的结果就是：
|
|
而ENTRYPOINT会把容器名后面的所有内容都当成参数传递给其指定的命令（不会对命令覆盖），比如：
|
|
然后运行
|
|
则CONTAINER_NAME后面的echo foo都作为参数传递给ENTRYPOING里指定的echo命令了，所以相当于执行了
|
|
最终打印出的结果就是：
|
|
另外，在Dockerfile中，ENTRYPOINT指定的参数比运行docker run时指定的参数更靠前，比如：
|
|
执行
|
|
相当于执行了：
|
|
打印出的结果就是：
|
|
Dockerfile中只能指定一个ENTRYPOINT，如果指定了很多，只有最后一个有效。
执行docker run命令时，也可以添加-entrypoint参数，会把指定的参数继续传递给ENTRYPOINT，例如：
|
|
然后执行：
|
|
那么，就相当于执行了echo foo bar，最终结果就是
|
|
设置Docker容器对外暴露的本地端口，需要在启动容器run时使用-p指定Docker容器外的端口和Docker容器内的端口
|
|
定义Docker容器内的环境变量
ENV的格式：
|
|
将本地主机目录挂载到目标容器中，将其他容器挂载的挂载点挂载到目标容器中
|
|
将复制指定的
|
|
将复制本地主机的
|
|
ADD与COPY是完全不同的命令。COPY是这两个中最简单的，它只是从主机复制一份文件或者目录到镜像里。ADD同样可以这么做，但是它还有更神奇的功能，像解压TAR文件或从远程URLs获取文件。为了降低Dockerfile的复杂度以及防止意外的操作，最好用COPY来复制文件。Best Practices for Writing Dockerfiles建议尽量使用COPY，并使用RUN与COPY的组合来代替ADD，这是因为虽然COPY只支持本地文件拷贝到container，但它的处理比ADD更加透明，建议只在复制tar文件时使用ADD，如ADD trusty-core-amd64.tar.gz /。
|
|
指定运行容器时的用户名或UID，后续的RUN、CMD、ENTRYPOINT也会使用指定用户
|
|
进入容器的默认路径，相当于cd，后续的RUN、CMD、ENTRYPOINT也会使用指定路径。
|
|
基础镜像Dockerfile，基础镜像更新，各个项目不用同步 Dockerfile 的变化，重新构建后就继承了基础镜像的更新。
|
|
这里我们把项目相关的构建指令拿出来，放到子项目里去。假设这个基础镜像的名字为 my-node 的话，各个项目内的自己的 Dockerfile 就变为：
|
|
基础镜像变化后，各个项目都用这个 Dockerfile 重新构建镜像，会继承基础镜像的更新。
如果这个 Dockerfile 里面有些东西需要调整呢？比如 npm install 都需要加一些参数，那怎么办？这一行 RUN 是不可能放入基础镜像的，因为涉及到了当前项目的 ./package.json，难道又要一个个修改么？所以说，这样制作基础镜像，只解决了原来的 Dockerfile 的前4条指令的变化问题，而后面三条指令的变化则完全没办法处理。
ONBUILD 可以解决这个问题。让我们用 ONBUILD 重新写一下基础镜像的 Dockerfile:
|
|
这次我们回到原始的 Dockerfile，但是这次将项目相关的指令加上 ONBUILD，这样在构建基础镜像的时候，这三行并不会被执行。然后各个项目的 Dockerfile 就变成了简单地：
|
|
是的，只有这么一行。当在各个项目目录中，用这个只有一行的 Dockerfile 构建镜像时，之前基础镜像的那三行 ONBUILD 就会开始执行，成功的将当前项目的代码复制进镜像、并且针对本项目执行 npm install，生成应用镜像。
参考文章：
最近在使用Golang开发，使用Docker创建一个Golang环境的镜像方便以后开发使用。这里是外置挂在了我自己的birdTracker项目，使用Docker的Golang环境启动运行birdTracker项目。
Dockerfile文件
|
|
Dockerfile源文件链接：
go_docker.sh
|
|
构建Docker镜像
|
|
运行Docker容器
|
|
上一篇我们对Nginx的access.log进行了初步的解析和提取字段处理，如果想进一步对客户端的IP来源进行分析和地理定位，我们需要借助第三方库GeoIP来进行地理定位。
如果想要让URL参数也解析并且成为索引字段，比如一些通用参数，如uid, country, language, etc. 那么可以使用KV插件
|
|
好了，现在还有一个问题，如果请求中有中文，那么日志中的中文是被urlencode之后存储的。我们具体分析的时候，比如有个接口是/api/search?keyword=我们，需要统计的是keyword被查询的热门顺序，那么就需要解码了。logstash牛逼的也有urldecode命令，urldecode可以设置对某个字段，也可以设置对所有字段进行解码。
|
|
对于安全扫描，只需要过滤 http_user_agent 中含有 inf-ssl-duty-scan 的请求就可以了
|
|
|
|
参考文章：
上一篇我们对Nginx的access.log进行了初步的解析和提取字段处理，如果想进一步对客户端的IP来源进行分析和地理定位，我们需要借助第三方库GeoIP来进行地理定位。
这里要说明一下GeoIP是一个免费的IP定位数据库，现在目前有两个版本GeoIP和GeoIP2
GeoIP官网地址：
这里GeoIP和GeoIP2我都尝试过了，使用GeoIP2是因为GeoIP不支持IPv6，开始access.log日志的IP使用的IPv6，但是ES 2.x版本也只支持IPv4类型，所以为了简单把access.log日志的IP改为了IPv4。下面说一下GeoIP和GeoIP2的安装和使用
GeoIP（免费版叫GeoLite）数据库下载地址
|
|
Logstash默认是安装了logstash-filter-geoip插件的，所以可以直接使用下面的配置。我们继续上一篇的Logstash配置文件修改如下：
|
|
|
|
GeoIP2（免费版叫GeoLite2）数据库下载地址
|
|
|
|
这里需要单独安装geoip2插件，因为geoip2插件不是Logstash的官方插件。不使用geoip是因为对IPv6支持的不好，但是ES 2.x版本也只支持IPv4，不支持IPv6类型存储，所以后来只是将access.log的IP地址改为IPv4了。这里只是介绍下如何使用GeoIP2。
|
|
注意这里的field不能直接用geoip插件的写法，因为有一些字段在geoip2中已经被去掉了，例如：real_region_name，否则会报如下错误
|
|
下面是GeoIP2的格式，可以对比一下GeoIP的格式，不同的地方用*号标识出来了。
|
|
引用GeoIP之后，对应的ES的索引Template模板也有相应的变化
|
|
这里添加了一个geoip字段，并且使用dynamic，这样允许Logstash的geoip插件将解析后的详细字段也保存到ES索引中。这里geoip插件解析出来会带有一个location字段，这个字段就是经纬度的坐标点，所以这里设置geoip.location字段的类型是geo_point。
从Logstash的1.3.0版本开始，如果GeoIP查询返回纬度和经度，则会创建一个[geoip] [location]字段。 该字段存储为GeoJSON格式。 此外，弹性搜索输出提供的默认Elasticsearch模板将[geoip] [location]字段映射到Elasticsearch geo_point。
以下是elastic.co官方文档对于geo_point类型的解释
geo_point映射将索引具有lat，lon格式的单个字段。lat_lon选项可以设置为也将.lat和.lon作为数字字段索引，geohash可以设置为true以索引.geohash值。
一个好的做法是启用索引lat_lon，因为geo距离和边界框过滤器可以使用内存检查或使用索引的lat lon值执行，并且它实际上取决于哪个数据集执行得更好。请注意，索引lat lon只有当字段有一个地理点值，而不是多个值时才有意义。
地理散列是一种纬度/经度编码的形式，它将地球分成网格。此网格中的每个单元格都由geohash字符串表示。每个单元又可以被进一步细分成由较长串表示的较小单元。因此，geohash越长，单元格越小（从而更精确）。
因为geohash只是字符串，它们可以像任何其他字符串一样存储在倒排索引中，这使得查询非常有效。
如果启用geohash选项，geohash“子字段”将被索引为，例如pin.geohash。geohash的长度由geohash_precision参数控制，geohash_precision参数可以设置为绝对长度（例如12，默认值）或距离（例如1km）。
更有用的是，将geohash_prefix选项设置为true不仅可以索引geohash值，还可以索引所有包围的单元格。例如，u30的geohash将被索引为[u，u3，u30]。此选项可以由Geohash单元格过滤器用于非常有效地查找特定单元格中的地理位置。
geo_point类型支持4种方式，下面是官网给出的例子。
|
|
以下是翻译自elastic.co官方文档
说明：
注意：
string方式的geo-points顺序是lat,lon，而数组方式的geo-points顺序是反过来的lon,lat。最初，lat,lon用于数组和字符串，但是数组格式早期改变以符合GeoJSON使用的格式。
|
|
在Visualization中选择创建TileMap
然后在索引中选择geoip.location字段，如下图左边所示。注意：我这里替换成了高德地图后的效果，具体可以参考Kibana系列的文章。
如果配置的过程中报错”No Compatible Fields: The “[nginx_access_logsindex*]” index pattern does not contain any of the following field types: geo_point”
错误原因：这个错误是因为我们的geoip的location字段类型不是geo_point，之前尝试Logstash写入数据到ES的时候没有在nginx_access_logsindex*索引模板中明确的指定geoip.location的类型，所以默认使用的dynamic_templates的配置，动态创建出来的geoip.location字段是string类型的，所以需要在ES的模板中指定好geoip.location字段的类型是geo_point。
参考文章：
最近公司的系统遇到了并发性能问题，需要分析系统各个接口的请求和响应时间，所以提议收集Nginx日志来进行分析。
默认的Nginx配置文件/etc/nginx/nginx.conf
|
|
下面是几个具有典型代表的access.log日志
|
|
看到上面的日志实例，可能已经看出来不同的日志差别还是挺大的，有些日志缺少client_ip, upstream_response_time, ua等等，这些日志是阿里云健康检查的日志，所以后面我们会想办法处理这些日志的。
|
|
注意：
从上面的描述可以看出，$request_time肯定比$upstream_response_time值大，特别是使用POST方式传递参数时，因为Nginx会把request body缓存住，接受完毕后才会把数据一起发给后端。所以如果用户网络较差，或者传递数据较大时，$request_time会比$upstream_response_time大很多。
Grok表达式的调试工具推荐使用
这里定义了一个名为NGINX_ACCESS_LOGS的Grok表达式
|
|
Grok表达式的匹配结果如下：
|
|
这里使用了Logstash默认定义的一些Grok表达式，下面列举了一些常用的Grok表达式
|
|
具体内置的Grok表达式可以参考：
这里有几个地方让我有些迷惑：
实际上是下面正则表达式的区别
具体区别请参考：
在Logstash中匹配client_ip为”-“的情况，然后将client_ip字段去掉，这样geoip解析的时候就不会报错了，后续会提供详细的配置文件
upstream_response_time是”-“的情况比较好解决，只要稍微修改下Grok表达式即可，修改后如果upstream_response_time是”-“，Grok表达式提取出来的upstream_response_time的值就是null
|
|
以阿里云的健康检查请求日志为例：
|
|
匹配结果如下:
|
|
这里我们尽量把处理方式简化，在单一的服务器上安装好Nginx和ELK环境，对Nginx的access.log日志进行收集，解析，最终写入到ES中。
|
|
上面Logstash写入日志数据到ES的时候，使用了nginx_access_logs_template.json模板，下面是ES模板的具体配置。这里我们只是把Logstash提取出来的值按照ES的Template定义好的类型写入到ES索引中。
|
|
参考文章：
找到src/ui/public/vislib/visualizations/_map.js文件，修改请求的地图API
|
|
|
|
K4有一套机制是要通过webpack来进行编译的，从而达到大数据多而不崩，畅而不卡的效果所架构的，及时修改源代码也要编译后才能用，所以要删除${KB_HOME}/optimize/bundles目录，然后重启Kibana重新进行编译。在这一步Kibana启动时间会比平时慢，往往会卡停一段时间，因为此时正在进行编译创造bundles文件夹编译完之后发现之前删除掉的bundles又出现了。
|
|
这个是默认显示的是空白，只要点放大的那个 + 号，就可以看到地图形状了。或者可以按照上面配置修改defaultMapZoom的值为5，就可以避免默认展示空白。
如上面配置修改defaultMapCenter默认显示的位置即可
修改后第一次启动的时候会比较慢，因为Kibana使用webpack进行编译的，从而提供高效稳定的性能。修改源码后需要编译后才能运行，上面的删除optimize/bundles就是删除编译的结果，让kibana重新编译
参考文章：
