logstash+kafka

线上项目的日志在整个系统中的重要性不言而喻，以往日志往往成为发现错误用来查看错误信息的工具，但是这其实时间相对滞后了，如果能比使用者更早发现问题，就能更好的应对了，这次我们介绍使用lostash+kafka来监控错误日志发送邮件的功能。

把准备好的包上传到服务器上，这里我放在 /usr/local 文件夹下，准备工作做好下面我们开始部署环境了~

在生产者窗口输入经典的hello world,在消费者窗口马上出现，这里就说明ok了！

logstash比较简单，不需要配置

至此，logstash+kafka的配置已经结束，后面只需要将日志输入logtsash，使用应用接收kafka消息来发送错误邮件，这些后面再介绍~~

在ELK架构中，使用logstash收集服务器中的日志并写入到Elasticsearch中，有时候需要对日志中的字段mapping进行特殊的设置，此时可以通过自定义模板template解决，但是因为logstash默认会向Elasticsearch提交一个名为logstash的模板，所以在定义logstash配置文件时有一些关键点需要注意。本文基于logstash-564和elastcisearch-564对需要注意的关键点进行列举。

默认的logstash模板：

使用logstash收集日志时， 如果对日志中的字段mapping没有特殊的要求，使用以下的logstash 配置文件1conf就可以满足需求：

1conf:

上述配置实现收集nginx的访问日志并写入到Elasticsearch集群中去，这种情况下logstash会向Elasticsearch创建一个名为logstash-的按天创建的index以及名为logstash的template，之后每天创建一个logstash-%{+YYYYMMdd}的index用于存储日志。

这种情况下，logstash-%{+YYYYMMdd}索引就会有两个type, 一个是 defalut , 一个是logs

如果不想使用logstash默认创建的模板创建索引，有两种解决方式，一是可以在logstash配置文件中的output中指定index索引名称, 如2conf所示：

2conf:

使用2conf, logstash会向Elasticsearch提交创建一个名为"nginx_access-%{+YYYYMMdd}"的索引，并且只有一个名为“logs”的type

第二种解决方式是在output中指定manage_template=>false，如3conf所示：

3conf

使用3conf配置，logstash会向Elasticsearch提交创建一个名为"logstash-%{+YYYYMMdd}"的索引,并且只有一个名为“logs”的type 注意此时logstash将不会提交创建名为logstash的模板。

默认情况下，logstash向Elasticsearch提交创建的索引的type为"logs",如果需要自定义type, 有两种方式，一种是在output里指定document_type参数，另一种是在input里指定type参数， output里的document_type优先级大于input里的type

使用自定义模板有两种方式，一种是启动logstash之前先调用Elasticsearch的API创建模板，并指定模板匹配的索引名称pattern以及模板优先级，具体可参考官方文档 >

git是一个分布式版本控制软件，最初由林纳斯·托瓦兹创作，于2005年以GPL发布。最初目的是为更好地管理Linux内核开发而设计。林纳斯·托瓦兹在编写第一个版本时就使用了“git”这个名称， 他将工具描述为“愚蠢的内容跟踪器”。

[上传失败(image-c23291-1619063471664)]

四个专有名词：

Workspace：工作区

Index / Stage：暂存区

Repository：仓库区（或本地仓库）

Remote：远程仓库

打开本地生成的git隐藏文件

创建新项目gittest

创建新文件testtxt

git add <file>

git status显示有变更的文件

git restore <file> 撤回文件修改内容

git commit –m “注释”

修改内容-> 执行git diff工作区和本地仓库的差异

git log显示当前分支的版本历史

git reset --hard HEAD^ 当前版本回退到上一个版本

git reset --hard HEAD^ ^ 当前版本回退到上上一个版本

git reset --hard HEAD~100 回退到前100个版本

恢复已经删除的版本

git reflog 展示所有的提交记录

git reset --hard <版本号> 回退到指定版本

git push origin master 将本地master分支推送到远程master分支，相当于创建远程分支

git checkout -b dev = git branch dev + git checkout dev 创建并切换分支

git branch 不带参数，会列出所有本地的分支；带参数表示创建分支

