Micro-tracker

Modern web application are more and more designed with micro-services. Those services exchange messages in order to communicate with each other. Eventually your architecture ends with a graph of services that could be quite complex. Micro-tracker is all about tracking this micro-service's interactions in order to know which service received which message, when and from which other service. It will help you monitor your architecture and debug faster.

Imagine you have three services Alice, Bob and Carl. Each one is sending messages to the two others. As good developer, you want to know exactly which message has been sent and received.

Micro-tracker helps you with that. It provides a very simple wrapper for your messages:

content = {'command' => 'list', 'target' => 'posts'}
message = Utracker::Message.pack(content)

Once you've packed your message, the content is accessible:

assert(message.content == content)

And you can pass this message to you message queue as you would have done with your content:

rabbit_mq.push(message.to_json)

After that, ou can use the log capability of micro-tracker to keep track that your process send this message:

message.log('sending_content')

The receiver can deserialize the received payload and log that he received this message with:

serialization = rabbit_mq.pop
message = Utracker::Message.unpack(serialization)
message.log('processing_content')

If all of your processes use the same logger configuration:

Utracker.configure do |config|
  config[:service_name] = 'alice' # or 'bob' or 'carl'
  config[:logger_class] = Utracker::MongoDB::Logger
end

Then the logs will be normalized and centralized and you'll be able to follow the flow of messages, replaying them, analyse trafic, smartly scale services and so on.

• MongoDB through utracker-mongodb

• Pack and unpack messages into JSON
• Assign an unique identifier to each packed message.
• Retrieve the unique identifier when the message in unpacked.
• Log events concerning a specific message.
• Create messages from a parent message.
• Allow to filter content of the logs (password, etc).

• Flow drawer
• Broken service alert
• Scaling advisor
• Replay messages after a failure