Wireshark可用的BOLT协议解析插件

https://github.com/leizhiyuan/bolt-dissector 自己平常看协议,经常看到眼花,所以写了一个解析 SOFARPC 中 BOLT 协议的 wiresharks 插件 Wireshark是排查网络问题最常用的工具,它已经内置支持了上百种通用协议,扩展性也好,对于私有协议,还是得自己写的.对 C 不熟,但是 Lua 看了一下语法,还是挺简单的. 插件是使用lua开发的,安装比较简单,以OS X平台为例: 将协议解析脚本拷贝到/Applications/Wireshark.app/Contents/Resources/share/wireshark/ 目录 (非必须) 编辑init.lua文件,设置disable_lua = false,确保lua支持打开,默认是打开的.一般就不要操作了. 在init.lua文件末尾增加,当然你也可以写全路径. dofile("bolt.lua") 再次启动Wireshark,会对12200端口的数据流使用脚本解析,已经可以识别BOLT协议了。 参考文档 https://wiki.wireshark.org/LuaAPI 附上 lua脚本 目前只支持 boltv1,稍后看看改一下支持 boltv2和 tr,方便大家理解 和抓包. --- --- Created by bystander. --- DateTime: 2018/11/16 8:57 AM --- -- declare the protocol bolt_proto = Proto("bolt", "SOFA BOLT Protocol") -- declare the value strings local vs_proto = { [1] = "BOLT", [13] = "TR", } local vs_type = { [1] = "Request", [2] = "Request Oneway", [0] = "Response", } local vs_cmdcode = { [0] = "HeartBeat", [1] = "Request", [2] = "Response", } local vs_version2 = { [1] = "v1", [2] = "v2", } local vs_codec = { [1] = "HESSIAN_CODEC", [2] = "JAVA_CODEC", [11] = "PROTOBUF_CODEC", } local vs_responsestatus = { [00] = "Success", [01] = "Error", [02] = "Server Exception", [03] = "Unknown Exception", [04] = "Server Thread Pool Busy", [05] = "Error Communication", [06] = "No Processor", [07] = "Timeout Exception", [08] = "Client Send Error", [09] = "Codec Exception", [10] = "Connection Closed", [11] = "Server Serialize Exception", [12] = "Server DeSerialize Exception", } -- declare the fields local f_proto = ProtoField. [Read More]

27 Years Old Man

又是一年,工作进入了第5年了。身体各方面略有一些下降,生活上,也未能彻底稳定下来。

由于各方面的原因,博客基本荒废,最近抽空搞成了go 版本的 hugo 生成静态网站的形式。速度快很多,也没有hexo那么折腾,写作的欲望有一些上升。下一年稍微还是写几篇。

2019年,希望几个事情能有一些推进,其他事情一切顺利,顺便祝自己生日快乐。

skywalking插件开发的注意事项

最近蚂蚁金服中间件开源了 sofa 相关的部分组件,比如 rpc,欢迎大家参与讨论贡献,为 rpc 做链路适配的时候,skywalking 现在快到5.0版本了. 已经不支持 h2暂时,开发过程中了,环境的搭建.以下部分字段不能少.否则外面无法连接 es.

docker run -d -p 9200:9200 -p 9300:9300 -e "network.host=0.0.0.0" -e "transport.host=0.0.0.0"  -e "network.publish_host=0.0.0.0"  -e "xpack.security.enabled=false" -e "network.bind_host=0.0.0.0" -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:5.5.0

这条命令会搞定.

同时 application.yml 文件中

storage:
  elasticsearch:
    cluster_name: docker-cluster
    cluster_transport_sniffer: false
    cluster_nodes: localhost:9300
    index_shards_number: 2
    index_replicas_number: 0
    ttl: 70

这一段改一下.

其他的一些网上已有的文档,可以看看.SkyWalking 源码分析 —— 调试环境搭建

开发 

最近的一些变动

现在是凌晨1点了,还在公司,想随便写点什么,也算是一点记录吧.

工作三年,经历了不少的事情,有一天,突然明白.那些曾经对我重要的,可能并不是我真正想要的,想要成为的,所以基于对自己未来的规划.和自己更想做的,大概在两个月前开始准备转岗.前前后后,很多人跟我聊,希望我留在原岗位,会有更好的”发展”.最终还是走到了工作交接这一步.

