Monitoring at scale: continuous monitoring

Editor's Notes

• #5: Who is kCura? We’re a fast-growing Chicago-based software company, tackling big data challenges for users spanning the globe. What do we do? We’re the developers of the e-discovery software, Relativity, which is used for managing large volumes of electronic evidence during litigation and investigations. Statistics to use: If you’d like to speak about the size of the Relativity Community: More than 130,000 active users More than 11,000 unique organizations using Relativity 218 enterprise clients 127 channel partners Used by 99 of the Am Law 100 and 197 of the Am Law 200. Used by 70 of the Fortune 100 If you’d like to speak about the large volumes of electronic data managed in Relativity: There are 67 billion files under management in Relativity. Largest case to date involves 750 million documents.   If you’d like to speak about the international growth of Relativity: 127 of our clients are international. Relativity is being used in 43 countries.
• #6: In this presentation we will talk about why we need Monitoring; the motiviations behind and benefits gained from adding monitoring to the system. Then we will focus on the principles of monitoring microservices and why they need special attention We will then dive into a couple of monitoring tools with a live practice demo of them; in particular New Relic Finally, we will talk about how we have and currently are implementing monitoring at kCura… we will share our experience and lessons learned so far
• #10: The reason to develop our own framework is to avoid dependency on external tools
• #12: The reason to develop our own framework is to avoid dependency on external tools
• #17: Often of the times; users don’t know exactly what feature they would like to see in your software. Monitoring their interaction with software helps us learn their demands and develop features that they themselves didn’t know that they loved! More educated estimates instead of guesstimates Evidence-based decision making
• #18: Failure in Monitoring is when we realize an error occurred in the system when the customer created a salesforce ticket for us.
• #23: - Doctor examining a patient with chest pain emergency; EKG or go through the record of his/her activity during the last 24 hours? - Insights from masses of stdout streams - Disconnected: Send me your logs I’ll see what’s going on
• #27: Concurrent execution of all components Runs on a distributed environment Each component can upgrade independently Each component can scale up or out independently Failure is isolated in each service Services can become resilient Services are isolated all the way to the hardware (virtualization, containers) Services act on their own; autonomous
• #28: Unless you’re running serverless - infrastructure less
• #31: Sociological Observation Software interfaces reflect social boundaries of the organization