The document discusses monitoring microservices, suggesting they should be treated like cattle rather than pets. It emphasizes the importance of checking resource utilization, saturation, and errors for effective monitoring, as well as exploring distributed tracing solutions like Zipkin to understand causality in service requests. The presentation also mentions existing tools and the challenges of requiring application-specific modifications for tracing.

1. Monitoring Microservices
tom@weave.works
@tom_wilkie

3. VisualisationMonitoring Tracing
0
25
50
75
100

4. Monitoring
0
25
50
75
100

5. Traditional 3-tier architecture
Incoming traffic
Load balancers
Application servers
Database & replica

6. Microservice architecture
Public APIWeb UI
NoSQL serversDatabase
Message
Broker
Services

8. Microservices should be
treated like cattle not pets

10. USE Method* - for every
resource, check:
• utilization,
• saturation, and
• errors
RED Method - for every
service, check request:
• rate,
• error (rate), and
• duration (distributions)
are within SLO/A
* http://www.brendangregg.com/usemethod.html
An alternative view

11. Monitoring
0
25
50
75
100

12. Visualisation

14. Weave Scope

15. Connection
Tracking
# cat /proc/net/tcp
# conntrack -E -p tcp

16. Matrix

17. Connection
Tracking
all connections
from
/proc
conntrack

18. Demo time

19. Visualisation

20. Tracing

21. Distributed
Tracing

22. Not a new topic
• Lots of literature
• Existing open source
projects
• e.g. Zipkin, originally from
Twitter

23. • Challenge: detecting
causality between
incoming and outgoing
requests
• Existing solutions
require propagation of
some unique ID
(dapper, zipkin)
• This requires
application-specific
modifications
some service
incoming
request
outgoing
requests
?

24. Can this be done without
application modifications?

25. Demo time

26. Tracing

27. VisualisationMonitoring Tracing
0
25
50
75
100

28. @weaveworks github.com/weaveworks
Questions?
http://weave.works/product/scope
tom@weave.works
@tom_wilkie