wy471x commented on issue #7614: URL: https://github.com/apache/shenyu/issues/7614#issuecomment-6233056638
### Control plane registration: should tracing be managed from the dashboard? The tracing plugin follows the local configuration model of `metrics` today: it has no `plugin` row, and it is configured with `shenyu.tracing.*` in the gateway properties. The plan lists the control plane registration as a conditional task, so it would help to decide it here. **What a row would change in the gateway.** A plugin without a `plugin` row never receives an enable or disable event, so it stays on the plugin chain for the lifetime of the process. With a row, the dashboard could switch tracing on and off at runtime, and the plugin would show up in the plugin list. **Options** 1. **Stay local** (like `metrics` and `global`, which also have no row): no dashboard entry, tracing is switched by `shenyu.tracing.enabled` and a restart. 2. **Row only** (proposal): the `plugin` row with sort 0 and enabled by default, without `plugin_handle` fields. This gives the plugin list entry and the runtime on/off switch, while every setting (sampler, OTLP endpoint, resource attributes) stays in `shenyu.tracing.*`. The semantics to document: the property says whether tracing is installed, the row says whether it is switched on. 3. **Full dashboard configuration**: the row plus `plugin_handle` fields and a `PluginDataHandler`. I would avoid this for now, because the plugin does not read `PluginData.config` today, and part of the configuration cannot take effect at runtime anyway: the OTLP exporter is built when the tracer provider starts, so a change of the endpoint needs a restart. A form with fields which cannot be applied would be misleading. **Cost of option 2** is small and mechanical: one row in the five init schemas plus the five `2.7.1-upgrade-2.7.2-*` scripts, and the `PluginEnum` sort test which keeps the enum and the database in sync. **Question**: should the tracing plugin be registered in the control plane for dashboard visibility and a runtime on/off switch (option 2), or stay a local configuration plugin (option 1)? If it stays local, I would keep this task as a future option. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
