Com més complex és el sistema, més s'envolta amb tot tipus d'alertes. I cal reaccionar davant aquestes mateixes alertes, agregar-les i visualitzar-les. Crec que aquesta és una situació que a molts és familiar fins al punt de nerviosisme.
La solució que es tractarà no és la més inesperada, però la cerca no retorna un article complet sobre aquest tema.
Per tant, vaig decidir compartir l'experiència de FunCorp i parlar de com s'estructura el procés de treball, qui truca, per què i com ho pots veure tot.
Què és PagerDuty?
Per tant, per resoldre tots aquests problemes, vam començar a buscar una eina convenient. Després d'una cerca, vam triar PagerDuty. PD ens va semblar una solució força completa i concisa amb un gran nombre d'integracions i configuracions. Com és ella?
En resum, PagerDuty és una plataforma de processament d'incidències que pot processar incidències entrants mitjançant diverses integracions, configurar ordres de servei i després avisar l'enginyer de servei en funció del nivell de l'incident (a un nivell alt - una trucada, a un nivell baix -). una empenta des de l'aplicació / SMS).
Qui és l'oficial de servei?
Aquest és probablement el primer lloc per començar a configurar PD.
A FunCorp, com altres empreses, hi ha un càrrec honorari d'oficial de servei. Es transmet d'enginyer a enginyer una vegada al dia. Hi ha una anomenada primera i segona línia de resposta a una alerta de PagerDuty. Suposem que arriba una alerta d'alta prioritat i si 10 minuts després de la trucada a l'oficial de servei des de la primera línia no hi ha cap reacció (és a dir, no es transfereix a l'estat de reconeixement o resolt), la trucada passa a la segona. enginyer de servei. Això es configura al propi PagerDuty mitjançant polítiques d'escalada.
Si el segon oficial de servei no respon, la notificació torna a principal a l'oficial de servei.
Per tant, qualsevol alerta d'alta prioritat entrant no pot romandre sense processar.
Ara veurem d'on poden venir els incidents.
Quines integracions fem servir?
PD rep moltes incidències diferents de diversos serveis. Actualment tenim uns 25 serveis d'aquest tipus, i per processar-los fem servir algunes integracions ja fetes.
- Prometeu
El principal sistema de recollida de mètriques és Prometheus. Ja s'ha escrit molt sobre això a Habré, només diré que en tenim uns quants per a diferents entorns: un recull mètriques de màquines virtuals i dockers, un altre dels serveis d'Amazon, el tercer de màquines hardware. Telegraf s'utilitza principalment com a exportador de mètriques.
També aquí, crec, tot queda clar pel títol. Aquesta integració s'utilitza per enviar notificacions d'alguns scripts executats per cron. PD us dóna una adreça determinada a la qual envieu cartes. Quan creeu un servei amb aquesta integració, podeu establir prioritats, en quin ordre es processaran les incidències entrants, com crear exactament una alerta (per a cada carta entrant, per a una carta entrant + una determinada regla, etc.).
- Fluix
Al meu entendre, una integració molt interessant. Hi ha moments en què passa alguna cosa però no està coberta per incidències. Per tant, hem afegit la integració de Slack per crear un incident. És a dir, podeu escriure a l'empresa Slack /callofduty tot és lent i es trencarà aviat i el PD la tramitarà i enviarà la incidència a l'enginyer de servei.
Nosaltres fem:
Nosaltres veiem:
- API
Integració HTTP. De fet, aquí no hi ha res especialment interessant, només una sol·licitud POST amb un cos en format JSON. Per exemple, alguna cosa interessant: l'utilitzem per a un seguiment extern . Aquest servei comprova l'accessibilitat dels nostres llocs des de diferents parts del món. En el cas que rebem un codi de resposta inacceptable (per exemple, 502), es crea una incidència i tot segueix la cadena descrita anteriorment. El mateix StatusCake té la capacitat de supervisar els URL interns, el certificat SSL o la caducitat del domini.
- LibreNMS
Aquest és un altre sistema de monitoratge, podeu llegir-ne més informació al seu lloc web . Amb la seva ajuda, monitoritzem les interfícies de xarxa i l'iDRAC des dels servidors.
També hi havia integracions com Datadog, CloudWatch. Podeu veure més coses sobre el que els va passar .
Visualització
El principal sistema de notificació d'incidències és Slack. Totes les incidències que arriben a PD s'escriuen a un xat especial i, si el seu estat canvia, també es mostra al xat.
Quan va sorgir l'oportunitat de mostrar dades útils a les pantalles dels monitors penjats del sostre, de sobte ens vam adonar que nosaltres (al departament de devops) no teníem res a mostrar. Hi ha una Grafana meravellosa, però no ho cobreix tot, i els empleats reaccionen a les alertes, no als gràfics.
Després d'una cerca exhaustiva però infructuosa a GitHub d'un "tauler" concís i informatiu per a PD, vam decidir escriure el nostre, només amb el que necessitàvem. Tot i que al principi hi havia una idea per mostrar la pròpia interfície PD, semblava encara més incòmode.
Per escriure-ho, només cal obtenir una clau d'un PD amb drets de només lectura.
I això és el que hem aconseguit:
La pantalla mostra les incidències obertes actuals, el nom de l'enginyer actual de servei de l'horari seleccionat i l'hora sense cap incidència de prioritat alta (el panell amb una incidència de prioritat alta es ressaltarà en vermell).
.
Com a resultat, vam rebre un tauler de control convenient per veure totes les nostres incidències. Estaré encantat si alguns de vosaltres trobeu útil la nostra experiència.
Font: www.habr.com