https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration-memory.html#mlockall

bootstrap.memory_lock

由于当jvm开始swapping时es的效率会降低，所以要保证它不swap，这对节点健康极其重要。实现这一目标的一种方法是将 bootstrap.memory_lock 设置为true。
要使此设置有效，首先需要配置其他系统设置。有关如何正确设置内存锁定的更多详细信息，请参阅启用bootstrap.memory_lock。

bootstrap.memory_lock: 是否锁住内存，避免交换(swapped)带来的性能损失,默认值是: false
bootstrap.system_call_filter: 是否支持过滤掉系统调用。elasticsearch 5.2以后引入的功能，在bootstrap的时候check是否支持seccomp。

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

检查bootstrap.memory_lock设置是否生效:
get http://10.127.0.1:9200/_nodes?filter_path=**.mlockall
响应：
{
    "nodes": {
        "9giihmDNRdS136KT52Gl5g": {
            "process": {
                "mlockall": true
            }
        },
        "X0zQESeeT8uJ9kVXvHpl-w": {
            "process": {
                "mlockall": true
            }
        },
        "w4hYw86rQhqL1ayGyUK1Kw": {
            "process": {
                "mlockall": true
            }
        }
    }
}

如果看到mlockall为false，则表示mlockall请求失败。还将在日志中看到一行”Unable to lock JVM Memory”。

elasticsearch报错之 memory locking requested for elasticsearch process but memory is not locked:

安装elasticsearch报错如下：

1
2
3

[2019-01-14T03:57:16,453][ERROR][o.e.b.Bootstrap          ] [ip-172-31-30-62.ec2.internal] node validation exception
[1] bootstrap checks failed
[1]: memory locking requested for elasticsearch process but memory is not locked

网上查找资料，发现都不是适应自己的环境。最后在官网找到了方法：

不过先跟大家声明一点就是：环境不一样解决的方法也不一样，这里是Centos7.5版本的系统，所有的服务都由systemd来管理。elasticsearch是6.5.4版本，使用RPM包的方式安装的。

现在我们开始解决问题：

1、修改/etc/sysconfig/elasticsearch文件调整JVM内存大小

1
2
3
4
5

#ES_JAVA_OPTS="-Xms16g -Xmx16g" (内存大小也可以在/etc/elasticsearch/jvm.options配置文件中定义，或者ES_HEAP_SIZE=16g)
JAVA_HOME=/usr/java/jdk1.8.0_51
ES_HEAP_SIZE=16g
MAX_OPEN_FILES=655350
MAX_LOCKED_MEMORY=unlimited

替换16g为总内存的一半（Elasticsearch官方建议是主机总内存的一半）

2、修改/etc/security/limits.conf文件内容

1
2

elasticsearch soft memlock unlimited
elasticsearch hard memlock unlimited

需要将elasticsearch替换为运行Elasticsearch程序的用户,使用root执行：service elasticsearch start实际上是以elasticsearch用户来执行

3、在/etc/systemd/system/elasticsearch.service.d目录下创建一个文件override.conf，并添加下列内容

1
2
3

[Service]
LimitMEMLOCK=infinity
详情可以参考：https://www.elastic.co/guide/en/elasticsearch/reference/current/setting-system-settings.html#systemd

4、最后重新载入配置文件更新服务

systemctl daemon-reload

5、重启elasticsearch

service elasticsearch restart

Secret解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用。

Secret类型：

1. Opaque：base64编码格式的Secret，用来存储密码、密钥等；但数据也通过base64 –decode解码得到原始数据，所有加密性很弱。
2. kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。
3. kubernetes.io/service-account-token： 用于被serviceaccount引用。serviceaccout创建时Kubernetes会默认创建对应的secret。Pod如果使用了serviceaccount，对应的secret会自动挂载到Pod目录/run/secrets/kubernetes.io/serviceaccount中。

1.Opaque Secret

Opaque类型的数据是一个map类型，要求value是base64编码格式： 比如来创建一个用户名为：admin，密码为： 1f2d1e2e67df的Secret 对象，首先把这用户名和密码做base64编码，

1
2
3
4

$ echo -n "admin" | base64
YWRtaW4=
$ echo -n "1f2d1e2e67df" | base64
MWYyZDFlMmU2N2Rm

然后就可以利用上面编码过后的数据来编写一个YAML文件：(secrets.yml)

