You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Story about feedback loops needs data. Data can be collected automatically by the systems. These metrics are describing how the user is using the services. This is of course specific to each service and they define their own metrics.
There can be common metrics between systems and these can be documented in this standard.
Collection of data happens by the services. But the data must be accessible for services which are analyzing the data. This can be the same service of course, but it would be much better to share the data system wide. This way all services can see how the user is moving between services in the whole system. This data could even be open.
Different methods and other thoughts:
Each service collects and stores the data themselves and then periodically publishes the data to central repository. Data is then queried back from central repository to services which need it. Central repository behaves like a cache for the data and it is stored there for only certain amount of time.
Each service collects the data and pushes it to central repository in realtime. Central repository works as a publish/subscribe message bus and publishes the data to all listening parties. Data is not stored in the repository.
Each service has common API which everyone else can use to query for data. There would be retention policies how long the data must be accessible in the API.
As a personal opinion I like all of them. They are not mutually exclusive and we could define the central repository to:
must have a database which stores the data for certain period
must have REST API to query the data (with public and open part)
must have publish/subscribe API for realtime message passing
must have an API to register services and then it must query periodically the data and publish it in the publish/subscribe API on behalf of the service
Services:
may connect to the publish/subscribe API
may have common API for querying metrics and register to the repository
must either connect to the publish/subscribe API or have the common API
The text was updated successfully, but these errors were encountered:
Story about feedback loops needs data. Data can be collected automatically by the systems. These metrics are describing how the user is using the services. This is of course specific to each service and they define their own metrics.
There can be common metrics between systems and these can be documented in this standard.
Collection of data happens by the services. But the data must be accessible for services which are analyzing the data. This can be the same service of course, but it would be much better to share the data system wide. This way all services can see how the user is moving between services in the whole system. This data could even be open.
Different methods and other thoughts:
Each service collects and stores the data themselves and then periodically publishes the data to central repository. Data is then queried back from central repository to services which need it. Central repository behaves like a cache for the data and it is stored there for only certain amount of time.
Each service collects the data and pushes it to central repository in realtime. Central repository works as a publish/subscribe message bus and publishes the data to all listening parties. Data is not stored in the repository.
Each service has common API which everyone else can use to query for data. There would be retention policies how long the data must be accessible in the API.
As a personal opinion I like all of them. They are not mutually exclusive and we could define the central repository to:
Services:
The text was updated successfully, but these errors were encountered: