Shadow Analytics via Redis Replica

About the Organization

<p>*APPLICATION ONLY OPEN TO STUDENTS IN INDIA*</p><p><br></p><p><strong>Problem Statement</strong></p><p><br></p><p>SONiC is a database-centric NOS: much of the control-plane and operational state is available in Redis, and telemetry can poll/subscribe to DB data. There are a variety of interesting analytics and telemetry data that can be extracted from this DB, many by leveraging Redis capabilities. However, directly adding heavy analytics (e.g., long-running server-side scripts) to the primary Redis risks impacting normal SONiC applications. Redis Lua scripts execute atomically but block the server for the full runtime of the script. This project proposes a low-risk pattern: create a Redis replica (master → replica) that maintains a synchronized copy of selected SONiC databases, and run the analytics plane on the replica.&nbsp;</p><p><br></p><p><strong>Mentorship Objectives</strong></p><p><br></p><ul><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Design and prototype a “shadow analytics plane” using Redis replication (master → replica) so normal SONiC apps continue to use the primary Redis instance unchanged. Design and implement cold boot, Warmboot and fast-boot.</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Implement use-cases, some examples”</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Incident Forensics (A): Build a flight-recorder capability on the replica that can reconstruct recent sequences of “interesting” changes (timeline) and provide a compact incident summary.</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Alert Storm Reduction (B): Build novelty detection and heavy-hitter summarization on the replica to suppress repeated alerts and highlight top recurring signatures.</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Provide operational documentation: how to deploy, how to tune retention/limits, and how to validate that primary-path performance is not affected.</span></li></ul><p><br></p><p><br></p><p><strong>Recommended Qualifications</strong></p><p><br></p><ul><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Strong Linux fundamentals; comfortable working in containerized environments.</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Python and/or Go proficiency (for collectors, processors, and CLI tooling).</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Basic understanding of Redis concepts (pub/sub, streams, replication) and willingness to learn SONiC DB schemas.</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Interest in reliability engineering / observability / operational tooling.</span></li></ul><p><br></p>