Monitoring: tool pro sledování základních parametrů

[ornsteinfilip]

Prosím o vytvoření jednoduchého toolu, kterýpljde prozatím spustit na lokálu z test složky tohoto gemu. Ten by po zadání access url a token do lokálního .env umožnil sledovat běh projektu obsahujícího auctify. Zejména jde o ukončování položek ve správných časech, přítomnost příhozů, přeplněnost front či přítomnost nevykonaných jobů (zejména těch uzavíracích). Může využívat pro ověření základní funkcionality i existující https://www.aukceaukci.cz/app/status.json.

V případě, že něco nebude fungovat dle očekávání, tak by měl svítit červeně a vydávat výstražný zvuk.

Smysl je, aby jej mohl mít otevřený brigádník, který bude volat dev/ops s konkrétním issue.

• remote přístup
• sledování ukončování položek (původní konec + tolerance)
• sledování prodlevy mezi příhozy (přes všechny aukce)
• sledování počtu úkolů v frontách (Sidekiq/ActiveJob)
• sledování nevykonaných Jobů
• {"results":[{"name":"Database","message":"","status":"OK"},{"name":"Cache","message":"","status":"OK"},{"name":"Sidekiq","message":"","status":"OK"}],"status":"ok","timestamp":"2022-06-02T12:04:27.488+00:00"}

[mreq]

Skvele 👍

[foton]

Konstrukce:
V Auctify enginu bude API endpoint, na který se zavolá GET s tokenem a vrátí se JSON s daty.
V Auctify gemu, v test/dummy app bude controller, který se bude pravidelně na tenhle soubor doptávat, ukládat získaná data a zobrazovat grafy. A popřípadě spouštět alerty.
@ornsteinfilip @mreq Máte lepší nápad?

[mreq]

Imho na tohle bude existovat milion hotovych 3rd party reseni. Za auctify vidim jako podstatne udelat ten API endpoint vracejici JSON. Ten by si pak pingovala externi sluzba, ktera s nim nejak nalozi. To bude vedet @ornsteinfilip - aby to umelo ty stupnovane alerty typu slack/email/sms/hovor atd.

[ornsteinfilip]

@foton S kontrukcí v zásadě souhlasím.

Našel jsem krásný výpis různých OS dashboard toolů, které je možné použít pro vizualizaci bez programování. Viz https://github.com/obazoud/awesome-dashboard

Lze tam nalézt Grafanu, kteoru máme a platáíme a možná by bylo možné si snadno naklikat vlastní dashboard a mít to pohromadě s ostatníma věcma, jako jsou logy. Grafana nabízí i storage, takže tam asi jen nakonfiguruješ přístupy, tokeny, způsob vizualizace a bude.

Z dalších jsme v minulosti jednou použili Kibanu a ta taky nebyla špatná. Real time monitoring tam šel a data byla uložená v Elasticu. To by bylo možná zajímavé pro to lokální řešení. Vím, že jsme to klikali v rámci hackathonu tak trochu navíc a šlo to rychle. Ale osobní zkušenost nemám.

[ornsteinfilip]

Asi si to prohlédnete sami, ale posunulo mne to v přemýšlení k nástrojlm, které zajišťují i storage těch dat. Nejen pingování a real time zobrazení, které je však také třeba.

[foton]

Teď jsem hodinu věnoval hledání gemů na téma metrics apm a monitoring a většinou jde o Agenty pro nějaké SaaS monitoringy.

Nejblíž myšlence "gem na čtení a zobrazení časosběrných dat" má https://github.com/xiayuanyin/simple_apm (v čínštině, google překlad stránky mě pobavil).
A možná https://github.com/dgilperez/metrics-graphics-rails

Zajímavý pro "data generující" část je https://github.com/johnewart/ruby-metrics .
Ještě se musím podívat jak funguje Active Support Instrumentation

A tohle dělá taky pěkný endpoint https://github.com/lbeder/health-monitor-rails , ale nevím, zatím jestli je to rozšiřitelné.

Takže mi přijde, pro naše potřeby, jednodušší mít controller pro monitoring, co zobraszuje naše datav grafech pomocí https://www.ruby-toolbox.com/projects/chartkick

[ornsteinfilip]

V tom odkazu, cojsem posílal jsou i pěkný příklad využití http://graphiteapp.org/ pro realtime dashboardy

[ornsteinfilip]

Nebo NGX, ale tam sice vidím něco s live update, ale nejsem si jist, zda podporuje real time zobrazeni

https://github.com/akveo/ngx-admin
https://www.akveo.com/ngx-admin/pages/dashboard?theme=material-light

[ornsteinfilip]

@foton Imho health monitor používáme už teď, ne? Nějakou takovu status page přidával Jindřich. To je podobné, jako ten JSON, kterým sleduje K8s základní životní funkce.

To, co jsi našel ty, je takové dost low-level. Což není špatně, ale @mreq má asi pravdu, že bychom neměli psát vlastní, když budou existovat řešení,kde se jen napojí daotový zdroj na připravený widget. Viz výše jak posílám https://github.com/obazoud/awesome-dashboard, přijde mi, že toho je opravdu mraky. A mžná bude ze všeho nejlepší Grafana, když ji už máme, platíme a ukládá data. Nechám na tvém posouzení, asi to bude o nějakém experimentování.

[foton]

S Prometheem (a Grafanou) se mám obrátit a @jindrichskupa ?

[foton]

BTW:
S těmito "metrikami" jsem do teď počítal

{
  "bids_count":161, # po zapsání bidu
  "avg_diff_in_closing_time_secs":35, # při ukončovacím jobu
  "max_diff_in_closing_time_secs":433, # při ukončovacím jobu
  "avg_time_diff_between_bids_secs":73, # po zapsání bidu
  "queue_sizes":{ # při naplánování, startu a ukončení jobu
    "in_progress":0,
    "queued":5,
    "finished":106,
    "failed":6,
    "dead":0,
    "retries":1,
    "critical":0,
    "mailers":1,
    "default":1,
    "scheduled":0
  }
}

Možná, že Sideki´q umí sám nějaký svůj prometheus report.

[foton]

Publikování metrik pro Prometheus (a následně Grafanu) nasazeno na produkci. Aplikační na /metrics , sidekiqové na :9394/metrics. @jindrichskupa slíbil, že zprovozní to načítání do Prométhea.

[foton]

@jindrichskupa @ornsteinfilip Je to už nastavené?

[jindrichskupa]

@foton Mrknu na to. Musi se k podum pridat anotace aby prometheus vedel, kde to hledat.

[foton]

Tohle jede."Grafana => Dashboards => General"
za zvážení před uzavřením stojí:

• lze v grafaně poskládat "per Web dashboard?" Tj sloučit vybrané metriky na jednu stránku.
• vyměnit "Bids_count" za "Bids per minute" ?

Jinak lze uzavřít
@ornsteinfilip

[ornsteinfilip]

@foton Bid count bch ponechal, jen přidal rate. Naopak u sidekiq bych rád vidět i počty tam, kde je rate. A ano, ještě dotáhněme sdružený dashboard a pak zbytek nechme na další revize.

[foton]

Přidat metriky:

• počet příhozů za minutu
• ?