gridgain.com

In this post, we describe how to implement monitoring of a complex distributed system by using Zabbix as the monitoring tool and Apache Ignite as the distributed system. The key external indicators (KPIs) of system performance constitute a relatively standard set: Zabbix contains templates for monitoring these metrics and for monitoring extended metrics, like disc utilization. Template file already contains the “Template App Ignite JMX” template, I have added the “Template App Generic Java JMX” and “Template OS Linux by Zabbix agent” templates. When you organize monitoring, you can choose between the redundancy of the metrics  and the performance of the product and monitoring system.

You can then run the JMX Exporter  as a Java agent: $ bin/ignite.sh -v $PROJECT/config/myconfig.xml -J- If you use the server, you need to add the “hostPort” parameter to your JMX Exporter configuration. You point the exporter at the JMX port of your Apache Ignite or GridGain node. Our commitment to open standards and open source led GridGain to implement OpenCensus support in Apache Ignite too.

And, with GridGain 8.8, we are rolling out the first set of advancements (yep, more to come) that enable you to leverage the disk tier of the database to query larger datasets, reduce the total cost of ownership, and secure sensitive and personal data at rest. Also, you can join the “New Advances in GridGain's Multi-Tier Database Engine” webinar to learn about the details and to watch demos that illustrate the key improvements that GridGain 8.8 offers. Previous releases of GridGain and Ignite (before GridGain 8.8) do not provide automatic defragmentation, which compacts used space and makes more space available for on-disk records. SQL memory quotas avoid out-of-memory issues and use the disk tier when SQL queries that require a lot of memory space are running.

The engine introduces an API that can update most Ignite configuration parameters in runtime, without requiring you to follow special parameter-update procedures or do cluster-node restarts. DDL statements and external tools function on top of the unified API, so users can always get intuitive results Probably, in regard to developer experience, a unified CLI tool is the most important addition planned for Ignite 3. * Single-file download (Instead of downloading a huge ZIP file that has hundreds of files and a complicated structure, you get a single script, the CLI tool, which you can use for all further operations.) * Ability to install core Ignite artifacts and external dependencies via Maven * Ability to connect to a cluster, acquire the current configuration, and update some of the dynamic parameters