How to Gain Visibility into Containers, VM's and Multi-Cloud Environments Using Telegraf, InfluxDB and Mist
Session date: Dec 15, 2020 08:00am (Pacific Time)
Mist.io are the creators of Mist, the open source multi-cloud management platform. Their solution helps clients manage the complexities of using a mix of public and private clouds, hypervisors, containers and bare metals. Mist streamlines its customers’ operations and optimizes costs by improving DevOps practices. Discover how Mist achieves that by building on top of Telegraf and InfluxDB.
Join this webinar as Chris Psaltis and Dimitris Moraitis dive into:
- Mist's approach to improving visibility across environments
- How a time series database is used to monitor infrastructures
- Mist's ability to automate processes and reduce infrastructure costs
Watch the Webinar
Watch the webinar “How to Gain Visibility into Containers, VM’s and Multi-Cloud Environments Using Telegraf, InfluxDB and Mist” by filling out the form and clicking on the Watch Webinar button on the right. This will open the recording.
[et_pb_toggle _builder_version=”3.17.6” title=”Transcript” title_font_size=”26” border_width_all=”0px” border_width_bottom=”1px” module_class=”transcript-toggle” closed_toggle_background_color=”rgba(255,255,255,0)”]
Here is an unedited transcript of the webinar “How to Gain Visibility into Containers, VM’s and Multi-Cloud Environments Using Telegraf, InfluxDB and Mist”. This is provided for those who prefer to read than watch the webinar. Please note that the transcript is raw. We apologize for any transcribing errors.
Speakers:
-
- Caitlin Croft: Customer Marketing Manager, InfluxData
- Chris Psaltis: CEO and Co-Founder, Mist.io
- Dimitris Moraitis: CTO and Co-Founder, Mist.io
Caitlin Croft: 00:00:04.240 Welcome to today’s webinar. My name is Caitlin Croft. I am very excited to have our friends from Mist.io here to talk about how they are using Telegraf and InfluxDB to help their customers gain insights into their containers, VMs, and any multi-cloud environment. So once again, a friendly reminder, this session is being recorded. Feel free to post any questions you may have in the Q&A box. And without further ado, I am going to hand it off to Chris and Dimitris.
Chris Psaltis: 00:00:42.422 Thanks, Caitlin. Thanks for hosting us, first of all. So as Caitlin said, today we will present how we’re using Telegraf and InfluxDB at Mist.io in order to help our users gain visibility to containers, VMs, and multi-cloud environments. So first, a quick round of introductions. I’m Chris Psaltis. I’m the co-founder and CEO of Mist.io, and together with me is Dimitris. Dimitris?
Dimitris Moraitis: 00:01:16.904 Hi, all. I’m Dimitris Moraitis. I am the CTO and co-founder of Mist.io.
Chris Psaltis: 00:01:23.534 Okay. So in terms of the agenda for today, I will briefly go over what is Mist, then I will explain why we integrated with Telegraf and InfluxDB and how. Then I will go into a live demo of our platform and focus on multi-cloud management use cases. And then I will close with some of our plans for the future. Okay. So first of all, what is Mist? Mist is an open source, multi-cloud management platform. We support more than 20 infrastructure providers, including public clouds like AWS, Microsoft Azure, Google Cloud, but also private clouds - OpenStack, VMware - and then containers, hypervisors, KVM, and even bare-metal servers. So Mist connects to all those infrastructure providers over native APIs, and then on the other side, it exposes a multi-cloud interface for all that. You can think of Mist as a single pane of glass from where you can manage all your infrastructure. This is our main dashboard. I will get back to that during the demo. And the reason we built Mist was that we were trying to scratch our own itch and answer some questions we had back in the day when we were managing infrastructure for our customers.
Chris Psaltis: 00:03:00.209 So we were running a consulting business. We had customers around the world, and their infrastructure was all over the place: AWS, on-prem, colo. And on a practically daily basis, we were faced with questions like: what resources do we have? Where are they? How can we control users’ access to them? And can we automate self-service workflows for our own team members as well as for our customers so they can simply provision resources in a controlled and secure way? And then obviously, how do I optimize uses? How can I better control spending and reduce costs? So all of that is what we are answering with Mist. And I’m sure that you already know that managing infrastructure is hard. In order to make good decisions, you need data, and that’s why monitoring metrics are essential when managing infrastructure. Since the early days of Mist, we integrated with monitoring tools so we can pool those monitoring metrics inside the platform and then help our users make good decisions.
Chris Psaltis: 00:04:23.131 Of course, over time, the tools we were using have evolved. We started with CollectD and Graphite, and then a couple of years ago, we moved over to Telegraf and InfluxDB. And why we moved? So it mostly revolves around flexibility. Let me give you an example with Telegraf. Telegraf is written in Go. It’s a single binary. It’s super simple to install on any distro, any version, and you can easily do it automatically as well. Now, with CollectD, that was really, really hard to achieve. CollectD is written in C, and it’s linking dynamically to system libraries, so you can imagine the dependency here. It’s practically impossible to cover any distro with any version. Now, with Telegraf, we have no such problems. Also, Telegraf is much better maintained. You can check the relevant GitHub repositories yourself. Telegraf is better, almost four times better across all metrics, like number of contributions, contributors, commits, and all that. Plus, it has monthly or bimonthly release cycles, whereas CollectD did six-month cycles, meaning you get fixes much faster with Telegraf. And this extends to the plugins as well, so better installation process, better maintenance.
Chris Psaltis: 00:05:59.319 And then with InfluxDB, the situation is rather similar. InfluxDB brought us a whole new level of flexibility. For example, with Graphite, we had to preconfigure the granularity of our ingested metrics, and we also had to pre-allocate disk space to store those metrics. Now, with InfluxDB, we don’t have to worry about any of that. So I discussed the flexibility a little bit already, but there are also other things we love about Telegraf and InfluxDB. And one of the biggest ones is that they’re real open-source products. And by real open-source products, I mean MIT licensed. I mean we can hack, we can distribute, and without any worries. Now, contrast that to code-available options out there. It’s a huge difference, and it takes a lot of pain away. Then also, we have a big and vibrant ecosystem we can tap in, and that’s super helpful at least for two reasons. First, you can quickly find solutions to any potential problems you have, but also you can leverage third-party integrations with those products. So we can move faster with our product, add more features without a lot of effort. And then finally, the wide user base. This is extremely helpful in our case because several of our customers are hosting Mist themselves. And by distributing InfluxDB, they don’t have to worry about new components on their stack. Chances are they are already using the InfluxDB, or they are familiar with it, and this helps us reduce friction a lot. So with that, I will hand this over to Dimitris so he can go over our architecture and how we integrated those products to our Mist code base. Dimitris?
Dimitris Moraitis: 00:08:06.184 Thank you, Chris. And so let’s quickly go over the lifecycle of monitoring data. It gets collected by Telegraf on the target machine, usually a virtual machine or a bare-metal server. From there, it’s sent over HTTPS using the InfluxDB line protocol to gocky; gocky is a fork of InfluxDB Relay. InfluxDB Relay will relay the same monitoring data [inaudible] the InfluxDB databases, providing a level of high visibility - gocky, on top of that, supports multiple monitoring backend support from InfluxDB, supports Graphite. And [inaudible], it counts the metering data - how many data points, say, it has received per machine and per organization, and sends them over AMQP to RabbitMQ. And while the monitoring data is, again, sent to InfluxDB, and the metering comes - after it’s aggregated, it comes again in InfluxDB. So we use Influx both for monitoring and for metering data. And finally, there is a component called Cilia, which evaluates rules. It queries either InfluxDB for metrics or Elasticsearch for logs, and it decides if it will trigger any action.
Dimitris Moraitis: 00:09:40.369 So Telegraf is installed with a simple Bash script or a PowerShell script on Windows. It can be installed automatically if you associate an SSH key to your machine on Mist. Or if you’d rather not do that, you can easily get the one-liner, the command to install it manually. It comes with all the standard plugins for collecting system metrics, like CPU, disk, RAM, network, etc. And apart from that, it includes the Python plugin, which you can use to easily configure your custom metrics through the Mist UI - gocky, as we mentioned, is an open-source fork of InfluxDB Relay. It scales horizontally. We run it on Kubernetes with multiple Pods consuming metrics from monitored machines. And it supports, apart from InfluxDB, also Graphite. And as we mentioned, it also counts metrics per machine and per organization and sends them over to RabbitMQ or RabbitMQ cluster. We’re running the latest one, .x version of InfluxDB. It comes in a container by default, either under a docker compose setup or a Kubernetes setup. If you’re already running InfluxDB, you can bring your own. And we use it both for monitoring and for metering data. Cilia is the component that evaluates the rules, the rules that you have configured in Mist. And these rules can target - it can target metrics, monitoring metrics, or logs. And so it queries either InfluxDB or Elasticsearch for that, and it triggers actions like webhooks, alerts. It executes scripts or performs lifecycle actions like rebooting machines, destroying, etc. So, Chris, will you please show us an action, how that looks like?
Chris Psaltis: 00:12:01.839 Yes. Let me switch to another screen so I can begin the demo. Okay. All right. Okay. So let’s go ahead with the demo then. I’m going to show you Mist’s enterprise edition, which is hosted on-prem. This is a preview of our 4.4 release. And first of all, I will show you how you can onboard Mist. It’s rather simple. The first thing you need to do is to add your cloud. This is the list of the supported providers. In every case, you will need some sort of API credentials. In the case of DigitalOcean, that’s an API token, like we pasted here. And the moment I add my cloud to Mist, it will start calling and autodiscover the resources that I have running in my account. So it already found three machines which I am running, and it is also able to estimate my burn rate on DigitalOcean. Right now, I’m spending 20 bucks per month for those VMs.
Chris Psaltis: 00:13:20.610 Okay. So that’s very simple. But let’s move to another organization which is more populated - and I have added more resources to it - so I can show you the rest of the platform. Okay. So in this account, I have added 11 clouds on public as well as private infrastructure, like AWS, Azure, DigitalOcean again, a Docker host, a KVM host, an account on Equinix Metal, a vSphere cluster, and several others. Again, in this case, you can see that I am currently burning about $400 across all those accounts. And let’s see the list of my machines. This is the list of all the machines I am currently running across all those clouds. And you will see information like the name, the state, the cost, and other relevant metadata. Let me quickly show you how a machine looks like. Okay. So this is a test instance of InfluxDB v2. At the top, the basic information about this machine. Then as you scroll down, this machine is monitored, and you can see the graphs with the system metrics. I will get back to that later on. Then you can also see the rules that Dimitris told you about and more metadata, again, as they are coming from the provider. And finally, at the bottom, there is a log of all the actions that happened on this machine over Mist’s API.
Chris Psaltis: 00:15:07.397 So what can you do with machines? So you can start them, destroy them, reboot them, whatever you would normally expect from your web console of your public cloud provider. And if you have deployed a key on your machines - this is mine here, this “cpsaltis” key. So if you have a key, then you can also open a shell. Let’s give it some time. Okay. Here it is. This is a fully featured Linux web shell. So you don’t have to go to your terminal when you need to just do an action or weekly troubleshoot something. Okay. So this is [inaudible]. You can see how it fetches new values here, how things are changing. All right. Let me close this down now. But it’s not just about actions. You can provision new resources as well. Let me create a new VM, let’s say, again, on DigitalOcean. I will name this VM “Webinar Test”. I will spin it up in Amsterdam. Let me use Debian image. And I will pick this size, 5 bucks for one vCPU. Okay. And then I will also select the SSH key I want to use on this VM. Okay. So this will kickstart the provisioning process. As this is happening, let me show you a couple of more things, like how can I filter my resources? Let’s say, I would like to see only my VMs on Linode - here it is - or all my VMs on every AWS region I am using. Here are those VMs: Sydney, Oregon. And I can save these filters for later use.
Chris Psaltis: 00:17:08.161 So now I am able to switch, let’s say, from the entire list to the AWS VMs only. Okay. Let’s see now the provision. Yeah. Okay. You see that now this is running. It’s live. Let’s see if SSH is working. Yeah. Okay. So everything is working fine. All right. So this is the machine section, very similar for volumes. These are block storage devices, EBS, again, list actions, filters. You can sort them, like, okay, this way, you can easily detect if something is detached, maybe it needs to be destroyed as well. Then we have networks, Amazon VPC, for example. Then we also have DNS. These are DNS service coming from some public cloud providers like Google DNS, Route 53, things like that. And this practically concludes what I would call your inventory, your resource inventory. So by [inaudible] your clouds to Mist, all those resources get automatically discovered. And then you can start performing actions, doing stuff, provisioning new resources, destroying old ones, and all that.
Chris Psaltis: 00:18:44.854 But what more can you do? Okay. Let me go into scripts for a second. So Mist allows you to upload your Bash scripts or Ansible playbooks and then execute them through our platform. Let me show you an example. This is a simple Hello World script. So once I upload it, or you can also do it through a link or a GitHub URL, then I could select that I would like to run this script on this VM, give it whatever parameters you wanted to do, and it will execute on the machine. It will also leave an audit trail. Okay. So scripts are really useful for installing an application or taking a backup or do some sort of per-VM operation. But in some cases, you have applications which need a whole cluster of machines. Let’s say, for example, a Kubernetes cluster or a database cluster, so you need to provision a lot of VMs and then configure maybe something on the volume side or do some networking tweaks and all that. For such cases, we have the template section in Mist. We are integrating with another open-source technology called Cloudify, which is similar to Terraform. In fact, we’re working to integrate with Terraform as well. So what this does is similar to scripts. You upload your Cloudify template, and then you’re able to execute it from here on any of the cloud accounts that you have added to Mist. So in this example, I can create a Kubernetes cluster with one master, one worker node. I just select which VMs I want this to create, and it will happen, and that’s with templates.
Chris Psaltis: 00:20:50.918 One last thing I would like to show you in this theme are schedules. So schedules are for operations that have some sort of periodic execution plan, like taking a backup every night or cleaning up or rotating my logs or doing something like that. So I could show you here, for example, like I could run a backup operation. I would like this to run a specific script. This is the backup DB script that I showed you previously in the DB section. And then I can apply this, let’s say, to all my machines with the prod tag, which are older or cost more or whatever. And then I would like this to happen once a day. So schedules are useful for the cases I described earlier, like backups, log rotations, but can also be extended to cases where you need to proactively scale up a cluster or scale it down, back again after the spike is gone. But we also very often see them being used for actively reducing your cost. So for example, you can set up a schedule that shuts down all your VMs off business hours. So when engineers leave their work, if they forget something running, then Mist will automatically power it down so you’re not getting charged for it.
Chris Psaltis: 00:22:37.168 And so I showed you so many things that people can do from within the platform. But then how can you make sure that everything is happening in a controlled way, so you don’t have people, let’s say, destroying your production VMs? And for that, we have the team section. I have added three teams here already. Let’s see my dev team. It has three members. You can invite new members from here over email. They will get an email, activate their account, log in Mist. And then they will be able to do only what it is allowed to them through this team policy section. So let me add a rule. For example, I would like my dev team to have full access only to my Google Cloud account. And I would also like them to have full access to all machines with the tag “dev”. So that’s it. So in a couple of seconds, it’s super simple to configure cross-cloud RBAC policies that are very fine-grained. Every resource that’s managed through Mist has some sort of RBAC policy attached to it - same with all available actions. And if you have ever worked with IAM credentials or IAM services out there, you know already that this is hard to do and maintain, even in the context of a single cloud. Now, if you had 10 or 20 or whatever, it becomes practically impossible to manage unless you have something like what I’m showing you right now.
Chris Psaltis: 00:24:33.054 Now that I have created my teams and people start logging in and doing stuff, how do I know what happened? This gets us to our logs. Mist keeps track of all actions that are happening over its API and logs the requests and the results. So for example, let’s see what did I do in the last couple of days. Okay. So here, I executed the script, and that was the result. And then I created the machine, and all this. So this is extremely helpful for figuring out who did what and when. Another interesting feature in this category, let’s say, is ownership. So you see that this VM belongs to me. I’m the owner. But whenever somebody creates a resource from Mist’s API, the owner gets tagged automatically, but you can also transfer ownership later on to another person in your team. So this is really helpful for two reasons. First of all, based on the owners, we can configure quotas, cost quotas from the team section. Again, for example, the dev team, I would like them to have a budget of $500 per month. And if they try to provision more than that, it just fails. But you can also do something, let’s say, more light. I guess it’s rather common. We were in this situation as well. That’s why we built the owner’s metadata tag. I am going through my AWS account, and suddenly I discover an extra-large instance running for a couple of days with the very descriptive name, Test ABCD. So you go out on Slack and say, “Hey, whose machine is this? What does it do? Do you need it? Should I destroy it? It’s costing us a fortune.” So all that can be easily avoided just by knowing whose machine is that.
Chris Psaltis: 00:26:47.452 Another interesting thing you can do through Mist’s team sections or with constraints is that you can force people to select an expiration date when they create new resources. This VM doesn’t have an expiration date, but I can show you here, for example, that I would like this VM to expire in one week from now and please notify me 60 minutes before expiration. This can be enforced during the provisioning phase, again, by leveraging Mist’s teams. Okay. And with that, let me go into more monitoring-related features, let’s say. Let me find the VM I created earlier. Okay. So here it is, the Webinar Test VM. So this VM already has an SSH key associated. I will click Enable Monitoring. And what this does is that it practically runs the installation script for Telegraf over SSH. It’s downloading the binary. It’s configuring it. And in a few moments, it will be up and running. When Telegraf gets installed, then it will start collecting metrics and sending them back to Mist. Let’s see. So here you can also see the manual command that Dimitris has described. Okay. And in case you don’t want to provide Mist with Sage access to your machine, you can use this one to deploy Telegraf.
Chris Psaltis: 00:28:45.920 Okay. So this was installed. Now Telegraf is running, and slowly you will see that it will begin collecting metrics and sending them back to Mist. These metrics here are the first ones. These metrics are going through gocky, as Dimitris explained earlier, and then they end up being stored in InfluxDB. Out of the box, we install some metrics regarding system information, like load, CPU, uptime, but also network information and file systems and [discrete write?], things like that. You can also add more graphs from here, for example, CPU usage and more metrics around network and several others. But we are also deploying Telegraf’s Python plugin. And using this plugin, I am now able to deploy a custom Python script on my Telegraf that will start collecting metrics. Let’s call it random metric. And so this a quick example. It just generates a random value. And now I will add this. And what this does currently is that, again, it communicates with your machine. It deploys this Python script, and Telegraf will begin executing this Python script and start sending data. So, oh, here it is, first random value. Okay. Random values are not very helpful, but you get the idea. You can practically script anything you like, like fetching a value from a database or hitting some sort of external URL or fetching a value from a log. So it’s really nice and flexible. You can do a lot of stuff with it.
Chris Psaltis: 00:30:52.265 And you will also notice here that there is a default rule enabled in this VM. If we don’t receive data from it for two minutes, then it will alert us. But let’s dig deeper in the rule section so I can show you more from there. Okay. So Mist allows you to set rules on two types of data, first of all, log entries, and then monitoring metrics. Let’s show you an example with monitoring metrics. So this will apply to all my machines or to specific machines or, let’s say, all machines with the dev tag. I will check once a minute for my five-minute load average. And let’s say that if it’s higher than one within a minute, then I would like you - and here’s the action part. I would like you to email the owner’s team or the dev team or only these people. Another thing you could do is you could trigger a webhook, or you could reboot the machine, or you could just destroy it, let’s say, if you detect that it’s sitting idle, or you could run a command, like I’m detecting my web server is leaking memory, let’s restart the web server.
Chris Psaltis: 00:32:30.040 And the other thing you can do - I will show you here - is that you can apply these rules on logs. So for example, again, this would apply in all clouds. If I get a log entry that says destroy machine, I would like you to notify me. And again, this is helpful so you can keep track of nonauthorized usage, or you can make sure that you don’t have people signing in your public cloud web portal and doing stuff from there or whatever. So you could also apply those rules on logs. Now, the cool thing with that is that - let me show you in this example. So you can see that this applies to all my clouds. Sorry. This applies to AWS Sydney. So you can set the rule’s context to a single cloud or a group of resources or a specific resource, and you can also use tags, like this rule applies to all my machines with the dev tag. And the interesting thing here is when new resources get created, they will automatically inherit these rules as long as they have, let’s say, the dev tag. And that makes it super simple for the end users to just spin up a resource, just get the proper tags, if any are required, and then the rules will be automatically applied to it. So they apply both on all VMs as well as new ones without any configuration needed from the user side. So that can be really, really helpful.
Chris Psaltis: 00:34:27.687 And one final thing I would like to show you around this subject is the insights section. So what we do here is that we’re pulling together information from different sources and different types of information across your entire infrastructure so we can help you answer questions like: What it is that I am running, how much is it costing me, and is this cost justified or not? Yeah. It’s pretty common to see your spending increase, let’s say, 10% month over month. But is this because you actually had more [inaudible] in your service, or is it because people just forget turning off resources? And the insights section is split in three parts: first, the cost overview part where you see how my cost evolved over time and how it’s distributed across the clouds I’m using, across the different tags. And then from the monitoring metrics we’re collecting, you can also see what’s going on with your utilization. So for example, here, you see that I have a total of four cores being monitored, and below this, 0.65. So probably, I’m overprovisioning stuff. And then you can also have a high-level overview of how your inventory evolved, how many machines you had, how many you’re currently running, and all that.
Chris Psaltis: 00:36:06.803 And so that’s it with the demo. Oh, yeah. One last thing I would like to note is that everything you saw so far is possible to do over a RESTful API. So the web application itself, the Mist web application itself, is just another client of this API. So it’s super simple to leverage this API to integrate with third-party systems, or even make it part of your applications and make them multi-cloud aware, let’s say. And there is also a CLI, so you can perform these operations from the command line. So that’s it with the demo. Let me stop sharing the screen and get back to the presentation for a second. Okay. Yeah, I have some screenshots here in case something went wrong with the demo. Okay. All right. So just a recap. So what we discussed about so far, first of all, is what is Mist, why we integrated with monitoring tools of Telegraf and InfluxDB, how we built this integration and why, and then we also went through our demo and discussed the benefits that our users get from our platform.
Chris Psaltis: 00:37:54.412 Now, in terms of plans for the future, our 4.4 release is about to go live in a couple of weeks. What we are working on, though, already is v5.0. And Mist 5 will bring support for InfluxDB v2, but it will also bring a fully-fledged, multi-cloud CLI. Currently, the feature set it supports is a little bit limited, but it will be covering all functionality with v.5. And then past v.5, we’re really excited about InfluxDB IOx because it will bring a whole new level of performance, much better flexibility, and even more features in the open-source version. So we are waiting to see how this goes. We will be experimenting with it in Q1. And then finally, on the Mist.io site, we will be working on custom dashboards for our web interface so our users can rearrange stuff and create their own dashboards with information that our platform is collecting. And that’s it for me. If you’d like to find out more about Mist.io, you can visit our website or our account on GitHub to get our code. And you can also reach us on social media, LinkedIn, Twitter. Okay. So that’s it for me. Thank you.
Caitlin Croft: 00:39:35.207 Awesome. Thank you, Chris and Dimitris. That was fantastic. So we did get one question. I know Dimitris already answered it, but just in case anyone also had this question or was curious, how often are you collecting metrics?
Chris Psaltis: 00:39:52.934 Dimitris, would you like to handle that?
Dimitris Moraitis: 00:39:55.322 Sure. Yeah. The default interval is 5 seconds. Of course, you can configure it yourself. You can change it to 10 or larger than that, but the default is 5.
Caitlin Croft: 00:40:09.575 Perfect.
Dimitris Moraitis: 00:40:10.267 And you can change, of course, the Telegraf configuration and the different plugins and whatever you’re already doing, yeah, each fully configurable.
Caitlin Croft: 00:40:22.009 Did you guys play around - I’m assuming the 5 seconds is sort of your default. Did you guys play around with different time intervals and found that 5 seconds was the best?
Dimitris Moraitis: 00:40:32.846 Well, more resolution is better, at least, when you want to know what’s going on right now on your infrastructure. Of course, there’s a trade-off. We found out that 5 seconds is a good enough trade-off that provides enough granularity and resolution while not overloading the ingestion system. So we tried lowering it. Of course, after a point, it becomes problematic even. Telegraf can time out and send the same data over and over. So 5 seconds is the default, and it’s the lowest setting we support at this point.
Caitlin Croft: 00:41:22.816 Great. We’ll give everyone just a couple of minutes if anyone has any more questions. And I know you guys mentioned that you’re interested in trying InfluxDB IOx. This was announced at - just for anyone who doesn’t know, it was announced at InfluxDays North America just last month. And I know there’s been a lot of excitement and questions around it. So we do have InfluxDB IOx Tech Talks every month. We just had one last week actually. And so there will be another one in early January. And Paul Dix is actually on those calls, and he’s there to answer any questions that anyone has about InfluxDB IOx. And also, he and the team are there to provide an update on the progress that they’ve made on InfluxDB IOx. So if you’re interested in learning more about that, that’s also worthwhile checking out as well.
Chris Psaltis: 00:42:17.251 Yeah. The day the announcement happened, I was on Twitter. And then suddenly, I got [inaudible] with Paul and said, “Hey, can we build it and try it out?” “You better wait a little bit.” [laughter] So we’re waiting a little bit. But it’s super interesting. I’m very eager to compile everything right now, if possible, but I will wait for a little bit.
Caitlin Croft: 00:42:44.198 Just out of curiosity, what is so exciting to you about it?
Chris Psaltis: 00:42:50.209 I want to see what’s happening performance-wise. It’s also really nice that you can bring it online on a cluster pretty much everywhere. So we would also like to check out how the whole registration thing works and what’s the - I’m mostly curious about the performance, about how much can it take - how much it can take. So that’s what I’m waiting to find out.
Caitlin Croft: 00:43:26.849 Absolutely. And I just threw in chat the link for the next InfluxDB IOx session. So it’ll be on Wednesday, January 13th, 2021, at 8:00 AM Pacific, which is 4:00 PM GMT. So be sure to come to that if you are also excited about it or just interested in learning more. There were a ton of questions last week, so I’m sure there’ll be even more next month. And I look forward, Chris, to seeing what you guys - once you guys start testing it out and playing with it, I look forward to seeing what you guys do with it.
Chris Psaltis: 00:44:05.436 Yeah. Yeah, yeah, that’s for sure.
Caitlin Croft: 00:44:09.724 I don’t know if we talked about this, but how did you initially find InfluxDB and Telegraf?
Chris Psaltis: 00:44:18.202 I don’t remember, to be honest. Dimitris, do you remember?
Dimitris Moraitis: 00:44:20.107 Well, we were building our monitoring system. We had all those troubles that Chris mentioned with CollectD and also Graphite. And we were on the lookout for any new exciting developments in this space. And yeah, we were a very early adopter initially. Internally, we were following -
Chris Psaltis: 00:44:43.446 [crosstalk].
Dimitris Moraitis: 00:44:43.588 -it very closely. First, we integrated Telegraf. So were using Telegraf instead of CollectD, but [inaudible] the data in Graphite. And yeah, finally, we also integrated InfluxDB.
Caitlin Croft: 00:45:01.539 Awesome. Yeah. And I think your UI that you guys built is incredible. It’s always interesting when - it takes a lot of time to build something like that. So I think it’s fantastic, and all of the dashboards are great. So someone did ask if this recording will be posted online. Yes, it will be. I just have to clean it up a little bit. I’ll trim it a little bit. And then it’ll be available later today as well as the slides. So don’t worry. You can go back and rewatch it and check out Chris’s awesome demo that went flawlessly. [laughter].
Chris Psaltis: 00:45:38.816 Okay. So thankfully, I didn’t need the backup slides after all. [laughter]
Caitlin Croft: 00:45:43.540 Hey, it’s because you had the backup slides that you didn’t need them.
Chris Psaltis: 00:45:46.383 Ah, yeah, yeah. That’s the trick, yeah. That’s true. [laughter]
Caitlin Croft: 00:45:51.362 The joys of live webinars and such. Well, thank you, everyone, for joining today’s webinar with Mist.io. It was fantastic seeing you all here. If you have any questions for the speakers, Chris and Dimitris, please feel free to email me. I’m happy to pass them along and connect you guys. The recording and slides will be made available later today. And I hope to see all of you on tomorrow’s virtual time series meetup as well as our Thursday webinar with Tim Hall, who will provide an update. And maybe you can ask him and bug him about InfluxDB IOx 2 as well. [laughter]
Chris Psaltis: 00:46:32.574 Will do. Will do.
Caitlin Croft: 00:46:34.134 Thank you, everyone, and I hope you have a good day.
Chris Psaltis: 00:46:37.546 Bye. Have a nice day.
Dimitris Moraitis: 00:46:38.907 Thank you, Caitlin. Bye.
[/et_pb_toggle]
