Placeholder for Metrics implementation and documentation

[jpwhitemn]

Per Monthly Architect's meeting of 6/27/22 - use an issue in this repository to list and track the implementation and documentation of Levski anticipated metrics collection.

🚀 Feature Request

List of expected metrics to be collected in the associated service areas

Application Services
see edgexfoundry/app-functions-sdk-go#1116

• Size of data exported (HTTP and MQTT)
  

•     Requires Meter metric type to be added.
  

• Number of invalid messages received (i.e. error decoding)
  

• Number of errors that terminate a pipeline (per pipeline)
  

• What is the current store and forward queue size (stretch)
  

• Message latency for received from MessageBus to hand off to Pipeline (stretch)
  

Device Services
see https://wiki.edgexfoundry.org/display/FA/Initial+Metrics+for+Device+Services

1. Metrics defined for all EdgeX services in ADR add the 'docs' subdirectory to match previous folder structure #6
   Cumulative API requests succeeded / failed / invalid
   Average response time for API requests
   Average and Maximum request size
   Note: The API requests of interest are the device accesses. For Device service purposes "request size" is to be read as "event size"
2. Metrics defined for Device Services in ADR add the 'docs' subdirectory to match previous folder structure #6
   Device requests
   Note: For "Device requests" we shall provide:
   total number of events generated
   total number of readings generated
   number of events generated in the last sampling period (configurable with a default of 1 minute)
   data volume of events generated in the last sampling period.
3. Metrics which will replace the lastConnected field in v3
   Last successful read or write access (per device)
   In addition the SDKs shall provide a facility for the device service implementations to collect and report custom metrics for that service.

Core/Supporting Services
this list is still a work in progress
Avg response time on APIs
Avg and Max request size
Latency (measure of time) an event takes to get through core data
Number of notifications handled successfully
Number of failed notification transmissions
Number of notifications in queue
Scheduler successful interval actions vs failed action

Security

• still being discussed *

Relevant Package [REQUIRED]

Per service list above

Description [REQUIRED]

A clear and concise description of the problem or missing capability...

Describe the solution you'd like

If you have a solution in mind, please describe it.

Describe alternatives you've considered

Have you considered any alternative solutions or workarounds?

[cloudxxx8]

Number of notifications in queue should not be the metric because the notification service sends out the notifications immediately once it receives any of them in the current design.
There will be no Number of notifications in queue

[jpwhitemn]

closing this issue as it was a list of needs for Levski. If we have other metrics we would like to capture we should open a new issue with the specific need.