… Но не только Raspberry Pi

Это пятая статья из серии Разработка и развертывание приложений Kubernetes в кластере Raspberry Pi. Предыдущая статья Установка Kubernetes Ingress в кластере Raspberry Pi является предварительным условием и должна быть завершена перед выполнением шагов, описанных в этой статье.

Эта статья посвящена приложениям для мониторинга, развернутым в кластере Kubernetes, работающему на Raspberry Pis, в частности инфраструктуре мониторинга.

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

Последний раздел этой статьи - это список ссылок, которые я нашел полезными.

Чем не является эта статья:

  • Учебное пособие по передовым методам мониторинга приложений
  • Учебник по Prometheus, Grafana, Fluentd, Elasticsearch и Kibana

Все это важные темы, но выходящие за рамки данной статьи.

Эта статья довольно сложная, и ее завершение займет некоторое время. Возьмите свои любимые закуски и что-нибудь выпить, и приступим!

Обзор

Обзор мониторинга

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

Метрики записываются приложением для отслеживания таких вещей, как частота запросов, частота ошибок и продолжительность запроса, также называемая КРАСНЫЙ. Метрики хороши для быстрого выявления проблем - например, чрезмерного количества ошибок или неприемлемой продолжительности запроса. Метрики не определяют причину конкретной проблемы, а только то, что произошло событие проблемы. Prometheus - это один из фреймворков, который предоставляет приложению возможность записывать и хранить метрики по относительно низкой цене.

Ведение журнала обычно включает запись записей в файл или стандартный вывод. Записи журнала обычно включают такие вещи, как отметки времени и сведения о произошедшем событии. Например, запись журнала может содержать информацию об искаженном HTTP-запросе и включать информацию о запрашивающем клиенте, а также информацию о том, что конкретно было не так с запросом. Таким образом, журналы очень удобны для исследования и устранения проблем.

И метрики, и ведение журнала имеют место в мониторинге приложений. Метрики относительно дешевы, и на них легко обратить внимание. У показателей есть обратная сторона по сравнению с входом в систему: они не содержат контекста, а только информацию о том, что что-то произошло. Напротив, журналы могут предоставить контекст, необходимый для исследования и устранения проблемы. Обратной стороной журналирования является то, что контекст обходится дорого по сравнению с метриками. Метрики очень маленькие, часто это просто метка, число и временная метка. Журналы могут быть довольно объемными, и их может быть относительно сложно выявить из записи журнала.

Существует ряд ресурсов, посвященных философии и механике мониторинга. Два отличных ресурса - это руководство Google по SRE, в частности Глава 6: Мониторинг распределенных систем. Weaveworks имеет отличную рецензию на использование метрик с Prometheus и Grafana. Я также включил другие ресурсы в конце этой статьи.

Обзор статьи

В этой статье рассматривается набор инструментов, которые обычно используются как для метрик, так и для ведения журнала. Журналы можно собирать, индексировать и визуализировать с помощью так называемого стека EFK: Elasticsearch, Fluentd и Kibana. EFK - это модификация ELK, в которой для пересылки журналов используется Logstash вместо Fluentd. Метрики можно запрашивать, визуализировать и получать предупреждения через Prometheus и Grafana.

На приведенной ниже диаграмме показан стек журналов Elasticsearch-Fluentd-Kibana.

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

  1. Контейнер регистрируется в stdout.
  2. Fluentd работает на том же узле, что и модуль / контейнер, и захватывает поток сообщений журнала.
  3. Fluentd можно настроить для пересылки сообщений журнала на несколько серверов, включая Elasticsearch.
  4. Elasticsearch сохраняет и индексирует, насколько это возможно, сообщения журнала, полученные от Fluentd. Структурированное ведение журнала значительно улучшает способность Elasticsearch индексировать сообщения журнала.
  5. Kibana может запрашивать базу данных Elasticsearch и может представлять результаты в виде визуализации.