这个博客原来的名字叫做 “寻找妹子和窄门”, 后来,大概一段时间后,和文哥认识,现在三年多过去了.一切安好.余生请君指教,还是我的签名,也是我的承诺,于是这个博客的名字改成了寻找窄门,也有很多人问我,寻找窄门到底是什么意思.这个窄门其实来自圣经中的一段话:“你们要从窄门进去;因为那通向灭亡的门是大的,那条路是宽的,从那里进去的人也多”,我当时想表达的意思是,我们有很多的选择和不同的路,那些在大多数看来,这个选择更好,可能并不是未来几年看来更好的选择,所以我希望,能够在这种得失选择中,不要受到公司对自己的 job model, 或者title: 的影响.遵从内心的感受,更多的关注自身的兴趣和梦想,让自身的能力发挥最大化的体现.

下个月末会进入蚂蚁中间件做基础技术的研发.也算是个人职业生涯中比较重要的一个改变,在这三年中,我偶尔会想,我在目前的团队继续呆着,明年成为了测试技术专家,又能怎么样呢,这是我想要的吗,我想成为自己心中认为的技术专家,我想得到的不是一个 title, 而是真正的能力上的提升,更多的技术上的认可.更跟随自己内心的感受.

从测试开发工程师到中间件研发工程师,新的部门,会有新的挑战,希望下一个三年,能在中间件有更大的突破.

生活 

分析代码调用关系的利器-Flow

今天推荐一个不错的软件.是idea 的插件.名字是Flow, 官方称:A better way to understand your Java applications,原理就是通过 java-agent 修改字节码,配置了拦截器,然后真实地跑一个测试用例,或者启动一下项目,就会生成一个真实的调用关系.官方地址:http://findtheflow.io/

之前阅读源代码,对于抽象类,或者接口,静态阅读代码不太容易确定具体的调用类,因此阅读有一定的阻碍,当然 debug 也行..但是这个可以通过跑用例,或者简单的测试用例,理清调用关系,非常不错. 可以对代码结构有一个整体关系

安装

安装比较简单:https://plugins.jetbrains.com/plugin/8362?pr=idea 直接安装idea 这个插件,然后重新启动 idea, 安装完成后的效果.

安装结果

使用

使用更简单,直接点击上图中的按钮,开始跑一下,即可,如果启动成功.控制台会有显示.

开始启动

然后,会在本地开启7575的端口,来显示结果.

效果

结果

结果明细

注意,在结果页里,可以和 idea 源码交互,对着方法点右键,可以直接定位到 idea 代码中的源代码,非常方便.

跳转

其他

其他,就是 可以在配置里设置根据哪些类,这样一些工具类啥的可以直接忽略了.

运行配置

使用了一下,还是不错的.但是这个有个问题,如果你的项目自定义了 classloader/ 或者使用了自定义的容易,这个由于没有 mvn 的 jar 包,可能会报错,类找不到.暂时没有好的办法.但是阅读开源代码基本没有问题了.

java  工作 

jdk8_cannot_access_class_file

之前有个项目用 jdk6跑运行正常,用 jdk8跑的时候,会报java cannot access ....class file ...as class file not found though it exists. 虽然可以通过加上报错的类到依赖里解决.但是一直没想明白,为啥 jdk6下没报错.

最近再次遇到,于是想一次性搞清楚.搜了一下,看 so 上有这么个说法.大意就是以前,如果 A 依赖 B,B 实现了 C 接口,编译的时候, 用 jdk8编译的时候, C 必须在 classpath 中, http://stackoverflow.com/questions/40255718/compiling-with-jdk-1-8-java-cannot-access-class-file-class-file-not-found

给出了一个 bug 连接,但是这里跟我们的问题有差异,不过这个点提醒了我.于是我搜索了一下 jdk8的relase note

http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html

注意观看这一段:

Area: Tools / javac Synopsis Interfaces need to be present when compiling against their implementations

好了.也就是说还是乖乖加依赖.但是清楚了原因了

java  工作 

oom介绍

oom 之前知道, 但是并不是很了解,最近遇到了由 oom 引发的问题,所以学习记录一下. OOM-killer:Out-of-Memory (OOM) Killer是一种保护机制,用于当内存严重不足时,为了系统的继续运转,内核迫不得已挑选一个进程,将其杀死,以释放内存,缓解内存不足的问题。 可以看出这种方式对进程的保护是有限的,不能完全的保护进程的运行。 如何知道是否发生了 oom 两种方法,第一种,查看 /var/log/messages,会有类似 Out of memory: Kill process 9682 (mysqld) score 9 or sacrifice child Killed process 9682, UID 27, (mysqld) total-vm:47388kB, anon-rss:3744kB, file-rss:80kB httpd invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0 httpd cpuset=/ mems_allowed=0 Pid: 8911, comm: httpd Not tainted 2.6.32-279.1.1.el6.i686 #1 这样的标识,说明发生了 oom,关键就是 kill process, 所以可以这样 sudo cat /var/log/messages | grep -i"killed process" 另一种是通过dmesg来查看 dmesg | egrep -i 'killed process' 这个命令查看的 oom 的时间里是时间戳的形式,如果你的 dmesg 没有-T这个时间的选项,那么就需要通过 [Read More]
java  工作 

