...

1. We should add some entities in Ignite:

1. MetricDomain MetricRegistry - Ignite subsystem that provides some set of sensors and lists.
   1. Cache,
   2. Compute,
   3. ServiceGrid,
   4. etc.

2. Sensor Metric - some named number with a well-defined algorithm to calculate the value in any given moments in time. 

   Code Block
   language java
   class SensorMetric { String name; //EntryCount, MemoryAvailable, etc long value; //or double Collection<Tuple2<String, String>> labels; //hostName, cacheName, etc. } class TimeSensorLongMetric extends SensorMetric { long ts; //timestamp of the last value update. }

   
   

3. List SystemView - some named list of string that contains info about Ignite objects. Examples: List of caches, Transaction Transactions list, List of nodes, List of running queries, Las N queries, etc...

4. MonitoringEvent - generated when some user-defined code violates the threshold.

   Code Block
   language java
   class MonitoringEvent { MonitoringEventType type; //Event type. T info; //Event info. Type of info differs for different type of events. }

   
   

2. SensorProcessorGridMetricManager, MonitoringEventProcessorGridSystemViewManager: 

1. SensorProcessor GridMetricManager - should be able to store and query Ignite sensorsmetrics.
2. MonitoringEventProcessor GridSystemViewManager - should be able to set up event listeners, watch for user code executions and route eventsstore and export SystemViews.

3. ExposersExporters:

Specific admin interfaces will be supported through exposersexporters.
Exposer Exporters should work only with SensorProcessor only with a read-only version of GridMetricManager and don't rely on other knowledge about Ignite internals.

...

Example of exporters:

1. JMX
2. HTTP
3. SQL System View
4. Java
5. etc.
6. Log
7. etcPushExposer - this type of exposers should export sensors and list to some external system based on the configured schedule.
8. LogExposer
Integration with proprietary monitoring system can be implemented as PushExposer.

List of API that should be listed in Phase

...

2

1. Compute tasks:
   1. Closures
   2. Map-reduce jobs
   3. ComputeJob
   4. Scheduled tasks
2. Service grid:
   1. Services with deployment status
3. Caches
4. Cache groups
5. Cluster nodes
6. SQL objects
   1. Schemas
   2. Tables
   3. Views
   4. Tables columns
   5. Views columns
   6. Indexes
7. Queries:
   1. SQL
   2. Scan
   3. Text
   4. ContinousQuery
8. IgniteCache#invoke
9. put, get, remove, replace, clear operations
10. Transactions with lock list
11. DataStreamers
12. Explicit locks(IgniteCache#lock)
13. DataStructures
    1. Queue
    2. Set
    3. AtomicLong
    4. AtomicReference
    5. CountDownLatch
    6. Sequence
    7. Semaphore
14. Message topics (IgniteMessaging)
15. Thin client connections.
16. Machine Learning - ???

...

We should consider implementing this IEP as Ignite 3.

Discussion Links

http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Monitoring-amp-Profiling-Proof-of-concept-td41904.html

http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Monitoring-amp-Profiling-Current-API-Analysis-td41823.html

http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-IEP-35-Metrics-configuration-td42478.html

http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-GridJobProcessorMetrics-migration-td42415.html#a42441

http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-IEP-35-Replace-RunningQueryManager-with-GridSystemViewManager-td43794.html/ Links to discussions on the devlist, if applicable.

Gap analysis

Current monitoring APIs availability:

...