怎样进行Windows事件日志分析？如何做日志分析

本文目录

• 怎样进行Windows事件日志分析
• 如何做日志分析
• Linux系统日志分析的基本教程
• 华为服务器如何分析bmc日志
• 「SpringCloud」（三十八）搭建ELK日志采集与分析系统
• MongoDB应用1——日志分析
• 分布式日志系统Graylog、Loki及ELK的分析和对比
• 为什么要分析日志
• elk日志分析平台是什么意思
• 如何进行网站日志分析

怎样进行Windows事件日志分析

EventLog Analyzer为所有Windows、Unix系统、交换机和路由器(Cisco)、其他Syslog支持设备以及IIS、MS SQL等应用程序执行日志分析。Eventlog分析器应用程序能够执行实时日志文件分析。事件日志文件分析器应用程序可以对导入文件执行日志文件分析。这些文件可以从档案或任何机器导入。
当网络中的机器上生成重要的安全事件时，事件日志文件分析器应用程序会实时收集、执行日志分析并在EventLog Analyzer仪表板上显示事件。事件日志报表从所分析的事件日志中生成。从事件日志报表（图表）中，您可以深入查看原始日志事件并在几分钟内完成根本原因分析，然后专注于解决它。
日志分析器应用程序对导入和归档的日志文件执行分析，以满足取证分析和事件日志审核的要求。取证和审核报表可以从所分析的日志中生成。
接收特定服务器上关键事件的即时告警
您可以设置告警，当服务器上生成特定事件时触发该告警。例如，您可以设置告警，以在邮件服务器上生成紧急事件时通知管理员。告警可在触发时通过电子邮件发送给操作员。使用EventLog Analyzer告警，您将获知网络上每个系统的最新状态。
将分散事件存档到中央位置
已归档事件日志能够让您深入了解系统的性能。但是，除非所有事件日志都存档在中央位置，并且操作员能够随时对其进行访问，否则事件日志检索是一项相当复杂的任务。EventLog Analyzer自动将从每个系统收到的事件日志归档到一个中央位置，并允许操作员随时访问档案。

如何做日志分析

一个合格的站长或者seoer必须要能看懂网站的服务器日志文件，这个日志记录了网站被搜索引擎爬取的痕迹，给站长提供了蜘蛛是否来访的有力佐证，站长朋友可以通过网站日志来分析搜索引擎蜘蛛的抓取情况，分析网站的是否存在收录异常问题。并且我们可以根据这个日志文件判断蜘蛛来访频率以及抓取规律，这将非常有利于我们做优化。另外，学习分析网站日志文件也是站长必须具备的能力，也是你从一个初级seo进阶到seo高手的必由之路。但是前提是要主机服务商开通日志统计功能，一般虚拟主机提供商都不会开通，你可以申请开通，或者自己到服务器管理后台开通这个日志统计功能，不过日志也会占用空间的，我们在看完日志文件后，可以隔段时间清理下日志文件。那么如何分析服务器日志文件呢?听我娓娓道来。
　　搜索引擎抓取网站信息必会在服务器上留下信息，这个信息就在网站日志文件里。我们通过日志可以了解搜索引擎的访问情况，一般通过主机服务商开通日志功能，再通过FTP访问网站的根目录，在根目录下可以看到一个log或者weblog文件夹，这里面就是日志文件，我们把这个日志文件下载下来，用记事本(或浏览器)打开就可以看到网站日志的内容。那么到底这个日志里面隐藏了什么玄机呢?其实日志文件就像飞机上的黑匣子。我们可以通过这个日志了解很多信息，那么到底这个日志给我们传递了什么内容呢?
***隐藏网址***
　　说到分析日志文件，我们就不得不说分析日志文件的时机了，那么在什么情况下我们要去分析日志文件呢?首先，新网站刚建立的时候，这个时候也是站长朋友最急切的时候，我们一般都会焦急的等待搜索引擎收录网站内容，经常会做的事情就是去百度或者Google用命令site:下网站域名看看是否被收录，这个时候，其实我们没必要频繁的查询网站是否被收录，要想知道搜索引擎是否关顾我们的网站。我们就可以借助网站日志文件来查看，怎么看?看网站日志是否有搜索引擎的蜘蛛来网站抓取过，看返回的状态码是200还是其他，如果返回200说明抓取成功，如果返回404说明页面错误，或者页面不存在，就需要做301永久重定向或者302暂时重定向。一般抓取成功后被搜索引擎放出来的时间也会晚点，一般谷歌机器人放出来的比较快，最快可秒杀，但是百度反应就慢了，最快也要一周左右，不过11月份百度算法调整后，放出来的速度还是很快的。其次，当网站收录异常时我们要把正常收录的日志和异常的日志进行对比分析，找出问题所在，这样可以解决网站收录问题，也是对完整优化大有裨益的。第三，网站被搜索引擎K掉后，我们必须要观察网站日志文件来亡羊补牢，一般这种情况下，日志文件里只有很少的几个蜘蛛爬行了首页和robots，我们要找出被K的原因并改正，再提交给搜索引擎，接下来就可以通过观察日志来看蜘蛛是否正常来临，慢慢过一段时间，如果蜘蛛数量增加或者经常来临并且返回200状态吗，那么恭喜你，你的网站又活了，如果半年都没反应，那么建议放弃该域名重新再战了。
　　很多站长朋友不懂得如何利用网站日志文件，遇到网站收录问题就去提问别人，而不好好自检，这是作为站长或者seoer的悲哀。而且网上的很多软文都提到要做好日志文件的分析，但是那只是软文而已，说不定写文章的作者都没有去看日志文件。说到底，还是希望站长朋友一定不要忽略了网站日志文件，合理的利用好网站日志文件是一个站长或seoer必备的技能。再者说，看懂网站日志文件并不需要你有多么高深的编码知识，其实只要看得懂html代码和几个返回的状态码就可以了，一定不能懒，或者抱着侥幸心理去对待你的网站，这种心理会导致你输得很惨。如果你是一个小站长，或者你是一个seoer，如果你以前没有意识到网站日志文件的重要性，那么从看到我写的这篇文章开始要好好对待你的网站日志了。

