Leveraging Redis for System Monitoring by Adam McCormick of SBG - Redis Day Seattle 2020
•Download as PPTX, PDF•
0 likes•170 views
The document discusses how Sinclair Broadcast Group leverages Redis for system monitoring of its content delivery network. It operates 193 news stations with 10,000 active pages daily and millions in archive. New stories are posted every 15 seconds and must be visible across its 1,000+ targets within 1 minute. Redis is used to track performance across the multi-level CDN and ensure service level agreements are met with real-time resolution and alerting. It provides a black box view of the audience experience and can scale monitoring to all relevant pages within 30 seconds. Redis acts as a distributed data store to parallelize the monitoring task across the large scale of the network.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Leveraging Redis for System Monitoring by Adam McCormick of SBG - Redis Day Seattle 2020
Similar to Leveraging Redis for System Monitoring by Adam McCormick of SBG - Redis Day Seattle 2020 (20)
More from Redis Labs
More from Redis Labs (20)
Recently uploaded
Recently uploaded (20)
Leveraging Redis for System Monitoring by Adam McCormick of SBG - Redis Day Seattle 2020
- 1. PRESENTED BY Leveraging Redis for System Monitoring Adam McCormick Senior Principle Engineer, Sinclair Broadcast Group sinclairdigital.com
- 2. PRESENTED BY 1 Background Isn’t monitoring a simple thing? 2 Problems Why would the business care? 3 Architecture How do we deal with enforcing SLAs at this kind of scale? Agenda: 4 Lessons Learned What’s the payoff?
- 3. PRESENTED BY Sinclair Broadcast Group operates 193 News Stations •That’s 10,000 active pages every day and several million pages in our archive •New stories are posted every 15 seconds One CMS system which can syndicate any piece of content to any of 1,000+ targets • A single story may be seen on as many as 600 locations across our content network Every change must be visible to the audience in 1 minute • Highly-Cached distribution architecture • Burst-heavy content consumption and production Background
- 4. PRESENTED BY Two core needs: •Are we meeting our SLA (1 minute from producer to audience)? •What is happening RIGHT NOW (And should it be National)? SLA Enforcement • Must account for multi-level CDN and N-Tier architecture • Resolution and alerting within the SLA Syndication • Can we leverage real-time publish data to surface important data? Problems
- 5. PRESENTED BY Operate from the Audience’s viewpoint (black box) •No cache breaking, no specialized headers, cache-inclusive Scale to hit all relevant pages • 10,000 pages within 30s to guarantee SLA Publish all updates • Roughly 4-5 per minute at peak from several million possible targets Architecture
- 6. PRESENTED BY The only question is, how many monitors? Architecture
- 9. PRESENTED BY Pain is proportional to time spent •If we had known how much intervention a self-hosted solution would require, we would have waited for a hosted solution Redis was more than a cache •Parallelizing a monitoring task is really a data problem •It’s tempting to think of Redis as a cache, but if you view it as a distributed data store, it opens up a serverless universe Don’t overthink your data •Think of Redis like you think of a HashMap Lessons Learned
- 10. Thank You!
- 11. PRESENTED BY Leveraging Redis for System Monitoring Adam McCormick Senior Principle Engineer, Sinclair Broadcast Group https://sinclairdigital.com