使用Hexo搭建个人博客也有两年多时间了，当文章数量达到上百篇之后，开始发现Hexo生成文章的效率越来越慢，直到每次生成都需要至少五分钟的时间。我发现生成效率和文章涉及到的分类和标签有很大关系，由于文章数量多，每篇文章又都关联了若干个分类和标签，再加上我使用了压缩样式的插件，最终导致极其低下的生成效率。
在经过一段时间的考量后，决定将Hexo博客迁移到Hugo。Hugo是用go语言开发的，在用法上和Hexo类似，可以简单地把Hugo当成go语言版的Hexo，但是它拥有更快的生成效率。下面是官网的原话：
一般开发项目时可以直接本地借助IDE工具进行debug调试，但对于线上的项目，则需要借助Java提供的远程debug功能来进行调试。可以在启动项目前通过配置对应的JVM参数来启用远程debug，也可以把参数添加到Tomcat或者Jetty之类的启动脚本里。
| |
参数说明：
on和where后都表示查询条件，它们的区别如下：
1、on只能用于连接查询（内连接、外连接、交叉连接），在其他情况下使用on会报错，比如：
| |
2、连接查询会产生一张中间表(临时表)，on是在生成中间表时使用的条件；而where是在中间表生成后对中间表进行过滤使用的条件。比如：
某天领导report了一个问题：线上的CPU自从上一个版本迭代后就一直处于居高不下的状况，领导看着这段时间的曲线图判断是有两条线程在不停的死循环。
接到任务后去查看了AWS的CloudWatch，发现线上CPU确实一直居高不下，使用率基本是之前的两倍；另外发现线程使用率以比之前频繁很多。后来公司的大佬拿到dump后经过分析发现，是由正则表达式造成的CPU持续高使用率的问题。
在启动公司项目时发现报错如下：
| |
启动Logstash时可以指定一些参数：
| |
Kibana在创建Index Patterns的时候，可以选择某个date类型的field作为排序字段。之后在Discover里打开对应的index，会发现这个date类型的field的格式显示如下：
| |
这是Kibana默认的日期格式，有两种修改的方式。
最近公司分了个ELK相关的任务给我，在一边学习一边工作之余，总结下这些天来的学习历程和踩坑记录。
首先介绍下使用ELK的项目背景：在项目的数据库里有个表用来存储消息队列的消费日志，这些日志用于开发者日后的维护。每当客户端生产一条消息并发送到消息队列后，就会插入一条对应的记录到数据库里。当这条消息被消费之后，又会更新数据库里对应的记录的几个column的值，比如status、updated_on这些常用的column。
由于客户每天生产消费的消息很多，导致数据库里的这个表里的数据很多，长年累月下来，会达到数以亿计。领导决定不再把这些消费日志保存到数据库，而是改为通过Log4j2 + ELK架构把这些日志保存到Elasticsearch里。
ELk是Elasticsearch + Logstash + Kibana的缩写，ELK一般用来收集分布式架构下各个节点的日志，并进行统一地管理。