На приведенной ниже диаграмме показано, как Prometheus и Grafana вписываются в архитектуру приложения:

Поток данных метрик выглядит следующим образом:

  1. Prometheus извлекает (т. Е. извлекает) данные метрик из приложения. Приложения открывают /metrics конечную точку, обычно на порту 5000, которую Prometheus периодически опрашивает. Использование аннотаций Kubernetes позволяет Prometheus находить модули, аннотированные соответствующим набором аннотаций Prometheus.
  2. Prometheus хранит данные метрик в своей собственной базе данных временных рядов.
  3. Grafana использует PromQL, язык запросов Prometheus, для создания информационных панелей, которые можно использовать для визуализации данных метрик. Графана также может использоваться в качестве источника предупреждений. В Grafana можно установить пороговые значения для срабатывания предупреждения, когда заданная метрика выходит за пределы (например, запросы выполняются слишком долго).

Проницательные наблюдатели заметят, что и Kibana, и Grafana являются инструментами визуализации данных. Возникает вопрос: зачем нам и то, и другое? Причина в том, что текущая поддержка визуализации журналов в Grafana ограничена и находится на стадии бета-тестирования, в то время как Kibana и Elasticsearch могут управлять и отображать данные Prometheus. Учитывая бета-версию Grafana, я решил, что она не совсем готова к производственному использованию. Тем не менее, это все еще интересный вопрос. Я буду следить за этим и могу в конечном итоге использовать только один или другой для всей визуализации данных.

Прометей

Prometheus - это полный набор инструментов для системного мониторинга и оповещения. Его компоненты включают:

  • Сервер, который собирает данные метрик из включенных приложений, а также является базой данных, в которой хранятся данные временных рядов, полученные из этих приложений.
  • PromQL, язык запросов Prometheus, используемый для запросов к базе данных
  • Клиентские библиотеки для разных языков (поддерживаются большинство основных языков)
  • И другие компоненты (Документация Прометея обсуждает их более подробно)

Для установки Prometheus требуется Helm и контроллер Traefik Ingress. Если вы выполнили необходимые шаги из моей статьи о настройке Kubernetes Ingress в кластере Raspberry Pi, у вас уже будет установлен Helm и развернут Traefik. В противном случае вам нужно сначала выполнить действия, описанные в этой статье.

У меня есть репозиторий GitHub, в котором есть диаграммы Helm, необходимые для установки Prometheus. Подробные инструкции по установке и развертыванию-проверке доступны в файле README. Вкратце, шаги следующие:

  1. Клонируйте репозиторий.
  2. Выполните команду helm install ..., чтобы развернуть Prometheus.
  3. Проверьте развертывание, открыв панель управления Prometheus в веб-браузере.

Прометей также доступен в helm/charts/prometheus репозитории. Обычно это хороший источник диаграмм Helm, которые можно использовать для развертывания приложений в кластере Kubernetes. Первоначально я не использовал это из-за отсутствия поддержки ARM, но образ Docker, на который в настоящее время ссылается диаграмма, действительно включает поддержку архитектуры multiCPU, включая arm, так что это может работать. Однако он не отмечен как поддерживающий arm32v7 или armhf, которые я использовал.

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

Графана

Grafana - это платформа, которая позволяет запрашивать, визуализировать, предупреждать и понимать свои показатели независимо от того, где они хранятся. Эта возможность включает поддержку Prometheus в качестве источника данных. Grafana также может использоваться для того же с метриками, производимыми Telegraf, как описано далее в этой статье. В этом разделе описывается, как установить Grafana на Raspberry Pi.

Сначала оговорка: я не развернул Grafana в Kubernetes, так как хотел сохранить возможность перенести ее на выделенный Raspberry Pi, который не находится в кластере Kubernetes, или полностью переместить его из кластера Raspberry Pi. Причина этого в том, что мой кластер сейчас почти полностью загружен, и мне нужна гибкость, позволяющая высвободить ресурсы.

