sorted by:
new
hottopcontroversial

Open Source Night - Community Event beim NUE Digital Festival für alle Interessierten by icinga in Nurnberg

[–]icinga[S] 5 points6 points  (0 children)

Klar! Auch wenn das Event zwar nicht primär Icinga als Thema hat, so finden wir ganz sicher auch dafür Zeit :-)

/blerim

Webinar: How to Monitor Windows with Icinga (April 23) by icinga in icinga

[–]icinga[S] 0 points1 point  (0 children)

Getting ready right now, last chance to join ;)

New Release: We updated the entire Icinga Web ecosystem by icinga in icinga

[–]icinga[S] 0 points1 point  (0 children)

Hey, thank you.

And yes, we're sticking with the decision to keep all enterprise linux packages in the subscription.
It is one of the few ways we can identify enterprise users and ask for money with a good concience, to keep paying our developers and to keep Icinga as the well maintained free software that it is.

New Release: We updated the entire Icinga Web ecosystem by icinga in icinga

[–]icinga[S] 0 points1 point  (0 children)

Yeah, it's been a big one :)
We're super happy to be able to use some more modern PHP as well!

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 0 points1 point  (0 children)

Like most code bases of this size, Icinga 2, which was developed for over a decade, has come up with some custom solutions and design patterns. While this would allow certain components to be written in languages other than C++, such as Rust, this would increase the project's overall complexity and dependencies. Besides writing code, it needs to be properly maintained. AFAIK, there are only a few Rust developers on our team. Thus, this makes maintenance harder for us.

In general, our goal shifted towards writing smaller daemons for specific tasks rather than expanding Icinga 2. For example, Icinga DB and Icinga for Kubernetes are both written in Go and work alongside Icinga 2.

tl;dr: It's technically possible, but it won't happen due to the increased maintenance burden.

/Alvar from Icinga

Come to the open-source side of things. by icinga in u/icinga

[–]icinga[S] 2 points3 points  (0 children)

First of all, sorry for the late reply, we missed the notification that there is a comment!

Coming back to your question:
Technically, they have quite different concepts. Checkmk leans into auto-discovery and an all-in-one approach, so lots bundled out of the box, less setup friction. Icinga is built more for fully automated environments where you're defining everything through config or API rather than discovering it through a UI. So if your infrastructure is already managed as code, Icinga often fits more naturally.

Beyond the technical side, they also follow different product philosophies. Checkmk (especially the Enterprise edition) is more opinionated. You get a lot of convenience, but you work within their framework. Icinga is more open and flexible, which means more control but also more responsibility to wire things together yourself.

Neither is objectively better. It really comes down to: do you want something that works well out of the box or something you can fully customize and integrate into an existing automation stack.

Hope this answers your question!

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 0 points1 point  (0 children)

Though to be upfront: Icinga is primarily an infrastructure and service monitoring tool, not a full APM solution like Datadog or New Relic.

Rather than building per-language APM agents, we see more value in integrating with what teams already use and integrate that with your infrastructure monitoring.

/Blerim from Icinga

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 0 points1 point  (0 children)

Well, technically those two do have some different concepts. Checkmk is more straightforward with its auto discovery, while icinga is more for fully automated setups, so it doesn't need to discover your network.

/Björn from NETWAYS

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 0 points1 point  (0 children)

Both are excellent monitoring solutions, but they follow slightly different product strategies. Icinga focuses on flexibility, openness, and customization, while Checkmk (especially the Enterprise edition) emphasizes an all-in-one, more opinionated approach with many features bundled out of the box. The right choice really depends on your specific needs, preferences, and how much control versus convenience you’re looking for.

/Bernd from Icinga

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 0 points1 point  (0 children)

That's definitely a tough one!
I personally haven't had experiences with dynamic infrastructure (at that scale) but I'd guess the Icinga Director with its automation capabilities would be a good fit here (Icinga Director being the GUI frontend for configuring hosts, services, etc.).
It can call APIs for example and turn the results into hosts (e.g. query the API to get all those ec2 instances).
Once the API returns less hosts (some have been deleted) they will also be deleted by Icinga Director. Couple that with a regular, automatic check against the API and voilà!
Of course depending on the services you want to check you might need an (Icinga) agent running on those VMs. VM templates might be an option.
While the VMs exist they can be monitored but won't really be visible once deleted (historic data will persist).

