Hoe complexer het systeem, hoe meer het overspoeld raakt met allerlei waarschuwingen. En het is nodig om op dezelfde waarschuwingen te reageren, ze samen te voegen en te visualiseren. Ik denk dat dit een situatie is die bij velen bekend is, tot op het punt van nervositeit.
De oplossing die zal worden besproken is niet de meest onverwachte, maar de zoekopdracht levert geen volwaardig artikel over dit onderwerp op.
Daarom besloot ik de ervaring van FunCorp te delen en te praten over hoe het plichtsproces is gestructureerd, wie er belt, waarom en hoe je er allemaal naar kunt kijken.
Wat is PagerDuty?
Om al deze problemen op te lossen, zijn we dus op zoek gegaan naar een handig hulpmiddel. Na wat zoeken hebben we voor PagerDuty gekozen. PD leek ons een redelijk complete en beknopte oplossing met een groot aantal integraties en instellingen. Hoe is zij?
Kortom, PagerDuty is een incidentverwerkingsplatform dat via verschillende integraties binnenkomende incidenten kan verwerken, dienstopdrachten kan instellen en vervolgens de dienstdoende engineer kan waarschuwen, afhankelijk van het niveau van het incident (op een hoog niveau - een oproep, op een laag niveau - een push van de applicatie / sms).
Wie is de dienstdoende officier?
Dit is waarschijnlijk de eerste plaats waar u begint met het opzetten van PD.
Bij FunCorp bestaat er, net als bij andere bedrijven, een erefunctie van officier van dienst. Het wordt één keer per dag van ingenieur naar ingenieur verzonden. Er is sprake van een zogenaamde eerste en tweede lijnsreactie op een alert van PagerDuty. Stel dat er een waarschuwing met hoge prioriteit binnenkomt en als er 10 minuten na de oproep naar de dienstdoende officier van de eerste lijn geen reactie daarop volgt (d.w.z. de waarschuwing wordt niet overgedragen naar de status Bevestigen of Opgelost), gaat de oproep naar de tweede lijn. dienstdoende ingenieur. Dit wordt in PagerDuty zelf geconfigureerd via escalatiebeleid.
Als de tweede officier van dienst niet reageert, keert de melding terug naar hoofd aan de dienstdoende ambtenaar.
Elke binnenkomende waarschuwing met hoge prioriteit kan dus niet onverwerkt blijven.
Laten we nu eens kijken waar incidenten vandaan kunnen komen.
Welke integraties gebruiken we?
De PD krijgt van verschillende diensten veel verschillende incidenten binnen. We hebben momenteel ongeveer 25 van dergelijke services en om deze te verwerken gebruiken we enkele kant-en-klare integraties.
- Prometheus
Het belangrijkste systeem voor het verzamelen van statistieken is Prometheus. Er is al veel over geschreven op Habré, ik wil alleen zeggen dat we er verschillende hebben voor verschillende omgevingen: de ene verzamelt statistieken van virtuele machines en dockers, een andere van Amazon-services, de derde van hardwaremachines. Telegraf wordt voornamelijk gebruikt als statistiekexporteur.
Ook hier denk ik dat alles duidelijk blijkt uit de titel. Deze integratie wordt gebruikt om meldingen te verzenden van sommige scripts die door cron worden uitgevoerd. Van PD krijgt u een bepaald adres waarnaar u brieven stuurt. Bij het creëren van een dienst met een dergelijke integratie kunt u prioriteiten stellen, in welke volgorde binnenkomende incidenten worden verwerkt, hoe u precies een waarschuwing moet aanmaken (voor elke inkomende brief, voor een inkomende brief + een bepaalde regel, enz.).
- Slack
Naar mijn mening een zeer interessante integratie. Er zijn momenten waarop er iets gebeurt, maar dat valt niet onder de incidenten. Daarom hebben we integratie van Slack toegevoegd om een incident te creëren. Dat wil zeggen, u kunt schrijven naar Slack van het bedrijf /callofduty alles is traag en zal snel kapot gaan en de politie zal het verwerken en het incident naar de dienstdoende ingenieur sturen.
Wij doen:
Wij zien:
- API
HTTP-integratie. In feite is er hier niets bijzonders interessants, alleen een POST-verzoek met een body in JSON-formaat. Iets interessants bijvoorbeeld: we gebruiken het voor externe monitoring . Deze dienst controleert de toegankelijkheid van onze sites vanuit verschillende delen van de wereld. In het geval dat we een onaanvaardbare responscode ontvangen (bijvoorbeeld 502), wordt er een incident gecreëerd en volgt alles de hierboven beschreven keten. StatusCake heeft zelf de mogelijkheid om interne URL's, SSL-certificaten of domeinvervaldatum te monitoren.
- Gratis NMS
Dit is een ander monitoringsysteem, je kunt er meer over lezen op hun website . Met zijn hulp monitoren we netwerkinterfaces en iDRAC vanaf servers.
Er waren ook integraties zoals Datadog, CloudWatch. Je kunt meer zien over wat er met hen is gebeurd .
Visualisatie
Het belangrijkste incidentrapportagesysteem is Slack. Alle incidenten die bij PD binnenkomen, worden naar een speciale chat geschreven en als hun status verandert, wordt dit ook in de chat weergegeven.
Toen de mogelijkheid zich voordeed om nuttige gegevens weer te geven op de schermen van monitoren die aan het plafond hingen, beseften we plotseling dat we (op de devops-afdeling) er niets op konden weergeven. Er is een prachtige Grafana, maar deze dekt niet alles, en werknemers reageren op waarschuwingen, niet op grafieken.
Na een grondige maar mislukte zoektocht op GitHub naar een beknopt en informatief “bord” voor PD, besloten we ons eigen bord te schrijven - alleen met wat we nodig hadden. Hoewel er aanvankelijk een idee was om de PD-interface zelf weer te geven, zag het er nog ongemakkelijker uit.
Om het te schrijven hoeft u alleen maar een sleutel te verkrijgen van een PD met alleen-lezen-rechten.
En dit is wat we kregen:
Het scherm toont de huidige openstaande incidenten, de naam van de huidige dienstdoende monteur uit het geselecteerde schema en de tijd zonder incident met hoge prioriteit (het paneel met een incident met hoge prioriteit wordt rood gemarkeerd).
.
Hierdoor kregen we een handig dashboard waarop we al onze incidenten konden bekijken. Ik zal blij zijn als sommigen van jullie onze ervaring nuttig vinden.
Bron: www.habr.com