AIOps

Antonio

AIop's and Netcool omnibus are slightly different, in terms of how you manage them.  Internally AIOps has multiple datastore which have to be kept in sync, therefore direct modifications of datastores is not advised due to data synchronisation issues. Therefore interaction and modification of the system is done via well-defined API's.( https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=apis-issue-resolution-api)   In AIops thing like object server trigger are no longer present. 

The structure of AIops alerts is different to a Netcool alert.  This allows more reasoning about the nature of the data.  In AIops things like String limits, Object Server Row size limit, and having to up front add a column to the object server is no longer need.

Link to the AIops alert schema

https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=schemas-alerts-events-schema-fields

Aiops can consume alerts from an object server  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-tivoli-netcoolomnibus-connections) or https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-probe-common-tasks to connect probes directly to the AIops internal object server (FYI it not a normal object server, so customer cannot add triggers etc to it)

It sounds like you have developed automation that act on the events, it depends on what component you have encoded that logical in.  If the logic is within object server triggers the that logic cannot be directly applied.   If that logic in impact policy AIops can call impact policy.  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=policies-invoke-impact-policy) .  If that logic is contained in object server trigger, it might be worth considering connected you on prem object server with the custom logic in to aiops via the Netcool connector.   This will allow you to reuses that logic, but take the befits of AIops features.

Dear Jonathan,

I see some attributes like "Location", "Service", etc. Similar to what we do in Omnibus, Can we add these attributes in the alert console for AIOPS so the user can see a column to represent location or any other custom attributes?

Thanks.

Antonio

AIop's and Netcool omnibus are slightly different, in terms of how you manage them.  Internally AIOps has multiple datastore which have to be kept in sync, therefore direct modifications of datastores is not advised due to data synchronisation issues. Therefore interaction and modification of the system is done via well-defined API's.( https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=apis-issue-resolution-api)   In AIops thing like object server trigger are no longer present. 

The structure of AIops alerts is different to a Netcool alert.  This allows more reasoning about the nature of the data.  In AIops things like String limits, Object Server Row size limit, and having to up front add a column to the object server is no longer need.

Link to the AIops alert schema

https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=schemas-alerts-events-schema-fields

Aiops can consume alerts from an object server  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-tivoli-netcoolomnibus-connections) or https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-probe-common-tasks to connect probes directly to the AIops internal object server (FYI it not a normal object server, so customer cannot add triggers etc to it)

It sounds like you have developed automation that act on the events, it depends on what component you have encoded that logical in.  If the logic is within object server triggers the that logic cannot be directly applied.   If that logic in impact policy AIops can call impact policy.  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=policies-invoke-impact-policy) .  If that logic is contained in object server trigger, it might be worth considering connected you on prem object server with the custom logic in to aiops via the Netcool connector.   This will allow you to reuses that logic, but take the befits of AIops features.

Antonio

AIop's and Netcool omnibus are slightly different, in terms of how you manage them.  Internally AIOps has multiple datastore which have to be kept in sync, therefore direct modifications of datastores is not advised due to data synchronisation issues. Therefore interaction and modification of the system is done via well-defined API's.( https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=apis-issue-resolution-api)   In AIops thing like object server trigger are no longer present. 

The structure of AIops alerts is different to a Netcool alert.  This allows more reasoning about the nature of the data.  In AIops things like String limits, Object Server Row size limit, and having to up front add a column to the object server is no longer need.

Link to the AIops alert schema

https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=schemas-alerts-events-schema-fields

Aiops can consume alerts from an object server  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-tivoli-netcoolomnibus-connections) or https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-probe-common-tasks to connect probes directly to the AIops internal object server (FYI it not a normal object server, so customer cannot add triggers etc to it)

It sounds like you have developed automation that act on the events, it depends on what component you have encoded that logical in.  If the logic is within object server triggers the that logic cannot be directly applied.   If that logic in impact policy AIops can call impact policy.  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=policies-invoke-impact-policy) .  If that logic is contained in object server trigger, it might be worth considering connected you on prem object server with the custom logic in to aiops via the Netcool connector.   This will allow you to reuses that logic, but take the befits of AIops features.

Thank you for the very detailed response.

Yes, we have automations that are implemented partly via Impact policies and partly via triggers.

The original alarm is enriched by specific enrichment policies that add more personalized information.

Currently, there are dozens of custom fields in ObjectServer. Some of these fields are currently important for the operation team to identify the problem. For example, one of these fields informs the geographic location of the equipment using GPS coordinates.

How can we present this type of information on the operator console?

How can we incorporate more information into the alerts console?

Furthermore, there are automations external to Netcool that consult information directly from the ObjectServer to assist in troubleshooting Netcool as a whole.

From what we are realizing, the procedures developed over more than ten years will have to be reviewed to be implemented in AIOPs. We believe that most of these procedures are not easy to implement in AIOPs.

The expectation is that the transition from Netcool to AIOPs will be slow and that we will have to keep the current on-premises environment functional for a long period of time.

Antonio

