2022年12月

tcpdump 里面的数据只有特定方向的

最近在诊断一个问题的时候, 当时有件奇怪的事情: 所有的流量都是流向一个IP的, 再也没有其它流量.
为了查出为什么会连接timeout, 于是去抓包, 因为知道连接肯定是443 或 80, 于是使用下面的命令:

$ tcpdump port 80 or port 443 -w /tmp/tcpdump.pcap

可是抓到的结果却全是流向这个IP 的, 并且没有返回traffic:
tcpdump.png

最后发现, 这个机器上有2个接口: tunl0 和 eth0, 抓包时候, tcpdump 默认使用了 tunl0 接口:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 10.147.64.197/32 scope global tunl0
       valid_lft forever preferred_lft forever
22: eth0@if23: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether e2:99:0b:96:46:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.147.166.192/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::e099:bff:fe96:46a0/64 scope link
       valid_lft forever preferred_lft forever

$ tcpdump port 80 or 443 -w /tmp/tcpdump.pcap
tcpdump: listening on tunl0, link-type RAW (Raw IP), capture size 262144 bytes
^C2 packets captured
16 packets received by filter
0 packets dropped by kernel

从上面ip a 的结果看, 除了 lo 之外, 它存在一个隧道接口和一个eth 端口, 可是使用 tcpdump 时候, 它默认使用了 tunl0 接口.

如果要抓取所有接口的流量, 可以使用

$ tcpdump -i any port 80 or port 443 -w /tmp/tcpdump.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

记录在生产环境k8s安装 janusgraph 的艰难过程

最近有个功能的某些数据特别适合图数据库, 一开始使用的是 MySQL 数据库, 但是在业务开发的过程中, 愈发觉得图数据库才是它的最终归宿, 于是先期先用 MySQL 做了一版, 顺利上线, 然后第二步准备迁移到图数据库.

