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.
Previously, I shared with you all a handy operational analytics dashboard you can build to visualize key message processing metrics, such as number of inbound/outbound messages, average processing times, etc.
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).
Note (Sept 2018): There have been big changes since this post first appeared, I suggest using the Docker Container version, the project and details for running as a container are still in the same place published on GitHub so you can download, run - and modify if you need to.
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.
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 :)
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.
APM normally focuses on the activity of the application but gathering information about system usage gives you important background information that helps understand and manage the performance of your application so I am including the IRIS History Monitor in this series.
In this article I will briefly describe how you start the IRIS or Caché History Monitor to build a record of the system level activity to go with the application activity and performance information you gather. I will also give examples of SQL to access the information.
This post is dedicated to the task of monitoring a Caché instance using SNMP. Some users of Caché are probably doing it already in some way or another. Monitoring via SNMP has been supported by the standard Caché package for a long time now, but not all the necessary parameters are available “out of the box”. For example, it would be nice to monitor the number of CSP sessions, get detailed information about the use of the license, particular KPI’s of the system being used and such. After reading this article, you will know how to add your parameters to Caché monitoring using SNMP.
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:
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.
This example is extracted from a long-running installation. The purpose is to have a simple monitoring of several servers at a rather primitive level. Just slightly more intelligent than a raw PING. But still easy to integrate. It avoids the overkill of information you are often confronted with while you are just interested in the number of active processes or similar basic figures.
Has anyone tried the new Activity Volume Statistics and Monitoring in Ensembel 2016.1? I would love to get some feedback.
If you haven't read about this, there is a dashboard that provides counts and response times for messages sent and received by each configuration item. Alternatively the underlying data is arranged in tables that should make it easy for you to use your favorite SQL reporting tools to generate reports for short term performance monitoring or longer term capacity planning.
I wanted to see some alerts that occur in my Productions in a Mobile Device, I came across Pushover.net recently that although has an upfront cost $5 you can send as many messages as you like after that, there is a 7 day free trial to check it out.
To Integrate this with a production I did the following.
A key part of Application Performance Management (APM) is recording the activity and performance of user activity. For many web applications the closest you can get to this is to record the CSP pages or CSP based services being dispatched.