{"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\/en\/blog\/administrirovanie\/monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury","title":{"rendered":"Monitoring as a service: a modular system for microservice architecture","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Today, in our project, alongside monolithic code, dozens of microservices are operational. Each of them requires monitoring. Doing this in such volumes with DevOps engineers is problematic. We have developed a monitoring system that works as a service for developers. They can independently write metrics to the monitoring system, use them, build dashboards based on them, and attach alerts that will trigger upon reaching threshold values. For DevOps engineers, it's just infrastructure and documentation. <\/p>\n<p>This post is a transcript of my presentation from our <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/tomicro\">session<\/a><\/noindex> at RIT++. Many have asked us to provide text versions of the talks from there. If you attended the conference or watched the video, you won't find anything new. To everyone else \u2014 welcome below the fold. I'll explain how we arrived at this system, how it works, and how we plan to update it. <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring as a service: a modular system for microservice architecture\" 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>The Past: Schemes and Plans <\/h3>\n<p>\nHow did we come to the existing monitoring system? To answer this question, we need to go back to 2015. Here's how it looked back then: <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring as a service: a modular system for microservice architecture\" src=\"\/wp-content\/uploads\/2019\/11\/d955f9bcdb5f5a5a54720c77113ca85d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWe had about 24 nodes responsible for monitoring. There was a whole bunch of various crons, scripts, daemons, that monitored something somewhere in some way, sent messages, and performed functions. We thought that the further we went, the less viable such a system would be. It made no sense to develop it: it was too cumbersome. <br \/>\nWe decided to select the elements of monitoring that we would keep and develop, and those we would abandon. There ended up being 19. We kept only Graphite, aggregators, and Grafana as the dashboard. But what would the new system look like? Like this: <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring as a service: a modular system for microservice architecture\" src=\"\/wp-content\/uploads\/2019\/11\/57d220113d0b76c05874b5d774bff8af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWe have a metrics storage: these are Graphite, which will be based on fast SSD drives, and specific aggregators for metrics. Next \u2014 Grafana for displaying dashboards and Moira for alerting. We also wanted to develop a system for anomaly detection. <\/p>\n<h3>Standard: Monitoring 2.0<\/h3>\n<p>\nThese were the plans in 2015. But we needed to prepare not only the infrastructure and the service itself but also documentation for it. We developed a corporate standard for ourselves, which we called Monitoring 2.0. What were the requirements for the system? <\/p>\n<ul>\n<li>constant availability; <\/li>\n<li>metric storage interval = 10 seconds; <\/li>\n<li>structured storage of metrics and dashboards; <\/li>\n<li>SLA &gt; 99.99% <\/li>\n<li>collection of event metrics via UDP (!). <\/li>\n<\/ul>\n<p>\nWe needed UDP because we have a large volume of traffic and events that generate metrics. If we tried to write them all to Graphite at once, the storage would crash. We also chose first-level prefixes for all metrics. <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring as a service: a modular system for microservice architecture\" src=\"\/wp-content\/uploads\/2019\/11\/d24c4474b19b532a48cef4d4376287ad.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEach prefix carries a specific property. There are metrics for servers, networks, containers, resources, applications, and so on. A clear, strict, typed filtering system is implemented where we accept first-level metrics and simply drop the rest. This is how we planned this system back in 2015. What about the present? <\/p>\n<h3>Present: the interaction scheme of monitoring components<\/h3>\n<p>\nFirst and foremost, we monitor applications: our PHP code, applications, and microservices \u2014 in short, everything that our developers create. All applications send metrics to the Brubeck aggregator via UDP (statsd, rewritten in C). It turned out to be the fastest based on synthetic test results. It sends the already aggregated metrics to Graphite via TCP. <\/p>\n<p>It includes a type of metrics known as timers. This is a very convenient tool. For instance, for each user connection to the service, you send a metric with the response time to Brubeck. A million responses came in, but the aggregator produced only 10 metrics. You have the total number of users, maximum, minimum, and average response times, the median, and four percentiles. Then, the data is transmitted to Graphite, and we see everything live. <\/p>\n<p>We also have aggregation for metrics related to hardware, software, system metrics, and our old monitoring system Munin (which was in use until 2015). All of this is collected through the C-based daemon CollectD (which comes with a wide range of plugins; it can query all resources on the host system where it's installed by simply specifying where to write the data in the configuration) and we write the data to Graphite through it. It also supports Python plugins and shell scripts, allowing you to create your custom solutions: CollectD will gather this data from a local or remote host (assuming there\u2019s Curl) and send it to Graphite. <\/p>\n<p>Next, we send all the metrics we've collected to Carbon-c-relay. This is the Carbon Relay solution from Graphite, developed in C. It acts as a router that gathers all metrics from our aggregators and routes them to nodes. During the routing process, it also validates the metrics. Firstly, they must match the prefix schema I showed earlier, and secondly, they must be valid for Graphite; otherwise, they are dropped. <\/p>\n<p>Then, Carbon-c-relay sends the metrics to the Graphite cluster. We use Carbon-cache, rewritten in Go, as the main metric storage. Go-carbon, due to its multithreading capabilities, outperforms Carbon-cache significantly in terms of performance. It ingests data and writes it to disks using the whisper package (the standard one, written in Python). To read data from our storage systems, we leverage the Graphite API, which operates much faster than the standard Graphite WEB. What happens to the data next? <\/p>\n<p>They go to Grafana. We use our Graphite clusters as the main data source, plus we have Grafana as a web interface for displaying metrics and creating dashboards. Developers set up their own dashboards for each of their services. They then build graphs on these dashboards displaying metrics sent from their applications. Besides Grafana, we also have SLAM. This is a Python daemon that calculates SLA based on data from Graphite. As I mentioned, we have several dozen microservices, each with its own requirements. With SLAM, we refer to the documentation and compare it with what\u2019s in Graphite to assess how well the requirements align with the availability of our services. <\/p>\n<p>Moving on: alerting. It is organized using a robust system \u2014 Moira. It operates independently because it has its own Graphite running underneath. Developed by the guys from SKB Kontur, it is written in Python and Go and is completely open-source. Moira receives the same data stream that goes to the Graphites. If, for any reason, your storage fails, your alerting will still function.<\/p>\n<p>We deployed Moira in Kubernetes, using a cluster of Redis servers as its primary database. As a result, it became a fault-tolerant system. It compares a stream of metrics against a list of triggers: if there are no mentions, it drops the metric. This allows it to process gigabytes of metrics per minute. <\/p>\n<p>We also integrated corporate LDAP with it, allowing each user of the corporate system to create notifications for existing (or newly created) triggers. Since Moira includes Graphite, it supports all its features. Therefore, you first take a line and copy it into Grafana to see how the data displays on the graphs. Then, you take the same line and copy it into Moira, attach limits, and obtain alerts. You don't need any specific knowledge to do all this. Moira can alert via SMS, email, Jira, Slack... It also supports executing custom scripts. When a trigger occurs and it is subscribed to a custom script or binary, it executes it and sends JSON to that binary via stdin. Consequently, your program must parse it. What you do with this JSON is up to you. You can send it to Telegram, open tasks in Jira, do whatever you want. <\/p>\n<p>We also use our own development for alerting \u2014 Imagotag. We adapted a panel typically used for electronic price tags in stores to fit our needs. We displayed the triggers from Moira on it, indicating their status and when they occurred. Some of our developers opted out of Slack and email notifications in favor of this panel. <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring as a service: a modular system for microservice architecture\" src=\"\/wp-content\/uploads\/2019\/11\/bcf454c96adaa0cff81f5e56db5b715c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAnd since we are a progressive company, we also monitored Kubernetes in this system. We integrated it using Heapster, which we installed in the cluster. It collects data and sends it to Graphite. Ultimately, the diagram looks like this: <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring as a service: a modular system for microservice architecture\" src=\"\/wp-content\/uploads\/2019\/11\/cca0f2f9f590fc84609d48e52ebd0d21.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Monitoring Components<\/h3>\n<p>Here is a list of links to the components we used for this task. All of them are 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>Statistics<\/h3>\n<p>\nHere are some statistics on how our system operates. <\/p>\n<h4>Aggregator (brubeck)<\/h4>\n<p>\nNumber of metrics: ~ 300,000 \/ sec<br \/>\nMetrics sending interval to Graphite: 30 sec<br \/>\nServer resource usage: ~ 6% CPU (referring to full servers); ~ 1Gb RAM; ~ 3 Mbps LAN<\/p>\n<h4>Graphite (go-carbon)<\/h4>\n<p>\nNumber of metrics: ~ 1,600,000 \/ min<br \/>\nMetrics update interval: 30 sec<br \/>\nMetrics storage scheme: 30sec 35d, 5min 90d, 10min 365d (provides understanding of what happens with the service over a prolonged period) <br \/>\nServer resource usage: ~ 10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN<\/p>\n<h3>doesn\u2019t stop at one thing, like Yandex.Metrica, but evolves and is used in an increasing number of different projects and industries. It can be expanded by adding new features to address new tasks. For instance, it is often believed that storing logs in a DB is outdated, which is why<\/h3>\n<p>\nAt Avito, we highly value the flexibility in our monitoring service. Why did it turn out this way? Firstly, its components are interchangeable: both the modules themselves and their versions. Secondly \u2014 maintainability. Since the entire project is built on open source, you can edit the code, make changes, and implement features that are not available out of the box. It uses fairly common stacks, mainly Go and Python, so this is quite straightforward. <\/p>\n<p>Here\u2019s an example of a real issue that arose. A metric in Graphite is a file. It has a name. The file name = the metric name. And there is a path to it. File names in Linux are limited to 255 characters. We have (acting as \"internal customers\") folks from the database department. They tell us, \"We want to monitor our SQL queries. However, they are not 255 characters but 8 MB each. We want them displayed in Grafana, to see parameters for this query, and even better, we want to see the top such queries. It would be great if it could be displayed in real-time. And it would be even cooler to push them into alerting.\" <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring as a service: a modular system for microservice architecture\" src=\"\/wp-content\/uploads\/2019\/11\/e1136c7fd0b6156c0c3fd49bab54737e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>An example SQL query is taken as an example from <noindex><a rel=\"nofollow\" href=\"https:\/\/postgrespro.ru\/docs\/postgrespro\/9.6\/queries-with\">the site postgrespro.ru<\/a><\/noindex> <\/i><\/p>\n<p>We are launching a Redis server and using our Collectd plugins, which query Postgres to retrieve all the data, sending metrics to Graphite. However, we replace the metric name with hashes. We send this same hash to Redis as a key, while the entire SQL query serves as the value. We still need to configure Grafana to query Redis to get this information. We open the Graphite API, as it is the main interface for interaction between all monitoring components and Graphite, and we add a new function called aliasByHash() \u2014 we obtain the metric name from Grafana and use it in the Redis query as the key, receiving back the value of the key, which is our \u201cSQL query\u201d. Thus, we have managed to display in Grafana the SQL query that, theoretically, couldn't be shown there, along with its statistics (calls, rows, total_time, \u2026). <\/p>\n<h3>Summary <\/h3>\n<p>\n<b>Availability.<\/b> Our monitoring service is available 24\/7 from any application and any code. If you have access to the storage, you can write data to the service. The language doesn\u2019t matter, the solutions don\u2019t matter. You only need to know how to open a socket, send a metric through it, and close the socket. <\/p>\n<p><b>Reliability.<\/b> All components are fault-tolerant and handle our loads well. <\/p>\n<p><b>Low entry threshold.<\/b> To use this system, you don\u2019t need to learn programming languages or make queries in Grafana. Just open your application, plug in the socket that will send metrics to Graphite, close it, open Grafana, create dashboards there, and monitor your metrics\u2019 behavior, receiving notifications through Moira.<\/p>\n<p><b>Independence.<\/b> All of this can be done independently, without the help of DevOps engineers. This is an overshoot, as you can monitor your project right now without needing to ask anyone \u2014 neither to start working nor for modifications. <\/p>\n<h3>What are we striving for? <\/h3>\n<p>\nAll of the points listed below are not just abstract thoughts; they represent what we have made at least initial strides towards. <\/p>\n<ol>\n<li>Anomaly detector. We want to create a service that will go into our Graphite storage and check each metric against various algorithms. We already have the algorithms we want to review, and we have the data; we know how to work with it.\n<\/li>\n<li>Metadata. We have many services, which change over time, just like the people who work with them. Keeping documentation manually is not an option. Therefore, our microservices are now embedding metadata. It specifies who developed it, the languages it interacts with, SLA requirements, and where to send notifications. During the service deployment, all the entity data is created automatically. As a result, you get two links \u2014 one for triggers and the other for dashboards in Grafana.\n<\/li>\n<li>Monitoring in every home. We believe that every developer should use such a system. In this case, you always know where your traffic is, what is happening with it, where it drops, and where its weaknesses lie. If, for example, something happens and overwhelms your service, you will find out not during a call from a manager but from an alert, and you can immediately open the latest logs and see what happened.\n<\/li>\n<li>High performance. Our project is constantly growing, and today it processes about 2,000,000 metric values per minute. A year ago, this figure was 500,000. And the growth continues, which means that after some time Graphite (whisper) will start to significantly strain the storage subsystem. As I mentioned earlier, this monitoring system is quite versatile due to the interchangeability of components. Some maintain and constantly expand their infrastructure specifically for Graphite, but we decided to take a different route: to use <noindex><a rel=\"nofollow\" href=\"https:\/\/clickhouse.yandex\/\">ClickHouse<\/a><\/noindex> as a storage for our metrics. This transition is nearly complete, and soon I will share more details about how it was done: what challenges were faced and how they were overcome, how the migration process went, and describe the selected components and their configurations. \n<\/li>\n<\/ol>\n<p>\nThank you for your attention! Please ask your questions on the topic, and I will try to answer them here or in future posts. Perhaps someone has experience building a similar monitoring system or migrating to Clickhouse in a similar situation \u2014 feel free to share in the comments.<br \/>\n<br \/>Source: <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.2 - 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\/en\/blog\/administrirovanie\/monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\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\/en\/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 as a Service: a modular system for microservice architecture | ProHoster","description":"Today, in our project, besides the monolithic code, dozens of microservices are functioning. Each of them requires monitoring. Doing this at such scales with DevOps engineers is problematic.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","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\/en\/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\/en\/wp-json\/wp\/v2\/posts\/52115","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=52115"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/52115\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=52115"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=52115"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=52115"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}