MacOS上设置”邮件”定时发送
在MacOS上想使用邮件定时发送的的功能可是太不容易了, 先后换过好几个客户端, Airmail的定时发送功能跟傻X一样, Outlook又卡成xiang, 找来找去找到了这个名为mailbulter的”邮件”插件(需要在MacOS原生邮件客户端设置里启用此插件).
查了下, mailbulter的免费套餐里有些功能只能使用30次/月(比如我需要的定时发送功能), 但是也够我用了, 先用着吧.
Read MoreElasticSearch索引/数据定期清理
关于定期清理ElasticSearch索引, 最简单粗暴的方法是写一个shell脚本, 实现定理删除INDEX. 但其实ElasticSearch官网也提供了一些工具来做这些事, 比如下面2个方法.
1, Crontab方式
$ crontab -l
00 05 * * * /usr/bin/curl -XDELETE localhost:9200/myindex-`date -d "-10days" +\%y\%m\%d`
30 05 * * * /usr/bin/curl -XDELETE localhost:9200/myindex-`date -d "-11days" +\%y\%m\%d`
00 06 * * * /usr/bin/curl -XDELETE localhost:9200/myindex-`date -d "-12days" +\%y\%m\%d`2, ILM: Manage the index lifecycle
应该是最简单有用的清理INDEX的办法了(官方文档在此, 一个简单的范例在此), 是X-Pack自带的功能, 不需要安装额外工具. ILM的主要功能有
- 当index容量达到一定数值(例如50G), 或者其中的日志数量达到一定数值以后, 开启一个新index
- 定期把旧index移动到旧的硬件节点上
- 指定什么情况下可以修改replicas数量, 或者修改一个index的主分片数量, 或者指定什么情况可以Force merge segments
- 定期删除旧index
3, Curator
也是ElasticSearch官方的工具, 需要额外安装(下载地址). 这个工具最早是clearESindices.py演化而来的, 最早的目的就是清理删除Index, 再后来, 随着作者被Elasticsearch公司聘用, 这个工具也被更名为Elasticsearch Curator. 它使用yaml作为基础配置语法, 官网提供了一堆Example配置可以参考.
$ cat /etc/elasticsearch/curator-cfg.yml
client:
hosts:
- 172.29.4.158
- 172.29.4.157
- 172.29.4.156
port: 9200
use_ssl: False
http_auth: "elastic:MyPassword"
timeout: 30
logging:
loglevel: INFO
logformat: default
logfile: /var/log/elasticsearch/curator.log$ cat /etc/elasticsearch/curator-del.yml
actions:
1:
action: delete_indices
description: >-
Delete old system indexes.
options:
ignore_empty_list: True
timeout_override:
continue_if_exception: False
disable_action: False
filters:
- filtertype: pattern
kind: prefix
value: .monitoring-kibana-7-
- filtertype: age
source: name
direction: older
timestring: '%Y.%m.%d'
unit: days
unit_count: 3
2:
action: delete_indices
description: >-
Delete old indexes.
options:
ignore_empty_list: True
timeout_override:
continue_if_exception: False
disable_action: False
filters:
- filtertype: pattern
kind: regex
value: '^(office_dns_log-|office_dns_log_failover-|mail-|mail_failover-).*$'
- filtertype: age
source: name
direction: older
timestring: '%Y.%m.%d'
unit: days
unit_count: 180dry-run运行试一下
/usr/bin/curator --config /etc/elasticsearch/curator-cfg.yml --dry-run /etc/elasticsearch/curator-del.yml然后可以观察下/var/log/elasticsearch/curator.log文件里的提示. 确认没问题后, 将–dry-run去掉并写入crontab即可.
参考文档:
Automatically removing index
转载: 使用tcpdump抓包
1, tcpdump常用选项介绍
-n 禁止IP名称解析
-nn 禁止IP和端口名称解析
-i 指定捕获哪个网卡的网络数据包。
-w 指定将包写入哪个文件，如果文件不存在则创建该文件；如果存在则覆盖其内容
-f 指定过滤表达式，例如指定捕获哪个端口，哪个协议等
-r 指定从哪个文件读取网络数据包文件
-F 指定使用哪个文件的过滤表达式抓包
-D 列出所有可以使用tcpdump抓包的网卡
-c 指定捕获或者读取包的个数，-c后面直接接数字即可
-l 抓包时保存到文件的同时查看包的内容
-t 不打印时间戳
-tt 秒级时间戳
-ttt 打印时间戳到微秒或者纳秒，取决于 –time-stamp-precision option 选项
-s 指定每个包捕获的字节数
-S 打印绝对的tcp序列号，而不是相对的序列号
-v/-vv/-vvv 打印详细信息，v的个数越多， 打印内容越详细
上面是常用的选项, 更多的选项请参考tcpdump官方文档, 下面将对使用过滤条件抓包进行基本的介绍
2, tcpdump常用命令
#协议为tcp, 目标端口或源端口为80的包, 并将其写入packets.pcap文件中 tcpdump -nni ens33 -w packets.pcap 'tcp port 80' #协议为tcp, 目标端口为80 tcpdump -nni ens33 -w packets.pcap 'tcp dst port 80' -c10 #协议类型为tcp, 源端口为80 tcpdump -nni ens33 -w packets.pcap 'tcp src port 80' -c10 #读取文件中协议类型为tcp, 目标端口为80的包 tcpdump -nnr packets.pcap 'tcp dst port 80' -c10 #将packets.pcap文件中目标端口为443的包转存到dst_port_443.pcap中 tcpdump -r packets.pcap 'dst port 443' -w dst_port_443.pcap #指定IP地址为14.215.177.39 tcpdump -nni ens33 host 14.215.177.39 -c5 #源IP地址为192.168.248.134 tcpdump -nni ens33 src 192.168.248.134 -c5 #目标IP地址为192.168.248.134 tcpdump -nni ens33 dst 192.168.248.134 -c5 #通往网络192.168.248.0/24 tcpdump -nni ens33 net 192.168.248.0/24 -c5
本文来源:
tcpdump使用过滤条件抓包(基础篇)
解决访问kibana monitoring 被提示Access Denied
在Kibana中使用”Stack Monitoring”时, 提示
Access Denied
You are not authorized to access Monitoring. To use Monitoring, you need the privileges granted by both the `kibana_user` and `monitoring_user` roles.
If you are attempting to access a dedicated monitoring cluster, this might be because you are logged in as a user that is not configured on the monitoring cluster.
解决办法: 停用Elasticsearch集群的remote.cluster功能, 将现有remote.cluster全部清除即可.
# 查看现有的 remote cluster
curl -XGET "127.0.0.1:9200/_cluster/settings?pretty"
{
"persistent" : {
"cluster" : {
"remote" : {
"aaa" : {
"skip_unavailable" : "true",
"seeds" : [
"172.29.4.168:9300"
]
},
"leader" : {
"seeds" : [
"172.29.4.168:9300"
]
},
"hello-elk" : {
"skip_unavailable" : "false",
"seeds" : [
"127.0.0.1:9300"
]
}
}
},
"xpack" : {
"monitoring" : {
"collection" : {
"enabled" : "true"
}
}
}
},
"transient" : { }
}
# 清除其中一个 remote cluster 节点
curl -X PUT "127.0.0.1:9200/_cluster/settings" -H 'Content-Type: application/json' -d'{
"persistent" : {
"cluster" : {
"remote" : {
"leader" : {
"seeds" : null
}
}
}
}
}'
提示: 如果一个remote cluster节点设置了”skip_unavailable” : “true”信息, 直接清除可能会提示Cannot configure setting [cluster.remote.hello-elk.skip_unavailable] if remote cluster is not enabled. 解决办法为, 先将skip_unavailable设置为null, 再将seeds设置为null
Read MoreMigrate data for Elasticsearch cluster
迁移ElasticSearch集群的数据, 最好用的是用到ElasticSearch的CCR(Cross-cluster replication, 跨集群复制)功能(官方文档在此). 但无奈今天配置了一天, 怎么也没有成功. 其实CCR存在的意义不仅仅是迁移数据, 更重要的是保证ElasticSearch集群的多副本/高可用状态. 比如, 如果你的主ES集群不能对外暴露, 那么可以设置一个readonly的对外暴露集群(数据通过CCR功能与主集群保持同步, 等. 而如果仅仅是迁移数据的话, 只用到ES的reindex功能即可完成.
将旧集群(172.29.4.168:9200)里的mail-w3svc1-2020.06.06索引数据迁移过来, 仅需要在新集群上执行如下命令即可.
curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
{
"source": {
"remote": {
"host": "http://172.29.4.168:9200",
"username": "elastic",
"password": "MyPassword"
},
"index": "mail-w3svc1-2020.06.06"
},
"dest": {
"index": "mail-2020.06.06"
}
}'
参考文档:
Reindex API
ElasticSearch中修改Field的Type
ElasticSearch中的Index一旦建立, 里面的Field类型就不可以再更改. 例如, 你不能把一个int类型的字段, 改为string类型. 否则该字段中的数据将失效. 那么如何解决这个问题呢? 答案就是重新建立索引(Reindex).
本文演示一下如何将以下旧的index中的数据以零停机的方式迁移到新的Index中.
旧Index: mail-w3svc1-2020.06.09
新Index: mail-w3svc1-2020.06.09-v2
1, 创建一个template, 指定新Index的mapping内容
curl -XPUT 127.0.0.1:9200/_template/mail-test -H 'Content-Type: application/json' -d'{
"index_patterns": ["mail-w3svc1-2020.06.09-v2"],
"settings" : {
"index.refresh_interval": "10s",
"number_of_shards": 1,
"number_of_replicas": 0,
"index.translog.durability": "request",
"index.translog.sync_interval": "30s"
},
"mappings": {
"properties": {
"rt": { "type": "integer" },
"status": { "type": "integer" },
"sub_status": { "type": "integer" }
}
},
"order" : 5
}'
2, 创建新Index
curl -XPUT 127.0.0.1:9200/mail-w3svc1-2020.06.09-v2 # 查看之 curl -XGET 127.0.0.1:9200/mail-w3svc1-2020.06.09-v2?pretty=true
3, 创建alias指向旧的Index(本例中的alias名为mail-w3svc1-2020.06.09-alt)
curl -XPOST localhost:9200/_aliases -H 'Content-Type: application/json' -d '{
"actions": [
{ "add": { "index": "mail-w3svc1-2020.06.09", "alias": "mail-w3svc1-2020.06.09-alt" } }
]
}'
Read More
Elasticsearch那点事
1, 如何知道我的INDEX的数据都存在哪些node?
需要注意的是, 一个INDEX由多个segment组成, 只要知道这些segment在哪个node, 就能知道这个INDEX存在哪些node上面.
curl -X GET "127.0.0.1:9200/_cat/segments/mail-w3svc1-2020.05.31?v" index shard prirep ip segment generation docs.count docs.deleted size size.memory committed searchable version compound mail-w3svc1-2020.05.31 0 p 172.29.4.171 _2q0 3528 369102 0 249.7mb 113048 true true 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _2r7 3571 319454 0 216.6mb 99914 true true 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _2zd 3865 320827 0 219.8mb 105560 true true 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _31k 3944 7768065 0 4.7gb 3059591 true true 8.4.0 false mail-w3svc1-2020.05.31 0 p 172.29.4.171 _35i 4086 119684 0 84.9mb 43316 true true 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _37q 4166 53366 0 38.2mb 0 true false 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _39q 4238 242418 0 170.2mb 78499 true true 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3cc 4332 109124 0 77.3mb 40302 true true 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3f3 4431 396442 0 272.7mb 132842 true true 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3fj 4447 26586 0 19.7mb 0 true false 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3g5 4469 40256 0 29mb 0 true false 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3gk 4484 48216 0 34.4mb 0 true false 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3hu 4530 39447 0 27.7mb 0 true false 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3i2 4538 116472 0 81.3mb 42064 true true 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3jc 4584 29177 0 21.1mb 0 true false 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3kt 4637 209783 0 146.1mb 71957 true true 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3m5 4685 44456 0 32.5mb 0 true false 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3ny 4750 51744 0 37mb 0 true false 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3of 4767 112861 0 79.2mb 40737 true true 8.4.0 true mail-w3svc1-2020.05.31 0 p 172.29.4.171 _3pc 4800 35665 0 25.8mb 0 true false 8.4.0 true
引申知识:
1, segment memory是常驻在内存(Jvm heap)里的, 且无法被GC的. 所以需要留意segment memory的大小
2, 也可以按node查看segment memory大小, 命令如下:
curl -X GET "127.0.0.1:9200/_cat/nodes?v&h=name,port,sm" name port sm it_elk_node169 9300 20.2mb it_elk_node171 9300 107.3mb it_elk_node168 9300 61.1mb it_elk_node170 9300 18.1mb it_elk_node167 9300 24.4mb
Read More