Another monitoring service?
Why creating another monitoring service when there are new monitoring services every day?
I love this comic, because it definitely apply to monitoring services:
Here are the 5 reasons why creating a new monitoring service:
— Need something simple and fast to configure
— Wan’t to have distinct information about our deployment impact
— Powerful configuration that could be updated by an API
— Errors reports useful for our ISO-27001 compliance audit report
— Plan affordable for companies not part of Nasdaq
And here happen PepperReport.io 🌶
Configuration is a pain!
Too many service are made to manage 10 or 20 checks. But If I need more, it became complicated to navigate or find them.
I don’t like to have too many things to configure by clicking everywhere, and when a service provide all the option I need, I’ve to create many many many monitoring checks. This is boring.
Initial idea was to create a domain (kind of namespace), configure some monitoring checks in this domain, and then fork the domain, just updating the domain URI path. This would be awesome when your application is replicate on dev, preprod and prod stages.
It will also make sense if you deploy your application for a new client with their own domain/subdomain.
I’ve dreamed about a YAML configuration, that I could work on with my IDE. And so I’ve made it.
Monitor your application, for real, not your application firewall.
That’s something I’ve seen in my previous position, databases repositories were down, shutting down almost all our application stack, but probes where still ok.
It happen because the applications firewall doesn’t require a database access and redirect probes to the login page, loaded from cache without any database connection.
So yes, everything was down, but for the probes, it was fine 😹
Yes, My firewall is working but is my application really working correctly?
Many applications are fully private. How could I test thoses API? Their behavior? Their APM?
Let’s figure this API monitoring:
Nice, but my credential are directly related to my user session, so let’s identify who am I:
You see? This small new line in the headers values? Now I can request this private API endpoint with PepperReport.io… for a limited time… the token will expire in few minutes, and the monitoring check will fail.
So let’s make it dynamic:
You see that new “dynamicToken” defined as a parameter ? Seems nothing, but now we can update this value through our UI or the API.
Look nice no? And if sending token to our API seems a bit tricky, you can now use crypted RSA keys to send them.
Track deployment
Continuous Delivery is very common among the teams of developers because of the zero-downtime deployments and the faster time to market value.
But it’s also harder to track commit that will have bad impact on performance, even with code review and tests. When you’re team are creating hundred of commits per weeks, on many micro-services, every minor edition could impact your stack negatively. Statistically it’s just about time before it happen.
So it seems imperative to me to monitor them. Having a vision of the performance of the actual application release and compare it to previous release is priceless! It’s also great, when there’s an outage, to link it with a previously made deployment of a new release.
Regardless of the deployment of new releases, the deployment of a new infrastructure give good indications about it performance impact.
PepperReport.io
🌶 Quickly identify which of your web services are underperforming in terms of speed and availability with our detailed performance reports. 🔥
