Why Use InfluxData to Gain More Visibility into Network Monitoring
Session date: Mar 19, 2019 08:00am (Pacific Time)
Learn how to use InfluxData for your network monitoring to gain the necessary visibility in the status, performance and responsiveness of your enterprise, cloud or hybrid application environments. Get a faster and easier tool to start collecting data from multiple sources and quickly perform root-cause analysis reducing your MTTR.
Watch the Webinar
Watch the webinar “Why Use InfluxData to Gain More Visibility into Network Monitoring” by filling out the form and clicking on the download 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 Why Use InfluxData to Gain More Visibility into Network Monitoring. 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:
- Chris Churilo: Director Product Marketing, InfluxData
Chris Churilo: 00:00:00.415 Welcome everybody. My name is Chris Churilo and I work at InfluxData. Today we’re going to talk about using open source, in particular a number of the commands and the TICK Stack to help you with network monitoring. But before we dig right into the specifics of it, just wanted to kind of set the stage by just talking about right now, we’re really in this age of what our CEO likes to call the age of instrumentation. Where it’s really about gathering as much information about how things are working in the physical world as well as in the virtual world. On the IoT side, there are more and more sensors that are out there that are helping us to gather information so that we can understand the change over time of factories, or wind turbines, any kind of machinery that’s out there. And we’re getting that data in larger and larger amounts. And then on the virtual side of the world, it’s of course the traditional kinds of infrastructure we’ve been monitoring for the last 20 to 25 years, the networks and servers and whatnot. But of course these things are getting even more interesting and becoming more than just the physical world on that landscape. We’re not talking about a lot of the components within the applications, a lot of things are getting virtualized. And actually the thing that’s crossing between both of these worlds is that, in both sides you do need to understand how well the network is performing. On the IIoT side, it’s all about making sure that there’s enough bandwidth, there’s enough network available for all those sensors, whether they’re out in the middle of field, or deep in a mine, or in an urban area. Understanding the network performance in that scenario is equally as important as understanding it within our infrastructure for the applications that are using those networks.
Chris Churilo: 00:02:09.705 So it’s just becoming really critical in all aspects. And in particular, what we’re trying to accomplish with this is that, as we understand how these components are doing and then we can get that understanding by making sure that we instrument these systems so we can get all kinds of data from these different sources. And then taking a look at that and trying to gain some kind of understanding from what’s going on within these environments with the ultimate goal of trying to make sure that we can apply some learnings and understandings. Maybe even a little bit of AI to help us then to ultimately develop self-healing systems or at least systems that can make sure that they are constantly performing in a more automated fashion. So this is all really great. It’s very exciting. But when we think about our experiences with the network engineering, this is probably how a lot of us have had our experiences laid out in this kind of very siloed manner. All right. If you’re on the network engineering team, we talk about very specific things technical things that pertain to the network. Things that don’t necessarily translate to other parties in the organization. So we could be talking about something very specific like Jitter in the network. But really our line of business leaders like our CIOs or CEOs, they don’t really care about those particular details. What they really want to understand is what is actually happening. How do I get an understanding of how the results can manifest in themselves, right? CIO or the entire management team is more about making sure that the overall service is functioning so that it can generate happy users and ultimately generate revenues and increase profitability.
Chris Churilo: 00:04:16.655 And then there are other organizations as well. The capacity planner wants to know where are those bottlenecks, what does it mean for us as far as forecasting goes? And then if you’re looking at the support groups, they understand that networks need to be performant but they really need to make sure that they can prove to their constituencies that the response time is going to be there so that they don’t have to deal with these slow monitoring solutions. Oops. Oh, no. What happened? Sorry about that. Somehow I stopped sharing accidentally. Okay. There we go. All right. And so one of the things that we have to be careful with our as we progressed through collecting all this information to make sure things are working is that, we also don’t just present the data in its raw format to the different organizations. Because one, they’re just not going to know what you’re talking about. And two, we do need to make sure that we provide them with the proper context so that they can understand that we’re doing everything that we can to make sure these networks are performing properly. And that we can on the flip side also when we provide them with that kind of context it’s also going to be a lot easier for them to provide us with any kind of assistance, right? So if we can provide the capacity planning team with the knowledge that, hey, it looks like our networks are going to be at capacity next month instead of giving them all the nitty gritty details. It’s more likely that they’re going to be able to help us to ensure that we get whatever kind of assistance that we need to make sure that things are flowing very nicely. And same with the CIO, we just have to it’s just a matter of making sure that the information that we’re pulling is going to get translated in a way that each of these different organizations is going to have an understanding that things are going well, or we need some more help, or things aren’t going really well. And what that could mean in terms of what they understand best. So it could be revenue, it could be cost, it could be also how the customers are going to be responding because we’re having some problems with the network.
Chris Churilo: 00:06:49.758 And so really it’s all about pulling in lots and lots of raw metrics and making sure that we can then categorize that in a way that is going to make sense. And ultimately, what we’re trying to accomplish is to help people understand the overall health of our services. Letting them know what is the overall status, where are the risks, how are we doing, and then getting into the more specifics of these different indicators. And this is where you can then start to really dig into the more detailed metrics that we’re gathering from the various systems that we have, right? So helping people understand the availability of the network, how well it’s performing, what the capacity looks like, and then even who is actually driving consumption and for what purpose? And I think it’s really important that we take these different viewpoints because ultimately what we’re all trying to do is make sure that we’re providing a service to our customers that’s going to be useful and interesting. And so with that in mind, network monitoring isn’t just about looking at the network. It’s just one component of the overall health, our entire application or infrastructure, whether it be under IoT or whether it be under a traditional application. Or even just an application that could be an internal application that we might be managing like an HR application or even the SaaS service that we’re offering to our customers. It’s one very critical network monitoring is one very critical component of the overall health of the solution, but we shouldn’t lose sight of it and just look at it on its own.
Chris Churilo: 00:08:39.424 I think a lot of us have had experiences where we all get the support team you know sharing with us all the tickets that have come in about the complaints about the slowness of the service. And when you have this very siloed approach, each of the teams will just kind of look at their area and go, well, my area looks good, everything’s a green light, nothing I can do here. And at the end of the day, that’s not useful to the overall business. And we really need to make sure that we look at these things as a component of the overall health of our services. And with that in mind, we also need to make sure that we can understand, what are the overall goals that we’re trying to achieve with these different components of monitoring? And also take a look at the approach and see if there are areas where we can actually use the data that we’re already gathering in certain areas across the different monitoring landscapes. So are there things that we can understand in the network side that can also be helpful for other areas of monitoring? So digging in a little bit further, I think it’s really important for us to start to look into when we’re looking at network the network monitoring, what are the things that can help to drive success and growth. And looking at it from both a cost- and a profit-centric viewpoint are often pretty helpful for us that are a little bit more closer to the metrics that are being gathered. So understanding some of the key metrics that are going to determine network performance like latency, and error rates, bandwidth consumption. But then also understanding how those things can impact revenue generation. And being able to be that translator to the different lines of businesses, I think is going to be make us much more successful and make us have sympathy across the different groups. And ultimately, I think the sympathy that come back to us whenever we need to get more budget or more assistance in making sure that we can put in the right actions to make sure that we’re collecting the right kinds of data and doing the right things for our networks.
Chris Churilo: 00:11:03.972 So that’s all great. But specifically, why should we consider open source tools to help us achieve those goals? And I think the number one thing is that, when it comes to network monitoring, that’s probably one area where open source has had quite a long life. If we think back to the tools that have been in place for the last 20 years, a lot of those tools were community-based tools. And so in the landscape at network monitoring, it’s just always been that way. And so it just makes sense for it to continue to be that way. In addition to that I think there are more and more open source projects that are popping up because it is important that we can pull together as an overall community and help each other out. Because at the end of the day, a lot of these things should be leveraged across all kinds of different organizations and also across all kinds of different industry sectors. Of course the other thing that I think open source is particularly useful for is helping us to also innovate. And if you look at a number these open source projects, they’re really trying to kind of push the boundaries of what we can do with network monitoring. Not just looking at the networks as we have traditionally but also trying to come up with other frameworks and other ways to be able to see how can we get information that’s going to help us to be a lot more successful when monitoring these networks. And these networks are no longer combined to the physical networks, right? But also having to look at the network performance of applications within containers, within a more virtualize world as well. We’re making sure that we can look to each other to try to come up with ways to do that so we can all be successful. Of course, you guys are all here because you have some understanding of InfluxDB, and one of the key things that we’re really proud of is that we are open source at our heart with a pretty rapidly expanding open source community behind us. And it’s interesting to see how the community is actually using us, and how they’re actually expanding on the open source front as far as it pertains to network monitoring.
Chris Churilo: 00:13:30.066 So I’m not going to spend too much time about what InfluxDB is. Hopefully everybody here understands it’s a purpose-built time series database, used for bringing in large volumes of data at a very high ingest rate. And we have to keep in mind when we’re thinking about network monitoring that InfluxDB is indeed a place to be able to store your metrics events that you’re collecting from your networks. Because when we go back and think about what we’re really trying to accomplish when we’re doing network monitoring, it isn’t just about collecting the metrics from the activities around the networks, it is also making sure that we can collect all kinds of other data points that are going to bring a lot more context to our monitoring efforts. So looking at the metrics from the infrastructure the application if you happen to be in the IoT role, looking at the metrics of the actual devices that are out in the field, it’s really about bringing in all those different metrics from the things that we’re monitoring. And then on top of that, layering it with other data points that may also be useful. This could be some forecasting information about the business, what the expectations are from a revenue perspective. Or probably more precisely, what expectations the business has on how many users are expected to be on the applications or using these particular networks. And once we have those things all tied together, then all of a sudden I think that our planning and our understanding of the direction that we need to go into is going to make a lot more sense for all of us. Which means that you want to make sure that you aren’t tied to a solution that’s going to be limiting you and not allowing you to add those additional data points. And that’s the reason why at InfluxData that we chose to become more of a platform than just a single database. So we want to be able to allow you to add all kinds of different metrics from all parts of the business and not just be limited to just one particular area. So it’s not just about a particular router. It’s not just about a particular application or just one type of sensor. It’s about bringing in all the different kinds of data points that are going to be useful for you when monitoring your networks or any of your infrastructure for that matter.
Chris Churilo: 00:16:00.752 Of course what is also going to be true across any of these metrics that we’re bringing in, we need to make sure that we can bring them in at a high ingest rate and store them as efficiently as we can. So that we can be able to query them as quickly as we can, especially in the event that we see something that might be amiss or maybe we see something interesting. The whole point of being able to gather all this data, is to be able to do a real-time query to gain some understanding and then ultimately do something about the situation. Maybe it’s to provide some kind of automation, maybe to build some kind of self-healing. Maybe even it’s just to provide some understanding to the capacity planning organization that, hey, we’re going to be reaching a critical juncture pretty soon so we better be prepared for it. Normally, I would spend some time looking into our products and offerings in quite a bit of detail but I’m good of under the assumption that for today’s audience, you guys have a pretty good understanding of what we have. So at our heart, we have an open source set of projects with InfluxDB being the time series database. Then we have a set of collector agents called Telegraf that allow you to collect the metrics and it’s stored in to InfluxDB. You can use Chronograf for visualizing that data. And you can also use Kapacitor to do some real-time processing of that data. You can set thresholds and alerts. Throw that information into your incident management tools. You can also throw this data into any kind of machine learning framework you might have put together. Or if you’ve created your own user defined functions you can also put that data through that. And oftentimes people will bring that data back into InfluxDB so that their teams can then visualize all the data sets the raw data as any of the data that’s been manipulated. And then finally, we also do have a set of commercial offerings called InfluxDB Cloud and InfluxDB Enterprise.
Chris Churilo: 00:18:17.521 So more specifically, let’s talk about what we can do in the network monitoring realm. And when it comes to network monitoring, there are so many tools that are already available out there and so many approaches that you can take. And so we decided that we would just narrow down the scope to just the four things on the left, and these are the things that you can do with InfluxDB and Telegraf as well as some other community data sources that are out there. So what we can do is we can help you with traffic monitoring. We can also help you with understanding the responsiveness of the networks that you’re monitoring. And also with availability. And specifically when we’re talking about traffic monitoring, we’re talking about bandwidth consumption, and helping you understand who was using the bandwidth, when and how much. And of course you can do that per IP, per protocol, per port, however way you want to be able to measure those things. And also help you understand whether it was with malicious intent or not in providing you more of a viewpoint from a security perspective. And the way that we can do that is that we can use either Telegraf, a couple of the Telegraf plugins, or we can also use some of the community data sources, or also some of the community collector agents that are available. And in this particular instance we have a pretty strong network monitoring community member called ntop, that has been able to open source their NetFlow agent so you can actually bring this information gather that information from your various networks and store that into InfluxDB.
Chris Churilo: 00:20:14.273 Moving down. We can also help you with understanding the responsiveness of your networks. Basically, getting an understanding of the question of, is this network actually functional? And we can do that by looking at things like latency, packet loss, or any kind of error rates, or Jitter. And once again using a number of different Telegraf plugins that are available to gather that information and put that into InfluxDB. And then finally, we can help you understand, are the various endpoints available, are they up, are they down, how is the health of these things? And also probably the thing that I hear quite a bit with a lot of our users is just managing the certificates because a lot of times those are the cause of the availability issue that they might be having with the networks. So here’s a view of our architecture diagram with more of a highlight on network monitoring. And so you can gather all this information from the various network devices that you have, whether it’s the physical appliances or whether this is within the containers that you have. And there are a number of Telegraf plugins that are available today. We have an SNMP plugin that’s pretty popular. PING plugin. A number of our users also use Syslog to gather a number of those metrics that we described in the previous slide. And there’s also this JTI OpenConfig Telegraf plugin that’s available. And this is just the ones that are really focused on network monitoring, and there’s over 200 other plugins that you can also use to be able to help you with gathering this kind of information or information that might be surrounding other components of your overall infrastructure. And then on the community data sources, what’s been really interesting over the course of the past couple of years is that there have been a number of other data sources that may not currently have a Telegraf plugin but they have figured out a way to write using line protocol, which is basically the format that you need to be able to use, to be able to ingest data into InfluxDB.
Chris Churilo: 00:22:32.689 And so a number of the different network appliance people or companies like the Cisco, or Juniper, or Vista, you name it, has been successful in writing line protocol into InfluxDB to store a variety of the metrics that they can pull from their devices. So you can see here on the left, I listed out Cisco pipeline, ntop which I mentioned previously has the ability to use NetFlow and sFlow, and Metamako of Juniper or Vista. You name it almost all the top appliance makers that you can think of have already demonstrated that their users have been successful in being able to pool these metrics and put them into InfluxDB. And I think if you talk to any of these appliance makers or read any of the blogs where they talk about how they’re doing this, the one thing that they all share in common is that, it’s important for them to be able to put these metrics into a centralized database along with all the other kinds of metrics that you may want to gather to make sure that your entire infrastructure is running smoothly. And we can’t just limit to what we have today, right? It’s always about thinking about or looking at the data that we have and seeing what other data points might be useful or might be able to help us gain even better understanding of how our networks and our overall infrastructure is doing. So I’m just going to go into a couple of examples of what some of our users have been doing. I’ve talked a little bit about ntop a couple of times now, and they’ve been in business for a number of years, and they have open sourced their endpoint kind of monitoring collector agent. And so that’s available for anybody to be able to use, to grab the information about the networks and put it into whatever data source that they were interested in.
Chris Churilo: 00:24:47.419 In addition to that, they created a SaaS version of their traffic analysis product. And originally when they built it, they were actually using RRD to put all this data into that, and then they could build these beautiful dashboards that you see in the back end that their users can interface with to get an understanding of what’s going on. And what was becoming more important to them is that they realized that they needed to be able to deliver even higher granularity data than what they had in the past because they needed to see where those actual spikes of those anomalies lived. And it was no longer good enough for them to be able to look at things in the minute range. They definitely had to go into seconds and sometimes milliseconds to really understand what’s happening with the networks that people are monitoring. In addition, they also just found out that RRD just wasn’t cutting it with their users, and a number of the users actually told them that they had a preference to put the data that they’re collecting into a temporary database like InfluxDB. And so that’s why they made the switch to move to the open source version of InfluxDB for their overall solution as well as for their individual customers. So each of their customers can have their own instance of the database to be able to use not just for the network monitoring traffic that they’re pulling in but they can also use it for any other monitoring data that they might be collecting. LibreNMS is also another open source network monitoring system and went down a similar path as ntop. They were also originally dependent on RRD and felt that it was important for them to make the switch to something like InfluxDB. Because their users wanted to not only take advantage of the dashboards that they had in their system, in their monitoring solution, but they also wanted to be able to use other open source products like Grafana to build a dashboard. What was happening with their infrastructure and then tie it to the other data that they’re collecting about their overall infrastructure. So they thought it was important to be able to make that switch and offer that to their users.
Chris Churilo: 00:27:25.319 Some other customers that are actually not only looking at network monitoring but looking at the overall infrastructure monitoring across the board are companies like PayPal, and also the next one I have is actually RingCentral. And one of the things that’s really interesting about a number of these organizations is that, not only are they trying to look at all the metrics across the board but they decided both of the companies decided that they were going to build a centralized metrics as a store kind of the solution. Where they could make it easy for any of their developers across the company to be able to grab any of the metrics that they thought was necessary and important for their jobs. To just make it simple for people to be able to add those metrics into a centralized store to build their own dashboards if necessary so that they could really look at improving things in their functional areas. As well as making sure that the overall company could have a sense of how things were going across the board. In the past, for both of these companies, monitoring and collecting these metrics are very, very, very siloed. So not only was it siloed by function, by the network team or the application teams, but even within those organizations it was often just a couple of people had their own tiny little dashboards or their own tiny little databases collecting metrics on a very local level. And so the company wasn’t really able to even get an understanding of, what would capacity look like across the board? And it was really only understood in small little chunks which ultimately isn’t really helpful for understanding how well the company is going to progress.
Chris Churilo: 00:29:20.174 And especially with these kinds of companies where we think about companies like RingCentral, really the network is just so critical to their overall service. I mean they’re actually offering these services that without a network without a really high performing network their customers will just very quickly abandon them. And it’s gotten to a point where companies like RingCentral and a number of these other providers I think we have New Voice Media is another example on our website where it’s not just about waiting for that next nasty Twitter tweet to come out saying that the overall services and performance. It is also about making sure that they can hit those vessels before they get any kind of complaints from their customers. And in some circumstances we’ve heard from a number of customers that they’re trying to even go beyond five nines and trying to achieve 100% uptime of the networks as well as the overall service. So different approaches that we were seeing from a number of our users that are out there, some are using the number of plugins and the number of data sources to build their own monitoring solution that they can make available to customers. Some are doing it internally. Some of them are using it as a centralized store for all the metrics that they have. And I think it speaks to the versatility of the InfluxData platform. So you can gather all these metrics in what a way you want to, layer it on with all kinds of other data sources to make sure that you get a real complete view of the solution.
Chris Churilo: 00:31:10.647 So what I’ve been doing is we’ve been actually gathering a lot of the information, and we’ve started to post them on a page. The links will be made available via the main navigation before the end of the week. But if you could just use this link now, it’s just influxdata.com/solutions/networkmonitoring. And what we’ve done is we’ve started to pull together the particular Telegraf plugins that I described as well as sharing a number of other documentation and other blogs from the various network appliance vendors. In addition to that, we have also started to collect a lot more documentation on some best practices for being able to use the various Telegraf plugins. And what you can also expect to see before the end of the month, for example, is especially when configuring SNMP, we’ll actually have a set of OIDs from all the top appliance makers available via a Dockerfile so that it can be a lot it’ll be a lot easier for you to be able to configure in your environment because I know that can be pretty tricky. And in fact when you read a lot of the blogs, what oftentimes people end up telling you to do is, oh, just go to Cisco’s documentation to figure out how to setup the configuration. And what we’re trying to do is make sure that we can make it a little bit easier for everybody. So that’s kind of I think I kind of talked a little bit too fast today. Too much coffee. But I want to stop there and see if there are any questions from the audience today. Let me see. And if there are no questions because I’m actually kind of ending early. What we can do is if you just raise your hand, I’m more than happy to also just have a conversation with everybody today and we can talk a little bit more about this topic.
Chris Churilo: 00:33:27.848 Here we go. No chat. Oh, yes. Alice asks: when will the Docker container be available? That will be available by the end of this month. And so everything will be on this network solutions page. We’re just doing some final testing of the files. Making sure that everything’s okay. So we’ll have that available to you. And then there’s also some additions that we’re going to be making to the SNMP plugin that hopefully will be available in the next release. One of the things that we are well, there’s a number of features that the community’s been asking for, and so you just go to the GitHub page as you can see what Nathaniel and team are working on. But if there’s any feedback, we’d love to hear from everybody. What’s missing, what are some other things that we’re interested in? For example, we’re actually writing the requirements for putting NetFlow into Telegraf itself to make that available to everybody. So just shoot us a line and we’d be happy to hear from everybody about what they’re doing as far as network monitoring is concerned. In fact what I can do is, the moment that we go live with these OIDs, what we’ll do is I’ll just send an email to everybody that has joined us today so you guys can see that. But everything will be made available pretty soon. The one link is already up so you can see that’s where we’re going to be adding a number of these things. Presentation will be made available later on today, but you’ll get a link to the presentation that will be available first thing in the morning. If something is not right with the link, or with the presentation, with the recording, just shoot me an email. You have my email from when you registered earlier today. It’s [email protected]. We just type it in for everybody. There we go.
Chris Churilo: 00:35:49.959 And I think the most important thing is reach back to us. Let us know what you guys are working on. Where else we can help you. How else we can what other plugins you want to see us adding. This is a topic that we’ve been talking to the community quite a bit. The more that I talk to you guys, the more that we’re learning, and the more we’re able to add on, and hopefully make you guys a lot more successful. All right. Well, I’ll keep the lines open for the next couple of minutes and if you have any questions, I’ll be here.
[silence]
Chris Churilo: 00:37:17.620 Oh, I see a question from Menard. I’m sorry. I didn’t realize it was in the Q&A section. So the question he has: Is there some beta NetFlow InfluxDB testing we can try? I can definitely put you in touch with the guys from ntop so you can definitely try what they have with their ntop plugin. And once we actually have the Telegraf version of this, be more than happy to point you to that. We’re just in the we’re just finalizing the requirements for that. So we’d definitely be happy to share that with you. Hi, Samuel. Do you have a question?
[silence]
Chris Churilo: 00:38:06.717 Menard asks: So Telegraf plugin will be a derivative ntop plug in? No, not necessarily. They’re two separate things. I mean they are helping to contribute to the requirements but they’re going to be two separate things. We have a couple of sales engineers that have some very specific requirements that they want to add into the NetFlow Telegraf plugin. Let’s see. Alex asks: Is there a list to be on the network page, of Telegraf plugins provided by vendors? Network page, meaning the one you linked. Yes, there is a yes. Actually Alex, so we will be posting there’s actually a few more pages that just haven’t gone live yet that are going to have a little more details. Currently, if you go to that network solutions page, you’ll see that it links to the specific Telegraf plugins. And then once we make those OIDs available with the Dockerfiles, that will also be posted there. There’ll also be a little more document well, a lot more documentation that will be going there. So I just wanted to share that page with you because that’s going to be our central repository for everything network monitoring. And like I mentioned a few minutes ago, what I’m going to do is I’m going to keep everybody who’s been on this webinar posted. I’ll make sure that as we make updates to that, which we are doing weekly, we will send everybody an update letting you know everything that we’ve added there. Okay. I think I have another question. Open. Oh, Samuel. Which is the best way to collect data from a script inside Telegraf instance? I think there’s a couple of different ways and I think I’m going to post that question to the community because I’m going to get Daniel to help me answer that. Because I think there’s actually two different ways that I can think of that would be good, but I think that would be useful for everyone. And plus, I think he might have some better ideas. So let me just post that right now. Give everybody the link. And then that’ll be another thing that I will make sure we get linked back to this network page. So just give me a second here. And Samuel, actually your question actually pertains to more than just networks. You can you can definitely do that across the board. New topic.
[silence]
Chris Churilo: 00:41:53.967 Okay. I’m going to post that to the chat for all of us. So we can track that. And then I will type the answer for everybody.
[silence]
Chris Churilo: 00:42:18.506 All right. Esteban asks, what is the level of scalability for InfluxData? So it’s horizontally scalable so it’s up to you. So it can scale as much resources as you can provide it. I know that’s really vague, but of course keep in mind as with any kind of database, it’s going to depend on what your data looks like, what the shape of your data looks like. So within InfluxData, you can add tags to any of the values that you bring in. So if I wanted to bring in so fundamentally what InfluxDB brings in as you bring in a timestamp with the value, and attached to that value or additional information that you can add on. So any kind of metadata. So you can tag that data, that you can tag it based on where it’s coming from, even location or any other kind of information that be useful to you. And in addition to that, you don’t have to limit yourself to one value. You can actually bring in multiple values if that’s of interest to you. So by doing that, all of a sudden you can see that your data set gets to be quite large. So it’s really going to depend on what you’re doing with that data. InfluxData is compatible with Icinga? Yes, it is compatible with Icinga. In fact, let me just grab some information. Let’s see.
[silence]
Chris Churilo: 00:44:11.252 Let me just grab some documentation from you on that. And I’ll post that in the chat as well.
[silence]
Chris Churilo: 00:45:24.932 Menard asks: Is there an example of putting Nagios script results and importing them into InfluxDB? Maybe this is a similar question to Icinga compatibility. Let me see if there’s some documentation on that.
[silence]
Chris Churilo: 00:45:56.563 And then let me get back to you on that. Let me just grab some docs on that for you. So just give me a second. Esteban, as I’m grabbing this, your question is: How can I visualize the data collected? So you can visualize the data collected either by using Chronograf, which is an open source project that InfluxData has. It’s really, really simple. You just go into Chronograf, you tell it where your InfluxDB is, where the data is getting collected. There’s a set of pre-canned dashboards that are already available, so you can use that. And it’s basically it’s tied to the Telegraf plugins that you already have. Or you can also use Grafana. And I actually just wrote a blog that was published on The New Stack last week on how to use Grafana with the InfluxDB. And it’s super easy to do as well. So the moment you get both of those installed in Grafana, all you have to do is point to the InfluxDB data source. And then they have a really nice point and click visualization where you can then just select what data do you want to visualize, what kind of graph do you want it to be, etc. So it’s pretty simple. So hopefully that answered your question best.
[silence]
Chris Churilo: 00:47:39.836 Well, Menard, just give me a sec. I’m just trying to find that blog for you.
[silence]
Chris Churilo: 00:48:06.326 User info. Yes. No, no, no. That is the plugins for Icinga 2. Absolutely right.
[silence]
Chris Churilo: 00:48:32.670 Oh, Icinga plugin page is 404. Okay. Thank you. I will fix that for everybody. Well, I’ll tell the docs team to fix that. Good catch.
[silence]
Chris Churilo: 00:49:01.190 Menard, I’m just going to email you the other links. I just can’t find it right now. But I have that on my list. And there’s actually a couple of really great actually, there’s even a couple of community Q&A’s that might be useful. Let me just pull some of those in for you.
[silence]
Chris Churilo: 00:49:36.345 I’m sorry. It didn’t go through. All right. There you go. So hopefully that will help. And what I’ll do, like I said, I think I’ll actually post some of these on to that network page as well. Awesome. Okay. Well, let me just check. Are there any other questions? No. All right. Awesome. Well, cool. So stay tuned for more of an update. I will definitely send everybody an update to this on the 31st. So expect to see an email. We’ll give very specific updates to the page and all the questions that were asked today. All right. Everybody, thank you and hope to see you soon. Bye, Esteban. Bye, Menard. Talk to you later.
[/et_pb_toggle]