Как и в случае с предыдущими статьями, если был хороший источник того, как выполнить что-то вроде установки Kubernetes, я сослался на этот источник, чтобы получить инструкции по установке указанного пакета. Я тоже сделаю это здесь. Есть отличная статья под названием Как установить Grafana + InfluxDB на Raspberry Pi, в которой довольно хорошо описаны шаги, необходимые для установки Grafana на Raspberry Pi. Как видно из названия, в нем также рассказывается, как установить InfluxDB. Это необязательный шаг. Я рекомендую сделать это сейчас, если вы собираетесь использовать Telegraf для мониторинга машин, как описано ниже.

Если вы все же установите InfluxDB, вы можете столкнуться с моей проблемой. При проверке установки, как описано в статье выше, запустив influxd, я получил сообщение об ошибке influxd не удалось найти. Чтобы решить проблему, я удалил его через sudo apt remove influxdb. Я снова переустановил InfluxDB - очень внимательно следуя инструкциям в Как установить Grafana + InfluxDB на Raspberry Pi. Это устранило проблему, но я до сих пор не уверен, пропустил я что-то или нет.

Прежде чем начать, следует отметить одну вещь. В моей серии статей под названием Разработка и развертывание приложений Kubernetes в кластере Raspberry Pi предполагается, что Raspberry Pi, на котором вы развертываете, доступен через браузер во внешней сети. Во второй статье этой серии, посвященной созданию кластера Raspberry Pi, я настроил один из Raspberry Pi для работы в качестве маршрутизатора, связывающего частную сеть кластера с внешней сетью. Я установил Grafana на этот Pi (он же Pi router), так как я хотел получить доступ к Grafana извне кластера. Я вернусь к этому на более позднем этапе, когда для проверки установки Grafana используется браузер.

Я дословно выполнил инструкции, изложенные в статье. Они касаются установки Grafana v6.2.2. Grafana теперь до версии 6.7.2, поэтому теперь есть новый пакет Debian, который можно использовать вместо того, о котором идет речь в статье. Если вы решили использовать более новую версию, замените шаг 1 в статье на:

sudo apt-get install -y adduser libfontconfig1
wget https://dl.grafana.com/oss/release/grafana_6.7.2_armhf.deb
sudo dpkg -i grafana_6.7.2_armhf.deb

Это извлекает пакет Debian для ARMv7, как описано на странице загрузки Grafana.

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

  1. Откройте панель управления Grafana, как описано в справочной статье, и войдите в систему. Примечание: вам, вероятно, придется изменить адрес панели управления Grafana на что-то вроде http://xxx.xxx.xxx.xxx:3000, чтобы учесть IP-адрес Raspberry Pi где была установлена ​​Grafana. Я упоминал выше, что вам необходимо установить Grafana на Raspberry Pi, доступном извне кластера Kubernetes. В моем развертывании URL-адрес панели управления Grafana - http://10.0.0.100:3000.
  2. Проверьте доступность Прометея, настроив источник данных Прометей, как показано на снимках экрана ниже. Примечание. Настройки в третьем изображении относятся к http://prom.kube, как описано в Инструкциях по развертыванию Prometheus, упомянутых в предыдущем разделе):

Elasticsearch, Fluentd и Kibana

Возможно, вы знакомы со стеком ELK: Elasticsearch-Logstash-Kibana. В этой статье мы используем Fluentd вместо Logstash. Основываясь на некоторых ограниченных исследованиях, казалось, что Fluentd проще настроить, требует меньше инфраструктуры и легко интегрируется в Docker.

Я также выбрал Fluentd вместо Fluent Bit. Когда я начал это, я не был знаком с Fluent Bit. Оглядываясь назад, мне жаль, что я не проводил и не мог провести больше исследований, чтобы выяснить, какой из них лучше всего подходит для развертывания Raspberry Pi / Kubernetes. Это то, к чему я могу вернуться в будущей статье или в качестве обновления к этой статье.