之前小组内部有人用过 Neo4j, 用的还挺不错, 准备使用, 但是后来听说这个对于大企业要收费, 并且公司有个部门已经做好了一个基于 Janusgraph 的数据库, 统一管理, 保证稳定运行, 所以最后放弃 Neo4j, 转而准备上公司已经搭好并且有部门维护的这个图数据库. 但是一番打听下来, 要使用这个数据库, 有个复杂的流程, 关键的关键是: 如果你改任何一个图的schema(顶点, 边及其任何属性, 都要提ticket, 然后走review流程. 对于我们这种一开始还不确定到底有多少类型的顶点, 多少边, 时不时随时可以加边的实验性的项目, 这种流程简直就是灾难.

所以, 最可行的方案是: 我们先自己在开发, 测试, 生产环境搭一套基于 Janusgraph 的图数据库, 等我们的 schema 都稳定之后, 再考虑迁移到有稳定保障的, 有部门支持的图数据库.

首先, 在开发环境基于 Janusgraph 的 docker image 做了一个server, 并且搭了一个 graphexp 的 UI server. 脚本如下:

mkdir -p /home/supra/work/data/janusgraph/{data,index}
sudo chown -R 999:999 /home/supra/work/data/janusgraph
docker run --name janusgraph -p 8182:8182 --restart always -d --platform linux/amd64 -v /home/supra/work/data/janusgraph/data:/var/lib/janusgraph/data -v /home/supra/work/data/janusgraph/index:/var/lib/janusgraph/index janusgraph/janusgraph
docker run --name graphexp  -p 8183:80 --restart always -d --platform linux/amd64 ghcr.io/armandleopold/graphexp:0.8.3

大家注意到, 这里我们给 Janusgraph 的server 挂载了一个 volume, 还把这个挂载的文件夹的owner 改成了用户和组都是999的用户, 这里确实是偷懒. 这一切都是因为 Janusgraph 的 docker 文件里面新起了一个 janusgraph 的用户, 它的uid和gid都是 999. 在 Janusgraph server 里面, 都是以这个用户运行的. 都是因为这个用户和组, 导致我最后必须写下这篇记录.

本地环境这么起起来, 往里面灌入数据, 在用 graphexp 的UI 去访问, 一切顺利. 于是准备轰轰烈烈的去搞一个prod Janusgraph server 集群, 目标是1个小时搞定.

首先, prod 环境不能访问外网的 docker image, 于是拉下最新的外网image, 然后重新打一个 tag, 搞成内网的 image, 然后在生产环境的 k8s 环境做一个新的app, 然后一番乱搞, docker image 开始启动了.

但是呢, 总是启动不起来, 为啥, 因为:

chown: changing ownership of '/var/lib/janusgraph': Operation not permitted
chown: changing ownership of '/etc/opt/janusgraph': Operation not permitted
chmod: changing permissions of '/var/lib/janusgraph': Operation not permitted
chmod: changing permissions of '/etc/opt/janusgraph': Operation not permitted

仔细分析下来, 主要是:

  1. 生产环境都是 rootless 的, 所以运行 container 的 uid 都不是 root, 是一个根据 namespace 预先定义好的用户.
  2. 生产环境默认所有image 里面的文件都是read only, 所以对于日志, 数据文件必须通过 volume 挂载使用.
  3. 给 Janusgraph server 用的 data 和 index 文件夹都是挂载的 volume, 而这些 volume 的owner 都是上面预先定义好的 rootless 用户;
  4. 而一旦进入 Janusgraph, 它却以 Dockerfile 中自己新加的 janusgraph(999:999) 这个用户运行.

所以, 就造成了这种困境: 因为 image 里面的文件都是 read only, 和必须保存这些数据, 数据必须以 volume 的方式挂载, 然而挂载的文件夹的主人是预先定义好的非 root 账号, Janusgraph 的启动脚步里面却要改变这些数据文件夹的属主, 但是它使用的自己创建的账号janusgraph(999:999), 而这个账号有没有权限更改owner. 于是死了.

想解决这个问题, 有2种可能的方案:

  1. 生产环境其实可以改变这个预先定义好的非root 账号, 我们的生产环境可以针对某个namespace 创建一个新的用户, 而这个用户必须绑定生产环境的 LDAP. 所以, 要先定义一个生产环境的 LDAP 账号, 规定它的uid/gid, 然后绑定某个 k8s 下面的namespace, 然后在运行这个 container 的 spec 里面的 SecurityContext 里面设置 fsgroup, runAsUser 等.
  2. hack Janusgraph 的 Docker 文件, 去掉这个自己创建的用户, 像其它 image 一样, 用默认用户不香吗?

首先想去试试第一种方案. 去找了公司内部k8s的文档, 说是有这么一个创建posixuser 的流程, 可能是因为很少有人用, 搜了半个多小时, 没有找一个完整的文档, 能教会我怎么去做的. 更多的文档是说查看有了这么一个账号, 然后就可以以它运行container 了. 再加上更改任何生产环境的东西, 要走审批流程, 1个小时后, 我彻底放弃了.

第二种方案, 就是要大改看懂 Janusgraph 的Dockerfile 和 docker-entrypoint.sh 两个文件. 花了半个小时, 大改看到它就是想以一个service acount (janusgraph) 来运行这个服务, 然后启动前, 把相关的文件都给这个用户设置好, 然后就启动. 于是改了上述2个文件里面的关于这个用户的行, 然后加了一些日志, 然后本地做一个新的image, 然后push 到内部 image 仓库, 然后启动等好消息.

然而, 有没起来, 还以为是关于这个用户的错误, 又加调试代码, 做新image, 发布的流程再走一遍, 仍然起不来. 后来竟然发现是 刚起来, 就被 OOM kill 了. 哎, 命运多舛. 为啥 OOM 呢, 本地好好的. 因为 OOM 很快被 kill, 所以只有很短的时间, 能进入 container 去查看日志, 但是进入发现, 日志文件都是空.

于是进入本地启动好的 container 里面, 去查看它的启动参数(container 里面啥工具都没有, cat /proc/1/cmdline 才看到), 发现它启动的时候, 竟然就要求 heap 是4G, 那么再加点其它的 metaspace , 还有些辅助进程等, 岂不是5G打不住? 然而一开始我觉的它需要的内存很小, 只给了它1G的空间, 所以 OOM 也就很好理解了. 于是我就想问了, 为啥官方文档不告诉你最少需要5G呢???, 另外启动日志不能把这么重要的参数打印出来吗?

虽然心有不忿, 还是立马改了内存限制, 立马给他8个G, 然后再启动, 发现起来了, 可是有错:

Disk usage is not within je.maxDisk or je.freeDisk limits and write operations are prohibited

对了, 就是这个还在 open 的issue, 必将以后还要open: https://github.com/internetarchive/heritrix3/issues/340. 因为他们改变不了. 原来这个内存数据库, 需要至少5个G的磁盘空间, 否则, 它就生气. 而我给所有的 volume 的大小总共才2个G, 所以出这个错, 也就不难理解了.

于是, 我有给 volume 加到12个G. 于是重新部署, 大家都开心了, 你好, 我也好. 终于成功了. 至此, 本来打算要1个小时完成的工作, 终于通过12个小时(早上9点到晚上9点, 当然中间包括2顿饭的时间和1个多小时的开会)的努力, 画上句号了.

jcmd 的 GC.class_stats 子命令

jcmd 的 GC.class_stats 子命令 输出 JVM 里metaspace (元数据)区的 class 相关的信息. 这里必须记住, 所有的 java.lang.Class 及其子类都在heap, 元数据区只是这些class的元数据, 元数据区存的也不是这些类编译后的字节码(bytescode).

GC.class_stats 能输出每个class 在 metaspace 空间占用的大小.

这个子命令在JDK 14 deprecated, 15去掉.

默认只输出下面这些列, 还有更多列可以显示, 需要指定列名称:

InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes,MethodAll,ROAll,RWAll,Total
$ bin/jcmd <pid> GC.class_stats

由于类太多, 并且长度会折叠, 这里截图开头和结尾的截图:
head.png
tail.png

最好结合 jcmd <pid> VM.metaspace 一起看
vmMetaspace.png

- 阅读剩余部分 -

JVM 的 TimeZone 被别人改了

昨天有同事让我看看为啥一台QA的机器上的时区变了, 同样的代码在生产环境显示的日期都是 MST 时区(如:Tue Dec 06 06:52:22 MST 2022), 可是QA 环境显示的时间都是 UTC 时区(如: (如:Tue Dec 06 013:52:22 UTC 2022)).

检查步骤:

首先确认这个 Linux 机器上的时区

$ date
Tue Dec 06 013:52:22 UTC 2022

通过以上代码确认, 这个Linux 机器时区是正确的

检查 JVM 的时区

  1. JVM 可以通过启动参数添加: -Duser.timezone="XXXX/YYYY"

    java -Duser.timezone="Asia/Kolkata" com.tianxiaohui.AppMain
  2. 又或者设置系统环境变量添加

    System.setProperty("user.timezone", "Asia/Kolkata");
  3. 又或者通过设置默认时区:

    TimeZone.setDefault(TimeZone.getTimeZone("UTC"));

对于第一种方式, 可以通过检查Java 进程的启动命令获得(这里假设pid是44848), 发现命令行没设置时区.

cat /proc/44848/cmdline
````
对于第二种方式, 我们首先通过查 看 ```cat /proc/44848/environ``` 的方式去查看, 没发现这个环境变量. 不过我们通过jdk 自带的命令的方式却发现了:

$ bin/jcmd 44848 VM.system_properties
java.version=1.8.0_342
user.timezone=America/Phoenix
sun.arch.data.model=64

虽然找到了系统环境变量, 却发现这里是正确的, 并不是Date.toString() 表现出的UTC 时区. 于是就只能检查是不是第三种设置的. 

# 如何查看当前运行中的JVM里面的默认时区
1. 可以通过 JVM attach agent的方式去查看, 要自己写个 Agent, 可以参考这个简单的 Agent: https://github.com/manecocomph/myJavaAgent/blob/962f424176e02b9638fec87a0a5d1bad9cfaf0b2/src/com/tianxiaohui/java/agent/SampleAgent.java
当然, 你可以通过 Btrace 不安全的方式,找个容易控制的拦截点, 然后打印 默认时区. 

2. 另外一种方式就是直接做一个heap, 直接查看heap 里面的 Timezone 找个class的字段, 我们就采取了这种方式, 打开 heap dump, 找到这个 java.util.TimeZone 类, 然后查看其静态字段defaultTimezone, 直接可以看到被设置的时区. 
第一步找到这个类:
![heap1.png][1]
查看其 静态字段 defaultTimeZone
![defaultTZ.png][2]

# 找到代码
既然确认是通过代码设置默认时区, 那么直接搜索代码就找到了. 原来他们在最近的代码改动中, 有人为了某个feature, 直接修改了系统 TimeZone, 但是其本来只是想看看另外一个时区的时间. 


[1]: https://www.tianxiaohui.com/usr/uploads/2022/12/2240322561.png