git branch –d name 删除本地分支(-D表示强制删除）

git branch –r 不带参数，会列出所有远程的分支

git branch --set-upstream-to=origin/<branch本地> 本地和远程分支关联

git push origin –delete <branch> 删除远程分支

git merge release用于合并指定分支到当前分支上

注：Fast-forward表示的合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。在这种模式下，删除分支后，会丢掉分支日志信息。可以使用带参数 --no-ff来禁用”Fast forward”模式。

git merge --no-ff -m “注释”dev

git checkout release 切换release分支

vim testtxt 修改某条内容

git commit testtxt -m “release修改某条内容”

git checkout master 切换master分支

vim testtxt 修改某条同release内容

git commit testtxt -m “master修改某条内容”

git merge release 显示冲突

git status 显示冲突提示

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，其中>>>>release 是指release上修改的内容
vim testtxt 修改内容

git add testtxt

git commit -a -m “fix conflict”

当前分支有没有提交但也不合适现在就提交的内容，Git提供了暂储功能stash

git checkout release

vim testtxt 修改testtxt内容

git checkout develop 此时会提示Aborting

git status 查看当前状态

Git stash list 查看所有暂储列表

git stash apply恢复，恢复后stash内容并不删除，你需要使用命令git stash drop来删除；
另一种方式是使用git stash pop,恢复的同时把stash内容也删除了

创建Git Tag并推送远程服务器

git tag -a V100 –m“注释” //创建TAG

git push origin V100 //推送到远程服务器

git push origin --tag //提交所有tag至服务器

git tag -d V100 //删除本地标签

git push origin --delete tag <tagname> //删除远程标签

HEAD，它始终指向当前所处分支的最新的提交点。你所处的分支变化了，或者产生了新的提交点，HEAD就会跟着改变

add相关命令很简单，主要实现将工作区修改的内容提交到暂存区，交由git管理。

git add 添加当前目录的所有文件到暂存区

git add 添加指定目录到暂存区，包括子目录

git add 添加指定文件到暂存区

commit相关命令也很简单，主要实现将暂存区的内容提交到本地仓库，并使得当前分支的HEAD向后移动一个提交点。

git commit -m 提交暂存区到本地仓库,message代表说明信息

git commit --amend -m 使用一次新的commit，替代上一次提交

上传本地仓库分支到远程仓库分支，实现同步。

git push 上传本地指定分支到远程仓库

git push --force强行推送当前分支到远程仓库，即使有冲突

git push --all推送所有分支到远程仓库

关于分支，大概有展示分支，切换分支，创建分支，删除分支这四种 *** 作。

git branch列出所有本地分支

git branch -r列出所有远程分支

git branch -a列出所有本地分支和远程分支

git branch 新建一个分支，但依然停留在当前分支

git checkout -b 新建一个分支，并切换到该分支

git checkout 切换到指定分支，并更新工作区

git branch -d 删除分支

git push origin --delete 删除远程分支

关于分支的 *** 作虽然比较多，但都比较简单好记

merge命令把不同的分支合并起来。在实际开放中，我们可能从master分支中切出一个分支，然后进行开发完成需求，中间经过R3,R4,R5的commit记录，最后开发完成需要合入master中，这便用到了merge。

git merge 合并指定分支到当前分支

注：如果在merge之后，出现conflict，主要是因为两个用户修改了同一文件的同一块区域。需要针对冲突情况，手动解除冲突。

rebase又称为衍合，是合并的另外一种选择。

在开始阶段，我们处于new分支上，执行git rebase dev，那么new分支上新的commit都在dev分支上重演一遍，最后checkout切换回到new分支。这一点与merge是一样的，合并前后所处的分支并没有改变。

git rebase dev，通俗的解释就是new分支想站在dev的肩膀上继续下去。

rebase *** 作不会生成新的节点，是将两个分支融合成一个线性的提交。

rebase也需要手动解决冲突。

1如果你想要一个干净的，没有merge commit的线性历史树，那么你应该选择git rebase

2如果你想保留完整的历史记录，并且想要避免重写commit history的风险，你应该选择使用git merge

reset命令把当前分支指向另一个位置，并且相应的变动工作区和暂存区。

git reset —soft 只改变提交点，暂存区和工作目录的内容都不改变

git reset —mixed 改变提交点，同时改变暂存区的内容

git reset —hard 暂存区、工作区的内容都会被修改到与提交点完全一致的状态

git revert用一个新提交来消除一个历史提交所做的任何修改。

在回滚这一 *** 作上看，效果差不多。git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。

在 Git工作区的根目录创建一个特殊的gitignore文件。

在gitignore文件中，添加需要忽略的文件。

git rm -r --cached //将仓库中的index递归删除

git add //重新添加仓库索引

git commit -m “update gitignore” //提交

git branch --set-upstream-to=origin/<branch> <branch> //重现将本地仓库和远程仓库关联

最后，如果此篇博文对你有所帮助，别忘了点个赞哟~

---