我的便当盒

利用arthas排查性能问题实践，最终排查是并发竞态问题！

Elasticsearch集群状态RED问题排查。

GF_AUTH_JWT_URL_LOGIN用于指定是否可以通过http query参数传递jwt，9.2.2前的版本改环境变量不生效。

[TOC][match_phrase_prefix] query does not support [zero_terms_query] 问题解决。

通过源码追踪可知，所有数据库SQL请求均被封装为HirariProxyPreparedStatement，而系统异常状态下，共计16个正在运行中的HirariProxyPreparedStatement同时存在，与JpaExecutorService线程上限一致，且所有SQL均是TdEngine的插入操作。因此，作为临时方案，可修改配置文件，增加最大线程数，并同时设置TdEngine连接池超时时间，使得线程池资源在TdEngine请求都超时的最坏情况下依然能正常工作。没错了，答案就是：资源耦合！

http响应头不能随意透传，有些响应头是框架维护的，并且可以影响底层TCP连接。tomcat对http协议的处理逻辑在Http11Processor，后面可以进一步掌握与学习。

记一次k8s线上容器网络问题，最后排查出是容器间跨主机访问不通，重启所有POD解析，但是具体原因没查到，希望大神能帮助解答！

问题描述：https://github.com/prometheus/client_java/issues/623查看源码后发现，micrometer-registry-prometheus:1.6.3版本中PrometheusMeterRegistry类中newMeter方法引用的Collector.Type.UNTYPED这个枚举在io.prometheus:simpleclient中没有对应定义。@Override protected Meter newMeter(Meter.I

connect reset by peer应该是服务点发送了rst或者客户端发送了fin，总之就是tcp连接已经断了，但是程序不知道，还在往这个连接里写东西，才会报这个错。所以就需要使用tcpdump这个命令来进行抓包，看看具体是哪个原因。但是，不过滤下源\目的IP，源\目的端口，tcpdump出来的东西太多了，我又是小白肯定没法分析。所以需要了解怎么缩小抓取范围，这个时候就需要k8s容器网络的知识了，因为我们的java应用服务和es都是在k8s里面的。