Fork me on GitHub
让一切随风

Martin's Blog


  • 首页

  • 分类

  • 标签

  • 归档

  • 留言

  • 关于

  • 搜索

bootstrap.memory_lock简要说明

发表于 2019-10-17

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

kubernetes之secret

发表于 2018-11-14 | 分类于 K8s

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证书的三种方式

发表于 2018-08-21 | 分类于 K8s

根据官方文档,生成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
阅读全文 »

只在移动端网页内显示”Fork me on Github”

发表于 2018-08-19 | 分类于 hexo
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>

Kubernetes RBAC Detailed

发表于 2018-06-27 | 分类于 K8s

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。
阅读全文 »

基于k8s 动态配置及扩容maven nexus私服

发表于 2018-06-22 | 分类于 K8s

配置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认证失败

阅读全文 »

kubernetes-jenkins-ci-cd

发表于 2018-06-14 | 分类于 K8s

流程图:

基于Jenkins的CI/CD流程如下所示:
kubernetes-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容器

发表于 2018-06-13 | 分类于 K8s

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容器的作用可以从这个例子中看出,首先见下图:
map

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容器探究

crontab、anacron、logrotate relationship

发表于 2018-05-24 | 分类于 Logrotate

服务器上的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
阅读全文 »

ELK Sentinl

发表于 2018-05-21 | 分类于 ELK

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"
}
},
123
Martin Lei

Martin Lei

Still Waters Run Deep

23 日志
6 分类
8 标签
RSS
GitHub E-Mail Twitter 微博
友情链接
  • 老缪
  • jimmysong
  • github
© 2019 Martin Lei  粤ICP备18019482号-1 本站总访问量 次, 访客数 人次, 本文总阅读量 次