Whether we need an attribute of the array type?

[NeJan2020]

For now, the AttributeMap we defined in DataGroup support to use "string","int" and "bool" as the value type.
This design does not have the capacity to carry more complex data, it is more evident in some complex Span when we care about repetitive structured data. Here is an example.
A DNS request contains more than one domain to look up. We can record each result captured in response, such as below.

[
    {"dns.domain": "xxx1.com","dns.r_code": 0},
    {"dns.domain": "xxx2.com","dns.r_code": 3},
    {"dns.domain": "xxx3.com","dns.r_code": 0},
]

However, it's hard to put this data into AttributeMap in a reasonable way now.

Describe the solution you'd like
Add MapAttributeType map And ArrayAttributeType is an obvious way to solve this problem.
And since we are using an array, it's more convenient to get the instance of the ArrayValue when using it.
Here we used some static struct to get the instance and not affect the exposed structure.

type AttributeValueType int
const (
        ...
	ArrayAttributeValueType
        StringAttributeValueType
)


type AttributeValue interface {
        Type() AttributeValueType
        ...
	valueHepler
}

type valueHepler interface {
	ArrayValue() *AttributeArray
	StringValue() string
	...
}

type aValueHelper struct {
}

func (h *aValueHelper) ArrayValue() *AttributeArray {
	panic("type error: this value is not definend as array!")
}

func (h *aValueHelper) StringValue() string {
	panic("type error: this value is not definend as string!")
}


type AttributeArray struct {
        ...
	aValueHelper
}

// Overwrite the method defined by aValueHelper
func (v *AttributeArray) ArrayValue() *AttributeArray {
	...
}

func (v *AttributeArray) Append(value *AttributeValue) {
	...
}

How we use this:

var attr AttributeValue
var sub_item AttributeValue
... // initialization
if attr.Type() == ArrayAttributeValueType{
    attr.ArrayValue().Append(sub_item)
}
if attr.Type() == StringAttributeValueType{
    attr.StringValue()...
}

Additional context
The changes are not complex, but clearly affect the logic of the subsequent processing components, and we are not in high demand at the moment.

Is this change necessary?

[dxsup]

Could you provide more use cases?

[NeJan2020]

Here is another example that I was working on.
I am recording all network devices that message packets passed before leaving the host, to evaluate packet loss and retransmission on the specified trace. The final record format is as follows.

DataGroup:
        Name: single_net_request_metric_group
        Values:
                "connect_time": 0
                "request_sent_time": 65127
                "waiting_ttfb_time": 474005443
                "content_download_time": 6316209816
                "request_total_time": 6790280386
                "request_io": 35
                "response_io": 4407
        Labels:
        {
                "comm": "kube-proxy",
                "container_id": "500a49155f81",
                "dnat_ip": "",
                "dnat_port": -1,
                "dst_ip": "10.10.101.124",
                "dst_port": 6443,
                "error_type": 0,
                "is_error": false,
                "is_server": false,
                "is_slow": true,
                "message_capture": [
                        {
                                "ENDts": "1663810836525855529",
                                "STARTts": "1663810836523790402",
                                "dst_ip": "10.10.101.124",
                                "dst_mac": "30:0d:9e:27:6b:26",
                                "dst_port": 6443,
                                "if_name": "tunl0",
                                "skb_addr": "18446612133608880872",
                                "src_ip": "10.10.103.195",
                                "src_mac": "00:50:56:92:38:88",
                                "src_port": 55604,
                                "ts": "1663810836524817575"
                        },
                        {
                                "ENDts": "1663810836525855529",
                                "STARTts": "1663810836523790402",
                                "dst_ip": "10.10.101.124",
                                "dst_mac": "30:0d:9e:27:6b:26",
                                "dst_port": 6443,
                                "if_name": "ens192",
                                 ...
                        },
                        ...
                ],
                "pid": 25255,
                "protocol": "NOSUPPORT",
                "src_ip": "10.10.103.195",
                "src_port": 55604
        }
        Timestamp: 1663810836524790402

There is no suitable storage structure for the field named message_capture now in the Labels, it is a complex property consisting of an array and a map.

[dxsup]

I also find a use case that requires an array as a label. Now I have to marshal the array to a string, which makes the subsequent processing extremely inconvenient.

It seems like this feature is necessary now. The next topic will be how we implement it to make it easy to use.