Plans for Telemetry Module in OpenMRS

Development
1

Hi all,

As you may or may not be aware, depending on how regularly you attend our O3 Squad calls, we’ve been working on integrating OpenMRS with a monitoring stack based on a standard called OpenTelemetry, which is widely-used for observability. Currently, we’ve been working on this for system monitoring, i.e., being able to build dashboards in something like Grafana that display real-time system uptime and usage metrics. (See this PR for a sample of what this work looks like).

While this monitoring work mostly focuses on stuff we can get out-of-the-box (JVM metrics, Docker metrics, and other application-agnostic things), really ensuring an OpenMRS instance is running as expected requires more application-specific data, including program-level real-time monitoring data. That’s what this discussion is about.

What to Measure

As a first, pass we’ve been considering having metrics like those below. These are defined in groups based on OpenTelemetry’s metric definitions. The name is meant to give a flavor of what the data captured is. The attributes are, roughly speaking, similar to disaggregates, i.e., the groupings that we can break things down by.

Counters (accumulate over time):

  • openmrs.patient.registrations (attributes: location)
  • openmrs.encounters (attributes: encounter.type, location)
  • openmrs.appointments.scheduled (attributes: appointment.service, location)
  • openmrs.appointments.attended (attributes: appointment.service, location)
  • openmrs.orders (attributes: order.type, location)
  • openmrs.logins (attributes: outcome)

Gauges (a periodic sample):

  • openmrs.sessions.active
  • openmrs.visits.active (attributes: visit.type, location)
  • openmrs.queue.entries (attributes: queue, status, location)
  • openmrs.appointments.upcoming (attributes: location)

How to Measure

This would likely be done through a new backend module which would provide an easy API to contribute metrics at sensible points that plug into the OpenMRS system. E.g., we might implement the registration counter through an event listener that listens to new patient creation events, whereas the active session count would be provided by plugging into the login/logout events that we already publish, etc.

What we’d like to hear from you

  1. Does this sound like something helpful and useful?
  2. What metrics or attributes should we also consider?
  3. What sort of extensibility would you want for something developed along these lines?
3 Likes
2

Resource utilization in the cases of containerised instances to monitor things like

  • orphaned / dangling images / volumes I know this may be high later but build up of unused resources negatively impacts overall performance in terms of RAM and storage.

a SneakPeek into this can help the user to mitigate dangling build up and so action taken( similar to how portainer does it) .

Hope this is in scope of the current work