Service-Status

Very Polite Service Monitoring

Introduction

Passionate Coder

@mbazydlo

VeInteractive

Psst... We are hiring.

How are you?

  • I’m fine, thanks!
  • I hate Mondays.
  • My commute sucks!
  • Not too bad. Not too bad.

DIRECT QUESTION, SIMPLE ANSWSER

No calling husband/wife!

No asking behind a back

No long looks

Monitoring

Why bother with monitoring?

  • Monitoring is automated debugging (less effort)
  • Monitoring is faster then manual checking
  • Monitoring is discrete and continuous
    (it just check and check again and again)
  • Monitoring is pointing the exact time when problem started
  • Monitoring is eliminating many other possibilities
  • Monitoring helps to understand where the solution might be
  • Monitoring can expose recurring problems
  • Monitoring speeds up deployments and makes them much more reliable
  • Monitoring describes system and it’s dependencies.

Everyone
Needs
Monitoring

Monitoring ain't easy

  • Yet another tool to learn
  • You need to pay time and money to have it
  • It often shows you all rather then what you care for
  • It is hard to customise
  • Complex solutions lead to complex issues
  • Vendor lock-in

How monitoring should be?

  • Simple
  • Extensible
  • Consistent
  • Distributed

Service-Status

Just do it

Manual

  1.      /service-status
  2. 200❓👍 : 👎
  3. 🕵 📜

Manual

response = GET /service-status
if (response.status == 200)
    return <OK, response.body>
else
    return <FAILURE, response.body>

Example

GET /service-status
{ monitorResults: [
    {
        monitorName: "VeAppsDatabaseMonitor",
        successful: true,
        metaData: {
            message: "Database exists succeeded? True"
        }
    },
    {
        monitorName: "LiveDataRedisMonitor",
        successful: true,
        metaData: {
            message: "Successfully written and retrieved data from live data redis instance."
        }
    }
]}

Run Tests

sut = new serviceStatus()

sut.isSimple?

sut.isExtensible?

sut.isConsistent?

sut.isDistributed?

How it all works together?

Monitoring for deployment?

Monitoring for deployment?

Monitoring for deployment?

Monitoring for deployment?

Monitoring for deployment?

You will love it!

You own it!

Developers are responsible for monitoring strategy

Easily Customisable

You can write monitor for things that failed in the past.

'It won't happen again!'

Reliable Deployments

Service-Status doubles as smoke tests during deployment.

Test Constantly

You can check state of application at any point in time, preferably periodically.

Good Perspective

Your monitoring verifies everything from application perspective, rather then from yours.

Simple? Complex?

You decide how simple or complex is your monitoring.

Documentation

Monitor contains documentation about the system, making it easier to understand it's needs.

Documentation

Monitor is documentation about the system, telling you system expectations.

Tried & Tested

Code

Monitor Interface

public interface IServiceStatusMonitor
{
    string Name { get; }

    MonitorResult Execute();
}

Monitor Result

public class MonitorResult
{
    public string MonitorName { get; }

    public bool Successful { get; set; }

    public Dictionary<string, string> MetaData { get; set; }
}

Service-Status Controller

public class ServiceStatusController : Nancy.NancyModule
{
    public ServiceStatusController(List<IServiceStatusMonitor> monitors)
    {
        Get["/service-status"] = 
            _ => monitors.AsParallel().Select(x=>x.Execute()).ToList();

        Get["/service-status/{monitorName}"] = 
            params => monitors.First(x=>x.Name == params.monitorName).Execute();
    }
}

Thanks!

Questions?

@mbazydlo

Service-Status

By gondar

Service-Status

  • 491