某天领导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一般用来收集分布式架构下各个节点的日志，并进行统一地管理。
| |
我在个人站点的左下角和右下角各自使用了如下代码来将页面滚动到顶部和底部：
| |
有这样一道有趣的题目：
| |
出于业务考虑，将多个字符串拼接起来时，使用的分隔符是;,;。如果要将这样一个拼接来的字符串分割成原本的多个字符串时，就需要使用到jdk自带的split()方法。不过因为公司的编程规范，改为使用了Apache工具类的StringUtils.split()。
之后就发现，当被拼接的字符串里含有;或,时，就会出现分割不正确的问题。
今天在查看项目代码时发现有这样一个逻辑：在查询数据库时通过代码去拼接一个SQL，这个SQL的某个字段的别名是由多个变量名拼接而成的，于是在拼接该别名时特地限制了其长度为30，如果超过30就只截取前30个字符来作为列别名。
一时间很好奇为什么要限制列别名的长度，查阅过资料才明白，原来数据库的名字、表名、表别名、列名、列别名和函数名等，这些都属于标识符，不同数据库对于标识符会限定各种的长度最大值。
