Inventory of servers without disgust
I want to share the story of one successful project to create a server inventory system. The story will be useful to those who want to finally clean up their server farm and are looking for real-life examples with answers to questions.
This is a success story, not an installation guide. Since there are plenty of step-by-step how to on the Internet and on this site for this product. But they all talk about PC inventory, and with servers there are some nuances. GLPI, despite the existing server functionality and plugins, specializes in PC inventory. But in skilled hands, you can imprison it for the needs of server Administrators (network, by the way, too). Perhaps the methods used by programmers will cause complaints, but I remind you that this is done by admins and for admins.
Probably there is no need to explain how important it is to have up-to-date information on the ward zoo of technology online. This becomes especially important when the amount begins to exceed one hundred. Surely everyone goes through an exel file with the necessary fields. With the same probability, everyone had a feeling of disgust from this method when hammering or modifying a dozen lines.
Having worked in one mobile operator where the number of servers was calculated in 4-digit numbers and appreciating the charms of the self-written inventory system used there, I was puzzled by finding something similar for my new employer. The prompt threw the Badoo blog on a geek magazine
One article mentioned the use of the FusionInventory + GLPI bundle to collect information on installed servers. Due to the great respect for other technologies used in the article, I decided to try this in our environment.
A few words about the products:
Both products are Open Source, both are periodically updated and supplemented with new features. But from both products we need only part of the functionality:
After studying the functionality and understanding what is needed and what is not, we cut off everything superfluous in the interface. It works great through a flexible profile management system. Having created a profile for server administrators and carefully scrolling through the available checkmarks, mercilessly mowed down all unused functionality. In this form, you and your colleagues will not be distracted from the main task of this resource - painstaking collection of information.
The severe legacy of GLPI as a helpdesk tool will have to be cut out while coding. My skills in PHP on which the system is written are enough for an intuitive understanding of the code, but despite this, quite a lot can be done. First, I recommend correcting localization so that inventory items are not called computers, but servers. It seems to be not a very significant point, but it helps in the proper positioning of the product within the company.
The file with Russian localization is by default stored here: /usr/share/glpi/locales/ru_RU.php. Make a backup and boldly edit the names.
Next, I recommend changing the default page to a list of servers. This will reduce access to the most requested information by a couple of clicks and remove unnecessary questions:
Next, we define the set of fields that we want to see for the servers. In our case, this resulted in the following list:
Let's try to remove unnecessary from our server display web form. To do this, edit the computer class: /usr/share/glpi/inc/computer.class.php . We find the showForm function (and comment on the output of the fields.
If we successfully transfer the remaining fields by hyphenation, we get a similar form:
I advise you to create templates with predefined fields to reduce the aversion from filling the inventory.
Hint 1: By adding a couple of lines to this function, you can get a convenient link to the item in nagios monitoring system in which there is a link back to the inventory (see screenshot above):
Hint 2: By renaming the “inventory number” field that was not used by our team to “console address” and changing the type to url, we were able to go directly to the SP console from the list of servers. Helps to quickly solve problems with a failed server.
Also, in order not to distract our administrators with unnecessary elements, I recommend commenting out these tabs in the same file (some of them can be removed by cutting rights through the profile):
In order not to drive information on components, we used the FusionInventory plugin. Very good article on how to install already has Habré . I can only add from myself what has been changed in our case.
I didn’t want to install agents in view of so many outsiders on the servers. Moreover, a single launch is enough to collect data. Not every day your OS or components on the server changes. A ball on the network (CIFS and NFS) and the FusionInventory agent distribution package unpacked on it for each OS used by the company allows collecting data in one command:
How to launch this procedure en masse in your company is up to you. After launch, we will either receive a new object in the inventory or update the data of the existing one (uniqueness is checked by serial / MAC / IP / name) with the clogged data:
In the settings of the FusionInventory plugin, disable the collection of the information that you do not need.
Hint: the result of the agent can be uploaded to a file, and then imported into GLPI. This mechanism creates an ideal API for automatically loading any data. We have implemented this feature to import data on virtual machines from our VMware farm.
The FusionInventory plugin for these tasks has its own tool, but it adds components to the server, instead of creating full-fledged elements of the server list. Which is not so convenient. In the latest version released a couple of months ago, there was a choice to create an element for virtual machines or a component to the ESXi server.
Since there are a lot of admins in the team, they periodically go on vacation or get sick, you need to collect information about active applications in TP somewhere. It is also useful to know what problems were with this server (and in our case with gatekeepers, switches, and software).
The solution is embedded in GLPI applications, but in this case they imply an application outside, not inside the IT team. To simplify the application process, a similar trimming of the functionality was made:
We get a list of open or closed tickets:
Actually, the inventory of the servers is completed, then, depending on the need, we add functionality to the plugins . I recommend these add-ons:
That's all. If readers will be interested in supplements and the way we use them, I will write a separate article about the implementation of data plug-ins, but for an understanding of what it looks like throw screenshots:
custom elements - storages
IT services
Racks
This is a success story, not an installation guide. Since there are plenty of step-by-step how to on the Internet and on this site for this product. But they all talk about PC inventory, and with servers there are some nuances. GLPI, despite the existing server functionality and plugins, specializes in PC inventory. But in skilled hands, you can imprison it for the needs of server Administrators (network, by the way, too). Perhaps the methods used by programmers will cause complaints, but I remind you that this is done by admins and for admins.
Prehistory
Probably there is no need to explain how important it is to have up-to-date information on the ward zoo of technology online. This becomes especially important when the amount begins to exceed one hundred. Surely everyone goes through an exel file with the necessary fields. With the same probability, everyone had a feeling of disgust from this method when hammering or modifying a dozen lines.
Having worked in one mobile operator where the number of servers was calculated in 4-digit numbers and appreciating the charms of the self-written inventory system used there, I was puzzled by finding something similar for my new employer. The prompt threw the Badoo blog on a geek magazine
One article mentioned the use of the FusionInventory + GLPI bundle to collect information on installed servers. Due to the great respect for other technologies used in the article, I decided to try this in our environment.
Implementation
A few words about the products:
- GLPI - a system for organizing heldesk in an enterprise with a hardware database
- FusionInventory - Automate data collection and task execution
Both products are Open Source, both are periodically updated and supplemented with new features. But from both products we need only part of the functionality:
- Storage of basic information on servers and virtual machines:
- Automatically collect this data from servers
- Tracking requests to external Tech Support
- Storage of information about TP (who provides support, at what level and when it will end)
- Association of servers with business services provided by IT
- Rack server location tracking
- Report Creation
After studying the functionality and understanding what is needed and what is not, we cut off everything superfluous in the interface. It works great through a flexible profile management system. Having created a profile for server administrators and carefully scrolling through the available checkmarks, mercilessly mowed down all unused functionality. In this form, you and your colleagues will not be distracted from the main task of this resource - painstaking collection of information.
Surface tuning
The severe legacy of GLPI as a helpdesk tool will have to be cut out while coding. My skills in PHP on which the system is written are enough for an intuitive understanding of the code, but despite this, quite a lot can be done. First, I recommend correcting localization so that inventory items are not called computers, but servers. It seems to be not a very significant point, but it helps in the proper positioning of the product within the company.
The file with Russian localization is by default stored here: /usr/share/glpi/locales/ru_RU.php. Make a backup and boldly edit the names.
Next, I recommend changing the default page to a list of servers. This will reduce access to the most requested information by a couple of clicks and remove unnecessary questions:
cp /usr/share/glpi/front/central.php /usr/share/glpi/front/central.php.b
cp /usr/share/glpi/front/computer.php /usr/share/glpi/front/central.phpNext, we define the set of fields that we want to see for the servers. In our case, this resulted in the following list:
- Server name
- Serial number
- Model
- OS
- Management Console Address
- Status
- Location
- Contact of the person responsible for the applications on the server: person and unit
Let's try to remove unnecessary from our server display web form. To do this, edit the computer class: /usr/share/glpi/inc/computer.class.php . We find the showForm function (and comment on the output of the fields.
If we successfully transfer the remaining fields by hyphenation, we get a similar form:
I advise you to create templates with predefined fields to reduce the aversion from filling the inventory.
Hint 1: By adding a couple of lines to this function, you can get a convenient link to the item in nagios monitoring system in which there is a link back to the inventory (see screenshot above):
echo "";
echo "";
echo "";
echo "fields["name"]."> Server monitoring in NAGIOS ";
Hint 2: By renaming the “inventory number” field that was not used by our team to “console address” and changing the type to url, we were able to go directly to the SP console from the list of servers. Helps to quickly solve problems with a failed server.
Also, in order not to distract our administrators with unnecessary elements, I recommend commenting out these tabs in the same file (some of them can be removed by cutting rights through the profile):
# $this->addStandardTab('ComputerVirtualMachine', $ong, $options);
# $this->addStandardTab('RegistryKey', $ong, $options);
# $this->addStandardTab('Item_Problem', $ong, $options);
# $this->addStandardTab('Link', $ong, $options);
# $this->addStandardTab('Reservation', $ong, $options);
# $this->addStandardTab('OcsLink', $ong, $options);
# $this->addStandardTab('Computer_SoftwareVersion', $ong, $options);
# $this->addStandardTab('Note', $ong, $options);
# $this->addStandardTab('Document', $ong, $options); Data collection
In order not to drive information on components, we used the FusionInventory plugin. Very good article on how to install already has Habré . I can only add from myself what has been changed in our case.
I didn’t want to install agents in view of so many outsiders on the servers. Moreover, a single launch is enough to collect data. Not every day your OS or components on the server changes. A ball on the network (CIFS and NFS) and the FusionInventory agent distribution package unpacked on it for each OS used by the company allows collecting data in one command:
- \\ share \ FusionInventory \ Windows \ fusioninventory-agent.bat
- / net / share / FusionInventory / RHEL / fusioninventory-agent
How to launch this procedure en masse in your company is up to you. After launch, we will either receive a new object in the inventory or update the data of the existing one (uniqueness is checked by serial / MAC / IP / name) with the clogged data:
In the settings of the FusionInventory plugin, disable the collection of the information that you do not need.
Hint: the result of the agent can be uploaded to a file, and then imported into GLPI. This mechanism creates an ideal API for automatically loading any data. We have implemented this feature to import data on virtual machines from our VMware farm.
The FusionInventory plugin for these tasks has its own tool, but it adds components to the server, instead of creating full-fledged elements of the server list. Which is not so convenient. In the latest version released a couple of months ago, there was a choice to create an element for virtual machines or a component to the ESXi server.
We track external applications
Since there are a lot of admins in the team, they periodically go on vacation or get sick, you need to collect information about active applications in TP somewhere. It is also useful to know what problems were with this server (and in our case with gatekeepers, switches, and software).
The solution is embedded in GLPI applications, but in this case they imply an application outside, not inside the IT team. To simplify the application process, a similar trimming of the functionality was made:
We get a list of open or closed tickets:
Addition
Actually, the inventory of the servers is completed, then, depending on the need, we add functionality to the plugins . I recommend these add-ons:
- Appliances - the ability to integrate servers with the service they provide
- Bays Management - management of server racks, their power supply, server location in a rack
- Custom Fields - add custom fields to existing elements
- Databases - Inventory of databases, association with services and servers
- File injection - Import elements from a csv file
- Objects management - Creating custom objects
That's all. If readers will be interested in supplements and the way we use them, I will write a separate article about the implementation of data plug-ins, but for an understanding of what it looks like throw screenshots:
custom elements - storages
IT services
Racks