#Monitoring

From time to time, we get the previous question in support, something or someone is using more licenses than expected, and we need to find what.

We have two scenarios. The first scenario is when we realize that the licenses are exhausted when the application does not work or when we try to connect through the terminal and get the "lovely"

<LICENSE LIMIT EXCEEDED> message:

This is a self contained class that can be run from the Intersystems Task Scheduler which records peak usage details for databases and licenses built up throughout the day and retaining 30 days history.

To schedule the task to run every hour:

d ##class(Metrics.Task).Schedule()

You can also specify your own start time, stop time, and run interval:

d ##class(Metrics.Task).Schedule(startTime, stopTime, intervalMins)

Metrics are stored in ^Metrics in the namespace that the class resides in/is run from.

Hi community,

The aim of this article is to explain how to create messaging between IRIS and Microsoft Teams.

In my company, we wanted to monitor error messages, and we used the Ens.Alert class to redirect those error messages through a Business Operation that sent an email.
The problem was that we sent those error messages to a support account where there were many emails. We wanted something specific for a specific team.

So we investigated how to make these messages reach the development team directly and they could have, in real time, a notification of an error in our production.
In our company we use Microsoft Teams as a corporate tool, so we asked ourselves: How could we make these messages reach the IRIS development team?

InterSystems Production Monitor is a page in Management Portal to display monitoring information for the current running production. I like the page as it comes, but one size does not fit all.

On May 13, 2022 I read this post on Developer Community:

InterSystems IRIS Business Intelligence provides the Cube Registry as an interface for managing and scheduling build and synchronize tasks for your cubes.

Presenter: Kerry Kirkham
Task: Prevent application-to-application interface problems from escalating
Approach: Give examples of using alerts to get the right person working on a problem as soon as possible

Problems with application-to-application interfaces are inevitable but in most cases they can be fixed with little disruption as long as the right person gets to know about it as soon as possible. But delays in attention cause problems to escalate, pressure mounts and business suffers. This session looks at how monitoring and alerting can be set up to recognize problems and get the right person working on the problem in the shortest possible time so that small problems don’t turn into major issues.

Solution: Using alerts to minimize interface problems

Content related to this session, including slides, video and additional learning content can be found here.

1. Overview

With more and more hospital applications built, business interface data processing may be affected by a variety of factors (network, consumer systems, etc.), there is an excessive accumulation of messages or even cause interface lag, affecting the routine performance of hospital IT systems , so the monitoring of the business interface components queue is increasingly important.

While current Intersystems IRIS platform's built-in queue monitoring only displays real-time queue information for interface components, which is limited in providing the queue data information needed by hospitals. The queue monitoring component program is based on the Intersystems IRIS platform and can monitor all interface components and display component queue information within 24h of the component, as well as query component historical queue data by setting a time period to better meet the needs of current in-hospital applications.