AIop's and Netcool omnibus are slightly different, in terms of how you manage them.  Internally AIOps has multiple datastore which have to be kept in sync, therefore direct modifications of datastores is not advised due to data synchronisation issues. Therefore interaction and modification of the system is done via well-defined API's.( https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=apis-issue-resolution-api)   In AIops thing like object server trigger are no longer present. 

The structure of AIops alerts is different to a Netcool alert.  This allows more reasoning about the nature of the data.  In AIops things like String limits, Object Server Row size limit, and having to up front add a column to the object server is no longer need.

Link to the AIops alert schema

https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=schemas-alerts-events-schema-fields

Aiops can consume alerts from an object server  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-tivoli-netcoolomnibus-connections) or https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-probe-common-tasks to connect probes directly to the AIops internal object server (FYI it not a normal object server, so customer cannot add triggers etc to it)

It sounds like you have developed automation that act on the events, it depends on what component you have encoded that logical in.  If the logic is within object server triggers the that logic cannot be directly applied.   If that logic in impact policy AIops can call impact policy.  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=policies-invoke-impact-policy) .  If that logic is contained in object server trigger, it might be worth considering connected you on prem object server with the custom logic in to aiops via the Netcool connector.   This will allow you to reuses that logic, but take the befits of AIops features.

Hi 

I sent you a private message, i think we should get together and talk specifics, that will be the best way to answer your question.  Thought to a general point so help other people that come across this message.   In aiops you can add field to alert by just included them, at current to allow custom properties to be seen on the UI.  They need to be included in the detail section.   On the Alert view it possible to create view like in webgui to show that column of data, 

if you go to an incident or the alert page, there the view button which you can press see below. 

that will take you to the view build

i add column something, when you save it,

it will show up, in the alert list.  

On the impact policy let talk on a Webex, as the devil in the detail, as some policy many not need to change, depending on where they are in a lifecycle, and what function they are doing 

Thank you for the very detailed response.

Yes, we have automations that are implemented partly via Impact policies and partly via triggers.

The original alarm is enriched by specific enrichment policies that add more personalized information.

Currently, there are dozens of custom fields in ObjectServer. Some of these fields are currently important for the operation team to identify the problem. For example, one of these fields informs the geographic location of the equipment using GPS coordinates.

How can we present this type of information on the operator console?

How can we incorporate more information into the alerts console?

Furthermore, there are automations external to Netcool that consult information directly from the ObjectServer to assist in troubleshooting Netcool as a whole.

From what we are realizing, the procedures developed over more than ten years will have to be reviewed to be implemented in AIOPs. We believe that most of these procedures are not easy to implement in AIOPs.

The expectation is that the transition from Netcool to AIOPs will be slow and that we will have to keep the current on-premises environment functional for a long period of time.

Antonio

AIop's and Netcool omnibus are slightly different, in terms of how you manage them.  Internally AIOps has multiple datastore which have to be kept in sync, therefore direct modifications of datastores is not advised due to data synchronisation issues. Therefore interaction and modification of the system is done via well-defined API's.( https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=apis-issue-resolution-api)   In AIops thing like object server trigger are no longer present. 

The structure of AIops alerts is different to a Netcool alert.  This allows more reasoning about the nature of the data.  In AIops things like String limits, Object Server Row size limit, and having to up front add a column to the object server is no longer need.

Link to the AIops alert schema

https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=schemas-alerts-events-schema-fields

Aiops can consume alerts from an object server  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-tivoli-netcoolomnibus-connections) or https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-probe-common-tasks to connect probes directly to the AIops internal object server (FYI it not a normal object server, so customer cannot add triggers etc to it)

It sounds like you have developed automation that act on the events, it depends on what component you have encoded that logical in.  If the logic is within object server triggers the that logic cannot be directly applied.   If that logic in impact policy AIops can call impact policy.  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=policies-invoke-impact-policy) .  If that logic is contained in object server trigger, it might be worth considering connected you on prem object server with the custom logic in to aiops via the Netcool connector.   This will allow you to reuses that logic, but take the befits of AIops features.

Hi Jonathan,

Could you explain how to add a custom column to AIOPS like the "something" column that you mentioned.

Thanks,

Hi 

I sent you a private message, i think we should get together and talk specifics, that will be the best way to answer your question.  Thought to a general point so help other people that come across this message.   In aiops you can add field to alert by just included them, at current to allow custom properties to be seen on the UI.  They need to be included in the detail section.   On the Alert view it possible to create view like in webgui to show that column of data, 

if you go to an incident or the alert page, there the view button which you can press see below. 

that will take you to the view build

i add column something, when you save it,

it will show up, in the alert list.  

On the impact policy let talk on a Webex, as the devil in the detail, as some policy many not need to change, depending on where they are in a lifecycle, and what function they are doing 

Thank you for the very detailed response.

Yes, we have automations that are implemented partly via Impact policies and partly via triggers.

The original alarm is enriched by specific enrichment policies that add more personalized information.

Currently, there are dozens of custom fields in ObjectServer. Some of these fields are currently important for the operation team to identify the problem. For example, one of these fields informs the geographic location of the equipment using GPS coordinates.

