Introduction to AIMS
If you have been working with BizTalk Server for some time now, chances are you are aware of how much hassle you will need go through to get a comprehensive operational monitoring for the entire environment encompassing your integration solution.You will probably be using several tools like Windows built-in performance counters, Event log, SQL Server profiler, BizTalk Administration Console, and may be even SCOM or HP OpenView, just to name a few.
So, assuming you are equipped with the right toolset and backed with in-depth BizTalk Administration experience, you will then need to make sense of the entire environment picture from all these different tools’ outcomes.
In my experience this usually leads the development teams to one of two paths, either monitoring is entirely evaded or postponed by the team, or it is conducted inadequately which means to wait for a critical issue to happen and business suffer, then start looking for which tools to use to diagnose it.
AIMS monitoring platform bridges the gap of the need to work with several disparate monitoring tools, by centralizing different metrics from across your environment in one place.
The very first time I heard about AIMS monitoring platform was from reading one of my favorite books: SOA Patterns with BizTalk Server 2013 and Microsoft Azure Second Edition. However, what really caught my eyes was the proactive, intelligent, self-learning monitoring approach that leverage AI and machine learning in its backend.
AIMS first analyzes normal behavior pattern in different metrics, then it will detect anomalies that clearly deviate from the normal patterns. Moreover, these metrics not only focuses on BizTalk server, but could also span across SQL Server, and Windows Server, creating the much-needed big picture for your entire environment.
I was really excited by the proactive and self-learning aspects, let’s say it brought the geek spirit out of me, as the idea was simply differentiated from all the other monitoring tools I had used or known about to that point, especially that you don’t have to manually configure thresholds yourself, instead AIMS uses dynamic thresholds based on observed behavior that was analyzed by AIMS.
I registered and used the trial version for a few weeks to explore it, and here are my initial thoughts as well as highlighting the following few points for anyone interested to work with AIMS for the first time.
Ideally, you should start monitoring your integration solution after it has been stabilized, live, and already being used by the business, or end-users. This will allow AIMS to take its time to analyze the normal behavior patterns based upon the actual real-world usage of the solution.
You could also start monitoring earlier in your project life cycle, may be start creating the required metrics, for example during the UAT phase, and then you could force AIMS to re-learn these patterns again after going live.
Another key point here is to start creating your own custom visual chart blocks and reports with the expected metrics that could be dependent on each other, and thus could be correlated.
This will help conveying the right information for your administrators, for example, you could correlate the message count & the message publishing throttling state.
The correlation will initially rely on your technical experience, or the out-of-the-box charts that ship with AIMS, however, sometimes you could also recognize other correlated metrics that you didn’t plan for ahead of time which could be unique to your solution, this will happen during issues encountered.
As mentioned earlier, correlating metrics could go beyond one platform, which give a lot of potential for deeper understanding of your entire environment behavior and health, after all BizTalk Server runs on top of SQL server, and both run on top of Windows Server, so it becomes crucial to see the big picture.
Consequently, using AIMS charts, you could overlay the relevant throttling charts along with server memory usage, and DB size charts, this could give you an indication to potential, or existing problems in one consolidated chart at a glance!
Anomalies detection is one of the pinnacle features of AIMS, you should leverage such detection alerts by providing your feedback on such anomalies, be either ignoring or accepting these anomalies, for even further fine tuning of AIMS learning process, in order to indicate what is considered normal and what is not.
Contrary to my initial perception, you could also create some useful business reports based on specific message types defined in your integration solution for things like: how many a specific business request has been received, or how long these requests are handled by the solution, this could be displayed over a range with the required granularity: hour, day, week. Then, you could gather all these business reports into dedicated dashboards targeting your business users.
One important thing to note is that AIMS engine is cloud-based, aside from installing the relevant agents (Windows Services) on the target servers, it doesn’t actually need a local back-end storage. These agents relay only the messages’ metadata that are required for all the metrics being analyzed by the engine, so no need to worry about message payload which could include sensitive data.
I will continue exploring the platform, and I will post further interesting findings on AIMS platform, If you are excited and want to try it too, you could contact AIMS team or schedule a demo from their official site.