SpO₂ is oxygen saturation and is used in medical person monitoring.

I am Kerollmops, I am the CTO of [Meili](https://www.meilisearch.com/) and today I am releasing [SpO₂](https://github.com/Kerollmops/spo2/).

At Meili, we needed a tool that allows us to monitor our pods, we already have [vigil](https://github.com/valeriansaliou/vigil) which health checks our front page and backend, but the number of these services is limited. We do not pop new front or backend servers dynamically (for now). When we create new search engines for the user we instanciate a kubernetes pod, we need to monitor the health of this service. Adding each of those URLs by hand in the vigil config file is not a solution.

So we decided that we needed a simple tool, a tool that can accept HTTP requests to register/unregister URLs to health check. We use the [new async/await Rust syntax](https://blog.rust-lang.org/2019/09/30/Async-await-hits-beta.html) along with [tide](https://github.com/http-rs/tide) for the http server, no big deal here.

Our current cloud provider is [Digital Ocean](https://www.digitalocean.com/), therefore, we cannot host our SpO₂ service there. We chose [Scaleway](https://www.scaleway.com) as it is way cheaper, and it works out of the box. We need persitent storage of the health checked URLs. What would you do if those are only stored in RAM? What if the server restarts? I already worked on [a disk backed key-value store in Rust named Sled](https://sled.rs/). So we chose to rely on it.

![](https://unable-actionable-car.media.strapiapp.com/screenshot_d586f10f06.png)

[@qdequele](https://quentin.llmops.com) built the front-end with vanilla javascript. Using Websocket we are able to display in realtime the pods status. As most humans do not stand in front of a TV the whole day, spotting color changes to notify the devops, we decided to implement notifications. We are using Slack for all of our monitoring tools, and because it is as simple as a webhook to implement, we went with it.

In the last release, we made some improvements to the Slack notification system. We now batch status changes events by 40; this means that SpO₂ sends one message with at most 40 events and regulates channel spamming. It also displays the HTTP status related to an unhealthy measurement and the error message on an unreachable one.

SpO₂ does not support SSL/TLS by itself, neither for the HTTP nor the WebSocket endpoints. We needed this kind of security so we looked at NGINX, a tiny little obscure reverse proxy server which we configured with basic authentication. It is not an easy task and because we are cool we made the documentation to help you do the same.

Do not hesitate to share or star this project, pull requests are welcome 😊

And just as a side note, we do not measure humans but machines actually.

SpO₂ the little dynamic monitoring tool

Today we are releasing [MeiliES](https://github.com/meilisearch/MeiliES), our event store which is fully implemented in Rust.

Event sourcing is a way to _"Capture all changes to an application state as a sequence of events"_ as [Martin Fowler describes it](https://martinfowler.com/eaaDev/EventSourcing.html). The first purpose of the server is to publish events of a stream to subscribed clients. A client can also specify from which event number it wants to read, therefore it is possible to recover from a crash by rebuilding a state with new events only.

Since [a message queue is not made for event-sourcing](https://medium.com/serialized-io/apache-kafka-is-not-for-event-sourcing-81735c3cf5c), there are few available applications for event sourcing: the main option being [EventStore](https://eventstore.org/), an event sourcing database made in C#.  
So we began using EventStore for our event sourcing needs and ran against some troubles:

*   Portability: EventStore is built with C# and uses mono, making it quite difficult to install and run on UNIX
*   Support: We asked for information about EventStore commercial support and never got any response
*   Stability: the Rust client is not production-ready, and despite making some merge-requests there was still a lot to do while many of the available features were not useful to us.

So we decided to implement our own event store to resolve these issues.

MeiliES is an _Event Sourcing database_ that uses the _RESP_ (REdis Serialization Protocol) to communicate. We use the Redis protocol to simplify clients implementation. The portability problematics are resolved by using a full Rust implementation (we are using [Sled as internal storage](https://github.com/spacejam/sled)).

Installation is as simple as doing a `cargo build --release`. If you do not want to clone the repository you can [download the binaries from the Azure pipeline](https://dev.azure.com/thomas0884/thomas/_build) or run it using docker `docker run -p 6480:6480 --rm getmeili/meilies:latest`.

If you have any questions regarding MeiliES, you can tweet [@meilisearch](https://twitter.com/meilisearch) or make an [issue on GitHub](https://github.com/meilisearch/MeiliES) 🎉

Meilisearch latest news and company updates

SpO₂ the little dynamic monitoring tool

MeiliES - Event sourcing in Rust