nginx日记服务器_nginx日记设置文件「nginx记录日志」

　　文|Mr-Bruce

　　作为系列文章的第四篇，本文将重点探究数据收罗层中的ELK日记体系。日记，指的是背景服务中产生的log信息，通常会输入到差别的文件中，比如Django服务下，一样平常会有nginx日记和uWSGI日记。这些日记分散地存储在差别的呆板上，取决于服务的摆设环境了。假如我们依次登录每台呆板去查阅日记，显然非常繁琐，服从也很低，而且也没法举行统计和检索。因此，我们必要对日记举行会合化管理，将全部呆板上的日记信息网络、汇总到一起。完备的日记数据具有非常紧张的作用：

　　信息查找。通过检索日记信息，定位相应的bug，找出办理方案。服务诊断。通过对日记信息举行统计、分析，相识服务器的负荷和服务运行状态，找出耗时哀求举行优化等等。数据分析。假如是格式化的log，可以做进一步的数据分析，统计、聚合出故意义的信息，比如根据哀求中的商品id，找出TOP10用户感爱好商品。

　　ELK是一套开源的会合式日记数据管理的办理方案，由Elasticsearch、Logstash和Kibana三个体系构成。最初我们建立ELK日记体系的目标是做数据分析，记得第一个需求是盼望利用nginx的日记，从API哀求的参数中发掘出用户的位置分布信息。厥后该体系在追踪恶意刷量、优化耗时服务等方面都发挥了紧张作用，而且随着对Elasticsearch的认知加深，我们将其应用到了其他方面的数据存储和分析中。本文的重点是连合自身实践来先容怎样利用ELK体系、利用中的题目以及怎样办理，文中涉及的ELK版本是：Elasticsearch2.3、Logstash2.3、Kibana4。

　　ELK团体方案

　　ELK中的三个体系分别扮演差别的脚色，构成了一个团体的办理方案。Logstash是一个ETL工具，负责从每台呆板抓取日记数据，对数据举行格式转换和处理惩罚后，输出到Elasticsearch中存储。Elasticsearch是一个分布式搜刮引擎和分析引擎，用于数据存储，可提供及时的数据查询。Kibana是一个数据可视化服务，根据用户的操纵从Elasticsearch中查询数据，形成相应的分析结果，以图表的情势显现给用户。

　　ELK的安装很简单，可以按照“下载-修改设置文件-启动”方法分别摆设三个体系，也可以利用docker来快速摆设。具体的安装方法这里不具体先容，我们来看一个常见的摆设方案，如下图所示，摆设思绪是：

　　第一，在每台天生日记文件的呆板上，摆设Logstash，作为Shipper的脚色，负责从日记文件中提取数据，但是不做任那边理惩罚，直接将数据输出到Redis队列(list)中;

　　第二，必要一台呆板摆设Logstash，作为Indexer的脚色，负责从Redis中取出数据，对数据举行格式化和相干处理惩罚后，输出到Elasticsearch中存储;

　　第三，摆设Elasticsearch集群，固然取决于你的数据量了，数据量小的话可以利用单台服务，假如做集群的话，最好是有3个以上节点，同时还必要摆设相干的监控插件;

　　第四，摆设Kibana服务，提供Web服务。

　　在前期摆设阶段，重要工作是Logstash节点和Elasticsearch集群的摆设，而在后期利用阶段，重要工作就是Elasticsearch集群的监控和利用Kibana来检索、分析日记数据了，固然也可以直接编写程序来斲丧Elasticsearch中的数据。

　　在上面的摆设方案中，我们将Logstash分为Shipper和Indexer两种脚色来完成差别的工作，中心通过Redis做数据管道，为什么要如许做?为什么不是直接在每台呆板上利用Logstash提取数据、处理惩罚、存入Elasticsearch?

　　起首，采取如许的架构摆设，有三点上风：

　　第一，低落对日记地点呆板的影响，这些呆板上一样平常都摆设着反向署理或应用服务，本身负载就很重了，以是尽大概的在这些呆板上少办事;

　　第二，假如有很多台呆板必要做日记网络，那么让每台呆板都向Elasticsearch连续写入数据，肯定会对Elasticsearch造成压力，因此必要对数据举行缓冲，同时，如许的缓冲也可以肯定程度的掩护数据不丢失;

　　第三，将日记数据的格式化与处理惩罚放到Indexer中同一做，可以在一处修改代码、摆设，克制必要到多台呆板上去修改设置。

　　其次，我们必要做的是将数据放入一个消息队列中举行缓冲，以是Redis只是此中一个选择，也可以是RabbitMQ、Kafka等等，在实际生产中，Redis与Kafka用的比力多。由于Redis集群一样平常都是通过key来做分片，无法对list范例做集群，在数据量大的时间肯定不符合了，而Kafka天生就是分布式的消息队列体系。

　　Logstash

　　在官方文档中，DeployingandScalingLogstash一文具体先容了各种Logstash的摆设架构，下图是与我们上述方案符合合的架构。Logstash由input、filter和output三部分构成，input负责从数据源提取数据，filter负责分析、处理惩罚数据，output负责输出数据，每部分都有提供丰富的插件。Logstash的计划思绪也非常值得鉴戒，以插件的情势来构造功能，通过设置文件来形貌必要插件做什么。我们以nginx日记为例，来看看怎样利用一些常用插件。

