• Gmail via the Email Connector
• Google Chat and Slack via the Webhook Connector.

{"text": "Message from Kibana Connector"}

{"text": "Message from Kibana Connector"}

"webhook_googlechat": {
 "webhook": {
 "scheme": "http",
 "host": "169.254.16.1",
 "port": 8000,
 "method": "post",
 "params": {},
 "headers": {},
 "body": """{"request_body": "{\"text\": \"The Elasticsearch cluster status is {{ctx.payload.status}}.\"}","kibana_webhook_connector": "<google-chat-webhook-connector-name>"}"""
 }

• Add a webhook action with the following fields to select Google Chat and Slack Webhook Connectors.
  • Method: POST
  • Scheme: HTTP
  • Host: 169.254.16.1
  • Port: 8000
  • Specify the Body field as follows:
    • kibana_webhook_connector: The name of the Kibana connector (of type webhook) in string format. It is case-sensitive.
    • request_body: Enter the required fields: The connector gets the HTTP request body (in string format as text).
      Note: request_body value is specific to the connector’s specification.

"{\"text\": \"The Elasticsearch cluster status is {{ctx.payload.status}}.\"}"

{
 "trigger": {
 "schedule": {
 "interval": "1h"
 }
 },
 "input": {
 "http": {
 "request": {
 "scheme": "https",
 "host": "10.10.10.10",
 "port": 443,
 "method": "get",
 "path": "/es/api/_cluster/health",
 "params": {},
 "headers": {
 "Content-Type": "application/json"
 },
 "auth": {
 "basic": {
 "username": "admin",
 "password": "::es_redacted::"
 }
 }
 }
 }
 },
 "condition": {
 "script": {
 "source": "ctx.payload.status != 'green'",
 "lang": "painless"
 }
 },
 "actions": {
 "webhook_googlechat": {
 "webhook": {
 "scheme": "http",
 "host": "169.254.16.1",
 "port": 8000,
 "method": "post",
 "params": {},
 "headers": {},
 "body": """{"request_body": "{\"text\": \"The Elasticsearch cluster status is {{ctx.payload.status}}.\"}","kibana_webhook_connector": "BSN-Analytics-AppTest-GH-connector"}"""
 }
 }
 }
}

• text: (mandatory)
• channel : (optional) The channel name must match the same Slack channel for which the webhook is enabled.
• username: (optional) You can select any username.

"{\"channel\": \"test-channel\", \"username\": \"webhookbot\", \"text\": \"The Elasticsearch cluster status is {{ctx.payload.status}}.\"}"

{
 "trigger": {
 "schedule": {
 "interval": "1m"
 }
 },
 "input": {
 "http": {
 "request": {
 "scheme": "https",
 "host": "10.10.10.1",
 "port": 443,
 "method": "get",
 "path": "/es/api/_cluster/health",
 "params": {},
 "headers": {
 "Content-Type": "application/json"
 },
 "auth": {
 "basic": {
 "username": "admin",
 "password": "::es_redacted::"
 }
 }
 }
 }
 },
 "condition": {
 "script": {
 "source": "ctx.payload.status != 'green'",
 "lang": "painless"
 }
 },
 "actions": {
 "webhook_slack": {
 "webhook": {
 "scheme": "http",
 "host": "169.254.16.1",
 "port": 8000,
 "method": "post",
 "params": {},
 "headers": {},
 "body": """{"request_body": "{\"channel\": \"test-webhook\", \"username\": \"webhookbot\", \"text\": \"The Elasticsearch cluster status is {{ctx.payload.status}}.\"}","kibana_webhook_connector": "test-slack-webhook-connector"}"""
 }
 }
 }
}

• Check Kibana Connector, which is a type of Webhook.
• Check that the Kibana Connector is properly configured by running tests from UI. Check connector-specific configurations.
• Check for properly configured Watcher’s trigger conditions.
• Make sure all required parameters are present in the connector's watcher configuration.
• To debug execution in CLI:
  • SSH to AN node
  • Log in to CLI mode command: debug bash
  • Review logs in /var/log/analytics/webhook_listener.log for any clues. Command: tail -f /var/log/analytics/webhook_listener.log
  • To execute service in debug mode:
    • Login as root command: sudo su
    • Stop service command: service webhook-listener stop.
    • Edit web-service in your preferred editor and set the logger to debug mode command: vi /usr/lib/python3.9/site-packages/webhook_listener/run_webhook_listener.py Change Line: LOGGER.setLevel(logging.INFO) to LOGGER.setLevel(logging.DEBUG).
    • Start service command: service webhook-listener start.

• Latency Records By Flows: The pie chart represents the proportions of flow latency summed. The inner circle displays source IP addresses, the middle circle displays destination IP addresses, and the outermost circle displays destination ports.
• Latency over time By Flows: The line chart represents the maximum Latency in nanoseconds (ns) over time, split by each flow between source IP and destination IP addresses.
• Observation Point Selector (A > B or DiffPair): Use the drop-down menus to filter by A > B pair or DiffPair. The point B selector is dependent on point A.
• Top Latencies By A > B Pair: The pie chart shows the Latency max summed by A > B Points. The inner circle displays the source A tap point, while the outer circle displays the B destination tap point.
• Latency over time By A > B Pair: The line chart represents the maximum Latency in nanoseconds (ns) over time, split by each A > B pair between the source tap point and destination tap point.
  

• Drop Records By Flows: The pie chart represents the proportions of drop packets for each flow summed. The inner circle displays source IP addresses, the middle circle displays destination IP addresses, and the outermost circle displays destination ports.
• Max Drops By Flows: The line chart represents the maximum number of drop packets, separated by each flow between source IP and destination IP addresses. If fewer data points exist, the chart displays them as individual points instead of complete lines.
• Observation Point Selector (A>B or DiffPair): Use the drop-down menus to filter by A > B pair or DiffPair. The point B selector is dependent on point A.
• Top Drop A>B: The heat map displays the drop of packets summed by A > B Points. The map plots the source tap point, A, on the vertical axis and the destination tap point, B, on the horizontal axis.
• Top Dropping A>B Pairs: The bar chart represents the sum of drop packets over time, separated by each A > B pair between the source and destination. It shows the Top 10 available dropping A > B pairs.

  

• It provides a dashboard for packet drops between points A and B(s), either split by flows in between those points (Top) or filtered by A > B pairs (bottom) as selected. View the diff records at the bottom of the dashboard.
• Select individual data points in the visualization for further analysis.
• Selecting DiffPairs can provide a similar visualization perspective. Choose one or more DiffPairs for analysis.

  

• Arista_NetOps_Drop_Differ_Watch
• arista_NetOps_Latency_Differ_Watch

1. Navigate to Stack Management > Connector.
2. Under Configuration for the SMTPForAlerts Connector, specify the Senderand Service field values.
3. Email alerts may require authentication based on the type of mail service selected.
4. Test and validate the settings using the Test tab.

   

• arista_NetOps_Drop_Differ_Watch:
  1. It configures the watcherto send an alert when the maximum drop count of packets in NetFlow in the last 5-minute interval exceeds the historical average (last 7-day average) of drop of packets by a threshold percentage.
  2. By default, it configures the watcher to be triggered every 10 minutes.
  3. As this may be incorrect for all flows combined, configure it for a particular Flow and Destination Port.
  4. Search for CHANGE_ME in the watcher and specify the flow and destination port value (introduced to correctly compare each flow and destination port individually instead of comparing all flows together).
  5. Specify the percentage_increase parameter in the condition using a positive value between 0-100.
  6. Enter the recipient's email address receiving the alert.
  7. Select Save watch.

     

      

     

      

     

• arista_NetOps_Latency_Differ_Watch:
  1. It configures the watcher to send an alert when NetFlow's maximum latency (or lag) in the last 5-minute interval exceeds the historical average (last 7-day average) latency by a threshold percentage.
  2. By default, it configures the watcher to be triggered every 10 minutes.
  3. As this may be incorrect for all flows combined, configure it for a particular Flow and Destination Port.
  4. Search for CHANGE_ME in the watcher and specify the flow and destination port value (introduced to correctly compare each flow and destination port individually instead of comparing all flows together).
  5. Specify the percentage_increase parameter in the condition using a positive value between 0-100.
  6. Enter the recipient's email address receiving the alert.
  7. Select Save watch.

• Policy configured to filter for SIP traffic (UDP port 5060) such that low-rate traffic (< 1Gbps) is delivered to AN via collector interface with a filter on the Layer 4 port number or User Defined Field (UDF).
• LAG will send SIP Control Packets to 1, 3, and 5 AN Nodes with symmetric hashing enabled and without hot-spotting.
• Recorder Node to receive SIP and Control packets recorded with standard key fields.

• There is no toggle switch to turn this feature on or off.

• Verify records are arriving for sFlow^® on the home page of the Analytical Node.
• In Kibana Discover, select data-view flow-sflow-* to determine if any records are arriving.
• Check the agt field to see if the switch sends sFlow, and the AN parses and shows records.
• Verify the records contain fields proto, eType, dP, sP. These are the fields required by this feature to categorize tType to MPLS, GRE, GTP, IPinIPv4, IPinIPv6, and VXLAN.

• Verify records are arriving for sFlow^® on the home page of the Analytical Node.
• In Kibana Discover, select data-view flow-sflow-* to determine if any records are arriving.
• Check the agt field to see if the switch sends sFlow, and the AN parses and shows records.
• Verify the records contain field drops & discard_reason.