Re: Ignite not friendly for Monitoring

Assigned the version 2.5 to the ticket. Let's try to make progress on this before then. On Tue, Jan 16, 2018 at 12:03 PM, Denis Magda wrote: > Serge, > > Thanks for taking over this. Think we’re moving in a right direction with > your proposal: > > * I would add a top-level

Re: Ignite not friendly for Monitoring

Serge, Thanks for taking over this. Think we’re moving in a right direction with your proposal: * I would add a top-level domain for “Integrations”. All the integrations with Kafka, Spark, Storm, etc. should go there. * Second-level domains number can grow over the time per a top-level layer.

Re: Ignite not friendly for Monitoring

It might be an issue: https://issues.apache.org/jira/browse/IGNITE-3690 I'm going to update it when the domain list will be agreed upon by the community. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: Ignite not friendly for Monitoring

Is there a Jira ticket for it? On Mon, Jan 15, 2018 at 7:48 AM, Serge Puchnin wrote: > Igniters, > > It's a right idea! > > Let's try to revitalize it and make a move on. > > As a first step, I would like to propose a list of a top-level domain. > > -- the phase 1 >

Re: Ignite not friendly for Monitoring

Igniters, It's a right idea! Let's try to revitalize it and make a move on. As a first step, I would like to propose a list of a top-level domain. -- the phase 1 1. UnExpected, UnKnown 2. Cluster and Topology Discovery Segmentation Node Startup

Re: Ignite not friendly for Monitoring

Dima, Please see latest comments in the ticket [1]. There is special specification called SQLSTATE governing what errors code are thrown from SQL operations [2]. This is applicable to both JDBC and ODBC. Apart of from standard code, database vendor can add it's own codes as a separate field, or

Re: Ignite not friendly for Monitoring

On Mon, Aug 28, 2017 at 1:22 AM, Vladimir Ozerov wrote: > IGNITE-5620 is about error codes thrown from drivers. This is completely > different story, as every driver has specification with it's own specific > error codes. There is no common denominator. > Vova, I am not

Re: Ignite not friendly for Monitoring

IGNITE-5620 is about error codes thrown from drivers. This is completely different story, as every driver has specification with it's own specific error codes. There is no common denominator. On Thu, Aug 17, 2017 at 11:10 PM, Denis Magda wrote: > Vladimir, > > I would

Re: Ignite not friendly for Monitoring

Denis, IGNITE-5620 is completely different thing. Let's do not mix cluster monitoring and parser errors. ср, 16 авг. 2017 г. в 2:57, Denis Magda : > Alexey, > > Didn’t know that such an improvement as consistent IDs for errors and > events can be used as an integration point

Re: Ignite not friendly for Monitoring

Alexey, Didn’t know that such an improvement as consistent IDs for errors and events can be used as an integration point with the DevOps tools. Thanks for sharing your experience with us. Would you step in as a architect for this task and make out a JIRA ticket with all the required

Re: Ignite not friendly for Monitoring

Hi Alexey, A nice thing about delegating alerting to 3rd party enterprise systems is that those systems already deal with lots of things including distributed apps. What is needed from Ignite is to consistently write to log files (again that means stable event IDs, proper event granularity, no

Re: Ignite not friendly for Monitoring

Hi Denis, Monitoring tools simply watch event logs for patterns (regex in case of unstructured logs like text files). A stable (not changing in new releases) event ID identifying specific issue would be such a pattern.  We need to introduce such event IDs according to the principles I described

Re: Ignite not friendly for Monitoring

Hello Alexey, Thanks for the detailed input. Assuming that Ignite supported the suggested events based model, how can it be integrated with mentioned tools like DynaTrace or Nagios? Is this all we need? — Denis > On Aug 14, 2017, at 5:02 AM, Alexey Kukushkin >

Ignite not friendly for Monitoring

Igniters, While preparing some Ignite materials for Administrators I found Ignite is not friendly for such a critical DevOps practice as monitoring.  TL;DRI think Ignite misses structured descriptions of abnormal events with references to event IDs in the logs not changing as new versions are