remove idleCount in druid plugin

[AlchemyDing]

In fact, in the druid, PoolingCount and idleCount represent the same meaning.

associate issue in opentelemetry-java-instrumentation

[wu-sheng]

Pending on OTEL side discussion, as I want to keep the whole context continuous.

[wu-sheng]

Your fix at OTEL-java side seems different. Could you explain more here or need to align with that?

[AlchemyDing]

idleCount should be druidDataSource.getPoolingCount()
But this way it's the same as poolingCount.
https://github.com/apache/skywalking-java/blob/main/apm-sniffer/apm-sdk-plugin/druid-1.x-plugin/src/main/java/org/apache/skywalking/apm/plugin/druid/v1/PoolingAddDruidDataSourceInterceptor.java#L63
Because the idleCount is not present in the druidDataSource, I removed the idleCount.

[wu-sheng]

So, Druid pool doesn't have an idle concept? Then what is the status of the connection after it is used?

[AlchemyDing]

Poolingcount represents the concept of idle

[wu-sheng]

Poolingcount represents the concept of idle

Then why don't put Poolingcount to idle, and idle + activeCount(maybe?) as the real poolingCount?
The reason I am asking about this is, that I want to make metrics meanings aligned with general understanding.

If this is able to apply, please add comments in the codes why we change like this.

[wu-sheng]

BTW, as a metric label is removed, the CI fails as expected. Let's focus on the above question first.

[AlchemyDing]

Poolingcount represents the concept of idle

Then why don't put Poolingcount to idle, and idle + activeCount(maybe?) as the real poolingCount? The reason I am asking about this is, that I want to make metrics meanings aligned with general understanding.

If this is able to apply, please add comments in the codes why we change like this.

Of course, this is possible.
But before that, I also have a question. I searched for the code of skywalking-java and found that only the druid plugin has attributes called poolingCount and idleCount. Do we need to change the original meaning of the druid for these two attributes in APM, perhaps we need a standardized semantic convention?
WDYT?

[wu-sheng]

Of course, this is possible.
But before that, I also have a question. I searched for the code of skywalking-java and found that only the druid plugin has attributes called poolingCount and idleCount. Do we need to change the original meaning of the druid for these two attributes in APM, perhaps we need a standardized semantic convention?

Good question. It should be good to remove that, rather than recalculate.

__

Meanwhile, to make CI passed, you should fix the expected file.

skywalking-java/test/plugin/scenarios/druid-1.x-scenario/config/expectedData.yaml

Lines 223 to 227 in eb10416

	- meterId:
	name: datasource
	tags:
	- {name: name, value: test_mysql-server:3306}
	- {name: status, value: idleCount}

[AlchemyDing]

Therefore, I have a proposal to standardize our semantic conventions, which can avoid potential semantic ambiguity in the future.

[AlchemyDing]

Of course, this is possible.
But before that, I also have a question. I searched for the code of skywalking-java and found that only the druid plugin has attributes called poolingCount and idleCount. Do we need to change the original meaning of the druid for these two attributes in APM, perhaps we need a standardized semantic convention?

Good question. It should be good to remove that, rather than recalculate.

__

Meanwhile, to make CI passed, you should fix the expected file.

skywalking-java/test/plugin/scenarios/druid-1.x-scenario/config/expectedData.yaml

Lines 223 to 227 in eb10416

	- meterId:
	name: datasource
	tags:
	- {name: name, value: test_mysql-server:3306}
	- {name: status, value: idleCount}

Done.

[wu-sheng]

Therefore, I have a proposal to standardize our semantic conventions, which can avoid potential semantic ambiguity in the future.

We should consider that in a way.