ctlstat: fix -P with disassociated LUNs.

[asomers]

Summary

It is possible to create a CTL LUN that is not associated with any
target. For example, prior to 15b3e3bb7efc that could happen if the
user exceeded kern.cam.ctl.max_ports and tried to create an additional
LUN. In this case, report the LUN to Prometheus as having no target at
all, rather than failing the command.

MFC after: 2 weeks
Sponsored by: Axcient

Test Plan

Manually tested

[mav]

I've never before looked on this code, but all this targdata.targets[lun] logic looks wrong to me. Any LUN may be mapped into multiple different ports, think that this code does not allow. LUNs not mapped into any port is only a one minor case of generally broken design. I have no idea what data this Prometheus is expecting to receive, but right now it obviously does not receive the full picture. This particular patch is not bad, but it just does not fix whole problem, only a minor part.

[asomers]

In D38130#866209, @mav wrote:

I've never before looked on this code, but all this targdata.targets[lun] logic looks wrong to me. Any LUN may be mapped into multiple different ports, think that this code does not allow. LUNs not mapped into any port is only a one minor case of generally broken design. I have no idea what data this Prometheus is expecting to receive, but right now it obviously does not receive the full picture. This particular patch is not bad, but it just does not fix whole problem, only a minor part.

Prometheus is expecting that each LUN has one associated target. If one LUN can be shared by multiple targets, then that's certainly a problem. Could you please share an example of such a configuration?

[asomers]

Note that ctlstat's prometheus functionality has already been MFCed to stable/13. However, it wasn't included in 13.1. So there's still time to change the output schema if we must, without breaking compatibility with any releases.

[mav]

In D38130#866215, @asomers wrote:

Prometheus is expecting that each LUN has one associated target. If one LUN can be shared by multiple targets, then that's certainly a problem. Could you please share an example of such a configuration?

I don't have exact working configuration, so just quickly drafted this for illustration:

portal-group 10g {
        discovery-auth-group no-authentication
        discovery-filter portal-name
}

lun 0 {
        path /dev/zvol/optane/zzz1
        serial "3000000000000300"
        device-id "3000000000000300"
        option naa 0x3000000000000300
}

lun 1 {
        path /dev/zvol/optane/zzz2
        serial "3000000000000301"
        device-id "3000000000000301"
        option naa 0x3000000000000301
}

lun 2 {
        path /dev/zvol/optane/zzz3
        serial "3000000000000302"
        device-id "3000000000000302"
        option naa 0x3000000000000302
}

target iqn.2000-01.net.company.testzzz:user1 {
        auth-group no-authentication
        portal-group 10g

        lun 0 0
        lun 1 1
}

target iqn.2000-01.net.company.testzzz:user2 {
        auth-group no-authentication
        portal-group 10g

        lun 5 1
        lun 7 2
}

target naa.50015178f369f092 {
        port isp0
        port isp1

        lun 8 0
        lun 17 1
        lun 22 2
}

[asomers]

@mav I think reporting a schema like this would work . I need to prototype it first to be sure, though:

• A bunch of "iscsi_lun_XXX" metrics each with a "lun" key iscsi_lun_bytes{lun="232", type="READ"} = 123456
• A join table like this: iscsi_target_lun{target="iqn.2018...", lun="232"} = 1

So to query the bytes/second for an entire target, you could do this sum(rate(iscsi_lun_bytes[5m] and on(lun, instance) iscsi_target_lun{target="..."} == 1)).
I'll try to prototype it now.

[mav]

I suppose that request would give you all traffic of the LUNs accessible through that target, even one going though different targets. As alternative, CTL collects per-port statistics, that would closer match targets, if desired, but then without separation between different LUNs.

[asomers]

In D38130#866489, @mav wrote:

I suppose that request would give you all traffic of the LUNs accessible through that target, even one going though different targets. As alternative, CTL collects per-port statistics, that would closer match targets, if desired, but then without separation between different LUNs.

Yes, that would work well. And I see that you can print those with the -p option. But there's not currently any way to get all of them, is there?

[mav]

In D38130#866505, @asomers wrote:

And I see that you can print those with the -p option. But there's not currently any way to get all of them, is there?

I guess not in this tool right now.

[asomers]

Closing in favor of D38500