1
2
3
4
5
6
7
8

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: MWYyZDFlMmU2N2Rm
  username: YWRtaW4=

同样的就可以使用kubectl命令来创建了： 创建secret：kubectl create -f secrets.yml。

1
2
3
4

# kubectl get secret
NAME                  TYPE                                  DATA      AGE
default-token-xxx   kubernetes.io/service-account-token   3         45d
mysecret              Opaque                                2         7s

注意：其中default-token-xxx为创建集群时默认创建的secret，被serviceacount/default引用。 可以使用describe命令查看详情，如果想看到Data里面的详细信息，可以输出成YAML文件进行查看

如果是从文件创建secret，则可以用更简单的kubectl命令，比如创建tls的secret：

1
2
3

$ kubectl create secret generic helloworld-tls \
  --from-file=key.pem \
  --from-file=cert.pem

2.Opaque Secret的使用

创建好secret之后，有两种方式来使用它：

• 以Volume方式
• 以环境变量方式
• 以Volume方式挂载制定的key

将Secret挂载到Volume中

用一个Pod来验证下Volume挂载，创建一个Pod文件：(secret2-pod.yaml)

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

apiVersion: v1
kind: Pod
metadata:
  labels:
    name: db
  name: db
spec:
  volumes:
  - name: secrets
    secret:
      secretName: mysecret
  containers:
  - image: registry.martin.com:5000/my_project_id/pg:v1
    name: db
    volumeMounts:
    - name: secrets
      mountPath: "/etc/secrets"
      readOnly: true
    ports:
    - name: cp
      containerPort: 5432
      hostPort: 5432

查看Pod中对应的信息：

1
2
3
4
5
6

# ls /etc/secrets
password  username
# cat  /etc/secrets/username
admin
# cat  /etc/secrets/password
1f2d1e2e67df

查看输出日志：

1
2
3

$ kubectl logs secret2-pod
password
username

可以看到secret把两个key挂载成了两个对应的文件。

根据官方文档，生成k8s秘钥证书及相关管理证书有三种方式，其本质都是通过openssl:

• cfssl
• easyrsa
• openssl

官方文档：https://kubernetes.io/docs/concepts/cluster-administration/certificates/

cfssl方式

1.cfssl下载地址:

1
2
3
4
5

VERSION=R1.2
for i in {cfssl,cfssljson,cfssl-certinfo}
do
wget https://pkg.cfssl.org/${VERSION}/${i}_linux-amd64 -O /usr/local/bin/${i}
done

2.生成CA配置文件

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

mkdir ssl && cd ssl
cfssl print-defaults config > config.json
cfssl print-defaults csr > csr.json
cat > ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "kubernetes": {
        "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ],
        "expiry": "87600h"
      }
    }
  }
}
EOF

3.生成CA签名配置文件

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

cat > ca-csr.json << EOF
{
  "CN": "kubernetes",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names":[{
    "C": "CN",
    "ST": "Beijing",
    "L": "BeiJing",
    "O": "k8s",
    "OU": "System"
  }]
}
EOF

1.修改文件hexo博客根目录\themes\next\layout_layout.swig 找到如下代码块

1
2
3
4

<html class="{{ html_class | lower }}" lang="{{ config.language }}">
<head>
  {% include '_partials/head.swig' %}
  <title>{% block title %}{% endblock %}</title>

2.添加代码，结果如下：

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

<html class="{{ html_class | lower }}" lang="{{ config.language }}">
<head>
  {% include '_partials/head.swig' %}
  <title>{% block title %}{% endblock %}</title>
  {% include '_third-party/analytics/index.swig' %}
  
  <style>
  .forkMeOnGithub{
  display: none;
  }
  @media (min-width: 768px) {
  .forkMeOnGithub{
   display: inline;
   }
  }
  </style>
</head>

3.最后在之前引用代码块上套上div加上class就行了，代码如下

1
2
3

<div class="forkMeOnGithub">
<a href="https://github.com/hannius"><img style="position........</a>
</div>

RBAC - 基于角色的访问控制
RBAC使用：rbac.authorization.k8s.io API Group 来实现授权决策，允许管理员通过 Kubernetes API 动态配置策略，要启用RBAC，需要在 apiserver 中添加参数–authorization-mode=RBAC，如果使用的kubeadm安装的集群，1.6 版本以上的都默认开启了RBAC，可以通过查看 Master 节点上 apiserver 的静态Pod定义文件：

