那有审计/监控的话看下每个节点的 in/out 记录呗，总能看到是哪一步跌了...
照你现在提供的信息听起来一切正常那就是业务逻辑本身输出少了，不然总得有哪里不一样。如果只有 sink 跌了，那就是 sink 有问题，比如可能依赖了外部环境或者内部积累错误等等。 Best, tison. Yang Peng <yangpengklf...@gmail.com> 于2020年9月30日周三 下午5:26写道： > 感谢回复，是的，之前确实怀疑是业务逻辑导致的 > 但是重启任务之后数据输出恢复了，而且让任务从故障点重新消费也没发现问题，我们这个任务已经跑了几个月了第一次遇到这种问题 > > tison <wander4...@gmail.com> 于2020年9月30日周三 下午2:33写道： > > > Hi Yang, > > > > 你的意思是上游输出没变，全链路没有负载升高甚至反而降低，sink 输出变少么？ > > > > 如果全链路没有异常也没有负载升高、流量阻塞，那感觉就是业务逻辑的实际结果，可以看看输入数据的内容有没有变化。 > > > > Best, > > tison. > > > > > > Yang Peng <yangpengklf...@gmail.com> 于2020年9月30日周三 上午10:29写道： > > > > > 感谢回复，我们看了consumer的lag很小 > > > 而且监控显示数据流入量也没明显变化但是感觉这部分数据只是offset被更新了但是数据没有消费到，这个问题之前没有遇到过 这是突发发现的 > > > 而且任务重启了没法jstack判断了 > > > > > > hailongwang <18868816...@163.com> 于2020年9月29日周二 下午10:35写道： > > > > > > > > > > > > > > > > > > > 不过也比较奇怪，Source 数据的 format的话，应该不会使得 CPU 降低，这期间 Iowait 高吗 > > > > 也可以 jstack 采下堆栈看下，GC等看下。 > > > > 至于 Source format 能力的话，可以自己测试下单个线程的QPS多少，然后乘以 Partition个数就是了。 > > > > Best, > > > > Hailong Wang > > > > 在 2020-09-29 20:06:50，"Yang Peng" <yangpengklf...@gmail.com> 写道： > > > > > > > > > > > > > > >感谢回复，我重启完任务之后消费恢复了，我查看了我们的监控（监控kafkamanager上groupid消费速度）发现消费速度并没有下降，目前分区是90 > > > > >flinkkafkaconsumer消费的并行度也是90 > 应该不是分区的问题，至于2这个source序列化耗时严重这个有什么方式可以查看吗？ > > > > > > > > > >hailongwang <18868816...@163.com> 于2020年9月29日周二 下午8:59写道： > > > > > > > > > >> > > > > >> > > > > >> > > > > >> Hi Yang Peng: > > > > >> 根据你的描述，可以猜测瓶颈是在 Source 上，有可能以下情况： > > > > >> 1. Kafka 集群和Flink 集群之间的带宽被其它打满了。 > > > > >> 2. Source 的序列化耗时严重，导致拉取变慢。 > > > > >> 可以尝试着扩kafka 分区，加大Source并发看下。 > > > > >> Best， > > > > >> Hailong Wang > > > > >> > > > > >> 在 2020-09-29 19:44:44，"Yang Peng" <yangpengklf...@gmail.com> 写道： > > > > >> >请教大家一个问题，flink实时任务消费kafka写入到kafka，Flink版本是1.9.1 线上kafka集群为1.1.1 > > > > >> >kafka集群为容器化集群部署在K8s上，任务运行了很久 今天突然发现任务的数据产出降低了很多，发现cp 没有问题 > > > > >> >kafka消费没有积压，也没有反压， > > > > 也没有任何异常日志，kafka集群也没有异常，flink集群也没有异常，但是发现监控上tm的cpu负载也降低了 > > > > >> >tm上网卡流量也降低了，除此之外没有其他异常信息，大家又遇到这种情况的吗、 > > > > >> > > > > > > > > > >