Как и в случае с Grafana, я решил не развертывать Elasticsearch и Kibana в кластере Kubernetes. В отличие от Grafana, я решил установить их на свой MacBook Pro. Я сделал это по тем же причинам, что и Grafana, но пошел дальше, так как не хотел увеличивать нагрузку на кластер Raspberry Pi, особенно на маршрутизатор Pi.

Elasticsearch

Многие источники предлагают установить Elasticsearch с помощью Homebrew. Так я и поступил изначально. Когда я установил Elasticsearch с помощью Homebrew, он установил v6.8.7. Оказалось, что для моего образа Fluentd Docker требуется версия v7.x, поэтому в итоге я загрузил версию 7.6.2 файла TAR с веб-сайта Elasticsearch. Я извлек файлы в /usr/local, в результате чего был создан каталог user/local/elasticsearch-7.6.0:

sudo tar xvf elasticsearch-7.6.0-darwin-x86_64.tar.gz

Важно отметить, что Elasticsearch - это приложение Java, для которого требуется Java 8. Java 8 можно загрузить и установить с сайта загрузки Oracle Java. Загружаемый файл представляет собой .dmg файл, поэтому его довольно легко установить.

Запустить Elasticsearch несложно - просто запустите /usr/local/elasticsearch-7.6.0/bin/elasticsearch (путь может отличаться в зависимости от загруженной версии и места ее извлечения). Elasticsearch должен запуститься, и в конечном итоге вы должны увидеть что-то вроде следующего, зарегистрированного в stdout:

OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
[2020-04-08T15:26:19,746][INFO ][o.e.e.NodeEnvironment    ] [Richs-MacBook.local] using [1] data paths, mounts [[/System/Volumes/Data (/dev/disk1s1)]], net usable_space [156.2gb], net total_space [465.6gb], types [apfs]
[2020-04-08T15:26:19,761][INFO ][o.e.e.NodeEnvironment    ] [Richs-MacBook.local] heap size [989.8mb], compressed ordinary object pointers [true]
[2020-04-08T15:26:19,978][INFO ][o.e.n.Node               ] [Richs-MacBook.local] node name [Richs-MacBook.local], node ID [EQqVfk2TTRSp1I37Yz4ZYg], cluster name [elasticsearch]
[2020-04-08T15:26:19,979][INFO ][o.e.n.Node               ] [Richs-MacBook.local] version[7.6.0], pid[25833], build[default/tar/7f634e9f44834fbc12724506cc1da681b0c3b1e3/2020-02-06T00:09:00.449973Z], OS[Mac OS X/10.15.2/x86_64], JVM[AdoptOpenJDK/OpenJDK 64-Bit Server VM/13.0.2/13.0.2+8]
[2020-04-08T15:26:19,979][INFO ][o.e.n.Node               ] [Richs-MacBook.local] JVM home [/usr/local/elasticsearch/elasticsearch-7.6.0/jdk.app/Contents/Home]
[2020-04-08T15:26:19,979][INFO ][o.e.n.Node               ] [Richs-MacBook.local] JVM arguments [-Des.networkaddress.cache.ttl=60, -Des.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dio.netty.allocator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.locale.providers=COMPAT, -Xms1g, -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75, -XX:+UseCMSInitiatingOccupancyOnly, -Djava.io.tmpdir=/var/folders/9z/lyfc9l3500b_111_x89br7bh0000gn/T/elasticsearch-16970401582958554317, -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=data, -XX:ErrorFile=logs/hs_err_pid%p.log, -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m, -XX:MaxDirectMemorySize=536870912, -Des.path.home=/usr/local/elasticsearch/elasticsearch-7.6.0, -Des.path.conf=/usr/local/elasticsearch/elasticsearch-7.6.0/config, -Des.distribution.flavor=default, -Des.distribution.type=tar, -Des.bundled_jdk=true]
...
[2020-04-08T15:26:26,909][INFO ][o.e.n.Node               ] [Richs-MacBook.local] started
[2020-04-08T15:26:27,129][INFO ][o.e.l.LicenseService     ] [Richs-MacBook.local] license [2b1f4f4b-1c35-4b77-ae7f-6c9c6a590f36] mode [basic] - valid
[2020-04-08T15:26:27,129][INFO ][o.e.x.s.s.SecurityStatusChangeListener] [Richs-MacBook.local] Active license is now [BASIC]; Security is disabled