1
2
3
4
5
6

$ cat /usr/lib/systemd/system/kube-apiserver.service
或者是：
$ cat /etc/kubernetes/manifests/kube-apiserver.yaml
...
    - --authorization-mode=Node,RBAC
...

如果是二进制的方式搭建的集群，添加这个参数过后，记得要重启 apiserver 服务。

RBAC API 对象

Kubernetes有一个很基本的特性就是它的所有资源对象都是模型化的 API 对象，允许执行 CRUD(Create、Read、Update、Delete)操作(也就是我们常说的增、删、改、查操作)，比如下面的这下资源：

• Pods
• ConfigMaps
• Deployments
• Nodes
• Secrets
• Namespaces

上面这些资源对象的可能存在的操作有：

• create
• get
• delete
• list
• update
• edit
• watch
• exec

在更上层，这些资源和API Group 进行关联，比如Pods属于Core API Group，而Deployements属于 apps API Group，要在Kubernetes中进行RBAC的管理，除了上面的这些资源和操作以外，我们还需要另外的一些对象：

1. Rule：规则，规则是一组属于不同API Group 资源上的一组操作的集合
2. Role 和 ClusterRole：角色和集群角色，这两个对象都包含上面的Rules 元素，二者的区别在于，在Role 中，定义的规则只适用于单个命名空间，也就是和namespace 关联的，而ClusterRole 是集群范围内的，因此定义的规则不受命名空间的约束。另外Role和 ClusterRole在Kubernetes中都被定义为集群内部的API 资源，和Pod、ConfigMap 这些类似，都是集群的资源对象，所以同样的可以使用kubectl相关的命令来进行操作
3. Subject：主题，对应在集群中尝试操作的对象，集群中定义了3种类型的主题资源：
   • User Account：用户，这是有外部独立服务进行管理的，管理员进行私钥的分配，用户可以使用KeyStone或者Goolge 帐号，甚至一个用户名和密码的文件列表也可以。对于用户的管理集群内部没有一个关联的资源对象，所以用户不能通过集群内部的API 来进行管理
   • Group：组，这是用来关联多个账户的，集群中有一些默认创建的组，比如cluster-admin
   • Service Account：服务帐号，通过Kubernetes API 来管理的一些用户帐号，和namespace 进行关联的，适用于集群内部运行的应用程序，需要通过API 来完成权限认证，所以在集群内部进行权限操作，都需要使用到 ServiceAccount
4. RoleBinding和 ClusterRoleBinding：角色绑定和集群角色绑定，简单来说就是把声明的Subject和Role 进行绑定的过程(给某个用户绑定上操作的权限)，二者的区别也是作用范围的区别：RoleBinding只会影响到当前namespace 下面的资源操作权限，而ClusterRoleBinding会影响到所有的 namespace。

配置nexus

从官网下载了nexus之后还需要进行一些配置。
编辑bin/nexus.vmoptions 调整后的如下：

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

-Xms600M
-Xmx600M
-XX:MaxDirectMemorySize=1G
-XX:+UnlockDiagnosticVMOptions
-XX:+UnsyncloadClass
-XX:+LogVMOutput
-XX:LogFile=/data/docker/soft/nexus/log/jvm.log
-XX:-OmitStackTraceInFastThrow
-Djava.net.preferIPv4Stack=true
-Dkaraf.home=.
-Dkaraf.base=.
-Dkaraf.etc=etc/karaf
-Djava.util.logging.config.file=etc/karaf/java.util.logging.properties
-Dkaraf.data=/data/docker/soft/nexus/data
-Djava.io.tmpdir=/data/docker/soft/nexus/tmp
-Dkaraf.startLocalConsole=false

其中除了1，2行的jvm内存配置之外，最关键的就是，以下几个属性配置：

• -XX:LogFile=/data/docker/soft/nexus/log/jvm.log # 日志文件生成位置
• -Dkaraf.data=/data/docker/soft/nexus/data # 仓库数据存放位置(上传的jar包)
• -Djava.io.tmpdir=/data/docker/soft/nexus/tmp # 临时文件存放位置

制作Docker镜像

配置好nexus之后，需要再制作自己的docker镜像，因为k8s就是调度镜像容器的。

