мониторинг grafana windows server

Мониторинг вашей инфраструктуры с помощью Grafana, InfluxDB и CollectD

У компаний, которым необходимо управлять данными и приложениями на более чем одном сервере, во главу угла поставлена инфраструктура.

Для каждой компании значимой частью рабочего процесса является мониторинг инфраструктурных узлов, особенно при отсутствии прямого доступа для решения возникающих проблем. Более того, интенсивное использование некоторых ресурсов может быть индикатором неисправностей и перегрузок инфраструктуры. Однако мониторинг может использоваться не только для профилактики, но и для оценки возможных последствий использования нового ПО в продакшне. Сейчас для отслеживания потребляемых ресурсов на рынке существует несколько готовых к использованию решений, но с ними, тем не менее, возникают две ключевые проблемы: дороговизна установки и настройки и связанные со сторонним ПО вопросы безопасности.

Первая проблема это вопрос цены: стоимость может варьироваться от десяти евро (потребительские расценки) до нескольких тысяч (корпоративные расценки) в месяц, в зависимости от числа подлежащих мониторингу хостов. Для примера, предположим что мне нужен мониторинг трех узлов в течение одного года. При цене в 10 евро в месяц я потрачу 120 евро, тогда как небольшая компания будет вынуждена раскошелиться на десять-двадцать тысяч, что окажется финансово несостоятельным решением и попросту подорвет весь бюджет.

Вторая проблема это стороннее ПО. Учитывая, что для анализа данные пользователя — будь то частное лицо или компания — должны обрабатываться третьей стороной, возникает вопрос: каким образом третья сторона собирает данные и представляет их пользователю? Обычно для этого на узел устанавливают специальное приложение, через которое и ведется мониторинг, но зачастую такие приложения успевают устареть или оказываются несовместимы с операционной системой клиента. Опыт исследователей в области информационной безопасности проливает свет на проблемы в работе с «проприетарным ПО». Стали бы вы доверять такому ПО? Я — нет.

У меня есть свои узлы как для Tor, так и для некоторых криптовалют, поэтому для мониторинга я предпочитаю бесплатные, легко настраиваемые альтернативы с открытыми исходниками. В этом посте мы рассмотрим три таких инструмента: Grafana, InfluxBD и CollectD.

Мониторинг

Для эффективного анализа каждой метрики нашей инфраструктуры нужно приложение, способное подхватывать статистику с интересующих нас устройств. В этом отношении нам на помощь приходит CollectD: этот демон группирует и собирает («collects», потому и такое имя) все параметры, которые можно хранить на диске или передать по сети.

Данные затем будут переданы инстансу InfluxDB: это база данных временных рядов (time series database, TSBD), которая связывает данные со временем (закодированным в UNIX временную метку) в которое их получил сервер. Таким образом, отправленные CollectD данные поступят уже как последовательность событий.

Наконец, мы воспользуемся Grafana: эта программа свяжется с InfluxDB и отобразит данные на удобных для пользователя цветастых приборных панелях. Благодаря всевозможным графикам и гистограммам мы сможем в реальном времени отслеживать данные CPU, оперативной памяти и так далее.

InfluxDB

Давайте начнем с InfluxDB, свободно распространяемой TSBD для хранения данных в виде последовательности событий. Эта разработанная на Go база данных станет сердцем нашей мониторинговой «системы».

Всякий раз при поступлении данных к ним по умолчанию привязывается UNIX метка. Гибкость такого подхода освобождает пользователя от необходимости хранить переменную «time», что в противном случае оказывается довольно сложным. Давайте представим, что у нас есть несколько расположенных на разных материках устройств. Каким образом мы будем обрабатывать переменную «time»? Станем ли мы привязывать все данные ко времени по Гринвичу, или мы зададим каждому узлу свой часовой пояс? Если данные сохраняются в разных часовых поясах, каким образом нам корректно отобразить их на графиках? Как можно видеть, проблемы возникают одна за другой.

Так как InfluxDB отслеживает время и автоматически проставляет метки на каждое поступление данных, она может синхронно записывать данные в конкретную базу данных. Именно поэтому InfluxDB часто представляют в виде таймлайна: запись данных не влияет на производительность базы данных (что порой случается у MySQL), поскольку запись это всего лишь добавление конкретного события в таймлайн. Поэтому название программы происходит от восприятия времени как бесконечного и неограниченного «потока».

