Aiki Linux will be delivering a talk in the upcoming Icinga Camp Amsterdam on the 28 of June.
Our founder, Assaf Flatto will be speaking about when you need to start your monitoring.
Check out all of the talks and other topics covered at the Icinga camp at www.icinga.org , there are many interesting items and talks about the development of Icinga.
If you would like to schedule a chat with Assaf please drop us a line so we can schedule it.
After a long wait, and many failed attempts to get to an Icinga event, I finally am able to attend the icinga Berlin camp, arriving early the main lecture hall is vacant
and the reception hall is stating to fill up.
The front counter stuff was very friendly and helpful.
After the initial orientation and saying hello to the team members we moved to network and mingle with the crowd, most speaking German but there was a presence of Italians, English, Netherland and a Syrian.
The Guys from OlinData presented the smooth and powerful way that Icinga2 can and does incorporate with Puppet and how you use the Manisent they published for it, and also on how you can expand the functionality.
@dnsmichi (core developer for Icinga) gave a facinating presentation that (as is usually the case i have been told) ran over the alloted time about the Icinga2 API , showing the improvements and featrures that came and were added.
One of the things that many users have asked for in Icinga is the ability to configure the system from a WebUI , and in this talk is was announded , the Icinga Director, which is a Icinga2 Web module and enables the user to define and configure Icinga with all the regular functionality that you can do with the configuration files.
It is an “add-on” module, meaning it does not come pre-bundled in the Icinga2 Web, but you can add it when and if you want it.
There were other talks, some less interesting to the general , but one that realy was of interest to me was how a university is using Icinga2 to monitor training labs in the courses it is giving, it is able to connect to virtual boxes and determine the status of the task the student is running and inform the teacher of it’s progress. This is something both Training Partners present showed interest in as it can be used in our training courses for the “hands-on labs”.
After event dinner and Beer
All the presentation are avilable on the Icinga Camp archive.
We talked about doing another Camp in a European city in the near future and I am hoping to prestent a talk of my own.
When you start talking to System Administrators, DevOps engineers, Developers or NOC personal about open source NMS* tools, the first one that comes to mind is Nagios®. When you tell them that Icinga is a fork of Nagios, they are quick to dismiss it too, due to the reputation that Nagios carries with it.
Icinga owes its origin to Nagios’ limitations. It started as a fork from the Nagios code, and as such was encumbered with the limitation of the original design: Classic Data Centre computing – bare metal and manual management, but it evolved to something quite different.
Icinga was born due to the slow progress of the Nagios project in response to requests made by the community and the inability of that same community to contribute, send updates and improvements upstream to the core product. Wanting to allow the community to have its say, Icinga started by asking for improvement ideas. Many improvements were added to the Icinga code but the main request that was coming back from users was: redundancy and adaptability.
Creative solutions thought of: integrations with CMDBs, active-passive fail-over with data syncing etc. but none of those truly solved the inherent problem that was in Nagios – centralized standalone box that required constant updating to keep up with new servers or services.
The Icinga team knew they had to adapt the project to the Cloud frame of thought and mode of adaptability. Thus Icinga2 and the Icinga2 API were conceived and developed. Icinga2 was designed from the ground up, forgoing the old code base and starting from a fresh view. Some principals were brought over (hosts, services, hostgroups, servicegroups and dependencies) but the approach to those concepts was altered:
The configuration scheme was changed to become a configuration DSL which allows quasi-code to be incorporated in the definition and includes conditional logic for improve dynamic adaptation to the actions taken.
While the old classic UI works seamlessly with the new engine, a new Web2.0 User Interface (titled Icinga2 Web2) was designed, and includes the capabilities to incorporate other tools that expand the monitoring exposure to the Dashboard, like ELK* stack, Graphite, Nagvis and PNP4Nagios.
Icinga2 comes with a truly distributed solution that allows monitoring in geographically separated zones to sync and transfer HA capability for redundancy, which is supported by a SSL based communication to increase the security of the data transferred between nodes.
Icinga2 API is a fully fledged REST API that allows registration and configuration of nodes and services at run time without the need to modify configuration files or restart the main process for the systems to be monitored or be removed (for example: when a cloud instance goes off-line).
Icinga1 was available as a preconfigured VM* image to those that wanted to test and learn how to use the system. Moving along with the times, Icinga2 comes in other ways that are easier and faster to adopt and deploy: Docker & Vagrant. The Icinga team also provides a ready to use play-books/recipes/manifests for the most popular configuration tools: Puppet, Chef and Ansible.
If you are looking to learn about how implement Icinga2 into your organization, all those developments and more topics are covered in the official training courses provided by Icinga training partners, like Aiki Linux Ltd.
Glossary:
NMS = Network Monitoring System, a software tool that enables querying the state of the nodes that exist in the company’s infrastructure (local & remote).
ELK = ElasticSearch, LogStash & Kibana stack, a combination of software tools that allows collection and aggregation of logs and data for analysis and study.
CMDB = Configuration Management Database
As I try to show more people the good work being done by the developers on the Icinga project, I have decided to open a new Meetup group in Israel dedicated to open source monitoring : “Monitoring – The Open Source Way.
I am aware that those things start small, but hope I will be able to grow and get more people interested and willing to share.
As part of my involvement in the Icinga Project , I work in the QA and VM team , and as such with the new release of 1.7.1 I have worked on upgrading the VM’s the project provides (The project officially provide a VM based on CentOS , OpenSuSe and Debian )and have provided the new RPM based VM’s (CentOS and OpenSuse) for the community to work with , evaluate and test.
The VM’s are Virtual Box exported OVA , and can be downloaded here,
Please try them and is you find any issues , please report therm here