 Okay, welcome to our next talk. Let me introduce Marcus Frosch. He will ask why Isinga is better than Nagius. Please give him a warm applause. Thank you all for coming. What an audience. Two questions up front. Who of you is using Isinga at the moment? Wow. Anyone with Isinga too yet? Yeah, nice Alex, I know. Okay, who am I? I'm working for a German consulting company called Netways. Most of the people behind the Isinga project, which is still an open source project, I'm with the Isinga team myself since 2012, and I took care about the whole organization of the Isinga 2 daemon over the last months, so I hope we at the team are doing a pretty good job for you. I myself am a Debian developer because Alex asked me to help him with the Isinga stuff. And yeah, so what is Isinga or our understanding of it? We want to provide an open source enterprise monitoring solution, which means we want to have a monitoring solution that fits everyone from a small home user with like three computers, a bit of switches, access points up to a really large company with a lot of different networks at different locations. And we want to have that environment running just as easily as for the home user. There are a lot of people in the team who are doing packages, who are doing core development, web development and testing whatever. So if you are interested in Isinga and you want to help us or want to contribute in any way, please raise your hand and come up later or contact us on the internet. So a quick brief intro Isinga. We started as a fork from Nagios originally in 2009 because Nagios development was pretty stalled back then and it is still. And our focus was to make it better and address a few issues we had and other users saw. And this journey took us to Isinga 2, which released, which first stable release was in 2014. And around the project we built some web interfaces we tried to integrate add-ons. So what we are currently having on the project is we're running on two tracks. We're having that Isinga 1 core, which is basically still the Nagios fork. There's a lot of small changes. We have a web interface called Isinga Web 1. And we have the new fancy Isinga 2, which I'm trying to talk about today. So I'm not comparing Nagios to Isinga 1. I'm comparing Nagios to what we want to achieve as a team and what we do with Isinga 2. Isinga 2 itself is currently on the release 2.3.8, which is just from Julie. And the most difference behind Isinga 2, it's completely been rewritten from scratch. So no codes from Nagios is in there. It's even a different programming language. But the ideas are the same. So if you have an understanding about the hosts and services in Nagios, you really will have a quick way to understand Isinga 2. But there are small differences. And what's really important to us, we're taking care and we're wanting to provide a lot of packages, not only for Debian, also for other platforms, but we are in Debian itself and try to update there as soon as possible. So why is Nagios actually pretty good? You can monitor things very easily with it. Just a few configuration files host and IP address, and you're done. The software stack is so simple that you just install the package, change a few configuration files, restart the demon, and it works. There are no really external dependencies like you have in Ruby with a big software project, you have in Python with a really software project, just a few dependencies. And the way Nagios does things is also really good, because we're doing active checks to determine if services are running, if hosts are up, if everything works as you want it to be. And with a site type, we're gathering performance data, like CPU load, disk performance, whatever. Everything you want to use, and you can extend your Nagios setup just by adding plugins, either download them from the Internet, simple Perl script, Bash script, whatever, or write your own to check stuff. So why is there a Singer? Because to be honest, Nagios doesn't care about open source. I know that is a hard statement, but from the last years, I had myself the feeling it's getting worse and worse. So that's actually the download page on Nagios.org. You should see the open source version is the do-it-yourself column there. And there's a student VM costing $50 you can pay via PayPal. That's what they want you to use in your environment. And of course, they're adding tools. But most of that stuff is open source tools, they're packaging. And a few additions, which are proprietary. And that's what we don't want to do. Also, the community has experienced very weird stuff with Nagios incorporated over the last years, even when we started with the Singer back there. And the most interesting changes I've seen over the last time is the mating list is gone, replaced by a customer support forum. That's really the title of the forum. They are really enforcing that trademark, meaning if anyone that uses Nagios in its product name, like the Nagios plugins, who tells you it works with the Singer, will get problem with Nagios because they want the name Singer on their website. And the only real reason for Nagios is to sell the enterprise product. So what we want to hold up is our community support. We try, try, the requests get even more each year. But we want to have a 100% free software product. Meaning the core, but everything we do, web interface and so on. And we're really welcoming to contributors, I hope. So we never want to sell our software. And even I'm as a consultant, I want to sell my knowledge to customers to show them how it works and not the software components they're using. So the real big problem is Nagios does not really scale how it works currently. If you look at the code, you will notice it's a single loop. It will have a lot of limitations, even in mid-size environments. And you're having a lot of work to do in large environments. So we decided to roll the Singer 2, which is really multisreaded, which works clustered on multiple servers and which can do a ton of checks. So I'm just going through a few things you might have seen with Nagios in the past and the Singer one and our ideas to make it better. Have you ever added a NEB module to Nagios or a Singer? Like LiveStatus, ModGearMan, whatever. Basically, it's a mess. And we thought about making a really library we can export to modules. But what we actually wanted is to support everything that makes sense in the Singer 2. But it's still modular. You can enable what you want. You can use what you want. And maybe if you want to change something in the lock output module, you can just do that and send us a patch or change the module. We will be happy to work with your code. And all you really need to do is to tell us to enable the module, maybe change your configuration file, but only to maybe change your password for a database server, whatever, and not more. So clustering is really interesting. There is no method in Nagios to cluster in any way. You can add fancy scripts to do that, but it won't work really good. So distributed configurations. Maybe you want to have a high availability master or a satellite checking from a DMZ zone or another location in another country. It will be really hard. So that's supported in the Singer 2 out of the box. Zones on multiple locations, high availability. And it works pretty good. And all you need to do is run a Singer 2 in different configuration ways. That's what we call master, satellite, and agent. So it is not really a problem to just set up two Singer hosts that share the same master config, set another Singer host in different locations, and tell him, okay, check all your local systems and aggregate that status to our central data center to have all the status of our thousands of services there. So Nagios in security is also a big problem. They try to implement SSL in there. It is not really good. We want to enforce people to use SSL security or TLS, which means we require them to set up certificates to secure their communication between the cluster. And it's pretty easy. We even supply you the scripts to set up your own CA and whatever. Configuration. I know you have a fair share idea of how complicated it can be to set up a Singer and Nagios 1 configuration. You want to replace that by logic to let you decide on logical measures, how to assign services, how to assign host groups, just by logic. You can parametrize everything and connect your config on that. And with the latest release, we even added some kind of scripting functionality in there. I'm not sure if you understand that code snippet. Basically, what you're doing here in that double bracket, you're adding a function to the variable load reload one. And what that does is every time you run a check, it's executing that function to give you your wanted limit or your warning severity for load, meaning that in 9-5, it's actually lower to warn you about problems than it is at night. And you can do a lot of scripting in there. There are a lot of examples. And I've seen users with a lot of crazy shit, really. But it's not only about the core. We also want to have a web interface that you can use anyway. And again, from a small user at home to a big set up at a lot of big industry companies, whatever. So the real problem behind all this stuff is old legacy stuff. I personally have customers, when I have a look at the status dot of a single one, it's about 500 megabytes. And that file is parsed on every request you make to the classic web interface. So we started pretty early to use a database called the IDO to write status out there. And it's not only about displaying status, but also history. So if you don't really like the idea of running a database on your monitoring, just try it. It works. So we decided after E-Singer 2, there may come E-Singer Web 2, which is currently in development. And we're hoping to publish in September in its first stable release. It is already, you can try it out. There is a few bugs in there, but most of the stuff works. And it's a responsive web interface, meaning it runs everywhere. It runs on your smartphone even. That was a screenshot for you later. So the simplest set up you will have is E-Singer 2, a small database server. We don't care if it's MySQL or Postgres and the web interface on the other side. That's all you need to run your small set up. And we could say we want to add SQLite later in there, because stuff like onCloud runs on SQLite, but you don't really want to support it. Tell me if you want to support it. I'm not. So how does the web interface look? It's a really new look. It's not really something you will be familiar if you have had Nagios before, and not even our E-Singer web interfaces we had before. It's a really different approach. And what you see here is the main dashboard of the system. You see all the service problems that are up there. Down there are host problems, which you would see on a wider screen on the right side. And the recently recovered services. That's basically just a dashboard for a few looks. And if you go into the status of a host or service, you will see all the detailed data you will need there. But on our way to display it very easily for you, so you can see pretty quickly what's up there and what's the problem. Oh, and by the way, where is it? Oh, it's down there. Rescheduling is one click. And as I said, it runs on a smartphone. That's my Android phone. I think I did the script on Wednesday. You can see exactly the same data there. Do the same commands you would do on your PC. The only thing you would have is to access it from the internet somewhere. So, over the last years, we were pretty happy to have a big community out there. And even Debian System administrators run Icinga 1 currently, which I'm pretty glad that they do. And we want to be all about the community. So, what we started in the last year, I think, was something called Icinga Camps, which is just like a bar camp about Icinga. So, if you're in the States, you're here in October, just the day after the Puppet Conference Portland, and we will have one in Berlin next year on 1st March. So, if you're curious to try Icinga 2 out, it's really easy. Have a look at the documentation. Use the Debian packages. They work out of the box. And one of the biggest stepstone you might have is your old Nagas configuration won't work there. But it's really good to renew it. So, thank you. And can I answer any questions? No, Mike. In the beginning, you talked about integration for Puppet and some other stuff. Yeah. I missed Salt in the list. Any progress there or any thoughts there? Well, we make it easy. We are a community. I myself, I work on the Puppet stuff, because I'm a Puppet friend. There are other people working on the Ansible stuff. There are people working on the Chef stuff. I'm not sure if anything for Saltstack is there yet, but if you like to use it, to share your code, you'll be happy to have it on our Git. No problem. Okay. Configuration scripting. Was that Lewis script or something else you've created? No. Well, it's a completely own config syntax. It's not Lua or any other programming language. It's basically an implementation of object definitions. You can extend by functionalities. Okay. And basic behavior with a lot of standard functions on there. So it's admin friendly. Yeah. What does Puppet integration mean? We've got no idea, please. What's pretty neat in there, what I built for a German drugstore chain is to have a Puppet modules that install Isinger as an agent on every system. So when they set up a Linux server, Isinger 2 gets installed on there. The Puppet SSL certificates are used to connect it to the master system. So I'm using the same CA infrastructure that Puppet uses internally for the connection. And the host just shows up. And the funny thing about the configuration logic of Isinger 2, you would only have to configure, okay, there's a host called XYZ. It has this IP address. There's your cluster connection to it. And all the facts you might need, like application, role, which stage it is, how many CPU cores it is, you can just write into your Isinger 2 config. We get just standard exported resources in Puppet, maybe. And all the services that gets applied onto your system come from a catalog. So you can say, how do I want to monitor a Linux system? There are five, six services I want to monitor on there. Things like disks can be calculated dynamically. So you can add something like a hash to the host describing the disks, mount points, size, and the config language allows you to just auto add service checks for that. Just based on a wall that is assigned to the host. I can't include those examples here. But if you look on the configuration, there's a lot of examples. Something like a for loop that creates services in there. So the Puppet logic only takes care about creating the host and all the other stuff comes from your configuration catalog. You mentioned just installing Isinger a database and Isinger web. When will the Isinger web package hit the devian archive? I thought about it, releasing it for the release candidate now. But it will be more or less exactly at the same date with the release. The package is already there. I just would have to push it to unstable. Okay, the time is over. So I'm sure Markus will answer your questions if you give him a beer or coffee outside. Even without a beer. So thank you very much.