Установка и настройка

Еще одно преимущество InfluxDB заключается в простоте установки и предоставляемой сообществом проекта, которое его широко поддерживает, объемной документации. У InfluxDB есть два типа интерфейса: командная строка (удобный инструмент для разработчиков, но плохо подготовлена к работе с большими объемами данных) и HTTP API для прямого взаимодействия с базой данных.

Скачать InfluxDB можно не только с официального сайта, но и через систему управления пакетами (мы продемонстрируем это через Debian). Кроме того, перед установкой рекомендуется проверить пакеты через GPG, поэтому ниже мы импортируем ключи пакета InfluxDB:

Наконец, мы обновим и установим InfluxDB:

Для запуска мы воспользуемся systemctl :

В том же CLI интерфейсе мы создадим базу данных «metrics», в которой и будем хранить наши метрики.

Затем мы настроим конфигурацию InfluxBD ( /etc/influxdb/influxdb.conf ) таким образом, чтобы интерфейс открывался через порт 24589 (UDP) с прямым соединением к базе данных «metrics» для поддержки CollectD. Также нам надо будет скачать файл types.db и поместить его по адресу /usr/share/collectd/ (или в любую другую папку) для корректного определения данных, которые CollectD передает в родном формате.

Больше про CollectD в конфигурации можно прочесть в документации.

CollectD

CollectD в нашей мониторинговой инфраструктуре будет исполнять роль агрегатора данных, который упрощает передау данных до InfluxDB. По определению CollectD собирает метрики с CPU, оперативной памяти, жестких дисков, сетевых интерфейсов, процессов… Потенциал этой программы безграничен, особенно если учесть широкий выбор как уже доступных плагинов, так и набор запланированных.

Как можно видеть, установка CollectD проста:

Давайте проиллюстрируем работу CollectD упрощенным примером. Допустим, я хочу знать число процессов на моем узле. Для проверки этого CollectD совершит вызов API чтобы узнать число процессов за единицу времени (по определению это 5000 миллисекунд) и ничего более. Как только агрегатор получит данные, он передаст их для настройки в InfluxDB через модуль (под названием «Network»), который нам надо будет настроить.

Я предлагаю изменить в файле конфигурации имя хоста, который пересылается InfluxDB (в нашей инфраструктуре это «централизованная» база данных, поскольку она расположена на одном узле). Таким образом, к нам не будут поступать лишние данные и исчезнет риск перезаписи данных другими узлами.

Grafana

Один график стоит тысячи изображений

Беря во внимание перефразированную цитату, наблюдение за метриками инфраструктуры в режиме реального времени через графики и таблицы дает нам действовать эффективно и своевременно. Для создания и настройки приборной панели наших графиков и таблиц мы воспользуемся Grafana.

Grafana это совместимый с широким набором баз данных (включая InfluxDB) свободно распространяемый инструмент по графическому отображению метрик, в котором пользователь может создавать оповещения об удовлетворении частью данных конкретного условия. Например, если ваш процессор достигает пиковых значений, оповещение может прийти вам в Slack, Mattermost, на почту и так далее. Более того, свои оповещения я настроил так, чтобы активно отслеживать каждый случай, когда кто-то «заходит» в мою инфраструктуру.

Grafana не требует каких-то особых настроек: как мы уже отметили ранее, InfluxDB «сканирует» переменную «time». Сама же интеграция очень проста: мы начнем с импорта публичного ключа чтобы добавить пакет с официального сайта Grafana (он зависит от вашей операционной системы):

Затем запустим его через systemctl:

Теперь, когда мы перейдем в браузере на страницу localhost:3000, мы должны будем увидеть интерфейс входа в Grafana. По определению, зайти можно через логин admin и пароль admin (после первого входа учетные данные рекомендуется сменить).

Давайте перейдем в раздел Sources (Источники) и добавим туда нашу базу данных Influx:

Теперь под надписью New Dashboard виднеется небольшой зеленый прямоугольник. Наведите на него свой курсор и выберите Add Panel (Добавить Панель), а затем Graph (График):

Теперь можно увидеть график с тестовыми данными. Нажмите на заголовок этой диаграммы и нажмите Edit(Изменить). С Grafana можно создавать умные запросы: вам не нужно знать каждое поле в базе, Grafana предложит их вам из списка подходящих для анализа параметров.