1
2
3
4
5
6
7
8
9

[root@master nexus]# pwd
/data/docker/dockerfile/nexus
[root@master nexus]# ls -lth 
total 223M
-rw-r--r-- 1 root root  146 Jun 21 16:06 Dockerfile
-rw-r--r-- 1 root root 108M Jun 21 16:02 nexus3.tar.gz
drwxr-xr-x 3 root root 4.0K Jun 21 15:53 sonatype-work
drwxr-xr-x 9 root root 4.0K Jun 21 15:53 nexus-3.12.1-01
-rw-r--r-- 1 root root 115M Jun 21 15:36 nexus-3.12.1-01-unix.tar.gz.org

docker镜像的制作很简单，新建一个Dockerfile文件：

1
2
3
4
5
6

[root@master nexus]# cat Dockerfile 
FROM registry.cn-hangzhou.aliyuncs.com/luhaoyuan/oracle-jdk8:latest

ADD nexus3.tar.gz /opt

ENTRYPOINT ["/opt/nexus-3.12.1-01/bin/nexus", "run"]

• 第一行：nexus的运行是依赖JDK环境的，所以我们这里就使用jdk作为基础镜像；(镜像是基于centos7，比较大，后续可以考虑修改为alpine_3.6)
• 第二行：将我们配置过后的nexus(nexus-3.12.1-01)再重新打包一下，添加到容器中；
• 第三行：启动容器时，执行的命令，nexus的启动命令有start和run，由于start默认是启动在后台进程的，这样容器一启动就退出了。所以这里必须要使用run命令启动了。

最后构建Docker镜像：
docker build -t registry.martin.com:5000/tools/nexus:3.12.1 .
registry.martin.com:5000为我registry地址,构建之后将改image push到私库,当然也可以用harbor
如果有做ca校验，需要将证书拷贝到指定的:/etc/docker/certs.d/xxx/ca.crt,然后docker login校验
再docker push registry.martin.com:5000/tools/nexus:3.12.1，不然会提示x509认证失败

流程图：

基于Jenkins的CI/CD流程如下所示:

流程说明：

1. 用户向Gitlab提交代码，代码中必须包含Dockerfile
2. 将代码提交到远程仓库
3. 用户在发布应用时需要填写git仓库地址和分支、服务类型、服务名称、资源数量、实例个数，确定后触发Jenkins自动构建
4. Jenkins的CI流水线自动编译代码并打包成docker镜像推送到Harbor镜像仓库
5. Jenkins的CI流水线中包括了自定义脚本，根据我们已准备好的kubernetes的YAML模板，将其中的变量替换成用户输入的选项
6. 生成应用的kubernetes YAML配置文件
7. 更新Ingress的配置，根据新部署的应用的名称，在ingress的配置文件中增加一条路由信息
8. 更新PowerDNS，向其中插入一条DNS记录，IP地址是边缘节点的IP地址。关于边缘节点，请查看边缘节点配置
9. Jenkins调用kubernetes的API，部署应用

Pause容器定义

Pause容器，又叫Infra容器，本文将探究该容器的作用与原理。

在kubelet的配置中有这样一个参数：

1

KUBELET_POD_INFRA_CONTAINER=--pod-infra-container-image=registry.access.redhat.com/rhel7/pod-infrastructure:latest

上面是openshift中的配置参数，kubernetes中默认的配置参数是：

1

KUBELET_POD_INFRA_CONTAINER=--pod-infra-container-image=gcr.io/google_containers/pause-amd64:3.0

Pause容器，是可以自己来定义，官方使用的gcr.io/google_containers/pause-amd64:3.0容器的代码见Github，使用C语言编写。

Pause容器的作用

检查nod节点的时候会发现每个node上都运行了很多的pause容器，例如如下:

1
2
3
4
5
6
7
8