Вы можете проверить установку, curl указав в браузере http://localhost:9200. Вы должны увидеть информацию о статусе Elasticsearch, например:

{
  "name": "Richs-MacBook.local",
  "cluster_name": "elasticsearch",
  "cluster_uuid": "OkZ2-Lj2RjW-pVyVl0C7og",
  "version": {
    "number": "7.6.0",
    "build_flavor": "default",
    "build_type": "tar",
    "build_hash": "7f634e9f44834fbc12724506cc1da681b0c3b1e3",
    "build_date": "2020-02-06T00:09:00.449973Z",
    "build_snapshot": false,
    "lucene_version": "8.4.0",
    "minimum_wire_compatibility_version": "6.8.0",
    "minimum_index_compatibility_version": "6.0.0-beta1"
  },
  "tagline": "You Know, for Search"
}

Кибана

Как и в случае с Elasticsearch, многие источники также рекомендуют устанавливать Kibana через Homebrew. Как и в случае с Elasticsearch, эта версия у меня не работала, поэтому в итоге я применил тот же подход, что и с Elasticsearch. Я загрузил файл TAR для версии 7.6.2 со страницы загрузок Kibana и извлек файлы в usr/local, в результате чего был создан каталог user/local/kibana-7.6.0-x86_64.

sudo tar xvf kibana-7.6.0-darwin-x86_64.tar.gz

Запустить Kibana просто - просто запустите /usr/local/kibana-7.6.0-x86_64/bin/kibana (путь может отличаться в зависимости от загруженной версии и того, куда она была извлечена). Kibana должна запуститься, и в конечном итоге вы должны увидеть что-то вроде следующего, зарегистрированного в stdout:

log   [21:26:53.163] [info][plugins-service] Plugin "case" is disabled.
  log   [21:27:08.526] [info][plugins-system] Setting up [37] plugins: [taskManager,siem,infra,licensing,encryptedSavedObjects,code,usageCollection,metrics,canvas,timelion,features,security,apm_oss,translations,reporting,share,uiActions,data,navigation,newsfeed,status_page,home,spaces,cloud,apm,graph,bfetch,kibana_legacy,management,dev_tools,inspector,embeddable,advancedUiActions,dashboard_embeddable_container,expressions,visualizations,eui_utils]
...
log   [21:27:11.671] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [21:27:11.699] [info][listening] Server running at http://localhost:5601
  log   [21:27:11.824] [info][server][Kibana][http] http server running at http://localhost:5601

Вы можете проверить установку, открыв окно браузера на http://localhost:5601/status. Вы должны увидеть что-то вроде этого:

Свободно

С Fluentd оказалось довольно сложно. Хотя есть образы Fluentd Docker для ARM, они не настроены для Elasticsearch. И хотя есть конфигурации Fluentd для Elasticsearch, они не подключаются к образу ARM.

Моя задача заключалась в том, чтобы найти Dockerfile образа ARM Docker и изменить его, чтобы добавить поддержку Elasticsearch. В итоге я использовал три разных репозитория Fluentd на GitHub для достижения этой цели и создал собственное репозиторий GitHub youngkin/fluentd-armv7-raspbpi для созданного мной Франкенштейна. Может быть и, вероятно, есть лучший способ сделать это, но он действительно работает.

