ISW - Wizard Step: Input Diagnostics

[grotlue]

Issue for building the diagnostics page.

• Shows a status of the input with
  • Input name
  • Input description (stretch goal)
  • node it is running on
  • input specific details (only for listener inputs)
    • bind address (if available)
    • port (if available)
    • show info copy to check if UCP or TCP
• Shows a button "Show Received Messages"
  • clicking on it will forward you to the search page
  • already exists:

Input Test Results

Metrics:

• if any metric does not exist we show 0
• we will use the fifteen_minute property of the metrics rate object
• the metrics are automatically refetched every 5 seconds
• we will show an UI element that can manually trigger a refresh of the metrics
• Throughput (already exists):
• Message error at input
• Message failed to process
• Message failed to index
• Input state and detailed message(already exists in input state)
  • We show a summary of existing states of all nodes of this input (e.g.: FAILED: 2/10, RUNNING: 8/10)
    • When clicking on each state, the list expands, showing the related node ids
    • if a detailed message exists, the node id can be clicked to show it
• Messages received by input count
  • Descriptional text of that this metric represents
• Streams count and stream names ( count query for gl2_source_input and stream)

Mock-Up

[grotlue]

To show the input name and a type specific description we will need an additional call returning input name and description based on a given type.

[grotlue]

@AntonEbel Do you know if we have the information TCP or UCP for listener inputs? bind address and port I can find in the form.

[AntonEbel]

@grotlue No, we do not provide this information and do not persist it. I don't know if we want to display this explicitly because the TCP/UDP protocol is already included in the Input Type name.

[patrickmann]

Agree with @anton that there is not a lot of value in adding the TCP/UDP detail.

We can use existing metrics APIs for all of the numbers. So what is left that backend needs to expose? This part seems to have some new information:

We show a summary of existing states of all nodes of this input (e.g.: FAILED: 2/10, RUNNING: 8/10)
When clicking on each state, the list expands, showing the related node ids
if a detailed message exists, the node id can be clicked to show it
Messages received by input count ( Opensearch count query for gl2_source_input)
Streams count and stream names ( count query for gl2_source_input and stream)

[grotlue]

@grotlue No, we do not provide this information and do not persist it. I don't know if we want to display this explicitly because the TCP/UDP protocol is already included in the Input Type name.

Agree with @anton that there is not a lot of value in adding the TCP/UDP detail.

@tellistone What is your take on the TCP/UDP detail?

[tellistone]

could be replaced with a line of ui copy reminding the user to check they are using the right one re: TCP/UDP

Users trip over this a surprising amount (perhaps because the app gives no feedback when this is happening)