　　1.设置nginx日记格式

　　起首必要将nginx日记格式规范化，便于做分析处理惩罚。在nginx.conf文件中设置：

　　2.nginx日记–Logstash–消息队列

　　这部分是LogstashShipper的工作，涉及input和output两种插件。input部分，由于必要提取的是日记文件，一样平常利用file插件，该插件常用的几个参数是：

　　path，指定日记文件路径。type，指定一个名称，设置type后，可以在背面的filter和output中对差别的type做差别的处理惩罚，实用于必要斲丧多个日记文件的场景。start_position，指定起始读取位置，“beginning”表现从文件头开始，“end”表现从文件尾开始(雷同tail-f)。sincedb_path，与Logstash的一个坑有关。通常Logstash会记录每个文件已经被读取到的位置，生存在sincedb中，假如Logstash重启，那么对于同一个文件，会继承从前次记录的位置开始读取。假如想重新重新读取文件，必要删除sincedb文件，sincedb_path则是指定了该文件的路径。为了方便，我们可以根据必要将其设置为“/dev/null”，即不生存位置信息。

　　output部分，将数据输出到消息队列，以redis为例，必要指定redisserver和listkey名称。别的，在测试阶段，可以利用stdout来查察输出信息。

　　3.消息队列–Logstash–Elasticsearch

　　这部分是LogstashIndexer的工作，涉及input、filter和output三种插件。在input部分，我们通过redis插件将数据从消息队列中取出来。在output部分，我们通过elasticsearch插件将数据写入Elasticsearch。

　　这里，我们重点关注filter部分，下面罗列几个常用的插件，实际利用中根据自身需求从官方文档中查找得当本身业务的插件并利用即可，固然也可以编写本身的插件。

　　grok，是Logstash最紧张的一个插件，用于将非布局化的文本数据转化为布局化的数据。grok内部利用正则语法对文本数据举行匹配，为了低落利用复杂度，其提供了一组pattern，我们可以直接调用pattern而不必要本身写正则表达式，参考源码grok-patterns。

　　grok分析文本的语法格式是%{SYNTAX:SEMANTIC}，SYNTAX是pattern名称，SEMANTIC是必要天生的字段名称，利用工具GrokDebugger可以对分析语法举行调试。比方，在下面的设置中，我们先利用grok对输入的原始nginx日记信息(默认以message作为字段名)举行分析，并添加新的字段request_path_with_verb(该字段的值是verb和request_path的组合)，然后对request_path字段做进一步分析。

　　kv，用于将某个字段的值举行分解，雷同于编程语言中的字符串Split。在下面的设置中，我们将request_args字段值按照“”举行分解，分解后的字段名称以“request_args_”作为前缀，而且扬弃重复的字段。

　　geoip，用于根据IP信息天生地理位置信息，默认利用自带的一份GeoLiteCitydatabase，也可以本身更换为最新的数据库，但是必要数据格式必要依照Maxmind的格式(参考GeoLite)，好像如今只能支持legacydatabase，数据范例必须是.dat。下载GeoLiteCity.dat.gz后解压，并将文件路径设置到source中即可。

　　translate，用于检测某字段的值是否符合条件，假如符合条件则将其翻译成新的值，写入一个新的字段，匹配pattern可以通过YAML文件来设置。比方，在下面的设置中，我们对request_api字段翻译成更加易懂的笔墨形貌。

　　Elasticsearch

　　Elasticsearch承载了数据存储和查询的功能，其底子概念和利用方法可以参考另一篇博文Elasticsearch利用总结，这里重要先容些实际生产中的题目和方法：

　　关于集群设置，重点关注三个参数：

　　第一，discovery.zen.ping.unicast.hosts，Elasticsearch默认利用ZenDiscovery来做节点发现机制，保举利用unicast来做通讯方式，在该设置项中罗列出Master节点。

　　第二，discovery.zen.minimum_master_nodes，该参数表现集群中可工作的具有Master节点资格的最小数量，默认值是1。为了进步集群的可用性，克制脑裂征象(所谓脑裂，就是同一个集群中的差别节点，对集群的状态有不同等的明白。)，官方保举设置为(N/2)+1，此中N是具有Master资格的节点的数量。

　　第三，discovery.zen.ping_timeout，表现节点在发现过程中的等待时间，默认值是3秒，可以根据自身网络环境举行调解，肯定程度上提供可用性。

　　关于集群节点，第一，节点范例包罗：候选Master节点、数据节点和Client节点。通过设置两个设置项node.master和node.data为true或false，来决定将一个节点分配为什么范例的节点。第二，只管将候选Master节点和Data节点分离开，通常Data节点负载较重，必要思量单独摆设。

