最近日志系统经常出问题，经过排查发现logstash cpu占用过高也是很严重问题之一，所以在此记录下，logstash常用的配置和使用技巧。

grok 的理解

grok 是 logstash filter最常用，最有用的模块了。 基本上对数据处理都需要用到它。 在grok中 metch又是其中的关键。它的主要作用就是把message某些字段扣出来，然后赋值给另一个字段。

eg:

1
2
3

grok {
            match => { "message" => "%{DATA:data}metrics_event%{GREEDYDATA:message_tag}end_event" }
          }

其中，要操作的是”message”这个字段，用一段正则将其描述，其中用”%{}”括起来的就是我们关注的字段,格式就是 %{一段正则:字段名:类型} 这样的三段式， 最后的类型可以不写。这样就可以添加一些字段了，同时会保留 message 原有信息。

问题描述

目前公司很多服务会通过nginx调用到外部服务，业务量起来的时候，通过查看上游日志，可以看到有大量的连接产生，随着连接数增加会给服务器带来巨大压力。
所以针对这个问题去做一些性能优化。
优化项如下：

1. 更换基础nginx镜像为淘宝tengine镜像 — tengine 支持upstream同时还支持域名动态解析，同时编译支持lua,具体模块为： ngx_http_upstream_keepalive_module，ngx_http_upstream_dynamic_module。由于没有官方提供的tengine docker镜像 需要自己编译打包。
2. 修改pod dns选项优化查询域。
3. 配置文件参数调优,主要针对 https，以及websocket。

最近公司某些接口经常遭到cc攻击，暂时可以通过配置nginx来缓解这个问题，在这里记录下处理的思路和流程。

整个环节分为两个步骤，首先识别出真正的客户端ip地址，然后针对这些地址去做访问速率限制，禁止频繁请求，在这里我们使用ngx_http_limit_req_module和ngx_http_limit_conn_module 来限制资源请求。

识别客户端地址

由于大量使用了cdn以及经过了层层代理，直接使用nginx的$remote_addr无法得到真正的客户端ip，显示的大概率是上层代理的ip。所以在这里我们使用了http_realip_module这个模块来解决这个问题。

http_realip_module 由三个部分组成：

1、set_real_ip_from 是指接受从哪个信任前代理处获得真实用户ip

2、real_ip_header 是指从接收到报文的哪个http首部去获取前代理传送的用户ip

3、real_ip_recursive 是否递归地排除直至得到用户ip（默认为off）

首先，real_ip_header 指定一个http首部名称，默认是X-Real-Ip，假设用默认值的话，nginx在接收到报文后，会查看http首部X-Real-Ip。

（1）如果有1个IP，它会去核对，发送方的ip是否在set_real_ip_from指定的信任ip列表中。如果是被信任的，它会去认为这个X-Real-Ip中的IP值是前代理告诉自己的，用户的真实IP值，于是，它会将该值赋值给自身的$remote_addr变量；如果不被信任，那么将不作处理，那么$remote_addr还是发送方的ip地址。

（2）如果X-Real-Ip有多个IP值，比如前一方代理是这么设置的：proxy_set_header X-Real-Ip $proxy_add_x_forwarded_for;

得到的是一串IP，那么此时real_ip_recursive 的值就至关重要了。nginx将会从ip列表的右到左，去比较set_real_ip_from 的信任列表中的ip。如果real_ip_recursive为off，那么，当最右边一个IP，发现是信任IP，即认为下一个IP（右边第二个）就是用户的真正IP；如果real_ip_recursive为on，那么将从右到左依次比较，知道找到一个不是信任IP为止。然后同样把IP值复制给$remote_addr。

了解了这个原理接下来就比较好操作了。

最近由于工作需要，要将logstash采集到的数据，经过过滤发送到mq中，直接用默认的logstash镜像并不能支持。查了下资料，发现有相关的插件，可以支持。在此记录一下。

准备阶段

logstash 部署在k8s集群中，之前我们已经通过helm完整的封装，在此我们只需要对于原始镜像去做修改，让它支持stomp output即可。

问题描述

今天发现有一台机器dns解析总是出现问题，经过排查发现ubuntu18.04更改了域名解析的规则，默认是走127.0.0.53 这个地址，由它再去到真正的dns地址。同时系统配置了一些保留域名，导致系统拒绝为一些域名提供解析。报错如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

