EducationSoftwareStrategy.com
StrategyCommunity

Knowledge Base

Product

Community

Knowledge Base

TopicsBrowse ArticlesDeveloper Zone

Product

Download SoftwareProduct DocumentationSecurity Hub

Education

Tutorial VideosSolution GalleryEducation courses

Community

GuidelinesGrandmastersEvents
x_social-icon_white.svglinkedin_social-icon_white.svg
Strategy logoCommunity

© Strategy Inc. All Rights Reserved.

LegalTerms of UsePrivacy Policy
  1. Home
  2. Topics

Kafka cluster health check fails in MicroStrategy 2021 with the error "Group coordinator lookup failed: The coordinator is not available."


Jing (Sally) Cheng

Senior Principal Consultant • MicroStrategy


This article provides a workaround for the Kafka health check error "Group coordinator lookup failed: The coordinator is not available."

Symptom


Users are unable to start the Platform Analytics Consumer in Strategy 2021 when the Platform Analytics health check fails with the error:
Group coordinator lookup failed: The coordinator is note available. 
The health check logs display the following information:

06/24/2019 11:22:23.983 INFO Producing health check data to 3 partitions of Kafka topic - 'mstr-pa-health-check' ...06/24/2019 11:22:24.014 INFO Configuring consumer for reading data from topic - 'mstr-pa-health-check' ...06/24/2019 11:23:24.030 ERROR Timeout of 60000ms expired before successfully committing offsets {mstr-pa-health-check-2=OffsetAndMetadata{offset=18, metadata=''}}06/24/2019 11:23:24.036 INFO Kafka cluster health check result is unhealthy.************************************************************************************************************* Health Check Summary ********************************* Platform Analytics MySQL Warehouse PASSPlatform Analytics Redis Server PASSPlatform Analytics Kafka Cluster FAIL

When the logging level is changed to debug, the Telemetry Store logs display the following:
2019-07-01 07:25:18,704 DEBUG AbstractCoordinator:651 main - [Consumer clientId=consumer-4, groupId=health-check] Sending FindCoordinator request to broker akl0ap8h2.corp.ad.airnz.co.nz:9092 (id: 1 rack: null)2019-07-01 07:25:18,705 DEBUG NetworkClient:472 main - [Consumer clientId=consumer-4, groupId=health-check] Using older server API v1 to send FIND_COORDINATOR {coordinator_key=health-check,coordinator_type=0} with correlation id 963 to node 12019-07-01 07:25:18,705 DEBUG AbstractCoordinator:662 main - [Consumer clientId=consumer-4, groupId=health-check] Received FindCoordinator response ClientResponse(receivedTimeMs=1561922718705, latencyMs=0, disconnected=false, requestHeader=RequestHeader(apiKey=FIND_COORDINATOR, apiVersion=1, clientId=consumer-4, correlationId=963), responseBody=FindCoordinatorResponse(throttleTimeMs=0, errorMessage='null', error=COORDINATOR_NOT_AVAILABLE, node=:-1 (id: -1 rack: null)))2019-07-01 07:25:18,705 DEBUG AbstractCoordinator:685 main - [Consumer clientId=consumer-4, groupId=health-check] Group coordinator lookup failed: The coordinator is not available.2019-07-01 07:25:18,705 DEBUG AbstractCoordinator:242 main - [Consumer clientId=consumer-4, groupId=health-check] Coordinator discovery failed, refreshing metadata2019-07-01 07:25:18,805 DEBUG NetworkClient:1018 main - [Consumer clientId=consumer-4, groupId=health-check] Sending metadata request (type=MetadataRequest, topics=mstr-pa-health-check) to node akl0ap8h4.corp.ad.airnz.co.nz:9092 (id: 3 rack: null)  

 

Cause


The Kafka server broker ID is different from the output.
For example, say the broker ID for a clustered environment is

1
,
 2
, and
3
, which can be confirmed by checking the Kafka configuration file, server.properties.
However, when you run the command
 ./bin/window/kafka-topics.bat --describe --zookeeper localhost:2181
, the output displays the Leader's ID as
0
, which means it can't match to the broker of the environment.

Correct Output

ka0PW0000000rCPYAY_0EM2R000000lPEr.jpeg

Incorrect Output

ka0PW0000000rCPYAY_0EM2R000000lPEw.jpeg

This situation can happen when there is an existing Kafka and Zookeeper service in the C:\Program Files (x86)\MicroStrategy\Messaging Services\tmp folder. These services may exist if a user created a one node environment at first to test the service using the Strategy installer. When you use the installer, the default broker ID is set to

0
, so all the
_consumer_offsets
Leader IDs are
0
.
After creating a test node, users sometimes create a clustered environment and include the original test node, so the Strategy installer would set the new nodes with the broker IDs of
1
,
2
, and
3 
(since the broker ID
0
is already in use). 
After creating the clustered environment, if the original data from the first node is not deleted from C:\Program Files (x86)\MicroStrategy\Messaging Services\tmp, the Kafka service will start by reading the topic information from the historical data file and thus provide the wrong Leader ID.
 

Workaround


To fix the output, perform the following steps:

  1. On Windows, open Services and stop the Kafka and Zookeeper services.
  2. Navigate to the Messaging Services installation path. The default path is C:\Program Files (x86)\MicroStrategy\Messaging Services\tmp.
  3. Delete the kafka-logs folder.
  4. Navigate to C:\Program Files (x86)\MicroStrategy\Messaging Services\tmp\zookeeper.
  5. Delete the version-2 folder.
    Note: Do not delete the myid file from the \Messaging Services\tmp\zookeper folder.
  6. Open Services and restart the Kafka and Zookeeper services. The Telemetry Store should start normally.


For more information on Platform Analytics workarounds, Troubleshooting: How to Check Platform Analytics Services or see the Platform Analytics guide.


Comment

0 comments

Details

Knowledge Article

Published:

July 19, 2019

Last Updated:

February 26, 2024