Писать запросы еще никогда не было так легко: просто выберите интересующую вас метрику и нажмите Refresh (Обновить). Еще я рекомендую разделить метрики по хостам, чтобы было проще изолировать проблемы. Если вам интересны другие идеи по созданию контрольных панелей, для вдохновения можно посетить сайт Grafana со всевозможными примерами.

Мы заметили, что Grafana это очень легко расширяемый инструмент, и он позволяет нам сравнивать очень разные по сравнению друг с другом данные. Нет ни одной метрики, которую нельзя было бы заполучить, так что вас ограничивает только ваша же изобретательность. Отслеживайте ваши устройства и получайте самый полный обзор вашей инфраструктуры в реальном времени!

Источник

Мониторинг за час: influxdb, telegraf, grafana

В этом посте описаны установка и настройка связки технологий, позволяющих быстро и достаточно просто получить работающий сервис мониторинга.

В заключении приведен скрипт на ansible, позволяющий развернуть все это легким движением руки.

Предусловия

Все дальнейшие действия выполняются на машине с установленным CentOS7/Red Hat 7.

В рамках этого поста мы упрощаем эту схему и она принимает следующий вид:

Установка и настройка InfluxDB

Начнем с базы, в которой будут храниться результаты наших измерений.

Добавим репозиторий в менеджер пакетов YUM:

Установим influxdb и запустим сервис:

Чтобы сервис работал после перезагрузки машины, введем команду:

Проверяем, что все прошло хорошо, выполнив в консоли команду:

Создадим нашу первую базу командой:

Посмотрим что получилось:

Попробуем добавить в базу значения. В документации указан такой формат:

После этого смотрим какие измерения стали доступны:

Документация обещает нам SQL-like синтаксис, пробуем:

Новые теги могут добавляться с любого момента, например так:

Используя SQL-like синтаксис легко можем получить выборку по квартире:

И даже посчитать среднюю температуру по больнице:

Также можно добавлять данные через REST API:

И читать данные через REST API в формате JSON:

На этом краткое знакомство с базой InfluxDB можно закончить, очень много подробной информации при необходимости можно найти в документации. А мы пойдем дальше.

Установка и настройка Telegraf

Далее надо сгенерировать конфигурационный файл. Для этого наберем команду:

В сгенерированном файле видим следующее:

Cмотрим пример настроек плагина exec для сбора данных произвольным скриптом:

Попробуем написать свой такой скрипт:

Добавляем метрику process_status с тегами host и proc и значением working равным 0 или 1 в зависимости от результата проверки.

Сохраняем этот скрипт как /opt/telegraf/check_karaf.sh и редактируем конфиг:

Кладем полученный конфиг в /etc/telegraf/telegraf.conf и запускаем сервис:

Данные пишутся, на этом с telegraf пока закончим, выполнив напоследок следующую команду, чтобы сервис telegraf запускался после каждой перезагрузки:

Установка и настройка Grafana

Установим и запустим Grafana:

По умолчанию grafana запустится на порту 3000. Идем браузером на http://host:3000/login, видим окно:

Авторизуемся, используя стандартные логин и пароль: admin / admin.

Если чуда не произошло и на порту 3000 искомого веб-интерфейса мы не увидели, смотрим логи в /var/log/grafana.

Далее создаем свой первый дашборд и следуя подсказкам интерфейса конструируем запрос, например так:

Дальнейший процесс носит скорее творческий, чем технический характер. По большому счету можно и не знать синтаксис SQL, а ориентироваться на настройки, предоставляемые интерфейсом Grafana.

Создав dashboard, мы можем его экспортировать в json-формате и в дальнейшем загрузить на другом хосте. Мы будем активно использовать эту возможность при создании ansible-скрипта.

Ansible-playbook для быстрого деплоя

На первом шаге плейбука мы добавляем нужные репозитории и устанавливаем telegraf, influxdb, grafana. Далее на втором шаге конфигурируем telegraf, используя шаблон jinja2, затем запускаем все сервисы и создаем источник данных/импортируем дашборд в grafana, используя REST API.

Источник

Визуальный мониторинг серверной инфраструктуры на базе Nagios + Grafana

