… но не само Raspberry Pi

Това е петата статия от поредицата „Разработване и внедряване на приложения на Kubernetes на Raspberry Pi клъстер“. Предишната статия „Инсталиране на Kubernetes Ingress на Raspberry Pi клъстер“ е предпоставка и трябва да бъде завършена, преди да изпълните стъпките, описани в тази статия.

Тази статия е за приложения за наблюдение, внедрени в клъстер Kubernetes, работещ на Raspberry Pis, по-специално инфраструктурата за наблюдение.

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

Последният раздел на тази статия е списък с препратки, които намерих за полезни.

Какво не е тази статия:

  • Урок за най-добри практики за наблюдение на приложения
  • Урок за Prometheus, Grafana, Fluentd, Elasticsearch и Kibana

Всички те са важни теми, но извън обхвата на тази статия.

Тази статия е доста ангажираща и завършването й ще отнеме известно време. Вземете любимите си закуски и нещо за пиене и да започваме!

Преглед

Преглед на мониторинга

Всяко приложение от производствен клас се нуждае от добър стек за наблюдение. За повечето приложения това ще включва комбинация от регистриране и показатели.

Метриките се записват от приложение за проследяване на неща като честота на заявките, честота на грешки и продължителност на заявките, наричани още RED. Показателите са добри за бързо идентифициране на проблеми - например прекомерен процент грешки или неприемлива продължителност на заявката. Метриките не идентифицират какво е причинило конкретен проблем, а само че е настъпило проблемно събитие. Prometheus е една рамка, която предоставя на приложението възможността да записва и съхранява показатели на сравнително ниска цена.

Регистрирането обикновено включва писане на записи във файл или stdout. Регистрационните записи обикновено включват неща като времеви клейма и подробности за настъпило събитие. Например, регистрационен запис може да съдържа информация за неправилно формирана HTTP заявка и да включва информация за искащия клиент, както и информация за това какво конкретно не е наред със заявката. Като такива, регистрационните файлове са много добри за разследване и отстраняване на проблеми.

И показателите, и регистрирането имат място в мониторинга на приложенията. Метриките са сравнително евтини и лесно се предупреждават. Метриките имат недостатък по отношение на влизането, че не съдържат контекст, а само информация, че нещо се е случило. За разлика от това, регистрационните файлове могат да предоставят контекста, необходим за проучване и отстраняване на проблем. Недостатъкът на регистрирането е, че контекстът е скъп в сравнение с показателите. Показателите са много малки, често само етикет, число и клеймо за време. Регистрационните файлове могат да бъдат доста обемисти и може да бъде сравнително трудно да се предупреди от запис на регистрационен файл.

Има редица ресурси, които обхващат философията и механиката на мониторинга. Два отлични ресурса са ръководството за SRE на Google, по-специално „Глава 6: Мониторинг на разпределени системи“. Weaveworks има отличен запис относно използването на метрики с Prometheus и Grafana. Включих и други ресурси в края на тази статия.

Преглед на статията

Тази статия обхваща набор от инструменти, които обикновено се използват както за показатели, така и за регистриране. Дневниците могат да бъдат заснети, индексирани и визуализирани чрез това, което е известно като EFK стека: Elasticsearch, Fluentd и Kibana. EFK е модификация на ELK, където Logstash се използва за препращане на регистрационни файлове вместо Fluentd. Метриките могат да бъдат запитвани, визуализирани и предупреждавани чрез Prometheus и Grafana.

Диаграмата по-долу илюстрира стека за регистриране на Elasticsearch-Fluentd-Kibana.

Като цяло потокът от съобщения в регистрационните файлове върви по следния начин:

  1. Контейнерът влиза в stdout.
  2. Fluentd работи на същия възел като pod/контейнера и улавя потока от съобщения в регистрационния файл.
  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 може да се използва и като източник на предупреждение. В Grafana могат да се задават прагове, за да се задейства предупреждение, когато дадена метрика е извън границите (напр. заявките отнемат твърде много време).

Проницателните наблюдатели ще забележат, че и Kibana, и Grafana са инструменти за визуализация на данни. Това повдига въпроса: Защо имаме нужда и от двете? Причината е, че текущата поддръжка за визуализация на журнали в Grafana е ограничена и е в бета версия, докато Kibana и Elasticsearch могат да управляват и показват данни на Prometheus. Като се има предвид бета естеството на Grafana, реших, че не е напълно готов за производствена употреба. Въпреки това, това все още е интересен въпрос. Ще следя това и може да се наложи да използвам само едното или другото за цялата визуализация на данни.

Прометей

«Prometheus е пълен „системен набор от инструменти за наблюдение и предупреждение.“ Неговите компоненти включват:

  • Сървър, който събира данни за показатели от активирани приложения и също така е базата данни, която съхранява данните от времеви серии, получени от тези приложения
  • PromQL, Prometheus Query Language, използван за запитване към базата данни
  • Клиентски библиотеки за различни езици (повечето основни езици се поддържат)
  • И други компоненти (Документацията на Prometheus ги обсъжда много по-подробно)

Инсталирането на Prometheus изисква Helm и контролера Traefik Ingress. Ако сте изпълнили необходимите стъпки в моята статия за настройка на Kubernetes Ingress на Raspberry Pi клъстер, вече ще имате инсталиран Helm и разгърнат Traefik. Ако не, първо ще трябва да изпълните стъпките в тази статия.

Имам хранилище на GitHub, което съдържа диаграмите на Helm, необходими за инсталиране на Prometheus. Подробни стъпки за инсталиране и проверка на внедряването са достъпни във файла README. Накратко, стъпките са както следва:

  1. Клонирайте хранилището.
  2. Изпълнете командата helm install ..., за да разположите Prometheus.
  3. Проверете внедряването, като отворите таблото за управление на Prometheus в уеб браузър.

Prometheus също е достъпен от хранилището helm/charts/prometheus. Това обикновено е добър източник за диаграми на Helm, които могат да се използват за внедряване на приложения в клъстер на Kubernetes. Първоначално не използвах това поради липса на поддръжка на ARM, но изображението на Docker, посочено в момента в диаграмата, включва поддръжка на многопроцесорна архитектура, включително 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 Pis да работи като рутер, свързващ частната клъстерна мрежа с външна мрежа. Инсталирах Grafana на този Pi (известен още като Pi рутер), тъй като исках да имам достъп до Grafana извън клъстера. Ще се върна към това в по-късна стъпка, която използва браузър за проверка на инсталацията на Grafana.

Следвах дословно инструкциите, дадени в статията. Те обхващат инсталирането на Grafana v6.2.2. Grafana вече е до v6.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. Тествайте дали Prometheus е достъпен, като настроите източник на данни Prometheus, както е показано на екранните снимки по-долу. Забележка: Настройките в третото изображение препращат към 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 с помощта на 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

Можете да проверите инсталацията, като curling или посочите браузър към 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 се оказа малко труден. Въпреки че има изображения на 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 repo, по-специално в docker-image/v1.9/debian-elasticsearch7/Dockerfile. Използвах списъка с Ruby Gems, посочен в 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 repo, 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. Инсталира се достатъчно лесно, като следвате инструкциите на този сайт относно импортирането на табла за управление. Можете да използвате таблото за управление на 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.

Препратки

Общи ресурси за наблюдение

Пакети за наблюдение

Ресурси за инсталиране