Linux系统日志分析的基本教程

首先，我们将描述有关 Linux 日志是什么，到哪儿去找它们，以及它们是如何创建的基础知识
Linux 系统日志
许多有价值的日志文件都是由 Linux 自动地为你创建的。你可以在 /var/log 目录中找到它们。下面是在一个典型的 Ubuntu 系统中这个目录的样子：
　一些最为重要的 Linux 系统日志包括：
/var/log/syslog 或 /var/log/messages 存储所有的全局系统活动数据，包括开机信息。基于 Debian 的系统如 Ubuntu 在 /var/log/syslog 中存储它们，而基于 RedHat 的系统如 RHEL 或 CentOS 则在 /var/log/messages 中存储它们。
/var/log/auth.log 或 /var/log/secure 存储来自可插拔认证模块(PAM)的日志，包括成功的登录，失败的登录尝试和认证方式。Ubuntu 和 Debian 在 /var/log/auth.log 中存储认证信息，而 RedHat 和 CentOS 则在 /var/log/secure 中存储该信息。
/var/log/kern 存储内核的错误和警告数据，这对于排除与定制内核相关的故障尤为实用。
/var/log/cron 存储有关 cron 作业的信息。使用这个数据来确保你的 cron 作业正成功地运行着。
Digital Ocean 有一个关于这些文件的完整教程，介绍了 rsyslog 如何在常见的发行版本如 RedHat 和 CentOS 中创建它们。
应用程序也会在这个目录中写入日志文件。例如像 Apache，Nginx，MySQL 等常见的服务器程序可以在这个目录中写入日志文件。其中一些日志文件由应用程序自己创建，其他的则通过 syslog (具体见下文)来创建。
什么是 Syslog?
Linux 系统日志文件是如何创建的呢?答案是通过 syslog 守护程序，它在 syslog 套接字 /dev/log 上监听日志信息，然后将它们写入适当的日志文件中。
单词“syslog” 代表几个意思，并经常被用来简称如下的几个名称之一：
Syslog 守护进程 — 一个用来接收、处理和发送 syslog 信息的程序。它可以远程发送 syslog 到一个集中式的服务器或写入到一个本地文件。常见的例子包括 rsyslogd 和 syslog-ng。在这种使用方式中，人们常说“发送到 syslog”。
Syslog 协议 — 一个指定日志如何通过网络来传送的传输协议和一个针对 syslog 信息(具体见下文) 的数据格式的定义。它在 RFC-5424 中被正式定义。对于文本日志，标准的端口是 514，对于加密日志，端口是 6514。在这种使用方式中，人们常说“通过 syslog 传送”。
Syslog 信息 — syslog 格式的日志信息或事件，它包括一个带有几个标准字段的消息头。在这种使用方式中，人们常说“发送 syslog”。
Syslog 信息或事件包括一个带有几个标准字段的消息头，可以使分析和路由更方便。它们包括时间戳、应用程序的名称、在系统中信息来源的分类或位置、以及事件的优先级。
下面展示的是一个包含 syslog 消息头的日志信息，它来自于控制着到该系统的远程登录的 sshd 守护进程，这个信息描述的是一次失败的登录尝试：
341 2003-10-11T22:14:15.003Z server1.com sshd - - pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.2.2
Syslog 格式和字段
每条 syslog 信息包含一个带有字段的信息头，这些字段是结构化的数据，使得分析和路由事件更加容易。下面是我们使用的用来产生上面的 syslog 例子的格式，你可以将每个值匹配到一个特定的字段的名称上。
复制代码
代码如下:
%pri%%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name% %procid% %msgid% %msg%n
下面，你将看到一些在查找或排错时最常使用的 syslog 字段：
时间戳
时间戳 (上面的例子为 2003-10-11T22:14:15.003Z) 暗示了在系统中发送该信息的时间和日期。这个时间在另一系统上接收该信息时可能会有所不同。上面例子中的时间戳可以分解为：
2003-10-11 年，月，日。
T 为时间戳的必需元素，它将日期和时间分隔开。
22:14:15.003 是 24 小时制的时间，包括进入下一秒的毫秒数(003)。
Z 是一个可选元素，指的是 UTC 时间，除了 Z，这个例子还可以包括一个偏移量，例如 -08:00，这意味着时间从 UTC 偏移 8 小时，即 PST 时间。
主机名
主机名 字段(在上面的例子中对应 server1.com) 指的是主机的名称或发送信息的系统.
应用名
应用名 字段(在上面的例子中对应 sshd:auth) 指的是发送信息的程序的名称.
优先级
优先级字段或缩写为 pri (在上面的例子中对应 ) 告诉我们这个事件有多紧急或多严峻。它由两个数字字段组成：设备字段和紧急性字段。紧急性字段从代表 debug 类事件的数字 7 一直到代表紧急事件的数字 0 。设备字段描述了哪个进程创建了该事件。它从代表内核信息的数字 0 到代表本地应用使用的 23 。
Pri 有两种输出方式。第一种是以一个单独的数字表示，可以这样计算：先用设备字段的值乘以 8，再加上紧急性字段的值：(设备字段)(8) + (紧急性字段)。第二种是 pri 文本，将以“设备字段.紧急性字段” 的字符串格式输出。后一种格式更方便阅读和搜索，但占据更多的存储空间。
分析 Linux 日志
日志中有大量的信息需要你处理，尽管有时候想要提取并非想象中的容易。在这篇文章中我们会介绍一些你现在就能做的基本日志分析例子(只需要搜索即可)。我们还将涉及一些更高级的分析，但这些需要你前期努力做出适当的设置，后期就能节省很多时间。对数据进行高级分析的例子包括生成汇总计数、对有效值进行过滤，等等。
我们首先会向你展示如何在命令行中使用多个不同的工具，然后展示了一个日志管理工具如何能自动完成大部分繁重工作从而使得日志分析变得简单。
用 Grep 搜索
搜索文本是查找信息最基本的方式。搜索文本最常用的工具是 grep。这个命令行工具在大部分 Linux 发行版中都有，它允许你用正则表达式搜索日志。正则表达式是一种用特殊的语言写的、能识别匹配文本的模式。最简单的模式就是用引号把你想要查找的字符串括起来。
正则表达式
这是一个在 Ubuntu 系统的认证日志中查找 “user hoover” 的例子：
复制代码
代码如下:
$ grep "user hoover" /var/log/auth.log
Accepted password for hoover from 10.0.2.2 port 4792 ssh3
pam_unix(sshd:session): session opened for user hoover by (uid=0)
pam_unix(sshd:session): session closed for user hoover
构建精确的正则表达式可能很难。例如，如果我们想要搜索一个类似端口 “4792” 的数字，它可能也会匹配时间戳、URL 以及其它不需要的数据。Ubuntu 中下面的例子，它匹配了一个我们不想要的 Apache 日志。
复制代码
代码如下:
$ grep "4792" /var/log/auth.log
Accepted password for hoover from 10.0.2.2 port 4792 ssh3
74.91.21.46 - - "GET /scripts/samples/search?q=4972 HTTP/1.0" 404 545 "-" "-”
环绕搜索
另一个有用的小技巧是你可以用 grep 做环绕搜索。这会向你展示一个匹配前面或后面几行是什么。它能帮助你调试导致错误或问题的东西。B 选项展示前面几行，A 选项展示后面几行。举个例子，我们知道当一个人以管理员员身份登录失败时，同时他们的 IP 也没有反向解析，也就意味着他们可能没有有效的域名。这非常可疑!
复制代码
代码如下:
$ grep -B 3 -A 2 ’Invalid user’ /var/log/auth.log
Apr 28 17:06:20 ip-172-31-11-241 sshd failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 28 17:06:20 ip-172-31-11-241 sshd
Apr 28 17:06:20 ip-172-31-11-241 sshd: Invalid user admin from 216.19.2.8
Apr 28 17:06:20 ip-172-31-11-241 sshd
Apr 28 17:06:20 ip-172-31-11-241 sshd
Tail
你也可以把 grep 和 tail 结合使用来获取一个文件的最后几行，或者跟踪日志并实时打印。这在你做交互式更改的时候非常有用，例如启动服务器或者测试代码更改。
复制代码
代码如下:
$ tail -f /var/log/auth.log | grep ’Invalid user’
Apr 30 19:49:48 ip-172-31-11-241 sshd: Invalid user ubnt from 219.140.64.136
Apr 30 19:49:49 ip-172-31-11-241 sshd: Invalid user admin from 219.140.64.136
关于 grep 和正则表达式的详细介绍并不在本指南的范围，但 Ryan’s Tutorials 有更深入的介绍。
日志管理系统有更高的性能和更强大的搜索能力。它们通常会索引数据并进行并行查询，因此你可以很快的在几秒内就能搜索 GB 或 TB 的日志。相比之下，grep 就需要几分钟，在极端情况下可能甚至几小时。日志管理系统也使用类似 Lucene 的查询语言，它提供更简单的语法来检索数字、域以及其它。
用 Cut、 AWK、 和 Grok 解析
Linux 提供了多个命令行工具用于文本解析和分析。当你想要快速解析少量数据时非常有用，但处理大量数据时可能需要很长时间。
Cut
cut 命令允许你从有分隔符的日志解析字段。分隔符是指能分开字段或键值对的等号或逗号等。
假设我们想从下面的日志中解析出用户：
复制代码
代码如下:
pam_unix(su:auth): authentication failure; logname=hoover uid=1000 euid=0 tty=/dev/pts/0 ruser=hoover rhost= user=root
我们可以像下面这样用 cut 命令获取用等号分割后的第八个字段的文本。这是一个 Ubuntu 系统上的例子：
复制代码
代码如下:
$ grep "authentication failure" /var/log/auth.log | cut -d ’=’ -f 8
root
hoover
root
nagios
nagios
AWK
另外，你也可以使用 awk，它能提供更强大的解析字段功能。它提供了一个脚本语言，你可以过滤出几乎任何不相干的东西。
例如，假设在 Ubuntu 系统中我们有下面的一行日志，我们想要提取登录失败的用户名称：
复制代码
代码如下:
Mar 24 08:28:18 ip-172-31-11-241 sshd
你可以像下面这样使用 awk 命令。首先，用一个正则表达式 /sshd.*invalid user/ 来匹配 sshd invalid user 行。然后用 { print $9 } 根据默认的分隔符空格打印第九个字段。这样就输出了用户名。
复制代码
代码如下:
$ awk ’/sshd.*invalid user/ { print $9 }’ /var/log/auth.log
guest
admin
info
test
ubnt
你可以在 Awk 用户指南 中阅读更多关于如何使用正则表达式和输出字段的信息。
日志管理系统
日志管理系统使得解析变得更加简单，使用户能快速的分析很多的日志文件。他们能自动解析标准的日志格式，比如常见的 Linux 日志和 Web 服务器日志。这能节省很多时间，因为当处理系统问题的时候你不需要考虑自己写解析逻辑。
下面是一个 sshd 日志消息的例子，解析出了每个 remoteHost 和 user。这是 Loggly 中的一张截图，它是一个基于云的日志管理服务。
　你也可以对非标准格式自定义解析。一个常用的工具是 Grok，它用一个常见正则表达式库，可以解析原始文本为结构化 JSON。下面是一个 Grok 在 Logstash 中解析内核日志文件的事例配置：
复制代码
代码如下:
filter{
grok {
match = {"message" = "%{CISCOTIMESTAMP:timestamp} %{HOST:host} %{WORD:program}%{NOTSPACE} %{NOTSPACE}%{NUMBER:duration}%{NOTSPACE} %{GREEDYDATA:kernel_logs}"
}
}
下图是 Grok 解析后输出的结果：
　用 Rsyslog 和 AWK 过滤
过滤使得你能检索一个特定的字段值而不是进行全文检索。这使你的日志分析更加准确，因为它会忽略来自其它部分日志信息不需要的匹配。为了对一个字段值进行搜索，你首先需要解析日志或者至少有对事件结构进行检索的方式。
如何对应用进行过滤
通常，你可能只想看一个应用的日志。如果你的应用把记录都保存到一个文件中就会很容易。如果你需要在一个聚集或集中式日志中过滤一个应用就会比较复杂。下面有几种方法来实现：
用 rsyslog 守护进程解析和过滤日志。下面的例子将 sshd 应用的日志写入一个名为 sshd-message 的文件，然后丢弃事件以便它不会在其它地方重复出现。你可以将它添加到你的 rsyslog.conf 文件中测试这个例子。
复制代码
代码如下:
:programname, isequal, “sshd” /var/log/sshd-messages
~
用类似 awk 的命令行工具提取特定字段的值，例如 sshd 用户名。下面是 Ubuntu 系统中的一个例子。
复制代码
代码如下:
$ awk ’/sshd.*invalid user/ { print $9 }’ /var/log/auth.log
guest
admin
info
test
ubnt
用日志管理系统自动解析日志，然后在需要的应用名称上点击过滤。下面是在 Loggly 日志管理服务中提取 syslog 域的截图。我们对应用名称 “sshd” 进行过滤，如维恩图图标所示。
　如何过滤错误
一个人最希望看到日志中的错误。不幸的是，默认的 syslog 配置不直接输出错误的严重性，也就使得难以过滤它们。
这里有两个解决该问题的方法。首先，你可以修改你的 rsyslog 配置，在日志文件中输出错误的严重性，使得便于查看和检索。在你的 rsyslog 配置中你可以用 pri-text 添加一个 模板，像下面这样：
复制代码
代码如下:
"%pri-text% : %timegenerated%,%HOSTNAME%,%syslogtag%,%msg%n"
这个例子会按照下面的格式输出。你可以看到该信息中指示错误的 err。
复制代码
代码如下:
: Mar 11 18:18:00,hoover-VirtualBox,su:, pam_authenticate: Authentication failure
你可以用 awk 或者 grep 检索错误信息。在 Ubuntu 中，对这个例子，我们可以用一些语法特征，例如 . 和 ，它们只会匹配这个域。
复制代码
代码如下:
$ grep ’.err’ /var/log/auth.log
: Mar 11 18:18:00,hoover-VirtualBox,su:, pam_authenticate: Authentication failure
你的第二个选择是使用日志管理系统。好的日志管理系统能自动解析 syslog 消息并抽取错误域。它们也允许你用简单的点击过滤日志消息中的特定错误。
下面是 Loggly 中一个截图，显示了高亮错误严重性的 syslog 域，表示我们正在过滤错误：

华为服务器如何分析bmc日志

1、连接到服务器的BMC管理界面。可以通过服务器的IP地址和BMC的管理端口（一般为IPMI端口）登录BMC管理界面。
2、导航到日志页面。在BMC管理界面中，找到日志相关的菜单或选项，通常在“系统日志”或“事件日志”等位置。
3、查看和导出日志。在日志页面中，可以查看到BMC记录的各种事件和错误信息。根据需要，可以选择特定的日志进行查看，也可以导出整个日志文件。
4、分析日志内容。打开导出的日志文件，可以通过查找关键词、过滤特定事件等方式进行日志内容的分析。可以根据错误码、时间戳等信息来定位和解决问题。

「SpringCloud」（三十八）搭建ELK日志采集与分析系统

 一套好的日志分析系统可以详细记录系统的运行情况，方便我们定位分析系统性能瓶颈、查找定位系统问题。上一篇说明了日志的多种业务场景以及日志记录的实现方式，那么日志记录下来，相关人员就需要对日志数据进行处理与分析，基于E(ElasticSearch)L(Logstash)K(Kibana)组合的日志分析系统可以说是目前各家公司普遍的首选方案。

  作为微服务集群，必须要考虑当微服务访问量暴增时的高并发场景，此时系统的日志数据同样是爆发式增长，我们需要通过消息队列做流量削峰处理，Logstash官方提供Redis、Kafka、RabbitMQ等输入插件。Redis虽然可以用作消息队列，但其各项功能显示不如单一实现的消息队列，所以通常情况下并不使用它的消息队列功能；Kafka的性能要优于RabbitMQ，通常在日志采集，数据采集时使用较多，所以这里我们采用Kafka实现消息队列功能。
  ELK日志分析系统中，数据传输、数据保存、数据展示、流量削峰功能都有了，还少一个组件，就是日志数据的采集，虽然log4j2可以将日志数据发送到Kafka，甚至可以将日志直接输入到Logstash，但是基于系统设计解耦的考虑，业务系统运行不会影响到日志分析系统，同时日志分析系统也不会影响到业务系统，所以，业务只需将日志记录下来，然后由日志分析系统去采集分析即可，Filebeat是ELK日志系统中常用的日志采集器，它是 Elastic Stack 的一部分，因此能够与 Logstash、Elasticsearch 和 Kibana 无缝协作。

软件下载：

  因经常遇到在内网搭建环境的问题，所以这里习惯使用下载软件包的方式进行安装，虽没有使用Yum、Docker等安装方便，但是可以对软件目录、配置信息等有更深的了解，在后续采用Yum、Docker等方式安装时，也能清楚安装了哪些东西，安装配置的文件是怎样的，即使出现问题，也可以快速的定位解决。

***隐藏网址***

我们选择如下版本：

Kafka下载：

  安装前先准备好三台CentOS7服务器用于集群安装，这是IP地址为：172.16.20.220、172.16.20.221、172.16.20.222，然后将上面下载的软件包上传至三台服务器的/usr/local目录。因服务器资源有限，这里所有的软件都安装在这三台集群服务器上，在实际生产环境中，请根据业务需求设计规划进行安装。
  在集群搭建时，如果能够编写shell安装脚本就会很方便，如果不能编写，就需要在每台服务器上执行安装命令，多数ssh客户端提供了多会话同时输入的功能，这里一些通用安装命令可以选择启用该功能。

新建/usr/local/java目录

将下载的jdk软件包jdk-8u64-linux-x64.tar.gz上传到/usr/local/java目录，然后解压

配置环境变量/etc/profile

在底部添加以下内容

使环境变量生效

备注：后续可通过此命令停止elasticsearch运行

  新建kafka的日志目录和zookeeper数据目录，因为这两项默认放在tmp目录，而tmp目录中内容会随重启而丢失,所以我们自定义以下目录:

修改如下：

在data文件夹中新建myid文件，myid文件的内容为1（一句话创建：echo 1 》 myid）

kafka启动时先启动zookeeper，再启动kafka；关闭时相反，先关闭kafka，再关闭zookeeper。
1、zookeeper启动命令

后台运行启动命令：

或者

查看集群状态：

2、kafka启动命令

后台运行启动命令：

或者

3、创建topic，最新版本已经不需要使用zookeeper参数创建。

参数解释:
复制两份
　　--replication-factor 2
创建1个分区
　　--partitions 1
topic 名称
　　--topic test

4、查看已经存在的topic（三台设备都执行时可以看到）

5、启动生产者：

6、启动消费者：

添加参数 --from-beginning 从开始位置消费，不是从最新消息

7、测试：在生产者输入test，可以在消费者的两台服务器上看到同样的字符test，说明Kafka服务器集群已搭建成功。

Logstash没有提供集群安装方式，相互之间并没有交互，但是我们可以配置同属一个Kafka消费者组，来实现统一消息只消费一次的功能。

  Filebeat用于安装在业务软件运行服务器，收集业务产生的日志，并推送到我们配置的Kafka、Redis、RabbitMQ等消息中间件，或者直接保存到Elasticsearch，下面来讲解如何安装配置：

1、进入到/usr/local目录，执行解压命令

2、配置filebeat.yml
  配置文件中默认是输出到elasticsearch，这里我们改为kafka，同文件目录下的filebeat.reference.yml文件是所有配置的实例，可以直接将kafka的配置复制到filebeat.yml

后台启动命令

停止命令

2、测试logstash是消费Kafka的日志主题，并将日志内容存入Elasticsearch

自动新增的两个index，规则是logstash中配置的

数据浏览页可以看到Elasticsearch中存储的日志数据内容，说明我们的配置已经生效。

Gitee: GitEgg: GitEgg 是一款开源免费的企业级微服务应用开发框架，旨在整合目前主流稳定的开源技术框架，集成常用的最佳项目解决方案，实现可直接使用的微服务快速开发框架。
***隐藏网址***

MongoDB应用1——日志分析

线上运行的服务会产生大量的运行及访问日志，日志里会包含一些错误、警告、及用户行为等信息。通常服务会以文本的形式记录日志信息，这样可读性强，方便于日常定位问题。但当产生大量的日志之后，要想从大量日志里挖掘出有价值的内容，则需要对数据进行进一步的存储和分析。

本文以存储 web 服务的访问日志为例，介绍如何使用 MongoDB 来存储、分析日志数据，让日志数据发挥最大的价值。本文的内容同样适用于其他的日志存储型应用。

一个典型的web服务器的访问日志类似如下，包含访问来源、用户、访问的资源地址、访问结果、用户使用的系统及浏览器类型等。

最简单存储这些日志的方法是，将每行日志存储在一个单独的文档里，每行日志在MongoDB里的存储模式如下所示：

上述模式虽然能解决日志存储的问题，但这些数据分析起来比较麻烦，因为文本分析并不是MongoDB所擅长的，更好的办法是把一行日志存储到MongoDB的文档里前，先提取出各个字段的值。如下所示，上述的日志被转换为一个包含很多个字段的文档。

同时，在这个过程中，如果您觉得有些字段对数据分析没有任何帮助，则可以直接过滤掉，以减少存储上的消耗。比如数据分析不会关心user信息、request、status信息，这几个字段没必要存储。ObjectId里本身包含了时间信息，没必要再单独存储一个time字段 (当然带上time也有好处，time更能代表请求产生的时间，而且查询语句写起来更方便，尽量选择存储空间占用小的数据类型）基于上述考虑，上述日志最终存储的内容可能类似如下所示：

日志存储服务需要能同时支持大量的日志写入，用户可以定制writeConcern来控制日志写入能力，比如如下定制方式：

同时，为了达到最优的写入效率，用户还可以考虑批量的写入方式，一次网络请求写入多条日志。格式如下所示：

db.events.insert()

当日志按上述方式存储到MongoDB后，就可以按照各种查询需求查询日志了。

q_events = db.events.find({’path’: ’/apache_pb.gif’})

如果这种查询非常频繁，可以针对path字段建立索引，提高查询效率：

db.events.createIndex({path: 1})

通过对time字段建立索引，可加速这类查询：

db.events.createIndex({time: 1})

同样，用户还可以使用MongoDB的aggregation、mapreduce框架来做一些更复杂的查询分析，在使用时应该尽量建立合理的索引以提升查询效率。

当写日志的服务节点越来越多时，日志存储的服务需要保证可扩展的日志写入能力以及海量的日志存储能力，这时就需要使用MongoDB sharding来扩展，将日志数据分散存储到多个shard，关键的问题就是shard key的选择。

使用时间戳来进行分片（如ObjectId类型的_id，或者time字段），这种分片方式存在如下问题：

按照_id字段来进行hash分片，能将数据以及写入都均匀都分散到各个shard，写入能力会随shard数量线性增长。但该方案的问题是，数据分散毫无规律。所有的范围查询（数据分析经常需要用到）都需要在所有的shard上进行查找然后合并查询结果，影响查询效率。

假设上述场景里 path 字段的分布是比较均匀的，而且很多查询都是按path维度去划分的，那么可以考虑按照path字段对日志数据进行分片，好处是：

不足的地方是：

当然上述不足的地方也有办法改进，方法是给分片key里引入一个额外的因子,比如原来的shard key是 {path: 1}，引入额外的因子后变成：

{path: 1, ssk: 1} 其中ssk可以是一个随机值，比如_id的hash值，或是时间戳，这样相同的path还是根据时间排序的

这样做的效果是分片key的取值分布丰富，并且不会出现单个值特别多的情况。上述几种分片方式各有优劣，用户可以根据实际需求来选择方案。

分片的方案能提供海量的数据存储支持，但随着数据越来越多，存储的成本会不断的上升。通常很多日志数据有个特性，日志数据的价值随时间递减。比如1年前、甚至3个月前的历史数据完全没有分析价值，这部分可以不用存储，以降低存储成本，而在MongoDB里有很多方法支持这一需求。

MongoDB的TTL索引可以支持文档在一定时间之后自动过期删除。例如上述日志time字段代表了请求产生的时间，针对该字段建立一个TTL索引，则文档会在30小时后自动被删除。

db.events.createIndex( { time: 1 }, { expireAfterSeconds: 108000 } )

如果对日志保存的时间没有特别严格的要求，只是在总的存储空间上有限制，则可以考虑使用capped collection来存储日志数据。指定一个最大的存储空间或文档数量，当达到阈值时，MongoDB会自动删除capped collection里最老的文档。

db.createCollection("event", {capped: true, size: 104857600000}

比如每到月底就将events集合进行重命名，名字里带上当前的月份，然后创建新的events集合用于写入。比如2016年的日志最终会被存储在如下12个集合里：

当需要清理历史数据时，直接将对应的集合删除掉：

不足之处，在于到时候，如果要查询多个月份的数据，查询的语句会稍微复杂些，需要从多个集合里查询结果来合并。

分布式日志系统Graylog、Loki及ELK的分析和对比

日志系列：

企业级日志平台新秀Graylog，比ELK轻量多了

日志系统新贵Loki，比ELK轻量多了

1. 为什么需要集中的日志系统？

在分布式系统中，众多服务分散部署在数十台甚至是上百台不同的服务器上，要想快速方便的实现查找、分析和归档等功能，使用Linux命令等传统的方式查询到想要的日志就费时费力，更不要说对日志进行分析与归纳。

如果有一个集中的日志系统，便可以将各个不同的服务器上面的日志收集在一起，不仅能方便快速查找到相应的日志，还有可能在众多日志数据中挖掘到一些意想不到的关联关系。

作为DevOps工程师，会经常收到分析生产日志的需求。在机器规模较少、生产环境管理不规范时，可以通过分配系统账号，采用人肉的方式登录服务器查看日志。然而高可用架构中，日志通常分散在多节点，日志量也随着业务增长而增加。当业务达到一定规模、架构变得复杂，靠人肉登录主机查看日志的方式就会变得混乱和低效。解决这种问题的方法，需要构建一个日志管理平台：对日志进行汇聚和分析，并通过Web UI授权相关人员查看日志权限。

2. 日志系统选择与对比

关于企业级日志管理方案，比较主流的是ELK stack和Graylog。

常见的分布式日志系统解决方案有经典的ELK和商业的splunk。为什么没有选择上面的两种方案呢，原因主要是如下两种：

ELK目前很多公司都在使用，是一种很不错的分布式日志解决方案，但是需要的组件多，部署和维护相对复杂，并且占用服务器资源多，此外kibana也在高版本中开始商业化。

splunk是收费的商业项目，不在考虑范围。

3. 认识graylog

3.1 简介

graylog是一个简单易用、功能较全面的日志管理工具，graylog也采用Elasticsearch作为存储和索引以保障性能，MongoDB用来存储少量的自身配置信息，master-node模式具有很好的扩展性，UI上自带的基础查询与分析功能比较实用且高效，支持LDAP、权限控制并有丰富的日志类型和标准（如syslog，GELF）并支持基于日志的报警。

在日志接收方面通常是网络传输，可以是TCP也可以是UDP，在实际生产环境量级较大多数采用UDP，也可以通过MQ来消费日志。

3.2 优势

部署维护简单

资源占用较少

查询语法简单易懂(对比ES的语法…)

内置简单的告警

可以将搜索结果导出为 json

UI 比较友好

3.3 graylog单机架构图

3.4 graylog集群架构

4、基于 GrayLog & ELK 的日志监控

Collector

FileBeat：轻巧占用资源少，但是功能有点弱。「想起了一些东西，都是泪」

Fluentd：个人理解在Logstash与FileBeat中间，可以简单处理一些日志，插件丰富「要再研究下」

自己弄：架构图里面只是mysql调用了自己实现的解析工具，但是其实当日志大到一定的量的还是必须自己来的，类似日志抽样、降级、控制频率等功能，是要真真切切的花费大量时间精力下去的一个sidecar并非动动嘴巴就能搞定的。「都是泪」

Queue

Kafka：王者地位「量小的时候也可以不用这个直接朝后面输出，有很多中间方案大家自己脑补」，不同的日志分不同的topic，严格区分日志所属类型，为后续消费打下基础，比如A业务进入A Topic并在日志中打上所属语言类型的Tag。

Consumer

Logstash：其实这个东西也可以作为收集端来使用，就是比较耗费资源有点重，还会莫名其妙挂了「应该是我不会玩」

GrayLog：本人最喜欢的一个组件，集解析、报警、简单分析、Dashboard、日志TTL的综合体，有这个东西吧其实Kibana就没啥用了，毕竟谁没事天天去分析日志。

Storage

ElasticSearch：全文索引Engine，其实并没有官方说的那么牛，当到一定的并发写入、大量查询之后其实根本不是加机器能解决的，怎么分shard，是按照天保存还是按照条数保存「我比较喜欢按照条数保存，这样可以保证每个index都差不多大小，对于reblance是有好处的，重复利用多盘」如何保存是需要不断调整的。「我们这边不讨论MongoDB去存日志，看着都不靠谱」

规范

其实日志系统最关键的是怎么打、什么格式打、但是这个东西需要消耗大量的时间去定义与各个部门Pk，遇到过大量不讲理的输出，直接线上Debug，600k的并发写入，日志又大又臭谁能扛得住「阿里云的SLS是真的很牛」

卷起袖子加油干，少动嘴，多动手，日志很好玩。在容器化的大环境下也越发的重要。

Flunted + Elasticsearch + Kibana的方案，发现有几个缺点：

不能处理多行日志，比如Mysql慢查询，Tomcat/Jetty应用的Java异常打印

不能保留原始日志，只能把原始日志分字段保存，这样搜索日志结果是一堆Json格式文本，无法阅读。

不符合正则表达式匹配的日志行，被全部丢弃。

对比图

总结

虽然两种解决方案在功能上非常相似，但仍有一些差异需要考虑。

两者之间最重要的区别在于，从一开始，Graylog就定位为强大的日志解决方案，而ELK则是大数据解决方案。Graylog可以通过网络协议直接从应用程序接收结构化日志和标准syslog。相反，ELK是使用Logstash分析已收集的纯文本日志的解决方案，然后解析并将它们传递给ElasticSearch。

在ELK中，Kibana扮演仪表盘的角色并显示从Logstash收到的数据。Graylog在这点上更方便，因为它提供了单一应用程序解决方案（不包括ElasticSearch作为灵活的数据存储），具有几乎相同的功能。因此，部署所需的时间更短。此外，与ELK相比，Graylog开箱即用，且具有出色的权限系统，而Kibana则不具备此功能。作为Elasticsearch的粉丝，我更喜欢Graylog而不是ELK，因为它完全符合我在日志管理方面的需求。

Graylog具有直观的GUI，并提供警报、报告和自定义分析功能。最重要的是，它能在多个日志源和跨机房收集数TB的数据。基于这些优势，我更喜欢用Graylog而不是另一个具有类似功能的流行堆栈——ELK。

如果有需要领取免费资料的小伙伴们， 可以点击此处领取资料哦！

为什么要分析日志

• 网络设备、系统及服务程序等，在运作时都会产生一个叫log的事件记录；每一行日志都记载着日期、时间、使用者及动作等相关操作的描述。

• Windows网络操作系统都设计有各种各样的日志文件，如应用程序日志，安全日志、系统日志、Scheduler服务日志、FTP日志、WWW日志、DNS服务器日志等等，这些根据你的系统开启的服务的不同而有所不同。我们在系统上进行一些操作时，这些日志文件通常会记录下我们操作的一些相关内容，这些内容对系统安全工作人员相当有用。比如说有人对系统进行了IPC探测，系统就会在安全日志里迅速地记下探测者探测时所用的IP、时间、用户名等，用FTP探测后，就会在FTP日志中记下IP、时间、探测所用的用户名等。

• 当然，日志数据对于实现网络安全的价值有多大取决于两个因素：第一，你的系统和设备必须进行合适的设置以便记录你需要的数据。第二，你必须有合适的工具、培训和可用的资源来分析收集到的数据。

elk日志分析平台是什么意思

首字母为该管理系统三个主要软件：Elasticsearch、Logstash、Kibana。这三个并非该管理系统的全部组成，而且还可以添加Redis,kafka,filebeat等软件

它们各自的功能大概可以这样概述：E：实时分析、实时检索、海量存储，建立索引，以便日后快速查看、搜索、分析

L：数据流传输、日志结构化

K：分析统计、酷炫图表

传统的日志架构存在的以下若干缺点：

• 开发人员无权登录，经过运维周转费时费力

• 日志数据分散在多个系统，难以查找

• 日志数据量大，查询速度慢

• 一个调用会涉及多个系统，难以在这些系统的日志中快速定位数据

• 数据不够实时

因此，需要日志分析产品，美国有Splunk，中国有日志易。也有更多的企业在使用开源产品，也就是题主说到的ELK。

如何进行网站日志分析

一、什么是网站日志

1.网站日志是记录web服务器接收处理请求以及运行时错误等各种原始信息的以·log结尾的文件。

2.通过网站日志可以清楚的得知用户在什么IP、什么时间、用什么操作系统、什么浏览器、什么分辨率设备下访问了网站的哪个页面，是否访问成功。

3.搜索引擎也属于网站中的一类用户，我们今天的分享课，主要是针对搜索引擎这种用户在服务器留下的记录展开分析。

为了方便读懂搜索引擎日志，我们需要了解不同搜索引擎蜘蛛的标识，以下为4种搜索引擎的标识——*百度蜘蛛：Baispider*搜狗：SogouNewsSpider*360：360Spider*谷歌：Googlebot

二、如何看懂网站日志

通常日志文件较大的情况下，需要借助shell与python结合起来，做数据提取与分析。所以读懂网站日志中的字段就有利于日常的分析。这个在此不赘述，有兴趣的童鞋可以继续深入了解。

大型网站通常可以用以上的方法来进行做日志分析。

普通的个人站点，或者企业网站，则可以通过光年日志分析工具结合百度站长平台一起使用。

三、为什么要做网站日志分析

先来了解SEO流量的获取流程：抓取－－》索引－－－》排名－－－》点击－－－》流量

因此，要获得SEO流量的前提务必是，有价值的页面被搜索引擎抓取到。

四、怎么做网站日志分析

*定期监控搜索引擎抓取量变化，历史数据的横向纵向对比才能发现异常情况。*借助第三方站长平台，如百度站长平台，了解搜索引擎抓取频次变化。*借助光年日志分析工具，定期做数据记录，了解重要栏目、重要页面的抓取量变化。

举个栗子：

老站点（建站1年且有人维护的网站）：Seo流量出现异常波动。

分2种情况：

了解外界：了解外界的前提在于平时你得有一定的人脉基础，如果没有也没关系。泡2个地方——去搜索引擎站长平台或者加入搜索引擎站长群。比如，像百度搜索引擎，它拥有站长平台，也会相应建立站长QQ群。有人脉基础上，可以直接了解外界的情况——是否也出现类似幅度的波动？这个的前提要结合你短期做过的SEO操作一并考虑，避免误判。无人脉的情况，泡群、泡站长平台。通常如果是搜索引擎算法升级，会在群里或者站长平台有相关的小道信息出现。如果是搜索引擎自身算法升级导致的流量波动，那么就得根据新算法做相应的站内优化。比如，百度冰桶3.0版本提出：将严厉打击在百度移动搜索中，打断用户完整搜索路径的调起行为。如果站点有存在以上的情况就需要针对性的做优化：无论是通过对接的APPLINK调起，还是网页自主调起的应用，以及普通的网页，都应是可返回，可关闭的。用户校验搜索结果的准确性，不需要额外下载APP或者权限。

分析内在：

在分析内在之前，再次抛出这个公式：Seo流量=抓取量*收录率（准确来说应该是索引率）*首页率*点击率

。当抓取频次出现异常必然引起抓取量的减少。因此，排除了外界的因素，就需要对网站的日志进行分析。如果你的站点是中文站点，且是百度站长平台的VIP用户。那么，你就可以先借助第三方站长平台的“抓取频次”工具（如，百度），先了解搜索引擎近期的抓取频次、抓取时间、异常页面。通常借助这个工具，我们可以对搜索引擎近期抓取情况有初步了解，并且可以借助这个工具，相应的找到一些解决办法。

在此先解释这个概念，方便理解：

1.抓取频次：抓取频次是搜索引擎在单位时间内（天级）对网站服务器抓取的总次数，如果搜索引擎对站点的抓取频次过高，很有可能造成服务器不稳定，蜘蛛会根据网站内容更新频率和服务器压力等因素自动调整抓取频次。

2.抓取时间：指的是搜索引擎每次抓取耗时。而影响抓取频次的可能原因有：

（1）抓取频次上限误调，调低了，则会直接影响到抓取量减少，抓取量减少则索引量少，流量相应减少。

小结一下：

老站如何做网站日志分析（针对中文站点）：外界排除：

了解搜索引擎最新算法是否发生变动、同行是否也有类似变化。

内在分析：

（1）使用工具：百度站长平台（非VIP账户看后文介绍）

（2）分析方法：主要使用抓取频次分析工具进行分析，网站抓取频次、抓取时间、异常页面情况等数据变化。并与相关部门进行对接解决。

五、用光年日志分析工具

非百度VIP：

步骤：

1.下载网站日志（如果是企业站点，可以直接让运维部门的童鞋帮忙下载，如果是个人站长，直接在你所购买的虚拟主机后台进行下载，文件以.log为结尾的便是）

2.打开光年日志分析工具，上传网站日志。

3.查看分析结果。主要维度有这几个：

（1）概况分析：各种爬虫的总抓取量、总停留时间、总访问次数。

（2）目录分析：各种爬虫抓取各目录的情况分析。通过这个可以了解到搜索引擎对一些重要栏目的抓取情况，又抓取了哪些无效的页面。

（3）页面分析：通过页面分析可以了解到经常被重复抓取的页面有哪些，可以相应的做优化调整。比如，像网站的一些注册页面及登录页面，经常会发现多次被抓取，发现这种情况，我们通常会将登录/注册页面进行屏蔽处理。

（4）状态码分析主要分为2种，爬虫状态码以及用户状态码。主要反应用户/爬虫访问页面时的页面状态。通过页面状态码，我们可以了解到页面状态，做相应调整，如，当网站存在大量404页面。那就需要进一步排查，比如，有些团购页面，团购过期后，页面就直接变成404了，但并未向百度站长平台提交死链清单，则容易造成无效抓取。