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.
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.
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.
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.
> 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.
Internally we use splunk for monitoring applications and network.
Does Ensemble have a way of exposing internal metrics and/or a way of exposing custom built metrics?
I've used Deepsee dashboards in the past to monitor Apache Tomcat/Apache Camel/hawtio using JMX rest calls. This is the other way around and ideally I'd like to expose metrics on:
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.
Can Cache Monitor (^MONMGR) and System Monitor be configured to also send 'OK' messages? With the first bad email, you still wonder if things are still broken, when in-fact normalcy has been restored, some even within some seconds.
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.
As per the documentation of QueueCountAlert: Number of messages on this item's queue needed to trigger an Alert message to be sent. Note that no further alerts will be sent unless the number of messages on the queue drops below 80% of this number and then rises again to this number. Note that this alert will be sent even if AlertOnError is False. Zero means no alerts of this type will be sent.
Now, the question is, If QueueCountAlert is set to 10, and the queue size become 11 we will be getting email once.
When we write unit test cases for cache object script code using %UnitTest.TestCase, what is the best way to write code to identify code coverage?
So, let say my unit test case hit all 10 lines of code of a method for a given class. So, unit test coverage should be 100% for that. But, using line-by-line coverage [(%Monitor.System.LineByLine] getting wrong percentage, because it also includes code comment/documentation as part of code. So, practically we can not ever achieve 100% of code coverage by using this API.
At the Global Summit several folks had mention that they developed their own production monitor. I am looking to create a monitor similar to eGate that we only display those Services/Processes/Operations that are in trouble, and those Errors that are showing up in the Event Log. Does anyone have any examples of this?
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
We have multiple implementations spanning many namespaces and edges. I would like to see if I could identify a single place, perhaps on HSREGISTRY or HSBUS, that I could capture certain events like searches (from all customers) and record transfers (with requester and provider).
The goal is to have a dashboard that would show simple stats such as searches by participant, records shared by participant and records consumed by participant. These are the 3 most important.
I appreciated the feedback on the other question of "how" but now I'm hoping to find the "Where".
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.