Monitoring streaming to an Event Streams instance

Monitoring streaming by using IBM Cloud Monitoring

Event Streams is integrated with the Monitoring service. Monitoring provides a default template that you can customize to monitor the Event Streams instance, how data is streamed out of Activity Tracker and consumed by any application or service that is subscribed to Event Streams.

Complete the following steps to monitor the Event Streams instance:

1. Check that you have an instance of the Monitoring in the same region as your Event Streams instance. This instance must be configured to collect platform metrics. For more information, see Enabling platform metrics.

2. Launch the Monitoring UI.

3. In the Dashboards section, go to Dashboard templates and select the template IBM > IBM Event Streams (Enterprise).

4. Create a copy of the template by clicking Create custom dashboard.

   You can use the metric Topic bytes in per second to see how data is sent by Activity Tracker to Event Streams.

   You can use the metric Topic bytes out per second to see how data is consumed by any application or service that is subscribed to Event Streams.

5. (Optional) Edit the panel Topic bytes in per second.

   

   Then, customize the metric to see data per topic.

   

   Check that the resolution is set to 10M.

Monitoring streaming by using IBM Cloud Activity Tracker

Streaming generates Activity Tracker events with the action logdnaat.streaming-logs.send to notify about failures that occur when data is streamed to Event Streams.

There are different reasons for failure, for example:

• unknown_topic or unknown_topic_or_partition: This notification reports that the topic that is configured for streaming is not valid.

  If you get this notification, check the topic that is configured for streaming is defined in Event Streams.

• broker_handle_destroyed: This notification reports a change in the Kafka cluster configuration.

  If you get this notification, check the SASL URLs and update the streaming configuration.

• authentication_failure: This notification reports a failure to authenticate with Event Streams.

  If you get this notification, check the credentials that are configured for streaming.

• broker_transport_failure: This notification reports connectivity problems with Event Streams. There are different reasons why you might get this notification such as that credentials were deleted after streaming was activated and started.

• message_timed_out or timed_out: This notification reports generic timeout errors when streaming messages to Event Streams.

The Activity Tracker event includes different fields that you can use to monitor streaming data failures:

• reason.reasonCode = 500 and severity = critical notify of a failure streaming data.
• reason.reasonType indicates the type of failure.
• target.typeURI = logdna/account/streaming-notification indicates that the event is a notification event.

The following sections include samples of some fields in the notification event that you can use to monitor and be alerted when a failure happens:

"requestData": {
        "notificationType": "unknown_topic_or_partition",
        "start": "2021-06-29T21:33:52.333Z",
        "end": "2021-06-29T21:35:13.772Z",
        "topic": "kafka-java-console-sample-topic",
        "error": "Error: Broker: Unknown topic or partition"
    },

"reason": {
        "reasonCode": 500,
        "reasonType": "unknown_topic_or_partition",
        "reasonForFailure": "Error: Broker: Unknown topic or partition"
    },

"target": {
        "id": "crn:v1:staging:public:logdna:us-south:a/9bb3ea01633c4d828080de16ce34ea70:d8ba830f-b0e0-4c42-9345-8981d4a94b31:streaming-logs:",
        "typeURI": "logdna/account/streaming-notification"

action:logdnaat.streaming-logs.send reason.reasonCode:500 severity:critical target.typeURI:"logdna/account/streaming-notification"

action:logdnaat.streaming-logs.send reason.reasonCode:500 severity:critical target.typeURI:"logdna/account/streaming-notification" requestData.notificationType:"authentication_failure"