U più cumplessu u sistema, più diventa invastatu cù ogni tipu di alerti. È ci hè bisognu di reagisce à sti stessi alerti, aggregali è visualizeli. Pensu chì questa hè una situazione chì hè familiar à parechji à u puntu di nervosità.
A suluzione chì serà discutitu ùn hè micca u più inesperu, ma a ricerca ùn torna micca un articulu cumpletu nantu à questu tema.
Dunque, aghju decisu di sparte l'esperienza di FunCorp è di parlà cumu u prucessu di u duvere hè strutturatu, quale chjama, perchè è cumu pudete vede tuttu.
Cosa hè PagerDuty?
Allora, per risolve tutti questi prublemi, avemu cuminciatu à circà un strumentu convenientu. Dopu qualchì ricerca, avemu sceltu PagerDuty. PD ci pareva esse una soluzione abbastanza cumpleta è cuncisa cù un gran numaru di integrazioni è paràmetri. Cume hè ella?
In cortu, PagerDuty hè una piattaforma di trattamentu di incidenti chì pò processà incidenti entranti attraversu diverse integrazioni, stabilisce ordini di duvere è dopu avvisà l'ingegnere di turnu secondu u livellu di l'incidentu (à un altu livellu - una chjama, à un livellu bassu - una spinta da l'applicazione / SMS).
Quale hè l'ufficiale di u duvere?
Questu hè probabilmente u primu locu per inizià a stallazione di PD.
À FunCorp, cum'è altre cumpagnie, ci hè un postu onorariu di ufficiale di serviziu. Hè trasmessa da ingegnere à ingegnere una volta à ghjornu. Ci hè una chjamata prima è seconda linea di risposta à una alerta da PagerDuty. Suppone chì una alerta d'alta priorità ghjunghje, è se 10 minuti dopu à a chjama à l'ufficiale di serviziu da a prima linea ùn ci hè nisuna reazione à questu (vale à dì, ùn hè micca trasferitu à u statu di ricunniscenza o risolta), a chjama passa à a seconda. ingegnere di serviziu. Questu hè cunfiguratu in PagerDuty stessu attraversu Politiche di Escalation.
Se u sicondu ufficiale di serviziu ùn risponde micca, a notificazione torna à principale à l'ufficiale di turnu.
Cusì, ogni alerta di priorità alta in entrata ùn pò micca esse micca processata.
Avà vedemu da induve l'incidenti ponu vene.
Chì integrazioni usemu?
PD riceve assai incidenti diffirenti da diversi servizii. Avemu attualmente circa 25 tali servizii, è per processarli usemu alcune integrazioni pronti.
- Prometheus
U sistema di cullizzioni di metrica principale hè Prometheus. Moltu hè digià scrittu annantu à Habré, dicu solu chì avemu parechji di elli per ambienti diffirenti: unu raccoglie metriche da e macchine virtuali è dockers, un altru da i servizii di Amazon, u terzu da e macchine hardware. Telegraf hè principalmente utilizatu cum'è esportatore di metrica.
- Malice
Ancu quì, pensu, tuttu hè chjaru da u titulu. Questa integrazione hè aduprata per mandà notificazioni da certi script eseguiti da cron. PD vi dà un certu indirizzu à quale mandate lettere. Quandu creanu un serviziu cù una tale integrazione, pudete stabilisce priorità, in quale ordine l'incidenti entranti seranu processati, cumu esattamente per creà una alerta (per ogni lettera entrata, per una lettera entrata + una certa regula, etc.).
- Slack
In my opinion, una integrazione assai interessante. Ci sò volte chì qualcosa succede, ma ùn hè micca cupartu da incidenti. Dunque, avemu aghjustatu integrazione da Slack per creà un incidente. Questu hè, pudete scrive à Slack corporativu /callofduty tuttu hè lentu è si rompe prestu è u PD u processerà è mandarà l'incidentu à l'ingegnere di serviziu.
Facemu:
Avemu vistu:
- API
Integrazione HTTP. In fatti, ùn ci hè nunda particularmente interessante quì, solu una dumanda POST cù un corpu in formatu JSON. Per esempiu, qualcosa interessante: l'avemu aduprà per u monitoraghju esternu cù l'usu . Stu serviziu verifica l'accessibilità di i nostri siti da diverse parti di u mondu. In u casu quandu avemu ricivutu un codice di risposta inacceptable (per esempiu, 502), un incidente hè creatu è dopu tuttu seguita a catena descritta sopra. StatusCake stessu hà a capacità di monitorà l'URL interni, certificatu SSL o scadenza di duminiu.
- LibreNMS
Questu hè un altru sistema di surviglianza, pudete leghje più nantu à u so situ web . Cù u so aiutu, monitoremu l'interfaccia di rete è iDRAC da i servitori.
Ci era ancu integrazioni cum'è Datadog, CloudWatch. Pudete vede più nantu à ciò chì hè accadutu per elli .
Visualizazione
U sistema principale di rapportu di incidente hè Slack. Tutti i incidenti chì venenu à PD sò scritti in un chat speciale, è se u so status cambia, questu hè ancu mostratu in u chat.
Quandu l'oppurtunità hè ghjunta per vede dati utili nantu à i schermi di i monitori appiccicati da u tettu, avemu capitu di colpu chì noi (in u dipartimentu devops) ùn aviamu nunda per vede nantu à elli. Ci hè una maravigliosa Grafana, ma ùn copre micca tuttu, è l'impiegati reagiscenu à alerti, micca charts.
Dopu una ricerca approfondita ma senza successu in GitHub per una "tavola" concisa è informativa per PD, avemu decisu di scrive u nostru propiu - solu cù ciò chì avemu bisognu. Ancu s'ellu prima ci era una idea per vede l'interfaccia PD stessu, pareva ancu più inconveniente.
Per scrivelu, tuttu ciò chì duvete fà hè di ottene una chjave da un PD cù diritti di sola lettura.
È questu hè ciò chì avemu avutu:
A schermu mostra l'incidenti attuali aperti, u nome di l'ingegnere attuale in turnu da u calendariu sceltu, è u tempu senza un incidente di priorità alta (u pannellu cù un incidente di priorità alta serà evidenziatu in rossu).
.
In u risultatu, avemu ricevutu un dashboard convenientu per vede tutti i nostri incidenti. Seraghju felice se alcuni di voi trovanu a nostra sperienza utile.
Source: www.habr.com