Telegraf processes input data to transform, filter, and decorate it, and then performs selected aggregation functions on it such as tallies, averages, etc. On the Workload, install Telegraf: workload:~# apt update With LXD installed in our host we can use its lxc command line tool to create our containers: $ lxc launch ubuntu:20.10 workload We’ll be using LXD as our container technology, but there’s very little that depends on this particularly any VM, container, or bare metal host should work for purposes of this example, so long as it’s running Ubuntu 20.10. If you select other hostnames, simply substitute the correct ones as we go.Īs reference, here are the ports we’ll be binding for each service:įirst, let’s set up the Workload. Our Monitor node will double as both data store and web UI, receiving data from the Workload, storing it to disk, and displaying it for analysis.įor clarity, we’ll refer to these two hosts as named ‘workload’ and ‘monitor’. In a real environment, we’d have multiple hosts each with their own Telegraf instance collecting hardware, network, and software status particular to that node. For demo purposes we’ll just read the cpu/mem data from the node. The Workload node will be running Telegraf to collect metrics from whatever load we’re monitoring. This will help familiarize ourselves with the various components and how they interoperate.
Let’s set up a basic demonstration with two nodes, the first acting as a placeholder load with Telegraf installed - the “Workload”, and the second acting as our data visualization system - the “Monitor”. For this LMA stack, visualization is handled via Grafana and email/pager alerts are generated via the Prometheus Alertmanager plugin. Prometheus works as a hub, polling data from different Telegraf nodes and sending it to various outputs, including persistent storage. Its plugin system permits export of data in any arbitrary format for this system we collect the data in a central data manager called Prometheus. Telegraf collects metrics from the operating system, running software, and other inputs. Architectural OverviewĬanonical’s LMA stack involves several discrete software services acting in concert, including: Your LMA stack will help point out issues in load, networking, and other resources before it becomes a failure point. Logging, Monitoring, and Alerting (LMA) is a collection of tools used to guarantee the availability of your running infrastructure. While the current LMA will continue to work for the time being, most users are recommended to instead consider COS.
Logging, Monitoring and Alerting - Introduction LMA -> COS Multi-node configuration with Docker-Composeĭistributed Replicated Block Device (DRBD)
0 kommentar(er)