Так мы пришли к пониманию, что надо собирать что-то самостоятельно. За основу решили взять самую гибкую и продвинутую систему, которую можно настроить для мониторинга чего и как угодно — Nagios. Настроили, поставили, работает — круто! Жаль только интерфейс сего чуда застрял где-то в середине 90-х, а нам хотелось, чтобы еще и визуальная составляющая была на уровне.

Недолгий поиск показал, что лидером среди решений по созданию красивых дашбордов является Grafana. Так и решили выводить весь наш мониторинг из Nagios на мониторах в виде красивых графиков в Grafana. Вопрос остался только в том — как их подружить друг с другом?

Общая цель

Контролировать всю инфраструктуру через Nagios, настроить оповещения о проблемах в системе через Slack, подключить вывод данных о производительности системы в графическую оболочку Grafana для мониторинга в реальном времени.

Стэк технологий

Короткое описание

Nagios собирает статистические данные со всевозможных виртуалок всей системы. Нам эти данные нужно сохранять в базу в определенном формате и с определенным интервалом, чтобы Grafana смогла их выводить. Grafana работает с несколькими форматами, но самый удобный для нас — Graphite. Graphite — по сути, такая же графическая оболочка, но его интерфейс, видимо, делали те же люди, что и интерфейс Nagios. Под капотом у него лежит база данных, которая хранит стат. данные — Whisper и прослойка для обработки этих данных — Carbon. Напрямую Nagios не умеет общаться с Graphite-ом, поэтому умные люди создали доп. плагин, который берет текущие показания из Nagios и передает их в Carbon — этот плагин называется Graphios. Таким образом, наша задача — связать воедино 6 различных технологий. Поехали!

Сразу небольшой дисклеймер:

Carbon

Ставим и настраиваем Carbon:

Проставляем значение параметра в true:

Редактируем файл схем

В этом файле представлены директивы, в которых указаны параметры хранения стат. данных: как часто сохраняются и как долго хранятся. Для себя мы используем приблизительно следующую директиву:

Это означает, что данные будут поступать в базу каждую минуту и храниться на протяжении года. Поправьте значения под свои нужды.

Также, важно понимать, что частота сохранения данных в базе не должна превышать частоту отдачи данных самим Nagios-ом — иначе мы будем складывать в базу дубликаты значений. Из коробки Nagios прослушивает все сервисы и хосты раз в 10 минут, так что если хочется добиться максимального real-time-а — нужно также изменить интервалы обработки на стороне Nagios-а.

Подключаем последний конфиг и стартуем Carbon:

Database

Подготавливаем базу для всех дальнейших программ. Мы предпочитаем PostgreSQL, но Graphite поддерживает разные базы.

Настраиваем нового пользователя и базу:

Пароль от БД нужно сохранить — он нам еще пригодится.

Graphios

Устанавливаем Python, Django и далее — сам graphios:

Редактируем файл /etc/graphios/graphios.cfg:

Создаем папку для хранения статистических выгрузок:

Тестирование:

Добавляем тестовую строку в определение сервиса Nagios:

Вызываем Graphios в тестовом режиме:

На выходе должны появляться записи типа:

Если все в норме — запускаем демона graphios:

Graphite

Graphite нужно ставить строго после установки Carbon, иначе Nagios/Graphios не смогут правильно отправлять данные

Устанавливаем основные зависимости

Далее, нужно немного поправить новый конфиг Apache2:

Меняем «WSGISocketPrefix /etc/httpd/wsgi/» на:

Добавляем еще один алиас после строчки «Alias /content/ /opt/graphite/webapp/content/»:

Настраиваем local_settings.py

В открывшемся файле включаем строки и проставляем значения:

SECRET_KEY нужно придумать, а значения для директивы DATABASE берем из ранее созданной базы.
Значение WHISPER_DIR можно найти через команду «locate whisper«.

Настраиваем Graphite

В процессе конфигурации, система попросит завести супер-пользователя. Нужно проставить новые значения и запомнить их.

Grafana

Самая простая часть — если Graphite/Carbon настроены правильно — достаточно будет подключить новый ресурс типа Graphite и настроить дашборд для вывода данных — Grafana сама сделает все остальное!

Интерфейс будет доступен на 3000 порту. Дефолтные логин/пароль — admin.

Бонус: Slack Nagios App

Как альтернатива прямой визуализации и пассивным письмам — подключим также вывод оповещений из Nagios в Slack.

1) Создаем новый канал в Slack, например #alerts

