{"id":52115,"date":"2019-11-01T00:00:00","date_gmt":"2019-10-31T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury"},"modified":"2020-02-18T13:59:47","modified_gmt":"2020-02-18T10:59:47","slug":"monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury","title":{"rendered":"Monitoring als een service: modulaire systeem voor microservicesarchitectuur","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Vandaag functioneren er op ons project, naast monolithische code, tientallen microservices. Elk van hen vereist monitoring. Dit is problematisch om door DevOps-engineers in zulke grote hoeveelheden te doen. We hebben een monitoreersysteem ontwikkeld dat als een service voor ontwikkelaars werkt. Ze kunnen zelf metrics naar het monitorsysteem schrijven, deze gebruiken, dashboards op basis daarvan opstellen en ze koppelen aan alerts die afgaan bij het bereiken van drempelwaarden. Voor DevOps-engineers is er alleen infrastructuur en documentatie. <\/p>\n<p>Deze post is een transcript van mijn presentatie tijdens onze <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/tomicro\">sessie<\/a><\/noindex> op RIT++. Velen vroegen ons om tekstversies van de daar gehouden lezingen te maken. Als je op de conferentie was of de video hebt bekeken, vind je niets nieuws. Voor iedereen andere: welkom onder de kat. Ik zal vertellen hoe we tot dit systeem zijn gekomen, hoe het functioneert en hoe we van plan zijn het bij te werken. <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring als een service: modulaire systeem voor microservicesarchitectuur\" src=\"\/wp-content\/uploads\/2019\/11\/000b8fdc8fb16aa76ce545ff2aa4e767.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Het verleden: schema's en plannen <\/h3>\n<p>\nHoe zijn we tot het huidige monitorsysteem gekomen? Om deze vraag te beantwoorden, moeten we terug naar 2015. Zo zag het er toen uit: <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring als een service: modulaire systeem voor microservicesarchitectuur\" src=\"\/wp-content\/uploads\/2019\/11\/d955f9bcdb5f5a5a54720c77113ca85d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWe hadden ongeveer 24 knooppunten die verantwoordelijk waren voor monitoring. Hier zijn een heleboel verschillende cronjobs, scripts, daemonprocessen die op de een of andere manier iets monitoren, berichten verzenden, functies uitvoeren. We dachten dat hoe verder we gingen, hoe minder levensvatbaar zo'n systeem zou zijn. Het heeft geen zin om het verder te ontwikkelen: het is te log. <br \/>\nWe hebben besloten welke monitoringelementen we willen behouden en ontwikkelen en van welke we afscheid nemen. Het bleken er 19 te zijn. Alleen graphite, aggregators en Grafana als dashboard blijven over. Maar hoe zal het nieuwe systeem eruitzien? Zo: <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring als een service: modulaire systeem voor microservicesarchitectuur\" src=\"\/wp-content\/uploads\/2019\/11\/57d220113d0b76c05874b5d774bff8af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWe hebben een opslagplaats voor metrics: dat zijn graphite die op snelle SSD-schijven worden gebaseerd, en specifieke aggregators voor metrics. Vervolgens\u2014Grafana voor het weergeven van dashboards en Moira voor alerting. We wilden ook een systeem ontwikkelen voor het zoeken naar anomalie\u00ebn. <\/p>\n<h3>Standaard: Monitoring 2.0<\/h3>\n<p>\nZo zagen de plannen er in 2015 uit. Maar we moesten niet alleen de infrastructuur en de service zelf klaarmaken, maar ook de documentatie daarvoor. We hebben voor onszelf een bedrijfsstandaard ontwikkeld, die we monitoring 2.0 noemden. Wat waren de vereisten voor het systeem? <\/p>\n<ul>\n<li>permanente beschikbaarheid; <\/li>\n<li>bewaarinterval voor metrics = 10 seconden; <\/li>\n<li>georganiseerde opslag van metrics en dashboards; <\/li>\n<li>SLA &gt; 99,99% <\/li>\n<li>verzameling van evenementmetrics via UDP (!). <\/li>\n<\/ul>\n<p>\nWe hadden UDP nodig omdat we een grote hoeveelheid verkeer en gebeurtenissen hebben die metrics genereren. Als we ze allemaal tegelijk naar Graphite schrijven, valt de opslag uit. We hebben ook eerste niveau prefixes voor alle metrics gekozen. <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring als een service: modulaire systeem voor microservicesarchitectuur\" src=\"\/wp-content\/uploads\/2019\/11\/d24c4474b19b532a48cef4d4376287ad.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nElke prefix heeft een bepaalde eigenschap. Er zijn metrics voor servers, netwerken, containers, bronnen, toepassingen, enzovoort. Er is een duidelijke, strikte, getypeerde filtering ge\u00efmplementeerd, waarbij we de eerste niveau metrics accepteren en de anderen gewoon weggooien. Zo hebben we dit systeem in 2015 gepland. Wat is er nu? <\/p>\n<h3>Hedendaagse: het schema van de interactie tussen monitoringcomponenten<\/h3>\n<p>\nAllereerst monitoren we de applicaties: onze PHP-code, applicaties en microservices \u2014 kortom, alles wat onze ontwikkelaars schrijven. Alle applicaties sturen metrics via UDP naar de aggregator Brubeck (statsd, herschreven in C). Dit bleek de snelste te zijn op basis van synthetische tests. En het stuurt al geaggregeerde metrics via TCP naar Graphite. <\/p>\n<p>Het heeft een type metric genaamd timers. Dit is een erg handige functie. Bijvoorbeeld, voor elke gebruikersverbinding met de service stuur je een metric met de response time naar Brubeck. Er kwamen een miljoen antwoorden binnen, maar de aggregator gaf slechts 10 metrics weer. Je hebt het aantal binnenkomende mensen, de maximale, minimale en gemiddelde responstijd, de mediaan en 4 percentielen. Vervolgens worden de gegevens naar Graphite verzonden en zien we ze allemaal live. <\/p>\n<p>We hebben ook aggregatie voor metrics met betrekking tot hardware, software, systeemmetrics en ons oude monitoringsysteem Munin (dat tot 2015 bij ons functioneerde). Al deze gegevens verzamelen we via de C-daemon CollectD (die beschikt over een hele reeks verschillende plugins; het kan alle bronnen van het hostsysteem waarop het is ge\u00efnstalleerd ondervragen, door simpelweg aan te geven waar de gegevens in de configuratie geschreven moeten worden) en schrijven we via hem naar Graphite. Ook ondersteunt het python- en shellscript-plugins, zodat je je eigen aangepaste oplossingen kunt schrijven: CollectD verzamelt deze gegevens van een lokale of externe host (stel dat er Curl is) en verstuurt ze naar Graphite. <\/p>\n<p>Vervolgens sturen we alle verzamelde metrics naar Carbon-c-relay. Dit is de Carbon Relay-oplossing van Graphite, aangepast in C. Het is een router die alle metrics verzamelt die we van onze aggregators verzenden en deze routeert naar de nodes. Tijdens de routering controleert het ook de geldigheid van de metrics. Ten eerste moeten ze voldoen aan het schema met de prefixes dat ik eerder heb getoond en ten tweede moeten ze geldig zijn voor Graphite. Anders worden ze verworpen. <\/p>\n<p>Daarna stuurt Carbon-c-relay de metrics naar het Graphite-cluster. We gebruiken Carbon-cache, herschreven in Go, als onze belangrijkste opslag voor metrics. Go-carbon overtreft Carbon-cache in prestaties aanzienlijk vanwege zijn multithreading. Het accepteert gegevens en schrijft deze op schijven met behulp van het whisper-pakket (de standaard, geschreven in Python). Om gegevens uit onze opslag te lezen, gebruiken we de Graphite API. Dit werkt veel sneller dan de standaard Graphite WEB. Wat gebeurt er daarna met de gegevens? <\/p>\n<p>Ze gaan naar Grafana. Als primaire gegevensbron gebruiken we onze Graphite-clusters, plus we hebben Grafana als webinterface voor het weergeven van metrics en het bouwen van dashboards. Voor elke service cre\u00ebren ontwikkelaars hun eigen dashboard. Daarna bouwen ze grafieken waarmee de metrics worden weergegeven die ze vanuit hun applicaties verzenden. Naast Grafana hebben we ook SLAM. Dit is een Python-daemon die SLA's berekent op basis van gegevens uit Graphite. Zoals ik al zei, hebben we een paar decennia microservices, elk met hun eigen vereisten. Met behulp van SLAM raadplegen we de documentatie en vergelijken deze met wat er in Graphite is, en we vergelijken hoe goed de vereisten overeenkomen met de beschikbaarheid van onze diensten. <\/p>\n<p>Laten we verder gaan: alerting. Dit is georganiseerd met behulp van een sterk systeem - Moira. Het is onafhankelijk omdat het onder de motorkap zijn eigen Graphite heeft. Ontwikkeld door jongens van SKB 'Kontur', geschreven in Python en Go, volledig open source. Moira ontvangt dezelfde stroom die naar Graphite gaat. Als om de een of andere reden uw opslag uitvalt, blijft uw alerting werken.<\/p>\n<p>Moira draait in Kubernetes en gebruikt een cluster van Redis-servers als de belangrijkste database. Het resultaat is een fouttolerant systeem. Het vergelijkt de stroom van metrics met een lijst van triggers: als er geen vermeldingen zijn, wordt de metric gedropt. Zo kan het gigabytes aan metrics per minuut verwerken. <\/p>\n<p>Daarnaast hebben we een bedrijfs-LDAP eraan gekoppeld, waarmee elke gebruiker van het bedrijfsysteem meldingen kan aanmaken voor bestaande (of nieuw gecre\u00eberde) triggers. Aangezien Moira Graphite bevat, ondersteunt het al zijn functies. Je kopieert eerst een regel naar Grafana om te zien hoe de gegevens op de grafieken worden weergegeven. Vervolgens neem je dezelfde regel en kopieer je deze naar Moira. Je stelt er limieten aan in en ontvangt de alerting. Voor dit alles heb je geen specifieke kennis nodig. Moira kan alerten per sms, e-mail, in Jira, Slack... Bovendien ondersteunt het het uitvoeren van aangepaste scripts. Wanneer er een trigger plaatsvindt waar het aan een aangepast script of binaire app is gekoppeld, start het dit en geeft het JSON via stdin aan deze binaire app. Jouw programma moet dit parseren. Wat je met deze JSON doet, is aan jou. Wil je het naar Telegram sturen, of taken in Jira openen, doe wat je wilt. <\/p>\n<p>Voor alerting gebruiken we ook een eigen ontwikkeling \u2014 Imagotag. We hebben een paneel, dat normaal gesproken wordt toegepast voor elektronische prijslabels in winkels, aangepast voor onze taken. We hebben de triggers uit Moira daarop weergegeven. Daar staat in welke status ze zijn en wanneer het gebeurde. Een deel van het ontwikkelingsteam heeft de meldingen in Slack en via e-mail opgegeven ten gunste van dit paneel. <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring als een service: modulaire systeem voor microservicesarchitectuur\" src=\"\/wp-content\/uploads\/2019\/11\/bcf454c96adaa0cff81f5e56db5b715c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn omdat we een progressief bedrijf zijn, hebben we ook Kubernetes in dit systeem gemonitord. We hebben het systeem ge\u00efntegreerd via Heapster, dat we in het cluster hebben ge\u00efnstalleerd; dit verzamelt gegevens en verstuurt ze naar Graphite. Het schema ziet er als volgt uit: <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring als een service: modulaire systeem voor microservicesarchitectuur\" src=\"\/wp-content\/uploads\/2019\/11\/cca0f2f9f590fc84609d48e52ebd0d21.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Monitoringcomponenten<\/h3>\n<p>Hier is een lijst van links naar de componenten die we hebben gebruikt voor deze taak. Ze zijn allemaal open-source. <\/p>\n<h4>Graphite:<\/h4>\n<p><\/p>\n<ul>\n<li>go-carbon: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/lomik\/go-carbon\">github.com\/lomik\/go-carbon<\/a><\/noindex><\/li>\n<li>whisper: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/graphite-project\/whisper\">github.com\/graphite-project\/whisper<\/a><\/noindex> <\/li>\n<li>graphite-api: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/brutasse\/graphite-api\">github.com\/brutasse\/graphite-api<\/a><\/noindex> <\/li>\n<\/ul>\n<h4>Carbon-c-relay: <\/h4>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/grobian\/carbon-c-relay\">github.com\/grobian\/carbon-c-relay<\/a><\/noindex> <\/p>\n<h4>Brubeck: <\/h4>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/brubeck\">github.com\/github\/brubeck<\/a><\/noindex> <\/p>\n<h4>Collectd:<\/h4>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/collectd.org\/\">collectd.org<\/a><\/noindex><\/p>\n<h4>Moira: <\/h4>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/moira-alert\">github.com\/moira-alert<\/a><\/noindex> <\/p>\n<h4>Grafana: <\/h4>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/grafana.com\/\">grafana.com<\/a><\/noindex> <\/p>\n<h4>Heapster: <\/h4>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/heapster\">github.com\/kubernetes\/heapster<\/a><\/noindex><\/p>\n<h3>Statistieken<\/h3>\n<p>\nHier zijn een paar cijfers over hoe ons systeem werkt. <\/p>\n<h4>Aggregator (brubeck)<\/h4>\n<p>\nAantal metrics: ~ 300.000 \/ sec<br \/>\nVerzendinterval van metrics naar Graphite: 30 sec<br \/>\nServerbronnen gebruik: ~ 6% CPU (betreft volledige servers); ~ 1Gb RAM; ~ 3 Mbps LAN<\/p>\n<h4>Graphite (go-carbon)<\/h4>\n<p>\nAantal metrics: ~ 1.600.000 \/ min<br \/>\nUpdatesnelheid van metrics: 30 sec<br \/>\nOpslagschema van metrics: 30sec 35d, 5min 90d, 10min 365d (geeft inzicht in wat er op lange termijn met de service gebeurt) <br \/>\nServerbronnen gebruik: ~ 10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN<\/p>\n<h3>Flexibiliteit<\/h3>\n<p>\nBij Avito waarderen we de flexibiliteit in onze monitoringservice enorm. Hoe is het zo tot stand gekomen? Ten eerste, de onderdelen zijn uitwisselbaar: zowel de componenten als hun versies. Ten tweede \u2014 onderhoudbaarheid. Aangezien het hele project op open source is gebaseerd, kunt u zelf de code aanpassen, wijzigingen aanbrengen en functies implementeren die niet standaard beschikbaar zijn. We gebruiken vrij gangbare stacks, voornamelijk Go en Python, dus dat is vrij eenvoudig. <\/p>\n<p>Hier is een voorbeeld van een echt probleem. Een metric in Graphite is een bestand. Het heeft een naam. De bestandsnaam = de naam van de metric. En er is een pad naar dit bestand. Bestandsnamen in Linux zijn beperkt tot 255 tekens. En wij hebben (als 'interne opdrachtgevers') jongens uit de database-afdeling. Zij zeggen tegen ons: 'Wij willen onze SQL-query's monitoren. En deze zijn niet 255 tekens, maar 8 MB elk. We willen ze weergeven in Grafana, de parameters van deze query zien, en nog beter, we willen de top van dergelijke query's zien. Het zou geweldig zijn als dit in real-time kan worden weergegeven. En nog beter zou het zijn als we dit in alerts kunnen integreren.' <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring als een service: modulaire systeem voor microservicesarchitectuur\" src=\"\/wp-content\/uploads\/2019\/11\/e1136c7fd0b6156c0c3fd49bab54737e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Een voorbeeld van een SQL-query is als voorbeeld genomen van <noindex><a rel=\"nofollow\" href=\"https:\/\/postgrespro.ru\/docs\/postgrespro\/9.6\/queries-with\">de website postgrespro.ru<\/a><\/noindex> <\/i><\/p>\n<p>We starten een Redis-server en via onze Collectd-plugins, die toegang hebben tot Postgres en alle gegevens daar ophalen, versturen we metrics naar Graphite. Maar we vervangen de naam van de metric door hashes. Deze hash wordt tegelijk naar Redis gestuurd als sleutel, en de hele SQL-query als waarde. We moeten ervoor zorgen dat Grafana toegang kan krijgen tot Redis en deze informatie kan ophalen. We openen de Graphite API, omdat dit de hoofdinterface is voor de interactie van alle monitoringcomponenten met Graphite, en voegen daar een nieuwe functie toe die aliasByHash() heet \u2014 we krijgen de naam van de metric van Grafana en gebruiken deze als sleutel in de Redis-query, waarbij we als reactie de waarde van de sleutel ontvangen, dat onze \u201cSQL-query\u201d is. Op deze manier hebben we de visualisatie van de SQL-query in Grafana mogelijk gemaakt, die normaal gesproken niet getoond kon worden, samen met de statistieken ervan (calls, rows, total_time, \u2026). <\/p>\n<h3>Conclusies <\/h3>\n<p>\n<b>Beschikbaarheid.<\/b> Onze monitoringservice is 24\/7 beschikbaar vanuit elke applicatie en elke code. Als je toegang hebt tot de opslagplaatsen, kun je gegevens naar de service schrijven. De taal is niet belangrijk, de oplossingen zijn niet belangrijk. Je hoeft alleen te weten hoe je een socket opent, de metric uploadt en de socket sluit. <\/p>\n<p><b>Reliability.<\/b> Alle componenten zijn fouttolerant en kunnen onze belasting goed aan. <\/p>\n<p><b>Lage instapdrempel.<\/b> Om dit systeem te gebruiken, hoef je geen programmeertalen of queries in Grafana te leren. Je opent gewoon je applicatie, vult de socket in die metrics naar Graphite zal sturen, sluit deze, opent Grafana, maakt dashboards aan en bekijkt het gedrag van je metrics, terwijl je meldingen ontvangt via Moira.<\/p>\n<p><b>Zelfstandigheid.<\/b> Dit alles kan je zelf doen, zonder hulp van DevOps-engineers. En dit is overkill, want je kunt je project nu al monitoren, je hoeft niemand te vragen \u2014 niet om te beginnen, niet voor wijzigingen. <\/p>\n<h3>Waar streven we naar? <\/h3>\n<p>\nAlles wat hieronder staat, zijn geen abstracte gedachten, maar doelen waarop minstens de eerste stappen zijn gezet. <\/p>\n<ol>\n<li>Anomaliedetector. We willen een service implementeren die onze Graphite-opslagplaatsen bezoekt en elke metric controleert met verschillende algoritmen. Er zijn al algoritmen die we willen inspecteren, we hebben de gegevens en we weten hoe we ermee moeten werken.\n<\/li>\n<li>Metadata. We have many services that change over time, just like the people who work with them. Keeping documentation up to date manually is not an option. Therefore, we now embed metadata into our microservices. It specifies who developed it, the languages it interacts with, SLA requirements, where and to whom to send notifications. During the deployment of a service, all entity data is created automatically. In the end, you receive two links \u2014 one for triggers and the other for dashboards in Grafana.\n<\/li>\n<li>Monitoring in every home. We believe that all developers should use such a system. In this case, you always understand where your traffic is, what is happening to it, where it drops, and where its weak points are. If something happens that overwhelms your service, you will find out not during a call from a manager, but through an alert, and you can immediately open fresh logs and see what happened.\n<\/li>\n<li>High performance. Our project is constantly growing, and today it handles about 2,000,000 metric values per minute. A year ago, this number was 500,000. And growth continues, which means that after a while, Graphite (whisper) will start to heavily load the disk subsystem. As I mentioned, this monitoring system is quite versatile due to the interchangeability of components. Some specifically maintain and continuously expand their infrastructure for Graphite, but we chose a different path: to use <noindex><a rel=\"nofollow\" href=\"https:\/\/clickhouse.yandex\/\">ClickHouse<\/a><\/noindex> as storage for our metrics. This transition is nearly complete, and soon I will provide more details on how it was done: what challenges there were and how they were overcome, how the migration process went, and I will describe the components chosen for integration and their configurations. \n<\/li>\n<\/ol>\n<p>\nThank you for your attention! Feel free to ask your questions on the topic, and I will try to answer them here or in future posts. Perhaps some of you have experience building a similar monitoring system or transitioning to Clickhouse in a comparable situation \u2014 please share it in the comments.<br \/>\n<br \/>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/335410\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043d\u0430 \u043d\u0430\u0448\u0435\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u0435, \u043f\u043e\u043c\u0438\u043c\u043e \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u043d\u043e\u0433\u043e \u043a\u043e\u0434\u0430, \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u0443\u044e\u0442 \u0434\u0435\u0441\u044f\u0442\u043a\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432. \u041a\u0430\u0436\u0434\u044b\u0439 \u0438\u0437 \u043d\u0438\u0445 \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u0435\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043b\u0438. \u0414\u0435\u043b\u0430\u0442\u044c \u044d\u0442\u043e \u0432 \u0442\u0430\u043a\u0438\u0445 \u043e\u0431\u044a\u0435\u043c\u0430\u0445 \u0441\u0438\u043b\u0430\u043c\u0438 DevOps-\u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043e\u0432 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0442\u0438\u0447\u043d\u043e. \u041c\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043a\u0430\u043a \u0441\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432. \u041e\u043d\u0438 \u043c\u043e\u0433\u0443\u0442 \u0441\u0430\u043c\u043e\u0441\u0442\u043e\u044f\u0442\u0435\u043b\u044c\u043d\u043e \u043f\u0438\u0441\u0430\u0442\u044c \u043c\u0435\u0442\u0440\u0438\u043a\u0438 \u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430, \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c\u0441\u044f \u0438\u043c\u0438, \u0441\u0442\u0440\u043e\u0438\u0442\u044c \u043d\u0430 \u0438\u0445 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0438 \u0434\u0430\u0448\u0431\u043e\u0440\u0434\u044b, \u043f\u0440\u0438\u043a\u0440\u0443\u0447\u0438\u0432\u0430\u0442\u044c \u043a \u043d\u0438\u043c \u0430\u043b\u0435\u0440\u0442\u044b, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52115","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043d\u0430 \u043d\u0430\u0448\u0435\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u0435, \u043f\u043e\u043c\u0438\u043c\u043e \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u043d\u043e\u0433\u043e \u043a\u043e\u0434\u0430, \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u0443\u044e\u0442 \u0434\u0435\u0441\u044f\u0442\u043a\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432. \u041a\u0430\u0436\u0434\u044b\u0439 \u0438\u0437 \u043d\u0438\u0445 \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u0435\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043b\u0438. \u0414\u0435\u043b\u0430\u0442\u044c \u044d\u0442\u043e \u0432 \u0442\u0430\u043a\u0438\u0445 \u043e\u0431\u044a\u0435\u043c\u0430\u0445 \u0441\u0438\u043b\u0430\u043c\u0438 DevOps-\u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043e\u0432 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0442\u0438\u0447\u043d\u043e.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u043a\u0430\u043a \u0441\u0435\u0440\u0432\u0438\u0441: \u043c\u043e\u0434\u0443\u043b\u044c\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043b\u044f \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043d\u0430 \u043d\u0430\u0448\u0435\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u0435, \u043f\u043e\u043c\u0438\u043c\u043e \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u043d\u043e\u0433\u043e \u043a\u043e\u0434\u0430, \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u0443\u044e\u0442 \u0434\u0435\u0441\u044f\u0442\u043a\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432. \u041a\u0430\u0436\u0434\u044b\u0439 \u0438\u0437 \u043d\u0438\u0445 \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u0435\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043b\u0438. \u0414\u0435\u043b\u0430\u0442\u044c \u044d\u0442\u043e \u0432 \u0442\u0430\u043a\u0438\u0445 \u043e\u0431\u044a\u0435\u043c\u0430\u0445 \u0441\u0438\u043b\u0430\u043c\u0438 DevOps-\u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043e\u0432 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0442\u0438\u0447\u043d\u043e.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T10:59:47+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Monitoring als service: modulaire systeem voor microservicesarchitectuur | ProHoster","description":"Vandaag functioneren op ons project, naast monolithische code, tientallen microservices. Elk van hen vereist monitoring. Dit op dergelijke schaal door DevOps-engineers is problematisch.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u043a\u0430\u043a \u0441\u0435\u0440\u0432\u0438\u0441: \u043c\u043e\u0434\u0443\u043b\u044c\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043b\u044f \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b | ProHoster","og:description":"\u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043d\u0430 \u043d\u0430\u0448\u0435\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u0435, \u043f\u043e\u043c\u0438\u043c\u043e \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u043d\u043e\u0433\u043e \u043a\u043e\u0434\u0430, \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u0443\u044e\u0442 \u0434\u0435\u0441\u044f\u0442\u043a\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432. \u041a\u0430\u0436\u0434\u044b\u0439 \u0438\u0437 \u043d\u0438\u0445 \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u0435\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043b\u0438. \u0414\u0435\u043b\u0430\u0442\u044c \u044d\u0442\u043e \u0432 \u0442\u0430\u043a\u0438\u0445 \u043e\u0431\u044a\u0435\u043c\u0430\u0445 \u0441\u0438\u043b\u0430\u043c\u0438 DevOps-\u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043e\u0432 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0442\u0438\u0447\u043d\u043e.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T21:00:00+00:00","article:modified_time":"2020-02-18T10:59:47+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52115","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 02:30:22","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:49:49","updated":"2026-01-24 02:30:22","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/52115","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=52115"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/52115\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=52115"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=52115"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=52115"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}