[root@elk-02 bin]# docker ps
CONTAINER ID        IMAGE                                               COMMAND                  CREATED             STATUS              PORTS               NAMES
576c56bd6065        mirrorgooglecontainers/kubernetes-dashboard-amd64   "/dashboard --inse..."   2 hours ago         Up 2 hours                              k8s_kubernetes-dashboard_kubernetes-dashboard-66c9d98865-jdbg8_kube-system_d2406f4f-6de3-11e8-8760-5254004f2222_0
c4985381c2b7        d4b7466213fe                                        "/coredns -conf /e..."   2 hours ago         Up 2 hours                              k8s_coredns_coredns-77c989547b-xq4dr_kube-system_d23ef2c4-6de3-11e8-8760-5254004f2222_1
ba2fef1cbf00        mirrorgooglecontainers/pause-amd64:3.0              "/pause"                 2 hours ago         Up 2 hours                              k8s_POD_coredns-77c989547b-xq4dr_kube-system_d23ef2c4-6de3-11e8-8760-5254004f2222_1
ea6c2994b397        d4b7466213fe                                        "/coredns -conf /e..."   2 hours ago         Up 2 hours                              k8s_coredns_coredns-77c989547b-lcbfw_kube-system_0696926b-6d79-11e8-8760-5254004f2222_1
f61476c51230        mirrorgooglecontainers/pause-amd64:3.0              "/pause"                 2 hours ago         Up 2 hours                              k8s_POD_kubernetes-dashboard-66c9d98865-jdbg8_kube-system_d2406f4f-6de3-11e8-8760-5254004f2222_0
b6f61200d5ea        mirrorgooglecontainers/pause-amd64:3.0              "/pause"                 2 hours ago         Up 2 hours                              k8s_POD_coredns-77c989547b-lcbfw_kube-system_0696926b-6d79-11e8-8760-5254004f2222_1

kubernetes中的pause容器主要为每个业务容器提供以下功能：

• 在pod中担任Linux命名空间共享的基础；
• 启用pid命名空间，开启init进程。

pause容器的作用可以从这个例子中看出，首先见下图：

Pause容器测试

首先在节点上运行一个pause容器。

1

docker run -d --name pause -p 8880:80 martin/pause-amd64:3.0

然后再运行一个nginx容器，nginx将为localhost:2398创建一个代理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$ cat <<EOF >> nginx.conff
error_log stderr;
events { worker_connections  1024; }
http {
    access_log /dev/stdout combined;
    server {
        listen 80 default_server;
        server_name example.com www.example.com;
        location / {
            proxy_pass http://127.0.0.1:2398;
        }
    }
}
EOF
$ docker run -d --name nginx -v `pwd`/nginx.conf:/etc/nginx/nginx.conf --net=container:pause --ipc=container:pause --pid=container:pause nginx

然后再为ghost创建一个应用容器，这是一款博客软件。

1

$ docker run -d --name ghost --net=container:pause --ipc=container:pause --pid=container:pause ghost

现在访问http://localhost:8880/就可以看到ghost博客的界面了。

Pause容器解析

pause容器将内部的80端口映射到宿主机的8880端口，pause容器在宿主机上设置好了网络namespace后，nginx容器加入到该网络namespace中，我们看到nginx容器启动的时候指定了–net=container:pause，ghost容器同样加入到了该网络namespace中，这样三个容器就共享了网络，互相之间就可以使用localhost直接通信，–ipc=contianer:pause –pid=container:pause就是三个容器处于同一个namespace中，init进程为pause，这时我们进入到ghost容器中查看进程情况。

1
2
3
4
5
6
7
8

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   1024     4 ?        Ss   13:49   0:00 /pause
root         5  0.0  0.1  32432  5736 ?        Ss   13:51   0:00 nginx: master p
systemd+     9  0.0  0.0  32980  3304 ?        S    13:51   0:00 nginx: worker p
node        10  0.3  2.0 1254200 83788 ?       Ssl  13:53   0:03 node current/in
root        79  0.1  0.0   4336   812 pts/0    Ss   14:09   0:00 sh
root        87  0.0  0.0  17500  2080 pts/0    R+   14:10   0:00 ps aux

在ghost容器中同时可以看到pause和nginx容器的进程，并且pause容器的PID是1。而在kubernetes中容器的PID=1的进程即为容器本身的业务进程。

参考

Kubernetes只Pause容器

kubernetes中的infra容器——Pause容器探究

服务器上的nginx使用logrotate来分割日志，设置为每天分割。但是logrotate似乎没有工作，日志并没有分割。服务器是CentOS 6。

为了找到原因，分析可能出错的地方。
如果是logrotate未执行，可能是crond没有启动，因为logrotate被/etc/cron.daily/logrotate脚本所启动，可以查看其中代码：

1
2
3
4
5
6
7
8
9