2) Идем на страницу приложений Slack-а

3) Находим приложение Nagios

4) Следуем инструкциям по загрузке конфига

5) Копируем токен и домен Slack и вставляем их в новый конфиг /usr/local/bin/slack_nagios.pl

6) Копируем директивы Nagios и вставляем в соответствующие места (команды и новый контакт)

7) Сохраняем, перегружаем Nagios, проверяем.

Источник

Monitoring Windows Services with Grafana, InfluxDB ‎and Telegraf

If you are a Windows Server administrator or a power user on Windows instances, you may have experienced the great sense of frustration that comes with services shutting down for no reason.

The worst of it comes when you happen to discover it way too late, leading to obvious useless costs for your team.

The goal of this tutorial is to help you put an end to this maddening, yet ultimately, avoidable waste of resources. Among other things, we show how to build a complete stack for DevOps engineers to monitor Windows services — and get alerts when one of them fails.

What you will learn

Before jumping right into the technical implementation, here’s the list of everything that you are going to learn if you follow the tutorial until the end:

Now that you know the skills that you are going to acquire, let’s first have a quick introduction about performance counters on Windows machines.

What are performance counters?

Performance Counters on Windows machines are native components that record and monitor data for a variety of tools on your machine such as: your CPU, your disks, processes, databases (if you are running some, like MySQL) and even ASP.NET applications.

Windows exposes an API that any tool can query in order to retrieve statistics from performance counters. Visual tools are also provided for you to take a look at metrics in real-time.

An example of a visual tool is the Performance Monitor, directly shipped on every Windows machine.

Performance Monitor accessed via the start menu

If you open the performance monitor, you can navigate to Monitoring Tools > Performance Monitor on the left menu.

There, by clicking on the green add button, you are exposed to a set of high-levels metrics available on your computer.

Process, PhysicalDisk, LogicalDisk and Databases are among the metrics that can be added to the graph that is refreshed periodically.

Low-cost Grafana!

Playing with the Performance Monitor is already a good way to get a sense of what one can monitor. Before jumping right into Telegraf, you may want to experiment a bit with the Performance Monitor.

Now that you know a bit more about the Performance Counters, let’s have a look at exactly how we are going to build our monitoring architecture.

Building a classic monitoring architecture

When building monitoring architectures for personal use, most of the time, you want to reunite three components:

In this case, Telegraf will periodically queries the Windows Performance Counters API and send the results to InfluxDB. Those results will be accessible and explorable in Grafana.

Installing the different tools

Now that we know exactly what we are going to build, let’s install the different tools that we need.

a – Installing InfluxDB

Before configuring any monitoring agent, it is important to have a time series database first.

Launching Telegraf without InfluxDB would result in many error messages that won’t be very relevant.

When saved, unzip the content wherever you want, launch a command line and navigate to the folder where you stored your binaries (in my case, directly in Program Files). Once there, you will be presented with a couple of files:

InfluxDB does not ship as a service yet, even if it is completely doable to configure it as a user-defined service on Windows.

b – Installing Telegraf

Telegraf installation on Windows can be a bit tricky.

To download Telegraf, head over to the InfluxDB downloads page and click on the latest version of Telegraf available.

Telegraf installation should be done in the Program Files folder, in a folder named Telegraf.

Launch a Powershell instance as an administrator. Head over to the Program Files folder and run:

Drop the executables downloaded here, and run:

As a consequence, Telegraf should be installed as a service and available in Windows services. Telegraf configuration file should be configured to retrieve metrics from your CPU and disk. To test it, run:

If everything is running okay, you should start seeing metrics aggregating in InfluxDB.

To check it, head over to InfluxDB folder (where you dropped your executables) and run influx.exe.

You should be presented with a CLI, where you’ll type your first IFQL queries.

If you are unfamiliar with basics of InfluxDB and what IFQL is, check my ultimate InfluxDB guide for beginners. It contains good explanations regarding everything that you need to know: https://devconnected.com/the-definitive-guide-to-influxdb-in-2019/

c – Installing Grafana

For this tutorial, we are going to use the brand new Grafana v6.

Head over to Grafana download page, download the zip and unzip it wherever you want. Similarly to what you did with InfluxDB, head over to the folder where you stored your executables and run the Grafana server (grafana-server.exe in bin folder).

By default, Grafana will run on port 3000. Default credentials are admin/admin (you are prompted to modify them directly at boot time).