graylog日记管理平台使用的那些坑

前言 最近使用 graylog在部署日志平台的时候,踩到很多”坑”,记录一下 日志采集(nxlog) 1.客户端不要做太多的正则计算 graylog 最早推荐的 nxlog 采集客户端,现在貌似有了 beats 的采集方式,不过我没了解,nxlog 采集的话,需要配置Snippets,就是定义输入,输出,处理器的地方,这个地方, Input 模块是在客户端计算的.所以,一定不要进行太多的正则计算.否则会严重影响客户端的 cpu 资源.降低应用程序的性能. 2.开多行一定要慎重 graylog 可以通过配置 <Extension multiline> Module xm_multiline HeaderLine /^\d{0,2}\/\d{0,2}\/\d{0,4}/ EndLine /^\d{0,2}\/\d{0,2}\/\d{0,4}/ </Extension> <Input pcc-esolutions-log> Module im_file File "*.log" SavePos TRUE InputType multiline </Input> 来实现对于类似错误栈这样的信息,将多行采集成一行,但是一定要注意.如果这个正则写错了,或者其他原因,导致,未能正确匹配.会导致 nxlog 客户端占用内存暴涨.原因是为了实现多行采集,会再客户端内存中保存日志内容,直到匹配到行尾.如果未能正确匹配.会一直保存.导致内存泄露. 这时候一般伴随着nxlog 的客户端日志中开始打印: 2016-12-05 18:36:47 ERROR oversized string, limit is 1048576 bytes 这样的信息.表示单条日志超过了1m 最终有一定几率影响客户端应用,被 oom 所杀.不要问我怎么知道的… 3 日志就是太大怎么办. 貌似没办法..只能在 Input 配置中. Exec if $raw_event $raw_event = substr($raw_event, 0, 1040000); 执行类似的来限制,没有尝试过,参考这里:日志大小超长配置 [Read More]
java  工作 

graylog中的mongodb配置

接手的一个工具平台,发现 graylog 集群使用了单个的 mongodb 作为数据库,于是需要配置一下集群,来防止数据丢失,毕竟很多配置都在里面. 为了以防万一,先备份一下 graylog 的配置. mongodump -h dbhost -d dbname -o dbdirectory 防止分布式部署的使用搞坏了.之后的恢复可以使用 mongorestore -h dbhost -d dbname --directoryperdb dbdirectory 来恢复.相关说明可以参考这里 之后就可以正式开始了 修改集群名字 在/etc/mongod.conf 中,修改这个值.设置集群使用的集群名称是 graylog,几个机器都配置一下.都先不要启动 replication: replSetName: graylog 然后添加集群配置 启动其中一台,然后通过mongo 命令连接上数据库,依次执行下面的命令.注意,这里有个坑.添加本机的时候,一定要写对外的域名或者 ip.否则会导致无法选主. rs.initiate() rs.add("<hostname>:27017") rs.add("<hostname>:27017") rs.add("<hostname>:27017") rs.conf() 开始启动 这里启动就不用说了. service mongod start 启动就好了. 配置 graylog 集群连接地址 在/etc/graylog/server/server.conf 中配置.mongodb_uri = mongodb://host1,host2,host3/graylog 后面这个 graylog 就是给 graylog 使用的库名,你可以先创建. 之后mongodb 就开始自行同步了. [参考] [Read More]
编程 

graylog中的字段解析

关于字段解析

一旦 graylog 用在了一个分布式系统上,那么采集的日志格式多种多样,涉及到通过 rules.drl来解析具体的字段.之前的同学的方案是用drools 来完成的.通过一个统一的界面,来给用户生成一些正则规则这种.然后自己写了个转换器转成 Drools 的文件.更新到 graylog 的服务器上.然后重启gralog 应用完成.

实际上, graylog 2之后的版本提供了rules和 pipeline ,这种不需要重启应用,完成这个解析的动作.但是.注意.这个不完善.所以只支持一些简单的语法,无法实现原有的完全转换.所以放弃.

在此过程中.这个rules 有一个比较强大的功能,自动解析 key value 对.需要添加,但是,需要你的日志文件格式里的 key value有空格, 也就是要求必须是 key=value 这样,不能紧挨着逗号这样的..比如你的打印日志是 key=value,key2=value2.那么久无法解析了..这个暂时没看到比较好的办法.估计要改代码.如果你恰好符合.那最好了.

java  工作