How can we present this type of information on the operator console?

How can we incorporate more information into the alerts console?

Furthermore, there are automations external to Netcool that consult information directly from the ObjectServer to assist in troubleshooting Netcool as a whole.

From what we are realizing, the procedures developed over more than ten years will have to be reviewed to be implemented in AIOPs. We believe that most of these procedures are not easy to implement in AIOPs.

The expectation is that the transition from Netcool to AIOPs will be slow and that we will have to keep the current on-premises environment functional for a long period of time.

Antonio

AIop's and Netcool omnibus are slightly different, in terms of how you manage them.  Internally AIOps has multiple datastore which have to be kept in sync, therefore direct modifications of datastores is not advised due to data synchronisation issues. Therefore interaction and modification of the system is done via well-defined API's.( https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=apis-issue-resolution-api)   In AIops thing like object server trigger are no longer present. 

The structure of AIops alerts is different to a Netcool alert.  This allows more reasoning about the nature of the data.  In AIops things like String limits, Object Server Row size limit, and having to up front add a column to the object server is no longer need.

Link to the AIops alert schema

https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=schemas-alerts-events-schema-fields

Aiops can consume alerts from an object server  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-tivoli-netcoolomnibus-connections) or https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-probe-common-tasks to connect probes directly to the AIops internal object server (FYI it not a normal object server, so customer cannot add triggers etc to it)

It sounds like you have developed automation that act on the events, it depends on what component you have encoded that logical in.  If the logic is within object server triggers the that logic cannot be directly applied.   If that logic in impact policy AIops can call impact policy.  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=policies-invoke-impact-policy) .  If that logic is contained in object server trigger, it might be worth considering connected you on prem object server with the custom logic in to aiops via the Netcool connector.   This will allow you to reuses that logic, but take the befits of AIops features.

Mohamed, I think this blog will help with what you're trying to accomplish. Cloud Pak for AIOps 4 tips: mapping Netcool/OMNIbus custom fields to AIOps (ibm.com)

Hi Jonathan,

Could you explain how to add a custom column to AIOPS like the "something" column that you mentioned.

Thanks,

Hi 

I sent you a private message, i think we should get together and talk specifics, that will be the best way to answer your question.  Thought to a general point so help other people that come across this message.   In aiops you can add field to alert by just included them, at current to allow custom properties to be seen on the UI.  They need to be included in the detail section.   On the Alert view it possible to create view like in webgui to show that column of data, 

if you go to an incident or the alert page, there the view button which you can press see below. 

that will take you to the view build

i add column something, when you save it,

it will show up, in the alert list.  

On the impact policy let talk on a Webex, as the devil in the detail, as some policy many not need to change, depending on where they are in a lifecycle, and what function they are doing 

Thank you for the very detailed response.

Yes, we have automations that are implemented partly via Impact policies and partly via triggers.

The original alarm is enriched by specific enrichment policies that add more personalized information.

Currently, there are dozens of custom fields in ObjectServer. Some of these fields are currently important for the operation team to identify the problem. For example, one of these fields informs the geographic location of the equipment using GPS coordinates.

How can we present this type of information on the operator console?

How can we incorporate more information into the alerts console?

Furthermore, there are automations external to Netcool that consult information directly from the ObjectServer to assist in troubleshooting Netcool as a whole.

From what we are realizing, the procedures developed over more than ten years will have to be reviewed to be implemented in AIOPs. We believe that most of these procedures are not easy to implement in AIOPs.

The expectation is that the transition from Netcool to AIOPs will be slow and that we will have to keep the current on-premises environment functional for a long period of time.

Antonio

AIop's and Netcool omnibus are slightly different, in terms of how you manage them.  Internally AIOps has multiple datastore which have to be kept in sync, therefore direct modifications of datastores is not advised due to data synchronisation issues. Therefore interaction and modification of the system is done via well-defined API's.( https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=apis-issue-resolution-api)   In AIops thing like object server trigger are no longer present. 

The structure of AIops alerts is different to a Netcool alert.  This allows more reasoning about the nature of the data.  In AIops things like String limits, Object Server Row size limit, and having to up front add a column to the object server is no longer need.

Link to the AIops alert schema

https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=schemas-alerts-events-schema-fields

Aiops can consume alerts from an object server  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-tivoli-netcoolomnibus-connections) or https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=integrations-probe-common-tasks to connect probes directly to the AIops internal object server (FYI it not a normal object server, so customer cannot add triggers etc to it)

It sounds like you have developed automation that act on the events, it depends on what component you have encoded that logical in.  If the logic is within object server triggers the that logic cannot be directly applied.   If that logic in impact policy AIops can call impact policy.  (https://www.ibm.com/docs/en/cloud-paks/cloud-pak-aiops/4.2.1?topic=policies-invoke-impact-policy) .  If that logic is contained in object server trigger, it might be worth considering connected you on prem object server with the custom logic in to aiops via the Netcool connector.   This will allow you to reuses that logic, but take the befits of AIops features.