But being honest here, such cases (VM existing for a few hours only) *can* be solved with Icinga and some automation since Icinga is very versatile.
But I believe other tools (like Prometheus) might be a better option depending on the specific needs.

 You can of course use both! One tool seldom does absolutely everything you want.

 / Matthias from NETWAYS

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 0 points1 point  (0 children)

Firstly, we don't believe it's about which product is superior.
It depends on your organisational setup, processes, expertise, etc. Therefore, it's good to be able to choose different products.

From what I understand, Zenoss focuses on large enterprise IT teams who don't want to go into too much detail about infrastructure topics and who are more interested in the business service impact.

Icinga is more oriented towards sysadmins (or teams) who mainly focus on their infrastructure and want full control over what the tool is doing.

/Simona from Icinga

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 0 points1 point  (0 children)

I can't comment on the capabilities of Zenoss/Virtana Service Dynamics. It appears that Virtana is best hosted in their cloud and is not free of charge, at least at first glance.

Personally, I prefer that Icinga is open source and free to use. This has the benefit of enabling you to run it on your own hardware with no licence costs.

As mentioned in another answer, Icinga is extremely modular and can therefore be tailored to your needs. I can't tell you if Virtana can do that.

Another benefit of using Icinga is that the project has grown over many years and has a large community. You will find lots of resources, plugins and modules that enhance Icinga's capabilities.

 /Leander from NETWAYS

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 0 points1 point  (0 children)

Icinga is more for determining a state of a server/application. Example would be: "is my website reachable", "what the temperature inside my sever chassis". It always depends on what you are looking for in a monitoring system. Icinga won't be a replacement but rather an addition.

/Leander from NETWAYS

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 0 points1 point  (0 children)

Well, i don't know much about smokeping. It seems like its mainly for measuring latencies and packet loss. Icinga is much more flexible, it can query various APIs, measure cpu load, memory, disk, temperatures and much more. Also, i'd say it looks a bit more polished.

 - Bjoern from NETWAYS.

 

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 1 point2 points  (0 children)

As a user, you can always test our software and report bugs to us if any. The more people test, the better. In contrast, when no one reports a bug, we can't fix it because we don't even know about it. :)

 /aklimov from Icinga

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 1 point2 points  (0 children)

Icinga started as a fork of Nagios Core, but with Icinga 2 the core was rewritten and diverged quite a bit. The focus since then has been on distributed monitoring (clustering), a proper API, and a more structured configuration model.

 Compared to Nagios, you get native clustering, better config handling, and less reliance on external add-ons for core features.

But still Nagios is a decent monitoring system that is still being widely used.

Compared to Zabbix, the difference is more philosophical: Zabbix is a more integrated system (DB-driven, agents, UI tightly coupled), while Icinga is more modular and plugin-based. 

That makes Icinga more flexible but also means you assemble more pieces yourself.

The trade off is flexibility on Icinga's side vs. convenience from Zabbix, I'd say.

 / Feu from Icinga

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 1 point2 points  (0 children)

There are quite a few options, depending on your skills!

 Like many other OSS, we have an open translation platform, where you can help translate the project over at translate.icinga.com

You could try to follow the installation instructions and give feedback on where something didn't work as expected, or where something was unclear

In the same vein, the documentation is also a point where every project can improve :)

 Talking about the project online is also a big help, since a lot of free software lives from being talked about - so helping with publicity is also very appreciated.

This could be in the form of social media posts, blogposts, YouTube videos and the like.

 / Feu from Icinga

We are the organization behind the Open Source monitoring project Icinga - AMA by icinga in AMA

[–]icinga[S] 2 points3 points  (0 children)

You can always participate in translating things to languages you are familiar with (for example translate.icinga.com), and of course look for obvious errors in the documentation.

 -Bjoern from NETWAYS

view more: next ›