root@ip-xx-xx-xx-xx:~# dig xxx.local

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> xxx.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49542
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
; xxx.local.	IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Apr 14 13:26:14 UTC 2020
;; MSG SIZE  rcvd: 56

公司在aws ec2 有一些陈年老业务，这些业务比较臃肿不太方便加入到新的k8s集群，我们也没有太多精力去迁移过去。但是时不时来个僵死触发报警也是很难受。毕竟谁都不想半夜爬起来搞这个…
在此契机下研究了下故障自愈的一些事情。 发现市面上这块呼声最大的其实是蓝鲸平台，但它比较大而全,并不适合小体量公司，而大体量公司还不如自己搞。由于我们所有的业务基本都在aws上所以更倾向于采用aws自己的一些方案。
经过调研发现 cloudwatch + EventBridge 可以比较好的处理当前我们的一些问题。

当前的告警机制

首先看一下当前我们的告警以及处理方式，当实例异常通过cloudwatch进行告警，收到电话☎️或者邮件后，人工开始处理。
由于是处理通常是机械性的重启，而且经常发生在半夜，所以我们希望加入自动化手段处理这些告警。

graph LR
    Ec2 --> Cloudwatch --> 电话,邮件,钉钉 --> 人工处理

问题分析

最近几天一直在排查k8s集群业务日志丢失的问题。现在业务集群上大概有十几个node跑了几百个pod。平时业务经常会更新。偶尔排查日志的时候发现个别的业务日志会采集不到，
但是重启pod之后又可以采集到了。 这给问题排查造成了很大困扰。由于偶尔出现，所以不好去定位和排查相关的问题。
简单说下目前集群日志采用的架构：基础就是elk，每个node节点通过demeonset方式部署filebeat,filebeat的output设置为logstash，经过logstash简单的处理发送到electicserch，最后通过kibana展示 。
判断的思路： 结合出现问题的现象是个别的pod采集不到数据而不是整体另外重启相关pod后又可以重新采集日志。所以可以初步判断是filebeat的问题。
查询了下filebeat相关资料 了解到一条日志是如何被采集的：

清明假期回来发现工作的mac电脑时间差了个几十秒，稍微影响了工作，在此记录下如何解决该问题：

确认mac当前版本为: 10.15.2

简单看了下mac当前管理时间的命令是sntp,所以打开终端直接输入命令:

1

sudo sntp -sS pool.ntp.org

一般情况下本人写blog会用公司的mac来搞,适逢清明放假所以把环境整理了下,用家里的windows来写。整个过程中还是有一些坑的,特此记录下。

1. nodejs 版本问题

由于很少在家coding,家中的nodejs版本过低。导致在安装hexo出现各种问题,网上搜了下资料发现现在的nodejs版本管理工具已经很成熟了，随便找了一个叫做gnvm 还挺好使。
安装很简单不需要复杂的操作,直接下载就能用。
GNVM 是一个简单的 Node.js 多版本管理器，类似 nvm nvmw nodist。很简单直接用了。

安装 & 验证

直接下载到nodejs所在目录即可，如果没安装nodejs，自己找一个目录放进去就好。由于我是之前就有所以就直接放进去了

1

curl -L https://github.com/Kenshin/gnvm-bin/blob/master/64-bit/gnvm.exe?raw=true -o gnvm.exe

下载其实也没有按照这个方式下载，原因是 ssl 证书问题，我是直接把链接拖到chrome里下载就完事了。在 cmd 下，输入 gnvm version，如有 版本说明 则配置成功。
接下来安装/升级 nodejs

最近要修改k8s集群上filebeat的配置文件，其中很重要的一项就是配置 close-inactive 的时间。 默认时间是5min，我们觉得时间有点长了，决定改为1min钟。我们部署filebeat是已经用helm封装好了，所以修改配置文件很简单，只需要改 values 即可。
原始的 values 文件内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

...
filebeatConfig:
  filebeat.yml: |-      
    filebeat.autodiscover:
      providers:
        - type: kubernetes      
          in_cluster: true    
          hints.enabled: true
          hints.default_config:          
            type: container
            paths:
              - /var/lib/docker/containers/${data.kubernetes.container.id}/*.log            
            processors:
              - add_kubernetes_metadata:   
            max_bytes: 102400                                   

    output.logstash:
      hosts: ['logstash-logstash.elk-system.svc.cluster.local:5044']
...