[Feature] The max length of service_name and service_instance_name cloud be configured

[elmerzeng]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Description

The default maximum length of service_name and service_instance_name is 50. But 50 is too short if service_name started with group_name.

So is it possible to set the length of service_name and service_instance_name through configuration?

Use case

Add configuration for these function.

MAX_LENGTH_OF_SERVICE_NAME=70
MAX_LENGTH_OF_SERVICE_INSTANCE_NAME=70

Related issues

No response

Are you willing to submit a pull request to implement this on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct

[wu-sheng]

First of all, as it is coded, this is not a bug.

Then, you had seen that this length is limited by the agent codes, so, it can't be changed without code changed.

[elmerzeng]

@wu-sheng This is a feature request. I'd. like to implement this function if you agree to it.

[wu-sheng]

Implement it like https://github.com/value annotation in spring framework. see https://www.baeldung.com/spring-value-annotation

Spring style is a reference, but we need a SkyWalking style thing.

[elmerzeng]

add length limited number after default value separated by '#'

In PropertyPlaceholderHelper.java parse this value as length limited.

[wu-sheng]

You can't easily use #70 to determine the length because you never know whether this # is a part of the configuration value or length definition.
Maybe consider using a different key? Such as agent.service_name#length=${SW_SERVICE_NAME_MAX_LENGTH:50}

[wu-sheng]

After all, there should not a field including #

[elmerzeng]

Ok, I will implement it as your suggestion. Place '#length' as a property for agent.service_name. Perfect suggestion!

[xiaozaiyuji]

I think this is should not be configuer by this.Because this is very complex.This serviceName is put together by the application name,clustername,namespace,This will be use to storage . For example this will base64 encode to as a id in elaticsearch.In service relation and endpoint realtion this will be very long even big than the elastic id max length 512.So this config will not solve the deep problem and just cause the complex.What we should do is try the best to change the length over the 512 of elasticsearch, we should change this deep problem other than just to limit the length or give a chance to config the length.But I know this is a big work to do this.even will be change the protool.So these need more discusss.

[elmerzeng]

We could provide this configuration, but we still could check if it is bigger than a fixed length. We could set the length no bigger than 128 or other fixed length.

[elmerzeng]

The length of base64 encoded service_name is no bigger than 512, so the maximum length of service_name is no bigger than 512/4 = 128

[wu-sheng]

What we should do is try the best to change the length over the 512 of elasticsearch,

@xiaozaiyuji This is not our call. Elasticsearch requires that, so be it. There are many other storage options that would benefit from this.
In 2024, BanyanDB will become our recommend storage option officially.

Generally, this kind of flexible configuration is acceptable. If you want to change Elasticsearch, you are free to go. We wouldn't. Elasticsearch is not open-source project anymore, we are not going to fully depend on it.
This is a decision had been made years ago.

[xiaozaiyuji]

I read this carefully,I have to advice we should did this slowly.I even try to write some code like to split the cluster_name,namespace to other elasticsearch properties.This will release some length to the serviceName to escape this problem.As our company,to change the storage to BanyanDB is expensive,because we did a lot of work to statistic the data by use elasticsearch. This job contains too much work.So can we take this advice in to consideration,when we to store the data to es ,we just use the group and service_name to gengerate the id to release the length.As we know the same service name to deploy in different clusters always as a servie. Maybe to split this can be query is something work less than to did the length config or wait 2024 to use BanyanDB.

[xiaozaiyuji]

In fact，I support the decision by Dear Wu to did the work BanyanDB，when the skywalking official think this can be replace elasticsearch I will try my best to change our storage to it to support us.