Ding ding... It's 3 am and your phone has just sent you multiple P1 alerts. Your site is down and you need to find out what the issue is and fast, but your log data is all over the place, metrics on your services are sub par and it's really hard to know where to go to find the issue. What if there was a way to leverage AI to help you make sense of your data in a clear and concise way, making your 3 am alert wake up call a walk in the park? This is exactly what our guest, David Wynn, is doing at Edge Delta, an automated observability platform that monitors your services, alerts you when something is wrong, and guides root-cause analysis. Today, we dive into observability; what it is, the data pieces that make up this ecosystem, tips on how to start your data collection journey, ways our guest is integrating AI with human expertise to enhance system observability and more.

David received his Bachelor of Science degree in Economics from Duke University and with over 15 years in the industry he has worked at companies like Intapp, Sumo Logic and formerly was Head of Solutions at Google Cloud for Games. Currently, a Principal Solution Architect for Edge Delta, an automated observability startup, he applies his visionary approach to automated observability, ensuring systems are not only monitored but also intelligently guided through root-cause analysis when issues arise.

When our guest is not making your production monitoring a breeze, he is reading philosophy and participating in the vibrant geek culture in Atlanta attending events like DragonCon. In his LinkedIn profile he calls himself the “People Machine Liaison”, enjoy the conversation!

Connect with David:

Sponsor:

Get Space: Are your engineers happy? Productive? Install Get Space’s real-time survey iteration tool now with code buildwithpeople and get 20% off your first year to find out real insights about your engineers experience.

Show notes and helpful resources:

Definition of observability: Understanding what the system is doing and whether it's doing what it's intended
Three pillars of observability are Logs, Metics and Traces
Logs are like notes to yourself from the code, and are only as structured and useful as the notes you write
Metrics are numbers, usually counts or measurements, that represent what you want to track
Traces tie together the different components of a distributed system into one object, capturing the flow and timing of a transaction or operation
Events are narrative-level components that describe key occurrences in the environment
MELT is the acronym for Metrics, Events, Logs, and Traces
Context as a 4th pillar

Three layers of Context; 1. Team context (developers, what maps to code), 2. Architecture context (how services are architected), 3. Business intent context (what the system is supposed to do)
Collection is step number 1 - getting the data into a place where you can understand it
Automated observability: Makes the collection process easier by automating aspects of it and makes the analysis process easier by using techniques like clustering algorithms

Edge Delta uses the k-means clustering algorithm to group similar events and apply sentiment analysis to identify issues.
Engineers should focus on understanding and implementing the business requirements correctly, as that will lead to better observability signals

Large Language Models (LLMs) are not reasoning machines; they are associativity machines that cannot truly understand or reason about concepts
Reality has a surprising amount of detail article - by John Salvatier

ReBoot cartoon - The main character Bob acts as the Guardian of Mainframe. Correction from the episode: he has a keytool named Glitch (not Gadget as mentioned) that he wears on his left wrist

Building something cool or solving interesting problems? Want to be on this show? Send me an email at jointhepodcast@unfilteredbuild.com

Podcast produced by Unfiltered Build - dream.design.develop.