When you’re done, you’ll be asked to configure your data sources. By default, an InfluxDB instance runs on port 8086. The following configuration should do the trick:

Now that all the tools are configured, it is time to start monitoring Windows services.

Configuring Telegraf

Before creating our awesome dashboard, we need to configure Telegraf in order for it to query the Performance Counters API we described in the first chapter.

This will be done by using the win_perf_counters plugin of Telegraf. The plugin needs to be declared in the inputs section of your configuration file. It looks like this:

The ObjectName property expects the exact same name that you would find the Performance Monitor. When in doubt about what you can query on Windows, you can either:

In our case, we want to monitor the Process object name, the ElapsedTime counter for the service we are interested in: postgres (for this example).

We can also add the ‘% Processor Time’ metric in order to stop CPU-consuming resources.
The resulting Telegraf configuration will be:

Now that everything is configured, let’s head over to Grafana and build our dashboard.

Building an awesome dashboard

This is where the fun begins.

We are going to build our dashboard in Grafana v6.0.

As a reminder, this is the dashboard that we are going to build today.

In Grafana, create a new dashboard by clicking on the plus icon on the left menu.

We chose the “Elapsed Time” metric in order to measure if services are up or down.

However, we have to perform transformations on our data as the Elapsed Time function is theoretically a never-ending growing function.

As I already did it in my article on systemd services, I will give you the widget and the query for you to reproduce this dashboard.

a – Building the performance gauge

If you want to exact same output for the gauge, head over to the Visualization Panel: in the “Value Panel,” show the ‘Last’ value and select a “percent” unit.

b – Building the “availability” graph

The key here is the difference operator.

It gives the graph a “heartbeat” look that avoids having a growing graph that rescales permanently.

If you want to have the exact same output, head over to the “Visualization” panel and click on the “Staircase” option.

The other boxes of this dashboard are just plain text panels with some CSS color, nothing special here.

You can of course tweak the examples to monitor the services you are interested in and/or modify the query to take an operator that you find more suitable to your needs.

Now that our visualization is ready, it is time to warn our DevOps team every time a service fails.

Alerting the DevOps team on service failure

Visualizing service failure is great but you don’t want to be staring at Grafana every second and wait for a service failure.

Ideally, you would want to be notified via Slack for example in order to take immediate action over the failure.

This is exactly what we are going to configure on Grafana: Slack alerts.
Let’s head to it.

In Grafana, you’ll be able to create some alerts only for the graph panel. Two steps, and we are done.

a – Creating a notification channel

Before creating the actual alert, we have to create a notification channel. In the left menu, head over to the little bell icon, and click on “Notification Channels.”

When you’re there, you are presented with a couple of fields that you have to fill. As an example, I’ll give you my own configuration.

b – Creating the alert

Now that our notification channel is created, it is time to build our final alert on the graph panel.

Head over to your dashboard, edit one of the graph panels and click on the little bell similar to the one on the left menu.

Again, I’ll provide a comprehensive screenshot on how I built my alerts.

This alert states that it will evaluate the last value provided by the query that you defined earlier for the last minute.

If it has no value, then an alert will be raised. The alert evaluation is done every 10 seconds.

You can reduce the “For” parameter too to 10s for your alert to be more reactive.

c – Emulating a service shutdown

Let’s pretend for a second that your Telegraf service is shutting down for no reason (it never happens in real-life, of course.)

Here’s the graphical result in Grafana, along with the alert raised in Slack!

Done! We finally got what the reward of this hard work. Congratulations!

Conclusion

With this tutorial, we learned many things: first, that Windows has an entire built-in API that we can leverage to our needs.

We saw how modern tools such as Telegraf, InfluxDB and Grafana can be used in order to setup a quick and efficient way to monitor applications.

In this tutorial, we took the concrete example of Windows services, but it can be applied to pretty much every performance counters that Windows exposes to its users.

IIS Monitoring, ASP.NET applications, Web Services, everything can be monitored with the Performance Counters and as a consequence implemented in Telegraf.

Knowing everything that you can now do, what metrics will you monitor on your system?
What value do you think it can bring to your company?

Leave a comment on this blog post and share your views on this project.

If you want to read more on the subject, make sure to read excellent posts written on InfluxData blog here.

They all contain valuable information for the DevOps industry.

Источник