如何在继承Netty ChannelInboundHandlerAdapter的类中，在exceptionCaught()方法中处理Prometheus指标并传递channelRead()中的数据？

遇到这种痛点太常见了——想在异常场景下也打出和正常流程标签一致的监控指标，但异常跳转到exceptionCaught后，原来channelRead里初始化的变量就拿不到了。这里给你两个实用的方案，你可以根据自己的业务场景选择：

方案一：利用ChannelHandlerContext的属性存储临时数据 #

Netty的ChannelHandlerContext自带属性映射功能，你可以用它来存储需要跨方法传递的指标数据（比如commandName、请求开始时间），这样不管channelRead里有没有抛出异常，exceptionCaught都能顺利拿到这些数据。

具体步骤如下：

1. 先定义一个封装指标数据的内部类，以及对应的AttributeKey：

// 定义AttributeKey，用来标识上下文里的指标数据
private static final AttributeKey<MetricContext> METRIC_CONTEXT_KEY = AttributeKey.newInstance("metricContext");

// 内部类封装需要传递的指标字段
private static class MetricContext {
    String commandName;
    long startTime;
    // 可以根据需求添加其他字段，比如channel标识等
}

2. 在channelRead方法开头就把数据存入上下文，并用finally保证清理：

@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
    MetricContext metricCtx = new MetricContext();
    // 初始化你需要的字段，这里假设你已经获取到commandName
    metricCtx.commandName = commandName;
    metricCtx.startTime = System.currentTimeMillis();
    
    // 把数据存入上下文
    ctx.attr(METRIC_CONTEXT_KEY).set(metricCtx);

    try {
        // 你的业务处理逻辑写在这里
        ...
        
        // 正常完成时记录成功指标
        long duration = System.currentTimeMillis() - metricCtx.startTime;
        meterRegistry.timer(
                "processing.handler.command.duration",
                "command_name", metricCtx.commandName,
                "success", Boolean.toString(true)
        ).record(duration, TimeUnit.MILLISECONDS);
    } finally {
        // 不管成功失败，都清理上下文里的临时数据，避免内存泄漏
        ctx.attr(METRIC_CONTEXT_KEY).remove();
    }
}

3. 在exceptionCaught方法中读取上下文数据，记录失败指标：

@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
    MetricContext metricCtx = ctx.attr(METRIC_CONTEXT_KEY).get();
    if (metricCtx != null) {
        // 计算从请求开始到异常发生的耗时
        long duration = System.currentTimeMillis() - metricCtx.startTime;
        // 记录失败的指标，标签和成功流程保持一致
        meterRegistry.timer(
                "processing.handler.command.duration",
                "command_name", metricCtx.commandName,
                "success", Boolean.toString(false)
        ).record(duration, TimeUnit.MILLISECONDS);
        
        // 保险起见，再次清理数据（避免finally没执行到的极端情况）
        ctx.attr(METRIC_CONTEXT_KEY).remove();
    }
    
    // 原来的异常处理逻辑，比如打印日志、关闭连接等
    ...
}

这个方案的优势是：即使异常是在其他Handler传递过程中抛出的，只要上下文还在，就能拿到指标数据，适合复杂的Handler链场景。

方案二：在channelRead内部用try-catch-finally统一处理指标 #

如果你的业务逻辑异常基本都在channelRead方法内部抛出，不想折腾上下文存储，可以直接用try-catch包裹业务逻辑，在finally里统一记录指标——不管成功失败，都能直接用当前方法里的变量。

示例代码：

@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
    String commandName = ...; // 初始化commandName
    long startTime = System.currentTimeMillis();
    boolean isSuccess = true;

    try {
        // 你的业务处理逻辑
        ...
    } catch (Exception e) {
        isSuccess = false;
        // 把异常抛出去，让exceptionCaught继续处理（如果需要的话）
        throw e;
    } finally {
        long duration = System.currentTimeMillis() - startTime;
        // 统一记录指标，根据isSuccess标记成功/失败
        meterRegistry.timer(
                "processing.handler.command.duration",
                "command_name", commandName,
                "success", Boolean.toString(isSuccess)
        ).record(duration, TimeUnit.MILLISECONDS);
    }
}

这个方案更简洁，代码紧凑，不需要额外的上下文操作，适合逻辑比较单一的Handler。

注意事项 #

• 用方案一的时候，一定要记得清理上下文属性！因为Netty的Channel可能会被复用，如果属性没清理，会导致内存泄漏或者脏数据。
• 如果你的commandName是从msg里解析出来的，要确保解析过程不会抛出异常——最好把解析逻辑也放在try块之前，或者在catch里处理解析失败的情况，保证commandName能正常拿到。

备注：内容来源于stack exchange，提问作者Eljah