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.
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
A practical guide to using the tools PERFMON and MONLBL.
Introduction
When investigating performance problems, I often use the utilities ^PERFMON and ^%SYS.MONLBL to identify exactly where in the application pieces of code are taking a long time to execute.
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.
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.
This article assumes that you are familiar with Zabbix and SNMP monitoring, if not, there are some very interesting posts on the Community, especially this one (https://community.intersystems.com/post/creating-custom-snmp-oids) which contains a lot of information on how to configure and request an SNMP Cache server.
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.
In last week's discussion we created a simple graph based on the data input from one file. Now, as we all know, sometimes we have multiple different datafiles to parse and correlate. So this week we are going to load additional perfmon data and learn how to plot that into the same graph.
Since we might want to use our generated graphs in reports or on a webpage, we'll also look into ways to export the generated graphs.
When an error occurs in your application, simply logging it might be enough. But for certain errors, you might want to send a notification to people right away. There are three ways to generate custom email notifications from InterSystems IRIS.
> Customizable System Monitoring. ## Introduction The Polymetric Dashboard is a stand-alone module that provides enhanced monitoring tools for a Caché environment. Equipped with over one hundred sensors that monitor key system metrics, a robust REST API, and a modular AngularJS user interface, the Polymetric Dashboard is fully functional out of the box. However, the Polymetric Dashboard is designed to be customizable; any system metric can be monitored by creating a new sensor, and the visualization of collected data can be tailored to specific requirements and purposes.
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.
In this post I would like to talk about the syslog table. I will cover what it is, how you look at it, what the entries really are, and why it may be important to you. The syslog table can contain important diagnostic information. If your system is having any problems, it is important to understand how to look at this table and what information is contained there.
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.
First post! In order to somewhat redeem myself for an unnecessary call to support, I've decided to post some classes that I've written to monitor certain metrics inside our Ensemble Live instance (yeah, Kyle, you WERE laughing at me, but it's okay). What the classes do is to run queries and code to get database sizes, status of the mirror, counts of rows in tables such as EnsLib.HL7.Message and Ens.MessageHeader. The data is collected and written to tables and then an email is sent out daily upon completion. I've found this quite useful in keeping an eye on what's going on. It's help
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.
Presenter: Barry Cooper Task: Enable users to perform analytics within an application and take actions based on those analytics Approach: Provide examples of embedding DeepSee within applications
Analytics is more than just using data to provide insight. Analytics is about taking action on that insight. See examples of how you can embed DeepSee in your applications, allowing you to take action.
Content related to this session, including slides, video and additional learning content can be found here.
Presenter: Luca Ravazzolo Task: Track the status and performance of clustered environments Approach: Give examples of using modern technology to spot potential bottlenecks before they turn into problems
This session will discuss how modern technology can be used to keep track of the status and performance of your cloud clustered environments.
Content related to this session, including slides, video and additional learning content can be found here.
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.
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.
By date
Open Exchange app