One of the strongest points of NetEye is the extremely high level of customization that you can reach. It allows any customer to set up their environment for an almost perfect fit to their own needs or desires.

This is typically achieved with the work of our Consultant Team in understanding each customer’s needs, and results in a completely custom design that can be implemented over a new NetEye deployment. Note that we can implement this custom design because a new NetEye installation is like a sheet of blank paper on which it’s possible to draw without any constraints.

Issues That Derive from a High Level of Customization

While this approach is well suited to individual customers, it comes with two major drawbacks:

• Initial startup is slow, because everything must be built from scratch
• Since the design is highly customized, it’s harder to add new features

The first issue is of almost no concern to all customers, because the task of building from scratch is done just once. But because it is done once per Customer it has a high impact on all consultants, forcing them to re-implement the wheel each time. Furthermore, each wheel is almost identical (but not exactly the same, because each scenario slightly differs) to the previously made wheels every time.

To address this issue, on behalf of the Consultant Team, our colleague Patrick Zambelli created the NetEye 4 Community Portal repository on GitHub. Many (if not all) of our customers already know about it because it is described during our training sessions (both the former Unified Monitoring with NetEye 4 training and the current NetEye Fundamental Training).

The purpose of this repository is to collect and share common templates and best practices, providing a common (and quick-to-implement) foundation to each NetEye Deployment. While this project hits its target, it’s not so easy and user-friendly to use as you might imagine. I mean, it provides a foundation quickly and one that’s easy to use, but this foundation is really small: to keep the necessary freedom, most of the features provided come in the form of raw building materials, so they must be processed and refined before becoming ready to use. In short, this foundation still needs to be customized, and the customization is a significant undertaking that only people with a lot of experience can take on.

The second issue impacts everyone who works with NetEye, be it a consultant or a customer. The objects that each NetEye custom design implements are deeply rooted in the foundation provided by the NetEye 4 Community Portal, which in turn is customized for each Customer. Therefore, it’s not easy to apply the latest fixes and improvements coming from the NetEye 4 Community Portal to each design: the older the design, the harder it is to review it. This results in a lot of manual work when a customer wants to monitor new objects, or change the way that existing ones are monitored. In short, maintenance and extensibility are heavily impacted because of the high degree of customization.

This has simply become unacceptable: it’s imperative to come up with a new strategy that is both easy to use and has plenty of room for customization, while still being easy to install and maintain.

Taking the Design to Another Level

And so as we at Wuerth Phoenix became aware that the current strategy was not sufficient, we needed to achieve several goals:

• Have a standard design that can fit almost everywhere with no customization
• Leave room for every kind of possible customization
• Updates must not break the design, even when customized
• Setup must be doable in the blink of an eye by anyone
• Everyone must be able to use it without knowing the intimate details of how NetEye works

It turned out to be a very ambitious set of targets. The logical consequences are the following:

• We had to create a whole new design, strongly breaking from the past
• This design had to be divided into two parts:
  • One with a strong standard, providing all the functionalities
  • One that leaves ample space for customization
• The end user has to then combine the two parts to achieve the results
• Strict rules must be created that describe how to combine the two parts

Therefore, the most obvious thing is to packetize all Wuerth Phoenix knowledge into a series of immutable objects that offer all the required support to configure NetEye to do what is needed, while leaving some hooks for the end user to create their set of custom objects in the safest possible way. Also, all immutable objects must handle all the various kinds of configuration options and possibilities, which means it will become very big and complex. Therefore, to limit the degree of complexity, the whole design must be split into self-contained units with a minimum number of objects, making the design modular.

While we were at it, we also decided not to limit this design to only monitoring capabilities, but to extend it to every element of NetEye, from ITOA to Log Management (SIEM).

---

In short, every thing we know had to be assembled to create a scalable design that allows for a fast start without any technical knowledge of how NetEye works, in the form of a set of modules that can be added with nothing more than a mouse click.

---

NetEye Extension Packs

Since that moment of awareness, a year has passed: a new, large foundation has been built with its set of rules, and on top of it we started to build the new design we needed. Because this design fundamentally is packed into several blocks that extend the capabilities of NetEye, we called these blocks NetEye Extension Packs (NEP).

Each NEP contains a set of objects that addresses a specific need, be it “how to monitor a family of objects” to “add extra-features to NetEye”. There is a common base that allows for basic operations, named nep-common, and all the other packages extend its functionalities. For example, if all you want is to monitor your remote Windows-based or Linux-based servers and have a nice dashboard to show the related performance data, then nep-common is what you need; but if you want to monitor the status of some “standard” network devices, you should also install nep-network-base.

