CLOJURE SYNTAX PRIMER

(1) Function definition (defn function-name [arg1 arg2 … argn] ;; body )

(2) Function call (function-name arg1 arg2 … argn)

1

(defn- function-name [arg1 arg2 … argn] ;; function call(s) )

(function-name arg1 arg2 … argn)

I will be showing Clojure code, however this is all the syntax you need to understand to be able to read it. p.s No monads :-)

MICROSERVICESmacromonitoring for

Andy Marks @andee_marks

amarks@thoughtworks.com

CHAPTER 8 - MONITORING

Monitoring for monolithic architectures Monitoring for microservice architectures Thanks to Sam’s book Introducing the sample app

3

why should I care?

4

(WEB) ARCHITECTURE: PRE 2013

5

Web Server

App Server

DB

Legacy App

MONITORING

6

MONITORING @ SCALE

7

MULTIPLEXING FTW!

8

MATURE TOOLS

9

compared with…

10

(WEB) ARCHITECTURE: PRE 2013

11

Web Server

DB

Legacy App

uSvc uSvc uSvc

uSvc uSvc uSvc

uSvc uSvc uSvc

App Server

(WEB) ARCHITECTURE: 2013-

12

DB

Legacy App

uSvc uSvc uSvc

uSvc uSvc uSvc

uSvc uSvc uSvc

MONITORING MICROSERVICES

13

Complex Architecture

Collaborating Components

Nuanced Failure Modes

Correlation IDs

Synthetic Transactions

Proactive monitoring

14

let’s get practical!

15

OUR SAMPLE APP

16

1. NORMALISE INPUT

macromonitoring4microservices

17

"Macromonitoring 4 Microservices"

2. SPLIT INTO ROWS

macrom onitor ing4mi croser vices

18

macromonitoring4microservices

Length = 29 chars 52 = 25 62 = 36

m a c r o m o n i t o r i n g 4 m i c r o s e r v i c e s

1 2 3 4 5 6

3. READ DOWN THE COLUMNS

macrom onitor ing4mi croser vices

4. CONSTRUCT THE CIPHERTEXT

moicvannricigocrt4seoomesmrir

m a c r o m o n i t o r i n g 4 m i c r o s e r v i c e s

1 2 3 4 5 6

to the code!

21

SERVICES

22

1. Get input 2. Normalise plaintext 3. Split into rows 4. Read down the columns 5. Construct ciphertext 6. Display ciphertext

Front-End (4000)

Back-End (3000)

Normaliser (3002)

Square sizer (3001)

Column handler (3003)

1 6

2

3

4

5

BEWARE OF OVERKILL!

23

Square sizer (3001)

3

CORRELATION IDS

CORRELATION IDS

GUID for all calls pertaining to a single user transaction Generated by first service in call chain Propagated through all downstream calls Challenges: asynchronous services

25

CORRELATION IDS

26

Front-End (4000)

Back-End (3000)

Normaliser (3002)

Square sizer (3001)

Column handler (3003)

Generate Propogate

ID GENERATION

27

Front-End (4000)

“crypto-square-6092d335-57f7-4220-afc7-2f677f9390e6”

Constant

Unique across user transactions

ID PROPOGATION

28

Front-End (4000)

Back-End (3000)

x-correlation-id: crypto-square-6092…90e6

now what?

29

RIEMANN.IO

30

RIEMANN EVENTS

31

(defrecord Event [ service state description metric tags time ttl

“reg1.foo.bar” “reg-service http” “ok” “apache-log” 201 [“reg1” “http”] 104534892 60

CORRELATION IDS

32

Front-End

(4000)

Back-End

(3000)

Normaliser

Square sizer

Column handler (3003)

Riemann

GENERATING EVENTS

33

DEMO!

Correlation IDs allow us to: (1) spot which services participate (ok/fail/warning in which transactions (2) gather relative metrics across transactions

34

corr-id mapping

CHALLENGES

35

Foo Barcorr-id Synchronous

Foo Barcorr-id

corr-id

Asynchronous

SYNTHETIC TRANSACTIONS

SYNTHETIC TRANSACTIONS

Fake transactions injected into production system Sole intention of checking “is the system working?” Reuse functional tests as clients Challenges: excluding from metrics

37

FUNCTIONAL TESTS

38

RUN THE TESTS

39

DEMO!

Synthetic Transactions allow us to: Get confidence that key user transactions are working in production

40

CHALLENGES

41

Are these all real sales?

PROACTIVE MONITORING

PROACTIVE MONITORING - CIRCUIT BREAKERS

(1) Closed: execute (2) Open/Tripped: use fallback (if available) (3) Half-Open: try 1 request Monitors circuit health (error % > threshold %) Help build antifragility

43Source: https://github.com/Netflix/Hystrix/wiki/How-it-Works#CircuitBreaker

HYSTRIX BY NETFLIX

44

in conclusion

45

MONITORING MICROSERVICES

46

Complex Architecture

Collaborating Components

Nuanced Failure Modes

• Correlation IDs

• Synthetic Transactions

• Proactive Monitoring

FINAL THOUGHTS

▫︎Monitoring microservices environments can be tricky

▫︎ Invest in operational capabilities in line with microservices development

▫︎ Reuse OSS from organisations doing this stuff well (e.g., Netflix)

▫︎ Passive/reactive monitoring is necessary, but “failure demand” (aka waste)

47

THANKS

Andy Marks @andee_marks

amarks@thoughtworks.com