Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Background

  1. Upon the peak memory utilisation of all the existing nodes in punjab cluster and implementation team's demand to match the need of the load, had to resize the cluster by adding better nodes. Of course upon customer approval & Demand.
    1. Punjab cluster resizing activity, causing customer dashboard to loose its visualisation and dashboard.
  2. While there was a peak load, the DB was bottleneck due to long running queries that cascaded into APIs and the system was slow.
    1. We had to fix the queries  

Retrospective

CLUSTER:

  • Though the cluster resize task as was successful, stateful pods (es-cluster) the way it is configured and the way kubernetes manages via headless service discovery resulted in ES-MASTER PODS being not connecting to each other, by the time the DevOps team troubleshoot and recover the ES-MASTER, Kibana lost its visualisation and dashboard indexes.
  • No impact to the ES-Data, but kibana as lost its dashboard and visualisation indexes. 

DB:

  • APIs were slow during the peak load from the punjab system.
  • Reports were taking much of the DB capacity due the inefficient joins, non-indexed data and Nested loop queries to DB, etc.
    • We fixed DB Queries and brought down the 
Start doingStop doingKeep doing
  • Publish strategy plan before the actual implementation
  • Any production change should be tried in UAT first.
  • Take Kibana Indexes backup periodically into GitHub
  • Need to perform 
    • Chaos Testing and resiliency testing on ES, Kafka
  • DB Script review cadence
  • DB query check-in without review
  • Saying no to on-the-fly requests
  • No to friendly requests, enforce Ops Tickets.
  • Keep 3 master quorum format for ES, Kafka in production

Action items


  • No labels