Первой задачей было найти Fluentd Dockerfile, желательно для ARM. Я нашел то, что мне нужно, в репозитории fluentd/fluentd-docker-image на GitHub, а именно в подкаталоге v1.9/armhf/debian. Это дало мне базу Dockerfile, в которой я нуждался. В этом репо также был необходимый мне базовый fluentd.conf файл.

Я изменил некоторые настройки в этом файле в соответствии с некоторыми статьями, которые я нашел по настройке Fluentd / Elasticsearch. Ссылки на эти статьи есть в файле fluentd.conf. В идеале я бы поместил всю эту информацию в Configmap, но это на другой день.

Мне также нужно было изменить файл entrypoint.sh, на который ссылается Dockerfile. Это нужно было изменить, чтобы установить переменную среды SIMPLE_SNIFFER, используемую Fluentd. Он не был включен, и это вызвало проблемы с инициализацией во время запуска Fluentd.

Моей второй задачей было найти Dockerfile для образа Fluentd, настроенного с соответствующими драгоценными камнями Ruby для Elasticsearch. Fluentd написан на Ruby и использует плагин для расширения своих возможностей. Elasticsearch - один из таких плагинов (на самом деле их несколько).

Я нашел то, что искал, в репозитории fluentd-kuberentes-daemonset на GitHub, а именно в docker-image/v1.9/debian-elasticsearch7/Dockerfile. Я использовал список драгоценных камней Ruby, указанных в Gemfile в том же каталоге, поскольку это источник драгоценных камней, установленных Dockerfile. Я вручную скопировал ссылки на драгоценные камни в свою копию fluentd-docker-image Dockerfile. Я использовал этот модифицированный файл Dockerfile для создания необходимого мне образа Fluentd Docker и поместил его в ryoungkin/fluentd-kube-daemonset:v1.9-arm32.0.0.20 в Docker Hub. Подробнее об этом ниже.

Наконец, мне нужен был файл развертывания Kubernetes. Зачем писать свой собственный, если он уже существует для решения этой задачи? Я обнаружил это из статьи под названием Вход в Kubernetes с помощью Elasticsearch, Kibana и Fluentd.

Хотя целевым развертыванием был Minikube, у него были файлы развертывания Kubernetes, которые я мог использовать, в частности, DaemonSet спецификация. Файлы находятся в репозитории GitHub, связанном с этой статьей. Я изменил файл efk-kubernetes/kubernetes/fluentd-daemonset.yaml, чтобы он ссылался на образ Docker, который я создал и отправил в Docker Hub. Я также изменил некоторую другую информацию в файле fluentd-daemonset.yaml.

Я взял эти измененные файлы и создал репозиторий GitHub, fluentd-armv7-raspbpi, чтобы разместить то, что мне было нужно. Файлы и их использование следующие:

  • Dockerfile: Создайте образ Docker, необходимый для Fluentd, работающего на процессоре ARMv7 (например, Raspberry Pi). Запустите docker build <somedockerhubrepo>/<somename>:<sometag>. В моем случае я запустил docker build ryoungkin/fluentd-kube-daemonset:v1.9-arm32.0.0.2, ссылаясь на образ Docker в моем репозитории Docker. После этого я поставил docker push, чтобы он стал более доступным. При желании вы можете клонировать репозиторий и создать свой собственный образ Docker.
  • entrypoint.sh: это цель выполнения, указанная в Dockerfile. Он был изменен, чтобы включить определение переменной среды SIMPLE_SNIFFER, как описано выше.
  • fluent.conf: это файл конфигурации Fluentd, указанный в Dockerfile
  • fluentd-daemonset.yaml: Это спецификация Kubernetes, необходимая для развертывания Fluentd на каждом узле Kubernetes в кластере. Этот файл необходимо изменить для вашей конкретной среды, так как он включает адрес / порт сервера Elasticsearch. Он также включает некоторые ограничения ресурсов, которые вы, возможно, захотите изменить.

