Merge pull request #3857 from albinsuresh/doc/agent-sync-signal

doc: sync signal support for tedge-agent

Author: albinsuresh

docs/src/extend/log-management.md

@@ -258,7 +258,7 @@ Retrieve logs with time filters (timestamps in seconds since epoch):
 sudo /usr/share/tedge/log-plugins/docker get tedge-agent --since 1696250000 --until 1696260000
 ```
 
-## Dynamic log type discovery
+## Refresh Supported Log Types
 
 To ensure that any newly installed services or log sources are immediately available for log collection,
 `tedge-agent` automatically reloads the plugins and refreshes the supported log types on the following events:
@@ -268,9 +268,12 @@ To ensure that any newly installed services or log sources are immediately avail
 * A new software is installed with the agent (via the `software_update` command)
 * A new configuration is installed or updated with the agent (via the `config_update` command)
 
-If the new software or configuration is installed/updated externally, and not via `tedge-agent`,
-a refresh can be triggered by just touching the plugin configuration file:
+A refresh can also be triggered manually by sending a sync signal to the agent as follows:
 
 ```
-touch /etc/tedge/plugins/tedge-log-plugin.toml
+tedge mqtt pub te/device/main/service/tedge-agent/signal/sync_log_upload '{}'
 ```
+
+The agent reacts to all these events by gathering the latest supported log types from all the installed plugins
+by invoking the `list` command on them,
+and publishes the aggregated types to the `te/device/main///cmd/log_upload` meta topic.

docs/src/references/mqtt-api.md

@@ -712,9 +712,10 @@ Where the signal segments are describe as follows:
 
 The following table details some example signal types which are supported by %%te%%.
 
-| Signal Type | Example Topic                 |
-|-------------|-------------------------------|
-| sync        | `te/<identifier>/signal/sync` |
+| Signal Type     | Example Topic                            |
+|-----------------|------------------------------------------|
+| sync            | `te/<identifier>/signal/sync`            |
+| sync_log_upload | `te/<identifier>/signal/sync_log_upload` |
 
 The signal would be interpreted differently based on the target entity.
 
@@ -725,14 +726,22 @@ We plan to add support for more signal types in the future.
 
 ### Examples: With default device/service topic semantics
 
-#### Signal to a service
+#### Signal to the Cumulocity mapper service
 
 Signal to request the supported operations of the `tedge-mapper-c8y` service:
 
 ```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main/service/tedge-mapper-c8y/signal/sync '{}'
 ```
 
+#### Signal to the agent service
+
+Signal to refresh the `log_upload` command metadata (supported log types) of the `tedge-agent` service:
+
+```sh te2mqtt formats=v1
+tedge mqtt pub te/device/main/service/tedge-agent/signal/sync_log_upload '{}'
+```
+
 ## Health check
 
 Services can publish their health status as follows: