Welcome to the next chapter of my CI/CD series, where we discuss possible approaches toward software development with InterSystems technologies and GitLab.
Today, we continue talking about Interoperability, specifically monitoring your Interoperability deployments. If you haven't yet, set up Alerting for all your Interoperability productions to get alerts about errors and production state in general.

Inactivity Timeout is a setting common to all Interoperability Business Hosts. A business host has an Inactive status after it has not received any messages within the number of seconds specified by the Inactivity Timeout field. The production Monitor Service periodically reviews the status of business services and business operations within the production and marks the item as Inactive if it has not done anything within the Inactivity Timeout period.
The default value is 0 (zero). If this setting is 0, the business host will never be marked Inactive, no matter how long it stands idle.

This is an extremely useful setting since it generates alerts, which, together with configured alerting, allows for real-time notifications about production issues. Business Host being idle means there might be some issues with production, integrations, or network connectivity worth looking into.
However, Business Host can have only one constant Inactivity Timeout setting, which might generate unnecessary alerts during known periods of low traffic: nights, weekends, holidays, etc.
In this article, I will outline several approaches towards dynamic Inactivity Timeout implementation. While I do provide a working example (currently running in production for one of our customers), this article is more of a guideline for building your own dynamic Inactivity Timeout implementation, so don't consider the proposed solution as the only alternative.

5 0
0 245
Article
· Aug 16, 2023 11m read
Http request response time monitoring

Hi developers!

Today I would like to address a subject that has given me a hard time. I am sure this must have been the case for quite a number of you already (so-called “the bottleneck”). Since this is a broad topic, this article will only focus on identifying incoming HTTP requests that could be causing slowness issues. I will also provide you with a small tool I have developed to help identify them.

Our software is becoming more and more complex, processing a large number of requests from different sources, be it front-end or third-party back-end applications. To ensure optimal performance, it is essential to have a logging system capable of taking a few key measurements, such as the response time, the number of global references and the number of lines of code executed for each HTTP response. As part of my work, I get involved in the development of EMR software as well as incident analysis. Since user load comes mostly from HTTP requests (REST API or CSP application), the need to have this type of measurement when generalized slowness issues occur has become obvious.

13 5
8 622
Article
· Aug 26, 2016 8m read
Enterprise Monitor and HealthShare

Enterprise Monitor is a component of Ensemble and can help organizations monitor multiple productions running on different namespaces within the same instance or namespaces running on multiple instances.

Documentation can be found at:

http://docs.intersystems.com/ens20161/csp/docbook/DocBook.UI.Page.cls?KEY=EMONITOR_all#EMONITOR_enterprise

In Ensemble 2016.1 there were changes made to make this utility work with HealthShare environments.

This article will:

  • Show how to set up Enterprise Monitor for HealthShare sites
  • Show some features of Enterprise Monitor
  • Show some features of Enterprise Message Viewer

For this article, I used the following version of HealthShare:

Cache for Windows (x86-64) 2016.1 (Build 656U) Fri Mar 11 2016 17:42:42 EST [HealthShare Modules:Core:14.02.2415 + Linkage Engine:14.02.2415 + Patient Index:14.02.2415 + Clinical Viewer:14.02.2415 + Active Analytics:14.02.2415]

10 2
0 1.3K

Released with no formal announcement in IRIS preview release 2019.4 is the /api/monitor service exposing IRIS metrics in Prometheus format. Big news for anyone wanting to use IRIS metrics as part of their monitoring and alerting solution. The API is a component of the new IRIS System Alerting and Monitoring (SAM) solution that will be released in an upcoming version of IRIS.

11 2
7 1.7K
Article
· Feb 3, 2023 3m read
Queue monitoring

Overview

With the gradual improvement of hospital information construction, there are more and more business interfaces in hospitals. Due to the influence of various factors (network, consumer system, etc.), the data processing of business interface may cause excessive message accumulation and even the situation of interface card congestion, which affects the normal business development in the hospital. Therefore, the monitoring of the queue of business interface components becomes more and more important.

3 2
0 353
Article
· Feb 7, 2023 3m read
IRIS Queue monitoring component

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.

4 1
0 210

Some Usage cases

1. A deployment may consist of two high availability instances and two disaster recovery instances in a different data center.

The corresponding UAT environment could replicate this giving a total of 8 instances. How do you confirm CPF and Scheduled task alignment across ALL instances.

3 2
0 293

The following steps show you how to display a sample list of metrics available from the /api/monitor service.

In the last post, I gave an overview of the service that exposes IRIS metrics in Prometheus format. The post shows how to set up and run IRIS preview release 2019.4 in a container and then list the metrics.


This post assumes you have Docker installed. If not, go and do that now for your platform :)

17 10
5 1.2K
Article
· Feb 25, 2019 4m read
Using Grafana directly from IRIS

There have been some very helpful articles in the community that show how to use Grafana with IRIS (or Cache/Ensemble) by using an intermediate database.

But I wanted to get at IRIS structures directly. In particular, i wanted to access the Cache History monitor data that is accessible by SQL as described here

https://community.intersystems.com/post/apm-using-cach%C3%A9-history-mon...

and didn't want anything between me and the data.

9 5
4 1.3K
Article
· Jul 12, 2019 2m read
Basic Database Metrics example

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.

6 3
3 524

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:

7 1
0 545

The MONITOR process (also called the Caché Monitor) scans the messages in your cconsole.log file and sends you emails based on the severity of those messages. The MONITOR is configured using the ^MONMGR utility in terminal.

The MONITOR should not be confused with the similarly named System Monitor, which checks a variety of system health and performance metrics and can log messages regarding them to the cconsole.log, where they can then be scanned by the MONITOR.

2 6
1 1.3K

When you have been using cubes for business intelligence in a namespace for some time, you may find that there are many cubes in the namespace, only some of which are actively being used. However, it can be difficult to tell which cubes users are or are not querying, and maintaining unused cubes can be costly both in terms of storage and of computation to keep them up to date. This article provides some suggestions and examples for monitoring which cubes are in active use, and for removing cubes that you determine are no longer necessary.

4 2
2 389
Article
· Aug 2, 2020 1m read
Application Errors Analytics

Hi Developers!

As you know the application errors live in ^ERRORS global. They appear there if you call:

d e.Log() 

in a Catch section of Try-Catch.

With @Robert Cemper's approach, you can now use SQL to examine it.

Inspired by Robert's module I introduced a simple IRIS Analytics module which shows these errors in a dashboard:

3 5
1 292

Hi All,

With this article, I would like to show you how easily and dynamically System Alerting and Monitoring (or SAM for short) can be configured. The use case could be that of a fast and agile CI/CD provisioning pipeline where you want to run your unit-tests but also stress-tests and you would want to quickly be able to see if those tests are successful or how they are stressing the systems and your application (the InterSystems IRIS backend SAM API is extendable for your APM implementation).

4 0
1 635

One of the topics that comes up often when managing Ensemble productions is disk space:

The database (the CACHE.DAT file) grows in a rate that was unexpected; or the Journal files build up at a fast pace; or the database grows continuously though the system has a scheduled purge of the Ensemble runtime data.

It would have been better if these kind of phenomena would have been observed and accounted for yet at the development and testing stage rather than on a live system.

For this purpose I created a basic framework that could aid in this task.

4 7
2 1.2K