After all the required blocks are installed, you just have to create some Host Objects using the right Host Templates, fill in the missing fields, and then just deploy the configuration: NetEye will immediately start to monitor your objects using the provided set of services without bothering you with Service Template design and Service Objects creation. Just like picking features from a catalog.

At present, the number of functionalities covered is not very high, but it’s being continuously extended: NEPs follow the release cycle of NetEye, meaning that at every new version of NetEye there will be new features and bugfixes. This also means the content of NEPs are available through our official release channel.

More info and details about NetEye Extension Packs are available from the NetEye Guide: just go to the NetEye Guide site, select the version of NetEye you’re interested in (as long as it’s 4.20 or higher), and then, from the left menu, pick NetEye Extension Packs.

Getting Started with NetEye Extension Packs

The first thing someone thinks might be: “Ok, now that there is this new design, I need a brand new NetEye to start playing with it”. Roughly speaking this is ay wrong statement: all objects from NEPs have a nx- prefix to their name, so if this prefix is not used anywhere in your environment, your existing design will not be overwritten (whatever the case, it’s always best practice to try everything out in a test environment). So, if you have a NetEye deployment, you can install NEP and begin preparing a strategy to move your objects from the old design to NEP.

Before doing this, we recommend that you read the Quick start guide: it will show you how to work with NEPs on a fresh NetEye Deployment, explaining all the basics.

The Basic Idea Behind Modular Monitoring: Type Templates

Since our main concern was the design of Director Objects, all NEPs are focused on Monitoring (but remember, they don’t only implement Monitoring features). So, inside Director reside the most important changes. To achieve modularity and ease of use, the current idea of monitoring has been completely revised.

Usually, a Host Template describing a particular class of devices is created, then it’s used to create one or more Host Objects. Afterwards, Services are bound to the Host Template or Host Object. NEP completely changes this approach so that a Host Template now describes how to monitor a specific technology.

Thinking for example in terms of a Windows-based Domain Controller, the “old” approach is to provide an agent-windows-domain-controller Host Template, perhaps derived from a generic-agent-windows Host Template, which contains all the required Custom Properties and Service Objects to monitor Active Directory, DNS Server, NTP Server and SNB Server. Instead, NEP provides several Host Templates, one for each technology implemented by the Host (DNS Server, NTP Server, SMB Server and Domain Controller, as well as a standard Windows Server). All these templates describe a specific part of monitoring, providing the Data Field and Services each strictly need, and the final Host Object will be created by combining all the required templates.

In short, each Host Template provides the required Fields to implement a specific part of monitoring, making it a self-contained configuration block. In this way a Host can be easily created by picking all the templates describing the technologies that that very Host is using. Also, Hosts that implement the same piece of technology can have the same set of Data Fields and Services, and thus behave the same way. This changes the role of a Host Template from a model based on devices to a model centered around technology, allowing for the smallest reusable blocks. Using NEP terminology, we call them Monitoring-Type Templates. They can be easily spotted because they all derive from the Host Template nx-ht-type-monitor. This is the immutable part of NEP design.

And now? If NEPs are built with small immutable blocks, where do the customizations take place? Now, a Host is made up of one or more small monitoring-type blocks, so the natural idea is to provide custom-type blocks and add them as necessary to each Host Object. Customer-related data should be packed into Host Templates deriving from nx-ht-type-custom, and assigned where needed.

The design of these Templates is left to the Customer, who can model it in the most suitable way to his or her own structure, be it technological, organizational or managerial. This also makes the Template Tree less complex, and thus has more flexibility than the previous one. Using NEP terminology, we call them Custom-Type Templates, and as stated before derives from Host Template nx-ht-type-custom. This is the mutable part of NEP design.

NOTE: Only the nx-ht-type-custom Host Template is provided by NEP, and it is up to the end user to create the other required templates.

At first, this might sound confusing and difficult, but the capabilities of this design are quite ample: it provides standard, reusable small blocks that can be applied wherever needed, providing uniform behavior.

Final Thoughts

NetEye Extension Packs is a tool that aims to transfer all the experience Wuerth Phoenix has into a modular, easy to use design. It implements a whole new design meant to help the end user gain all the potential of NetEye without needing to have deep insight into the product.

So far it just covers Monitoring and Dashboarding, but it will eventually grow to cover all aspects of NetEye. The entire project follows an open source license and is available as a BitBucket Project.

If this has awakened your interest, check out the NetEye Guide, and keep updated with Jira Dashboard for the current release as well as future developments.