[root@test ~]# cat /etc/cron.daily/logrotate
#!/bin/sh

/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0

可以看到logrotate运行时加载配置文件logrotate.conf，而这个配置文件除了设定一些分割日志相关的选项，还包含分割日志的配置文件目录/etc/logrotate.d。

nginx的日志分割配置文件就保存在logrotate.d目录：

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

[root@test ~]# cat !$
cat /etc/logrotate.d/nginx
/root/*.log {
    Daily
    Missingok
    rotate 52
    compress
    delaycompress
    notifempty
    dateext
    create 644 nobody nobody
    sharedscripts
    postrotate
    [ -f /usr/local/nginx/logs/nginx.pid ] && kill -USR1 `cat /usr/local/nginx/logs/nginx.pid`
    endscript
}

/root/*.log就是需要被分割的日志的目录，通配符*表示目录内的所有log文件都被分割，分割的规则就是{…}中的内容。这里把/root/*.log当做nginx日志只是为了测试。
在启动crond服务后，发现日志还是没有分割，于是想到会不会是/etc/logrotate.d/nginx配置文件的语法有问题，使用以下命令调试这个文件：

1

logrotate -vfd /etc/logrotate.d/nginx  # -vfd 三个选项分别表示显示详情，强制分割日志，只是调试配置文件而不是真的分割日志

输出结果表明有语法错误，Daily，Missingok 都应该是小写。改成daily，missingok。再次调试配置文件，可以正确分割日志：

1
2
3

[root@test ~]# ls -1 /root/
install-2017-5-14.log
install-2017-5-14.log-20170521  #logrotate归档的日志

上面猜测是crond执行/etc/cron.daily/内的脚本，实现定时执行计划任务，包括执行logrotate日志分割。
为了验证是否正确，网上搜索一番后找到了答案。如果没有crontab命令，先安装：

1
2
3
4

yum install crontabs  #安装crond，crond实际上来自cronie包，这个包作为crontabs包的依赖被安装
chkconfig --add crond #添加到开机启动列表
chkconfig crond on    #开机启动crond服务
/etc/init.d/crond     #立即启动crond

Sentinl简介

Sentinl 5扩展自Kibi / Kibana 5，具有警报和报告功能，可使用标准查询，可编程验证器和各种可配置操作来监控，通知和报告数据系列更改 - 将其视为一个独立的“观察者” “报告”功能（PNG / PDFs快照）。

SENTINEL还旨在通过直接在Kibana UI中整合来简化在Kibi / Kibana中创建和管理警报和报告的过程。

功能模块

Watchers
Alarms
Reports
Watchers是Sentinl核心，主要由 input,Condition,Transform,Actions几大块组成，可以和X-Pack一一对应，部分文档可参考X-Pack，但需要注意的是它和X-Pack还有一些区别，主要体现在input只实现了search，其他并未实现，Actions也并未都实现

安装与配置

• 安装

/usr/share/kibana/bin/kibana-plugin install https://github.com/sirensolutions/sentinl/releases/download/tag-5.5/sentinl-v5.6.5.zip

• config

kibana.yml config:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

sentinl:
  es:
    timefield: '@timestamp'
    default_index: watcher
    type: watch
    alarm_index: watcher_alarms
  sentinl:
    history: 20
    results: 50
  settings:
    email:
      active: false
      user: username
      password: password
      host: smtp.server.com
      ssl: true
      timeout: 10000  # mail server connection timeout
    slack:
      active: false
      username: username
      hook: 'https://hooks.slack.com/services/<token>'
      channel: '#channel'
    report:
      active: false
      tmp_path: /tmp/
    pushapps:
      active: false
      api_key: '<pushapps API Key>'

• raw

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

"input": {
      "search": {
        "request": {
          "index": [
            "<xxx-{now/d}>"
          ],
          "body": {
            "query": {
              "bool": {
                "should": [
                  {
                    "match": {
                      "status": "502"
                    }
                  },
                  {
                    "match": {
                      "status": "404"
                    }
                  }
                ],
                "minimum_should_match": 1,  #must setup
                "filter": {
                  "range": {
                    "@timestamp": {
                      "gte": "now-60s",
                      "lte": "now"
                    }
                  }
                }
              }
            }
          }
        }
      }
    },
    "condition": {
      "script": {
        "script": "payload.hits.total > 30"
      }
    },