一句话经验
有一些经验,非真切经历而不能真切体会,而当真切体会之后,就应当真切凝练汇总,这里汇总整理记录一些工作中的心得经验。
如果业务日志的 kafka 某个 topic 堆积了大量的数据,而业务方又确认可以将这段日志跳过的情况下,不能通过删除 topic 的方式处理,可以通过 kafka-manager 将参数
retention.ms
改小,改成 1 分钟,保存之后,十分钟左右,消息就会删完。完事儿之后再把参数还原。Jenkins 的主域名应该就解析在 master 服务器本身,因为在配置 slave 的时候,通信端口是
全局安全配置
中代理
处指定的端口。此时 slave 与 master 通信仍将通过系统配置
中Jenkins Location
中的Jenkins URL
加端口进行,如果域名解析到了其他地方,slave 节点将总是无法正常注册。如果实在无法在 master 上解析,也应该放一份 Nginx 配置文件,slave 通过绑定 hosts 到 master 的方式强行引导打通。在 k8s 中部署服务,如果服务域名通过 ingress 配置的,那么此时 svc 的模式可以设置成 ClusterIP,因为流量已经走了 ingress 的映射,不再需要通过 NodePort 进行代理转发。
es 中主索引的分片无法加大或者缩小,如果该索引是固定的单索引的话,通常索引分片是走 mapping 来定义分片,这个时候应该建立 mapping,新建索引,然后 reindex 的方式处理。
logstash 在 6.x 版本中使用 mutate 关键字 add_field 时,使用方式如下:
mutate { split => ["request_uri" , "?"] add_field => { "uri_path" => "%{request_uri[0]}" "uri_query" => "%{request_uri[1]}" } }
1
2
3
4
5
6
7这样是正常的,但是同样的配置在 7.x 版本中,会报如下错误:
[2021-05-06T20:33:53,365][WARN ][logstash.filters.mutate ][main][cc8d92e453b7aeb97baaede527c74dc6b680b6c68938aa1df68cf82be5edb576] Exception caught while applying mutate filter {:exception=>"Invalid FieldReference: `request_uri[0]`"}
1此时应该使用如下方式进行,即可正常添加:
add_field => {"uri_path" => "%{[request_uri][0]}"}
1参考:https://discuss.elastic.co/t/logstash-7-2-0-mutate-error/193086
使用 wget 下载文件时,尽量不要用-o 参数指定文件下载目录,可以通过-P 来指定文件存放目录,实测通过-o 之后可能会改变文件 md5,导致不可预知的问题出现。
千万不要部署破解版的东西用在公司生产,不但会给公司造成侵权问题,还会给自己后续的维护工作带来无穷尽的烦恼。如果这个产品没有较好的开源替代品,就应该在一开始反馈出来,让公司考虑付费使用,或者选择开源产品使用。
如果你用 nginx+upsync+consul 管理后端服务,并且通过配置管理平台管理着 Nginx 的配置文件,那么,每个 server 对应的 upstream 中的 dump 文件以及 include 文件,在初始同步之后就不应该再进行同步或者更新,当初始配置内容被 Nginx 加载之后,即与 consul 对接通过平台管理。之所以不应再更新的原因在于,Nginx 先读取本地配置加载成功并启动,然后才会连接 consul 对接数据。一旦初始数据中的后端服务有变更或者下线,那么下次更新就会出现简短的不可用。
为避免此问题,同步配置时,可借助 rsync 的
--ignore-existing
参数实现。后端接口需要拼接数据的场景中,应该优先安排查询,然后再在内存中对数据进行聚合处理。换言之就是不要把与 DB 的交互放到 for 里边,否则很容易造成请求放大。
后端在任何时候都不应该相信前端传过来的数据,而应该有自己的判断,否则就会有很多脏数据生成。
后端不同表之间做关联的时候,一定要以唯一的,不变的 ID 或者 identify 来进行关联,而不能将动态的值放到关联列表中,否则被关联数据一旦更改,数据就不准确了。
如何快速在谷歌浏览器截全页:进入检查页面,输入 cmd+shift+p 进入命令界面,输入 full 回车就会自动生成了。