Monitoring matters. Understanding the state of our infrastructure and systems is essential for ensuring the reliability and stability of our services. Information about the health and performance of your deployments won’t only help your team react to issues, it also gives them the confidence to make the necessary changes. One of the best ways to gain this insight is with a robust monitoring system that gathers metrics, visualizes data, and alerts operators when things appear to be broken.
So good monitoring is a must, but it’s not easy. It takes valuable developer time to build the right tools. It also takes precious time to decide what the right tools might even look like. Who even has the time for that??
What’s Monitored?
Monitored is an easy to deploy monitoring package for node projects. It’s the solution we came up with when we needed a dependable and consistent monitoring solution across our entire organization. It provides us with consistent metrics and common ground for monitoring across teams.
Monitored alleviates us from the need to develop new tools, metrics, and measurement practices for each new project. It’s the perfect plug & play monitoring tool we needed, saving both the time it would need to develop such a tool, and the time to set it up, with configurable custom metrics.
And now, you can use it too!
But why use Monitored?
- System health: Keeping a close eye on our system/app can help us identify problems before they get out of hand. Keeping track of SLA (Service Level Agreement) allows us to evaluate the health of the system and bolster it.
- Data: Recently, we developed an extensive data system to create a personalized experience for our users. In Soluto, we have a lot of independent products that expose data, and we needed to find a way to connect all the products’ data and create insights. To do that, We created a system that consists of several services and serverless functions that collect data from relevant sources and aggregate it. The metrics helped us keep track of all the moving parts, detect edge cases, ensure data quality, and understand the data better.
- Performance: You can track and improve the performance of your product easily by receiving ongoing stats on the time it takes for an action to perform.
HTTP Execution Time
How to implement Monitored
To create and expose custom metrics, we have three options:
- StatsD + Graphite + Monitored:Graphite — Makes it easy to store and graph metrics.StatsD — A network daemon that runs on the Node.js platform, listens for statistics, and sends aggregates to one or more pluggable backend services.
StatsD + Graphite
- Prometheus client + Monitored
- Prometheus client + Prometheus push server + Monitored (This option will be available in the future):Prometheus — a monitoring system that can sample all of our services and collect the metrics they generate. Prometheus has the ability to pull data from various sources, point it to your service.This combo makes it easy to store and graph metrics.
Prometheus
In all of the above cases, Monitored is implemented as a Wrapper function that writes success/error logs and metrics.
Using Monitored alongside Grafana
In Soluto we use Grafana to build metric dashboards, but you can choose any other tool. Grafana is an interactive visualization web application, providing charts, graphs, and alerts for the web when connected to supported data sources.
Step one: initialize the global instance of Monitored
Call setGlobalInstance at the root of the project.
To wire this package, you’ll need to pass an Options object.
- serviceName — Represents the name of the service you are monitoring (mandatory)
- plugins — Stats plugins, statsD and/or prometheus (mandatory)
- logging — Writes success and error logs with the logger that has been passed in (optional)
- shouldMonitorExecutionStart — When true, will log execution start and will increment metrics. Defaults to true (optional)
- mock — Writes the metrics to logs instead of StatsD for debugging. Defaults to false (optional)
setGlobalInstance
Now, you’re ready to wield the awesome power of Monitored.All you need to do is to wrap your functions with Monitored:
monitored async function example
Which, on the backstage, will do:
Counters:Start metric → Fire when a function startSuccess metric → Fire when a function endsError → Fire on functions exception
Counters
With that metric you can easily add a chart that shows the status of your (service/function). For example:
Service/Function status
Timers:ExecutionTime.meanExecutionTime.mean_90
Timers
With these metrics you can measure your function performance, or 3rd party api performance. For example:
Execution time
You can also call metric functions manually. For example, if you want to count something you just need to call:
I use it a lot for checking the occurrence of a data problem, but it’s also useful to use in other cases. For example, after implementing a notification server, I added a metric whenever I sent a notification and another metric whenever the client received the notification. With these two metrics I was able to measure the SLA of my notification service.
I hope I’ve made you see the value and flexibility Monitored can afford you. For us, it’s been a huge time saver, and made monitoring a much smoother task company-wide.
Blog article by: 