　　关于内存，Elasticsearch默认设置的内存是1GB，对于任何一个业务摆设来说，这个都太小了。通过指定ES_HEAP_SIZE环境变量，可以修改其堆内存巨细，服务进程在启动时间会读取这个变量，并相应的设置堆的巨细。发起设置体系内存的一半给Elasticsearch，但是不要高出32GB。参考官方文档。

　　关于硬盘空间，Elasticsearch默认将数据存储在/var/lib/elasticsearch路径下，随着数据的增长，肯定会出现硬盘空间不敷用的情况，此时就必要给呆板挂载新的硬盘，并将Elasticsearch的路径设置到新硬盘的路径下。通过“path.data”设置项来举行设置，比如“path.data:/data1,/var/lib/elasticsearch,/data”。必要留意的是，同一分片下的数据只能写入到一个路径下，因此还是必要公道的规划和监控硬盘的利用。

　　关于Index的分别和分片的个数，这个必要根据数据量来做衡量了，Index可以按时间分别，比如每月一个大概每天一个，在Logstash输出时举行设置，shard的数量也必要做好控制。

　　关于监控，笔者利用过head和marvel两个监控插件，head免费，功能相对有限，marvel如今必要收费了。别的，不要在数据节点开启监控插件。

　　Kibana

　　Kibana提供的是数据查询和表现的Web服务，有丰富的图表样板，能满意大部分的数据可视化需求，这也是很多人选择ELK的重要缘故起因之一。UI的操纵没有什么特别必要先容的，常常利用就会纯熟，这里重要先容常常碰到的三个题目。

　　1.查询语法

　　在Kibana的Discover页面中，可以输入一个查询条件来查询所需的数据。查询条件的写法利用的是Elasticsearch的QueryString语法，而不是QueryDSL，参考官方文档query-string-syntax，这里罗列此中部分常用的：

　　单字段的全文检索，比如搜刮args字段中包罗first的文档，写作args:first;单字段的正确检索，比如搜刮args字段值为first的文档，写作args:“first”;多个检索条件的组合，利用NOT,AND和OR来组合，留意必须是大写，比如args:(“first”OR“second”)ANDNOTagent:“third”;字段是否存在，_exists_:agent表现要求agent字段存在，_missing_:agent表现要求agent字段不存在;通配符：用?表现单字母，*表现恣意个字母。

　　2.错误“Discover:RequestTimeoutafter30000ms”

　　这个错误常常发生在要查询的数据量比力大的环境下，此时Elasticsearch必要较长时间才华返回，导致Kibana发生Timeout报错。办理这个题目的方法，就是在Kibana的设置文件中修改elasticsearch.requestTimeout一项的值，然后重启Kibana服务即可，留意单位是ms。

　　3.迷惑“字符串被分解了”

　　常常在QQ群里看到一些人在问如许一个题目：为什么查询结果的字段值是精确的，但是做图表时却发现字段值被分解了，不是想要的结果?如下图所示的client_agent_info字段。

　　得到如许一个不精确结果的缘故起因是利用了Analyzed字段来做图表分析，默认环境下Elasticsearch会对字符串数据举行分析，创建倒排索引，以是假如对这么一个字段举行terms聚合，肯定会得到上面所示的错误结果了。那么应该怎么做才对?默认环境下，Elasticsearch还会创建一个相对应的没有被Analyzed的字段，即带“.raw”后缀的字段，在如许的字段上做聚合分析即可。

　　又会有很多人问如许的题目：为什么我的Elasticsearch没有主动创建带“.raw”后缀的字段?然而在Logstash中输出数据时，设置index名称前缀为“logstash-”就有了这个字段。这个题目的根源是Elasticsearch的dynamictemplate在捣鬼(可以查察博文Elasticsearch利用总结中的具体先容)，dynamictemlate用于引导Elasticsearch如作甚插入的数据主动创建Schema映射关系，默认环境下，Logstash会在Elasticsearch中创建一个名为“logstash”的模板，全部前缀为“logstash-”的index都会参照这个模板来创建映射关系，在该模板中阐明白要为每个字符串数据创建一个额外的带“.raw”后缀的字段。可以向Elasticsearch来查询你的模板，利用API：GEThttps://localhost:9200/_template。

　　以上便是对ELK日记体系的总结先容，尚有一个紧张的功能没有提到，就是怎样将日记数据与自身产物业务的数据融合起来。

　　举个例子，在nginx日记中，通常会包罗API哀求访问时携带的用户Token信息，由于Token是偶然效性的，我们必要及时将这些Token转换成真实的用户信息存储下来。如许的需求通常有两种实现方式，一种是本身写一个Logstashfilter，然后在Logstash处理惩罚数据时调用;另一种是将LogstashIndexer产生的数据再次输出到消息队列中，由我们本身的脚本程序从消息队列中取出数据，做相应的业务处理惩罚后，输出到Elasticsearch中。如今，团队对ruby技能栈不是很认识，以是我们采取了第二种方案来实行。

　　当前，我们的数据增长相对迟钝，碰到的题目也有限，随着数据量的增长，将来肯定会碰到更多的挑衅，也可以进一步探索ELK。

　　End.

　　转载请注明来自36大数据（36dsj.com)：36大数据»创业公司做数据分析(四)ELK日记体系