Probably there will be something like WriteHourly and WriteDaily methods. But that should go hand in hand with #24

#28 should be done first. Then we can access the database.

biar ga buta

Currently the frontend uses fake data which is just an array of object, we need to replace it with the real data coming from backend. We're going to use SSE to get the data from the backend.

• test for inserting & retrieving data from the sqlite3 database
• test for creating the worker (can do without goroutines), by creating another http server instance that can be called
• test for the webhook calls

Historical writes should not be failing. But in any case of high database I/O throughput, this might be possible.

For now these should do (treat these as "providers"):

• Telegram (priority)
• Webhook

What should be done:

• Add a new section on configuration called "alerting", add generic schema for setting multiple alert integrations
• Create alerting implementation for each providers
• Implement the alerting on the monitor processor

Should be a scheduler-like worker. Do a SELECT query to the raw monitor_historical table, then aggregate it by hourly or daily.

Implement those. The schema is here https://github.com/teknologi-umum/semyi/blob/refactor/backend-duckdb/backend/migrations/20240523085502_monitor_historical.sql

• #28 should be done first
• The endpoint must be secured thoroughly by using some kind of authentication. Probably by using API key (at minimal) or something else.

It's pretty useless if we need to open the uptime monitoring page again and again each day. One good approach about monitoring is we (or the team) should get a notification whenever there's a service that's suddenly went out.

Unlike other monitoring services, I don't want the providers to be non-agnostic, meaning the app is fully loaded with multiple providers that making it harder to maintain, no. I think one good approach to make the provider agnostic is by creating a webhook.

That sense, based on the configuration defined in #7, we can trigger a HTTP POST request to the endpoint provided that contains the information about the current state of service. Keep in mind that in webhook, we don't need to think of spamming the provided endpoint. All we do is just sending an event with information. Meaning the webhook will be sent immediately after meeting a certain condition based on the configuration.

On Railway status page (https://status.railway.app/) they call it "notice" instead of "incident", since not everything is an incident anyway. Maybe we should convert our wording into that.

But.. we still need a database schema for storing those notices. It should include this data (as minimum):

• Title -> the title of the notice
• Timestamp -> Event timestamp
• Status -> must be one of "investigating" | "identified" | "monitoring" | "resolved" | "scheduled". If the timestamp is in the future, the status must only be "scheduled"
• Level (or severity) -> Informational, Warning, Error, Fatal

Some examples on how we would display this on the frontend:

Incident detail:

for this one, the config.json file should be changed into this schema:

{
  "endpoints": [
    {
        "name": "Digital Ocean",
        "url": "https://status.digitalocean.com/",
        "description": "The place where the whale stands",
        "timeout": 60,
        "interval": 10
    }
  ],
  "webhook": {
    "url": "http://your-endpoint/",
    "success_responses": true,
    "failed_responses": true
  }
}

on the webhook object, the URL key provides the URL endpoint that this API hit. so it acts like a webhook.

success_responses and failed_responses are both boolean, this will define whether we should send a request if the current health check if successful or not. this is good for debugging if the team has a Slack server and needs downtime notification.

the task is pretty simple, you should (basically rewrite a bit) read the config.json file and parse the new schema so that it can be understood by the Go backend. the endpoints should be passed to the workers, the webhook's functionalities is discussed on a different issue.

currently there's only overview page, we should make each page for each endpoint/website that's being monitored. Get the data from backend through SSE.

when the cursor is hovered over the green/red bar, it should show the detail about the snapshot (time, status, etc)