Развертывание Fluentd осуществляется запуском kubectl -n kube-system create -f fluentd-daemonset.yaml. Если все прошло хорошо, вы увидите что-то подобное, когда все модули работают (при условии, что в вашем кластере пять узлов, включая kubemaster):

kubectl -n kube-system get pods | grep flu
fluentd-4vhv2                         1/1     Running   0          99m
fluentd-8bs9f                         1/1     Running   0          98m
fluentd-b9hbw                         1/1     Running   0          98m
fluentd-dldwp                         1/1     Running   0          98m
fluentd-v7czq                         1/1     Running   0          98m

Телеграф

Telegraf поддерживает мониторинг машинных ресурсов, таких как использование ЦП и диска. Поскольку Telegraf требует InfluxDB, вам необходимо его установить. Инструкции по установке можно найти в этой статье, на которую также есть ссылки в предыдущем разделе о Grafana. Как и в случае с Графаной, я в значительной степени следовал этому дословно.

Поскольку Telegraf отслеживает ресурсы машины, он не устанавливается в кластер Kubernetes. Он должен быть установлен непосредственно на хосте Raspberry Pi, как это было сделано с Grafana выше. Его необходимо установить на каждом узле кластера, если вы хотите отслеживать использование ресурсов в кластере.

В статье Мониторинг с помощью Telegraf, InfluxDB и Grafana рассказывается, как установить Telegraf. В этой статье также рассказывается об установке InfluxDB и его настройке для работы с Telegraf, поэтому внимательно ознакомьтесь с разделом InfluxDB, чтобы получить общую информацию. Вы можете игнорировать раздел об установке Grafana.

Я настроил конфигурацию Telegraf, чтобы включить сбор данных о температуре процессора с использованием некоторых файлов из репозитория TheMickeyMike/raspberrypi-temperature-telegraf GitHub. В частности, я добавил строки от telegraph.conf до /etc/telegraf/telegraf.conf. У меня есть копия моего модифицированного /etc/telegraf/telegraf.conf в этой сущности.

Щиток приборов

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

Показанная выше приборная панель - это то, что я модифицировал. Он использует показатели температуры процессора, которые я добавил в /etc/telegraf/telegraf.conf. Его определение JSON можно найти в этой сути. Вы можете создать информационную панель на основе этой сути, импортировав новую информационную панель, как показано на следующих снимках экрана:

  1. Щелкните значок «+» в левой области навигации и выберите «Импорт» во всплывающем окне.

2. Вставьте JSON из сути в текстовое поле Или вставьте JSON. Затем нажмите кнопку Загрузить.

3. Завершите, следуя подсказкам, чтобы завершить процесс импорта.

Чтобы открыть только что созданную панель инструментов, щелкните значок в виде спирали в виде солнца в верхнем левом углу. как показано ниже:

Вы увидите панель под названием «Telegraf: системная панель». Щелкните по нему, и откроется панель управления.

Резюме

Мы многое сделали в этой статье. Мы установили и протестировали Prometheus с Grafana. Затем мы установили стек EFK и проверили установку. Наконец, мы развернули Telegraf на машинах, на которых размещен кластер Kubernetes, и установили панель управления Grafana для отображения метрик хоста Telegraf.

На этом завершается настройка инфраструктуры, которую мы начали во второй статье этой серии Настройка кластера Raspberry Pi. Теперь мы готовы развернуть нетривиальное приложение RESTful в нашем кластере Kubernetes. Это приложение будет использовать развертывания Helm, отображать метрики Prometheus, которые мы можем просматривать в Grafana, и публиковать журналы, которые мы можем просматривать / запрашивать в Kibana.

использованная литература

Общие ресурсы мониторинга

Пакеты мониторинга

Ресурсы для установки